The Stryker Wiper Attack: Why Every MSP Should Be Rethinking M365 Admin Security

Overnight on March 11, 2026, an attacker logged into Stryker Corporation’s Microsoft Intune console with valid administrative credentials. Over the next several hours, they issued remote wipe commands — not to a handful of devices, but to the entire managed fleet. By the time employees arrived at work the next morning, over 200,000 laptops, phones, desktops, and servers across 79 countries had been factory reset, according to the threat group’s claims.

There was no ransomware. No malware payload. No EDR alert. The attacker had used Stryker’s own device management platform — the same tool IT administrators use every day to push policies, deploy software, and yes, wipe lost devices — as the weapon itself.

Stryker, a Fortune 500 medical technology company with $25.1 billion in annual revenue and approximately 51,000 employees, filed an SEC 8-K disclosure that same evening, confirming “global disruption to the company’s Microsoft environment.” A week later, restoration was still underway with no projected completion date. The Iran-backed threat group Handala, assessed by Palo Alto Networks Unit 42 to be affiliated with Iran’s Ministry of Intelligence and Security, claimed responsibility.

The details of how they got in tell a story that should be familiar to anyone managing Microsoft 365 environments.

It Started with an Infostealer

According to analysis from Coalition’s security labs and other researchers, the initial compromise was not sophisticated. Infostealer malware — the kind that circulates in massive volumes through phishing emails, malicious ads, and cracked software downloads — captured credentials from an employee’s workstation. Among the harvested data were SSO login tokens, internal ITSM platform access, and enterprise password manager entries.

Those credentials likely ended up for sale on an initial access broker marketplace, where Handala-affiliated operators purchased them. From there, the path to Intune was short. The attackers authenticated into Stryker’s identity environment, escalated to an Intune administrator role, and gained access to the one console that could touch every managed device in the organization.

What happened next did not require any malware development, exploit research, or custom tooling. The attackers simply used the “Remote Wipe” function that Microsoft built into Intune — the same button any Intune admin can click to factory reset a lost laptop. They just clicked it 200,000 times.

The Security Stack That Didn’t Fire

This is the part of the Stryker story that deserves the most attention from MSPs and IT leaders, because it challenges a core assumption about how we defend environments.

Stryker almost certainly had endpoint detection and response (EDR) software deployed. They likely had next-generation antivirus, SIEM integration, and a security operations capability appropriate for a company their size. None of it mattered.

The wipe commands arrived at each endpoint as a legitimate administrative instruction from a trusted Microsoft service. From the device’s perspective, there was no difference between an IT admin wiping a stolen laptop and an attacker wiping the entire fleet. The command came through the same channel, signed by the same authority, executed by the same agent. EDR has no reason to block a command from the management platform it is designed to coexist with.

This is what makes living-off-the-land attacks so effective. The attacker never introduced a foreign tool into the environment. They operated entirely within the boundaries of what the system considers normal administrative behavior. The only anomaly was the scale — and nothing was configured to watch for that.

The MSP Angle No One Is Talking About Enough

The cybersecurity press has covered the Stryker attack primarily as an enterprise incident — a nation-state actor hitting a Fortune 500 company. That framing misses the more pressing risk.

MSPs operate the exact same management plane that was weaponized at Stryker. Microsoft Intune, Entra ID, Exchange Admin Center, SharePoint admin consoles — these are the daily tools of managed service delivery. And MSPs hold something Stryker did not: delegated administrative access across dozens or hundreds of client tenants.

A compromised MSP technician workstation — infected by the same commodity infostealer malware that initiated the Stryker breach — could expose admin credentials not to one Intune environment, but to every client the MSP manages. The blast radius is not one company. It is the MSP’s entire client base.

This is the Kaseya VSA attack pattern applied to Microsoft’s management plane. The difference is that Kaseya required a zero-day vulnerability. An Intune-based attack requires only stolen credentials and the absence of a few specific controls — controls that most organizations have available but have not yet enabled.

Five Controls That Were Already Available

Every defensive measure that could have prevented or limited the Stryker attack existed in Microsoft’s platform before March 11. None of them required additional licensing beyond what a company of Stryker’s size would already own. None of them are particularly difficult to implement. And every one of them is covered by the CIS Microsoft 365 Foundations Benchmark.

Phishing-resistant MFA is the first and most impactful. Standard MFA — push notifications, SMS codes, authenticator app approvals — has known weaknesses. Adversary-in-the-middle phishing kits can intercept MFA tokens in real time, and MFA fatigue attacks (sending repeated push notifications until the user approves one) have been documented in dozens of breaches. The CIS M365 Benchmark recommends FIDO2 security keys or certificate-based authentication for all administrative accounts. A hardware key cannot be phished, intercepted, or approved out of fatigue. If Stryker’s Intune admins had been required to tap a YubiKey to authenticate, the stolen password would have been useless.

Privileged Identity Management (PIM) addresses a different part of the problem. In most M365 environments, administrative roles are permanently assigned — an Intune admin is always an Intune admin, 24 hours a day, whether they are actively working or not. PIM changes this to a just-in-time model. Admins must explicitly activate their privileges for a defined time window, with optional approval workflows and forced reauthentication. When no one has activated the Intune Administrator role, there is no standing privilege for an attacker to exploit. The credentials might be valid, but the role is not active, and activating it requires a second administrator’s approval.

