Microsoft Defender’s attack disruption now includes device isolation, a new response action that extends autonomous protection directly to compromised endpoints.
At QNET, an attacker initiated a multi-stage attack using a legitimate Windows tool on a compromised endpoint to retrieve a malicious remote payload–a classic living-off-the-land (LOL) technique that often evades traditional containment. By automatically enforcing the new device isolation action on the compromised endpoint, Defender attack disruption stopped the attack dead in its tracks. From the first high-severity alert to completed isolation, after only 128 seconds, Defender cut off the attack chain before the second-stage payload could establish persistence or move beyond the host.
The growing threat: when the endpoint is the blast radius
Attack disruption has proven highly effective at stopping multistage, cross-domain attacks by disrupting the attacker’s ability to move across the environment. In many identity-driven attack scenarios, containing the compromised user is enough to shut down the attack chain, preventing lateral movement and limiting the attacker’s ability to access additional systems, identities, and resources.
However, we are increasingly seeing a different class of high-severity incidents that begin with initial access directly on the device. Once adversaries establish a foothold on an endpoint, they can plant multiple persistence mechanisms and continue operating locally on the machine. This means that acting against the user’s identity alone is no longer enough to dismantle the threat.
In these scenarios, the attacker has multiple ways to communicate and operate on the device beyond the user entity; the malicious code is already executing locally on the machine. The attacker doesn’t have to move laterally immediately; they can establish persistence, steal credentials, inject into processes, and prepare follow-on stages directly from the compromised endpoint itself.
Previously, stopping these attacks required manual triage and response, giving attackers time to advance. Device isolation closes this gap by automatically correlating signals, assessing the threat, and isolating the compromised device within seconds.
Traditional response approaches often depend on static playbooks triggered by individual alerts and maintained through manual tuning. Attack disruption instead uses AI-driven correlation and real-time analysis to identify multi-stage attacks by connecting signals across the environment before taking action. Device isolation is enforced only when the disruption pipeline reaches a high-confidence verdict—a threshold maintained at 99% precision.
What is device isolation?
When Microsoft Defender determines with high confidence that an endpoint is compromised, it isolates the device to immediately stop attacker activity and reduce the risk of further impact, such as data exfiltration and lateral movement.
What happens during device Isolation
When a device is isolated, all external network connectivity is blocked while maintaining access to required security services like Microsoft Defender for Endpoint. Selective isolation is supported, allowing customer-defined services or exclusions to continue functioning.
Automatic device isolation is scoped to the affected device (supported today on onboarded MDE workstations), time-limited, and operator-controlled. Security teams can review context, take follow-up actions, and manually release isolation when it’s safe to do so.
Why it matters
Device isolation is a powerful containment control because it disrupts the attack regardless of how the device was compromised or what the attacker planned to do next. A single action cuts off network access, breaking lateral movement, command and control, credential theft, and rapid encryption–effectively stopping hands-on activity and preventing spread to other systems. It is designed to work hand in hand with user containment. Isolating only the device or only the user leaves gaps; together, each one makes up for the weaknesses of the other, thereby mitigating these gaps to more effectively contain the attack.
Case study: QNET
QNET is a global direct-selling company with a distributed workforce and a lean security operations center (SOC). Like most teams of its size, QNET runs Defender with attack disruption enabled and relies on it to handle the first five minutes of a high-severity incident so analysts can focus on finding the root cause.
In the incident detailed here, attack disruption proved decisive: it stopped a multi-stage attack on a single endpoint within 128 seconds by automatically enforcing device isolation, its newest disruption action. Without this autonomous disruption, the human-in-the-loop delay could have been the difference between a contained initial living-off-the-land binary (LOLBin) execution and a fully detonated second-stage payload that had achieved credential theft and persistence.
In the customer’s words
“At QNET, we’ve seen a real impact from Microsoft’s attack disruption capability. During a recent incident, the device isolation was triggered almost immediately, which gave us confidence that the threat was contained early before it had any chance to spread.
What stood out for us is how this changes the way the team operates. Instead of racing against time to investigate and contain an active threat, my team can step in knowing the situation is already under control. That shift allows us to focus more on root cause analysis and remediation, rather than spending critical time trying to piece together what’s happening while the risk is still ongoing.
From a day-to-day SOC perspective, it makes our response more efficient and far less reactive. The alerts are clear, the actions are meaningful, and the disruption happens early enough to actually make a difference, not after the damage is done.
Overall, it’s helped us streamline our incident response and reduce exposure, while giving the team more breathing room to focus on what really matters.”
— Ben Bredenkamp, Group CIO, QI Group
Attack chain overview
| 08:30 – 09:22 | Baseline | A user opened a malicious file, likely delivered through email or browser download. The file executed mshta.exe, a legitimate Windows utility commonly abused by attackers. The mshta.exe process contacted an attacker-controlled URL and retrieved a second-stage payload. Persistence artifacts were then prepared (RunMRU activity was observed shortly afterward). |
| 09:23:20 | Initial Access / Execution | The malicious second stage executed through mshta.exe, establishing code execution on the device. Observed activity included suspicious command execution and user-level persistence behavior (RunMRU registry interaction). |
| 09:23:20 | Detection | Two independent Defender detection engines triggered within the same second: – Behavioral/execution-based detection flagged suspicious command activity (RunMRU abuse). – The correlation engine identified the activity pattern as malicious and consistent with real attack behavior (not benign tooling usage). |
| 09:25:02 | Disruption decision | The disruption pipeline correlated the alerts, evaluated the threat model (single endpoint, no lateral movement signs, malicious code already executing under user context), and selected device isolation as the action most likely to immediately contain the attack. |
| 09:25:16 | Playbook start | Defender autonomously initiated the IsolateDevice response playbook – the same containment action a SOC analyst would trigger manually – with full audit logging and a built-in auto-release mechanism to prevent prolonged business impact. |
| 09:25:28 | Device isolated | The IsolateDevice action completed successfully. The endpoint was cut off from all external and internal network communication, allowing only Defender management traffic. Communication with attacker-controlled infrastructure was immediately terminated. |
| 09:25 – onward | Post-isolation | No additional malicious activity was observed. The mshta-launched payload was unable to continue execution, retrieve additional stages, or establish persistence. With no lateral movement or follow-on activity, the incident remained fully contained to a single endpoint. The SOC inherits a contained incident. |
Total time from first detection to enforced isolation: 128 seconds.
The results
To summarize the results of the new device isolation response action:
- From first detection, Defender isolated the device in just 128 seconds.
- No second-stage payloads were observed after isolation. The mshta process was orphaned at the network layer; there was no outbound C2, and no follow-on download.
- No lateral movement attempts were observed before or after isolation.
- No SOC actions were required during the disruption window. The QNET SOC analyst who picked up the incident inherited an already-contained host and a complete action timeline.
MITRE ATT&CK techniques observed
| Tactic | Technique ID | Technique name | Observed details |
| Initial Access / Execution | T1204.002 | User Execution: Malicious File | User opened a malicious file delivered via browser download or email, resulting in execution of mshta.exe at approximately 09:23:20 UTC on device a3198469…b13. |
| Defense Evasion | T1218.005 | System Binary Proxy Execution: Mshta | Signed Microsoft binary mshta.exe was abused to proxy execution of attacker-controlled HTA/script content and evade application trust controls. |
| Command and Control | T1071.001 | Application Layer Protocol: Web Protocols | mshta.exe initiated outbound HTTP/HTTPS communication to attacker-controlled infrastructure to retrieve a second-stage payload. |
| Execution | T1059 | Command and Scripting Interpreter | HTA-delivered script content executed through the mshta.exe host process, enabling attacker-controlled command execution in user context. |
| Persistence | T1112 | Modify Registry | Suspicious RunMRU-related registry interaction indicated attempted user-level persistence preparation. |
| Discovery / Execution | T1057 | Process Discovery | Defender behavioral detections observed suspicious command activity consistent with attacker reconnaissance and execution staging immediately after payload launch. |
| Impact Mitigation (Defender response) | – | Device Isolation (Defender Automatic Attack Disruption) | Defender correlated multiple high-confidence detections and autonomously executed the IsolateDevice response action at 09:25:16 UTC, completing isolation by 09:25:28 UTC. |
| Command and Control (Prevented) | T1105 | Ingress Tool Transfer | Isolation interrupted outbound connectivity before additional payload stages or tooling could be retrieved from attacker infrastructure. |
| Lateral Movement (Prevented) | TA0008 | Lateral Movement | No evidence of lateral movement activity was observed before containment; device isolation prevented any subsequent propagation opportunities. |
| Persistence (Prevented) | TA0003 | Persistence | After isolation, no additional persistence artifacts or follow-on malicious processes were observed on the endpoint. |
References
- Automatic attack disruption in Microsoft Defender XDR
- Automatic attack disruption — supported triggers and enforced actions
- Device Isolation in Attack Disruption
- MITRE ATT&CK T1218.005 — Mshta
- MITRE ATT&CK T1204 — User Execution
Learn more
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
- Learn more about securing Copilot Studio agents with Microsoft Defender
- Evaluate your AI readiness with our latest Zero Trust for AI workshop.
- Microsoft 365 Copilot AI security documentation
- How Microsoft discovers and mitigates evolving attacks against AI guardrails
The post 128 Seconds to disruption: Microsoft Defender stops ransomware at QNET appeared first on Microsoft Security Blog.