Advanced Transport Features¶

Beyond the core listener types (HTTP/S, DNS, SMB, QUIC, TCP Bind), Stentor's implant includes a suite of advanced transport features for evasion, resilience, and flexibility. These features operate as layers around or alongside the primary transport -- they can be combined to build highly customized C2 communication channels.

DNS over HTTPS (DoH)¶

DNS over HTTPS wraps DNS C2 queries inside standard HTTPS requests to public DoH resolvers (Cloudflare, Google, etc.). This bypasses traditional DNS monitoring that inspects raw UDP/TCP port 53 traffic, since the DNS queries travel inside encrypted HTTPS connections to well-known, trusted endpoints.

How It Works¶

sequenceDiagram
    participant Implant as Implant (Windows)
    participant DoH as DoH Resolver (e.g., Cloudflare)
    participant DNS as C2 DNS Server
    participant Backend as Backend API

    Note over Implant: Encode C2 data as DNS subdomain labels
    Implant->>DoH: HTTPS POST /dns-query (RFC 8484)
    DoH->>DNS: Standard DNS query to C2 domain
    DNS->>Backend: Forward beacon data
    Backend-->>DNS: Task data in DNS response
    DNS-->>DoH: DNS response (A/AAAA/TXT records)
    DoH-->>Implant: HTTPS response with DNS answer
    Note over Implant: Decode task from DNS records

The implant constructs DNS wire-format queries (RFC 1035), wraps them in HTTPS requests per RFC 8484, and sends them to public DoH resolvers. The C2 server receives the queries through its authoritative DNS server and encodes responses in DNS records.

Data Channels¶

DoH supports three DNS record modes for task retrieval, selectable at runtime:

The mode can be changed at runtime via SetMode(), allowing the operator to switch data channels without redeploying the implant.

Configuration¶

Subhost prefixes for different query types are configurable:

DoH Request Methods¶

POST method (default, per Cobalt Strike spec): Sends the DNS wire-format query as the request body with Content-Type: application/dns-message.

GET method: Base64url encodes the DNS query (no padding, per RFC 8484) and places it in the dns query parameter:

GET /dns-query?dns=AAABAAABAAA... HTTP/1.1
Host: cloudflare-dns.com
Accept: application/dns-message

Round-Robin Server Selection¶

When multiple DoH servers are configured, the transport uses round-robin selection across requests. This distributes traffic across multiple resolvers to avoid rate limiting and reduce the chance of a single resolver being flagged.

OPSEC Considerations¶

Domain Fronting¶

Domain fronting routes C2 traffic through Content Delivery Networks (CDNs) by exploiting the difference between the TLS SNI hostname and the HTTP Host header. Network monitors see a connection to a legitimate CDN domain, while the CDN routes the request to the actual C2 server based on the Host header.

How It Works¶

sequenceDiagram
    participant Implant as Implant
    participant CDN as CDN Edge (e.g., CloudFront)
    participant C2 as C2 Server

    Note over Implant: TLS SNI = d111111abcdef8.cloudfront.net
    Note over Implant: HTTP Host = c2.attacker.com
    Implant->>CDN: HTTPS connection (SNI: cloudfront.net)
    Note over CDN: Routes based on Host header
    CDN->>C2: Forward request to c2.attacker.com
    C2-->>CDN: C2 response
    CDN-->>Implant: HTTPS response
    Note over Implant: Network monitor sees: cloudfront.net

