Ghost Calls: Abusing Web Conferencing for Covert Command & Control

Ghost Calls: Abusing Web Conferencing for Covert Command & Control

Speaker: Adam Crosser (Staff Security Engineer, Praetorian)

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=V9znA01MqUc

Reading time: 9 minutes

Type: Briefing

TL;DR

Adam Crosser of Praetorian built a covert command-and-control (C2) channel that routes traffic through the TURN relay infrastructure of Microsoft Teams and Zoom, making attacker traffic appear as legitimate video conference data at the network level. The tool, released on GitHub alongside the talk, supports SOCKS proxying, local and remote port forwarding, and 100 Mbps+ throughput — all tunneled over TLS to Microsoft or Zoom infrastructure. Zoom patched its TURN credentials exposure before the talk; Microsoft Teams remains open.

Introduction

Red team operators have no shortage of C2 frameworks, but the options for short-term, high-throughput, low-latency covert channels are limited. Most long-term C2 solutions (Cobalt Strike, Nighthawk, custom implants) work well for persistent access and low-bandwidth command execution — but when an operator needs to proxy a browser session through a compromised host, RDP into internal infrastructure, or run a thick client application through a victim endpoint, those channels struggle.

Adam Crosser of Praetorian identified this gap and set out to solve it. The result was Ghost Calls: a tool that extracts TURN (Traversal Using Relays around NAT) relay credentials from Microsoft Teams and Zoom's conferencing infrastructure and uses them to create a WebRTC-based tunnel between an attacker's system and a victim host. At the network level, the traffic looks like a user on a video call — TLS connections to teams.microsoft.com or zoom.us subdomains, using ports and protocols that security teams actively whitelist.

▶ Watch: Introduction — Defining the C2 Problem (00:00)

The Four Attributes of an Ideal Short-Term C2 Channel

Crosser opened by formalizing the problem. He defined four types of C2 channels used on red team engagements: short-term (for active operator interaction — proxying, port forwarding), long-term (persistent beacons surviving reboots), out-of-band (alternative channels for when the primary is detected or blocked), and lateral movement channels (for pivoting within an environment).

Ghost Calls targets the short-term category, which Crosser argued is the least well-served. An ideal short-term C2 channel requires four properties:

• Low latency: Interactive browsing and RDP sessions require near-real-time responsiveness.
• High throughput: Pulling internal web apps, running thick clients, or exfiltrating data requires bandwidth.
• Reach: The channel must work across diverse enterprise networks, including segmented or air-gapped environments.
• Trust: Traffic must blend into existing allowed flows and not trigger TLS inspection, proxy authentication, or IP reputation blocks.

Crosser evaluated DNS over HTTPS, cloud file storage, email, instant messaging, and web conferencing against these criteria. Each alternative failed on at least two dimensions. DNS over HTTPS has poor throughput and low enterprise reach (most enterprises use internal DNS). Cloud storage has acceptable throughput but latency too high for interactive sessions. Email and IM have good reach but are heavily inspected.

Web conferencing was the only category that met all four requirements simultaneously.

▶ Watch: Evaluating C2 Channel Candidates (02:00)

Why Web Conferencing Infrastructure Is Uniquely Trustworthy

The post-pandemic normalization of video conferencing has had a direct impact on enterprise security posture. Microsoft and Zoom both publish vendor recommendations advising enterprise IT teams to:

• Exclude conferencing traffic from full-tunnel VPNs to prevent media degradation
• Bypass TLS inspection for conferencing traffic to preserve end-to-end encryption and performance
• Allow direct UDP and TCP connections to conferencing media servers, bypassing proxy infrastructure

Security appliances frequently ship with default allow-lists that follow these recommendations. The result is that in most enterprise environments, traffic to Teams and Zoom infrastructure flows unimpeded through firewalls, bypasses SSL inspection, and is not subjected to the same behavioral scrutiny as other outbound traffic.

Additionally, Crosser noted that even organizations using Google Meet or another primary conferencing solution will typically see Zoom and Teams traffic — employees connect to external meetings hosted on platforms their company does not officially use. This makes both platforms universally present in enterprise network telemetry, regardless of which solution the organization has standardized on.

▶ Watch: Trust Properties of Web Conferencing Infrastructure (06:00)

The Technical Foundation: WebRTC and TURN Credentials

Web conferencing platforms — particularly Zoom and Microsoft Teams — rely on WebRTC for real-time media transport. WebRTC's ICE (Interactive Connectivity Establishment) protocol uses STUN and TURN servers to establish peer-to-peer connectivity between participants.

TURN is particularly relevant here. When direct peer-to-peer connectivity fails (due to NAT, firewalls, or egress restrictions), TURN servers relay media traffic between clients. Both Zoom and Microsoft Teams provision TURN credentials to clients at session establishment — credentials that are valid for a period of days, not tied to any specific call or authenticated session, and accessible by extracting them from HTTP traffic during a meeting join flow.

Crosser demonstrated that by intercepting traffic through Burp Suite during a browser-based meeting join, an attacker can extract ~1,200 bytes of JSON containing the TURN server addresses, usernames, and credentials. These credentials then work independently of the conferencing platform — the attacker can use the standard TURN protocol (RFC 5766) to relay arbitrary TCP data through Microsoft or Zoom's infrastructure.

