Subscribe to the Non-Human & AI Identity Journal

Stryker Microsoft Intune Wiper Attack: Handala Wipes 200,000 Devices Across 79 Countries

On 11 March 2026, employees at Stryker Corporation offices across 79 countries switched on their computers and found them blank. Login screens had been replaced with the logo of a barefoot boy holding a slingshot. Stryker, a Fortune 500 medical device company with 56,000 employees and $25.1 billion in 2025 revenue, had been hit by the most destructive corporate cyberattack of 2026. No malware was deployed. No ransomware payload was installed. No zero-day vulnerability was exploited. The Iran-linked hacktivist group Handala had obtained a Microsoft Intune administrator credential and used Microsoft’s own enterprise device management platform to factory-reset approximately 200,000 devices simultaneously.

What Happened

Stryker’s enterprise IT environment ran Microsoft Intune for endpoint management — a standard cloud-based mobile device management platform that allows administrators to remotely configure, manage, and wipe corporate devices. Stryker had also implemented a BYOD programme, meaning employees had enrolled personal phones in Intune to access corporate email and applications. When the wipe command executed, it reached not just corporate laptops but personal devices as well — wiping photos, eSIMs, and the authenticator apps employees relied on for personal banking.

Handala claimed responsibility publicly, stating it had wiped more than 200,000 servers, mobile devices, and systems across 79 countries and exfiltrated 50 terabytes of data. Stryker confirmed the attack in an SEC Form 8-K filing on 11 March 2026 and confirmed on 16 March that the incident involved Intune device wipes across its global infrastructure. Stryker explicitly stated it was not ransomware and that no malware was detected on its systems.

The timeline:

  • Prior to March 11: Threat intelligence researchers at Outpost24 identified 278 compromised Stryker credentials in telemetry between October 2025 and March 2026, with 138 linked to activity in 2026. The initial access mechanism remains unconfirmed but is assessed to involve infostealer malware and/or AiTM phishing.
  • March 11, 2026, approximately 03:30 AM Eastern: Handala executes the mass device wipe via Intune administrative console
  • March 11, 2026: Stryker employees across 79 countries find devices blank and login screens replaced with the Handala logo. Stryker activates crisis communications over WhatsApp because corporate systems are down.
  • March 11, 2026: Stryker files SEC Form 8-K disclosing the incident
  • March 13, 2026: Microsoft publishes direct hardening guidance for Intune in response to the attack
  • March 15, 2026: Stryker confirms products and patient-facing services remain safe; no ransomware; no malware detected
  • March 16, 2026: Stryker confirms Intune was used for the wipe; incident contained; restoration in progress
  • April 2026: CISA issues guidance on the risk of compromised device management platforms, confirming awareness of the attack vector

Financial impact is assessed at $62 million to $140 million, including device replacement, incident response, operational disruption, security hardening, and legal costs.

How It Happened

The Stryker attack did not require any novel technique. It required one compromised administrator account and access to the Intune management console. The attack chain, as reconstructed by multiple security firms including Palo Alto Unit 42, SlashID, Check Point Research, and Guardz, points to two primary hypotheses — not mutually exclusive:

Hypothesis 1 — Infostealer credential harvesting. Infostealer malware extracts browser session cookies, saved passwords, and authentication artifacts from infected endpoints after authentication has already completed. An administrator’s laptop infected with a Lumma, AMOS, or RedLine stealer variant would yield a browser cookie representing a valid authenticated session with Intune administrative access — an access path that bypasses MFA entirely because the session token already reflects a completed MFA event. Outpost24 identified 278 compromised Stryker credentials in its telemetry, including 138 linked to 2026 activity, consistent with infostealer activity preceding the attack.

Hypothesis 2 — AiTM session token theft. Adversary-in-the-Middle phishing intercepts the post-MFA session token in real time by proxying the victim through a attacker-controlled page that mirrors the legitimate Microsoft login. The attacker captures the session token before it reaches its intended destination. Check Point Research documented hundreds of Handala-linked logon and brute-force attempts against Stryker VPN infrastructure in the months preceding the attack.

Both paths lead to the same outcome: a valid authenticated session with Intune Global Administrator-level access, from which the attacker can issue a factory reset command to every enrolled device with no additional authentication required.

Stryker’s prior disclosure of a separate breach in December 2024, involving unauthorized access from May to June 2024 with PII and medical record exfiltration, raises the possibility that earlier compromise provided persistent footholds that enabled the March 2026 Intune access. This connection remains unconfirmed.

What This Means for NHI Governance

The Stryker breach makes explicit what has been understood in principle but rarely demonstrated at scale: cloud endpoint management identities are non-human identities with catastrophic destructive potential.

