Intune Mass Device Wipe is a Living-off-the-Land (LotL) destructive attack: an adversary compromises a privileged Microsoft Entra ID account, creates or promotes a Global Administrator, then uses the Microsoft Graph API or PowerShell to loop through every MDM-enrolled device issuing remote wipe commands — factory resetting every laptop, mobile, and Windows device in the tenant within hours. No malware is deployed. No EDR alert fires. The platform executes every command exactly as designed.
Real-world precedent: In March 2026, Iran-linked threat actor VOID MANTICORE (Handala) used this exact method against Stryker Corporation, wiping approximately 80,000 devices across 79 countries in a 3-hour window between 05:00–08:00 UTC. The attacker compromised an admin account, created a new Global Admin, and issued wipe commands via Graph API — no custom malware, no exploit. This SOP is the detection, containment, and hardening playbook.
◈ Table of Contents
01
Background
CONTEXT
B1
Attack Phases & MITRE Mapping
| Phase | MITRE ATT&CK | Signal | Severity |
|---|---|---|---|
| Admin credential compromise (Phishing / AiTM) | T1566 (Phishing), T1557 (AiTM Proxy) | Entra ID sign-in from unfamiliar IP / ASN; MFA fatigue alerts; token replay from new device | CRITICAL |
| Global Admin / Intune Admin role assignment | T1098.003 (Additional Cloud Credentials), T1078.004 (Cloud Accounts) | New Intune/Global Admin role assignment in Entra audit log; PIM activation outside business hours | CRITICAL |
| Graph API OAuth app creation / consent | T1550.001 (Application Access Token), T1136.003 (Cloud Account) | New service principal registered; Graph API DeviceManagementManagedDevices.ReadWrite.All permission granted | CRITICAL |
| Bulk remote wipe via Graph API / PowerShell | T1485 (Data Destruction), T1072 (Software Deployment Tools) | Intune audit log: surge of "Wipe ManagedDevice" actions in minutes; operator = attacker UPN or service principal | CRITICAL |
| Post-wipe persistence / data exfil (optional) | T1530 (Cloud Storage), T1005 (Data from Local System) | SharePoint / OneDrive mass download before wipe; Exchange forwarding rule created | HIGH |
B2
Required Admin Permissions for Mass Wipe
| Role / Permission | Wipe Capability | Risk Level |
|---|---|---|
| Global Administrator | Full — all devices, all actions via GUI + Graph API | CRITICAL |
| Intune Administrator (Entra built-in) | Full — all Intune device actions | CRITICAL |
| Custom Intune RBAC role with Wipe permission | Scoped — depends on RBAC scope assignment | HIGH |
| Graph API: DeviceManagementManagedDevices.ReadWrite.All | Full programmatic wipe via API/PowerShell | CRITICAL |
| Graph API: DeviceManagementManagedDevices.PrivilegedOperations.All | Wipe, retire, reset passcode | CRITICAL |
The Stryker attack ran entirely via Graph API + PowerShell, NOT the Intune GUI — because the GUI applies a 5-device practical limit by design, but the Graph API has no documented limit. A single loop script can wipe an entire tenant of 200,000 devices sequentially without any additional verification or approval gate unless Multi-Admin Approval is explicitly enabled.
02
Identification
INVESTIGATEIntune Mass Wipe — Investigation Workflow
I1
Detect Bulk Wipe Activity — Intune Audit Logs
KQL
KQL — Sentinel: Detect mass wipe event (>10 wipes in 60 min)
IntuneAuditLogs
| where TimeGenerated > ago(7d)
| where OperationName contains "Wipe" or OperationName contains "wipe"
| extend Actor = tostring(parse_json(Properties).Actor.UPN)
| extend DeviceId = tostring(parse_json(Properties).TargetObjectIds[0])
| summarize WipeCount = count(), Devices = make_set(DeviceId, 500) by bin(TimeGenerated, 60m), Actor
| where WipeCount > 10
| project TimeGenerated, Actor, WipeCount, Devices
| order by WipeCount desc
KQL — Detect new Intune/Global Admin role assignment (last 72h)
AuditLogs
| where TimeGenerated > ago(72h)
| where OperationName in ("Add member to role", "Add eligible member to role")
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| extend RoleName = tostring(TargetResources[0].displayName)
| extend InitiatorUPN = tostring(InitiatedBy.user.userPrincipalName)
| where RoleName in (
"Global Administrator",
"Intune Administrator",
"Cloud Device Administrator"
)
| project TimeGenerated, OperationName, RoleName, TargetUPN, InitiatorUPN, Result
| order by TimeGenerated desc
KQL — Graph API wipe via service principal (non-human actor)
IntuneAuditLogs
| where TimeGenerated > ago(7d)
| where OperationName contains "Wipe"
| extend Actor = tostring(parse_json(Properties).Actor.UPN)
| extend AppId = tostring(parse_json(Properties).Actor.ApplicationId)
| where isnotempty(AppId) and Actor !contains "@" // service principal, not human
| project TimeGenerated, Actor, AppId, OperationName
| order by TimeGenerated desc
If Intune audit logs are NOT ingested into Sentinel, you have zero real-time detection capability for this attack class. Logs only exist in the Intune portal with 30-day retention by default. Enable Diagnostic Settings → Log Analytics workspace for IntuneAuditLogs immediately — this is your only detection layer for a mass wipe event.
I2
Identify Compromised Account & Entry Point
URGENT
- 1Pull Entra sign-in logs for the actor UPN: Look for sign-ins from unfamiliar IPs, new countries, ASNs associated with VPNs / proxies / Tor, or impossible travel (same account logging in from two geographies minutes apart).
- 2Check for AiTM token replay: In Entra sign-in logs look for
tokenIssuedAtpredating the sign-in timestamp or a session that originated from a known phishing proxy ASN. - 3Identify the newly created Global Admin account: Query AuditLogs for any account created and immediately assigned Global Administrator or Intune Administrator within the same 24-hour window.
- 4Check for OAuth app / service principal registration: Graph API bulk wipe requires an app registration with DeviceManagementManagedDevices.ReadWrite.All consent. Enumerate any app registrations created in the past 7 days.
- 5Determine the initial access vector: Phishing email in mailbox? AiTM proxy (check for Evilginx / Modlishka IOCs)? Compromised VPN credential? Insider threat? This determines remediation scope.
KQL — New service principal with Intune write permissions
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Add app role assignment to service principal"
| extend AppRole = tostring(TargetResources[0].displayName)
| extend SPName = tostring(TargetResources[1].displayName)
| where AppRole in (
"DeviceManagementManagedDevices.ReadWrite.All",
"DeviceManagementManagedDevices.PrivilegedOperations.All",
"DeviceManagementConfiguration.ReadWrite.All"
)
| project TimeGenerated, OperationName, AppRole, SPName
| order by TimeGenerated desc
I3
Scope — Devices Wiped vs. Still Online
| Check | Where to Look | Output |
|---|---|---|
| Total enrolled devices at time of attack | Intune → Devices → All Devices (export CSV before any sync) | Baseline device count |
| Devices wiped (Intune audit log) | IntuneAuditLogs: OperationName = "Wipe ManagedDevice" | List of DeviceId + timestamp |
| Devices still checking in | Intune → Devices → filter LastContactDateTime < 4h ago | Surviving managed devices |
| Business-critical systems wiped | Cross-reference wiped DeviceId list with CMDB / device owner data | Impact priority list for recovery |
| Data exfil pre-wipe | CloudAppEvents / OfficeActivity: SharePoint / OneDrive mass download in same window | Possible data breach scope |
Devices that were offline / powered off at the time of the attack may still receive the wipe command when they next connect to MDM. Immediately place those devices in a restricted Entra CA policy blocking Intune MDM access until the attacker's access is fully revoked and the environment is re-secured.
03
Containment
STOP IT
C1
Immediate Session & Credential Revocation
Immediate
- 1Revoke all refresh tokens for the compromised account: Entra ID → Users → [actor UPN] → Revoke sessions. Also run
Revoke-MgUserSignInSession -UserId [UPN]via Graph PowerShell for immediate effect. - 2Disable the rogue Global Admin account: Entra ID → Users → [rogue account] → Block sign-in. Do NOT delete immediately — preserve for forensics.
- 3Remove all rogue role assignments: Entra ID → Roles → Global Administrator / Intune Administrator → remove any accounts created or assigned during the attack window.
- 4Delete rogue service principals and app registrations: Azure AD → App Registrations → filter by Created date → remove any apps created during attack window with Intune API permissions.
- 5Force MFA re-registration for all remaining admin accounts before re-enabling access.
PowerShell — Revoke all sessions for compromised UPN
Connect-MgGraph -Scopes "User.ReadWrite.All"
$userId = (Get-MgUser -Filter "UserPrincipalName eq '[email protected]'").Id
Revoke-MgUserSignInSession -UserId $userId
# Verify
Get-MgUserAuthenticationMethod -UserId $userId | Format-List
Token revocation in Entra ID takes up to 1 hour to fully propagate across all Microsoft services by default. If Continuous Access Evaluation (CAE) is NOT enabled, the attacker's existing access token may remain valid for its full lifetime (up to 1 hour) even after revocation. Enable CAE immediately — it reduces token lifetime and forces re-evaluation on policy change.
C2
Stop In-Progress Wipes — Conditional Access Emergency
- 1Create an emergency Conditional Access policy: Block all access to Microsoft Intune (App ID: 0000000a-0000-0000-c000-000000000000) and Microsoft Graph (App ID: 00000003-0000-0000-c000-000000000000) for all users EXCEPT named break-glass accounts.
- 2Enable the policy in Report-Only first to verify it does not block break-glass, then switch to Enforce. This gives a 5-10 minute window to validate.
- 3Devices already wiped cannot be un-wiped — focus is on halting the queue. Any device that has not yet checked in and received the wipe command is potentially saveable via this block.
- 4Contact Microsoft Support (P1 severity) if wipe queue cannot be stopped — Microsoft may have backend tooling to cancel queued MDM commands at the tenant level.
04
Eradication
CLEAN UP
E1
Tenant Environment Clean-up
- 1Full admin credential reset: Reset passwords and re-register MFA for ALL privileged accounts (Global Admin, Intune Admin, Security Admin, Exchange Admin). Do not reset in the compromised context — use break-glass or a separate clean device.
- 2Audit and clean all service principals: Export all app registrations and service principals. Remove any created during or before the attack window that have Intune or privileged Graph API permissions that cannot be verified as legitimate.
- 3Audit conditional access, named locations, and trusted IPs: Attackers may have pre-staged CA bypasses (added attacker IP to Named Locations, created CA exclusions) to ensure persistent access.
- 4Audit Exchange transport rules and inbox rules: Common post-compromise persistence — forwarding rules exfiltrating email. Check all admin and privileged mailboxes.
- 5Rebuild Intune configuration from backup / IaC: Do not attempt to reconstruct MDM policy manually. Export existing Intune config via
IntuneManagementtool or Graph API export before re-enrolling devices.
Eradication Complete When
- All rogue accounts disabled and removed; audit log confirms no residual role assignments
- All rogue service principals and OAuth app registrations removed
- All admin credentials reset; phishing-resistant MFA re-registered on clean devices
- No attacker persistence found in CA policies, Named Locations, mail rules, or federation settings
- Forensic log export complete and preserved (Entra sign-in, Intune audit, CloudAppEvents)
E2
Device Recovery Strategy
| Device Type | Recovery Path | Priority |
|---|---|---|
| Windows endpoints (Autopilot enrolled) | Re-image from Windows Autopilot reset or fresh OS install; re-enrol via Autopilot profile; user data recovery from OneDrive / backup if available | CRITICAL |
| iOS / macOS (ADE enrolled) | Apple Configurator or ADE re-enrolment; iCloud data may partially recover user data | HIGH |
| Android (Android Enterprise) | Factory reset + re-enrol via Work Profile; data loss dependent on backup policy | HIGH |
| Servers / VMs managed via Intune | Restore from Azure Backup / snapshot pre-wipe event; verify snapshot integrity timestamp | CRITICAL |
| Devices offline at time of wipe (saveable) | Remove from Intune management scope before reconnecting to network; manually re-enrol post-cleanup | MEDIUM |
05
Hardening
PREVENT RECURRENCE
H1
Identity & Access Hardening
Priority
- 1Enable Privileged Identity Management (PIM) for Global Administrator, Intune Administrator, and Cloud Device Administrator roles. All assignments must be time-bound Just-in-Time (JIT) — no standing persistent admin roles. Require approval + MFA for activation.
- 2Enforce phishing-resistant MFA for all admin account sign-ins via Conditional Access: require FIDO2 security keys or Windows Hello for Business. Standard TOTP / SMS MFA is bypassable via AiTM proxy attacks (as used in the Stryker attack).
- 3Restrict admin portal access to compliant managed devices only: CA policy targeting Microsoft Admin Portals and Intune → require compliant device + specific Named Location (corporate network / PAW subnet).
- 4Reduce Global Admin count to 2–4 accounts maximum (Microsoft's recommendation). Enumerate all current Global Admin assignments — most organisations have far more than needed.
- 5Use dedicated Privileged Access Workstations (PAWs) for all Intune and Entra administrative actions. PAWs must be separate devices — not regular workstations used for email and browsing.
H2
Intune RBAC & Multi-Admin Approval
- 1Enable Multi-Admin Approval in Intune for destructive actions: Intune → Tenant Administration → Multi Admin Approval → create an access policy requiring a second approver for
Wipe,Retire,Delete, andReset Passcodeoperations. This is the single most effective control against mass wipe abuse. - 2Remove the Wipe permission from all custom RBAC roles that don't absolutely require it. Create a scoped "Help Desk" RBAC role that can retire / sync devices but cannot wipe. Reserve Wipe to a separate break-glass RBAC role requiring PIM activation.
- 3Scope all Intune RBAC roles to specific device groups / scope tags — prevent any single role from having tenant-wide device scope unless explicitly required.
- 4Do NOT enrol personal devices with Full Device Wipe capability: For iOS use User Enrolment (not ADE) on personal devices — it only wipes the managed work partition. For Android use Work Profile mode, not Device Owner mode.
Multi-Admin Approval (MAA) applies to the Intune GUI only — it does NOT apply to Graph API calls by default. To enforce MAA for API-driven actions, combine it with a Conditional Access policy that blocks service principal access to the Intune API except from approved, managed identities with Managed Identity authentication.
H3
Detection & Alerting — Sentinel Rules
Sentinel Scheduled Analytics Rule — Mass Wipe Alert
// Analytics Rule: Intune Mass Device Wipe Detection
// Run every 5 minutes, lookback 1 hour, threshold: 10 wipes
IntuneAuditLogs
| where TimeGenerated > ago(1h)
| where OperationName contains "Wipe"
| extend Actor = tostring(parse_json(Properties).Actor.UPN)
| summarize WipeCount = count() by Actor, bin(TimeGenerated, 10m)
| where WipeCount >= 10
| extend AlertSeverity = "High"
| extend AlertDescription = strcat(
"MASS WIPE DETECTED: ", tostring(WipeCount),
" devices wiped by ", Actor,
" in 10-minute window"
)
| project TimeGenerated, Actor, WipeCount, AlertSeverity, AlertDescription
Sentinel Scheduled Rule — New Privileged Role Assignment
// Analytics Rule: Intune/Global Admin Role Assignment
// Run every 15 minutes
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName in~ ("Add member to role", "Add eligible member to role")
| extend RoleName = tostring(TargetResources[0].displayName)
| extend TargetUPN = tostring(TargetResources[0].userPrincipalName)
| extend InitiatorUPN = tostring(InitiatedBy.user.userPrincipalName)
| where RoleName in (
"Global Administrator",
"Intune Administrator",
"Cloud Device Administrator",
"Privileged Role Administrator"
)
| project TimeGenerated, RoleName, TargetUPN, InitiatorUPN, Result
06
Escalation
TIERS
ESC1
Escalation Tiers & Handoff Bundle
| Tier | Trigger | Action / Handoff Bundle |
|---|---|---|
| L1 → L2 | >10 wipe events in Intune audit within 60 minutes OR new Global Admin account created unexpectedly | Intune audit export, actor UPN, device count wiped vs total enrolled, Entra sign-in log for actor |
| L2 → IR + Identity Team | Actor is unrecognised OR sign-in from unusual geography/ASN OR rogue service principal found | Confirmed rogue accounts list, all revocation actions taken, surviving device list, attack timeline |
| IR → CISO + Legal + Comms | Confirmed mass wipe event affecting >10% of fleet OR evidence of data exfil pre-wipe | Business impact brief, BCP activation status, regulatory notification obligations (Privacy Act, GDPR), customer comms draft |
| External | Nation-state attribution indicators, criminal ransomware-as-a-service involvement, or attack exceeds internal IR capability | Microsoft DART engagement (CSS P1 ticket), CISA / sector ISAC notification, qualified external IR firm, NZ CERT (cert.govt.nz) notification |
Authorized security research & penetration testing only. Unauthorized use is illegal. Authored by Rudra Verma | Senior Security Architect | CyberHawk Threat Intel.
Threat intelligence references: VOID MANTICORE / Handala (Iran MOIS) — Stryker attack March 2026. MITRE ATT&CK T1485, T1072, T1098.003, T1078.004, T1550.001.