# Ransomware Attack on QNET Disrupted by Microsoft Defender Automatic Device Isolation in 128 Seconds — mshta.exe LOLBin, Web Protocol C2, and RunMRU Persistence Kill Chain Autonomously Contained

> Microsoft Defender for Endpoint's automatic attack disruption autonomously isolated a compromised QNET endpoint within 128 seconds of detection, blocking an in-progress ransomware attack. The attack chain leveraged a malicious file (likely email-delivered or browser-downloaded) to execute mshta.exe (T1218.005) as a proxy execution LOLBin, contacting attacker-controlled infrastructure via HTTP/HTTPS web protocols (T1071.001) to retrieve a second-stage payload, with RunMRU registry persistence (T1112) prepared for user-level foothold. Microsoft Defender's behavioral/execution-based detection engine and correlation engine fired simultaneously at 09:23:20 UTC; the AI-driven disruption pipeline evaluated the threat model and autonomously executed the IsolateDevice response playbook by 09:25:16 UTC, completing isolation at 09:25:28 UTC. No additional malicious activity, lateral movement, or SOC intervention was required during the containment window, marking the first public case study of Microsoft Defender's new device isolation autonomous response capability.

- **Published:** 2026-08-04T00:00:00Z
- **Last reviewed:** 2026-08-04T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1869
- **ID:** TL-2026-1869
- **Severity:** HIGH
- **Category:** RANSOMWARE
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 3 (full data via the Threadlinqs MCP server — Purple tier)

## Description

On August 4, 2026, Microsoft Security Research published a detailed case study (authored by David Shiran and Ayelet Artzi) documenting a real-world ransomware attack against QNET (QI Group), a global direct-selling enterprise with a distributed workforce and lean SOC. The incident, which took place prior to publication, represents the first public documentation of Microsoft Defender for Endpoint's new device isolation capability within the Automatic Attack Disruption pipeline — an autonomous response action that extends endpoint protection from detection to active containment without SOC intervention.

The attack chain began with a user opening a malicious file, most likely delivered via phishing email or drive-by browser download. The file executed mshta.exe, a digitally signed Microsoft binary designed to execute HTML Applications (HTA files). mshta.exe is a well-documented Living Off the Land Binary (LOLBin) corresponding to MITRE ATT&CK T1218.005, frequently abused by adversaries because trusted Microsoft-signed binaries can bypass application whitelisting, security policy controls, and traditional signature-based detection. The abused mshta.exe instance initiated outbound HTTP/HTTPS communication to attacker-controlled infrastructure (T1071.001) to retrieve a second-stage payload, establishing command execution through HTA-delivered script content (T1059). Concurrently, suspicious RunMRU registry interaction was observed (T1112), indicating the attacker's intent to establish user-level persistence via the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU registry key — a forensic artifact of commands executed through the Windows Run dialog (Win+R). This pattern is consistent with ClickFix / FakeCAPTCHA social engineering campaigns widely documented in 2025-2026, where victims are socially engineered to paste mshta.exe or PowerShell commands into the Run dialog, with the full command string recorded in cleartext within RunMRU. Process discovery activity (T1057) consistent with attacker reconnaissance and execution staging was detected immediately following payload launch.

At 09:23:20 UTC, two independent Microsoft Defender detection engines triggered simultaneously: the behavioral/execution-based detection engine flagged the suspicious command activity and RunMRU registry abuse, while the correlation engine identified the activity pattern as malicious and consistent with real attack behavior rather than benign tooling usage. The attack disruption pipeline — an ensemble of AI models including graph models for entity relationship mapping, boosted decision trees for classification, neural networks for pattern recognition, and small language models (SLMs) for contextual understanding — correlated these alerts within 102 seconds. At 09:25:02 UTC, the pipeline evaluated the threat model (single endpoint compromise, no lateral movement signs, malicious code executing under user context) and selected device isolation as the most appropriate containment action. At 09:25:16 UTC, 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. Device isolation completed at 09:25:28 UTC, cutting the endpoint off from all external and internal network communication while maintaining connectivity to Microsoft Defender for Endpoint cloud services for continued monitoring and remediation.

The 128-second window from first detection to enforced isolation interrupted the attack at a critical juncture: the second-stage payload had been retrieved but before additional payload stages, tooling, or ransomware execution could proceed. The mshta-launched payload was orphaned at the network layer with C2 communication immediately terminated. No further outbound C2, follow-on downloads, lateral movement attempts, credential theft, data exfiltration, or ransomware encryption were observed before or after isolation. The QNET SOC analyst inherited an already-contained host with a complete action timeline, shifting their role from emergency response to root-cause investigation and remediation. Microsoft's approach emphasizes that device isolation and user containment work as complementary layers: blocking only the user leaves the infected machine active; isolating only the machine allows attackers with compromised identities to continue; together, each compensates for the other's weakness.

