NimPlant

Open source

A light-weight first-stage C2 implant written in Nim (and Rust).

950 stars0 likes1 views

About

A light-weight first-stage C2 implant written in Nim (and Rust).

By Cas van Cooten (@chvancooten), with special thanks to some awesome folks:

Kadir Yamamoto (@yamakadi), Furkan Göksel (@frkngksl) , Fabian Mosch (@S3cur3Th1sSh1t), Rafael Félix (@b1scoito), Guillaume Caillé (@OffenseTeacher), and many others!

If NimPlant has been useful to you and/or you like my work in general, your support is very welcome:

Feature Overview

Lightweight and configurable implant written in the Nim and Rust programming languages
Pretty web GUI that will make you look cool during all your ops
Encryption and compression of all traffic by default, obfuscates static strings in implant artifacts
Support for several implant types, including native binaries (exe/dll), shellcode or self-deleting executables
Wide selection of commands focused on early-stage operations including local enumeration, file or registry management, and web interactions
Easy deployment of more advanced functionality or payloads via inline-execute, shinject (using dynamic invocation), powershell in a custom runspace, or in-thread execute-assembly
Support for operations on any platform, implant only targeting x64 Windows for now
Comprehensive logging of all interactions and file operations
Much, much more, just see below :)

Instructions

Installation

A modern version of Python3 is required to run Nimplant.

Server

Install requirements.txt from the server folder (pip3 install -r server/requirements.txt).

Implant (Nim)

