Stryker Wiper Attack — Iran-Linked Handala Group Weaponizes Microsoft Intune to Mass-Wipe 200,000+ Devices Across 79 Countries

On March 11, 2026 at approximately 3:30 AM EST, employees at Stryker Corporation — a $23 billion medical technology giant supplying surgical equipment, implants, and hospital infrastructure to healthcare systems in over 100 countries — discovered their devices had been wiped. Laptops showed factory-reset screens. Servers were offline. Mobile phones were bricked. Login pages across the organization displayed a single image: the Handala logo.

The Iran-linked hacktivist group Handala (also tracked as Void Manticore, Storm-0842, and COBALT MYSTIQUE) claimed responsibility within hours, asserting it had wiped over 200,000 devices across 79 countries and exfiltrated 50 terabytes of critical data — all in retaliation for a missile strike that hit an Iranian school on February 28, 2026.

Stryker filed an SEC 8-K (Item 1.05) the same day, confirming a severe global disruption to its Microsoft environment. The company reported no indication of ransomware or traditional malware. That detail is the most important one in this entire incident — because it reveals that the attackers didn't need malware at all.

They used Stryker's own tools against it.

The Attack: Microsoft Intune as a Weapon

The Stryker incident represents a paradigm shift in wiper operations. Previous Iranian wipers — Shamoon, ZeroCleare, Hatef, BiBi — relied on deploying destructive malware to disk. This attack used none.

Instead, Handala compromised administrative credentials for Microsoft Intune, Stryker's cloud-based Mobile Device Management (MDM) platform. With Intune admin access, the attackers issued legitimate remote wipe commands to every enrolled device — the same commands an IT administrator would use to factory-reset a lost laptop or decommission a phone.

The result was identical to a wiper attack, but executed entirely through trusted infrastructure. No payloads to detect. No suspicious binaries to flag. No endpoint protection alerts to trigger.

This is living-off-the-land at its most devastating — weaponizing the management plane itself.

Full Attack Timeline

Why No Malware Was Needed

Traditional endpoint detection is designed to catch malicious code — suspicious processes, unauthorized file modifications, known exploit signatures. In this attack, none of those signals existed.

The kill chain was entirely identity-based:

Phishing / Credential Theft
        │
        ▼
Valid Admin Credentials Obtained
        │
        ▼
Authenticate to Microsoft Entra ID / Azure AD
        │
        ▼
Access Microsoft Intune Admin Console (Legitimate Portal)
        │
        ▼
Issue "Wipe" Command to All Enrolled Devices (Legitimate Function)
        │
        ▼
200,000+ Devices Factory Reset — No Malware Deployed

Every step in this chain uses legitimate Microsoft infrastructure and authorized administrative functions. From Intune's perspective, the wipe commands came from a valid admin account performing a valid action. This is why Stryker found "no indication of ransomware or traditional malware" — there was none to find.

MITRE ATT&CK Mapping

Who Is Handala?

Handala (حنظلة) is named after a political cartoon character symbolizing Palestinian resistance. The group emerged in late 2023 and is assessed by multiple intelligence agencies and threat research firms to be a state-directed front for Iran's Ministry of Intelligence and Security (MOIS).

Operational History

Handala's evolution mirrors the broader Iranian shift from custom malware to identity-based attacks:

The Stryker attack represents Phase 3 — the most dangerous evolution because it eliminates every traditional detection signal.

Motivation

Handala stated the Stryker attack was retaliation for a missile strike on an Iranian school on February 28, 2026. Stryker's perceived connections to the U.S. military (the company's name derives from the Stryker armored vehicle namesake) and its operations in Israel likely made it a symbolic target.

What Was Impacted — And What Wasn't

The medical device isolation is critical. Like Intuitive Surgical (which was attacked within 24 hours of Stryker), Stryker's connected products operate on segmented networks independent of the corporate Microsoft environment. This architecture prevented a supply-chain catastrophe for thousands of hospitals.

Detection: Hunting for Intune Admin Abuse

The core detection challenge is this: the wipe commands were technically legitimate. Detection must focus on anomalous administrative behavior, not binary signatures.

Azure AD / Entra ID — Detect Unusual Admin Logins (KQL)

SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == 0
| where AppDisplayName has_any ("Intune", "Microsoft Endpoint Manager", "Azure Portal")
| where RiskLevelDuringSignIn in ("high", "medium")
    or ConditionalAccessStatus == "notApplied"
    or IsInteractive == false
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    Location,
    AppDisplayName,
    RiskLevelDuringSignIn,
    DeviceDetail,
    ConditionalAccessStatus
| order by TimeGenerated desc

Intune Audit Logs — Detect Mass Wipe Commands (KQL)

IntuneAuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("wipeDevice", "Wipe", "RemoteWipe", "factoryReset")
| summarize
    WipeCount = count(),
    TargetDevices = make_set(TargetResources),
    Admins = make_set(InitiatedByUserPrincipalName)
    by bin(TimeGenerated, 1h)
| where WipeCount > 5
| order by WipeCount desc

Alert threshold: Any Intune admin account issuing more than 5 device wipes within a rolling 1-hour window should trigger a P1 / Critical severity alert in your SIEM.

Microsoft Graph API — Detect Bulk Wipe API Calls

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Wipe device"
    or OperationName == "Fresh Start"
    or OperationName has "remoteLock"
| extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetDevice = tostring(TargetResources[0].displayName)
| summarize
    TotalActions = count(),
    UniqueDevices = dcount(TargetDevice)
    by Initiator, bin(TimeGenerated, 30m)
| where TotalActions > 10
| order by TotalActions desc

Impossible Travel for Intune Admins

let intune_admins = SigninLogs
    | where AppDisplayName has "Intune"
    | where ResultType == 0
    | distinct UserPrincipalName;
SigninLogs
| where UserPrincipalName in (intune_admins)
| where ResultType == 0
| sort by UserPrincipalName asc, TimeGenerated asc
| serialize
| extend
    PrevTime = prev(TimeGenerated),
    PrevLoc = prev(Location),
    PrevUser = prev(UserPrincipalName)
| where UserPrincipalName == PrevUser
    and Location != PrevLoc
    and datetime_diff("minute", TimeGenerated, PrevTime) < 60
| project
    UserPrincipalName,
    PreviousLocation = PrevLoc,
    CurrentLocation = Location,
    MinutesBetween = datetime_diff("minute", TimeGenerated, PrevTime)

Hardening: Preventing the Next Intune-Based Wiper

This attack class requires a fundamental shift in how organizations secure their management plane. Endpoint detection alone is insufficient — the battle is at the identity and admin privilege layer.

1. Enable Multi-Admin Approval (MAA) for Wipe Actions

Microsoft Intune supports Multi-Admin Approval (MAA), requiring a second administrator to approve high-impact actions like device wipes before they execute. This is the single most effective control against this exact attack vector.

Microsoft Intune → Tenant Admin → Multi-admin Approval:
  - Enable MAA for: Device Wipe, Device Retire, Factory Reset
  - Require: 2 of 3 designated approvers
  - Timeout: 4 hours (auto-deny if not approved)

2. Implement Privileged Identity Management (PIM)

Eliminate standing Intune Administrator access. All admin roles should require just-in-time (JIT) elevation via Azure AD Privileged Identity Management:

PIM Configuration for Intune Administrator:
  - Eligible (not active): All Intune admin accounts
  - Activation requires: MFA + manager approval + justification text
  - Maximum activation duration: 4 hours
  - Alert on: Activation from new IP, new device, or outside business hours

3. Enforce Phishing-Resistant MFA for All Admin Roles

Standard TOTP and SMS MFA can be bypassed by AiTM phishing proxies (Evilginx2, Modlishka). Admin accounts must use:

• FIDO2 hardware security keys (YubiKey 5 series, Google Titan)
• Windows Hello for Business (TPM-bound biometric)
• Apple Passkeys (device-bound WebAuthn)

# Verify FIDO2 enforcement for admin accounts via Microsoft Graph
az rest --method GET \
  --uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy" \
  --query "authenticationMethodConfigurations[?id=='fido2'].{state:state,includeTargets:includeTargets}"

4. Restrict Wipe Permissions via RBAC

Do not grant Global Administrator or full Intune Administrator to accounts that only need read or reporting access. Create custom RBAC roles in Intune that explicitly exclude remote wipe, retire, and factory reset permissions.

5. Conditional Access Policies for Admin Portals

6. Restrict Graph API Wipe Endpoints

Prevent human admin accounts from having programmatic wipe access. Restrict managedDevice/wipe API endpoints to approved service principals only:

