Hard2bit
← Back to blog

Hidden C2 in Microsoft Teams: how DragonForce abused TURN relays to stay invisible for two months

By Thilina Manana · COO y Director Técnico de Seguridad hard2bit · Published: 23 June 2026 · Updated: 23 June 2026
Drafonforce and backdoor

For nearly two months, the security team at a large services firm saw something that looked entirely normal in its network traffic: outbound connections to legitimate Microsoft Teams infrastructure.

There were no suspicious domains. No newly registered servers. No obviously malicious destination to block.

And yet, inside that apparently legitimate traffic, a ransomware operation was running its command-and-control channel.

On 16 June 2026, threat intelligence teams at Symantec and Carbon Black published their analysis of Backdoor.Turn, a Go-based backdoor linked to DragonForce ransomware activity. The malware was notable not only for what it could do, but for how it hid: by abusing the TURN relay infrastructure Microsoft Teams uses to support real-time communications.

According to Symantec, Backdoor.Turn is the first known malware observed in a real-world attack abusing Microsoft Teams TURN relays to mask command-and-control traffic. That matters because it challenges a comfortable assumption many organisations still make: that traffic to Microsoft infrastructure is, by definition, trusted traffic.

The issue is not that Microsoft Teams was “hacked” as a product. The issue is more uncomfortable: attackers used a legitimate function of a trusted enterprise service to hide in plain sight.

What happened, in order

According to Symantec’s analysis, also reported by The Hacker News and Help Net Security, the attackers remained inside the victim’s network for between one and two months.

During that time, they compromised the environment, performed reconnaissance, moved through internal systems and deployed DragonForce ransomware. Backdoor.Turn was introduced afterwards and injected into a legitimate process: DbgView64.exe, a Sysinternals utility that should not normally be running without a clear operational reason on many production servers.

That order matters.

Backdoor.Turn does not appear to have been the initial access mechanism. It looks more like a post-compromise persistence tool: a way to keep a discreet channel open after the main ransomware impact, return later, sell the access, support further extortion or maintain pressure on the victim.

For defenders, the problem was clear. For weeks, network telemetry did not show an obviously suspicious destination. What they saw were outbound connections to legitimate Microsoft servers.

The intrusion was not hiding despite Teams. It was hiding inside traffic that organisations expect to see when they use Teams.

How it works: TURN, STUN and anonymous visitor tokens

To understand the technique, it helps to look briefly at how real-time communications work.

Services such as Microsoft Teams need to traverse firewalls, NAT and corporate networks so users can hold calls, share screens and join meetings. To support that connectivity, they use mechanisms such as ICE, STUN and TURN.

STUN helps endpoints discover how they can communicate through NAT. TURN acts as a relay when direct communication between endpoints is not possible. In that case, a Microsoft relay server helps forward the media flow between participants. It is a legitimate and necessary part of the service.

Microsoft documents that Teams uses TCP 80/443 and UDP 3478-3481 for media and connectivity flows. As a result, many organisations allow this traffic by design.

Backdoor.Turn turns that legitimate mechanism into a covert channel.

The malware first requests an anonymous visitor token from Skype/Teams-related identity services, similar to the type of credential that allows a guest to join a meeting without a traditional corporate account. With that token, it authenticates against Teams infrastructure and uses a legitimate TURN relay to establish connectivity.

From there, the malware establishes a QUIC session towards the attacker’s real command-and-control server. The result is highly effective from an attacker’s perspective: the true C2 destination does not appear as an obvious direct connection in the victim’s network telemetry. What defenders see is traffic to legitimate Microsoft infrastructure.

The attacker does not need to build a new infrastructure layer to hide. It uses infrastructure the organisation already trusts, already allows and may not inspect with the same suspicion as an unknown external domain.

Why QUIC makes detection harder

