If you manage Microsoft Teams, security incidents are probably not your main concern. You deal with call quality, room systems, auto-attendants, licensing, and the occasional user who cannot find the mute button. That is fair. But a recent attack campaign is worth understanding, because it directly involves Teams infrastructure, and the controls to reduce the risk sit partly in your hands.
What happened
In June 2026, security researchers at Symantec published an analysis of a piece of malware called Backdoor.Turn, used by the DragonForce ransomware group against a large services organisation.
The attackers stayed inside that organisation’s network for nearly two months. During the entire time, the network team saw nothing obviously suspicious. What they saw was outbound traffic to legitimate Microsoft servers.
The malware was hiding its communications inside Microsoft Teams relay infrastructure.
What Teams TURN relays are, and why they matter here
When a Teams call or meeting cannot connect two participants directly (because of firewalls, NAT, or corporate network configurations), Teams uses a relay server to forward the traffic between them. This is called a TURN relay, and it is a completely normal, documented part of how Teams works.
Microsoft publishes the ports and IP ranges Teams uses for media traffic. Most network teams allow this traffic by design, often without deep inspection, because blocking it would break calls and meetings.
Backdoor.Turn abused exactly this mechanism.
The malware obtained an anonymous visitor token (the same type used when a guest joins a Teams meeting without a corporate account) and used it to authenticate against Teams infrastructure. It then established a connection through a legitimate Microsoft TURN relay, and tunnelled its communications to the attacker’s server through that channel.
From the outside, it looked like Teams traffic. Because, technically, it was.
This is not a Teams vulnerability
It is important to be clear about this. Microsoft Teams was not hacked. There is no patch to apply to Teams to fix this. The malware did not exploit a flaw in the product.
What it did was use legitimate Teams features (anonymous visitor tokens and TURN relays) for a purpose they were not designed for. The destination was genuine Microsoft infrastructure. The reputation was good. The traffic looked normal.
That is precisely what made it difficult to detect.
What you can do as a Teams administrator
You cannot stop this entirely on your own. Detection of this kind of threat requires endpoint security tools, security operations, and correlation across multiple data sources. But there are meaningful steps that reduce the attack surface.
There are important details to note:
- If you have network segmentation or firewall rules by device type or network zone, servers should not be allowed to reach Teams media endpoints at all. Review whether your current firewall rules differentiate between workstations and servers.
- Review your Microsoft 365 network exceptions. Many organisations have broad “allow all traffic to Microsoft 365 IPs” rules, sometimes applied at the perimeter without deep inspection. These rules make sense for workstations using Teams for calls. They do not make sense for servers, data centers, or any host that has no reason to initiate media sessions.
- Audit where the Teams client is installed. If Teams is deployed only to end-user workstations, make sure that is enforced through Intune compliance policies or application control.
- Monitor for anonymous guest token requests from unexpected sources. Anonymous visitor tokens are obtained through Microsoft identity infrastructure. If your environment has Conditional Access policies scoped to known devices and compliant endpoints, unenrolled or unmanaged devices requesting Teams guest access tokens would violate those policies. Conditional Access with device compliance requirements reduces the pool of machines that can silently obtain these tokens.
- Coordinate with whoever manages your firewall and endpoint security. The detection of this specific threat relies on correlating which process is generating network traffic and whether that process has any legitimate reason to do so.
The underlying shift in thinking
Blocking a malicious domain used to be a reasonable defense. If malware called home to a suspicious server, you blocked the domain and the communication stopped.
That model is increasingly insufficient. Attackers are learning to use infrastructure that organisations already trust and already allow. Microsoft 365, cloud storage services, and communication platforms all have legitimate outbound traffic patterns that most environments permit.
The question is no longer only “where is the traffic going?” It is also: which process generated it, from which machine, and does that make sense?
As a Teams administrator, you may not own the endpoint security tooling. But you are in a position to define what normal Teams usage looks like in your organisation, to help scope network exceptions correctly, and to flag when Teams infrastructure is present on machines where it has no reason to be.
That is a meaningful contribution to reducing the risk.
I hope this helps frame where your role fits in this kind of threat, and what practical steps are worth raising with your security team.
