Core Concepts¶

This page explains how Stentor works under the hood -- the components that make up the platform, the entities you interact with, and the lifecycle of a C2 operation from deployment to post-exploitation.

If you are new to Command and Control (C2) frameworks, this page will give you the foundation you need. If you have experience with tools like Cobalt Strike, Sliver, or Mythic, you will find familiar concepts mapped to Stentor's terminology.

Architecture Overview¶

Stentor is a distributed system with four components that communicate across network boundaries:

graph LR
    subgraph Operator
        UI["Web UI<br/><small>:3001</small>"]
    end
    subgraph Server ["Stentor Server"]
        API["Backend API<br/><small>:8082</small>"]
        DB[("PostgreSQL")]
    end
    subgraph Kali ["Relay Agent"]
        Relay["Relay Service"]
        Listener["C2 Listener"]
    end
    subgraph Target ["Windows Target"]
        Implant["Implant"]
    end

    UI -->|"REST / WebSocket"| API
    API --> DB
    API <-->|"WebSocket"| Relay
    Relay --> Listener
    Implant <-->|"HTTP / DNS / SMB"| Listener

The Four Components¶

Operator UI: A React web application that runs in your browser. This is your window into the engagement -- you create listeners, generate payloads, issue commands to beacons, and view collected intelligence all through this interface. The UI communicates with the server over REST API calls and a WebSocket connection for real-time updates.
Server: The Go backend that serves as the brain of the platform. It handles authentication, stores all data in PostgreSQL, manages a persistent task queue for beacon commands, and maintains WebSocket connections to both the operator UI (via CockpitHub) and relay agents (via RelayHub). The server never communicates directly with targets -- it coordinates everything through relays.
Relay: An agent process that runs on a Kali Linux machine (or any Linux host positioned at the network edge). The relay connects back to the Stentor server over a persistent WebSocket connection and hosts C2 listeners that accept connections from implants. Think of the relay as a translator: it speaks the C2 protocol to implants on one side and the internal WebSocket protocol to the server on the other.
Implant: A compiled binary that runs on the target Windows machine. Once executed, the implant connects to a C2 listener hosted by a relay. It checks in periodically, retrieves queued tasks, executes them, and returns results. The implant includes 60+ post-exploitation modules for file operations, process management, credential harvesting, privilege escalation, lateral movement, and more.

Core Entities¶

These are the objects you create and interact with during an engagement. Understanding how they relate to each other is essential for effective operations.

Listener

A network service that accepts connections from implants. Listeners are created by the operator in the UI and hosted on a relay agent. Each listener has a type (HTTP/S, DNS, or SMB), a bind address, and a port. You must start a listener after creating it -- creation alone does not begin accepting connections.

Example: An HTTPS listener on port 8443 assigned to the Kali relay.

Relay

A deployed agent that connects to the Stentor server and hosts listeners. In a typical setup, the relay runs on a Kali Linux machine that has network access to both the server and the target environment. Multiple relays can be deployed for redundancy or to span different network segments.

Example: A relay running on Kali at 10.0.0.50, connected to the server via WebSocket.

Implant

The payload binary deployed to a target machine. An implant is configured at build time with the address of a listener to call back to. Once executed, it establishes a connection and becomes a beacon. Implants support multiple transport protocols and can be generated in various formats (EXE, DLL, shellcode).

Example: An EXE implant configured to call back to https://10.0.0.50:8443.

Beacon

A live session representing an implant that has successfully connected to a listener and checked in with the server. Beacons appear in the cockpit pivot graph and can be interacted with via the shell console. Each beacon exposes properties about the target machine:

Hostname -- the machine's network name
Username -- the user context the implant is running as
PID -- the process ID of the implant
Integrity level -- Low, Medium, High, or SYSTEM
OS and architecture -- e.g., Windows 10 x64
Internal/external IP -- network addresses
Sleep interval and jitter -- how often the beacon checks in
Last check-in time -- when the beacon was last seen

Task

A command sent to a beacon for execution on the target machine. When you type a command in the cockpit shell (e.g., ls C:\Users), it becomes a task that is queued on the server. The task is delivered to the implant on its next check-in, executed, and the results are returned asynchronously.

Example: A screenshot task queued for beacon on WORKSTATION-01, delivered on next check-in, result displayed in the console.

The C2 Lifecycle¶

A complete Stentor operation follows this sequence from initial setup to active engagement:

1. Deploy¶

Install and start the Stentor server and database. Deploy a relay agent on a machine positioned to reach target networks (typically a Kali Linux VM). The relay connects to the server over WebSocket and registers itself.

2. Configure¶

Create a listener in the Stentor UI. Choose the transport type (HTTP/S is the most common), assign it to a relay, and configure the bind address and port. Optionally apply a malleable C2 profile to shape how the traffic appears on the wire.

3. Start¶

