Ghost Calls - Abusing Web Conferencing for Covert Command & Control

Ghost Calls — Abusing Web Conferencing for Covert Command & Control

Speakers: Adam Crosser

Conference: DEF CON 33

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

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Adam%20Crosser%20-%20Ghost%20Calls%20Abusing%20Web%20Conferencing%20for%20Covert%20Command%20%26%20Control.pdf

Overview

Command and control (C2) infrastructure is the nervous system of an adversary operation. Once a foothold is established on a target environment, attackers need a reliable, stealthy channel to issue commands, receive output, exfiltrate data, and maintain persistence — all without triggering detection from network monitoring tools, endpoint security agents, or threat hunting teams. As enterprise security teams have grown more sophisticated, they have tightened allowlists, deployed TLS inspection, and broadly blocked or flagged unusual outbound communications — creating an escalating challenge for red teams and adversaries alike.

Adam Crosser, a Staff Security Engineer at Praetorian, identified a gap in the available tooling for short-term, low-latency, high-throughput C2 channels during red team engagements. His answer: abuse the web conferencing infrastructure that modern enterprises have widely deployed and trusted, treating it as an always-on, organizationally blessed communication channel that is rarely subject to deep packet inspection. The resulting tool, presented at DEF CON 33 under the name "Ghost Calls," tunnels arbitrary bidirectional data through web conferencing APIs, providing a C2 channel with attributes uniquely suited to real-time short-term operations.

Background

▶ Watch: The second type is what I considered like a long-term CQ. (0:57)

Modern red team engagements have evolved well beyond simple reverse shells. Sophisticated operations involve identity-based attacks, CI/CD pipeline abuse, cloud resource pivoting, and complex lateral movement that can persist for weeks or months. Throughout this lifecycle, different types of C2 channels serve different purposes, and the failure to differentiate between them is a common operational mistake.

Crosser's mental model divides C2 channels into four categories:

1. Short-term C2: Used for real-time, interactive activities — SOCKS proxying through a compromised endpoint, remote port forwarding for NTLM relay attacks, live web browsing through a compromised host, data exfiltration over a few hours. Requires low latency and reasonably high throughput.

1. Long-term C2: The persistent implant that survives reboots and re-establishes access after interruptions. This is typically a staged beacon (Cobalt Strike, Sliver, Havoc, etc.) with configurable sleep timers. Many operators reuse the same tool for both short-term and long-term C2, which Crosser argues is operationally suboptimal — it exposes the persistent implant to detection events triggered by the more active short-term operations.

1. Backup C2: Alternative access vectors maintained in case of incident response activity that burns the primary channels. Crosser described finding tablet computers running on forklifts — non-domain-joined, EDR-free — and installing backup C2 on them as a creative example.

1. Peer-to-peer C2: Lateral tunneling for systems with internal network access but no direct internet egress — such as PCI-scoped systems. A compromised endpoint with internet access serves as a relay, linked to an isolated internal system via ICMP or SMB tunneling.

The problem Crosser set out to solve was specifically for short-term C2 on end-user devices. Existing options each fail one or more of his four selection criteria: latency, throughput, reach (prevalence in enterprise environments), and trust (likelihood of being allowlisted and excluded from TLS inspection).

Key Findings

▶ Watch: And so this isn't a vulnerability. (17:32)

1. Web conferencing platforms meet all four short-term C2 selection criteria simultaneously — they are purpose-built for real-time low-latency communication, carry enough data volume that additional covert traffic is invisible, are near-universally deployed in enterprises, and are typically allowlisted and excluded from SSL inspection.

1. Web conferencing APIs expose sufficient functionality for full bidirectional data tunneling, including the ability to send and receive arbitrary messages through meeting chat, data channels, or proprietary API mechanisms.

1. The resulting C2 channel blends into legitimate corporate traffic patterns. Web conferencing traffic routinely involves large amounts of bidirectional data (video, audio, screen share) and multiple simultaneous streams, making anomalous data exfiltration or C2 beaconing difficult to distinguish from normal usage.

