93 lines
5.5 KiB
Markdown
93 lines
5.5 KiB
Markdown
# 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.
|