Attackers deploying DragonForce ransomware against a major U.S. services company in December 2025 hid command-and-control traffic inside Microsoft Teams relay infrastructure using a custom Go backdoor tracked by Symantec as Backdoor.Turn. The technical novelty is not that Teams was “hacked,” but that legitimate collaboration plumbing became camouflage for a ransomware operation already deep inside a Windows estate. For defenders, the episode is a warning that the cleanest-looking outbound traffic can be the most dangerous when trust is granted by brand name rather than behavior. It also shows how far some ransomware crews have moved from noisy smash-and-grab intrusion toward bespoke tooling, patient dwell time, and cloud-native misdirection.
The old caricature of ransomware is still useful, but only as a cautionary fossil. An exposed server gets popped, commodity loaders arrive, PowerShell lights up the console, domain admin falls, and encryption follows before Monday’s coffee has cooled. That still happens, but the DragonForce case points to a more uncomfortable model: attackers who understand that modern networks are less a perimeter than a mesh of trusted services.
Backdoor.Turn matters because it abused the defender’s own mental shortcut. Microsoft Teams traffic is supposed to go out. TURN relays are supposed to help real-time communications traverse NAT boundaries and awkward enterprise networks. A firewall rule that blocks that infrastructure is not a security policy in most businesses; it is an outage ticket waiting to happen.
That is the strategic value of the technique. The attackers did not need to defeat every sensor if they could make the traffic look like something the business had already decided to allow. To a network team staring at flows and destinations, the malicious channel could resemble outbound connections to legitimate Microsoft infrastructure rather than a ransomware crew’s command server.
The word relay is doing a lot of work here. The reported chain had Backdoor.Turn obtain an anonymous Teams visitor token through Microsoft’s Skype-backed identity services, use a legitimate Microsoft TURN relay to establish the connection, and then run a QUIC session onward to the attacker’s real command-and-control server. In practical terms, the victim network saw the front stage; the attacker controlled the backstage.
That is why this incident should not be filed as merely another ransomware tool write-up. It is part of a larger shift in which enterprise collaboration, identity, remote access, and cloud connectivity become both operational necessities and attacker cover. The very services that made hybrid work possible have also expanded the set of traffic that defenders are under pressure not to question.
That distinction matters. Teams did not appear to be the door. It was the hallway the intruders used after they were already inside.
The earliest activity on the victim network began in December 2025, with the attackers later downloading a ZIP archive containing a legitimate VirtualBox or DbgView executable and a malicious DLL intended for side loading. From there, the malicious
But the Teams relay abuse changes the detection problem. Traditional network security has long leaned on reputation: known bad IP addresses, suspicious domains, unusual geographies, and destinations that have no obvious business purpose. Here, the visible destination was a legitimate Microsoft service used by legitimate Microsoft software.
That does not make the traffic undetectable. It makes it less likely to be questioned by controls built around the assumption that the destination tells most of the story. In a Windows environment where Teams, Microsoft 365, Azure AD, and related services already dominate normal telemetry, the attacker’s best hiding place may be inside the noise floor of productivity.
This is the same lesson defenders learned from abuse of cloud storage, email forwarding rules, OAuth grants, remote monitoring tools, and signed binaries. Attackers do not always need malware that looks invisible. Sometimes they need activity that looks administratively boring.
That cost-benefit equation is changing. If endpoint products are better at detecting commodity beacons, and if defenders are better at hunting known C2 frameworks, a tailored implant that blends into collaboration traffic becomes more attractive. The ransomware economy has matured enough that high-value intrusions can justify tools once associated more with espionage than extortion.
The Go implementation is also unsurprising in 2026. Go produces portable, self-contained binaries and has become common in both legitimate infrastructure software and offensive tooling. It is easy to overstate the meaning of a programming language, but Go remains popular with threat actors because it simplifies cross-platform development and deployment logistics.
What is more important is the protocol stack. QUIC, designed for low-latency encrypted transport, is not inherently suspicious. Microsoft’s use of relay services for real-time communication is not inherently suspicious. Anonymous visitor access is not inherently suspicious. The danger emerges when several ordinary pieces are composed into an attacker-controlled path that inherits trust from the environment around it.
This is where security architecture tends to lag software architecture. Enterprises adopted cloud collaboration as a platform. Attackers increasingly treat it as a substrate. Defenders still too often inspect it as a destination.
Database servers remain attractive because they sit near valuable data, often run with generous permissions, and sometimes straddle internal and external trust zones in ways nobody wants to diagram during an audit. MSSQL in particular has a long history as a target for brute force, credential reuse, misconfiguration, and exploitation. Even when a server is not internet-facing, it may be reachable from a compromised partner network, VPN account, or forgotten application tier.
The access-broker possibility is just as important. Ransomware groups do not always need to find the first crack themselves. The market for footholds, VPN credentials, web shells, and RDP access allows one actor to specialize in entry and another to specialize in monetization. That division of labor makes root-cause certainty harder and operational speed faster.
For administrators, the lesson is blunt: do not let the sophistication of Backdoor.Turn distract from the hygiene of the front door. Inventory SQL exposure. Patch aggressively. Segment database hosts. Restrict service accounts. Monitor for suspicious archive downloads and unusual child processes from database-adjacent systems. The most elegant C2 channel is still useless until an attacker has somewhere to run it.
There is an uncomfortable asymmetry here. A defender may spend years building clean Microsoft 365 allowlists and Teams reliability exceptions, only for the decisive failure to be a server no one wanted to reboot. The attack chain is modern, but the first domino may have been mundane.
The appeal is obvious. Security tools and administrators are conditioned to treat known signed executables differently from unknown binaries. A process associated with VirtualBox, Microsoft Sysinternals tooling, or another legitimate utility may attract less suspicion than a random executable launched from a temporary directory. If the malicious payload runs inside that trusted process context, the attacker gets both execution and camouflage.
This does not mean signed software is “bad.” It means trust must be contextual rather than absolute. A legitimate executable running from an odd path, loading a DLL from the same staging folder, making unexpected outbound connections, or spawning reconnaissance tools is no longer just a legitimate executable. It is a behavior sequence.
The Windows ecosystem has been wrestling with this for years. Living-off-the-land binaries, side-loaded DLLs, signed vulnerable drivers, and remote management tools all exploit the gap between file reputation and operational intent. Attackers understand that defenders often build exceptions around tools rather than around expected behavior.
The DragonForce case adds another layer because the side-loaded stage helped set up a broader campaign of persistence and evasion. The signed executable was not the end of the trick. It was the first costume in a chain of costume changes.
That ambiguity is useful to intruders. A new local user might be a helpdesk action. A firewall rule might be troubleshooting. A password policy tweak might be legacy application accommodation. Separately, each event can be explained away; together, they describe an operator preparing to remain.
The dwell time reinforces that point. The attackers were reportedly inside the network for between one and two months. That is a long time in a ransomware case, and it suggests the operation was not limited to immediate encryption. Time inside a network allows for reconnaissance, credential collection, privilege escalation, backup discovery, data staging, and the careful disabling of defenses.
This is where many organizations still measure the wrong thing. They ask whether malware was blocked, when the more important question is whether the environment noticed that its administrative reality was changing. New accounts, weakened password behavior, unusual firewall exceptions, suspicious service creation, and unexpected remote access paths are often the pre-encryption smoke.
Ransomware response has become a race against preparation, not merely a race against payload execution. By the time encryption begins, the attackers have often already made the environment less able to resist it. In this case, the configuration changes were the infrastructure of the crime.
In this incident, Symantec described a novel attack exploiting Havoc Process Terminator by leveraging Huawei’s
That does not make the broader technique new. BYOVD has been a growing ransomware staple because it flips Microsoft’s driver trust model into an attacker asset. If a driver is legitimately signed but dangerously capable, it can become a skeleton key for terminating security processes or tampering with protected systems. The driver does not need to be malicious in origin to become malicious in use.
The Huawei driver detail is especially instructive. The weakest point in an endpoint defense stack may not be the EDR agent itself, but an old or obscure signed component that the operating system is willing to load. Enterprises collect drivers the way attics collect boxes: slowly, invisibly, and with very little appetite for inspection.
Microsoft has mechanisms such as vulnerable driver blocklists and virtualization-based security features, but the operational reality remains uneven. Some environments do not enable every protection. Some need legacy compatibility. Some discover too late that a signed driver has become a known attacker tool. The defensive burden is not just patching applications; it is governing the kernel attack surface that ships through years of hardware and software dependencies.
The use of custom tooling does not necessarily prove that every DragonForce operator is sophisticated. Ransomware branding can blur who built what, who deployed what, and who merely rented access to a playbook. But it does show that at least part of the operation had access to capabilities beyond commodity point-and-click ransomware kits.
This is a business model issue as much as a technical one. High-value victims justify investment. A major U.S. services firm is not a random home PC; it is a target with operational dependencies, customer obligations, and likely insurance, legal, and regulatory pressure. For such targets, stealthier tooling can improve the odds of reaching the ransom stage with leverage intact.
The attacker’s goal is not elegance for its own sake. It is time. Time to map the network. Time to find backups. Time to identify high-value systems. Time to locate data worth stealing. Time to understand where the victim will hurt most. Backdoor.Turn’s sophistication should be read through that lens: a way to buy time by lowering the chance that command traffic triggers an alarm.
That also explains why ransomware increasingly resembles intrusion operations once associated with state actors. The economics of extortion reward patience when the target is large enough. The difference is not always in the tradecraft anymore; it is in the monetization.
If a sensor sees only outbound traffic to Microsoft Teams infrastructure, the hard question becomes: what should it have done with that information? Blocking it would likely break business communications. Alerting on it broadly would drown analysts. Ignoring it entirely gives attackers cover. The answer has to come from correlation, not from destination reputation alone.
Organizations need to ask whether a server that has no business launching Teams-like relay behavior is doing so. They need to inspect process lineage, user context, binary path, token behavior, connection timing, and whether the same host is also showing signs of reconnaissance or policy tampering. A database server using a relay path after a suspicious ZIP download is very different from an employee laptop joining a meeting.
That is where identity and endpoint telemetry become inseparable from network telemetry. The network can say where a connection went. The endpoint can say what process initiated it. Identity logs can say what token or account context made it possible. Security teams that operate these datasets in separate silos will miss the story that emerges only when they are stitched together.
There is also a governance issue. Allowlisting Microsoft, Google, Amazon, Cloudflare, and other major providers as undifferentiated “trusted internet” is increasingly untenable. Attackers have learned that the cloud is both infrastructure and camouflage. Defenders need more precise models of what specific services, from which devices, by which processes, under which identities, are normal.
Novel techniques often look unique right up until detection improves. Once defenders know what to hunt for, they sometimes find older traces. Alternatively, public reporting can inspire copycats. Either way, the technique is now part of the attacker imagination space.
TURN relays are not unique to Teams. Real-time communication platforms depend on relay mechanisms because the internet is messy, NAT is everywhere, and users expect calls to connect without understanding packet traversal. The same architectural patterns exist across collaboration, conferencing, gaming, remote support, and browser-based communications.
That does not mean every relay service is equally exposed or equally abusable. Implementation details matter. Authentication, token scope, relay policy, traffic inspection, anomaly detection, and abuse prevention all matter. But the defensive theme is broader than one vendor: infrastructure designed to make communication reliable can also make unwanted communication resilient.
QUIC adds another wrinkle. Its encrypted, low-latency design is valuable for modern applications, but it can complicate middlebox inspection and legacy monitoring assumptions. Enterprises that still treat QUIC as an edge case are increasingly behind the curve. Blocking QUIC wholesale is a blunt instrument; understanding where it is expected and where it is not is a better one.
The next detection fight will be less about spotting malware calling a strange domain and more about spotting an unauthorized application using an authorized service in an unauthorized way. That sentence is ugly because the problem is ugly. It is also the future of enterprise defense.
Major cloud and collaboration vendors sit in a difficult position. Their products must work across hostile network conditions, consumer-grade routers, strict firewalls, guest access flows, and mixed identity environments. The smoother they make that experience, the more implicit trust their traffic receives inside enterprises.
Security teams, meanwhile, need knobs and logs that match the granularity of abuse. If a service offers anonymous visitor tokens, relay-mediated sessions, and encrypted transport, defenders need ways to distinguish ordinary use from strange use. That may mean better tenant-level controls, clearer documentation, richer audit events, and stronger anomaly signals when relay paths are used by nonstandard clients.
The industry has seen this movie before with OAuth consent abuse, email forwarding rules, and cloud storage exfiltration. Features built for flexibility became attacker primitives because telemetry and policy lagged behind adoption. The answer was not to ban OAuth or email forwarding everywhere. It was to make abuse more observable and controllable.
For Microsoft, the optics are sensitive because Teams is deeply embedded in the Microsoft 365 security conversation. Customers are told to consolidate, integrate, and trust the ecosystem. When attackers hide inside that ecosystem’s legitimate paths, the platform owner has to help defenders tell the difference between productivity and parasitism.
That help cannot come only in the form of post-incident indicators. Indicators expire. Architectural patterns persist.
Start with servers. A SQL server should not normally be downloading random ZIP archives, launching VirtualBox-related executables from staging paths, loading unexpected DLLs, creating local users, weakening password restrictions, or modifying firewall policy to accommodate remote access. If those events happen in proximity, the destination of outbound traffic is almost secondary.
Then look at process lineage. Which executable initiated relay-bound traffic? Where did it live on disk? Was it signed? Did it load local DLLs from writable directories? Was it spawned by a service account, a database process, a script interpreter, or a remote shell? The legitimacy of the destination must be weighed against the weirdness of the origin.
Driver control also needs a harder line. Vulnerable driver blocklists should be treated as operational security controls, not optional hardening trivia. Endpoint teams should inventory loaded drivers, monitor for new kernel service creation, and treat unexpected signed driver drops in temporary directories as high-priority events. BYOVD is not exotic anymore; it is a recurring ransomware technique.
Finally, revisit allowlists. A rule that says “allow Microsoft” is not a security model. It is a convenience model. The closer an organization can get to service-specific, host-specific, process-aware policy, the less useful brand-name camouflage becomes to an attacker.
Individually, these may not trigger a crisis. Together, they describe a ransomware operation.
That is why modern detection engineering has to be narrative engineering. The goal is not simply to alert on bad hashes or suspicious IPs; it is to assemble sequences that make operational sense. A suspicious archive download followed by DLL side loading, followed by local account creation, followed by relay-mediated outbound sessions, followed by driver-based EDR tampering is not a collection of weak signals. It is a plot.
Security vendors often market this as correlation, but correlation is only part of it. The deeper requirement is environmental understanding. A workstation in sales and a domain controller should not be judged by the same baseline. A developer machine running VirtualBox is not the same as a production database host loading a VirtualBox DLL from a temporary directory. Context is what turns telemetry into judgment.
This is also where managed detection and response providers earn or lose their keep. Commodity alert triage will not catch subtle abuse of legitimate infrastructure quickly enough. Analysts need permission to ask why a “normal” Microsoft connection is happening from an abnormal host after abnormal execution.
The uncomfortable truth is that many enterprises already collect enough data to see attacks like this. They just do not organize it around attacker intent.
Cloud-native camouflage changes the defender’s economics. It makes broad blocking harder, simple reputation weaker, and after-the-fact log review more complex. It forces security teams to defend not only against malicious infrastructure but against malicious use of good infrastructure.
This has been coming for years. Attackers abuse Teams chats for phishing. They use Quick Assist and remote monitoring tools for hands-on access. They hide payloads in cloud storage. They route traffic through trusted providers. They exploit the fact that business technology has converged around a handful of platforms that cannot simply be turned off.
The DragonForce case is sharper because it reportedly extends that abuse into Teams relay infrastructure and QUIC-based C2. That is not just another SaaS account takeover trick. It is an attack on assumptions about what collaboration traffic means.
For WindowsForum readers, the Microsoft angle is unavoidable but should be handled precisely. This is not a story about uninstalling Teams. It is a story about the danger of treating Microsoft ecosystem traffic as self-authenticating. In a modern Windows estate, Microsoft infrastructure is both the nervous system of the business and an attractive shadow for intruders.
The same applies to signed binaries and signed drivers. A trusted signature is not a moral character reference. It tells you something about origin, not about current intent. Attackers are increasingly skilled at chaining legitimate components into illegitimate outcomes.
Security teams should treat this as a call to tighten the seams between endpoint, network, identity, and cloud telemetry. The interesting signals in this intrusion were not confined to one tool category. They crossed process execution, relay traffic, local policy changes, firewall modifications, driver loading, and likely credential or access expansion. No single dashboard tells that story unless someone designs it to.
There is a cultural piece as well. Enterprises often optimize for not breaking Microsoft 365, and understandably so. But the more essential a platform becomes, the more important it is to monitor its edge cases. Trust without instrumentation becomes an attacker subsidy.
The DragonForce case is a preview of where serious ransomware operations are headed: less noise at the edge, more abuse of trusted platforms, and more pressure on defenders to understand intent rather than merely classify destinations. Microsoft Teams did not need to be broken to become useful to attackers; it only needed to be trusted more than it was understood. The organizations that adapt fastest will be the ones that treat legitimate infrastructure as observable infrastructure, not invisible infrastructure, because the next clever relay will almost certainly arrive wearing another familiar logo.
The Ransomware Operator Has Learned to Dress Like the Tenant
The old caricature of ransomware is still useful, but only as a cautionary fossil. An exposed server gets popped, commodity loaders arrive, PowerShell lights up the console, domain admin falls, and encryption follows before Monday’s coffee has cooled. That still happens, but the DragonForce case points to a more uncomfortable model: attackers who understand that modern networks are less a perimeter than a mesh of trusted services.Backdoor.Turn matters because it abused the defender’s own mental shortcut. Microsoft Teams traffic is supposed to go out. TURN relays are supposed to help real-time communications traverse NAT boundaries and awkward enterprise networks. A firewall rule that blocks that infrastructure is not a security policy in most businesses; it is an outage ticket waiting to happen.
That is the strategic value of the technique. The attackers did not need to defeat every sensor if they could make the traffic look like something the business had already decided to allow. To a network team staring at flows and destinations, the malicious channel could resemble outbound connections to legitimate Microsoft infrastructure rather than a ransomware crew’s command server.
The word relay is doing a lot of work here. The reported chain had Backdoor.Turn obtain an anonymous Teams visitor token through Microsoft’s Skype-backed identity services, use a legitimate Microsoft TURN relay to establish the connection, and then run a QUIC session onward to the attacker’s real command-and-control server. In practical terms, the victim network saw the front stage; the attacker controlled the backstage.
That is why this incident should not be filed as merely another ransomware tool write-up. It is part of a larger shift in which enterprise collaboration, identity, remote access, and cloud connectivity become both operational necessities and attacker cover. The very services that made hybrid work possible have also expanded the set of traffic that defenders are under pressure not to question.
Microsoft Teams Was Not the Breach, but It Became the Blind Spot
It is tempting to frame this as a Microsoft Teams problem. That would be too simple, and probably too comforting. The initial access in the incident reportedly came from exploitation of a vulnerability in an SQL or MSSQL server, although the specific bug is not known; Symantec also left open the possibility that access may have been purchased from an access broker.That distinction matters. Teams did not appear to be the door. It was the hallway the intruders used after they were already inside.
The earliest activity on the victim network began in December 2025, with the attackers later downloading a ZIP archive containing a legitimate VirtualBox or DbgView executable and a malicious DLL intended for side loading. From there, the malicious
vboxrt.dll fetched additional code from multiple servers, supporting reconnaissance, access maintenance, and detection evasion. The intrusion then developed in the familiar ransomware direction: persistence, privilege, lateral movement, and preparation for impact.But the Teams relay abuse changes the detection problem. Traditional network security has long leaned on reputation: known bad IP addresses, suspicious domains, unusual geographies, and destinations that have no obvious business purpose. Here, the visible destination was a legitimate Microsoft service used by legitimate Microsoft software.
That does not make the traffic undetectable. It makes it less likely to be questioned by controls built around the assumption that the destination tells most of the story. In a Windows environment where Teams, Microsoft 365, Azure AD, and related services already dominate normal telemetry, the attacker’s best hiding place may be inside the noise floor of productivity.
This is the same lesson defenders learned from abuse of cloud storage, email forwarding rules, OAuth grants, remote monitoring tools, and signed binaries. Attackers do not always need malware that looks invisible. Sometimes they need activity that looks administratively boring.
Backdoor.Turn Is a Small Tool With a Big Architectural Message
Backdoor.Turn is notable for being custom, written in Go, and sophisticated enough to integrate with Microsoft’s relay infrastructure rather than simply beaconing to a server over HTTPS. Ransomware operations often reuse commodity tooling because it is cheaper, faster, and good enough. Custom tooling raises the attacker’s development cost, but it can buy stealth, control, and operational separation.That cost-benefit equation is changing. If endpoint products are better at detecting commodity beacons, and if defenders are better at hunting known C2 frameworks, a tailored implant that blends into collaboration traffic becomes more attractive. The ransomware economy has matured enough that high-value intrusions can justify tools once associated more with espionage than extortion.
The Go implementation is also unsurprising in 2026. Go produces portable, self-contained binaries and has become common in both legitimate infrastructure software and offensive tooling. It is easy to overstate the meaning of a programming language, but Go remains popular with threat actors because it simplifies cross-platform development and deployment logistics.
What is more important is the protocol stack. QUIC, designed for low-latency encrypted transport, is not inherently suspicious. Microsoft’s use of relay services for real-time communication is not inherently suspicious. Anonymous visitor access is not inherently suspicious. The danger emerges when several ordinary pieces are composed into an attacker-controlled path that inherits trust from the environment around it.
This is where security architecture tends to lag software architecture. Enterprises adopted cloud collaboration as a platform. Attackers increasingly treat it as a substrate. Defenders still too often inspect it as a destination.
The SQL Server Angle Is the Part Nobody Should Ignore
The flashiest piece of the case is Teams relay abuse, but the reported initial access path deserves equal attention. If the attackers entered through a vulnerable SQL or MSSQL server, the story starts not with exotic relay manipulation but with the oldest enterprise failure pattern in Windows land: exposed, under-patched, over-privileged infrastructure.Database servers remain attractive because they sit near valuable data, often run with generous permissions, and sometimes straddle internal and external trust zones in ways nobody wants to diagram during an audit. MSSQL in particular has a long history as a target for brute force, credential reuse, misconfiguration, and exploitation. Even when a server is not internet-facing, it may be reachable from a compromised partner network, VPN account, or forgotten application tier.
The access-broker possibility is just as important. Ransomware groups do not always need to find the first crack themselves. The market for footholds, VPN credentials, web shells, and RDP access allows one actor to specialize in entry and another to specialize in monetization. That division of labor makes root-cause certainty harder and operational speed faster.
For administrators, the lesson is blunt: do not let the sophistication of Backdoor.Turn distract from the hygiene of the front door. Inventory SQL exposure. Patch aggressively. Segment database hosts. Restrict service accounts. Monitor for suspicious archive downloads and unusual child processes from database-adjacent systems. The most elegant C2 channel is still useless until an attacker has somewhere to run it.
There is an uncomfortable asymmetry here. A defender may spend years building clean Microsoft 365 allowlists and Teams reliability exceptions, only for the decisive failure to be a server no one wanted to reboot. The attack chain is modern, but the first domino may have been mundane.
DLL Side Loading Remains the Windows Attacker’s Favorite Costume Change
After initial access, the attackers reportedly used a legitimate signed executable associated with VirtualBox or DbgView alongside a malicious DLL namedvboxrt.dll. This is classic DLL side loading: place a malicious library where a trusted program will load it, then let the trusted program provide cover for execution. Windows software’s flexibility around dynamic libraries is a feature for developers and a long-running gift to adversaries.The appeal is obvious. Security tools and administrators are conditioned to treat known signed executables differently from unknown binaries. A process associated with VirtualBox, Microsoft Sysinternals tooling, or another legitimate utility may attract less suspicion than a random executable launched from a temporary directory. If the malicious payload runs inside that trusted process context, the attacker gets both execution and camouflage.
This does not mean signed software is “bad.” It means trust must be contextual rather than absolute. A legitimate executable running from an odd path, loading a DLL from the same staging folder, making unexpected outbound connections, or spawning reconnaissance tools is no longer just a legitimate executable. It is a behavior sequence.
The Windows ecosystem has been wrestling with this for years. Living-off-the-land binaries, side-loaded DLLs, signed vulnerable drivers, and remote management tools all exploit the gap between file reputation and operational intent. Attackers understand that defenders often build exceptions around tools rather than around expected behavior.
The DragonForce case adds another layer because the side-loaded stage helped set up a broader campaign of persistence and evasion. The signed executable was not the end of the trick. It was the first costume in a chain of costume changes.
The Quiet Configuration Changes Tell the Real Ransomware Story
The reported persistence steps were not glamorous, but they were revealing. The attackers usedLimitBlankPassword, added users and groups, and modified firewall rules to facilitate remote access and keep command-and-control communication unobstructed. This is the sort of administrative tampering that can look less like malware and more like a careless engineer on a bad day.That ambiguity is useful to intruders. A new local user might be a helpdesk action. A firewall rule might be troubleshooting. A password policy tweak might be legacy application accommodation. Separately, each event can be explained away; together, they describe an operator preparing to remain.
The dwell time reinforces that point. The attackers were reportedly inside the network for between one and two months. That is a long time in a ransomware case, and it suggests the operation was not limited to immediate encryption. Time inside a network allows for reconnaissance, credential collection, privilege escalation, backup discovery, data staging, and the careful disabling of defenses.
This is where many organizations still measure the wrong thing. They ask whether malware was blocked, when the more important question is whether the environment noticed that its administrative reality was changing. New accounts, weakened password behavior, unusual firewall exceptions, suspicious service creation, and unexpected remote access paths are often the pre-encryption smoke.
Ransomware response has become a race against preparation, not merely a race against payload execution. By the time encryption begins, the attackers have often already made the environment less able to resist it. In this case, the configuration changes were the infrastructure of the crime.
BYOVD Turns Signed Drivers Into Security Debt
The attackers also used the Bring Your Own Vulnerable Driver technique, or BYOVD, for defense evasion. BYOVD works because Windows trusts signed kernel drivers, and vulnerable drivers can provide kernel-level capabilities to user-mode attackers. Once an attacker can load or abuse such a driver, endpoint security products running in user space may be outmatched.In this incident, Symantec described a novel attack exploiting Havoc Process Terminator by leveraging Huawei’s
HWAuidoOs2Ec.sys, a driver whose vulnerable status was later documented by Huntress in March 2026. The timing is important: according to the reporting, this DragonForce intrusion occurred before that public documentation, meaning defenders would not necessarily have had ready-made detection logic for this particular driver abuse at the time.That does not make the broader technique new. BYOVD has been a growing ransomware staple because it flips Microsoft’s driver trust model into an attacker asset. If a driver is legitimately signed but dangerously capable, it can become a skeleton key for terminating security processes or tampering with protected systems. The driver does not need to be malicious in origin to become malicious in use.
The Huawei driver detail is especially instructive. The weakest point in an endpoint defense stack may not be the EDR agent itself, but an old or obscure signed component that the operating system is willing to load. Enterprises collect drivers the way attics collect boxes: slowly, invisibly, and with very little appetite for inspection.
Microsoft has mechanisms such as vulnerable driver blocklists and virtualization-based security features, but the operational reality remains uneven. Some environments do not enable every protection. Some need legacy compatibility. Some discover too late that a signed driver has become a known attacker tool. The defensive burden is not just patching applications; it is governing the kernel attack surface that ships through years of hardware and software dependencies.
DragonForce Looks Less Like a Gang and More Like a Platform
DragonForce has been associated with ransomware-as-a-service activity, and this case fits the broader trend of ransomware crews becoming ecosystems rather than single crews. Affiliates, access brokers, tool developers, negotiators, leak-site operators, and laundering channels can all sit around the same extortion event. That makes attribution less tidy and defense less satisfying.The use of custom tooling does not necessarily prove that every DragonForce operator is sophisticated. Ransomware branding can blur who built what, who deployed what, and who merely rented access to a playbook. But it does show that at least part of the operation had access to capabilities beyond commodity point-and-click ransomware kits.
This is a business model issue as much as a technical one. High-value victims justify investment. A major U.S. services firm is not a random home PC; it is a target with operational dependencies, customer obligations, and likely insurance, legal, and regulatory pressure. For such targets, stealthier tooling can improve the odds of reaching the ransom stage with leverage intact.
The attacker’s goal is not elegance for its own sake. It is time. Time to map the network. Time to find backups. Time to identify high-value systems. Time to locate data worth stealing. Time to understand where the victim will hurt most. Backdoor.Turn’s sophistication should be read through that lens: a way to buy time by lowering the chance that command traffic triggers an alarm.
That also explains why ransomware increasingly resembles intrusion operations once associated with state actors. The economics of extortion reward patience when the target is large enough. The difference is not always in the tradecraft anymore; it is in the monetization.
The Defender’s Problem Is Now Trust, Not Just Visibility
Network defenders have spent years trying to improve visibility, and rightly so. Flow logs, DNS telemetry, proxy records, EDR events, identity logs, and cloud audit trails all matter. But the DragonForce case argues that visibility alone is not enough when the visible thing is legitimate infrastructure performing an attacker-abused function.If a sensor sees only outbound traffic to Microsoft Teams infrastructure, the hard question becomes: what should it have done with that information? Blocking it would likely break business communications. Alerting on it broadly would drown analysts. Ignoring it entirely gives attackers cover. The answer has to come from correlation, not from destination reputation alone.
Organizations need to ask whether a server that has no business launching Teams-like relay behavior is doing so. They need to inspect process lineage, user context, binary path, token behavior, connection timing, and whether the same host is also showing signs of reconnaissance or policy tampering. A database server using a relay path after a suspicious ZIP download is very different from an employee laptop joining a meeting.
That is where identity and endpoint telemetry become inseparable from network telemetry. The network can say where a connection went. The endpoint can say what process initiated it. Identity logs can say what token or account context made it possible. Security teams that operate these datasets in separate silos will miss the story that emerges only when they are stitched together.
There is also a governance issue. Allowlisting Microsoft, Google, Amazon, Cloudflare, and other major providers as undifferentiated “trusted internet” is increasingly untenable. Attackers have learned that the cloud is both infrastructure and camouflage. Defenders need more precise models of what specific services, from which devices, by which processes, under which identities, are normal.
Teams Relay Abuse Is a Preview of the Next Detection Fight
The most important phrase in Symantec’s description may be “to our knowledge.” The company said this was the first time TURN relay infrastructure had been abused this way in the wild, to its knowledge. That caveat should not be read as weakness; it should be read as a boundary marker around what defenders can currently observe and prove.Novel techniques often look unique right up until detection improves. Once defenders know what to hunt for, they sometimes find older traces. Alternatively, public reporting can inspire copycats. Either way, the technique is now part of the attacker imagination space.
TURN relays are not unique to Teams. Real-time communication platforms depend on relay mechanisms because the internet is messy, NAT is everywhere, and users expect calls to connect without understanding packet traversal. The same architectural patterns exist across collaboration, conferencing, gaming, remote support, and browser-based communications.
That does not mean every relay service is equally exposed or equally abusable. Implementation details matter. Authentication, token scope, relay policy, traffic inspection, anomaly detection, and abuse prevention all matter. But the defensive theme is broader than one vendor: infrastructure designed to make communication reliable can also make unwanted communication resilient.
QUIC adds another wrinkle. Its encrypted, low-latency design is valuable for modern applications, but it can complicate middlebox inspection and legacy monitoring assumptions. Enterprises that still treat QUIC as an edge case are increasingly behind the curve. Blocking QUIC wholesale is a blunt instrument; understanding where it is expected and where it is not is a better one.
The next detection fight will be less about spotting malware calling a strange domain and more about spotting an unauthorized application using an authorized service in an unauthorized way. That sentence is ugly because the problem is ugly. It is also the future of enterprise defense.
Microsoft’s Role Is Complicated Because the Abuse Rides on Design
There is no evidence in the provided reporting that Microsoft Teams itself was compromised as a service. The attackers appear to have abused legitimate relay functionality, not breached Microsoft’s infrastructure. That distinction is important for accuracy, but it does not absolve platform providers from the security implications of how their services can be misused.Major cloud and collaboration vendors sit in a difficult position. Their products must work across hostile network conditions, consumer-grade routers, strict firewalls, guest access flows, and mixed identity environments. The smoother they make that experience, the more implicit trust their traffic receives inside enterprises.
Security teams, meanwhile, need knobs and logs that match the granularity of abuse. If a service offers anonymous visitor tokens, relay-mediated sessions, and encrypted transport, defenders need ways to distinguish ordinary use from strange use. That may mean better tenant-level controls, clearer documentation, richer audit events, and stronger anomaly signals when relay paths are used by nonstandard clients.
The industry has seen this movie before with OAuth consent abuse, email forwarding rules, and cloud storage exfiltration. Features built for flexibility became attacker primitives because telemetry and policy lagged behind adoption. The answer was not to ban OAuth or email forwarding everywhere. It was to make abuse more observable and controllable.
For Microsoft, the optics are sensitive because Teams is deeply embedded in the Microsoft 365 security conversation. Customers are told to consolidate, integrate, and trust the ecosystem. When attackers hide inside that ecosystem’s legitimate paths, the platform owner has to help defenders tell the difference between productivity and parasitism.
That help cannot come only in the form of post-incident indicators. Indicators expire. Architectural patterns persist.
Windows Administrators Need to Hunt the Chain, Not the Brand
For Windows admins, the practical response should not be panic-blocking Teams or treating every Microsoft relay as radioactive. That would break businesses and miss the point. The better response is to hunt the behaviors surrounding relay abuse and to reduce the number of systems that can plausibly participate in it.Start with servers. A SQL server should not normally be downloading random ZIP archives, launching VirtualBox-related executables from staging paths, loading unexpected DLLs, creating local users, weakening password restrictions, or modifying firewall policy to accommodate remote access. If those events happen in proximity, the destination of outbound traffic is almost secondary.
Then look at process lineage. Which executable initiated relay-bound traffic? Where did it live on disk? Was it signed? Did it load local DLLs from writable directories? Was it spawned by a service account, a database process, a script interpreter, or a remote shell? The legitimacy of the destination must be weighed against the weirdness of the origin.
Driver control also needs a harder line. Vulnerable driver blocklists should be treated as operational security controls, not optional hardening trivia. Endpoint teams should inventory loaded drivers, monitor for new kernel service creation, and treat unexpected signed driver drops in temporary directories as high-priority events. BYOVD is not exotic anymore; it is a recurring ransomware technique.
Finally, revisit allowlists. A rule that says “allow Microsoft” is not a security model. It is a convenience model. The closer an organization can get to service-specific, host-specific, process-aware policy, the less useful brand-name camouflage becomes to an attacker.
The Clues Were There, but They Were Scattered Across the Estate
The DragonForce intrusion illustrates a common failure mode in enterprise detection: each team owns a piece of the evidence, but no one owns the story. Network teams see Microsoft-bound traffic. Endpoint teams see a signed executable doing something odd. Identity teams see account changes. Server teams see SQL weirdness. Firewall teams see rule modifications.Individually, these may not trigger a crisis. Together, they describe a ransomware operation.
That is why modern detection engineering has to be narrative engineering. The goal is not simply to alert on bad hashes or suspicious IPs; it is to assemble sequences that make operational sense. A suspicious archive download followed by DLL side loading, followed by local account creation, followed by relay-mediated outbound sessions, followed by driver-based EDR tampering is not a collection of weak signals. It is a plot.
Security vendors often market this as correlation, but correlation is only part of it. The deeper requirement is environmental understanding. A workstation in sales and a domain controller should not be judged by the same baseline. A developer machine running VirtualBox is not the same as a production database host loading a VirtualBox DLL from a temporary directory. Context is what turns telemetry into judgment.
This is also where managed detection and response providers earn or lose their keep. Commodity alert triage will not catch subtle abuse of legitimate infrastructure quickly enough. Analysts need permission to ask why a “normal” Microsoft connection is happening from an abnormal host after abnormal execution.
The uncomfortable truth is that many enterprises already collect enough data to see attacks like this. They just do not organize it around attacker intent.
The Ransomware Playbook Is Becoming a Cloud-Native Patience Game
The broader story is not that ransomware has become magically sophisticated across the board. It is that the upper tier of ransomware operations is selectively adopting techniques that buy stealth in cloud-heavy enterprise networks. They do not need every intrusion to be elegant. They need the profitable ones to last long enough.Cloud-native camouflage changes the defender’s economics. It makes broad blocking harder, simple reputation weaker, and after-the-fact log review more complex. It forces security teams to defend not only against malicious infrastructure but against malicious use of good infrastructure.
This has been coming for years. Attackers abuse Teams chats for phishing. They use Quick Assist and remote monitoring tools for hands-on access. They hide payloads in cloud storage. They route traffic through trusted providers. They exploit the fact that business technology has converged around a handful of platforms that cannot simply be turned off.
The DragonForce case is sharper because it reportedly extends that abuse into Teams relay infrastructure and QUIC-based C2. That is not just another SaaS account takeover trick. It is an attack on assumptions about what collaboration traffic means.
For WindowsForum readers, the Microsoft angle is unavoidable but should be handled precisely. This is not a story about uninstalling Teams. It is a story about the danger of treating Microsoft ecosystem traffic as self-authenticating. In a modern Windows estate, Microsoft infrastructure is both the nervous system of the business and an attractive shadow for intruders.
The Practical Lesson Is to Distrust Clean-Looking Traffic From Dirty Hosts
The most actionable lesson from this case is brutally simple: the reputation of the destination cannot redeem the behavior of a compromised source. If a server is behaving like an infected host, the fact that it is talking to Microsoft should not end the investigation. It should sharpen it.The same applies to signed binaries and signed drivers. A trusted signature is not a moral character reference. It tells you something about origin, not about current intent. Attackers are increasingly skilled at chaining legitimate components into illegitimate outcomes.
Security teams should treat this as a call to tighten the seams between endpoint, network, identity, and cloud telemetry. The interesting signals in this intrusion were not confined to one tool category. They crossed process execution, relay traffic, local policy changes, firewall modifications, driver loading, and likely credential or access expansion. No single dashboard tells that story unless someone designs it to.
There is a cultural piece as well. Enterprises often optimize for not breaking Microsoft 365, and understandably so. But the more essential a platform becomes, the more important it is to monitor its edge cases. Trust without instrumentation becomes an attacker subsidy.
The Teams Relay Trick Leaves Windows Shops With Fewer Excuses
This incident should push administrators and security teams toward concrete changes, not abstract anxiety. The point is not to declare Teams unsafe; the point is to stop granting blanket trust to any traffic wearing a Microsoft badge.- Servers that do not require collaboration or real-time communications should be baselined so unexpected Teams-like relay behavior stands out quickly.
- Security teams should correlate Microsoft-bound network sessions with the originating process, binary path, parent process, user context, and recent host activity.
- Windows driver governance should include active monitoring for newly created kernel services, unexpected signed drivers, and known vulnerable driver artifacts.
- SQL and MSSQL servers should be treated as high-risk entry points, with aggressive patching, segmentation, least-privilege service accounts, and monitoring for unusual downloads or process launches.
- DLL side loading detections should focus on legitimate signed executables loading libraries from writable or unexpected directories, especially on servers.
- Firewall and local account changes should be treated as ransomware preparation signals when they occur alongside suspicious execution or remote access activity.
The DragonForce case is a preview of where serious ransomware operations are headed: less noise at the edge, more abuse of trusted platforms, and more pressure on defenders to understand intent rather than merely classify destinations. Microsoft Teams did not need to be broken to become useful to attackers; it only needed to be trusted more than it was understood. The organizations that adapt fastest will be the ones that treat legitimate infrastructure as observable infrastructure, not invisible infrastructure, because the next clever relay will almost certainly arrive wearing another familiar logo.
References
- Primary source: security.com
Published: Tue, 16 Jun 2026 10:11:12 GMT
Hidden in Teams: DragonForce Attackers Weaponize Microsoft Teams Relays to Stay Hidden | SECURITY.COM
Backdoor.Turn, a Go-based RAT, is the first known malware to abuse Microsoft Teams' TURN relay servers to mask command-and-control traffic. The attackers also used a previously unknown vulnerability in a Huawei driver.www.security.com - Related coverage: huntress.com
Nightmare-Eclipse Tooling Seen in Real-World Intrusion | Huntress
Huntress observed in-the-wild use of Nightmare-Eclipse tooling, including BlueHammer, RedSun, and UnDefend, in a live intrusion involving FortiGate VPN compromise as the initial access, reconnaissance commands, and likely tunneling activity.www.huntress.com - Related coverage: cybernews.com
25K systems exposed via adware update flaw | Cybernews
A trusted adware app left 25,000+ systems exposed after researchers discover an insecure update channel that could have let attackers push malicious updates for as little as $10.
cybernews.com
- Official source: blogs.microsoft.com
Disrupting Fox Tempest: A cybercrime service that turned “verified” software into a pathway for ransomware - Microsoft On the Issues
Microsoft files legal case against Fox Tempest, a malware-signing service enabling cyberattacks by disguising malicious code as trusted software.blogs.microsoft.com - Official source: cdn-dynmedia-1.microsoft.com
- Related coverage: ransomwared.eu