1. Common C2 channel alternatives fail on reach or trust in enterprise settings: DNS-over-HTTPS is filtered by internal DNS infrastructure; cloud file storage (Box, Dropbox) is blocked for non-enterprise users; custom domains with WebSockets lack trust/allowlisting; email and messaging apps introduce latency; IRC and Tor are almost universally blocked.

1. Ghost Calls was developed as a practical red team tool at Praetorian, built to fill the short-term C2 gap identified through operational experience across multiple enterprise engagements.

Technical Deep Dive

▶ Watch: And so again, it's not a vulnerability. (18:29)

The C2 Channel Selection Framework

Crosser formalized the channel evaluation into a four-dimensional rubric. For short-term C2:

• Latency: Must be low enough for interactive use — SOCKS proxy browsing, RDP over the tunnel, live command output. Even 500ms round-trip latency makes interactive use painful; conference platforms target sub-100ms latency as a product requirement.
• Throughput: Must sustain enough bandwidth to support file transfers, data exfiltration of meaningful size, and proxied application traffic. Conference platforms routinely handle multi-megabit per-participant streams.
• Reach: The channel must be available outbound from the compromised endpoint. In most enterprises, web conferencing platforms (Zoom, Microsoft Teams, Cisco Webex, Google Meet) are explicitly allowed through firewalls and proxies because blocking them would disrupt business operations.
• Trust: Ideally, traffic to the platform is allowlisted in the proxy, excluded from TLS inspection (deep packet inspection would require the enterprise to trust-intercept certificates for a major SaaS provider, which creates compatibility issues), and not subject to per-session behavioral alerting.

Why DNS-over-HTTPS, Cloud Storage, and Custom Domains Fall Short