QUIC is an encrypted UDP-based transport commonly associated with HTTP/3 and modern low-latency services. In many environments, QUIC is associated with UDP/443, although Microsoft Teams media flows also rely on specific UDP ports such as 3478-3481.

From a defensive perspective, that creates several problems.

Many organisations inspect TLS over TCP more carefully than UDP traffic. Others allow UDP to trusted SaaS providers to avoid breaking critical services. Many also exclude Microsoft 365 destinations from strict inspection to reduce performance, reliability or privacy issues.

Backdoor.Turn takes advantage of that combination: encrypted transport, outbound UDP, legitimate infrastructure and a business-critical application that is widely allowed.

The lesson is not to block Teams or disable QUIC indiscriminately. That can break legitimate business operations. The lesson is that allowing a trusted destination should not mean trusting every behaviour that travels through it.

What Backdoor.Turn can do once inside

Backdoor.Turn is not just a communications channel. Once the tunnel is established, it gives the operator enough capability to continue operating inside the compromised environment.

Reported capabilities include:

  • Remote command execution.
  • Process creation on the compromised host.
  • Active Directory reconnaissance through LDAP queries.
  • Network scanning to discover reachable hosts and services.
  • Credential theft, including browser-stored credentials.
  • Credential-based lateral movement.
  • Persistent outbound communications that can be difficult to distinguish from normal corporate traffic.

In practice, this follows the same pattern seen in many modern intrusions: initial compromise, internal reconnaissance, privilege escalation, identity access, lateral movement, data theft, ransomware deployment and continued access.

The difference is the outbound channel. Instead of calling back to an obviously suspicious server, the malware blends into Microsoft Teams relay traffic.

Why traditional controls may miss it

Many egress filtering models still work primarily by destination: Microsoft domains and ranges are allowed, unknown destinations are monitored, and bad-reputation domains are blocked.

That model breaks down here.

The destination is legitimate. The reputation is good. The service is necessary. The traffic may look compatible with a normal enterprise application.

Traditional TLS inspection does not solve the issue by itself if the observed channel uses QUIC/UDP or if the organisation excludes certain SaaS services from inspection for operational reasons.

There is also no classic CVE-style patch to apply. This is not a case where the attacker exploited a Teams vulnerability to take control of the product. It is an abuse of legitimate functionality: TURN relays, visitor tokens and allowed connectivity to trusted infrastructure.

Defence therefore cannot rely only on domain reputation, allowlists or perimeter inspection. It has to look at behaviour.

Which process generated the connection? From which host? Under which user? At what time? With what volume and duration? What else did that process do on the system? Did it query Active Directory? Did it access credentials? Did it create child processes? Did it move laterally?

That is where EDR, XDR, NDR, SIEM, identity telemetry and threat hunting become essential.

The context: DragonForce and the professionalisation of ransomware

This level of tradecraft fits DragonForce’s recent trajectory.

According to Check Point Research’s Q1 2026 ransomware analysis, DragonForce claimed 101 victims in the first quarter of 2026, a 29% increase over the previous quarter. Its monthly numbers climbed from 10 victims in January to 35 in February and 56 in March.

Beyond the name of the group, the trend matters more: ransomware is no longer just file encryption. It is a criminal business operation involving affiliates, shared infrastructure, data theft, reputational pressure, negotiation, resale of access and techniques that were once associated mainly with more selective threat actors.

In September 2025, DragonForce publicly promoted a cooperation model with other operations, explicitly referencing groups such as LockBit and Qilin. The “cartel” framing should not necessarily be understood as a formal merger. It is better viewed as a branding, affiliate and infrastructure-sharing strategy.

For defenders, the label matters less than the outcome: better-resourced affiliates, more repeatable infrastructure and advanced techniques being reused in financially motivated extortion campaigns.

Operational detection: what to look for

If the network alone is not enough, detection must shift towards endpoint behaviour, identity activity and correlation across telemetry sources.

