The Stryker Hack: How One Compromised Admin Account Led to 200,000 Wiped Devices

On the morning of March 11, 2026, employees at Stryker offices across 79 countries turned on their computers and found them blank. Login screens had been replaced with the logo of a barefoot boy holding a slingshot. Many employees had enrolled their personal phones through Stryker's BYOD (Bring-Your-Own-Device) program, which meant those were also managed by Stryker's IT systems. Those phones were factory reset too, wiping not just corporate apps but everything: photos, eSIMs, and the authenticator apps employees relied on for personal banking. Company laptops were wiped. Everything connected to Stryker's corporate network had been erased overnight¹.

Stryker is one of the world's largest medical technology companies: approximately 56,000 employees, $25.1 billion in revenue for 2025, and products that impact more than 150 million patients annually². The real-world impact was immediate. Maryland's emergency medical services reported that Stryker's Lifenet ECG transmission system, which paramedics use to send cardiac data to hospitals ahead of patient arrival, went offline across most of the state. Paramedics had to fall back to radio consultations³. In Ireland, employees across Stryker's 5,500-person hub were sent home⁴.

An Iran-linked group called Handala claimed responsibility⁵. Multiple independent threat intelligence firms (Check Point, CrowdStrike, Microsoft, Palo Alto Networks) assess Handala as one of several online personas operated by Void Manticore, a destructive operations unit inside Iran's Ministry of Intelligence and Security (MOIS)⁶. The group stated the attack was retaliation for the ongoing US and Israeli military strikes on Iran. Palo Alto's Unit 42 identifies Handala as the most prominent Iranian hacktivist persona currently active in the conflict⁷.

This was a nation-state actor turning a company's own administrative infrastructure into a weapon. It was cyber warfare executed through an IT management console.

This post is a technical breakdown of how the attack happened, what allowed it to succeed, and what would have stopped it. The investigation is still ongoing and we will update this post as new details emerge.

What they used: Microsoft Intune as a weapon

Microsoft Intune is a cloud-based platform that lets companies manage their entire device fleet from a single web console. When a company enrolls a device in Intune (whether a corporate laptop or a personal phone through BYOD), that device trusts Intune as an authority. If Intune sends a factory reset command, the device executes it immediately without further verification⁸.

Anyone with admin-level access to Intune therefore holds a kill switch for every enrolled device in the organization.

According to a source who spoke to KrebsOnSecurity, the attackers used Intune's built-in Remote Wipe feature to issue factory reset commands to all enrolled devices simultaneously⁹. Stryker employees on Reddit confirmed being told to urgently uninstall Intune and Company Portal from their personal devices¹⁰.

Every command Intune executed was, from the platform's perspective, a legitimate administrative action. Endpoint detection tools did not flag it. There was no malicious payload to detect. The platform was doing exactly what it was designed to do, just for the wrong person.

How they likely got in

The exact initial access vector has not been officially confirmed¹¹. But the technical consensus from Check Point Research, Palo Alto Unit 42, and KrebsOnSecurity points to three hypotheses. They are not mutually exclusive, and the attackers likely combined them across different phases of the operation.

Hypothesis 1: Adversary-in-the-Middle (AiTM) phishing

This is the leading theory. AiTM phishing is fundamentally different from traditional phishing because it does not just steal a password. It steals an entire authenticated session, which means it renders MFA completely irrelevant.

Here is how it works.

The attacker sends a targeted email to someone at Stryker, likely an IT administrator. The email looks legitimate, perhaps a Microsoft 365 notification or a SharePoint document share. Modern phishing-as-a-service platforms like Tycoon 2FA generate pages that perfectly replicate an organization's branded login screen¹².

The link in the email goes to an attacker-controlled server running a reverse proxy. This proxy sits between the victim and the real Microsoft login page. It forwards everything in both directions. From the victim's perspective, they are logging into the real Microsoft Entra ID. They enter their password. Microsoft prompts them for MFA. They approve the push notification or enter their one-time code. Everything completes normally.

But after successful authentication, Microsoft issues a session token. This token is proof that the user has already authenticated. Whoever holds it has access. Because the proxy is in the middle, the token goes to the attacker's infrastructure. The victim lands on the real Microsoft 365 portal and may not notice anything wrong¹³.

The attacker now has a valid session token. They can use it from their own machine to access the victim's account. MFA will not trigger again because the token is the proof that MFA already happened. If that account has Global Administrator privileges, the attacker has full control of the entire Microsoft 365 tenant.

This is why Stryker's statement that they found "no indication of ransomware or malware" makes sense. AiTM phishing requires zero malware on the victim's device. The attack happens entirely between the victim's browser and the proxy.

