SMB Named Pipe Listeners¶

SMB named pipes provide peer-to-peer (P2P) C2 communication over internal Windows networks. Use SMB listeners when target hosts lack direct internet egress and must relay traffic through a parent beacon that does.

P2P Topology¶

SMB transport creates a parent-child beacon relationship where internal hosts chain through beacons with internet connectivity.

graph LR
    subgraph Internet
        Relay["Relay<br/>(Kali)"]
    end
    subgraph Internal Network
        A["Parent Beacon<br/>10.10.10.10<br/>(Internet Egress)"]
        B["Child Beacon<br/>10.10.10.50<br/>(No Egress)"]
        C["Deep Child<br/>10.10.10.80<br/>(Isolated Subnet)"]
    end

    Relay <-->|HTTPS| A
    A <-->|"SMB Pipe<br/>\\.\pipe\msagent_a1"| B
    B <-->|"SMB Pipe<br/>\\.\pipe\msagent_b2"| C

• Parent beacon: Has internet egress, connects to the relay over HTTPS (or any other transport). Runs an SMB pipe server that child beacons connect to.
• Child beacon: Connects to the parent's named pipe. All C2 traffic (checkin, tasks, results) is relayed through the parent to the relay.
• Chain depth: Multiple hops are supported. Beacon A can relay for B, and B can relay for C, creating deep pivot chains through segmented networks.

Creating an SMB Listener¶

Create an SMB listener using the REST API:

curl -s -X POST https://stentor.app/api/v1/listeners \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "SMB Pivot",
    "type": "smb_pipe",
    "relay_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "port": 0,
    "smb_pipe_name": "msagent_a1"
  }'

The response includes the listener ID. Start the listener:

curl -s -X POST "https://stentor.app/api/v1/listeners/$LISTENER_ID/start" \
  -H "Authorization: Bearer $TOKEN"

Stop the listener:

curl -s -X POST "https://stentor.app/api/v1/listeners/$LISTENER_ID/stop" \
  -H "Authorization: Bearer $TOKEN"

Configuration Options¶

Linking and Unlinking Beacons¶

Link Command¶

The link command connects a parent beacon to a child beacon's SMB pipe server:

link <target-host> <pipe-name>

Example:

link 10.10.10.50 msagent_a1

The parent beacon connects to \\10.10.10.50\pipe\msagent_a1 and begins relaying C2 traffic for the child.

sequenceDiagram
    participant Operator
    participant Parent as Parent Beacon
    participant Child as Child Beacon<br/>(10.10.10.50)

    Operator->>Parent: link 10.10.10.50 msagent_a1
    Parent->>Child: Connect to \\10.10.10.50\pipe\msagent_a1
    Child-->>Parent: Pipe connection established
    Parent-->>Operator: Link successful

    loop C2 Loop
        Child->>Parent: Checkin / Task Results
        Parent->>Operator: Relayed via HTTPS
        Operator->>Parent: Tasks
        Parent->>Child: Relayed via SMB pipe
    end

Unlink Command¶

The unlink command disconnects a child beacon from its parent:

unlink <beacon-id>

Example:

unlink 8a3b1c4d-5e6f-7890-abcd-ef1234567890

The child beacon goes offline but is not killed. It can be re-linked later by running link again from any beacon that can reach the host.

Pipe Naming Conventions¶

Common Legitimate Pipe Names¶

These pipe names appear on standard Windows installations and can serve as references for blending:

Encryption¶

SMB P2P connections support AES-256-GCM encryption:

• Enable: Set encrypted: true on the SMB client configuration.
• Key exchange: Uses RSA OAEP with SHA-256 and a dedicated P2P label (stentor-p2p-keyx), distinct from the HTTP key exchange label (stentor-keyx).
• Per-session: Each link establishes a new AES-256 session key. The key exchange is transparent to the operator.

The encryption flow:

1. Child requests parent's RSA public key (Phase 1)
2. Child generates a 32-byte AES-256 session key
3. Child encrypts the session key with the parent's RSA public key using OAEP-SHA256
4. Parent decrypts and confirms by sending an encrypted "OK" response
5. All subsequent messages use session.Encrypt() / session.Decrypt()

Internal Architecture¶

The SMB pipe server uses the same HTTP C2 mux as HTTP/HTTPS listeners. From the handler's perspective, the transport is invisible -- the same beacon checkin, task queue, and result submission endpoints are served over the pipe.

Troubleshooting¶