A reasonable hunting hypothesis would be to look for atypical processes generating sustained UDP traffic towards Microsoft Teams-related infrastructure, especially when those processes have no legitimate relationship with Teams, browsers or unified communications.

It is also important to monitor the execution of Sysinternals tools on servers, especially outside administration workstations or without an approved change. DbgView64.exe, PsExec and similar legitimate tools can be normal in the hands of an administrator, but highly suspicious on a production server or on a host that should not be using them.

Signals worth instrumenting include:

C2 signal table

In Microsoft Defender, Microsoft Sentinel or other XDR/SIEM platforms, the key is to correlate process, network, user, host and identity data. Looking only at the destination may not be enough. Looking at the full behaviour chain can change the outcome.

This is where mature threat hunting⁠, a managed SOC⁠ and EDR/XDR/MDR capability⁠ become critical.

Practical defence: what enterprises should do

There is no single switch that turns this risk off. But there are concrete measures that reduce the likelihood of compromise and, more importantly, reduce attacker dwell time.

1. Govern outbound UDP and QUIC traffic

This does not mean blocking Microsoft Teams indiscriminately. Doing so can affect call quality, meetings and screen sharing.

The better approach is to govern outbound traffic:

  • Allow UDP/QUIC only where needed.
  • Apply different policies for users, servers and administrative workstations.
  • Log source process, user, host and destination.
  • Review broad SaaS exceptions.
  • Detect processes that should not be generating media or QUIC traffic.
  • Segment the network so a compromised host cannot move freely.

Network segmentation⁠ remains a core defence: if an attacker gets an outbound channel, internal movement should still be constrained.

2. Treat legitimate tools as contextual signals

Sysinternals, PowerShell, PsExec, remote administration tools and signed binaries are not malicious by default. But outside the right context, they can be extremely valuable signals.

The question is not simply “is this tool legitimate?”. The right questions are:

  • Should it be running here?
  • Was it launched by an authorised user?
  • Is it appearing on a server where it is never normally used?
  • Does it coincide with unusual network connections?
  • Does it appear before or after LDAP queries, credential access or suspicious process creation?

That mindset is part of a mature security audit⁠ and SOC operating model.

3. Strengthen EDR, XDR and attack surface reduction

An EDR that is installed but poorly tuned, weakly monitored or not backed by 24/7 response delivers less protection than many organisations assume.

For cases like Backdoor.Turn, visibility should cover:

  • Process injection.
  • Suspicious child process creation.
  • Credential access.
  • Reconnaissance behaviour.
  • Administrative tool execution outside normal patterns.
  • Persistence.
  • Unusual outbound connections by process.

A combination of EDR, XDR and MDR⁠ helps transform isolated alerts into a coherent investigation.

4. Monitor identity and Active Directory

Modern ransomware rarely stops at encrypting one machine. It usually seeks to understand the domain, find privileged accounts, move laterally and increase impact.

Security teams should monitor:

  • Unusual LDAP queries.
  • User and group enumeration.
  • Access to domain controllers.
  • Privileged account use outside normal patterns.
  • Kerberoasting, AD CS abuse and hybrid Active Directory attack paths.
  • Lateral movement between servers.

In hybrid environments, organisations should specifically review hybrid Active Directory attack paths⁠ and their identity and Zero Trust posture⁠.

5. Correlate NDR, endpoint and identity

No single telemetry source sees everything.

The network may show connections to Microsoft, but not always whether the originating process is legitimate. The endpoint may show processes and credential access, but not always global communication patterns. Identity logs may show unusual access, but not always the binary that triggered it.

Real defence comes from correlation.

A SOC should be able to answer questions such as:

  • Which process opened this connection?
  • From which host?
  • Under which user?
  • Does that host normally use Teams?
  • Has that process executed commands?
  • Has it queried LDAP?
  • Has it accessed credentials?
  • Has it attempted lateral movement?
  • Has it generated persistent traffic to trusted destinations?