Conditional Access policies layer additional context onto every authentication event. The CIS Benchmark recommends policies that evaluate device compliance, network location, sign-in risk score, and session behavior before granting access to administrative consoles. The Stryker attackers were logging in from outside the company’s normal administrative context — likely from infrastructure in a different country, on unmanaged devices, at unusual hours. A Conditional Access policy scoped to admin roles would have blocked or challenged those sessions before the attacker ever reached the Intune console.

Unified audit logging with alerting provides the detection layer that EDR could not. Intune logs every administrative action, including device wipe commands. An organization monitoring those logs for anomalous patterns — hundreds of wipe commands in rapid succession, administrative sessions from unfamiliar geolocations, bulk actions executed outside business hours — would have had a window to detect and interrupt the attack. The CIS Benchmark requires not just that audit logging is enabled, but that retention periods are sufficient and that alert policies are configured for high-risk administrative events.

Multi-admin approval for destructive actions is perhaps the simplest control that would have had the greatest impact. Microsoft Intune supports requiring a second administrator to approve high-impact operations like device wipes, script deployments, and RBAC changes before they execute. With this enabled, a single compromised admin account cannot unilaterally wipe the device fleet. The attack stops at the approval gate. This feature has been available in Intune for over a year. Enabling it is a configuration change that takes minutes.

The Gap Between Available and Enabled

Every one of those controls was available. None of them were enabled — at least not in a configuration that stopped the attack.

This is not unique to Stryker. It is the normal state of affairs in organizations of every size, and it is the central reason that periodic CIS Benchmark assessments matter.

Microsoft ships new security features into M365 and Intune continuously. Multi-admin approval, PIM activation policies, token protection in Conditional Access, phishing-resistant authentication methods — these capabilities arrive through product updates, sometimes with announcements, sometimes buried in release notes. Internal IT teams, fully occupied with tickets, projects, and keeping the lights on, rarely have the bandwidth to audit which new controls have become available since their last configuration review.

The CIS M365 Foundations Benchmark is updated to track these changes. When Microsoft introduces a new hardening capability that meets the threshold for inclusion, CIS adds or updates the relevant control. A third-party assessment conducted against the current benchmark version will surface gaps that an internal team — working from configurations established months or years earlier — may never think to revisit.

This is not a criticism of internal IT teams. It is a structural reality. The people responsible for maintaining the environment are not the same people tracking the evolving benchmark. A third-party assessor’s entire job is to know the current state of the benchmark and measure environments against it. They also bring a cross-environment perspective that no single internal team can replicate — pattern recognition from assessing dozens of tenants, awareness of which misconfigurations appear most frequently, and practical knowledge of which remediations deliver the highest risk reduction for the least operational disruption.

There is also the question of evidence. A formal CIS assessment produces a documented baseline, a scored report, and a prioritized remediation roadmap. That documentation has value beyond the immediate security improvement: cyber insurance carriers increasingly ask for evidence of benchmark alignment, compliance frameworks reference CIS controls, and clients — especially in regulated industries — want assurance that their MSP’s management practices meet a recognized standard.

What This Means Going Forward

The Stryker attack is a turning point in how we think about wiper threats. Previous high-profile wipers — NotPetya in 2017, WhisperGate and HermeticWiper in 2022 — all relied on custom malware. They overwrote master boot records, corrupted file systems, or destroyed disk partitions using purpose-built code. That code could eventually be signatured, detected, and blocked by security vendors.

The Stryker attack needed no custom code at all. It weaponized the victim’s own management infrastructure. There is no signature to write for “an admin clicked the wipe button.” The detection and prevention must happen upstream — at the identity layer, the access control layer, and the administrative governance layer.

For MSPs, this reframes the security conversation. Endpoint protection remains necessary, but it is no longer sufficient as a primary defense against the most damaging category of attacks. The management plane — Intune, Entra ID, Exchange Admin, SharePoint Admin, every console with the ability to modify or destroy client environments — must be treated as a critical attack surface in its own right.

That means phishing-resistant MFA on every admin account, PIM for every privileged role, Conditional Access scoped to every administrative portal, audit logging with real-time alerting on every destructive action, and multi-admin approval wherever the platform supports it. It means GDAP instead of DAP, role-scoped permissions instead of Global Admin, and separate admin accounts for each client tenant.

And it means validating all of it on a regular cycle — not through self-assessment against a checklist you last updated a year ago, but through a formal review against the current CIS Benchmark, conducted by someone whose job it is to know what “current” looks like.

The controls that would have stopped the Stryker attack are not expensive. They are not disruptive. They are not difficult to implement. They were already available, sitting in the platform, waiting to be turned on. The only thing missing was someone to identify them, prioritize them, and make the case to enable them.

That is what a CIS M365 Benchmark assessment does. And after Stryker, the cost of not doing one is a lot harder to justify.

---

Genesis Solutions provides CIS M365 Benchmark assessments with 100% control coverage — manual and automated. Contact us to schedule an assessment for your organization or your MSP clients.