DragonForce Microsoft Teams relay malware became a same-day enterprise security story on June 16, 2026, when BleepingComputer reported that DragonForce operators used a custom backdoor called Backdoor.Turn to hide command-and-control traffic inside legitimate Microsoft Teams relay infrastructure. That is not just an interesting malware trick. It changes how defenders should think about trusted collaboration traffic, because activity that looks like ordinary Teams connectivity can now conceal ransomware persistence and post-compromise access.

For security teams, the timing matters as much as the technique. This is fresh public reporting, not an old incident being recycled through a CVE update or a vendor patch note. It is also a useful warning that the next ransomware blind spot may not be a shady domain or an obvious outbound beacon. It may be traffic your environment already allows by default.

Key Stat: Symantec said the attackers stayed on the victim network for between one and two months while masking command-and-control traffic through Microsoft Teams relay infrastructure.

Why DragonForce Microsoft Teams relay malware matters right now

The main freshness hook for this post is BleepingComputer's June 16, 2026 report, backed by the same-day Symantec write-up, on a real DragonForce intrusion against a major U.S. services company. That date is what makes this a publishable story today. Older background details about DragonForce, TURN relays, or vulnerable drivers are only supporting context.

What makes the story strong is not simply that DragonForce used custom malware. Ransomware crews constantly rotate tooling. The bigger issue is that the attackers turned trusted collaboration infrastructure into a stealth layer. That is a more important operational shift than another commodity loader or another recycled remote access trojan.

This also gives defenders a cleaner lesson than a generic exploited-vulnerability headline. Many recent security stories have focused on patch urgency, AI misuse, or data theft through browser-based trust. This case is different. It shows how attackers can hide inside software and network paths that enterprises are reluctant to block because those paths support routine work.

Key Takeaway: When ransomware command-and-control can blend into sanctioned Teams traffic, reputation-based network trust becomes a weaker security control.

How the DragonForce attack hid inside Microsoft Teams relays

According to BleepingComputer and Symantec's Hidden in Teams report, the custom Backdoor.Turn malware obtained an anonymous Teams visitor token through Microsoft's Skype-backed identity services, used a legitimate Microsoft TURN relay during setup, and then established connectivity to the attacker's real command-and-control server.

The critical point is what defenders saw and did not see.

  • They saw outbound connections tied to legitimate Microsoft Teams infrastructure.
  • They did not see an obviously hostile C2 destination in the normal way.
  • They had much less reason to classify the traffic as suspicious at first glance.

That changes the defensive equation. Many organizations treat collaboration platforms as high-trust services because blocking them breaks communication, meetings, and support workflows. Attackers understand that. If they can push their traffic through those same channels, they inherit a degree of trust they did not earn.

Why the TURN relay detail matters

TURN is normally just a connectivity helper. It exists to make real-time communication work when direct peer-to-peer paths are unavailable. In a normal enterprise setting, that is invisible plumbing.

In this intrusion, that plumbing became cover.

The malware used the relay setup path to make its network behavior resemble legitimate Teams activity. Symantec noted that this is the first known in-the-wild abuse of Microsoft Teams TURN relays for malware command-and-control. That matters because defenders are now dealing with a proven technique, not a conference demo or a theoretical abuse path.

Praetorian's earlier Ghost Calls research showed that web conferencing infrastructure could be bent into covert channels. DragonForce is the more uncomfortable follow-up. The concept has crossed into real operations.

Common Mistake: Treating sanctioned SaaS traffic as inherently low-risk because the domain, certificate, or provider is trusted.

Why this intrusion was more dangerous than a clever tunnel

The Teams relay abuse would be notable on its own. What raises the stakes is everything else happening around it.

Symantec said the attackers likely gained initial access by exploiting an unknown SQL or MSSQL server vulnerability, or by buying that access from a broker. Once inside, they used a mix of persistence, lateral movement, and defense evasion techniques that look much more like a disciplined intrusion set than a smash-and-grab encryption run.

The reported steps included:

  • creating rogue users and groups for resilience
  • modifying firewall rules to preserve remote access
  • abusing DLL sideloading through legitimate executables
  • using BYOVD techniques to terminate security tools
  • deploying ransomware only after reconnaissance and evasion work

That sequence matters because it tells you what the Teams channel was really buying them: time.

If command-and-control traffic can survive inside trusted collaboration flows, attackers get a better chance to stay resident, adjust tooling, and preserve access after the noisy part of the attack. Symantec also noted that Backdoor.Turn was installed after ransomware deployment, which suggests the operators may have wanted persistence for re-entry, follow-on monetization, or access resale.

