WebRTC Datachannels: C2 That Looks Like a Call Your Firewall Already Allows
HTTP is watched. DNS is watched. DoH is getting watched. so the implant opens a WebRTC datachannel. signaling is a tiny SDP blob on a paste you will not notice. ICE punches through NAT with STUN. DTLS wraps SCTP. suddenly you have a reliable bidirectional pipe that your firewall classifies as “media” because the UDP ports look like every other call on the floor. Zoom is not involved. your allowlist does not know that.
the trick in one paragraph
WebRTC was built so browsers could talk peer-to-peer. datachannels ride SCTP over DTLS over UDP. signaling (SDP offer/answer plus ICE candidates) can move over anything: HTTPS, a chat message, a gist, a QR code. once the channel is up, there is no URL path to grep and no Host header to sinkhole. blockers that only understand HTTP request shaping lose. blockers that understand “UDP to non-allowlisted peers with DTLS” still have a chance.

step 1: signal out of band
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-port:5000
operators paste offers where implants already look: gists, issues, game lobbies, “support” chats. the implant answers. ICE candidates exchange. if a TURN server is needed, that becomes another dependency to hide or rent.

step 2: open the channel, task as usual
once onopen fires, your C2 protocol is whatever you want: JSON, protobuf, age-encrypted blobs. no User-Agent. no path. retransmission and congestion control come free with SCTP. from the implant’s point of view it is sockets without the awkward HTTP costume.

step 3: what the wire admits
tcpdump sees UDP between high ports. maybe STUN binding requests. then encrypted DTLS records. deep packet inspection that expects HTTP Host headers has nothing to clutch. flow logs that keep byte counts and peer ASNs still help if you baseline who is allowed to call whom.

why defenders care
- UDP allowlists are soft: “media ports open” was a product decision, not a threat model.
- signaling is the weak link: pastebin/gist/chat fetches right before ICE starts are correlated gold.
- TURN is infrastructure: unknown TURN servers from endpoints are a higher-signal alert than yet another HTTPS beacon.
- works from hostile networks: NAT traversal is the feature. that is why attackers like it.
controls that are not theater
- allowlist SFU / TURN / STUN domains your company actually uses. default-deny the rest at the firewall.
- alert on signaling fetches (gist, paste, odd HTTPS) followed by new high-port UDP within N seconds.
- endpoint: browser processes doing WebRTC to unknown peers may be fine; python/node/electron sidecars doing the same often are not.
- disable WebRTC entirely on locked-down server images. servers should not be joining calls.
- for red team: scope the STUN/TURN IPs, avoid collateral NAT damage, document the signaling channel in the report.
sloth take
you hardened HTTP until beacons cried. attackers booked a peer-to-peer call with no camera and used the datachannel as a shell. if your firewall still treats UDP high ports as “probably Zoom,” congratulations on funding someone else’s C2 path. allowlist the meetings. question everything else.