The timing is notable. Proofpoint documented active AiTM campaigns by TA450 (the designation for MuddyWater, an MOIS-linked group with documented overlap with Handala) targeting US organizations as recently as March 8, three days before the attack¹⁴. Microsoft's research on the Tycoon 2FA platform found it had been responsible for tens of millions of phishing messages reaching over 500,000 organizations each month¹².

Hypothesis 2: VPN brute force and lateral movement

Check Point Research published direct observations of Handala's reconnaissance in the months before the attack. They identified hundreds of logon and brute-force attempts against VPN infrastructure linked to Handala, originating from commercial VPN nodes and, after Iran's January 2026 internet shutdown, from Starlink IP ranges to blend into legitimate satellite traffic⁶.

In this scenario, the attacker compromises a VPN credential (often belonging to a regular employee or contractor) and lands inside the corporate network. From there, they work toward the cloud admin console.

Here is how that works in plain terms. 

Most large companies sync their internal user directory (Active Directory) with their cloud identity system (Microsoft Entra ID) using a tool called AD Connect. When password sync is enabled, the same credentials work in both environments. An attacker inside the network can use freely available tools to extract stored passwords from machines they have access to. If they find an account that happens to hold admin privileges in both the internal network and the cloud environment, they can use those credentials to log into the cloud admin console directly. Alternatively, they can compromise the AD Connect sync server itself to extract the credentials it uses to communicate with the cloud, which are often highly privileged⁶.

Check Point's research on this specific intrusion notes that once inside, the attacker turned off security protections on the machines they accessed and ran automated tools to harvest as many stored credentials as possible⁶. This is standard procedure for this type of attack. The goal is to find the one account with enough privilege to reach the cloud management console.

The VPN entry point is particularly dangerous because it can bypass the Conditional Access policies that would normally gate cloud admin access. If Stryker's policies were configured to trust devices on the corporate network, an attacker connecting through VPN looks like a trusted insider.

Hypothesis 3: Supply chain compromise through a third-party vendor

Most large enterprises use managed service providers (MSPs), IT contractors, or consulting firms that have some level of privileged access to their environments. These vendors often have admin credentials, VPN access, or direct connections to cloud management consoles so they can manage devices, resolve tickets, and deploy patches.

If Handala compromised one of Stryker's IT vendors, they would not have needed to phish a single Stryker employee. They would have inherited whatever access that vendor already had. The vendor's security posture becomes your security posture, and most enterprises do not govern vendor access with the same rigor they apply internally.

This is not speculation about Handala's general approach. Palo Alto Unit 42 has specifically documented Handala's focus on "supply-chain footholds through IT and service providers to reach downstream victims"⁷. Check Point confirms the pattern: Handala has consistently targeted IT and service providers to obtain credentials for downstream organizations⁶. Whether this was the path into Stryker specifically remains unconfirmed.

Pre-positioned access

One of the most important findings across all three hypotheses is that this was not a reactive, day-of attack. Check Point Research states that initial access is believed to have been established well before the destructive phase, with network access dating back several months⁶. The Handala branding that appeared on screens before the wipe confirmed that the attackers had control well before they chose to use it.

Stryker also had a prior breach in 2024 involving unauthorized access from May to June, with PII and medical records exfiltrated. That breach was not disclosed until December 2024¹⁵. Whether persistence from that earlier compromise contributed to the March 2026 attack is under investigation.

Why MFA did not help

Standard MFA (SMS codes, authenticator app OTPs, push notifications) does not protect against AiTM phishing. The victim completes a real MFA challenge on the real Microsoft login page. The attacker captures the session token issued after MFA succeeds. The attacker steals what comes after authentication, not the authentication itself¹³.

The only forms of MFA that defend against AiTM are phishing-resistant credentials: FIDO2 security keys and passkeys (like Windows Hello for Business). These work differently from standard MFA because the authentication is cryptographically bound to the specific domain. During a FIDO2 login, the authenticator checks the domain it is communicating with before responding. If the user is on an attacker's proxy domain (say, login-stryker.attacker.com) instead of the real Microsoft domain (login.microsoftonline.com), the FIDO2 key recognizes the mismatch and refuses to authenticate. The proxy never receives a valid response, so there is no token to steal¹⁶.

Deploying FIDO2 across 56,000 employees in 61 countries is a significant undertaking. Most enterprises still rely on push-based MFA. This gap is industry-wide.

What would have stopped this

The breach was not one failure. It was a cascade of missing controls. Here is what would have made a difference.

1. Multi-admin approval for destructive actions

