TL;DR: A pro-Iran group wiped roughly 80,000 Stryker devices across 79 countries using Microsoft Intune. No custom malware, just a compromised admin account and a remote wipe command. The credentials were likely stolen by infostealer malware. Separately, a French healthcare vendor breach exposed 15.8 million patient records from practices that had no security failure of their own. Together they highlight two things: wiper attacks don’t follow the ransomware playbook, and operational dependencies on vendors and management platforms often carry more risk than organizations have formally accounted for.
Key Takeaways#
- A pro-Iran group wiped ~80,000 Stryker devices across 79 countries in three hours using Microsoft Intune’s built-in remote wipe feature — no custom malware, just a compromised admin account
- BYOD devices enrolled in the MDM were wiped too: personal photos, banking apps, authenticator tokens, eSIMs — because BYOD enrollment agreements allow it
- Android work profiles and iOS User Enrollment both limit a corporate remote wipe to the managed partition only; request these instead of full device enrollment
- Wiper attacks have no ransom negotiation phase; recovery means rebuilding your entire device fleet from scratch across however many countries you operate in
- Standard business interruption insurance excludes acts of war — if your operations depend on cloud services or MDM-managed endpoints, talk to your broker about whether you have a gap
At 5:00 AM UTC on March 11, someone logged into Stryker’s Microsoft Intune console using compromised credentials, created a new Global Administrator account for persistent access, and spent the next three hours issuing remote wipe commands across Stryker’s entire endpoint management system. By 8:00 AM, approximately 80,000 devices had been factory reset across offices in 79 countries. The attacker group Handala claimed the number was closer to 200,000.
Handala is Iran-linked and said the attack was retaliation for a February 28 US missile strike on an Iranian school. There was no ransom demand. Stryker’s electronic ordering systems remain unavailable as the company works through recovery.
How they got in#
Analysis of infostealer malware logs found harvested credentials for Stryker admin accounts alongside other Microsoft service and MDM credentials. Palo Alto Networks researchers point to either phishing or infostealer malware as the likely initial vector. Stryker hasn’t confirmed it publicly, but the infostealer theory has the most evidential support. The attackers used those credentials to log into Intune, created a new Global Admin account for persistent access, then issued the mass wipe.
The attack itself required no novel technique. Intune’s remote wipe is a standard feature, designed for lost or stolen devices. An account with the right permissions can issue that command to the entire device fleet simultaneously. That’s also what makes admin access to MDM platforms worth protecting carefully.
CISA published guidance today on securing Intune environments; The Register has the specifics. The same logic applies to any platform used to manage infrastructure at scale: your RMM, your cloud console, your identity provider. Compromising the admin layer is a force multiplier that compromising individual endpoints isn’t.
The BYOD problem#
Stryker runs a BYOD program, which meant personal phones enrolled in the MDM were in scope for the wipe command. Those devices were reset too: personal photos, banking apps, eSIMs, authenticator tokens. All of it.
BYOD enrollment agreements generally acknowledge the company can remotely wipe a device. That language was written with device loss in mind, not a geopolitical wiper attack. The blast radius of a BYOD program is larger than the policy documentation usually reflects, and it’s a design question worth revisiting deliberately rather than discovering mid-incident.
The vendor angle#
The Stryker attack was a direct strike on Stryker’s own infrastructure. An earlier incident this year illustrates the other vector.
We’ve written before about third-party risk as a compliance and procurement concern. The Cegedim Santé breach shows what it looks like operationally. Cegedim makes practice management software used by around 3,800 physicians in France. When attackers breached their systems, roughly 15.8 million patient records were exposed. The practices whose patients were affected had no security failure of their own. And when the vendor’s systems went down, those practices couldn’t access records or medication histories.
Vendor risk assessments ask whether a vendor meets a security baseline. They’re useful for that. They don’t answer what your operations look like when a critical vendor is unavailable for a week, or when your own management platform is the thing that’s been compromised. Those are resilience questions that require separate analysis.
This isn’t a ransomware problem#
Most incident response plans are built around the ransomware model: detect, contain, negotiate, restore. There’s a certain predictability to it because the attacker wants payment and you want your systems back.
Wiper attacks don’t have that middle. The goal is disruption, not revenue, so there’s nothing to negotiate. Recovery means rebuilding your device fleet from scratch, re-provisioning your workforce across, in Stryker’s case, 79 countries. How fast that goes depends almost entirely on decisions made before the attack: backup architecture, device provisioning automation, and whether critical processes have manual fallbacks that people have actually practiced.
What employees in BYOD programs can do#
If your employer requires you to enroll your personal device, it’s worth understanding what that actually gives them access to, and what options you have to limit your personal exposure.
The most robust option on Android is enabling a work profile. Android Enterprise’s work profile creates a hard OS-level separation between personal and work data. Your employer’s MDM controls only the work profile; a remote wipe command removes the work profile and everything in it without touching your personal apps, photos, or accounts. If your employer uses a modern MDM that supports work profiles (most do), ask IT to set it up this way instead of enrolling the full device.
On iOS, User Enrollment (available since iOS 13) works similarly. It creates a separate managed partition for work data that can be wiped independently of your personal data. It also limits what your employer can see; under User Enrollment, IT cannot view personal apps or device identifiers. If your company uses Intune, Jamf, or most other enterprise MDMs, User Enrollment is an option worth requesting.
If neither of those is available, the technique worth knowing is using containerized apps instead of full device enrollment. Many MDM platforms support app-level management (MAM without MDM), where your employer’s policies apply to specific apps like Outlook or Teams rather than to the device itself. A corporate remote wipe in this model removes only those apps and their data, not your device. Using a third-party mail client that authenticates against your work Exchange account via standard protocols, rather than enrolling in the MDM directly, achieves a similar outcome: the company can revoke your account access but cannot issue a device wipe command. Whether your employer allows this depends on their policy, so it’s worth clarifying before you assume it’s permitted.
One important caveat: all of the above applies to personally owned devices. If your employer issued the device, the protections above likely don’t apply even if a work profile is in use. Corporate-owned devices enrolled under Android’s COPE (Corporate-Owned, Personally Enabled) model support work profiles but retain full factory reset capability for the IT department. The OS doesn’t block it because the device isn’t yours. This is a good reason to keep personal data, personal accounts, and personal apps off employer-issued hardware entirely. The convenience isn’t worth it if the device can be wiped at any time for any reason, including a geopolitical incident your employer had nothing to do with.
The practical ask: before enrolling any personal device in a corporate MDM, find out what enrollment type is being used and what a remote wipe would actually affect. IT should be able to tell you. If the answer is “full device wipe,” that’s worth knowing, and work profile or MAM-only enrollment is a reasonable alternative to request.
What organizations can do#
- Enforce phishing-resistant MFA on all admin accounts, particularly for MDM, identity, and cloud management consoles. Infostealer-harvested credentials are useless if MFA can’t be bypassed. Hardware keys or passkeys are preferable to TOTP where admin access is concerned.
- Audit who holds Global Admin or equivalent roles in your endpoint management and identity platforms. These accounts should be few, tightly scoped, and accessed from dedicated workstations rather than general-use machines where infostealer infections are more likely.
- Review what a mass wipe command would actually reach in your environment: which devices, whose devices, and what the re-provisioning timeline looks like. If you haven’t modeled it, the Stryker recovery is a useful forcing function.
- Revisit your BYOD policy with this specific scenario in mind. Segmenting personal devices from full MDM management (using app-level management instead, for example) limits personal blast radius while preserving most of the productivity benefit.
- Know your critical vendor dependencies and what happens when they’re unavailable. Vendor risk questionnaires tell you about a vendor’s security posture. A separate conversation is needed about your own operational resilience if they go down.
- Test your IR plan against a wiper scenario, not just ransomware. The decision points are different and the clock moves faster.
Greymantle Risk Advisory helps organizations assess and harden their privileged access controls, endpoint management architecture, and vendor resilience posture. We work with leadership teams to translate threat intelligence into decisions that actually affect organizational risk.