The Stryker Attack: When Your Own Device Management Becomes the Weapon

The Stryker Attack: When Your Own Device Management Becomes the Weapon
On 11 March 2026, Stryker Corporation filed an 8-K with the SEC. The filing disclosed a cybersecurity incident that had caused "a global disruption to the Company's Microsoft environment." Stryker makes surgical equipment, robotic surgery systems, defibrillators, and clinical communications tools. Hospitals in more than 60 countries use its products. The company employs roughly 53,000 people and reported USD 22.6 billion in global sales in 2024.
An Iranian state-linked group called Handala claimed responsibility for the attack, calling it retaliation for US-Israeli military strikes on Iran that began on 28 February 2026. NBC News described it as the first significant instance of Iran hacking an American company since the conflict started.
What makes this incident different from a typical ransomware hit is the reported attack method. Multiple news outlets, citing anonymous sources inside the company, say the attackers didn't deploy malware or encrypt files. They allegedly used Stryker's own device management platform to wipe its devices. Personal phones enrolled in the company's MDM system were reportedly wiped too, destroying employees' photos, banking apps, eSIMs, and two-factor authentication tokens.
Stryker told the SEC that its timeline for full restoration was "not yet known." As of this writing, the company is still working to recover.
What everyone thinks happened
The headlines read like a straightforward breach: Iranian hackers attacked a medical company. Some early coverage implied that medical devices were compromised, raising questions about patient safety. Others framed it as a ransomware attack on critical healthcare infrastructure.
Stryker's own statements contradict both of those readings. The company stated it had "no indication of ransomware or malware." It confirmed that Mako (robotic surgical systems), Vocera (clinical communications), and LIFEPAK35 (defibrillators) were "fully safe to use." The attack hit Stryker's corporate IT environment, not its medical device firmware or hospital-facing systems.
That distinction matters because the actual attack method, if reporting proves accurate, is far more interesting than ransomware. It is also far harder to defend against.
What actually happened
Stryker confirmed a "global network disruption to our Microsoft environment" caused by a cyber attack. That is the company's own language, carefully worded for a legal filing during a live incident. What they haven't said publicly is how the attackers pulled it off.
The technical detail comes from reporting by Brian Krebs and other journalists citing anonymous sources inside Stryker. According to those reports, the attack unfolded through Stryker's Microsoft Intune deployment.
The reported attack chain
Microsoft Intune is an MDM platform that lets organisations manage every laptop, phone, and tablet enrolled in their estate. It can push software, enforce security policies, and remotely wipe devices. That last feature exists so companies can protect data on lost or stolen devices by erasing them remotely.
Anonymous source reporting indicates that the attackers got hold of high-privilege admin credentials for Stryker's Microsoft Entra ID (formerly Azure Active Directory) tenant. A Global Administrator account in Entra ID has full access to the entire Microsoft 365 environment, including the Intune MDM console. With that level of access, the attackers reportedly sent mass remote wipe commands to every device enrolled in Intune across Stryker's global estate.
A remote wipe through Intune is not a selective deletion but a full factory reset that returns the device to its out-of-box state. Every application, every file, every configuration setting is gone. On corporate-owned devices, the OS image, domain join settings, security software, and all local data are wiped. For personal devices enrolled through BYOD policies, the fallout is worse. Reports say employees lost personal photos, banking apps, eSIM setups, and two-factor authentication apps on devices they personally owned.
Krebs also reported that the Handala logo appeared on every login page across Stryker's environment, and that the group sent emails to company executives claiming credit for the attack.
Who is Handala?
Handala is assessed by Check Point Research, Palo Alto Unit 42, Microsoft, and CrowdStrike as a persona operated by Void Manticore, an Iranian threat actor. Microsoft tracks the group as Storm-842 and CrowdStrike tracks it as Banished Kitten. Check Point links Void Manticore specifically to Iran's Ministry of Intelligence and Security (MOIS), and more precisely to the MOIS Internal Security Deputy's Counter-Terrorism Division.
The group has a documented history of destructive operations. Void Manticore previously operated under the persona "Homeland Justice" during destructive cyberattacks against Albanian government systems in 2022. It operated as "Karma" during attacks against Israeli targets. Handala first surfaced in December 2023 and has become what Palo Alto Unit 42 describes as "the most prominent Iranian hacktivist persona."
The group's stated motivation for the Stryker attack was retaliation for the bombing of a girls' school in Minab, Tehran, by US military forces on 28 February 2026, which killed over 175 people, mostly children. Handala called Stryker a "Zionist-rooted corporation," possibly referencing Stryker's 2019 acquisition of OrthoSpace Ltd, an Israeli medical technology company, for USD 110 million.
Why a wiper and not ransomware
Void Manticore's track record is destruction, not extortion. Check Point's analysis shows a consistent pattern in the group's operations. First, compromised VPN credentials for initial access. Then lateral movement via RDP and tunnelling tools. Finally, manual destructive actions using off-the-shelf wipers. The group developed the BiBi wiper (named after Israeli Prime Minister Netanyahu) for use against Israeli targets in 2024.
A ransomware attack encrypts data and demands payment for the decryption key. There is a financial deal at the centre of it. The attacker has a reason to leave the infrastructure recoverable. A wiper attack has no such incentive because the data is gone and the goal is damage, not revenue.
Stryker's own public statement supports this reading. The company said it found "no indication of ransomware or malware." A mass wipe command sent through a legitimate MDM platform would not look like malware to endpoint security tools. It is a legitimate admin function being used for an illegitimate purpose. The MDM platform is doing what it was designed to do. The problem is who told it to do it.
How MDM wipe commands work
When an MDM admin sends a remote wipe, the command travels from the Intune cloud service to the enrolled device through the platform's management channel. The device doesn't question it because the MDM platform is a trusted authority. The device was enrolled to accept these commands.
For Windows devices, a full wipe resets the device to factory settings. For iOS and Android devices enrolled in corporate MDM, the result depends on the enrolment type. Full enrolment allows a complete device wipe. BYOD enrolment with a managed profile should, in theory, only wipe the corporate partition. But reports from Stryker employees suggest personal data was also wiped.
The devastating part of this approach is that the attacker doesn't need to deploy malware to thousands of endpoints one by one. A single compromised admin account with MDM access can wipe every enrolled device at once. The infrastructure does the work for them. Every endpoint in the organisation is already configured to obey.
Attacker claims vs confirmed facts
Handala claimed to have wiped over 200,000 systems, servers, and mobile devices, and to have exfiltrated 50 terabytes of data. The group also claimed to have disrupted offices in 79 countries and idled approximately 56,000 employees.
These claims should be treated with caution. Stryker has not confirmed any of these specific numbers. No exfiltrated data has been published as of 12 March 2026, which could indicate bluffing, an ongoing negotiation, or a delayed release. The 79-country figure is plausible (Stryker operates in over 60 countries, with some sources citing 75 or more), but it remains unverified by the company. (following the foundational provenance assessment protocol).
What is confirmed from other sources: RTE (Ireland's national broadcaster) and the Irish Examiner both reported that over 5,000 workers were sent home. Stryker runs six factories and three innovation centres across Cork, Belfast, and Limerick. Ireland represents Stryker's largest operations outside the United States. Stryker's stock fell approximately 4.5% on the day of the attack.
Myth vs fact
Myth: This was a ransomware attack on a hospital supply chain.
Stryker explicitly stated it had "no indication of ransomware or malware." The attack disrupted Stryker's corporate IT environment, not hospital systems. Stryker confirmed that Mako, Vocera, and LIFEPAK35 products remain "fully safe to use." Orders placed before the attack are still visible in Stryker's systems, and the company said shipments would restart once comms were restored. The worry about surgical scheduling delays is real. Just-in-time delivery of implants and surgical kit was disrupted. But the attack targeted Stryker's internal infrastructure, not its medical devices or hospital networks.
Myth: State-sponsored hacktivism is crude and unsophisticated.
Void Manticore's work is not technically complex in the way an APT group doing long-term espionage might be. Unit 42 describes their approach as "opportunistic and quick and dirty." But complexity is not the right yardstick. The group spotted that a single point of compromise (high-privilege MDM admin credentials) could cause maximum damage across a whole global estate. That is strategic thinking, even if the individual methods (credential theft, abuse of legitimate admin tools) are not new. Check Point also flags a handoff pattern where Scarred Manticore runs espionage and then passes targets to Void Manticore for destruction. That points to a more structured operation than a lone hacktivist group.
Myth: Medical devices were compromised and patients are at risk from the hacking group.
Based on everything Stryker has stated, the attack affected corporate IT systems running in the Microsoft environment. Stryker's medical devices (surgical robots, defibrillators, communications platforms) operate independently from the corporate IT estate. The patient safety risk from this incident is indirect: if surgical equipment can't be shipped on schedule, procedures may be delayed. But the devices themselves were not compromised, tampered with, or rendered unsafe.
Myth: You can't defend against an attacker who uses your own tools against you.
The Intune attack vector (if confirmed) is devastating precisely because MDM platforms are designed to have this level of control. But "designed to have this level of control" also means "designed to have access controls around that ability." The attack reportedly worked because the attackers got high-privilege admin credentials, not because Intune has a built-in flaw. The real question is whether those credentials were properly protected. That is a solvable problem with known fixes.
What would have stopped this
If the anonymous source reporting about the Intune attack vector is right, the defensive gaps sit squarely in identity and access management. The controls that would have cut the blast radius or stopped the attack are well known.
Privileged access management for MDM admins. A Global Administrator account should never be a standing permission. Privileged Identity Management (PIM) in Entra ID lets organisations make admin roles time-limited and approval-gated. An MDM admin should need to request elevation, give a reason, and get approval before issuing bulk device commands. A stolen credential that can only read policies, not issue wipes, limits what an attacker can do with it.
Conditional access policies on admin actions. High-privilege actions like bulk wipes should need extra checks beyond the initial login. Conditional access can require a specific compliant device, a known network location, and phishing-resistant MFA before granting access to admin consoles. An attacker with stolen credentials but no access to the required hardware token or compliant device gets blocked at the gate.
Break-glass accounts need strict isolation. Every organisation should have emergency access accounts that sit outside conditional access policies but are watched closely. These accounts exist for disaster recovery when normal admin access is gone. If every other admin account is compromised or locked down, the break-glass account is the fallback. It should be stored offline, monitored with instant alerting, and never used for routine admin work.
Alerts on bulk device management actions. Wiping a single lost laptop is a routine admin task. Wiping every enrolled device at once is not. Alerts on bulk MDM actions, particularly mass wipes, should trigger an instant response. The gap between "one device wiped" and "all devices wiped" is big enough for automated detection to catch, as long as someone has built the detection rule.
Separation of identity provider and MDM admin roles. If the same credential controls both the identity platform and the MDM platform, a single compromise gives the attacker both. Splitting these roles so that Entra ID Global Admins and Intune Admins are different accounts, held by different people, with different approval chains, reduces the single-point-of-failure risk.
None of these controls are new or theoretical. They are all in Microsoft's existing tooling. The question is whether they were turned on and enforced. Every organisation running Intune should be asking itself that right now.
What changed after
The short answer, as of 12 March 2026, is that we don't know yet. The incident is still active and CISA has launched an investigation. Acting director Nick Andersen stated: "We are working shoulder-to-shoulder with our public- and private-sector partners as we continue to uncover relevant information and provide technical assistance for the targeted attack on Stryker." No CISA advisory with IOCs or specific mitigation guidance for this attack had been published at the time of writing. Unit 42 noted that CISA was running at roughly 38% staffing due to a federal funding lapse, with the agency's website not actively updated since 17 February 2026.
Stryker's SEC filing stated that the incident "has caused, and is expected to continue to cause, disruptions and limitations of access to certain of the Company's information systems and business applications." The company hasn't given a timeline for full recovery or estimated the financial hit. A follow-up statement confirmed they still had visibility into orders placed before the attack and that shipments would restart once comms were restored.
The wider impact on BYOD policy is significant. If reports about personal device wipes are right, organisations that enrol employee-owned devices in MDM systems need to rethink what level of corporate control they hold over personal property. An MDM platform that can factory-reset a personal phone, wiping family photos, banking access, and personal messages, is a risk most employees don't grasp when they accept the enrolment prompt. The trust model that makes BYOD handy is the same trust model that makes this kind of damage possible.
This incident also raises questions about the wider threat picture. CISA, the FBI, DC3 (the DoD's cyber crime division), and the NSA issued a joint fact sheet in January 2026 warning that Iranian cyber actors may target vulnerable US networks. The FBI reissued that warning on 3 March 2026, calling out threats to healthcare and defence-adjacent organisations specifically. Stryker was hit just eight days after that warning.
Unit 42 tracked roughly 60 individual hacktivist groups as active in early March 2026, including pro-Russian groups alongside Iranian-linked personas. The Stryker attack may be the most visible incident so far, but it is unlikely to be the last.
Stryker hasn't confirmed the Intune attack vector, and the full technical details may not surface for weeks or months. But the pattern that anonymous sources describe, credential theft leading to abuse of a legitimate admin platform, is something every organisation with an MDM deployment should be testing against their own controls right now. You don't need to wait for the post-incident report to check whether your MDM admin accounts have standing Global Administrator privileges.
Related articles
- Active Directory Attacks Explained
- The CrowdStrike Outage: What Actually Happened
- Can AI Actually Do a Pen Test?
Get cybersecurity insights delivered
Join our newsletter for practical security guidance, Cyber Essentials updates, and threat alerts. No spam, just actionable advice for UK businesses.
Related Guides
The JLR Cyber Attack: How a Single Breach Contracted UK GDP
Inside the Jaguar Land Rover cyber incident that shut down production for five weeks, cost GBP 1.9 billion, and triggered the UK's first cyber-related government loan guarantee.
The Ivanti VPN Zero-Day: How a Buffer Overflow in a VPN Appliance Breached the UK's Domain Registry
In December 2024, a suspected Chinese state-sponsored group exploited CVE-2025-0282, a critical stack-based buffer overflow in Ivanti Connect Secure, to breach Nominet, the registry responsible for over 11 million .uk domain names. The vulnerability required no authentication. Five days after the patch was released, only 120 of 33,542 exposed appliances had been updated.
MuddyWater: How Iran's Intelligence Service Keeps Rebuilding Its Attack Infrastructure
The evolution of MuddyWater's command and control frameworks from Python to Go, how MOIS-linked operators target telecoms and government, and what each framework change reveals about detection pressure.
Ready to get certified?
Book your Cyber Essentials certification or check your readiness with a free quiz.