Intune as a Weapon
Detecting Mass Device Wipe Attacks
How the Handala threat group turned Microsoft's own device management platform into a kill switch — wiping tens of thousands of corporate devices at Stryker — and how to detect this in Microsoft Sentinel before the damage compounds.
Executive Summary
The Stryker attack demonstrates that Microsoft Intune — a tool trusted by over 300 million managed devices globally — can be turned into an enterprise-scale kill switch with nothing more than a compromised administrator account. No malware. No exploits. Just legitimate admin tooling.
On March 11, 2026, employees at Stryker Corporation — one of the world's largest medical technology companies — arrived at work to find their devices blank. Login screens had been replaced with the logo of a barefoot boy holding a slingshot: the trademark of Handala, an Iranian state-linked hacktivist group operated by Iran's Ministry of Intelligence and Security (MOIS).
The attackers had compromised a Windows domain administrator account, used it to create a new Global Administrator account in Entra ID, authenticated to the Microsoft Intune console, and issued enterprise-wide remote wipe commands. Approximately 80,000 devices across 79 countries were wiped in roughly three hours. Corporate laptops, Windows workstations, iPads, iPhones — and personal BYOD devices enrolled in Stryker's MDM — were all factory reset. For BYOD devices this meant photos, banking apps, eSIMs, and personal authenticator tokens were also destroyed.
This report covers the attack timeline, threat actor profile, full attack chain, MITRE ATT&CK mapping, and — critically — a production-ready Microsoft Sentinel KQL detection rule that uses per-actor statistical deviation to catch this class of attack without hardcoded thresholds, making it safe for multi-tenant deployment.
What Happened: The Stryker Attack
Stryker Corporation is a Michigan-based medical technology company with approximately 56,000 employees and $25.1 billion in revenue for 2025. Its products — surgical equipment, implants, and patient monitoring systems — are used in over 150 million patient procedures annually. The scale of the IT disruption, and the knock-on effect on healthcare delivery, made this one of the most consequential enterprise cyberattacks of 2026.
~05:00–08:00 ET
Morning
Stryker's BYOD programme enrolled personal devices in Intune to access corporate email. This placed personal phones in scope of the wipe command — destroying personal photos, eSIMs, and banking authenticators alongside corporate data. This was not a Stryker-specific failure; any organisation running BYOD on Intune shares this exposure.
Threat Actor Profile: Handala / Void Manticore
| Attribute | Detail |
|---|---|
| Primary Name | Handala / Handala Hack Team |
| Also Known As | Void Manticore, Storm-0842, Hatef, Hamsa, Banished Kitten, Red Sandstorm, Dune, Karma, Homeland Justice |
| Attribution | Iran Ministry of Intelligence and Security (MOIS) — assessed with high confidence by multiple vendors; formally attributed by US DOJ March 2026 |
| First Observed | December 2023, following October 7 attacks |
| Primary Targets | Israeli organisations, Gulf state entities, US critical infrastructure (expanded 2025–2026) |
| Motivations | Ideological disruption, psychological operations, intelligence collection — not financially motivated |
| Known Operations | Operation Epic Fury (Stryker, Mar 2026), Homeland Justice (Albania gov 2022–2024), Israeli infrastructure campaigns, Kindergarten PA system hijack (Jan 2026), FBI Director email breach claim (Mar 2026) |
| Sponsor | MOIS dual-actor handoff model — MOIS runs long-dwell espionage operations; Handala is used as the destructive/psyop persona |
Handala presents itself as an independent pro-Palestinian hacktivist collective, deliberately borrowing the imagery of a beloved political cartoon as ideological cover. The operational reality is considerably more structured. The group follows a documented MOIS dual-actor model: long-dwell espionage actors establish persistence and exfiltrate data; the Handala persona is then used to execute the destructive phase and claim public credit for psychological effect.
The TTPs associated with Void Manticore/Handala remained largely consistent from 2024 through 2026 — manual, hands-on operations using off-the-shelf tools and publicly available deletion utilities. The Stryker attack is a notable evolution: rather than deploying custom wiper malware, the group abused legitimate enterprise management tooling entirely, lowering the technical barrier to a devastating outcome.
Attack Chain Breakdown
The Stryker attack chain has no custom malware at any stage. Every step used either stolen credentials or legitimate Microsoft administrative tooling. This is what makes it both devastating and difficult to detect with traditional IOC-based approaches.
| Stage | Action | Method | Notes |
|---|---|---|---|
| 1. Initial Access | Credential compromise of Windows domain admin | AiTM phishing (suspected) or infostealer credential harvest | Standard MFA does not protect against AiTM — victim completes real MFA challenge; attacker captures the session token |
| 2. Privilege Escalation | New Global Administrator account created | Entra ID account creation using compromised admin session | Attacker-controlled account with full tenant admin rights — ensures persistence even if original account is remediated |
| 3. Pre-positioning | Reconnaissance of Intune device inventory | Intune admin console — native Microsoft portal | Handala logo appearing on wiped login pages confirms this was staged in advance — not executed in a single session |
| 4. Data Exfiltration | ~50TB data stolen (claimed) | Access to corporate data stores via Global Admin rights | Claimed but not independently verified at time of writing |
| 5. Impact | Enterprise-wide remote wipe via Intune | Native wipe ManagedDevice command via Intune console | ~80,000 devices in ~3 hours. No malware deployed. BYOD devices included. |
| 6. Psychological Op | Login screen defacement with Handala logo | Pre-staged via Intune configuration profile or device lock screen policy | Confirms dwell time preceded the wipe execution — cannot be done in a single session |
In an adversary-in-the-middle phishing attack, the victim completes a real MFA challenge against the real Microsoft login page. The attacker's proxy sits between the victim and Microsoft, capturing the authenticated session token after MFA succeeds. The attacker then replays that token to authenticate as the victim — MFA was satisfied, so Microsoft sees a legitimate session. SMS OTPs, push notifications, and authenticator app codes are all equally vulnerable. Only phishing-resistant MFA (FIDO2 hardware keys, Windows Hello for Business, or certificate-based authentication) is effective against AiTM.
MITRE ATT&CK Mapping
| Tactic | Technique | ID | Observed Behaviour |
|---|---|---|---|
| Initial Access | Valid Accounts: Cloud Accounts | T1078.004 | Compromised Entra ID admin account used for initial authentication |
| Initial Access | Phishing: Spearphishing via Service | T1566.003 | AiTM phishing suspected as initial credential theft vector |
| Persistence | Account Manipulation: Additional Cloud Roles | T1098.003 | New Global Administrator account created — attacker-controlled backdoor account |
| Persistence | Account Manipulation | T1098 | Entra ID account modification to elevate attacker-controlled identity |
| Discovery | Cloud Infrastructure Discovery | T1580 | Intune device inventory enumerated to identify wipe targets across 79 countries |
| Collection | Data from Cloud Storage | T1530 | ~50TB data claimed exfiltrated via Global Admin access to corporate data stores |
| Impact | Data Destruction | T1485 | Remote wipe permanently erased data on ~80,000 corporate and BYOD devices |
| Impact | Service Stop | T1489 | Wiped devices rendered inoperable — global operational disruption across supply chain, ordering, and manufacturing systems |
| Impact | Defacement: Internal Defacement | T1491.001 | Login screens replaced with Handala logo — psychological operation component |
Indicators of Compromise
The Stryker attack used no custom malware — it operated entirely through legitimate Microsoft administrative tooling. As a result, traditional file-based or network IOCs are limited. The most reliable detection signals are behavioural: account actions, role assignments, and wipe command patterns in audit logs rather than hashes or IPs.
| Type | Indicator | Context | Confidence |
|---|---|---|---|
| ACTOR | Handala / Void Manticore | Responsible group — formally attributed by US DOJ to MOIS March 2026 | High |
| BEHAVIOUR | New Global Administrator account created shortly before mass wipe | Core TTP — attacker creates backdoor admin before executing wipe. Query: Entra ID AuditLogs for Add member to role + Global Administrator | High |
| BEHAVIOUR | Bulk wipe ManagedDevice commands from single actor in compressed window | Primary detection signal — see KQL in §06 | High |
| BEHAVIOUR | Admin account sign-in from anomalous geography immediately before wipe window | AiTM sessions frequently originate from attacker-controlled infrastructure — different country/ASN to the legitimate admin's baseline | Medium |
| BEHAVIOUR | Intune device lock screen or wallpaper configuration pushed at scale before wipe | Handala logo appeared on wiped login screens — pre-staged via Intune configuration profile during dwell period | Medium |
| BEHAVIOUR | MFA method registration change on admin account before wipe window | Attacker may register their own authenticator after gaining account access — visible in Entra ID AuditLogs | Medium |
| BEHAVIOUR | OAuth app consent grant to unfamiliar application | AiTM and Device Code Flow attacks often involve OAuth token abuse — look for unexpected Consent to application events near the wipe window | Medium |
| PERSONA | Handala logo / barefoot boy with slingshot imagery | Used as login screen defacement — visible evidence of the psychological operation component | High |
Given the absence of traditional malware IOCs, defenders should prioritise behavioural detection over signature-based approaches for this threat class. The KQL detection in §06 is designed specifically for this constraint.
Detection: Microsoft Sentinel KQL
The detection below is production-ready for Microsoft Sentinel as a scheduled analytics rule. It does not use hardcoded device count thresholds — instead it builds a statistical baseline from each actor's own 30-day wipe history and fires when today's activity is a statistically significant outlier. This makes it safe to deploy across multiple tenants of different sizes without tuning.
AND TodayCount >= 10
AND ZScore >= 3.0
AND TodayCount >= 5
AND DeviationVsPeak >= 3.0
AND TodayCount >= 10
AND TodayCount >= 15
// STAGE 1 — Per-actor historical baseline (ago(14d) to ago(24h)) // Zero-wipe days excluded by design — keeps mean/stdev honest let HistoricalDailyWipes = IntuneAuditLogs | where TimeGenerated between (ago(14d) .. ago(24h)) | where OperationName in~ ("wipe ManagedDevice", "Delete ManagedDevice") // TUNING: Add/remove OperationName values to match your tenant | extend ActorUPN = tostring(todynamic(Properties).Actor.UPN) | where isnotempty(ActorUPN) and ActorUPN !in~ ("unknown", "system", "") // TUNING: Add service account UPNs to exclusion list if expected to wipe at scale | summarize DailyCount = count() by ActorUPN, Day = bin(TimeGenerated, 1d); // STAGE 2 — Statistical profile per actor // ActiveDays = wipe-active days only (not calendar days) let ActorBaseline = HistoricalDailyWipes | summarize HistMean = round(avg(DailyCount), 2), HistStdev = round(stdev(DailyCount), 2), HistMax = max(DailyCount), ActiveDays = count(), Total30d = sum(DailyCount) by ActorUPN; // STAGE 3 — Raw wipe events in 24h detection window // Joined to IntuneDevices for owner/ownership context // arg_max ensures latest inventory record per device (no duplicate rows) let RecentWipeEvents = IntuneAuditLogs | where TimeGenerated > ago(24h) | where OperationName in~ ("wipe ManagedDevice", "Delete ManagedDevice") | extend ActorUPN = tostring(todynamic(Properties).Actor.UPN) | extend DeviceId = tostring(todynamic(Properties).TargetObjectIds[0]) | extend DeviceName = tostring(todynamic(Properties).TargetDisplayNames) | where isnotempty(ActorUPN) and ActorUPN !in~ ("unknown", "system", "") | join kind=leftouter ( IntuneDevices | summarize arg_max(TimeGenerated, *) by DeviceId | project DeviceId, InvDeviceName = DeviceName, OwnerUPN = UPN, OwnerEmail = UserEmail, DeviceOS = OS, Ownership, ManagedBy, CompliantState, JoinType ) on DeviceId; // STAGE 4 — Aggregate per actor // DeviceIds capped at 1000 (only unbounded-cardinality field) // All other make_set() fields have naturally low distinct value counts let TodayActivity = RecentWipeEvents | summarize TodayCount = count(), DeviceIds = make_set(DeviceId, 1000), DeviceNames = make_set(InvDeviceName), AffectedOwnerUPNs = make_set(OwnerUPN), AffectedOwnerEmails = make_set(OwnerEmail), OSTypes = make_set(DeviceOS), OwnershipTypes = make_set(Ownership), Operations = make_set(OperationName), FirstAction = min(TimeGenerated), LastAction = max(TimeGenerated) by ActorUPN; // STAGE 5 — Join and compute anomaly signals TodayActivity | join kind=leftouter ActorBaseline on ActorUPN // Null normalisation — new actors produce nulls on join | extend HistMean = iff(isnull(HistMean), 0.0, HistMean), HistStdev = iff(isnull(HistStdev), 0.0, HistStdev), HistMax = iff(isnull(HistMax), 0, HistMax), ActiveDays = iff(isnull(ActiveDays), 0, ActiveDays), Total30d = iff(isnull(Total30d), 0, Total30d) | extend IsNewActor = (ActiveDays == 0), // HasReliableBaseline gates Z-score — stdev unreliable below 5 active days HasReliableBaseline = (ActiveDays >= 5 and HistStdev > 0) // TUNING: Raise to 10 for tenants with many irregular/seasonal admins | extend // Z-score: std deviations above personal mean (0 when baseline unreliable) ZScore = iff(HasReliableBaseline, round((toreal(TodayCount) - HistMean) / HistStdev, 2), toreal(0)), // DeviationVsPeak: today vs personal 30d peak — Pattern C fallback DeviationVsPeak = iff(HistMax > 0, round(toreal(TodayCount) / toreal(HistMax), 2), toreal(TodayCount)), // Floored at 1 to prevent division by zero (single event = identical timestamps) ActiveWindowMins = toreal(max_of(datetime_diff('minute', LastAction, FirstAction), 1)) | extend // Burst rate suppressed for single events — meaningless with one data point WipesPerHour = iff(TodayCount > 1, round((toreal(TodayCount) / ActiveWindowMins) * 60.0, 1), toreal(0)), DeviceCount = array_length(DeviceIds) // STAGE 6 — Detection filter (four independent patterns) // All thresholds relative to actor history — multi-tenant safe | where // Pattern A: new/unknown actor, mass volume // TUNING: Raise TodayCount gate (e.g. 20) for tenants where new admins bulk-onboard (IsNewActor == true and TodayCount >= 10) // Pattern B: known actor 3σ+ above own mean (reliable baseline only) // TUNING: Raise ZScore to 4.0/5.0 to reduce sensitivity or (HasReliableBaseline == true and ZScore >= 3.0 and TodayCount >= 5) // Pattern C: thin-history fallback — peak deviation when stdev unreliable // TUNING: Raise DeviationVsPeak to 5.0 for tenants with irregular admin behaviour or (HasReliableBaseline == false and IsNewActor == false and DeviationVsPeak >= 3.0 and TodayCount >= 10) // Pattern D: burst rate — catches attacks before statistical patterns accumulate // TUNING: Raise WipesPerHour to 50 for tenants with scripted bulk lifecycle ops or (WipesPerHour >= 20.0 and TodayCount >= 15) // STAGE 7 — Severity classification // Volume and rate take precedence over statistical signals | extend Severity = case( // Volume or rate at mass-wipe scale TodayCount >= 100 or WipesPerHour >= 100, "Critical", // High volume or statistically extreme deviation TodayCount >= 50 or WipesPerHour >= 50, "High", // Confirmed statistical anomaly or sustained burst ZScore >= 5.0 or WipesPerHour >= 20, "High", // Moderate volume or Z-score at detection threshold TodayCount >= 20 or ZScore >= 3.0, "Medium", "Low") | extend AlertReason = case( // Burst rate evaluated first — Critical rate requires instant action WipesPerHour >= 100, strcat("CRITICAL burst: ", tostring(WipesPerHour), " wipes/hr"), // Pattern A: actor has zero 30d wipe history IsNewActor == true and TodayCount >= 10, strcat("First-time wiper: ", tostring(TodayCount), " devices, zero 30d history"), // Pattern B: baseline reliable, 3σ above own mean HasReliableBaseline == true and ZScore >= 3.0, strcat("Z-score +", tostring(ZScore), "σ above personal mean (", tostring(HistMean), "/day avg over ", tostring(ActiveDays), " active days)"), // Pattern C: actor exceeded personal historical peak by 3x DeviationVsPeak >= 3.0, strcat(tostring(DeviationVsPeak), "x above personal peak (historical max: ", tostring(HistMax), "/day)"), // Pattern D: time-compressed burst below critical threshold WipesPerHour >= 20.0, strcat("Burst rate: ", tostring(WipesPerHour), " wipes/hr in ", tostring(round(ActiveWindowMins, 0)), " min window"), // Multiple patterns fired simultaneously — check signal columns directly "Combined anomaly signal") | project WipeWindow_Start = FirstAction, WipeWindow_End = LastAction, ActorUPN, Severity, AlertReason, Wipes_Last24h = TodayCount, BurstRate_PerHour = WipesPerHour, ZScore_SigmaAboveMean = ZScore, PeakDeviation_Multiplier = DeviationVsPeak, Baseline_DailyMean = HistMean, Baseline_DailyPeak = HistMax, Baseline_ActiveDays_30d = ActiveDays, Baseline_IsReliable = HasReliableBaseline, IsFirstTimeWiper = IsNewActor, UniqueDevices_Affected = DeviceCount, AffectedDevice_Names = DeviceNames, DeviceOwner_UPNs = AffectedOwnerUPNs, Affected_OSTypes = OSTypes, Device_OwnershipTypes = OwnershipTypes, Intune_Operations = Operations | sort by Wipes_Last24h desc
Sentinel Rule Settings: Run every 1 hour, lookback 14 days, alert threshold greater than 0, event grouping group all events into a single alert. Entity mapping: Account → AadUserPrincipalName → ActorUPN.
Hardening Recommendations
-
01
Enforce phishing-resistant MFA for all Intune and Entra ID admin accounts FIDO2 hardware keys or Windows Hello for Business only. Standard MFA (SMS, push, TOTP) does not protect against AiTM phishing — the exact vector suspected in Stryker. Conditional Access policy should enforce this as a requirement, not an option.
-
02
Enable Multi Admin Approval (MAA) for destructive Intune actions Microsoft's MAA feature requires a second administrator's approval before high-impact actions — including device wipes — execute. CISA specifically called this out in its March 18 advisory. A single compromised account cannot unilaterally wipe your fleet if MAA is enforced.
-
03
Apply least privilege RBAC to all Intune administrator accounts Use Intune's role-based access control to assign the minimum permissions required for each admin's daily tasks. Not every Intune admin needs device wipe permissions. Scope roles to device groups and geography where possible.
-
04
Alert on new Global Administrator and Intune Administrator role assignments The core Stryker TTP was creating a new Global Admin account using the compromised session. Real-time alerting on Add member to role events for privileged roles should be a baseline detection in every tenant.
-
05
Review and restrict BYOD enrolment scope Stryker's BYOD programme placed personal devices in scope of the wipe command. Evaluate whether BYOD devices require full MDM management or whether MAM (Mobile Application Management) without device enrolment achieves the same security outcome with less blast radius.
-
06
Implement Privileged Identity Management (PIM) for admin roles Use Entra ID PIM to require just-in-time activation for Global Administrator and Intune Administrator roles. Admin accounts should not be permanently active — they should require explicit time-bound activation with justification and approval.
-
07
Monitor admin account sign-in anomalies before acting on Intune Correlate Intune audit events with SigninLogs. A wipe command from an admin who signed in from a new country 10 minutes ago is a very different risk profile to the same command from a known IP and device. The SOP in the companion detection document covers this lookup.
-
08
Maintain offline or isolated backups for critical device configurations Intune AutoPilot profiles and device configurations should be backed up and recoverable independently of the Intune tenant. In a wipe scenario, the ability to re-enrol and reconfigure at scale is the difference between days and weeks of recovery time.
CISA Guidance Summary
On March 18, 2026, CISA published an advisory directly referencing the Stryker incident and urging all US organisations to harden their endpoint management system configurations. The FBI was engaged to identify additional threats. The key directives from the advisory:
| Directive | Implementation |
|---|---|
| Use Intune RBAC to enforce least privilege | Give users minimum permissions for day-to-day tasks — restrict destructive actions to specific roles |
| Enforce phishing-resistant MFA | Apply via Conditional Access in Entra ID — not optional for privileged accounts |
| Configure Multi Admin Approval for high-impact actions | Device wipe, application deployment, scripts, and RBAC changes should all require a second approver |
| Apply Zero Trust principles | Follow Microsoft's Intune Zero Trust configuration guidance — assume breach posture for MDM infrastructure |
| Apply guidance to other endpoint management platforms | CISA stated that the same principles apply beyond Intune to any MDM/EMM platform in use |
Full advisory: CISA Alert AA26-077A — "CISA Urges Endpoint Management System Hardening After Cyberattack Against US Organization" — published March 18, 2026 at cisa.gov. Microsoft and Stryker contributed to the alert.
The broader message from CISA is one that applies far beyond Stryker: any organisation running a device management platform at scale has created a single administrative plane from which an attacker with one compromised privileged account can execute a global wipe. That administrative plane needs the same protection as your most sensitive data systems — not as an afterthought, but as a fundamental security control.
Access the Cyberhawk Threat Intelligence Platform
IOC lookups, threat actor profiles, detection rules, and investigation tools — free to sign up.
Sign Up Free →