Infrastructure¶

Stentor uses a distributed architecture that separates the server (orchestration and UI), relay (attack infrastructure), and implant (target agent) into independently deployable components. This design allows operators to scale relay infrastructure independently, place relays in different network segments, and maintain a single server as the central management point.

graph LR
    subgraph Server["Stentor Server"]
        API[REST API + WebSocket]
        DB[(PostgreSQL)]
        UI[React UI]
    end

    subgraph Relays["Relay Infrastructure"]
        R1[Relay 1<br/>HTTPS Listener]
        R2[Relay 2<br/>DNS C2]
    end

    subgraph Targets["Target Environment"]
        I1[Implant A]
        I2[Implant B]
    end

    UI --> API
    API --> DB
    API <-->|WebSocket| R1
    API <-->|WebSocket| R2
    I1 -->|HTTPS| R1
    I2 -->|DNS| R2

The server handles all state management (beacons, tasks, credentials, logs) and provides the operator interface. Relays execute C2 operations: hosting listeners, generating payloads, processing implant check-ins, and routing traffic back to the server over persistent WebSocket connections. Implants run on target machines and communicate exclusively with relay-hosted listeners.

In This Section¶

• Relay Management -- Build, deploy, and manage relay agents including systemd service setup, database registration, health monitoring, troubleshooting, and multi-relay architectures.
• Target Management -- Host inventory management with single/batch creation, CIDR expansion, Nmap XML import, bulk OS updates, and upsert semantics.
• System Profiler -- Fingerprint target systems via reconnaissance landing pages, track visits with browser/OS/plugin metadata, and gather pre-engagement intelligence.
• Lab Deployment -- Deploy a complete 8-VM Active Directory lab using the Packer/Terraform/Ansible IaC pipeline with make deploy, or set up a minimal 3-VM test environment manually.