The Stryker Attack: No Malware Required

On 11 March 2026, employees at Stryker offices across dozens of countries turned on their computers and found them wiped. Login screens displayed the logo of Handala, an Iran-linked hacking group. By the time incident response teams had mobilised, thousands of devices had been erased across offices in 79 countries. Stryker, a Fortune 500 medical technology company employing around 56,000 people and reporting $25 billion in revenue for 2025, filed an 8-K disclosure with the SEC confirming a severe disruption to its Microsoft environment. CISA opened a formal investigation.

uh oh

The operational impact was immediate and broad. Stryker's order processing, manufacturing, and shipping were all disrupted, with no timeline given for full restoration. In Ireland, where Stryker employs around 5,500 people, its largest hub outside the United States, staff were sent home as internal networks went offline. Hospitals reported being unable to order surgical supplies through Stryker's systems. As a precautionary measure, some hospitals temporarily disconnected from Stryker's online services.

Handala claimed to have wiped more than 200,000 devices and exfiltrated 50 terabytes of data. Both figures should be taken with a grain of salt, threat intelligence firms including Palo Alto Networks have noted Handala's documented pattern of inflating breach claims. The operational disruption, however, is confirmed.

No Malware, No Software Exploit

Stryker was consistent across its public updates: there was no indication of ransomware or malware being deployed on its systems. The attack did not exploit a software vulnerability or use any novel technique. Instead, attackers used Stryker's own endpoint management platform, Microsoft Intune, against it.

Microsoft Intune is a cloud-based mobile device management (MDM) platform that gives IT administrators a centralised console to manage, configure, and control devices across an organisation. One of its features is the ability to remotely wipe enrolled devices. The attackers gained administrator-level access to Stryker's Intune environment and issued a mass remote wipe command to all enrolled devices. Bleeping Computer reported that the attackers also created a new global administrator account once inside, escalating their privileges to ensure the wipe could not easily be interrupted. Employees reported watching their devices erase in real time.

No custom tools or malware were deployed on individual endpoints. Every action taken was something a legitimate administrator could perform using the platform's built-in capabilities.

How the Credentials Were Obtained

The investigation into how the attackers obtained their initial credentials is ongoing, and no single cause has been confirmed. Researchers have identified several credible vectors.

Alon Gal, CTO of threat intelligence firm Hudson Rock, found that credentials associated with Stryker administrator accounts appeared in infostealer malware logs. These are databases of stolen credentials harvested by malicious software, packaged, and traded on criminal markets. Infostealer malware runs silently on an infected device, extracts saved passwords and session tokens, and sends them to the attacker. The victim typically has no indication anything has occurred.

Researchers at Lumos also noted that standard multi-factor authentication does not protect against adversary-in-the-middle (AiTM) phishing. In an AiTM attack, the victim completes a genuine MFA challenge on what appears to be a legitimate login page, but the attacker captures the session token issued after authentication completes. This bypasses MFA entirely without the attacker ever obtaining the MFA code itself. The only forms of MFA that defend against this technique are phishing-resistant credentials such as FIDO2 security keys or Windows Hello for Business.

Check Point Research separately observed hundreds of logon and brute-force attempts against VPN infrastructure linked to Handala in the period before the attack.

All three methods are consistent with Stryker finding no malware on its own systems. AiTM phishing and VPN brute-force involve no malicious code on Stryker devices at all. Infostealer malware does leave traces, but only on the device it infects. If that was a personal or contractor device rather than a Stryker-managed endpoint, it falls outside the scope of any internal forensic investigation. The investigation has not established which method, or combination of methods, was used to obtain the credentials that enabled access to Intune.

Why a Single Account Could Do So Much Damage

Microsoft Intune includes a multi-account approval feature for destructive actions, including remote wipe commands. When enabled, a second authorised administrator must approve a mass wipe before it executes. This control exists to prevent a single compromised account from issuing irreversible commands at scale. Based on the available evidence, this control was not enabled in Stryker's environment.

Whether the compromised account had MFA enabled is not publicly known. TechCrunch asked Stryker directly and received no response. It may also be the wrong question: if the attackers used AiTM phishing, standard MFA would not have protected the account. AiTM captures the authenticated session token after a legitimate MFA challenge completes, meaning MFA was passed correctly but the session was stolen immediately after. The only form of MFA that blocks this technique is phishing-resistant authentication such as FIDO2 security keys, which Microsoft's own hardening guidance, published on 13 March in direct response to the attack, explicitly requires for all privileged Intune roles.

Paddy Harrington, a senior analyst at Forrester, commented publicly that enforcing MFA on MDM access reduces the likelihood of a straightforward account takeover, and that the multi-account approval feature for wipe commands ensures no single account can make catastrophic changes unilaterally. Both controls are available within Intune as standard configuration options.

The scope of the wipe extended further than corporate devices. Employees reported that personal phones enrolled in Stryker's MDM to access corporate email or Microsoft Teams were also erased. When a personal device is enrolled in an enterprise MDM profile, it falls within the same management scope as a corporate device, and a remote wipe command applies to both. This is a known risk of BYOD policies that do not clearly separate personal device enrolment from the same MDM profiles applied to corporate assets.

A Prior Breach

In December 2024, Stryker disclosed a separate breach that had occurred between May and June 2024, involving approximately one month of unauthorised access during which personally identifiable information, including medical records, was exfiltrated. The breach was disclosed roughly six months after it was discovered.

Whether the 2024 incident and the March 2026 attack are connected has not been confirmed. Handala's logo appeared on login screens before the wipe executed, indicating that access had been established and held in advance of the destructive phase. Whether that access was newly obtained or linked to the earlier compromise remains under investigation.

What the Attack Illustrates

The Stryker incident shows what can happen when privileged access to a management platform is not adequately governed. No software vulnerability was exploited. The attack relied on valid credentials and a management console with the capability to wipe devices at scale, where the usual safeguards against that action had not been enabled.

The controls that could have limited the damage are configuration decisions available within the platform itself: Phishing resistant MFA on administrator accounts, multi-person approval for destructive actions, and defined boundaries around which devices should be enrolled in enterprise MDM profiles. For any organisation using cloud-based device management, the Stryker attack is a useful prompt to examine what a compromised administrator account could actually do, and what controls are in place to limit it.

This article reflects information available as of March 2026. The investigation is ongoing. Sources include reporting from SecurityWeek, Cybersecurity Dive, TechCrunch, KrebsOnSecurity, Bleeping Computer, Palo Alto Networks Unit 42, Check Point Research, Forrester, and Stryker's own public disclosures.