On June 16, 2026, a DragonForce ransomware case turned Microsoft Teams relay infrastructure into the hiding place for malware traffic, making trusted collaboration plumbing part of the detection problem.
The technique, reported by BleepingComputer, used custom Go-based malware called Backdoor.Turn to mask command-and-control traffic through Teams-related relay paths. The timing matters because the observed attack began in December 2025, after researchers had already shown in 2025 that conferencing relay systems could be abused for stealthy tunnels.
June 16 disclosure: DragonForce Microsoft Teams relay abuse turns trusted traffic into cover
The core issue is not that Microsoft Teams is ransomware. It is that DragonForce found a way to make malware communication blend into infrastructure many companies already permit.
Backdoor.Turn abuses Traversal Using Relays around NAT, or TURN, a protocol Teams uses when a direct connection to a client is not available, such as when clients sit behind private networks. In normal use, relay infrastructure helps real-time communications connect when networks get in the way. In this case, the backdoor used that trusted route as camouflage.
That changes the defender’s problem. A crude implant phoning home to an unfamiliar server can trigger obvious questions. A compromised machine reaching Microsoft-linked infrastructure is harder to challenge, especially in a company where Teams is part of daily work.
“Backdoor.Turn, a Go-based RAT, is the first known malware to abuse Microsoft Teams' TURN relay servers to mask command-and-control traffic,” Symantec says.
The useful takeaway is narrow but serious: security teams can’t treat trusted collaboration services as automatic safe zones. They need enough visibility to separate real employee activity from malware using the same broad lanes.
December 2025 intrusion: Backdoor.Turn hid C2 behind Microsoft Teams relays
The DragonForce attack Symantec analyzed hit a major U.S. services company and began in December 2025. Researchers said the initial access likely came through exploitation of an unknown flaw in an SQL or MSSQL server, though the exact vulnerability is not known.
Once inside, the attackers downloaded a ZIP archive containing a legitimate VirtualBox/DbgView executable and a malicious DLL used for sideloading. They then strengthened persistence, created rogue users, changed the LimitBlankPassword Windows security policy, and modified firewall rules.
Backdoor.Turn came later. According to the source material, the malware was injected into DbgView64.exe after the ransomware was deployed, suggesting it may have been used for persistence or future access.
At a high level, command-and-control means the infected system can receive instructions from the attacker. That can support reconnaissance, lateral movement, data theft preparation, and follow-on access. Backdoor.Turn’s reported capabilities included:
- Command execution: Running attacker instructions on compromised systems.
- Process creation: Launching additional tools or payloads.
- Network scanning: Mapping reachable systems and services.
- LDAP/Active Directory searching: Finding domain structure and targets.
- Browser credential theft: Stealing saved credentials from endpoints.
- TLS certificate and website title collection: Gathering reconnaissance data.
This is why the DragonForce Microsoft Teams relays tactic matters. It gives the attacker a quieter channel after the loudest stage of the attack.
The trust gap: why Teams relay paths are useful camouflage
Teams relay infrastructure is attractive because it sits inside a category defenders are reluctant to block. If a company depends on Teams, blunt network blocking can break work. Loose allowlists, though, can create blind spots.
The DragonForce case shows how that trust can be exploited. Backdoor.Turn obtained an anonymous Teams visitor token, used a legitimate Microsoft TURN relay during connection setup, and then connected to the attacker’s command-and-control server. To defenders watching only destinations, the traffic could appear tied to Microsoft Teams infrastructure.
| Normal Teams-related traffic | Backdoor.Turn abuse pattern |
|---|---|
| Supports collaboration when direct connections fail | Uses relay setup to help conceal malware communications |
| Often treated as trusted enterprise traffic | Blends C2 activity into Microsoft-linked paths |
| Expected from Teams users and approved devices | Suspicious if initiated by unexpected processes or servers |
| Blocking may disrupt business operations | Over-trusting can hide attacker persistence |
This is the same operational lesson behind many modern intrusion stories: the initial malware matters, but the hiding place matters more. For adjacent XOOMAR coverage on malware delivery and endpoint abuse, see USB Crypto Malware Weaponizes Windows Shortcut Files and Paid ShapedPlugin Updates Smuggle Malware Into WordPress.
Inside the services-company attack chain after the initial SQL foothold
The concrete case is more useful than a hypothetical one. In the observed intrusion, the attackers first gained access, likely through an unknown SQL or MSSQL issue. They then used DLL sideloading with a legitimate executable, adjusted system access, and prepared the environment for deeper control.
The next phase was defense evasion. Symantec reported use of Bring Your Own Vulnerable Driver, or BYOVD, where attackers abuse vulnerable signed drivers to gain kernel-level privileges and terminate security tools. The drivers named in the source include:
- Huawei HWAuidoOs2Ec.sys, described as “Havoc Process Terminator”
- Topaz Antifraud wsftprm.sys, tracked as CVE-2023-52271
- Tower of Fantasy GameDriverx64.sys, tracked as CVE-2025-61155
- K7 Security K7RKScan.sys, tracked as CVE-2025-1055
The attackers also used ABYSSWORKER, a custom malicious driver masquerading as a legitimate Palo Alto driver. After reconnaissance and evasion, they exfiltrated data, deployed DragonForce ransomware, and encrypted systems.
For defenders, the first clue may not be a scary domain. It may be a mismatch: Teams-like relay traffic from a machine that does not normally generate it, a non-Teams process initiating those connections, odd timing, unusual volumes, or command execution activity near suspicious network sessions.
Detection without breaking Teams: pair process context with relay telemetry
Blocking Teams for everyone is not a serious plan. The better answer is context.
Security teams should avoid trusting destination reputation alone. In this case, the destination may look legitimate because the traffic touches Microsoft-linked infrastructure. That means defenders need to combine network telemetry with endpoint data, identity logs, and behavior.
Practical detection ideas grounded in this case include:
- Process context: Check which process initiates Teams-related relay traffic. Backdoor.Turn was injected into DbgView64.exe, not described as normal Teams client behavior.
- Server activity: Investigate unexpected relay traffic from servers, especially systems that should not be participating in user collaboration flows.
- Command execution: Correlate suspicious outbound sessions with process creation, rogue user creation, firewall changes, and policy changes.
- Driver abuse: Hunt for vulnerable or suspicious drivers tied to attempts to terminate security tools.
- Persistence changes: Watch for user and group additions, LimitBlankPassword changes, and firewall rule modifications.
Basic controls still count. Patch exposed services. Reduce phishing and credential risk with multifactor authentication. Limit privileges. Test backups. Isolate compromised hosts quickly. None of that solves Teams relay abuse by itself, but it narrows the time attackers have to turn stealth into encryption.
The next decision point: trusted cloud paths need inspection, not blind faith
The DragonForce case points to a sharper future for ransomware defense. Crews are investing in stealth before encryption because the most damaging attacks need time: time to map networks, disable tools, steal data, and decide when to detonate ransomware.
Backdoor.Turn is important because it pushed that stealth into a trusted collaboration path. Symantec called the campaign “exceptionally sophisticated cyber tradecraft,” and the details support that judgment: custom malware, Teams TURN relay abuse, DLL sideloading, BYOVD tactics, malicious driver use, data exfiltration, and ransomware deployment in one chain.
The practical implication is clear. Companies can’t simply ban collaboration platforms. They need to inspect trusted services with the same seriousness they apply to unknown traffic, while preserving normal operations.
The next watch item is whether defenders can build reliable behavioral rules around Microsoft Teams relay abuse before this technique spreads beyond a first known in-the-wild case. Trusted cloud services should be treated as high-value attack surfaces, not permanent safe zones.
Impact Analysis
- DragonForce showed that trusted collaboration infrastructure can be abused to hide ransomware communications.
- Security teams may need deeper visibility into Microsoft Teams-related relay traffic instead of treating it as automatically safe.
- The case highlights how attackers are adapting known conferencing relay abuse techniques into real ransomware operations.
Originally published on XOOMAR. For more news and analysis, visit XOOMAR.
