We have spent years telling organizations that perimeter security is no longer enough—that the threat is living inside the house, not just knocking at the door. And yet, there is something remarkably unsettling about seeing the infrastructure we use to get our actual work done turned into the very mechanism that dismantles it.
The security industry often obsesses over the "newest" threat, the latest zero-day that makes the news cycle spin. But what the recent operations by the DragonForce ransomware gang demonstrate is far more pragmatic, and ultimately more dangerous: they are not hacking a firewall; they are exploiting the inherent trust we afford our collaboration tools.
When your organization's security posture is predicated on the idea that communication with Microsoft Teams is inherently 'trusted' traffic, you are effectively providing a free pass for a sophisticated attacker. DragonForce recognizes this. They are not breaking through the wall; they are walking through the front door, wearing the company badge, and using the company intranet to move data out and instructions in, all without triggering a single high-fidelity alert in a typical Security Operations Center (SOC). This is not just a tactical shift for DragonForce; it is a fundamental challenge to the way we have architected our enterprise security. We are at a point where the tools designed to connect the workforce are being weaponized to isolate, extort, and dismantle it.
DragonForce: A Pragmatic Pivot in Ransomware TTPs
DragonForce is not a new face in the ransomware ecosystem, but their recent activities show a pronounced maturity in their techniques. Historically, many ransomware operations relied heavily on brute-forcing Remote Desktop Protocol (RDP) or exploiting known vulnerabilities in edge devices. Those methods worked, sure, but they were noisy. They generated logs, they were easily blocked by savvy perimeter defenses, and they required constant innovation as security teams patched their edge devices.
The shift we are seeing in DragonForce is tactical. This reflects a broader trend among sophisticated threat groups, like the recent delivery campaigns linked to Vice Society, of pivoting towards stealthier, trust-exploiting vectors. They have moved toward what we call Living-off-the-Land (LOTL) tactics, but on a more granular level. They aren't just using local admin tools; they are using service-level, infrastructure-level trust. By targeting Microsoft Teams, the gang is exploiting a platform that is ubiquitous, essential, and, crucially, difficult to restrict.
Most organizations operate on a "permissive-by-default" model for Teams traffic. It is necessary for operations; it is how businesses survive in a distributed, post-pandemic world. DragonForce understands that if they can route their malicious traffic—their command-and-control (C2) operations—through these established pipes, they essentially vanish into the background noise. This is the hallmark of a group that has moved past the 'smash-and-grab' phase of ransomware and into the 'long-persistence, high-impact' phase. They are not looking for the easiest way in; they are looking for the hardest way to detect while they are already in. The ease with which they seem to integrate into the Teams environment—and the challenge for defenders in trying to decouple 'malicious' Teams traffic from 'legitimate' Teams traffic—is a testament to how effectively they've mapped out modern corporate workflows. It's a calculated move. They aren't interested in a quick, messy breach; they want sustained, stealthy control.
The Technical Pivot: Understanding Backdoor.Turn
The linchpin of this entire operation is a custom piece of malware that researchers have dubbed 'Backdoor.Turn'. To understand the gravity of this, one must look past the name and understand the function. 'Backdoor.Turn' isn't just a generic remote access trojan (RAT). It was purpose-built to interact with a specific protocol: Traversal Using Relays around NAT (TURN).
For those who do not live in the depths of network engineering, NAT (Network Address Translation) is the reason we do not have to give every single computer in an office its own unique public IP address. It is convenient, but it hides devices. If Device A inside your network wants to talk to Device B, which is outside, NAT can get in the way. TURN is the protocol engineered to solve this; it provides a relay server that facilitates communication when a direct, peer-to-peer connection isn't possible.
'Backdoor.Turn' does not simply use an existing Teams client to communicate. It interfaces with the Teams relay infrastructure directly, tunneling its command-and-control traffic through those same relay channels. These relay channels are designed to appear indistinguishable from the myriad of legitimate audio, video, and data packets constantly flowing through an organization's Teams implementation.
From the malware’s perspective, the Microsoft relay server is not a target to be compromised, but an asset to be leveraged. By talking to the relay, the malware establishes a stable, low-latency communication path to the attacker's server, all while appearing to be perfectly legitimate Teams traffic. The payload is not the malware itself; the payload is the abuse of the protocol's architecture. It is an incredibly elegant, and frankly distressing, exploitation of trust. They have effectively turned the protocol's own design efficiency against the enterprise network. If the relay server permits the traffic, and the endpoint trusts the protocol, the security perimeter effectively ceases to exist.
The SOC Dilemma: Detection and Security Challenges
Let’s be honest about the state of the SOC right now. Most enterprise monitoring relies on identifying malicious intent through abnormal traffic patterns, suspicious domains, or unusual volumes of data transfer. However, when the malicious traffic is intentionally engineered to blend into the most common communication channel in the organization, the traditional detection models begin to falter.
The fundamental challenge for defenders is the 'legitimacy trap' of Teams relayed traffic. How do you distinguish between a massive video conferencing meeting, which inherently involves TURN relay connections, and 'Backdoor.Turn' traffic? If you try to aggressively block or limit TURN connections, you risk killing your organization’s ability to conduct video calls, share screens, or use the very collaboration tool that the business depends on.
This is the rock and the hard place that DragonForce has forced security analysts into. Furthermore, the endpoint activity that 'Backdoor.Turn' generates is often tied to the legitimate Teams process or its integrated tools, which means an EDR (Endpoint Detection and Response) might see the activity but incorrectly classify it as benign because it's associated with a known, trusted binary.
We are forced to peel back layers of traffic that were never designed to be inspected this way. It requires us to move away from signatures and toward behavioral analytics at a scale that is exceptionally difficult to maintain. We need to look for anomalous TURN protocol patterns, but do we even have a baseline for what a 'normal' TURN pattern looks like in our own environment? For most, the answer is no. We do not monitor it because we’ve historically categorized TURN as infrastructure, not a risk factor. We need to change that, but the operational cost of the required deeper, more granular traffic inspection is substantial, both technically and in terms of the strain it places on our already over-burdened analysis teams. It is a slow, difficult, and constant-vigilance type of security—a major departure from the automated alert-response workflows we've been trying to build.
Mitigation Strategies and The Long Road Ahead
So, where does this leave us? We aren't going to stop using Microsoft Teams, and we aren't going to stop using TURN, because we can't operate a modern business without them. That means the mitigation has to be smarter, not just 'harder'.
First, we need to treat Teams relay traffic the way we treat any untrusted path across our perimeter. Does that mean blocking it? No. It means visibility. Security teams need to baseline the TURN traffic within their environment. What are the common relay endpoints? What does the volume of traffic look like? If an endpoint suddenly starts generating significant TURN traffic that doesn't correlate with active user conferencing, that's your alert.
Second, egress filtering needs to be more granular. It shouldn't just be about 'is the destination a known malicious blocklist?'; it needs to be about 'is this endpoint authorized to initiate relay connections to this specific infrastructure?'. Stricter controls on Teams' integrated tools are needed. Are endpoint users executing Teams components that have unnecessary network privileges? We often grant wide network access to the entire Office/Teams suite during deployment, and then forget to tighten it.
Finally, enhanced logging is not a luxury. We need to focus on the endpoint behavior. Even if the traffic looks right, the process that initiated that traffic might have other clues. Is the Teams executable behaving normally, or is it interacting with other system processes in a way that’s atypical?
This exploit is a reminder that we are entering a new phase of the battle—a phase where the attacker’s most potent weapon is not a new exploit, but the exploitation of the very infrastructure we rely on to do our jobs. We have to stop viewing the building blocks of modern collaboration as inherently secure. They are tools, they are relays, they are pathways. And to an attacker, a pathway is simply a means to an end. Our challenge is to make that path as difficult, as narrow, and as observable as possible. We cannot stop the communication, but we can no longer afford to be blind to the tunnels being built within it. The path is long, but it’s the only way forward.