Start the listener from the UI. The server sends a start command to the relay via WebSocket, and the relay begins accepting connections on the configured port.

4. Generate¶

Generate an implant payload configured to call back to the listener address. Choose the format based on your delivery method -- a standalone EXE for direct execution, a DLL for sideloading, or raw shellcode for injection.

5. Execute¶

Deliver the payload to the target and execute it. Delivery methods vary: phishing emails, drive-by downloads, USB drops, exploitation, or manual placement during physical access.

6. Beacon¶

The implant connects to the listener, and the relay forwards the connection to the server. A new beacon appears in the cockpit pivot graph. The operator can now see the target machine's details and begin issuing commands.

7. Operate¶

Issue commands via the cockpit shell. Commands flow from the operator through the server and relay to the implant, and results flow back along the same path. Common operations include:

File system browsing and file transfer
Process enumeration and injection
Credential harvesting (SAM, LSASS, Kerberos tickets)
Privilege escalation (UAC bypass, token manipulation)
Network reconnaissance (port scanning, LDAP queries)
Screenshot and keystroke capture

8. Persist¶

Establish persistence mechanisms so the implant survives reboots and re-establishes contact. Move laterally to additional machines, escalate privileges, and expand the engagement footprint.

Task Flow¶

The following diagram shows how a command travels from the operator to the target and back:

sequenceDiagram
    participant Op as Operator
    participant Srv as Server
    participant Rel as Relay
    participant Imp as Implant

    Op->>Srv: Issue command (REST API)
    Srv->>Srv: Queue task for beacon
    Note over Imp: Implant sleeps between check-ins
    Imp->>Rel: Check-in (HTTP/DNS/SMB)
    Rel->>Srv: Forward check-in (WebSocket)
    Srv->>Rel: Deliver queued tasks
    Rel->>Imp: Send tasks in response
    Imp->>Imp: Execute tasks locally
    Note over Imp: Next check-in cycle
    Imp->>Rel: Return results on next check-in
    Rel->>Srv: Forward results (WebSocket)
    Srv->>Op: Display output (WebSocket push)

Asynchronous by Design

Commands are not delivered instantly. The implant must check in before it receives queued tasks, and results are returned on the subsequent check-in. This delay is intentional -- it makes the implant harder to detect. See Communication Model below.

Communication Model¶

Beacon communication is asynchronous and pull-based. Understanding this model is critical for effective operations.

Sleep and Jitter¶

Each beacon has a configurable sleep interval -- the time between check-ins. A beacon sleeping at 60 seconds with 20% jitter will check in every 48 to 72 seconds (60 ± 12 seconds of randomization).

Longer sleep = stealthier but slower response times
Shorter sleep = faster interaction but more network activity (higher detection risk)
Interactive mode (sleep 0 or near-zero) provides near-real-time interaction but generates continuous traffic

You can change a beacon's sleep interval at any time with the sleep command.

Transports¶

Stentor supports three transport protocols for implant-to-relay communication:

HTTP/HTTPS: The most common transport. Implant makes HTTP requests to the listener, blending with normal web traffic. HTTPS adds TLS encryption. Malleable C2 profiles can transform the traffic to mimic legitimate websites, APIs, or CDNs.
DNS: Data is encoded in DNS queries and responses. Stealthier than HTTP because DNS traffic is rarely inspected, but significantly slower due to the small payload size per query. Best for low-bandwidth persistence channels.
SMB: Uses Windows named pipes for communication. Ideal for internal pivoting between machines on the same network segment without generating internet-bound traffic. SMB beacons chain through other beacons that have network access.

Task Queue¶

The server maintains a persistent task queue per beacon. When you issue a command, it is added to the queue immediately but only delivered when the beacon checks in. If you queue multiple commands, they are delivered together in a batch on the next check-in. This means you can issue several commands and walk away -- they will all execute in sequence.

Security Model¶

Stentor secures communication at every layer of the architecture.

Operator to Server: All API requests require a JWT (JSON Web Token) issued during login. Tokens are short-lived and can be refreshed. Passwords are hashed with Argon2id. The WebSocket connection to CockpitHub requires the same JWT authentication.
Server to Relay: The relay authenticates to the server using a shared secret (RELAY_SECRET environment variable). The WebSocket connection is persistent and bidirectional, with the server validating the relay's identity on connection.
Relay to Implant: Implant communication is encrypted using RSA for key exchange and AES for payload encryption. Malleable C2 profiles disguise the traffic pattern to evade network-level inspection, making C2 traffic look like legitimate web requests, API calls, or other benign network activity.

What's Next¶

With an understanding of the architecture and lifecycle, you are ready to start building your C2 infrastructure:

Listeners & Transports -- create and configure your first listener
Payload Generation -- generate implant payloads for target delivery
Beacon Commands -- learn the commands available in the cockpit shell