Graph API Restriction:
  - Block: Human accounts calling POST /deviceManagement/managedDevices/{id}/wipe
  - Allow: Only designated automation service principals with certificate-based auth
  - Monitor: All calls to /deviceManagement/managedDevices/*/wipe regardless of source

7. Network Segmentation for Medical Devices

Stryker's medical devices were protected because they operate on isolated network segments. Every healthcare and medtech organization should verify:

• Medical devices operate on dedicated VLANs with no route to corporate IT
• MDM management traffic does not traverse clinical network segments
• Connected devices (surgical robots, beds, communication systems) authenticate through separate identity systems

YARA Rule: Detect Handala Wiper Artifacts

While this specific attack didn't use traditional malware, Handala has historically deployed custom wipers. This rule covers known artifacts from both the Phase 2 wiper tools and Phase 3 identity indicators:

rule Handala_Wiper_Indicators {
    meta:
        description = "Detects known Handala/Void Manticore wiper artifacts and brand markers"
        author = "4nuxd.one"
        date = "2026-03-17"
        reference = "Stryker Wiper Attack - March 2026"
    strings:
        $brand1 = "Handala" ascii wide nocase
        $brand2 = {D8 AD D9 86 D8 B8 D9 84 D8 A9}
        $wiper1 = "hatef" ascii nocase
        $wiper2 = "hamsa" ascii nocase
        $wiper3 = "BiBi" ascii nocase
        $wiper4 = "bibi-linux" ascii nocase
        $intune1 = "deviceManagement/managedDevices" ascii
        $intune2 = "/wipe" ascii
        $intune3 = "RemoteWipe" ascii
        $graph1 = "graph.microsoft.com" ascii
    condition:
        2 of ($brand*) or
        2 of ($wiper*) or
        (1 of ($brand*) and 2 of ($intune*, $graph1))
}

Broader Implications

1. The Management Plane Is Now a Weapon

This attack proves that enterprise management tools — Intune, SCCM, Jamf, Workspace ONE — are not just administrative conveniences. They are pre-positioned destructive capabilities. An attacker who compromises an MDM admin account has root-level control over every enrolled device in the organization, without writing a single line of malware.

2. Healthcare Sector Under Coordinated Siege

Within a 24-hour window, both Stryker and Intuitive Surgical (maker of the da Vinci robotic surgery platform) were attacked — Stryker by a nation-state wiper operation, Intuitive by a credential theft campaign. The near-simultaneous targeting signals a deliberate campaign against the medtech sector, not coincidence.

3. Living-Off-the-Land Is Now Living-Off-the-Cloud

The cybersecurity industry spent a decade teaching defenders to watch for LOLBins — powershell.exe, certutil.exe, mshta.exe. The next generation of living-off-the-land doesn't use local binaries at all. It uses cloud admin consoles, MDM platforms, and identity management APIs. Detection must shift from the endpoint to the cloud control plane.

4. SEC 8-K Materiality Threshold for Wiper Attacks

Stryker's same-day SEC 8-K filing under Item 1.05 confirms that destructive attacks causing operational disruption — even without ransomware or data breach in the traditional sense — meet the materiality threshold for public disclosure. This has implications for every public company's incident response playbook.

Key Takeaways

• No malware was deployed. The entire attack was executed through legitimate Microsoft Intune admin functions. Endpoint detection and antivirus are irrelevant against this class of attack.
• Identity is the new perimeter — and the new weapon. Compromised admin credentials gave attackers the same destructive capability as a custom wiper binary, with zero detection surface.
• Multi-Admin Approval (MAA) would have stopped this attack. A single control — requiring a second admin to approve bulk wipe commands — would have prevented the mass device reset.
• Phishing-resistant MFA is non-negotiable for admin accounts. FIDO2 hardware keys are the only control that defeats AiTM phishing proxies used to steal admin sessions.
• Medical device isolation worked. Network segmentation between corporate IT and clinical OT environments prevented this from becoming a patient-safety catastrophe.
• The medtech sector is under active, coordinated targeting. Two of the world's largest surgical technology companies attacked within 24 hours. Security teams in healthcare should treat this as a campaign signal.

Stryker's investigation remains ongoing. The company has stated that connected medical products are safe for use and that affected operations are being restored with business continuity measures in place. Organizations in Stryker's supply chain should monitor for secondary phishing campaigns using Stryker branding and verify all vendor communications through established channels.