WebSocket C2

How WebSocket C2 Works

WebSocket C2 is a command channel built on a protocol that was designed for persistent, bidirectional browser-to-server communication. That design makes it attractive for attackers because it can keep a live session open while looking like ordinary web application traffic.

The core security issue is not the protocol itself, but the way its normal features, long-lived connections, message framing, and compatibility with HTTP and HTTPS, can be abused to hide command traffic inside infrastructure that defenders often allow by default.

Why WebSocket C2 Is Harder to Spot

Unlike a simple one-off request, WebSocket C2 can maintain state across many messages, which makes it easier for an implant to receive tasking, send results, and wait silently for new instructions. That persistence also reduces the value of controls that only inspect initial connections.

Because many organisations permit WebSocket traffic for legitimate applications, defenders may need to distinguish normal application behaviour from malicious controller-and-implant traffic. The challenge is often behavioural, not purely protocol-based.

WebSocket C2 is especially effective when it runs over TLS, because encryption limits the ability of network tools to inspect message content unless traffic is terminated or otherwise decrypted at a trusted inspection point.

How Organisations Check Exposure

Exposure begins with knowing where WebSockets are used in the environment, which applications upgrade HTTP connections, and which internet-facing services accept persistent sessions. Without that inventory, defenders can miss a channel that blends into expected web traffic.

Teams should review reverse proxies, application gateways, browser-facing services, and any cloud workloads that expose WebSocket endpoints. They should also compare what is actually observed on the wire with what the application owner expects, especially where interactive or real-time features are not business-critical.

For a practical baseline on hardening and validation, see WebSocket Security Guide, which covers handshake checks, authentication, per-message authorisation, validation, limits and testing.

Detection and Response Patterns

Detection usually depends on correlation, not a single signature. Suspicious indicators include unusual connection persistence, abnormal message cadence, unexpected destinations, repeated reconnection loops, and WebSocket endpoints that appear in environments where they are not required.

After suspected abuse, responders should review proxy logs, application logs, and endpoint telemetry for the lifetime of the session, not just the initial upgrade request. If a controller or implant used the channel successfully, post-incident review should focus on what was accessed, what commands were issued, and whether any credentials, tokens, or administrative sessions were exposed during the compromise.

Risk and Threat Considerations

WebSocket C2 creates a trust-abuse problem: defenders may allow the transport because it is common in modern applications, while an attacker uses that allowance to preserve command reachability and evade shallow filtering. The risk rises when security tooling treats all WebSocket sessions as ordinary application traffic.

Failure mechanism: Persistent bidirectional sessions, especially over HTTPS, can carry tasking and exfiltration inside traffic that is difficult to inspect deeply, allowing the implant to remain connected long enough for follow-on actions and persistence.

Impact: Compromise can shift from a single foothold into ongoing remote control, data theft, lateral movement, and repeated task execution without obvious new connection attempts.

Practitioner Guidance

What to watch for: Treat WebSocket endpoints as controlled attack surface, not just application plumbing. The most useful defensive judgement is whether each persistent channel is actually required, because unnecessary exposure creates avoidable space for covert command traffic.

Practitioner takeaway: If a WebSocket connection is business-critical, secure it explicitly with authentication, authorisation, logging, and behavioural monitoring, rather than assuming standard web controls will be enough.

Related resources from NHI Mgmt Group

• What do security teams get wrong about WebSocket-based local services?
• What do security teams get wrong about LLM-as-C2?
• How should security teams govern WebSocket authentication?
• What signals show that encrypted C2 traffic is still suspicious?