This is where a managed SOC⁠ and NDR⁠ capability provide real value.

6. Prepare incident response before the incident

When a command-and-control channel hides inside trusted services, containment cannot depend only on blocking a domain.

Response plans should cover:

  • Rapid endpoint isolation.
  • Session and credential revocation.
  • Privileged account rotation.
  • Persistence review.
  • Hunting for secondary access.
  • Forensic analysis of affected systems.
  • Review of identity, network and SaaS logs.
  • Internal and external communication.
  • Secure restoration from verified backups.

An incident response service⁠ or an incident response retainer⁠ can be the difference between hours and weeks.

Compliance implications: NIS2, DORA and ENS

This case shows why modern security regulation puts so much emphasis on detection, response and resilience.

NIS2 requires relevant organisations to manage cyber risk, implement appropriate technical and organisational measures, and improve incident handling. An attacker with one or two months of dwell time and a hard-to-see channel is exactly the kind of scenario NIS2 aims to reduce.

DORA focuses on digital operational resilience in the financial sector and its critical ICT providers. A case like this directly affects the ability to detect, contain, recover and demonstrate control over technology operations.

Spain’s ENS requires monitoring, traceability, incident management and proportionate security measures. In medium or high categories, it is not enough to have controls documented. Organisations need to reconstruct what happened, when, how and with what impact.

The shared lesson is simple: compliance cannot remain a paper exercise. Without endpoint visibility, control over outbound traffic, identity monitoring, vulnerability management and behaviour-led hunting, an organisation may appear compliant while still being blind to a real attacker.

For more context, see Hard2bit’s services for NIS2⁠, DORA⁠, ENS⁠ and ISO 27001⁠.

What security teams should review now

After this case, enterprises should review at least the following points:

  1. Which servers and endpoints can generate outbound UDP/QUIC traffic.
  2. Which processes are opening connections to Microsoft Teams infrastructure.
  3. Whether Microsoft 365 exceptions are too broad.
  4. Whether servers are allowed to use Teams or media flows without a business need.
  5. Whether Sysinternals execution is monitored in context.
  6. Whether the EDR alerts on process injection and anomalous execution.
  7. Whether LDAP queries and Active Directory reconnaissance are monitored.
  8. Whether endpoint, network and identity telemetry are correlated.
  9. Whether the SOC has hunting hypotheses for trusted-service abuse.
  10. Whether incident response can rapidly isolate hosts, revoke sessions and contain identity compromise.

These areas can be assessed through a Microsoft 365 security audit⁠, a broader Microsoft 365 security review⁠, an infrastructure and network security audit⁠ or an adversary simulation⁠.

The main lesson

The boundary is no longer the domain an endpoint connects to. The boundary is behaviour.

Trusting a destination because it belongs to Microsoft, Google, Amazon or another legitimate provider is precisely the assumption this type of technique exploits.

Effective defence does not stop at asking “where is the traffic going?”. It also asks:

  • Who generated it?
  • From which host?
  • Through which process?
  • At what time?
  • What happened before?
  • What happened afterwards?
  • Does this make sense for that user, system and context?

Backdoor.Turn does not prove that Teams is insecure. It proves that attackers are learning to live inside the exceptions, services and trust relationships organisations need in order to operate.

The answer is not blind distrust. The answer is to stop measuring trust only by destination and start measuring it by behaviour.

Would your organisation detect C2 hidden inside legitimate traffic?

Hard2bit helps organisations improve real detection, response and resilience against ransomware, identity abuse and advanced threats.

We can support you with:

If you want to review whether your organisation has enough visibility across endpoint, network, identity and Microsoft 365, contact the Hard2bit team through our contact page⁠.

