How 3mper0rr/c2link works
1. Overall shape
- This repository is split into two major runtime components: a Python/Flask team server and a Nim implant named c2link.
- It is a classic pull-based C2 loop: the implant repeatedly contacts the server over HTTP, instead of the server directly connecting back to the target.
2. Team server subsystem
- The server lives under c2link/server/ and is implemented in Python with Flask.
- Its role is to provide the operator-facing web dashboard/control panel, accept command input, and collect execution results from implants.
- It listens on 0.0.0.0:5000 per the README, making it the central coordination point for the lab.
3. Implant / agent subsystem
- The implant is the single Nim source file in c2link/c2link/c2link.nim.
- Its job is to be a cross-platform beacon that polls the configured server IP, receives a command, executes it on the local host, and posts back output.
- The binary is intended to run on Linux, macOS, and Windows via native build or cross-compilation.
4. Core data flow
- Operator uses the Flask dashboard to submit a command.
- The server stores or exposes that command to waiting implants.
- The implant polls every 5 seconds, retrieves the next command, executes it locally, and sends the result back.
- The server then surfaces the output in the web UI for the operator.
5. Network boundary
- All control traffic appears to be HTTP-based, which is the only documented transport in the repo.
- The implant-server boundary is the main architectural boundary: the server is the trusted control plane, while the implant is the remote execution endpoint.
6. Execution model on the target
- The implant supports system command execution on the victim machine.
- That means the target-side behavior is not a long-lived RPC server; it is a lightweight agent that periodically wakes up, polls, executes, and reports.
7. Operator interface
- The web dashboard is the main human interface.
- It provides two key functions: sending commands and viewing command output.
- In diagram terms, it is the presentation layer sitting on top of the Flask app and command/result handling.
8. Configuration and deployment
- The implant takes the server IP as an argument, with 127.0.0.1 as the default according to the README.
- That makes the server address an external configuration input rather than a compile-time constant.
- The server is started separately from the implant, which makes the system easy to stand up in a lab.
9. Build/tooling boundary
- The implant is built with the Nim compiler; the README shows both compile-only and compile-and-run workflows.
- Cross-compilation support is explicitly called out for Windows from Linux/macOS.
- The server has a minimal Python dependency footprint: just Flask.
10. Repository structure implication
- The repo is intentionally small and monolithic: one server file, one implant file, and no shared library layer.
- That suggests the protocol and state handling are likely embedded directly inside each component rather than abstracted into separate modules.
11. What to show in an architecture diagram
- Draw two main boxes: Flask Team Server and Nim Implant.
- Between them, show periodic HTTP polling and result reporting.
- From the operator to the server, show browser/web UI input.
- Mark the server as the control plane and the implant as the execution node.
Main entry points: c2link.nim HTTP Client · c2_server.py Flask App
Components 11
Operator
Human control surface
- Web UI · Operator interface for issuing commands and viewing results
Team Server
Python Flask control plane
- Flask App · Web application that handles dashboard requests and coordination
c2link/server/c2_server.py - Command Input · Receives operator-entered commands for execution
- Command Queue · Pending command exposed to polling implants
- Result Log · Collected command output returned from implants
Implant
Nim beacon on target
- Poll Loop · Repeatedly contacts the server for work on a fixed interval
c2link/c2link/c2link.nim - HTTP Client · Implements pull-based HTTP communication with the server
c2link/c2link/c2link.nim - Command Exec · Runs received system commands on the target host
c2link/c2link/c2link.nim - Server IP · Configured control address passed to the implant
Build & Deploy
Language/tooling boundary
- Nim Build · Compiles the implant, including cross-compilation workflows
- Flask Dep · Minimal Python dependency used by the server
Connections 12
- Web UI → Flask App: uses · Operator interacts with the dashboard and control panel
- Flask App → Command Input: accepts · Dashboard requests submit work for implants
- Command Input → Command Queue: queues · Commands are stored or exposed for polling clients
- Poll Loop → HTTP Client: drives · Beacon loop initiates each polling cycle
- HTTP Client → Command Queue: polls · Requests the next pending command over HTTP
- Command Queue → Command Exec: delivers · Received command is handed to local execution
- Command Exec → HTTP Client: returns output · Execution result is prepared for upload
- HTTP Client → Result Log: posts · Command output is sent back to the server
- Result Log → Flask App: surfaces · Results are displayed in the web dashboard
- Server IP → HTTP Client: configures · Server address determines where the implant polls
- Nim Build → Poll Loop: produces · Nim compiler builds the target binary
- Flask Dep → Flask App: supports · Flask provides the server runtime