DNS-over-HTTPS (DoH) has low latency but limited throughput (DNS payload size constraints) and limited enterprise reach (many organizations use internal DNS resolvers that don't route to public DoH endpoints). Cloud file storage solves throughput but introduces unacceptable latency for interactive use due to polling intervals and chunking. Custom domains with WebSockets solve throughput and latency but are not trusted within enterprise environments — they won't be allowlisted and will be subject to TLS inspection unless well-aged and legitimately categorized. Email and chat tools (Slack, Teams) have good reach and trust but introduce latency and attachment size limits that limit throughput.

Web Conferencing as C2 Infrastructure

Web conferencing platforms expose multiple potential data channels:

• Meeting chat messages: Arbitrary text (and in some platforms, binary data via base64 encoding) sent to meeting participants or to the meeting itself. Polling this endpoint gives a near-real-time command channel.
• Data channels: Some conferencing platforms expose lower-level data channel APIs (analogous to WebRTC data channels) for direct binary data transfer between participants, bypassing media encoding entirely.
• Custom status/presence fields: Platforms with rich presence APIs can encode small amounts of data in user status, profile fields, or meeting metadata.
• Meeting recordings and transcripts: For exfiltration, large files can be staged as meeting recordings and retrieved via authenticated download.

The Ghost Calls architecture establishes a meeting with specific identifiers known to both the implant (on the compromised host) and the operator's control server. Both sides authenticate to the conferencing platform using credentials or API tokens. The implant polls for new commands posted to the meeting, executes them, and posts results back — bidirectional tunneling through the conferencing platform's own infrastructure.

Operational Tradecraft

Key operational considerations raised during the talk:

• Endpoint accounts vs. service accounts: Using a target organization's own Zoom/Teams tenant is maximally stealthy (traffic goes to a domain the organization already uses) but requires compromised credentials with the right licensing. Using a separate attacker-controlled tenant is less dependent on target credentials but may trigger alerts if the domain is unusual.
• Traffic blending: Joining meetings with a camera off and microphone muted keeps data volumes consistent with legitimate behavior. A real video stream could be synthesized to further blend in if volume analysis is a concern.
• Avoiding the same channel for short-term and long-term C2: Crosser explicitly recommends using Ghost Calls for short-term interactive sessions and a separate low-and-slow implant for long-term persistence. This way, if the more active short-term C2 triggers detection, the long-term persistent access remains uncompromised.
• Dealing with platform-specific authentication: Each major platform (Zoom, Teams, Webex, Google Meet) has distinct API authentication flows. Ghost Calls implements support for multiple platforms to accommodate different enterprise environments.

Implementation Notes

The tool was built using the respective platforms' official APIs (Zoom REST API, Microsoft Graph API for Teams, etc.) and designed to operate from within a standard user-mode process — no elevated privileges required. The implant component can be deployed as a standard Windows executable or injected into an existing process. API tokens obtained through phishing or credential theft from the target organization would allow the implant to authenticate as a legitimate user, making its traffic indistinguishable from normal conferencing activity at the network level.

Demo / Proof of Concept

▶ Watch: I can't I can't vouch for if it's if it works or not. (28:49)

The live demonstration showed:

1. A compromised Windows endpoint with the Ghost Calls implant running.
2. An operator console (C2 server side) connecting to the same web conferencing meeting.
3. Commands typed at the operator console appearing in the implant's poll cycle and executing on the endpoint.
4. Command output (including large file content) returned to the operator via the same conferencing API.
5. A Wireshark or proxy capture showing outbound traffic as normal-looking HTTPS requests to the conferencing platform's API endpoints — indistinguishable from legitimate meeting participation at the network level.

The demo also illustrated SOCKS proxying — browsing an internal web application through the tunnel in real time, with acceptable interactive performance consistent with the platform's design goals for real-time communication.

Defensive Implications

▶ Watch: on their systems or reset other users passwords or things of that nature. (34:27)

Network monitoring:

• Standard signature-based detection will not identify this traffic as malicious — it consists of legitimate HTTPS requests to approved SaaS domains.
• Behavioral analytics should flag endpoints that connect to web conferencing APIs but are not running the conferencing client's official process, or that use API endpoints inconsistent with normal client behavior.
• Organizations that inspect TLS traffic (HTTPS inspection proxies) and have strict application allowlists at the process-level (application control) have a higher chance of detecting the implant's API calls if it masquerades as a non-conferencing process.

API-level controls:

• Most conferencing platforms offer admin controls to restrict which users can create meetings, use the API, or join external meetings. Organizations that lock down API token issuance reduce the attack surface.
• Rate limiting and anomaly detection at the SaaS provider level (unusual API call patterns, unusual data volumes for a given user) could detect this class of abuse — an area where platform vendors could invest.

EDR and endpoint controls:

• Endpoint detection should monitor for unusual processes making outbound connections to conferencing platform domains, especially processes other than the official conferencing client binary.
• Memory-resident or injected implants using this technique could be detected via behavioral monitoring of process hollowing, DLL injection, or unusual child process creation.

Separating short-term and long-term C2:

• From a blue team perspective, understanding that attackers may use different tools/channels for different phases helps in hunting. Hunting for persistence (long-term C2 beacons) versus hunting for active interactive sessions (short-term C2) requires different detection strategies.

Key Takeaways

• Web conferencing platforms represent an underexplored covert C2 channel class because they uniquely satisfy all four criteria for effective short-term C2: low latency, high throughput, near-universal enterprise reach, and high organizational trust.
• Ghost Calls tunnels bidirectional data through conferencing platform APIs, enabling fully interactive C2 (SOCKS proxying, command execution, data exfiltration) that blends into normal enterprise traffic at the network level.
• Standard network security controls (domain blocklists, TLS inspection policies, IDS signatures) are largely ineffective against this technique given that the traffic destinations are legitimate SaaS providers.
• Blue teams should focus on process-level behavioral analytics (what process is making these API calls?), API access control within SaaS admin consoles, and anomaly detection for API usage patterns inconsistent with normal conferencing activity.
• Operationally, separating short-term and long-term C2 into distinct tools/channels is sound tradecraft that preserves persistent access even if the more active short-term channel is burned by detection.

About the Speaker(s)

▶ Watch: chain of messages can be processed. (40:22)

Adam Crosser is a Staff Security Engineer at Praetorian, a professional security firm specializing in adversarial simulation, red team operations, and offensive security tooling. His work spans vulnerability research and the development of offensive tooling used in real-world red team engagements. The Ghost Calls research emerged directly from operational experience identifying gaps in available short-term C2 tooling during enterprise engagements. This was his DEF CON 33 presentation debut on the main stage, presenting novel C2 tradecraft to the broader security community. He can be reached through Praetorian's professional channels and social media.