# tetanus
Rust based pentesting tool. Will work as an implant generator, c2 server, c2 client, distrobox manager, engagement data management, and markdown note generator (and maybe editor?).

# Purpose
This will basically replace my existing pentest_tool project. It will do all the same things, but will use a client/server model and include a client that will run on Windows Victim machines in order to automate some of the victim stuff.

This is really meant to be used once you have initial access to a machine during a pentest.

Rust already seems to get around EDR/AV pretty easily, but I do also intend to add some evasion features later on.

# Usage
Download the release binary from the release section, or clone this repository and build it with cargo. On first run it will check for a config file in ~/.config/tetanus, if none exist it will prompt for install. During install it will clone this repository and copy the various files needed into ~/.config/tetanus. After first run give it the -c flag to run it in client mode, and the -s flag to run it in server mode. Running in both modes with the same command is not supported at the moment, but I plan to implement that at a later time. If you need to run both the client and the server spawn each in a seperate terminal.

Modules are loaded at launch time. If you write a new module and want to load it there is a reload_modules command for this.

Other command flag options are:
- -p port number to run the server on
- -i the ip address to run the server on
- -P the password to set for the server
- -C a path to a custom config file
- -n the name to set for the client or server (will be reported to the other servers/clients)

# Design considerations
Clients and the server will be wirtten in rust. The core modules will all be written in rust. Plugins are written in RHAI script (javascript like).

The server will keep the states of all clients, projects, and notes. The clients will interact with the server. Each client will have it's own handler thread. I intend to manage the threads with either Tokio or some sort of agent system. MPSC channels will be utilized to talk to all threads. 

The network communication for all clients will be encrypted. Victim clients will use a beacon model to check if there are any commands to run. Attacker clients will just use a tcp connection that stays open.

Any important data should be either printed to the attacker client, or saved in markdown format to the notes. The markdown format will be configurable, with Obsidian being the default.

There will be both a CLI and a GUI for the Attacker clients. The server and victim clients will be CLI only.

The attacker clients should have an easy function to spin up a server on the same machine they're running on, or any server that the attacker has SSH access to.

I plan to document how to properly write the network communications so that users can create their own modules that talk to the server or extend functionality with other tools.

This repo will be empty for a bit while I get the initial client/server communications working.

# WIP
This is very much a work in progress. The current status of features is shown below.

## Working
- project life time management (creation, promotion, and removal)
- distrobox management (creation on promotion, destruction on removal)
- TUI interface (might add enhancements later)
- relay style server
- client/server communications via beacon style TCP connections
- TLS Encryption for network communications

## Working but needs review and testing
- password based authentication between client and server (DO NOT USE ON THE OPEN INTERNET UNTIL THIS IS TESTED!)
- re-authentication easy checkin
- basic obfuscation compile time techniques (mostly just stripping debug symbols)

## Planned but not implemented yet
- string mangling for the victim client
- upload/download files for the victim client
- staging HTTP server to serve the binaries
- in memory execution of tools for the victim client
- portscan automation for attacker and victim client
- SOCKs5 proxy functionality for the client
- more victim automation
  - Kerberos ticket exfil
  - initial enum commands
  - file system searching
  - bloodhound (maybe)
  - interactive shell
- more attacker client automation
  - dns and directory bruteforcing
  - attack automation (common basic exploits like ftp anonymous login, smb attack automation, etc..)
- Microsoft Online integration
  - get scope from sharepoint file
  - upload password protected zip file for the project on completion

# Writing custom modules
Modules at the moment are written in RHAI script (javascript like). Each module should be stored in it's own directory, the directory structure should be as follows:

module directory
 - config.conf 
  - contains the following information
  - name: {name} - the command that calls this module
  - output_type: {type} - the type that is returned to tetauns (string should be your default).
  - new_thread: {bool} - whether this should run on a new thread or not.
  - args: {argument1},{argument2} - the arugments the module needs from tetanus to do its job.
  - calls: {command name or none} - if this scirpt calls another command to do more stuff after it's completion.
 - help.txt
  - contains the text for the help message for this command.
 - script.rhai
  - the actual script itself.

Once a module is written the entire directory should be placed in your tetanus_config/modules/custom directory to load them into the tool. A few default modules are provided as examples in the tetanus_config/modules/default directory.