Microsoft Intune has a built-in feature called Multi-Admin Approval (MAA). When configured, it requires a second administrator to approve before wipe, retire, or delete actions execute. A compromised admin account can request a mass wipe, but nothing happens until a second person from a designated approver group confirms¹⁷.

If Stryker had MAA enabled, the attacker would have needed to compromise two separate admin accounts and have the second one actively approve the wipe in real time.

This is a configuration setting in the Intune admin console. It should be a baseline requirement for any organization managing devices at scale.

2. Phishing-resistant MFA for privileged accounts

If Stryker's admin accounts had been protected with FIDO2 keys or passkeys, the AiTM phishing attack almost certainly would not have succeeded.

You do not need to roll FIDO2 to every employee to get the most important protection. Start with the accounts that can do the most damage: Global Admin, Intune Admin, and any other privileged roles. Microsoft's Conditional Access supports requiring phishing-resistant MFA specifically for users in privileged directory roles¹⁶.

3. Just-in-time privileged access, across every application

Microsoft has a native tool called Privileged Identity Management (PIM). With PIM enabled, nobody holds standing admin privileges. When an admin needs elevated access, they request it through PIM. The request is time-bound, requires justification, and can require approval. If an attacker compromises an admin account with PIM configured, they do not automatically get admin privileges. They have to request activation, which creates alerts and gives defenders time to intervene¹⁷.

Here is the bigger problem. Microsoft has PIM for their own environment. But Stryker does not just run Microsoft. They run hundreds of SaaS applications: Salesforce, Oracle, Workday, ServiceNow, and many more. Most of those platforms have no equivalent to PIM built in.

A Workday admin can exfiltrate every employee's compensation data. A Salesforce admin can export the entire customer database. A ServiceNow admin can modify approval workflows. An AWS admin can destroy infrastructure. In most enterprises, those admin roles are standing, permanently assigned, and poorly audited.

The Stryker attack happened to target Microsoft's control plane. But the same pattern (compromised credential plus standing admin privilege) applies to every SaaS application that does not enforce just-in-time access.

This is why you need a JIT privileged access layer across your entire application stack. At Lumos, we allow organizations to enforce just-in-time access policies across hundreds of integrations. Admin privileges are short-lived, must be explicitly requested, require approval, and automatically expire. The goal: nobody has standing access to do anything destructive, regardless of which application the access is in.

4. Entitlement hygiene with AI-driven classification

You cannot enforce least privilege if you do not know what privileges exist.

The average large enterprise has hundreds of applications, each with its own permission model, role names, and admin tiers. "Admin" in Salesforce means something different than "Admin" in Snowflake. "Owner" in GitHub means something different than "Owner" in Google Workspace. Understanding which entitlements are actually sensitive across hundreds of applications is a classification problem that does not scale when done by hand.

Lumos Identity Agents use Agentic AI to classify entitlements across your entire SaaS portfolio automatically. They tag what is sensitive, identify admin-level permissions, flag dormant access, and surface over-provisioned accounts. Once you have that classification, you can enforce policy: admin-tagged entitlements require JIT access, get reviewed on a shorter cycle, trigger alerts when assigned permanently, and are revoked when not in use.

5. Behavioral anomaly detection on admin actions

A bulk wipe command against 200,000 devices should never happen in normal operations. An alert that fires when more than five devices are wiped in a short window would have given Stryker's security team a chance to intervene. A Global Admin logging in from an unfamiliar location or an unmanaged device should trigger immediate investigation.

Microsoft's Continuous Access Evaluation (CAE) enables near real-time token revocation when security events occur, shrinking the window an attacker has to use a stolen token¹³. These capabilities need to extend across every management plane.

6. Third-party and vendor access governance

Every vendor account with privileged access should be subject to the same controls as internal admin accounts: just-in-time access, phishing-resistant MFA, behavioral monitoring, and regular access reviews. Vendor access should be scoped to the minimum permissions necessary and should expire automatically. Most enterprises have significant blind spots here because third-party access is often provisioned during onboarding and never reviewed again.

The bigger picture

The attackers needed one thing: a privileged credential for a cloud management console. Once they had it, the platform did the rest. Every organization running Intune, or any device management system, has given that platform the ability to remotely wipe every enrolled device. That capability is a feature. It is also, if the wrong person gains access, a weapon¹⁸.

The same logic applies to every centralized management plane in your environment: your identity provider, your cloud console, your HR system, your CI/CD pipeline. Any system that can push changes to many downstream systems from a single point of control is a force multiplier for an attacker who gains access to it.

The defenses are not mysterious. Phishing-resistant MFA for privileged accounts. Just-in-time access instead of standing privileges, across every app, not just Microsoft. Multi-party approval for destructive operations. AI-driven classification of entitlements so you actually know what is sensitive. Behavioral detection so you catch the anomaly before the blast radius expands.

