Ghost Calls: Abusing Web Conferencing for Covert Command & Control

## Overview

Adam Crosser, a Staff Security Engineer at Praetorian specializing in vulnerability research and offensive security tooling, explores the problem of developing covert command-and-control (C2) channels for red team engagements. Specifically, he identifies a gap in reliable channels for **short-term C2**—used for interactive tasks like SOCKS proxying, hidden VNC, remote port forwarding, and tooling tunneling.

Crosser contrasts short-term C2 with three other operational channels: - **Long-term C2:** Persistent beacons deployed across reboots on actively operated systems. - **Backup C2:** Redundant access paths designed to survive incident response (IR) evictions (e.g., hiding credentials on non-domain-joined tablets without EDR). - **Peer-to-Peer (P2P) C2:** Internal bridges (via ICMP, SMB named pipes, etc.) linking internet-isolated sensitive segments (such as PCI environments) to internet-connected nodes.

---

## Channel Selection Criteria & Alternative Analysis

Crosser evaluates potential short-term C2 channels against four critical attributes: 1. **Latency:** Minimal round-trip time between operator and implant. 2. **Throughput:** Capacity to transfer substantial data volumes within a given time frame. 3. **Reach:** Prevalence and normality within target enterprise networks. 4. **Trust:** Infrastructure allowlisting or explicit exclusion from network security inspections.

Applying this framework to standard egress protocols revealed significant drawbacks: - **DNS over HTTP (DoH):** Low latency and trusted, but fails on throughput (transferring large volumes like 20 GB looks abnormal) and reach (enterprises typically route queries through internal DNS resolvers). - **Cloud File Storage (e.g., Dropbox):** Good throughput, but unacceptable latency for browsing internal applications (e.g., Confluence), and non-standard services are often blocked. - **Classified Aging Domains / WebSockets:** Favorable latency and throughput, but traffic flows directly to attacker-controlled infrastructure rather than trusted services. - **Email / Messaging (e.g., Slack):** Excellent reach and trust, but throughput is insufficient for tunneling and latency varies significantly.

---

## Web Conferencing Infrastructure as a C2 Vector

Web conferencing services (such as Zoom, Microsoft Teams, and Google Meet) naturally fulfill all four requirements: - **Low Latency & High Throughput:** Required by design to support human conversation and multiple concurrent video/audio streams. - **Universal Reach:** Ubiquitous across corporate endpoints and common to all employee types (unlike developer tools such as SSH). - **Exceptional Trust & Security Bypass:** To preserve real-time performance, vendors explicitly recommend that enterprise administrators exclude their traffic from: - Full-tunnel enterprise VPNs (split-tunneling). - Deep packet inspection / TLS decryption (including entire wildcard subdomains).

---

## Protocol Architecture & Egress Resilience Findings

Crosser examined the underlying protocols and failover mechanics across platforms:

- **Signaling & Media Transports:** - **Google Meet:** Uses standard WebRTC relying on DTLS for key exchange and SRTP over UDP port 3478 for audio/video media streams. - **Zoom Desktop:** Operates over UDP port 801 using a proprietary header wrapping the RTP protocol (analyzed using Princeton-published Wireshark dissectors). - **Zoom Web Client:** Relies on WebRTC data channels to transport its proprietary protocol payload. - **WebRTC Handshake:** Relies on exchanging SDP offers/answers between endpoints to share session metadata and DTLS key fingerprints.

- **Egress Resilience in Restrictive Environments:** Testing Zoom in a strictly controlled lab environment (where direct egress was blocked and outbound traffic was restricted exclusively to an inspecting web proxy) demonstrated extreme network resilience: 1. *Zoom Desktop* attempts direct TLS over TCP port 443; upon failure, it establishes a WebSocket connection over TCP port 443 to a **zone controller** for media server allocation. If direct TCP 443 / UDP 801 multimedia connections fail, it falls back to encapsulating all traffic through WebSockets on TCP port 443, successfully traversing the web proxy. 2. *Zoom Web Client* queries a **real-time web gateway** over HTTP/HTTPS, attempts direct WebRTC over UDP port 801, and upon failure, falls back to TURN over TLS.