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)

Attack Client

The attack client runs in a TUI. The TUI is separated into 2 parts, the top part and the bottom part. The top part contains three, sometimes four sections. From left to right the sections are project list, output box, info box. The project box contains a list of projects that are currently being tracked. You can select from the list by holding control and pressing the up and down arrow keys. The output box shows the output of commands you run, and the info section displays information about the selected project and tetanus's config. If there are any tracked long running operations such as rustbusting the infobox will be split into two sections, a top and bottom section. The information previously shown will be displayed in the top section, and a list of long running operations will be displayed in the bottom section, along with a percentage of completeness. By default scrolling in any part of the TUI will scroll the output box, unless your mouse cursor is over the info box then the info box will be scrolled. If the output box is at the bottom of its scrolling then it will keep up with new output that comes in, if it's anywhere else (like you've scrolled up to read something), then it will not autmoatically follow, allowing you to review data easily without being interrupted by new input coming in.

The bottom part is the Command input box. This is where you type commands to run. Pressing enter will run the command in the box and clear the box. Pressing arrow up or down cycles through previous commands run like it does in a terminal.

If any command requiers elevated privileges (root) it will exit the tui to run sudo, then after the sudo command is executed it will return to the tui, keeping any output in the output box for review if needed.

Connecting to a server

To connect to a server from an attacker client you first run the new_server command. This will prompt you for the server IP address and port number. It will then add the server to the Attacker client's list of known servers. If it is the first server added the server will be marked as selected. If you want to select a different server use the select_server command. Once a server is added and selected you then run the connect_server command to connect to the currently selected server. This will send the CERT_REQ packet and save the certificate for encryption. After that is successful you then run the login_server command with the password as an argument to authenticate to the server. If authentication is successful the client will check in on the configured checkin timer, if it is not authenticated then it will wait until it is successfully authentiated before checking in.

Generating a victim

To generate a victim binary you must first be authenticated to a server, and have that server selected. Then you can run the generate_victim command to read the victim source code from tetanus_config/victim/rust_victim, format the string to replace |||CERT||| with the certificate of the selected server, |||SERVER||| with the address of the selected server, and |||PASSWORD||| with the password for the server. It will then save the source code and default cargo setup in the project_files directory, and compile the binary. The generate_victim command takes one argument for the target system type, currently supported are windows and linux. The binary will then be saved in either project_files/victim/target/release/tetanus_victim or project_files/victim/target/x86_pc-windows-gnu/release directory depending on the target type.

Server

Running the binary with the -s flag will start server mode. In server mode it will check for already generated certificates, as well as the names.txt file. If the ip or hostname the server is configured to run on is not in the names.txt list it will regenerate a self-signed certificate and corrosponding private key for the server. The server logs everything sent to it in stdout, I do plan on adding a logging flag to log data to a file as well. The server does not take any input or commands. To stop the server just ctrl+c it.

How it works

The attacker client holds the majority of the information. It keeps the projects, project configurations, command executions, and client configuration. The attack client can be run standalone if you just want distrobox mangement, project management, and attacker tooling automation. Connecting to a server allows you to control victim clients that are also connected to the same server, and in the future will allow for collaboration on projects. The server acts as a relay more than anything else. All clients connect to the server in a beacon style TCP connection mode. On a set timer the clients connect to the server, send any messages qued for the server, and recieve any commands the server has qued for them. This timer is configurable client side, and victim timers are configurable from the attacker client side.

Security considerations

The attacker client uses a trust on first connect style protocol to obtain the TLS Certificate of the server. When you first connect to a server from the attacking client, the client sends a clear text CERT_REQ packet. The server then sends the certificate to encrpyt all future communications with. The attcker client then uses this certificate to send a password to authenticate with the server. This password is then prepended to any messages the client sends to the server. If the client ever sends a bad password it will be required to re-authenticate. The password is determined by the server, and can be set at run time, or if no password is provided at run time it randomly generates one for you.

The victim client is generated after the attacker client authenticates with a server. The password for the victim is formatted into the source code, as is the certificate to encrypt the traffic. The victim client never makes any unencrypted network connections. The password is also prepended to every packet sent from the victim to the server. If the victim ever sends a bad password it is disconnected.

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 act as a relay, allowing clients to talk to one another. The attacker client will keep the states of projects, notes, and be the holder of what commands can be run. Collaboration will work with one client querying the source client for projet information and any data related to a project. This will require authentication not only to the server, but the source client as well. By default collaborating on a project will not save the project into your tracked projects configuration information, but that will be doable via a command. Collaboration is not implemented yet.

The network communication for all clients will be TLS encrypted. Clients will use a beacon model to check if there are any commands to run.

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

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

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.

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.