The FrontedClient builds URLs targeting the front domain (https://d111111abcdef8.cloudfront.net/api/v1/c2/beacon) but sets httpReq.Host = c2.attacker.com to route through the CDN to the real C2 backend.

Configuration¶

Proxy Support¶

Domain fronting supports optional proxy configuration via NewFrontedClientWithProxy(). When no explicit proxy is configured, the transport automatically falls back to IE/system proxy detection on Windows (see IE Proxy Detection below).

Integration with uTLS¶

Domain fronting uses newUTLSFrontedTransport() which sets the TLS SNI to the front domain (not the connection target). When a tlsFingerprint is specified, the TLS handshake uses a browser-matching ClientHello while keeping the SNI pointed at the CDN domain.

OPSEC Considerations¶

uTLS Fingerprinting¶

Go's standard crypto/tls library produces a distinctive TLS ClientHello fingerprint (JA3/JA4) that network security tools can identify as non-browser traffic. uTLS replaces the TLS handshake with browser-matching fingerprints using the refraction-networking/utls library, making C2 connections appear as normal browser traffic.

How It Works¶

Instead of Go's crypto/tls.Dial, the transport uses utls.UClient with a preset ClientHelloID that reproduces the exact TLS extensions, cipher suites, and handshake parameters of a specific browser version.

Supported Fingerprint Profiles¶

Transport Variants¶

uTLS is integrated into three transport constructors:

When fingerprint is empty, all constructors fall back to standard Go crypto/tls (no uTLS). The DisableCompression: true flag is always set to prevent Go from injecting Accept-Encoding: gzip which would fingerprint the client.

OPSEC Considerations¶

Rotating/Fallback Transport¶

The RotatingTransport wraps multiple transport instances and manages host selection through configurable strategies. It provides multi-host resilience, automatic failover, and an exit strategy when all C2 servers are unreachable.

Rotation Strategies¶

Duration suffixes: s (seconds), m (minutes), h (hours), d (days).

"round-robin"   -- Cycle through all hosts
"random"        -- Random selection
"failover-5"    -- Switch after 5 failures
"rotate-2h"     -- Switch every 2 hours
"rotate-7d"     -- Switch every 7 days

Max Retry / Exit Strategy¶

The MaxRetryConfig defines what happens when all hosts are unreachable:

Format: exit-[max]-[increase]-[duration]

exit-96-48-5m
  |    |   |
  |    |   +-- Escalate sleep interval to 5 minutes
  |    +------ Escalate at 48 consecutive failures
  +----------- Exit implant after 96 consecutive failures

On success after escalation, the sleep interval is automatically restored to its original value.

Host Mutation (Runtime)¶

Hosts can be added, removed, held, or reset at runtime via the operator's session:

Held Host Recovery¶

When all hosts are marked as "held" (temporarily unavailable due to failures), the transport automatically releases all hosts and retries. This prevents a deadlock state where no hosts are available.

Failover Callback¶

Register a callback to be notified when the active host changes:

rt.SetFailoverCallback(func(fromIndex, toIndex int) {
    log.Printf("Failover: host %d -> host %d", fromIndex, toIndex)
})

OPSEC Considerations¶

Adaptive Sleep¶

The AdaptiveTimer adjusts beacon sleep intervals based on time-of-day and day-of-week. During off-hours (nights and weekends), the sleep interval is multiplied by a configurable factor, reducing beacon frequency when real user traffic is low and anomalous network activity is more likely to be detected.

Configuration¶

Sleep Calculation¶

if (hour < WorkStart OR hour >= WorkEnd OR Saturday OR Sunday):
    sleep = baseSleep * OffHoursMult
else:
    sleep = baseSleep

Example with WorkStart=8, WorkEnd=17, OffHoursMult=3.0, baseSleep=60s:

OPSEC Considerations¶

TCP P2P (Peer-to-Peer Linking)¶

The TCPPeerClient enables parent beacons to connect to child beacons running in TCP bind mode. This creates peer-to-peer relay chains for reaching targets that have no outbound network access, routing C2 traffic through intermediate beacons.

How It Works¶

graph LR
    C2[C2 Server] <-->|HTTPS| Parent[Parent Beacon]
    Parent <-->|TCP P2P| Child[Child Beacon<br/>Bind Mode]
    Child <-->|TCP P2P| Grandchild[Grandchild Beacon<br/>Bind Mode]

    style C2 fill:#f96,stroke:#333
    style Parent fill:#6f9,stroke:#333
    style Child fill:#69f,stroke:#333
    style Grandchild fill:#69f,stroke:#333

The child beacon listens on a TCP port (bind mode). The parent beacon connects to it using TCPPeerClient and relays all C2 operations (checkin, task retrieval, result submission) through the P2P message protocol.

P2P Message Protocol¶

All communication uses structured P2P messages with type codes:

Connection Lifecycle¶

1. Creation: NewTCPPeerClient(host, port) -- does not connect immediately
2. First Checkin: Connection is established on the first Checkin() call
3. Operations: GetTask() and SubmitResult() use the established TCP connection
4. Teardown: Close() terminates the P2P connection

OPSEC Considerations¶

HTTP/2 Profiled Transport¶

HTTP2ProfiledClient provides HTTP/2 C2 communication with full malleable profile support. It applies the same URI, header, and body transforms as the standard ProfiledClient but forces HTTP/2 transport using golang.org/x/net/http2.Transport with ALPN h2 negotiation.

HTTP/2 vs HTTP/1.1 Profiled¶

Malleable Profile Integration¶

HTTP/2 profiled transport uses the same profile structure as HTTP/1.1:

• Checkin/GetTask: Uses http-get profile block -- metadata transforms, URI selection, termination types (cookie, parameter, header, body)
• SubmitResult: Uses http-post profile block -- output transforms, ID transforms, configurable HTTP verb

Data placement (termination types):

OPSEC Considerations¶

Header Ordering¶

Stentor's header management system removes Go's automatically injected HTTP headers and ensures only profile-defined headers appear in requests. This prevents trivial fingerprinting of the C2 client as a Go application.

Problem: Go's Default Headers¶

Go's net/http automatically injects two headers that identify the client as non-browser:

Solution¶

Two functions handle header management:

setOrderedHeaders() -- For profiled transports (ProfiledClient, HTTP2ProfiledClient):

1. Clears all existing headers from the request
2. Sets Accept-Encoding to nil (suppresses Go's auto-injection)
3. Applies profile-defined headers in their declared order
4. Falls back to profile UserAgent only if no profile header defines User-Agent

suppressGoDefaults() -- For non-profiled transports (FrontedClient, EncryptedClient):

1. Overrides User-Agent with the configured value
2. Suppresses Accept-Encoding: gzip auto-injection

OPSEC Considerations¶

IE Proxy Detection (Windows)¶

On Windows targets, the implant automatically detects system proxy settings configured through Internet Options (IE/WinHTTP). This allows the beacon to route through corporate proxy servers without manual configuration.

How It Works¶

At transport initialization, when no explicit proxy is configured, the implant calls the WinHTTP API to read the current user's IE proxy settings. This is the same mechanism that browsers and Windows applications use for proxy discovery.

Proxy Format Support¶

For per-protocol proxy strings, the http= entry is extracted. If no http= entry exists, the first entry is used as a fallback.

Automatic Integration¶

IE proxy detection is called automatically by several transports when no explicit proxy is provided:

• NewFrontedClient() -- calls applyIEProxyFallback(transport)
• NewFrontedClientWithProxy() -- falls back to IE proxy when proxyURL is empty
• newUTLSTransportWithProxy() -- falls back to IE proxy when both proxyURL and fingerprint are empty

Limitations¶

OPSEC Considerations¶

Encrypted Transport Wrapper¶

The EncryptedClient adds an AES-256-GCM encryption layer on top of HTTP transport. All C2 payloads (checkin, task retrieval, result submission) are encrypted end-to-end between the implant and the C2 server, independent of TLS.

Why Double Encryption?¶

Even if an SSL inspection appliance or CDN terminates and re-encrypts TLS, the inner AES layer protects the C2 payload from inspection.

Key Exchange Flow¶

sequenceDiagram
    participant Implant
    participant C2 as C2 Server

    Implant->>C2: GET /pubkey (fetch RSA public key)
    C2-->>Implant: RSA public key (PEM)
    Note over Implant: Generate AES-256 session key
    Implant->>C2: POST /keyx (RSA-encrypted session key)
    C2-->>Implant: Acknowledgment
    Note over Implant,C2: All subsequent traffic uses AES-256-GCM
    Implant->>C2: POST /beacon {encrypted checkin}
    C2-->>Implant: {encrypted response}

1. Implant fetches the server's RSA public key
2. Implant generates an AES-256 session key and encrypts it with the server's RSA key
3. Server decrypts the session key and stores it for the beacon's session
4. All subsequent requests use AES-256-GCM encryption

First Checkin Flow¶

The first checkin uses a special flow because the beacon does not yet have an assigned ID:

1. Generate a temporary UUID as a session identifier
2. Perform key exchange with the temporary UUID
3. Send encrypted checkin (beacon ID is nil in the body)
4. Server assigns a beacon ID and migrates the session from the temp UUID to the real beacon ID
5. Subsequent requests use the server-assigned beacon ID

Request Format¶

Encrypted requests include identifying headers:

The encrypted payload is wrapped in a JSON envelope with base64 encoding:

{"data": "base64-encoded-AES-256-GCM-ciphertext"}

Session Recovery¶

If the server restarts and loses the session key (returns HTTP 401), the client automatically:

1. Invalidates the local session (clears session key and cached public key)
2. Re-establishes the session via key exchange
3. Retries the failed request (once, to prevent infinite loops)

Custom Endpoint Paths¶

For OPSEC, the key exchange endpoint paths can be customized via SetStagerPaths(pubkeyPath, keyxPath) to match malleable profile stager paths. This avoids using default paths like /pubkey and /keyx that could be signatured.

Integration with uTLS¶

The encrypted client supports uTLS fingerprinting and proxy configuration:

• NewEncryptedClient() -- uses newUTLSTransport(fingerprint, insecureSkipVerify)
• NewEncryptedClientWithProxy() -- uses newUTLSTransportWithProxy(fingerprint, insecureSkipVerify, proxyURL)

OPSEC Considerations¶

Transport Comparison¶

See Also¶

• HTTP/HTTPS Listeners -- Standard HTTP/HTTPS transport configuration
• DNS Listeners -- Raw DNS C2 transport
• QUIC Listeners -- HTTP/3 over QUIC transport
• SMB Listeners -- Named pipe transport for lateral movement
• TCP Bind Listeners -- TCP bind mode for P2P linking
• Malleable Profiles -- Profile-based traffic shaping