Zoom's TURN implementation used TURNS (TURN over TLS on port 443), making it functional even in environments that block all non-HTTPS traffic. Microsoft Teams operated similarly.

▶ Watch: WebRTC, TURN, and Credential Extraction (08:00)

Ghost Calls: Architecture and Capabilities

The tool comprises two components: a controller running on the attacker's operator laptop, and a relay running on the victim host. The relay is designed to be deployed through an existing long-term C2 implant (Cobalt Strike, Nighthawk, or custom agents) by injecting it into a running process — the relay binary itself does not need to be written to disk.

Session establishment uses WebRTC's offer/answer signaling. The controller generates an offer (an SDP blob containing ICE candidates and DTLS fingerprints), which the operator pastes into the relay side through their existing C2 channel. The relay generates an answer, the WebRTC connection negotiates through TURN, and the tunnel is established.

Once connected, the tool supports:

• SOCKS5 proxy: Route arbitrary TCP connections from the attacker through the victim host, originating traffic from the victim's IP address. Useful for accessing internal web applications, Confluence, SharePoint, and other intranet resources.
• Remote port forwarding: Bind a port on the victim host and forward connections to a service running on the attacker's laptop. Crosser's primary use case: running NTLM RelayX on his operator laptop and exposing it through the victim's network interface without ever running Python on the victim host.
• Local port forwarding: Bind a port on the attacker's laptop and forward connections through the victim. Useful for proxying thick clients (SAP, Citrix Receiver) to originate connections from a victim system.

In the live demo, Crosser downloaded a 100MB test file through the channel, then demonstrated remote port forwarding — proving that a service running on his laptop was accessible from the victim GCP VM via the TURN relay.

▶ Watch: Ghost Calls Tool Architecture and Demo (24:01)

Zoom Patches; Teams Remains Open

Crosser disclosed a notable development that arrived days before the talk: Zoom pushed a mitigation that restricts how TURN credentials can be used. Because Zoom's web client communicates with centralized media servers (rather than peer-to-peer between users), Zoom was able to modify the TURN authorization policy so credentials can only relay traffic to Zoom's own media infrastructure — not to arbitrary endpoints.

Microsoft Teams does not appear to have implemented a similar mitigation. The demo using Teams TURN credentials ran successfully during the presentation.

"I did find out on Sunday that they actually pushed a mitigation for this on the Zoom side," Crosser said. "It does still work on Microsoft Teams, which I'll show now."

The feasibility of a Zoom-style fix depends heavily on how the provider uses TURN. If a platform uses TURN only for communication with centralized media servers, it can whitelist those destinations and block relay to arbitrary hosts. If the platform also uses TURN for peer-to-peer communication between users, restricting destinations would break peer-to-peer fallback functionality.

▶ Watch: Live Microsoft Teams Demo and Network Traffic (26:01)

Defensive Considerations

Crosser was candid that network-level detection of this channel is difficult and probably not the right place to focus defensive effort. Traffic to Teams and Zoom infrastructure looks identical regardless of whether it carries legitimate video or attacker tunnels — the same TLS handshake, the same SNI values, the same port and protocol patterns.

His recommendations:

• Focus on what flows through the channel, not the channel itself. Detect secretsdump.py, Mimikatz, BloodHound collection, and other attacker tooling as it runs on the victim host — regardless of how the attacker is accessing the system.
• Deploy canary tokens on internal infrastructure. If an attacker is using this channel to browse internal resources, canary tokens on intranet pages or sensitive documents can alert on access patterns that don't originate from expected user accounts or times.
• Do not try to block conferencing traffic. The operational disruption outweighs any detection value, and the channel could shift to another allowed protocol.
• Monitor for anomalous SOCKS or proxy usage behaviors on endpoints, particularly involving processes that do not normally establish network connections.

▶ Watch: Defensive Considerations and Future Work (30:02)

Notable Quotes

"We basically just didn't have a good channel that we liked for the short-term command and control perspective." — Adam Crosser [00:00]

"At the network level it might look, for a couple of hours, like you're on a video call — but you're actually just routing traffic through their TURN infrastructure." — Adam Crosser [18:01]

"It does still work on Microsoft Teams, which I'll show now." — Adam Crosser, after disclosing Zoom's patch [26:01]

"I would focus on detecting the actual tooling that's being run afterward. I think that would probably be a little bit better of a return on your time versus trying to do direct detection of the channel." — Adam Crosser [32:02]

Key Takeaways

• Web conferencing TURN infrastructure is a viable C2 relay: Valid TURN credentials extracted from a Zoom or Teams session allow arbitrary TCP tunneling through vendor infrastructure — traffic that bypasses TLS inspection and blends into normal conferencing telemetry.
• Credentials require minimal access to extract: Any user who can join a meeting (including in-browser, no software install required) can have their HTTP traffic intercepted with a tool like Burp Suite to extract valid TURN credentials, which remain valid for days.
• The tool supports full red team workflows: SOCKS proxying, local and remote port forwarding at 100+ Mbps throughput enables interactive browser sessions, thick client proxying, and tool execution through the channel with minimal latency.
• Zoom patched; Teams remains open: Zoom's ability to restrict TURN to media-server destinations closed the attack for their platform; Teams has not implemented equivalent controls.
• Network-level detection is a poor investment: Defenders should focus on detecting attacker tooling behavior on endpoints rather than attempting to fingerprint the C2 channel itself.

Slides

No slides PDF was available for this briefing.