What the DragonForce Attack Against Teams Is All About

Not a Teams Vulnerability – a Trust Problem Disguised in Normal Network Traffic

A recent report describing how the DragonForce ransomware group hid command‑and‑control (C2) traffic inside Teams infrastructure has triggered predictable headlines. The suggestion that a backdoor exists in Teams appeals to those who like to search for software flaws. However, in this case, the suggestion is inaccurate.

No vulnerability exists in Teams. No patch is required. Nothing except our concept of how networks function is “broken.” But the incident matters because everything worked as designed.

DragonForce Uses Backdoor.Turn

According to threat intelligence published in June 2026, DragonForce deployed a custom backdoor known as Backdoor.Turn inside a compromised network belonging to a “major U.S. services company.” Instead of connecting directly to attacker‑controlled infrastructure, the malware routed its communication through Microsoft Teams relay servers.

Teams uses TURN relays to handle media traffic when direct peer‑to‑peer connections are not possible. This is a normal, documented component of the service. Attackers leveraged this infrastructure to tunnel their traffic so that, from a defender’s perspective, all outbound connections appeared to be legitimate Teams activity. In effect, the malware disguised itself as routine collaboration traffic.

The result was predictable: monitoring systems detected nothing suspicious because the destination was Microsoft, the protocols were expected, and the behaviour aligned with normal usage patterns.

The Hype Takes Over

Security researchers naturally look for exploitable flaws and report the flaws that they find, even if the flaw turns out to live up to the hype in the real world (like this other Teams example). In this case, it is important to emphasize that Teams was not compromised, and the attackers did not exploit a vulnerability. Teams behaved as designed. The attackers simply used legitimate features—anonymous visitor tokens and relay infrastructure—to hide their activity.

More importantly, the attackers were already inside the network and had persistence and control long before they piggybacked on the Teams traffic. Security.com speculates that the attackers first gained access to the network via an exploited system (such as SQL Server) or that they “purchased access via an access broker.” When attackers play across your network, all sorts of bad things can happen. It seems like the attackers gained access in December 2025, downloaded some code, and promptly started to investigate how they could exploit the infrastructure.

Although reports don’t specify the exact architecture of the victim environment, the likely exploitation of SQL Server and subsequent domain-level activity suggests a hybrid enterprise environment with both some on-premises components and Microsoft 365. Given the long-standing attractiveness of Active Directory to attackers, it is reasonable to suspect that directory services may have been involved. The involvement of Active Directory is unconfirmed, but the signs are there.

The Attack Challenges Traditional Security Assumptions

Although Security.com notes that the attack exhibited “exceptionally sophisticated cyber tradecraft,” its significance is not technical complexity, but what the attack reveals about modern enterprise security assumptions. Most Microsoft 365 tenants treat the traffic from workloads like Teams as inherently trustworthy. Firewalls and proxies routinely allow outbound connections to Microsoft endpoints with minimal inspection because blocking them would disrupt business operations. DragonForce exploited that trust model.

The backdoor did not need to evade detection through obfuscation or domain reputation tricks. Instead, it blended its instructions into traffic the organization was set up to allow. From the network’s perspective, no obvious problems existed. This is the real shift: trusted SaaS platforms are now part of the attack surface, not just the defensive boundary.

What Actually Failed

Teams did not fail. The security model around it did. The gaps in this case are familiar:

• Initial compromise went undetected.
• Malware executed without being blocked.
• Endpoint behaviour was not sufficiently monitored.
• Trusted outbound traffic was not questioned.

By the time network traffic analysis might have helped, it was already too late.

However, the most important question is how the initial penetration happened. Was a compromise of an on-premises server at the heart? Did the attackers get lucky and find an administrator account that wasn’t protected with multifactor authentication? Finding and addressing the initial penetration is the highest priority.

Detection: Where to Look

This class of attack cannot be reliably detected by network inspection alone. The destination is Microsoft, the traffic is encrypted, and the usage patterns are normal. Detection must move closer to the endpoint.

The indicators that matter include:

• Processes not associated with Teams or other well-known Microsoft 365 processes initiating connections to Teams infrastructure.
• Suspicious parent‑child process relationships (e.g., DLL sideloading scenarios).
• Loading of unusual or vulnerable kernel drivers.
• Long‑lived outbound connections from non‑standard processes.

There’s no catch-all setting in the Teams admin center to block traffic that might be exploited by an attacker who’s already penetrated a network. Microsoft Defender for Endpoint is probably the best way to gain visibility into the kind of signals listed above. For example, a simple KQL query can highlight traffic where the initiating process is not in an expected list:

DeviceNetworkEvents
| where RemoteUrl contains "teams.microsoft.com"
   or RemoteUrl contains "skype.com"
| where InitiatingProcessFileName !in~ ("Teams.exe", "msedge.exe")

This is not a solution. It is a starting point to show what can be done using existing tools to validate that everything is working as expected.

The point is that security analysts need to correlate different signals together to form a view whether the signs indicate some form of compromise or are simply the normal activities seen inside a Microsoft 365 environment.

The Problem is for Networks, Not Teams

The DragonForce attack is not a story about a hidden Teams backdoor that poses systematic threat to Microsoft 365 tenants. It is a demonstration of how effective modern attackers can be when they have compromised an organization and are able to operate inside an environment that implicitly trusts its own tools.

If an attacker can make their traffic look like Microsoft 365 workloads, traditional controls cannot detect or stop them.

The problem is not Teams. The problem is always assuming that trusted traffic is safe.