A Microsoft Intune Global Administrator credential is not just an account that can view device inventory. It is an account that can factory-reset every enrolled device in the organisation simultaneously, push arbitrary configuration to all managed endpoints, override security policies across the entire fleet, and execute device retirement at scale. When that credential is compromised, the blast radius is not a mailbox or a SharePoint site. It is 200,000 devices and the operational continuity of a $25 billion company.

This credential should be treated with the same governance applied to any other non-human identity with destructive capability:

  • Identity binding: Administrator access to Intune should require phishing-resistant authentication — FIDO2 hardware keys or certificate-based authentication — not just standard MFA. AiTM attacks and infostealer session cookie theft both defeat standard MFA. Phishing-resistant MFA is the control that Handala could not defeat.
  • Privilege separation: Intune’s Global Administrator role carries far broader permissions than are needed for routine endpoint management. Administrative roles should be split: read access, policy change, device action, and tenant-wide administration should be separate roles assigned to separate accounts.
  • Just-in-time privileged access: Permanent standing access to Intune administrative functions is unnecessary. JIT access that requires an approval workflow for destructive operations – mass device wipe, bulk policy change, global configuration push, would have added a breakable link to the attack chain.
  • Multi-admin approval for destructive actions: Microsoft’s post-incident hardening guidance published on 13 March 2026 explicitly recommends requiring Multi-Admin Approval for device wipe, factory reset, and mass retire operations. A single compromised session should not be able to issue a fleet-wide wipe command.

Recommendations

Remove local administrator rights from machines that access privileged management consoles. An administrator’s daily-use laptop should not be the same machine used to access Intune administrative functions. Separate privileged access workstations for sensitive cloud console access.

Enforce phishing-resistant MFA on all Intune administrative accounts immediately. This is the highest-priority control. Standard push notifications and SMS codes do not protect against AiTM phishing or infostealer session cookie theft. FIDO2 hardware keys and Windows Hello for Business are the required controls.

Enable Multi-Admin Approval for all destructive Intune actions. Microsoft Intune has a native Multi-Admin Approval feature. Enable it for device wipe, factory reset, retire, and bulk policy push. Require a second administrator to approve before any of these actions execute.

Separate MDM administrative roles by action type. Split read access, configuration management, device actions, and tenant administration into distinct Intune roles. No single account should have the authority to both manage policies and execute fleet-wide device actions.

Hunt for infostealer infections across administrative endpoints. Administrator machines are the highest-value target for infostealer operators. Deploy EDR with explicit detection rules for infostealer behaviour: browser data access, credential store reads, unexpected outbound connections. Monitor dark web markets for credentials associated with your domain.

Review BYOD Intune enrollment scope. Personal devices enrolled in Intune for email access are included in the blast radius of any enterprise-wide wipe command. Assess whether personal device enrollment is necessary and whether its scope can be restricted to exclude the most destructive Intune operations.

Recommendations

  • Audit all OAuth grants to third-party SaaS platforms. Most organisations have no inventory of which third-party applications hold OAuth tokens, what scopes those tokens carry, and when they were last reviewed. Build that inventory. It is the minimum viable governance posture.
  • Implement OAuth token rotation and expiry policies. OAuth refresh tokens should not persist indefinitely. Work with integration vendors to enforce token expiry and require periodic re-authorisation.
  • Apply least-privilege scoping to all integration credentials. A competitive intelligence tool does not need write access to your CRM. Every OAuth grant should be scoped to the minimum required for the integration to function.
  • Treat third-party SaaS integrations as privileged NHIs. The Klue breach should be the end of treating SaaS integrations as low-risk configuration decisions. Every integration that holds a credential is a non-human identity with an attack surface.
  • Monitor for anomalous OAuth token usage. Salesforce and most enterprise SaaS platforms provide API access logs. Unusual access patterns from integration credentials, unexpected source IPs, access outside business hours, bulk data exports, should trigger alerts.

How NHI Mgmt Group Can Help

Securing Non-Human Identities (NHIs) including AI Agents, is becoming increasingly crucial as attackers discover and target service accounts, API keys, tokens, secrets, and OAuth credentials during breaches. These NHIs often hold extensive permissions that can be exploited, making their security a priority for any organisation focused on protecting their digital assets.

Take our NHI Foundation Level Training Course, the most comprehensive in the industry, that will empower you and your organisation with the knowledge needed to manage and secure these non-human identities effectively.

👉 Further details here

Final Thoughts

The Stryker breach is the moment when the theoretical risk of cloud management plane credential compromise became a documented operational reality at global scale. A single Intune Global Administrator account — accessed through credential material stolen from a legitimate administrator, wiped 200,000 devices across 79 countries in the early hours of a Tuesday morning using a native platform feature designed for legitimate administrative purposes. No malware. No exploit. Just a credential and a console.

That is the NHI threat model made concrete. Every organisation running Microsoft Intune, Jamf, Google Workspace admin, or any other cloud-based management platform needs to answer one question: if an attacker held your management platform credentials right now, what could they do? The answer determines the priority of your controls.