Talking Through the Walls: How DragonForce Ransomware Hides C2 Inside Microsoft Teams Infrastructure

The Innovation

DragonForce, the ransomware operation that has rapidly scaled through 2026, has introduced something genuinely new to the threat landscape: a custom Go-based remote access trojan called Backdoor.Turn — the first malware that uses Microsoft Teams TURN (Traversal Using Relays around NAT) relay servers as its command-and-control channel.

TURN relays are the infrastructure that carries legitimate Microsoft Teams video and audio calls. When two Teams users connect for a video meeting, the media traffic — the actual audio and video streams — routes through Microsoft’s globally distributed TURN relay servers. These are not edge cases or obscure services. They are the backbone of real-time communication for hundreds of millions of users worldwide.

Backdoor.Turn exploits this infrastructure by obtaining anonymous visitor tokens through Skype identity services — a legitimate authentication path that Microsoft provides so guest users can join Teams calls without a full organizational account. With these tokens in hand, the RAT establishes a TURN relay session and tunnels a QUIC connection through it back to the attacker’s actual C2 server. To any network monitoring tool inspecting the traffic, the C2 session is largely indistinguishable from legitimate Teams media traffic.

This is architecturally novel in a way that previous C2 innovations were not. Threat actors have used legitimate services for C2 before — Slack, Discord, Telegram, cloud storage APIs — but those channels were detectable because the traffic patterns differed from normal usage. A binary pulling commands from a Slack webhook every 30 seconds does not look like a human using Slack. A RAT uploading exfiltrated data to a Google Drive folder does not match typical user file-sync behavior. Network security tools could flag these anomalies because the protocol usage was correct but the behavior was wrong.

Backdoor.Turn eliminates that gap. The TURN relay protocol is designed to carry opaque media streams. The volume, timing, and packet characteristics of a C2 session match a legitimate media call because they use the same protocol in the same way. The traffic flows to Microsoft-owned IP ranges. The destination is trusted. The protocol is expected. The pattern is normal. The C2 is hiding inside the organization’s own collaboration infrastructure.

The Attack Chain

The DragonForce kill chain that leads to Backdoor.Turn deployment follows a four-stage sequence. Each stage uses known, documented techniques. Nothing in the attack chain is novel except the C2 channel itself — and that is precisely the point. Every stage generates alerts in a reasonably instrumented environment.

• Stage 1 — Initial access: SQL and MSSQL exploitation against internet-facing database servers. DragonForce targets exposed database instances with known vulnerabilities, gaining code execution on the database host. This is a well-understood attack surface that database monitoring tools are designed to detect.
• Stage 2 — Defense evasion: BYOVD (Bring Your Own Vulnerable Driver) using a vulnerable signed driver to disable endpoint protection. The attacker loads a legitimately signed but vulnerable driver, exploits it to gain kernel-level access, and uses that access to kill or blind EDR agents on the compromised host. The driver is signed, so it passes standard code-signing validation — but the load of an unusual driver and subsequent endpoint protection failure are both detectable events.
• Stage 3 — Lateral movement: Standard administrative tools and legitimate credentials. Once endpoint protection is disabled and credentials are harvested, the operators move laterally using the same tools any IT administrator would use. RDP, SMB, WMI, PsExec — all generating network and identity telemetry that anomaly detection can surface.
• Stage 4 — C2 establishment: Backdoor.Turn deployment and Teams TURN relay channel activation. The RAT is deployed on one or more hosts, obtains its anonymous visitor tokens, and begins communicating through Teams media relay infrastructure. From this point forward, the operators have a persistent, effectively invisible command-and-control channel.

Why the C2 Channel Passes Inspection

The effectiveness of Backdoor.Turn’s C2 channel rests on a stack of architectural advantages that compound to make detection through conventional network monitoring effectively impossible.

Microsoft Teams TURN relay traffic uses standard STUN/TURN protocols on expected ports. These are the same protocols, on the same ports, that every legitimate Teams call in the organization uses. There is no protocol anomaly to flag. The traffic flows to Microsoft-owned IP ranges — IP blocks that are universally allowlisted in enterprise environments because blocking them would break Teams, Outlook, SharePoint, and the rest of the Microsoft 365 ecosystem. No network security team is going to blocklist Microsoft’s media relay infrastructure.