What the Stryker attack exposed is the gap between knowing what to do and actually doing it. That gap is where the damage happens.

Post-Stryker security checklist

We put together a checklist of the most important actions to take in response to the Stryker attack.

This post will be updated as new technical details emerge from the ongoing investigation. Last updated: March 14, 2026.

‍

References & Sources

[1] SecurityWeek, "MedTech Giant Stryker Crippled by Iran-Linked Hacker Attack," March 12, 2026. https://www.securityweek.com/medtech-giant-stryker-crippled-by-iran-linked-hacker-attack/

[2] Stryker SEC Press Release, January 2025. "We impact more than 150 million patients annually." https://www.sec.gov/Archives/edgar/data/0000310764/000119312525014415/d919971dex991.htm

[3] CNN, "Pro-Iran hackers claim cyberattack on major US medical device maker," March 11, 2026. https://www.cnn.com/2026/03/11/politics/pro-iran-hackers-cyberattack-medical-device-maker

[4] Irish Examiner, "Stryker cyberattack Q&A," March 11, 2026. https://www.irishexaminer.com/news/munster/arid-41808479.html; IDA Ireland, "Stryker: 5,000+ employees in Ireland." https://www.idaireland.com/success-stories/stryker

[5] TechCrunch, "Pro-Iran hacktivist group says it is behind attack on medical tech giant Stryker," March 11, 2026. https://techcrunch.com/2026/03/11/stryker-hack-pro-iran-hacktivist-group-handala-says-it-is-behind-attack/

[6] Check Point Research, "'Handala Hack' - Unveiling Group's Modus Operandi," March 12, 2026. https://research.checkpoint.com/2026/handala-hack-unveiling-groups-modus-operandi/

[7] Palo Alto Networks Unit 42, "Insights: Increased Risk of Wiper Attacks," March 2026. https://unit42.paloaltonetworks.com/handala-hack-wiper-attacks/

[8] WION News, "How did Iran hack iPhones of Stryker employees?" March 13, 2026. https://www.wionews.com/photos/stryker-uses-microsoft-but-how-did-iran-hack-iphones-of-its-employees-understanding-the-handala-cyberattack-1773310596097

[9] KrebsOnSecurity, "Iran-Backed Hackers Claim Wiper Attack on Medtech Firm Stryker," March 11, 2026. https://krebsonsecurity.com/2026/03/iran-backed-hackers-claim-wiper-attack-on-medtech-firm-stryker/

[10] The Cyber Express, "Who Is Handala," March 13, 2026. https://thecyberexpress.com/who-is-handala-hackers-in-stryker-cyberattack/

[11] Securonix Community, "Iran-backed Handala wiper attack devastates Stryker globally," March 11, 2026. https://connect.securonix.com/threat-research-intelligence-62/iran-backed-handala-wiper-attack-devastates-stryker-globally-230

[12] Microsoft Security Blog, "Inside Tycoon2FA: How a leading AiTM phishing kit operated at scale," March 4, 2026. https://www.microsoft.com/en-us/security/blog/2026/03/04/inside-tycoon2fa-how-a-leading-aitm-phishing-kit-operated-at-scale/

[13] Microsoft Entra Blog, "Defeating Adversary-in-the-Middle phishing attacks," November 2024. https://techcommunity.microsoft.com/blog/microsoft-entra-blog/defeating-adversary-in-the-middle-phishing-attacks/1751777

[14] ABT Associates, "Stryker Cyberattack: What It Means for Financial Institutions Running Microsoft 365," March 11, 2026. Cites Proofpoint documentation of TA450 campaigns as recently as March 8. https://www.myabt.com/blog/stryker-cyberattack-microsoft-365-security

[15] TechnologyMatch, "The Stryker Cyberattack: What This Means for Your Security Architecture," March 13, 2026. https://technologymatch.com/blog/the-stryker-cyberattack-what-this-means-for-your-security-architecture

[16] Swissbit, "Bypassing MFA: The Rise of Adversary-in-the-Middle Attacks," April 2025. https://www.swissbit.com/en/blog/post/bypassing-mfa-the-rise-of-adversary-in-the-middle-aitm-attacks/

[17] Cyber Magazine, "Stryker Cyber Attack: Iranian Threat Actor Claims Revenge," March 12, 2026. https://cybermagazine.com/news/iran-war-cyber-front-stryker-cyber-attack

[18] Sig Murphy / Intruvent, "They Used Your Own Tools Against You," March 12, 2026. https://edge.intruvent.com/p/they-used-your-own-tools-against

‍

‍