Recommended sources

  • Symantec / Security.com: Hidden in Teams: DragonForce Attackers Weaponize Microsoft Teams Relays to Stay Hidden
    https://www.security.com/threat-intelligence/dragonforce-msteams-backdoor
  • The Hacker News: DragonForce Hackers Abuse Microsoft Teams Relays to Hide Backdoor.Turn C2 Traffic
    https://thehackernews.com/2026/06/dragonforce-hackers-abuse-microsoft.html
  • Help Net Security: Cybercriminals mask malicious communications through Microsoft Teams relays
    https://www.helpnetsecurity.com/2026/06/16/dragonforce-microsoft-teams-malware-backdoor-turn/
  • Microsoft Learn: Microsoft Teams call flows
    https://learn.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows
  • Check Point Research: The State of Ransomware Q1 2026
    https://research.checkpoint.com/2026/the-state-of-ransomware-q1-2026/

Frequently asked questions

What is Backdoor.Turn and why is it different?

Backdoor.Turn is a Go-based back door attributed to operators of the DragonForce ransomware and analysed by Symantec and Carbon Black in June 2026. Its novelty is not what it does once inside (running commands, stealing credentials, moving through the network) but how it communicates: it hides its command-and-control traffic inside Microsoft Teams TURN relay infrastructure, so that defenders see only connections to legitimate Microsoft servers.

How does it hide traffic inside Microsoft Teams?

It requests an anonymous visitor token from Microsoft's Skype-backed identity services, the same one a guest uses to join a meeting. With it the malware authenticates against Teams and opens a session through a legitimate TURN relay, the mechanism Teams uses to relay audio and video when two participants cannot connect directly. Through that tunnel it then establishes a QUIC session to the attacker's real control server.

Does this mean Microsoft Teams is insecure?

Not in the sense of having a vulnerability to patch. The attacker does not break Teams or exploit a product flaw: it uses intended features, TURN relays and guest tokens, for an unintended purpose. It is abuse of a trusted service, not a breach of the service. That is why the defence is not to apply a patch but to revisit the assumption that a trusted destination implies trusted behaviour.

Why don't my egress filtering and TLS inspection catch it?

Because destination-based filtering allows Microsoft domains, and here the destination is real. TLS inspection does not help either: the traffic runs over QUIC on UDP 443, which many organisations leave open and uninspected, and it ends at legitimate Microsoft infrastructure. Domain-reputation detection gives a green light because Microsoft's reputation is impeccable.

How does this relate to DragonForce and the ransomware “cartel”?

DragonForce is a ransomware group that in September 2025 proposed cooperating with LockBit and Qilin under the idea of a “cartel” that shares techniques, infrastructure and affiliates. According to Check Point Research, it claimed 101 victims in the first quarter of 2026, a 29% rise on the previous quarter. Backdoor.Turn reflects that professionalisation: techniques once typical of state-sponsored actors now appear in extortion operations.

How can I detect this kind of covert C2?

By shifting detection to the endpoint and to behaviour. Watch for injection into processes such as DbgView64.exe or other Sysinternals utilities on servers, atypical processes generating sustained UDP/443 traffic, bursts of LDAP queries away from domain controllers, and ransomware precursors such as shadow copy deletion. Correlating process and network telemetry, with proactive hunting and an NDR layer, is what closes the gap.

What concrete measures reduce the risk?

Govern outbound QUIC traffic and segment the network; treat the presence of Sysinternals utilities on servers as an anomaly; keep an EDR with process-injection visibility and attack surface reduction rules enabled; hunt by behaviour rather than by domain reputation; and rehearse a response and isolation plan. The key is to correlate endpoint, network and identity, which separately would not have seen this attack.

Does this affect NIS2, DORA or the ENS?

Yes, at its core. NIS2 and DORA require genuine detection and response capability and operational resilience against prolonged intrusions, and Spain's ENS at the high category expects sufficient monitoring and traceability. An attack with two months of dwell time and an invisible channel is exactly the scenario these rules aim to shorten. The conclusion is operational: without endpoint visibility, egress control and behaviour-led hunting, compliance stays on paper.