This is one reason the story should not be filed away as a quirky Teams problem. It is a reminder that ransomware campaigns increasingly behave like blended intrusion operations first and encryption events second.

For readers tracking this broader trend, Hexon's earlier coverage of AI as tradecraft and ServiceNow customer data exposure pointed to the same strategic issue from different angles: attackers succeed when defenders trust the workflow or platform more than they inspect the behavior moving through it.

What defenders should check this week

If your organization relies heavily on Microsoft Teams, the wrong response is to panic and the wrong response is to shrug. The right response is to tighten visibility around trusted traffic that has historically received less scrutiny.

Start with network and telemetry review:

  • baseline Teams relay and media traffic patterns for high-value user groups and servers
  • look for unusual Teams-related outbound activity from systems that should not normally run interactive collaboration clients
  • review QUIC, relay, and identity-service telemetry alongside endpoint events instead of in isolation

Then move to endpoint and identity controls:

  • hunt for signs of rogue user creation, modified firewall rules, and suspicious persistence near collaboration-related processes
  • flag use of legitimate signed tools loading unexpected DLLs
  • prioritize detections for vulnerable driver abuse and abrupt security-process termination

Then review architecture and policy:

  • segment servers so collaboration traffic is not broadly allowed where it has no business purpose
  • tighten egress rules for infrastructure that should never need Teams connectivity
  • validate whether detection logic treats Microsoft-owned network paths as too trusted by default

Three practical questions worth asking

  1. Which systems in your environment can reach Microsoft Teams infrastructure even though they do not need to?
  2. Would your detections correlate unusual Teams-related traffic with privilege escalation, DLL sideloading, or vulnerable driver abuse?
  3. After a ransomware detonation, would you know how to spot a trusted-channel backdoor left behind for later access?

Those questions are more useful than asking only whether DragonForce IOCs are blocked today.

Pro Tip: Build detections around behavior plus context, not provider reputation alone. Trusted Microsoft traffic coming from the wrong host, at the wrong time, next to the wrong endpoint events should stop being treated as routine.

The bigger lesson for ransomware defense

The biggest lesson from DragonForce Microsoft Teams relay malware is that collaboration infrastructure now belongs in the same mental category as identity systems, browsers, and cloud control planes: high-value trust surfaces that attackers can repurpose.

That has two consequences.

First, blue teams need to stop thinking in separate boxes where "messaging traffic," "endpoint malware," and "ransomware operations" are handled as mostly distinct problems. Modern campaigns happily combine them.

Second, defenders need to revisit the old habit of ranking risk by whether traffic points to a known-good provider. Attackers increasingly care less about owning the destination and more about borrowing the defender's trust assumptions.

This is also where the story connects with Hexon's earlier posts on Microsoft 365 Copilot data theft, Microsoft Defender RoguePlanet, and the broader prompt injection defense guide. Those pieces covered different technologies, but they all exposed the same uncomfortable pattern: security teams keep inheriting new blind spots whenever a trusted platform gains more reach than the monitoring strategy around it.

What security leaders should change after this disclosure

The most practical response is not a new "watch Microsoft Teams" memo. It is a better trust model.

Security leaders should treat collaboration infrastructure as a monitored control plane, not just a business utility. That means:

  • defining where Teams connectivity is expected and where it is anomalous
  • correlating relay traffic with identity changes, driver abuse, and signed-binary sideloading
  • including trusted SaaS channels in ransomware tabletop scenarios
  • assuming post-encryption persistence may hide inside normal-looking service paths

There is also a communication challenge here. Teams, Zoom, Slack, and similar platforms are so embedded in modern work that business leaders often hear security concerns about them as usability objections. That framing is too soft. The issue is not that collaboration tools are risky in a vague sense. It is that they are now credible cover channels for adversary operations.

Key Takeaway: The safest enterprise posture is not "block collaboration tools." It is "stop giving collaboration traffic a free pass."

Final takeaway

The reason this June 16 disclosure deserves attention is simple. DragonForce Microsoft Teams relay malware shows that trusted communication infrastructure can now mask ransomware command-and-control in live operations, not just in lab research.

Microsoft Teams is not the real story on its own. The real story is that attackers found another place where enterprise trust and enterprise visibility are out of balance. If a sanctioned service can hide long-dwell access, defense evasion, and post-ransomware persistence, then your detection strategy has to care less about who owns the platform and more about what the traffic is doing.

That is the shift worth making this week. Review where Teams traffic belongs, tighten scrutiny on systems that should never use it, and assume that the next stealth channel may arrive through a provider your network already treats as safe.