QNET/QI Group has been a repeated target of cyberattacks. In February-March 2024, the Play ransomware group (PlayCrypt) claimed responsibility for an attack against QI Group Canada, exfiltrating sensitive data including client documents, financial records, payroll information, and tax records under a double-extortion model. After an ultimatum deadline of March 15, 2024, the threat actors released hundreds of internal documents on their Tor-based dark web leak site. QNET has also suffered near-weekly DDoS attacks (including a 2011 attack taking their e-commerce portal offline for over 36 hours), a July 2020 web shell attack on a critical web server detected by Microsoft Defender for Endpoint, and persistent credential-based intrusion attempts from compromised distributor accounts. Since these incidents, QNET has invested heavily in Microsoft security infrastructure, migrating to Microsoft 365 E5, Azure, and a full Microsoft security stack including Defender for Endpoint, Defender for Identity, Microsoft Sentinel, Microsoft Entra ID, and Microsoft Copilot for Security, achieving a 60% improvement in security response efficiency.

## MITRE ATT&CK

- T1566 Phishing
- T1204 User Execution
- T1218 System Binary Proxy Execution
- T1059 Command and Scripting Interpreter
- T1071 Application Layer Protocol
- T1112 Modify Registry
- T1547 Boot or Logon Autostart Execution
- T1057 Process Discovery
- T1490 Inhibit System Recovery

## Sources

- [128 Seconds to disruption: Microsoft Defender stops ransomware at QNET](https://www.microsoft.com/en-us/security/blog/2026/08/04/129-seconds-disruption-microsoft-defender-stops-ransomware-qnet/)
- [Automatic attack disruption in Microsoft Defender XDR](https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption)
- [Microsoft Defender's AI-Powered Defense: How Automatic Device Isolation Stopped a Cyberattack in 128 Seconds](https://undercodenews.com/microsoft-defenders-ai-powered-defense-strikes-back-how-automatic-device-isolation-stopped-a-cyberattack-in-just-128-seconds/)
- [MITRE ATT&CK — System Binary Proxy Execution: Mshta (T1218.005)](https://attack.mitre.org/techniques/T1218/005/)
- [MITRE ATT&CK — User Execution: Malicious File (T1204.002)](https://attack.mitre.org/techniques/T1204/002/)
- [MITRE ATT&CK — Application Layer Protocol: Web Protocols (T1071.001)](https://attack.mitre.org/techniques/T1071/001/)
- [Automatic Attack Disruption: Enhanced Containment for Critical Assets and Shadow IT](https://techcommunity.microsoft.com/blog/microsoftthreatprotectionblog/automatic-attack-disruption-enhanced-containment-for-critical-assets-and-shadow-/4402157)
- [Microsoft Previews Automatic Device Isolation in Defender for Endpoint](https://www.csoonline.com/article/4177345/microsoft-previews-automatic-device-isolation-in-defender-for-endpoint.html)
- [Microsoft Defender Now Automatically Isolates Compromised Devices](https://cybersecuritynews.com/defender-automatically-isolates-hacked-devices/)
- [QNET increases security response efficiency 60% with Microsoft Security](https://www.microsoft.com/en/customers/story/1797704796946869974-qnet-microsoft-copilot-for-security-retailers-en-hong-kong-sar)
- [MITRE ATT&CK — Play Ransomware Group (G1040)](https://attack.mitre.org/groups/G1040/)
- [CISA #StopRansomware: Play Ransomware (AA23-352A)](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-352a)
- [Ransomware Play Group Hits QI Group (QNET Canada — March 2024)](https://www.hookphish.com/blog/ransomware-play-group-hits-qi-group/)
- [Sigma Rule: Command Executed Via Run Dialog Box — Registry (RunMRU Detection)](https://github.com/SigmaHQ/sigma/blob/master/rules-threat-hunting/windows/registry/registry_set/registry_set_runmru_command_execution.yml)
- [ClickFix Attack Detection via RunMRU and Process Lineage (2026 Variants)](https://cyberthreatintelligence.net/post/how-to-detect-clickfix-attacks-in-2026-runmru-process-lineage-and-the-variants-breaking-your-rules)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1869