Skip to content

WebRTC Datachannels: C2 That Looks Like a Call Your Firewall Already Allows

WebRTC Datachannel C2 Lab Walkthrough and Detection

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.

Lab only. screenshots use a synthetic SDP file and a local lab peer. do not stand up covert WebRTC meshes across networks you do not own. authorized red-team channel tests and detection research only. NAT-punching other people’s home routers as a demo is how presentations become incidents.

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.

Kali terminal showing a lab SDP offer for a WebRTC application datachannel with ICE ufrag and DTLS fingerprint.
Step 1: SDP offer. this is the whole “c2 config” until ICE finishes.

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.

Kali terminal lab implant completing ICE and DTLS, opening a datachannel named chat, and exchanging a whoami JSON task.
Step 2: channel open. tasking is just messages on ‘chat’.

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.

Kali terminal tcpdump of UDP between lab peers on high ports during a WebRTC datachannel session.
Step 3: wire view. UDP. maybe STUN first. then DTLS-shaped payloads. not port 53.

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.

Kali terminal hunting high-byte UDP flows to non-allowlisted peers that are not Zoom, Teams, Meet, or Webex.
Step 4: hunt datachannel-shaped UDP that is not on your SFU allowlist.

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

  1. allowlist SFU / TURN / STUN domains your company actually uses. default-deny the rest at the firewall.
  2. alert on signaling fetches (gist, paste, odd HTTPS) followed by new high-port UDP within N seconds.
  3. endpoint: browser processes doing WebRTC to unknown peers may be fine; python/node/electron sidecars doing the same often are not.
  4. disable WebRTC entirely on locked-down server images. servers should not be joining calls.
  5. for red team: scope the STUN/TURN IPs, avoid collateral NAT damage, document the signaling channel in the report.
honesty check: enterprise WebRTC (Teams, Meet, Zoom) is real traffic. the goal is not to nuke video. the goal is to stop pretending every DTLS UDP flow with a datachannel is a standup meeting.

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.