Install the Nim toolchain for your platform (installation via choosenim is recommended, as apt doesn't always have the latest version).
Install required packages using the Nimble package manager (cd client; nimble install -d).
If you're on Linux or MacOS, install the mingw toolchain for your platform (brew install mingw-w64 or apt install mingw-w64).
If you're on ArchLinux specifically, modify your Mingw config as per this gist (thanks @tothi!).

Implant (Rust)

Install the Rust toolchain (installation via rustup is recommended).
Install the MinGW windows target: rustup target add x86_64-pc-windows-gnu.
Recommended for increased opsec: Modify your ~/.cargo/config.toml file as per Cargo.toml and use the nighly build chain (rustup default nightly).

Note: Even if compiling on Windows, the x86_64-pc-windows-gnu target is recommended. It results in slightly larger binaries, but appears to be more stable when shellcode is generated from the resulting DLL. You may modify rust-toolchain.toml to change the target to x86_64-pc-windows-msvc, but generated shellcode may not work correctly in all cases.

Getting Started

Configuration

Before using NimPlant, create the configuration file config.toml. It is recommended to copy config.toml.example and work from there.

An overview of settings is provided below.

Category	Setting	Description
server	ip	The IP that the C2 web server (including API) will listen on. Recommended to use 127.0.0.1, only use 0.0.0.0 when you have setup proper firewall or routing rules to protect the C2.
server	port	The port that the C2 web server (including API) will listen on.
listener	type	The listener type, either HTTP or HTTPS. HTTPS options configured below.
listener	sslCertPath	The local path to a HTTPS certificate file (e.g. requested via LetsEncrypt CertBot or self-signed). Ignored when listener type is 'HTTP'.
listener	sslKeyPath	The local path to the corresponding HTTPS certificate private key file. Password will be prompted when running the NimPlant server if set. Ignored when listener type is 'HTTP'.
listener	hostname	The listener hostname. If not empty (""), NimPlant will use this hostname to connect. Make sure you are properly routing traffic from this host to the NimPlant listener port.
listener	ip	The listener IP. Required even if 'hostname' is set, as it is used by the server to register on this IP.
listener	port	The listener port. Required even if 'hostname' is set, as it is used by the server to register on this port.
listener	registerPath	The URI path that new NimPlants will register with.
listener	taskPath	The URI path that NimPlants will get tasks from.
listener	resultPath	The URI path that NimPlants will submit results to.
nimplant	riskyMode	Compile NimPlant with support for risky commands. Operator discretion advised. Disabling will remove support for `execute-assembly`, `powershell`, `shell` and `shinject`.
nimplant	sleepMask	Whether or not to use Ekko sleep mask instead of regular sleep calls for Nimplants. Only works with regular executables for now!
nimplant	sleepTime	The default sleep time in seconds for new NimPlants.
nimplant	sleepJitter	The default jitter in percent for new NimPlants.
nimplant	killDate	The kill date for Nimplants (format: yyyy-MM-dd). Nimplants will exit if this date has passed.
nimplant	userAgent	The user-agent used by NimPlants. The server also uses this to validate NimPlant traffic, so it is recommended to choose a UA that is inconspicuous, but not too prevalent.

Compilation

Once the configuration is to your liking, you can generate NimPlant binaries to deploy on your target. Currently, NimPlant supports .exe, .dll, and .bin binaries for (self-deleting) executables, libraries, and position-independent shellcode (through sRDI), respectively. To generate, run python nimplant.py compile followed by your preferred binaries (exe, exe-selfdelete, dll, raw, or all) and, optionally, the implant type (nim, rust, nim-debug, or rust-debug - will compile Nim by default). Files will be written to client/bin/ or client-rs/bin/, respectively.

You may pass the rotatekey argument to generate and use a new XOR key during compilation.

Notes:

NimPlant only supports x64 at this time!
The entrypoint for DLL files is Update, which is triggered by DllMain for all entrypoints. This means you can use e.g. rundll32 .\NimPlant.dll,Update to trigger, or use your LOLBIN of choice to sideload it (may need some modifications in client/NimPlant.nim or client-rs/src/lib.rs)

…

Compilation with Docker

Using Docker is easy and avoids dependency issues, as all required build-time and runtime dependencies are pre-installed in the container.

To use Docker, you can use the public chvancooten/nimplant container from Docker Hub (built via CI/CD), or build the Dockerfile from source.

To build from source, run the following from the main directory:
bash
docker build . -t nimplant

This will build a container tagged nimplant:latest. Note: this may take a while and produce a sizeable container due to the development dependencies!

Once this is done, you can run the container from the command line to compile your artifacts.

bash

docker run --rm -it -v ${PWD}:/nimplant chvancooten/nimplant:latest compile exe rust

Note: This is an example command, make sure to tweak arguments such as the mounted volumes to your situation.

Starting the Server

Once you have your binaries ready, you can spin up your NimPlant server! If you compiled locally, no additional configuration is necessary as it reads from the same config.toml file. To launch a server, simply run python nimplant.py server (with sudo privileges if running on Linux). You can use the console once a Nimplant checks in, or access the web interface at http://localhost:31337 (by default).

Notes:

If you are running your NimPlant server externally from the machine where binaries are compiled, make sure that both config.toml and .xorkey match. If not, NimPlant will not be able to connect.
The web frontend or API do not support authentication, so do NOT expose the frontend port to any untrusted networks without a secured reverse proxy!
If NimPlant cannot connect to a server or loses connection, it will retry 5 times with an exponential backoff time before attempting re-registration. If it fails to register 5 more times (same backoff logic), it will kill itself. The backoff triples the sleep time on each failed attempt. For example, if the sleep time is 10 seconds, it will wait 10, then 30 (3^1 * 10), then 90 (3^2 * 10), then 270 (3^3 * 10), then 810 seconds before giving up (these parameters are hardcoded but can be changed in client/NimPlant.nim).
Logs are stored in the server/logs directory. Each server instance creates a new log folder, and logs are split per console/nimplant session. Downloads and uploads (including files uploaded via the web GUI) are stored in the server/uploads and server/downloads directories respectively.
Nimplant and server details are stored in an SQLite database at server/nimplant.db. This data is also used to recover Nimplants after a server restart.
Logs, uploaded/downloaded files, and the database can be cleaned up by running nimplant.py with the cleanup flag. Caution: This will purge everything, so make sure to back up what you need first!

…

This will start both the C2 API and management web server (in the example above at http://127.0.0.1:31337) and the NimPlant listener (in the example above at https://0.0.0.0:443). Once a NimPlant checks in, you can use both the web interface and the console to send commands to NimPlant.

Starting the Server with Docker

The same chvancooten/nimplant container that can be used for compilation can be used for running the NimPlant server as well. For NimPlant to recognize the server, the config.toml and .xorkey files need to match the machine where NimPlant was compiled (this is automatically correct if you used the same Docker container for compilation). Furthermore, the config.toml file needs to be confi