The volume and timing patterns match legitimate media sessions. A TURN relay session carrying C2 commands looks, at the packet level, like a TURN relay session carrying video. The anonymous visitor tokens that Backdoor.Turn uses to authenticate are a legitimate Teams feature — guest users join Teams calls this way every day in every organization that allows external collaboration. There is nothing anomalous about a new visitor token appearing on the network.

Network security tools that flag C2 based on destination reputation see a trusted Microsoft IP. Tools that flag based on protocol anomaly see standard STUN/TURN. Tools that flag based on traffic pattern analysis see what looks like a media session. Every layer of network-based C2 detection fails simultaneously — not because the tools are broken, but because the C2 traffic genuinely is what it appears to be at the network layer: a Teams media relay session.

The Structural Problem

Here is where the DragonForce kill chain becomes a SOC problem rather than a detection engineering problem.

The SQL exploitation fires a database alert. The BYOVD fires an endpoint alert. The lateral movement fires a network and identity alert. The C2 traffic looks normal. These alerts arrive in different queues, evaluated by different analysts (or different automation rules), at different times. In a SOC processing thousands of alerts daily, no single analyst sees all four signals.

No single alert is urgent enough to escalate on its own. The SQL exploitation alert gets triaged as a vulnerability finding — patch the database, move on. The BYOVD driver load is suspicious but the driver is signed. The lateral movement looks like admin activity within policy. Each alert, evaluated in isolation, has a reasonable benign explanation. Each gets closed or deprioritized.

The connection between an endpoint protection bypass on Day 1 and an identity anomaly on Day 3 and unusual credential patterns on Day 5 requires investigation that spans days and crosses telemetry boundaries. It requires an analyst — or a system — that asks: “Is the host where the BYOVD alert fired the same host where the SQL exploitation was reported three days ago? And is the account now moving laterally the same account that was active on that host?” In a high-volume alert environment, that question almost never gets asked. The alerts are already closed.

What Cross-Telemetry Correlation Catches

The DragonForce kill chain is not invisible. It is uninvestigated. A system capable of correlating across telemetry boundaries and across time would surface the attack at multiple points:

• Connecting the SQL exploitation alert with subsequent endpoint protection tampering on the same host. These two events, hours or days apart, are individually low-severity. Together, they describe an attacker who gained code execution on a database server and immediately moved to disable defenses — a classic post-exploitation sequence.
• Linking the BYOVD alert to lateral movement originating from the compromised host. If the host where endpoint protection was disabled is the same host that subsequently initiates RDP or SMB sessions to other systems, the lateral movement is no longer “admin activity.” It is an attacker pivoting from a compromised position.
• Correlating new identity tokens with media relay sessions that don’t match any user-initiated Teams activity. Anonymous visitor tokens that appear on a host where no user opened Teams, or that coincide with no calendar event or meeting invitation, are signal. They are not signal that network monitoring can surface on its own — but cross-referenced against endpoint and identity telemetry, they become a strong C2 indicator.
• Threading all of these into a single investigation that reveals the full attack chain before the C2 channel is established or shortly after. The key is that none of these correlations require exotic detection logic. They require tracking activity across endpoint, identity, and network telemetry over days — not triaging each alert in isolation.

Closing the Gap

This is the problem Intruex was built to solve.

AI agents investigate every alert by automatically correlating activity across endpoint, identity, and network telemetry sources — not just in the moment the alert fires, but over days and weeks of historical context. The quiet signals that DragonForce depends on SOCs evaluating in isolation get connected into a coherent attack narrative.

When the SQL exploitation alert fires, the investigation doesn’t stop at “patch the database.” It automatically checks for subsequent endpoint anomalies on the same host. It looks for identity changes — new accounts, new tokens, new authentication patterns — originating from that host. It examines network behavior shifts: new destinations, new protocols, new session patterns. It does this across the full environment, across the full telemetry surface, across the full time window.

When the BYOVD alert fires on the same host two days later, the investigation already has context. The alert is not triaged in isolation — it is triaged in the context of a host that was the target of a SQL exploitation attempt 48 hours prior. The severity escalation is automatic because the correlation is automatic.

No alert gets closed in 90 seconds with zero context. Every alert is investigated with the full weight of cross-telemetry correlation, historical enrichment, and behavioral analysis — the same investigation that a senior analyst would perform if they had unlimited time, unlimited access to every data source, and unlimited ability to remember what happened on every host last week.

Source: Symantec Threat Hunter Team analysis, June 2026