Abusing TURN Infrastructure for Covert C2 and Egress Bypassing

TLDR: Modern web conferencing platforms rely on TURN servers to relay media traffic, creating a massive, trusted, and often unmonitored egress path for attackers. By extracting legitimate TURN credentials from these platforms, red teamers can proxy arbitrary traffic through these relays to bypass strict egress filtering and maintain persistent C2. This technique effectively hides malicious traffic within the noise of standard video conferencing, making it a powerful tool for post-exploitation in hardened environments.

Security researchers often focus on the front door of an application, but the most resilient C2 channels are frequently found in the infrastructure that organizations explicitly trust to bypass their own security controls. Web conferencing platforms like Zoom and Microsoft Teams are ubiquitous in enterprise environments. To ensure these tools function reliably, network administrators often whitelist their traffic, disable TLS inspection, and permit direct egress to their relay infrastructure. This creates a blind spot that is ripe for abuse.

The Mechanics of TURN Abuse

The core of this technique lies in the Traversal Using Relays around NAT (TURN) protocol. TURN servers are designed to relay media traffic between endpoints that cannot establish a direct peer-to-peer connection due to restrictive NAT or firewall configurations. Because these servers are essential for the functionality of real-time communication, they are rarely subjected to the same level of scrutiny as other external-facing infrastructure.

During the research presented at DEF CON 2025, it was demonstrated that an attacker can obtain valid TURN credentials by simply interacting with the web client of a conferencing platform. Once these credentials are in hand, they can be used to authenticate against the provider's TURN servers. From an attacker's perspective, this transforms a legitimate media relay into a high-performance, trusted SOCKS proxy.

The TURNt tool, released alongside this research, automates the process of obtaining these credentials and establishing a relay connection. By running a controller on an operator-controlled system and a relay component on a compromised host, an attacker can tunnel traffic through the conferencing provider's infrastructure. Because the traffic is encapsulated within the protocol expected by the TURN server, it blends perfectly with legitimate video and audio streams, effectively bypassing network-based detection systems that look for anomalous traffic patterns.

Technical Implementation and Egress Bypassing

When performing a red team engagement, the primary challenge is often exfiltrating data or maintaining C2 from a host with restricted egress. Traditional methods like DNS tunneling or ICMP exfiltration are slow and easily flagged by OWASP-defined monitoring tools. TURN abuse, however, provides a high-bandwidth, low-latency alternative.

To implement this, an attacker first needs to extract the TURN configuration. For many web clients, this is returned as part of the initial handshake or session initialization. Once the credentials are obtained, the attacker can use them to configure a local SOCKS proxy. The following command structure illustrates how one might initiate a relay connection using the tool:

# Example of initializing the relay component on a compromised host
turnt-relay --offer [OFFER_STRING] --credentials [TURN_CREDS]

# Configuring the local controller to proxy traffic
turnt-control --config config.yaml

The impact of this technique is significant. Because the traffic is routed through the conferencing provider's IP space, it is often treated as "known good" traffic by perimeter firewalls. Furthermore, since many organizations explicitly disable TLS inspection for these platforms to avoid performance degradation, the tunneled traffic remains encrypted and opaque to security appliances.

Real-World Applicability and Detection

In a typical engagement, this technique is most effective when the target environment has strict egress rules but allows traffic to common SaaS providers. If you are testing an environment where you have gained an initial foothold but cannot reach your C2 server directly, checking for the presence of web conferencing software is a logical next step. Even if the software is not actively running, the infrastructure it relies on is often accessible.

Defenders should not assume that all traffic to a trusted SaaS provider is benign. While blocking all TURN traffic is impractical for organizations that rely on these tools, there are ways to mitigate the risk. Monitoring for anomalous TURN authentication patterns—such as credentials being used from unexpected IP ranges or at unusual times—can help identify abuse. Additionally, organizations should enforce strict egress policies that limit the range of IP addresses that internal hosts can use to communicate with external TURN relays.

The reliance on third-party infrastructure for core business operations creates a unique set of security trade-offs. By understanding how these platforms handle NAT traversal and media relaying, researchers can identify new, resilient paths for communication that bypass traditional network defenses. The key is to recognize that trust is not a static property of a domain or an IP address, but a dynamic relationship that can be exploited if the underlying protocols are not properly secured. As red teamers continue to push the boundaries of what is possible with legitimate infrastructure, the focus must shift toward more granular, behavior-based detection that can distinguish between a legitimate video call and a covert C2 tunnel.