On March 11, 2026, someone logged into Stryker’s Microsoft Intune console using a valid administrator account and issued remote wipe commands to tens of thousands of Windows devices across dozens of countries.1 No malware. No exploit. No novel attack tool. The legitimate device management platform did the damage.
Handala, the Iran-linked group believed to operate under the Ministry of Intelligence and Security, claimed credit immediately.2 Stryker confirmed the incident disrupted manufacturing, order processing, and shipping globally.3 The FBI and CISA engaged at the executive level.4 Microsoft DART and Palo Alto Unit 42 were brought in for forensics.5
The first instinct in incidents like this is to ask whether MFA was configured. That framing misses the deeper structural problem. Whether MFA was absent or was bypassed by a more sophisticated technique, stolen credentials were sufficient to reach the Intune console. That is the vulnerability worth understanding.
What the evidence actually shows — as of March 18, 2026
Confirmed: An Intune administrator account was compromised and used to create a new Global Administrator account, which issued the wipe commands.1
Confirmed: No endpoint malware was deployed. Stryker’s SEC 8-K filing and public statements confirm attack was limited to the Microsoft environment.3
Confirmed: Credentials for Stryker administrator accounts appeared in infostealer malware logs, described by Hudson Rock’s Alon Gal as “months if not years old.”6
Confirmed: Stryker’s spokesperson declined to comment on MFA configuration when directly asked.7
Confirmed: Approximately 80,000 devices were wiped in a three-hour window between 5:00 and 8:00 AM UTC.1 Handala’s claim of 200,000+ is unverified.
Confirmed: Base64-encoded Intune wipe payloads were identified by Halcyon researchers.8
Not confirmed: The specific method used to compromise the admin account — including whether MFA was present and how it may have been bypassed. See note below.
3-stage horizontal flow: credential harvest (infostealer, months prior) → account compromise (Mar 11, ~05:00 UTC) → mass wipe (05:00–08:00 UTC, 80K devices). Clean, minimal, light background.
The Infostealer-to-Intune Path
What is established is the starting point: credentials belonging to Stryker administrator accounts were present in infostealer malware logs.6 Infostealer malware, distributed through phishing, malicious downloads, or compromised software, silently harvests credentials from infected machines and bundles them into logs that are sold or shared on criminal marketplaces. The credentials Handala likely used were old enough that rotation would have prevented the breach, if it had occurred.
What happened next, specifically how those credentials were used to successfully authenticate to Stryker’s Intune environment, is where confirmed evidence ends and informed analysis begins.
Editorial Note — AiTM as Conjecture
The following section describes Adversary-in-the-Middle (AiTM) phishing as a probable mechanism for how the admin account was compromised. This is the leading analyst hypothesis, not a forensically confirmed finding.
Multiple independent security firms, including Lumos Security, ThriveNextGen, and CMIT Solutions, have identified AiTM as consistent with Handala’s known tactics and the no-malware forensic outcome. Lumos explicitly labels it “Hypothesis 1 — the leading theory.” No public statement from Stryker, CISA, Microsoft DART, or Palo Alto Unit 42 has confirmed the specific bypass method as of March 18, 2026. The full forensic investigation remains non-public. This analysis presents AiTM as the most technically coherent explanation while acknowledging that absence of malware is also consistent with simple credential reuse if MFA was not configured.
How AiTM Phishing Defeats Standard MFA (Hypothesis)
If the leading analyst hypothesis holds, here is the mechanism. An AiTM attack places a proxy between the victim’s browser and the legitimate Microsoft login page.9,10 When the administrator enters their credentials and completes their MFA challenge, the proxy relays everything in real time to the real site. Microsoft authenticates successfully and issues a session token back to the proxy, which keeps a copy. The administrator sees a normal login. The attacker now holds a valid session token proving authentication already occurred. No further MFA challenge fires when they use it.
“The attacker does not defeat your MFA. They wait for your MFA to succeed once, then inherit the result.”
This is the structural limitation shared by every non-phishing-resistant MFA method: SMS codes, TOTP codes, and push notifications all result in a session token being issued to whoever successfully relayed the correct response. The token itself is the real credential, and it persists beyond the authentication event that created it.
CISA’s 2024 advisory AA24-242A addresses this directly, directing organizations to retire OTP and SMS-based MFA in favor of phishing-resistant methods because session token reuse makes legacy MFA insufficient against adversaries who deploy proxying techniques.11 The Zero Trust Maturity Model defines the appropriate posture as continuous phishing-resistant validation, not a one-time gate at login.12
Infostealer malware takes a related but distinct path. Tools like Lumma, which saw a 369% detection surge in the second half of 2024,13 extract active session tokens directly from the browser’s local cookie store alongside passwords. An attacker who imports those tokens inherits an authenticated session without any login prompt. Both techniques, AiTM and cookie theft, defeat standard MFA without exploiting any flaw in the MFA system itself.
Two-panel diagram: AiTM Attack Path (left, red) vs. Certificate-Based Authentication Defense (right, green). Shows the full flow from phishing email through session token capture to Intune wipe, and how TPM-bound private key breaks the chain. Main explanatory visual of the article.
Left: How AiTM captures a valid session token after MFA fires. Right: why a TPM-bound private key gives a proxy nothing to capture or replay.
What Certificate-Based Authentication Changes
Certificate-Based Authentication for Microsoft Entra ID operates on a fundamentally different principle. Instead of producing a code or approving a push notification, authentication is performed by signing a cryptographic challenge using a private key. That private key never leaves the hardware it was generated on, whether a TPM chip, a YubiKey, or a smart card.14
There is nothing to relay. An AiTM proxy can intercept the challenge, but it cannot produce a valid signature using a key it does not have. An infostealer can read the browser cookie store, but it cannot export a non-exportable private key from a TPM. The proxy holds nothing. The attack chain breaks before a session token is ever issued to the attacker.
In a CBA-enforced Entra environment, the attack path changes structurally. A stolen password from a years-old infostealer log is insufficient without the bound certificate. A captured session token loses value when Conditional Access policies require fresh certificate-based proof for privileged actions. Creating a new Global Administrator account requires authenticating with a certificate the attacker does not possess.
For Microsoft Intune specifically, the integration extends further. Device certificates issued through Intune’s SCEP connector bind device identity to a CA-issued credential.14 Conditional Access policies can require that MDM commands be honored only from devices presenting valid, current certificates. An attacker controlling an admin account but lacking access to the issuing certificate authority cannot provision those credentials. Without them, wipe commands either fail compliance validation or surface as anomalies.
The Credential Hygiene Argument is a Distraction
After the Stryker details emerged, much commentary focused on the age of the credentials. Alon Gal of Hudson Rock noted that Handala “likely just used infostealer logs” and that Stryker had “more than enough time” to rotate the stolen credentials.6 This is accurate. It is also an incomplete prescription.
A global enterprise with tens of thousands of employee accounts cannot realistically detect and rotate every credential that surfaces in infostealer marketplaces, across every Microsoft service and MDM instance, on a timeline that closes the window before a nation-state-adjacent group acts on it. Credential rotation is a maintenance task measured in months. Adversary dwell time in infostealer ecosystems is also measured in months. The treadmill does not favor defenders at scale.
The structural fix is to make stolen passwords and captured session tokens insufficient by design, not to demand operational perfection from security teams working with authentication architecture that was not built to handle this threat model.
What This Incident Actually Signals
This will not be the last time a group weaponizes legitimate MDM tooling. Intune, JAMF, and similar platforms are built for mass remote management. For an attacker holding valid admin credentials, they are equally available for mass destruction. The same API surface that lets an IT team push patches to 80,000 devices allowed Handala to wipe them in three hours.
The relevant question for every enterprise running Microsoft Intune is not whether their passwords are current. It is whether their authentication architecture makes a stolen credential, or a captured session token, sufficient to reach the console at all.
CISA’s answer, stated explicitly in its phishing-resistant MFA guidance, is that it should not be.11 Certificate-Based Authentication with hardware-bound keys closes that gap, not as a supplement to password-plus-MFA, but as a replacement for any authentication model that produces something replayable through a compromised environment.
The Stryker incident is a specific, named, publicly reported data point for what happens when the trust model does not match the threat model. Whether the admin account was compromised by credential reuse alone, by AiTM session token capture, or by some combination, the outcome is identical: the authentication model accepted something the attacker could obtain. That is the problem CBA is designed to eliminate by construction.
The question is how many 80,000-device wipes it takes before enterprises treat authentication architecture as infrastructure rather than a compliance checkbox.
Tim McAllister is Field CTO at DigiCert, where he leads technical strategy for Device Trust and enterprise PKI. He is active in standards bodies including NIST, SAE EVPKI, CharIN, and SEMI, and works with enterprise OEM customers on CRA/RED compliance, post-quantum cryptography, and device identity.
DigiCert’s Trust Lifecycle Manager integrate natively with Microsoft Entra ID for Certificate-Based Authentication and with Microsoft Intune via SCEP/PKCS for device certificate enrollment.
Sources and Attribution
Lawrence Abrams, “Stryker attack wiped tens of thousands of devices, no malware needed,” BleepingComputer, March 2026. Primary sourced from a person familiar with the incident. Confirms: Intune admin account compromised, new Global Admin created, ~80,000 devices wiped 05:00–08:00 UTC. PRIMARY SOURCE
“Iran-Linked Hacker Attack on Stryker Disrupted Manufacturing and Shipping,” SecurityWeek, March 11, 2026. Handala claim; notes MOIS attribution. CONFIRMED
Stryker Corporation, SEC 8-K filing and public incident updates, March 11–15, 2026. Confirms: attack limited to Microsoft Windows environment; no malware or ransomware found; manufacturing, order processing, and shipping disrupted. PRIMARY SOURCE
“Stryker says it’s restoring systems after pro-Iran hackers wiped thousands of employee devices,” TechCrunch, March 17, 2026. Confirms CISA, FBI, and HHS engagement. Also notes Stryker spokesperson declined to comment on MFA configuration. CONFIRMED
BleepingComputer (op. cit., fn 1). Microsoft DART and Palo Alto Unit 42 named as forensic leads. CONFIRMED
Alon Gal (CTO, Hudson Rock), LinkedIn post, March 2026. Analysis of infostealer malware logs revealing Stryker administrator credentials. Direct quote: “Handala really aren’t sophisticated and likely just used infostealer logs for the Stryker breach. Most of these creds are months if not years old.” Reported by Eduard Kovacs, SecurityWeek, March 18, 2026. CONFIRMED
TechCrunch, March 17, 2026 (op. cit., fn 4). Spokesperson “declined to comment” on MFA configuration. No primary source has confirmed whether MFA was present or absent. CONFIRMED
Halcyon Research, via Ground News, March 2026. Identification of base64-encoded Intune remote-wipe payloads in the attack. CONFIRMED
Lumos Security, “Stryker Hack Analysis,” March 2026. Explicitly labels AiTM phishing as “Hypothesis 1 — the leading theory” among several possible initial access vectors. Other hypotheses include VPN credential brute force and supply chain access. ANALYST HYPOTHESIS
ThriveNextGen, “The New Battlefield: How Iran’s Handala Group Crippled Stryker Corporation,” March 2026. Describes AiTM as the attack chain step: “Attackers deployed Adversary-in-the-Middle phishing to capture authenticated Entra session tokens, completely bypassing MFA without the victim receiving any notification.” No forensic citation provided; framed as TTP-consistent inference. Also referenced: CMIT Solutions blog, March 2026, which asserts SMS-based 2FA was in use — again without forensic sourcing. ANALYST HYPOTHESIS
CISA, “Advisory AA24-242A: Guidance on Phishing-Resistant Multi-Factor Authentication,” 2024. Directs retirement of OTP and SMS-based MFA in favor of phishing-resistant methods. OFFICIAL GUIDANCE
CISA, “Zero Trust Maturity Model v2.0,” 2023. Defines optimal authentication posture as continuous phishing-resistant MFA validation. OFFICIAL GUIDANCE
ESET Threat Report H2 2024. Reports 369% detection surge in Lumma infostealer activity; notes Redline takedown and shift in infostealer landscape. THREAT RESEARCH
Microsoft Learn, “Certificate-based authentication in Azure Active Directory / Entra ID,” and “Configure SCEP certificate profiles in Microsoft Intune,” Microsoft documentation, 2024–2025. VENDOR DOCUMENTATION