Stryker wiper attack: hardening admin tools against Iran-linked destructive intrusions

In March 2026, attackers linked to Iran wiped tens of thousands of employee devices at medical technology maker Stryker. According to a source BleepingComputer spoke to, they didn't deploy custom wiper malware. They used Microsoft Intune's own remote-wipe command from a compromised administrator account. For engineering and IT teams the takeaway is that the most destructive tool in your environment may be one you already run, and protecting it matters more than any one malware signature.

What happened

Stryker disclosed the incident on 11 March 2026. Devices were wiped between about 05:00 and 08:00 UTC that day. The Handala persona, which security researchers link to Iran's Ministry of Intelligence and Security (MOIS) and the Void Manticore activity cluster, claimed responsibility and called it retaliation for US–Iran tensions.

BleepingComputer's source said the attacker first compromised an administrator account, created a new Global Administrator, and then issued Intune wipe commands. Nearly 80,000 devices were hit, including personal phones and laptops enrolled in company management. Stryker's own updates referred to "tens of thousands" of devices. The company said the attack was limited to its internal Microsoft environment and that its medical products remained safe to use. Electronic ordering was offline for a time, so customers had to order through sales representatives. Microsoft's Detection and Response Team and Palo Alto Networks Unit 42 were brought in to investigate. Stryker first said no malware was involved. A 23 March update said the attacker had used a malicious file to run commands and hide activity. Handala's claims of 200,000 wiped systems and 50 TB of stolen data were not supported by investigators.

CISA then urged organizations to harden Intune and other endpoint management systems. Its recommendations included least-privilege RBAC, Conditional Access and MFA for privileged actions, and multi-admin approval for destructive operations such as device wipes.

The original version of this article was sponsored content from a network segmentation vendor. The pattern it described is consistent with public research on Handala and Void Manticore: stolen credentials, hands-on-keyboard operators, lateral movement over RDP, PowerShell remoting, WMI, SMB and SSH, and tunnelling tools such as NetBird for persistent access.

Who is affected

• Organizations that manage devices with Intune or another MDM/UEM platform, where a single admin role can wipe the whole fleet.
• Cloud identity tenants (Entra ID, Okta, Google Workspace) where a Global Administrator, or anyone able to create one, controls everything downstream.
• Companies with a geopolitical profile: US and Israeli firms, defense and healthcare suppliers, and critical infrastructure. Iran-linked groups have historically focused on these.
• Employees with personal devices enrolled under BYOD policies that allow a full wipe rather than a selective wipe.

What it means for developers and engineering teams

Most destructive attacks don't need sophisticated malware. They need privileged access to a system that already does destructive things by design: an MDM wipe, a cloud API that deletes resources, a CI pipeline with production credentials, or kubectl delete with cluster-admin. EDR tools look for malicious binaries. A legitimate admin console sending a legitimate command, signed by Microsoft, raises no alert.

That changes the design goal. Treat high-impact admin actions the way you treat production deploys: require a second approver, rate-limit them, and alert on bulk operations. Intune now supports multi-admin approval. Cloud providers offer similar guardrails, such as AWS service control policies and deletion protection on databases and buckets. Platform teams can apply the same idea in their own tooling with break-glass roles, just-in-time elevation and a hard cap on how many resources one call can destroy.

Recovery is the other half. If thousands of laptops are wiped, how fast can you re-enroll them? If your identity provider is compromised, can you still reach your source code, secrets and runbooks? Stryker kept its products safe because the attack stayed inside corporate IT. Many SaaS companies don't have that separation between corporate identity and production.

What to do now

1. Turn on multi-admin approval in Intune (or your MDM's equivalent) for device wipe, retire and RBAC changes.
2. Reduce standing Global Administrators to a small break-glass set and use just-in-time elevation (for example Entra Privileged Identity Management) for everything else.
3. Require phishing-resistant MFA (FIDO2 or passkeys) for admin roles, and limit admin sign-ins to managed, compliant devices with Conditional Access.
4. Alert on bulk destructive actions and on new privileged role assignments. For example, send Entra audit logs for "Add member to role" and Intune wipe actions to your SIEM with a low threshold.
5. Default-deny admin ports (RDP 3389, WinRM 5985/5986, SMB 445, SSH 22) between workstations, and watch for tunnelling tools such as NetBird.
6. Separate production from corporate identity so that compromising the corporate tenant doesn't give cloud-admin access to production.
7. Rehearse recovery: time a bulk device re-enrollment and an identity-provider-down scenario, and keep offline copies of critical runbooks.

Related on TechLogHub

• Authorization
• Authentication
• OAuth

Sources

• BleepingComputer: Stryker attack wiped tens of thousands of devices, no malware needed
• BleepingComputer: CISA warns businesses to secure Microsoft Intune systems after Stryker breach
• LevelBlue SpiderLabs: Stryker attack highlights Handala's shift from espionage to disruption
• BleepingComputer (sponsored by Zero Networks): A five-step playbook to stop Iranian wiper campaigns