Borrowing Trust From Microsoft: Breaking Down the DragonForce Teams Relay Campaign
In late 2025, a DragonForce affiliate operated for one to two months inside a major U.S. services firm. During the intrusion, the attackers deployed Backdoor.Turn, a custom Go-based RAT that Symantec says routed command-and-control traffic through the relay servers Microsoft Teams uses to carry calls. Every outbound connection the defenders could see went to legitimate Microsoft infrastructure, making the traffic look like Teams activity to reputation- and destination-based controls.
Almost every enterprise allows Teams traffic. Tools that flag C2 by reputation or by destination had nothing to flag here, because the destination really was Microsoft. Backdoor.Turn is the first known malware to abuse Teams relay infrastructure this way in the wild.
This post draws on the Symantec and Carbon Black Threat Hunter Team analysis published June 16 2026, Praetorian's Ghost Calls research from August 2025 and contemporaneous reporting from BleepingComputer and Help Net Security. It walks the full intrusion from initial access through ransomware deployment, with the most detail on the command-and-control stage, where the relay-abuse technique breaks assumptions that most detection still rests on.
The Incident
DragonForce has operated since at least June 2023. Symantec attributes its development to a group it tracks as Hackledorb and describes the operation as having moved from a conventional ransomware-as-a-service model to a formalized cartel structure. Affiliates run intrusions on top of DragonForce-supplied tooling, negotiation sites and leak infrastructure.
The victim was a major U.S. services firm, but Symantec doesn’t name it. The attackers were resident on the network for at least a month, which is consistent with a hands-on-keyboard intrusion rather than an automated smash-and-grab.
The Attack Chain
Stage 1: Initial Access
ATT&CK: T1190 Exploit Public-Facing Application, T1133 External Remote Services
Entry was most likely through an unidentified vulnerability in a SQL or MSSQL server. Symantec is explicit that the specific flaw is not known, and notes the alternative that the affiliate purchased access from a broker rather than exploiting the server directly. Either path would land them in the same place: a foothold on an internet-reachable database host.
Stage 2: Execution and Persistence
ATT&CK: T1574.002 DLL Side-Loading, T1136.001 Create Account: Local Account, T1562.004 Disable or Modify System Firewall, T1112 Modify Registry
From the foothold, the attackers pulled down a .zip archive containing a legitimate, signed VirtualBox/DbgView executable alongside a malicious vboxrt.dll built to be side-loaded. Forcing the signed binary to load the malicious DLL gave them code execution under a trusted process and bypassed monitoring keyed to binary reputation. The DLL then reached out to a list of attacker servers to pull additional code.
They dug in with a set of configuration changes: enabling LimitBlankPassword to ease reuse of accounts, creating rogue users, and modifying firewall rules to keep the C2 path open. None of these are exotic, and all are observable.
Stage 3: Defense Evasion via Vulnerable Drivers
ATT&CK: T1068 Exploitation for Privilege Escalation, T1543.003 Windows Service, T1562.001 Disable or Modify Tools
The group leaned on Bring Your Own Vulnerable Driver (BYVOD) to reach the kernel and kill security tooling. This stage mixed two distinct things. Four were genuine BYOVD abuses of legitimate signed drivers: a novel technique against Huawei's HWAuidoOs2Ec.sys that Symantec calls “Havoc Process Terminator,” plus Topaz Antifraud's wsftprm.sys (CVE-2023-52271), Tower of Fantasy's Gamedriverx64.sys (CVE-2025-61155) and K7 Security's K7RKScan.sys (CVE-2025-1055). The Huawei driver had no published vulnerability at the time of the attack. Huntress only documented its vulnerable status in March 2026, months after.
The fifth, ABYSSWORKER, isn’t BYOVD at all. It’s a custom malicious driver built to masquerade as a legitimate Palo Alto Networks driver. ABYSSWORKER is the attacker's own code wearing a trusted name.
Stage 4: Command and Control via Teams TURN Relay
ATT&CK: T1071 Application Layer Protocol, T1572 Protocol Tunneling, T1090 Proxy
This is the stage that makes the campaign notable. Backdoor.Turn is a custom Go-based RAT injected into the legitimate DbgView64.exe process. Rather than beacon to an attacker domain, it abuses the transport Teams itself uses.
The sequence is straightforward. The backdoor first requests an anonymous Teams visitor token from Microsoft's Skype-backed identity services, the same kind of token that lets an unauthenticated guest join a meeting. It uses that token to set up a connection through a legitimate Microsoft TURN relay. TURN (Traversal Using Relays around NAT) is the protocol Teams falls back on to carry media when two endpoints cannot reach each other directly, which is the normal case behind corporate firewalls. With the relay-assisted path established, the malware opens a QUIC session through it to the attacker's real C2 server.
The result is that a network defender sees outbound connections to legitimate Microsoft Teams infrastructure and nothing else. There’s no unfamiliar domain, no unusual port, no self-signed certificate, no beacon to a freshly registered host. The C2 channel inherits the trust the entire organization already extends to Teams.
Symantec credits the design as inspired by Praetorian's Ghost Calls research, presented at Black Hat in August 2025, which demonstrated abusing web-conferencing infrastructure for covert C2. The gap from proof of concept to in-the-wild deployment was roughly four months. This is the first known case of malware abusing TURN relay infrastructure this way.
The order here is interesting. Backdoor.Turn was installed after the ransomware was deployed, not before. That inverts the usual model where a RAT establishes the beachhead and ransomware is the payoff. Symantec reads the late installation as persistence, a path back in for a future intrusion, or access staged for resale. The encryption event wasn’t the end of the attackers' interest in the network.
Stage 5: Reconnaissance, Exfiltration and Ransomware
ATT&CK: T1046 Network Service Discovery, T1087.002 Account Discovery: Domain Account, T1555.003 Credentials from Web Browsers, T1567 Exfiltration Over Web Service, T1486 Data Encrypted for Impact
Backdoor.Turn's feature set covers the rest of the operation: command execution and process creation, network scanning that captures TLS certificate data and web page titles for further mapping, LDAP and Active Directory search for domain reconnaissance, credential-based lateral movement and browser credential theft. After reconnaissance and evasion, the affiliate exfiltrated data and deployed the DragonForce ransomware payload to encrypt the victim's machines, the double-extortion pattern the group is known for.
Where Defenders Had a Window
The internet-facing database server. The exact flaw is unknown, but the entry point was an exposed SQL/MSSQL host. Patch cadence, attack-surface reduction and exploitation monitoring on internet-reachable database servers are the first line, regardless of whether access was exploited or bought.
The side-loaded DLL. A signed VirtualBox/DbgView binary loading an unsigned vboxrt.dll from a writable path is a detectable anomaly. Application allowlisting and monitoring for trusted binaries loading unexpected DLLs would have surfaced this before the downloader ran.
The driver loads. Each BYOVD driver here has a known hash. The Microsoft vulnerable-driver blocklist, hash-based driver monitoring and alerting on new kernel-mode driver loads address the genuine BYOVD cases. ABYSSWORKER, as a custom signed-impersonation driver, needs behavioral detection rather than a blocklist.
The configuration changes. LimitBlankPassword changes, rogue account creation and firewall-rule modifications are loud. These are exactly the events endpoint and identity monitoring are built to catch, and they all preceded encryption.
The C2 itself. This is the hard one. The traffic genuinely went to Microsoft, so reputation, IP blocklists and destination allowlisting all pass it. What does not pass is the behavior: a debugging utility process such as DbgView64.exe initiating Teams-relay sessions has no business doing so. Detection has to move from “where is this going?” to “should this process be doing this at all?”. Symantec published file and network indicators, including the C2 domains and the Backdoor.Turn C2 address, which give defenders concrete hunting material.
Technique in Focus: Living off Trusted Infrastructure
The TURN abuse is one instance of a pattern that keeps recurring: routing C2 through services an organization already trusts so the malicious traffic inherits that trust. Attackers have done versions of this with cloud storage, with content delivery networks, and with legitimate paste and code-hosting sites. Teams relays are significant because the trust is near-universal, and conferencing traffic is encrypted, high-volume and operationally sensitive. Even where inspection is attempted, relay-mediated media infrastructure is difficult terrain for traditional network controls.
The defensive lesson is the one ThreatLocker's Kieran Human put plainly in SC Media's coverage: trust should not rest on the platform carrying the traffic. A destination-based trust model assumes that traffic to Microsoft is safe because Microsoft is safe. This campaign is a clean refutation. The relay was legitimate, the token was legitimate, the transport was legitimate, but the channel was hostile. The only signal left is behavioral, which means the detection burden falls on process-level baselines and egress anomaly analysis rather than on domain or IP reputation.
It’s also reasonable to expect adaptation. The same architecture exists in other conferencing and collaboration platforms, and a Go backdoor is portable. The technique is now public, demonstrated and proven in a real intrusion, which is usually the point at which a one-off becomes a category.
Sources
Hidden in Teams: DragonForce Attackers Weaponize Microsoft Teams Relays to Stay Hidden · Symantec and Carbon Black Threat Hunter Team · June 16 2026 · security.com
Ransomware gang abuses Microsoft Teams relays to hide malicious traffic · Bill Toulas, BleepingComputer · June 2026 · bleepingcomputer.com
Cybercriminals mask malicious communications through Microsoft Teams relays · Help Net Security · June 16 2026 · helpnetsecurity.com
Attackers drop DragonForce ransomware leveraging MS Teams relay systems · SC Media · June 2026 · scworld.com
Ghost Calls: Abusing Web Conferencing for Covert Command & Control · Praetorian · August 2025 · praetorian.com
From W2 Malvertising to Kernel-Mode EDR Kill · Huntress · March 2026 · huntress.com