updated the readme some more.

This commit is contained in:
2026-08-17 11:54:21 -05:00
parent 9a69ef0ba6
commit a57c139177
+24
View File
@@ -20,6 +20,30 @@ Other command flag options are:
- -C a path to a custom config file - -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) - -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 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. 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 # 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). 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).