threatintel
actor tracker
All briefs

Stryker, Handala, and the rise of MDM-abuse-as-wiper

Author: Thomas Malinowski Published: 2026-05-16 Status: OSINT synthesis, primary sources cited inline Tags: Iran, MOIS, Handala, Void Manticore, Stryker, MDM, Intune, wiper, medical-devices

Bottom line up front

On 11 March 2026, Stryker Corporation — one of the world's largest medical-device manufacturers (~$22B revenue, 51,000 employees) — disclosed a destructive cyberattack that disrupted its global internal networks and Microsoft systems and that the company subsequently confirmed materially impacted its Q1 2026 earnings. The attack was claimed by Handala, a pro-Palestine hacktivist persona that multiple credible vendor analyses (Check Point Research, Palo Alto Unit 42, Recorded Future) assess as one of the online identities operated by Void Manticore — an Iranian Ministry of Intelligence and Security (MOIS) intrusion set.

The technical detail that matters most about the Stryker incident is not that it happened, or that 200,000+ devices were wiped — both unsurprising for a destructive Iranian operation against a Western manufacturing target in the post-October-2023 environment. The detail that matters is how the wipe was achieved: open-source reporting indicates the operators reached Stryker's Microsoft Intune tenant and used Intune's legitimate device-management surface to issue a remote-wipe command against enrolled endpoints — laptops, phones, and managed workstations — at fleet scale.

This is the first publicly-disclosed major incident in what this analyst now expects to be a class: MDM-abuse-as-wiper. The implications extend well beyond Stryker.

What we know about the operation

AttributeDetail
Disclosed11 March 2026, Stryker customer letter
Attribution (claimed)Handala (the persona's own claim, on its Telegram channel)
Attribution (assessed)Iran MOIS-affiliated, via the Void Manticore umbrella (Check Point, Unit 42, RF)
Stated motivationRetaliation "for the brutal attack on the Minab school" — referencing the December 2025 Israeli airstrike in southeastern Iran
ScopeStryker's own claim of impact: global internal networks and Microsoft systems disrupted; Q1 2026 earnings impacted
Handala's claim200,000+ devices wiped
Initial accessNot publicly confirmed by Stryker. Coalition's analysis raises infostealer-sourced credentials as a probable vector — consistent with the broader 2024-2026 pattern of cybercrime infostealer logs feeding state-aligned operations
Pivot to wipeOperators reached Stryker's Microsoft Intune tenant and issued a remote-wipe command across the enrolled device fleet
Class of attackDestructive, not extortive. No ransom demand. No leak-site posting beyond the persona's own Telegram bragging.

Why MDM-abuse-as-wiper is a new class

Mobile Device Management platforms — Microsoft Intune, Jamf, Workspace ONE, Kandji, Hexnode — exist to give an organization's IT department a single console from which it can issue destructive commands as a matter of routine: factory-reset a stolen laptop, selectively wipe a former employee's BYOD phone, force-rotate a compromised device. The destructive primitive is not a bug. It is the product.

For an attacker who reaches the MDM tenant, three things happen at once:

  1. No exploit is required. The attacker does not need to drop a wiper binary, evade EDR on each endpoint, or find privileged credentials on each host. The legitimate, signed, vendor-blessed "wipe" feature does the destruction.
  2. The blast radius is the entire enrolled fleet. Whatever scope the MDM tenant manages — five thousand laptops, fifty thousand phones, all of the above — the operator inherits in a single click.
  3. Endpoint controls are categorically unhelpful. The wipe command arrives over the legitimate management channel from a trusted tenant. EDR sees nothing to block. The endpoint sees a policy directive from its own administrator and obeys.

The defensive surface against this pattern is therefore not the endpoint — it is the MDM tenant itself. And on that surface, many large enterprises are weaker than they realise.

How a Stryker-class organization gets here

Reconstructing the most plausible kill chain from public reporting plus standard Intune defaults:

  1. Initial access. A Stryker employee, contractor, or an integrated MSP staff member runs an infostealer (commodity, distributed via SEO poisoning or trojanised software). The stealer harvests browser-stored Microsoft 365 credentials and active session tokens and exfiltrates them to an infostealer-log marketplace. Operators harvest those logs and identify a session belonging to an account with privileged roles in Stryker's Microsoft 365 tenant.
  2. MFA bypass via session hijack. The harvested session token itself often carries the MFA assertion. The operator replays it from a residential-proxy egress to avoid impossible-travel detection.
  3. Privilege check. The operator enumerates role assignments, looking for Intune Service Administrator or Global Administrator — both of which can issue device-wipe commands. In a tenant where role hygiene is loose and Privileged Identity Management (PIM) just-in-time elevation is not enforced, these accounts often have standing privilege sufficient for the wipe.
  4. Wipe. Via the Intune Devices blade or via the Graph API microsoft.graph.managedDevice/wipe action, the operator issues wipe against every enrolled device. The Graph endpoint accepts a single privileged call; the fan-out happens server-side at Microsoft's MDM service. There is no opportunity to interrupt or roll back.
  5. Bragging. Handala posts on Telegram. Stryker discloses.

The fragility of step (3) is the lever. Standing Global Admin or Intune Service Admin, no PIM, no break-glass-only enforcement, no Conditional Access policy requiring a managed device to manage devices — all of these are configuration defaults that experienced M365 administrators routinely fail to harden. The operator does not need a zero-day. The operator needs a tenant administered to the median.

Defender takeaways

Every recommendation below is a configuration change, not a tool purchase. None of them are novel; all of them are absent from Stryker-scale tenants more often than they should be.

  1. Put microsoft.graph.managedDevice/wipe (and its peers — retire, cleanWindowsDevice) behind PIM just-in-time elevation, with explicit per-elevation justification, an approver, and an out-of-band notification. The legitimate business cadence of "we need to wipe an entire device fleet tonight" is roughly never. PIM-gating a destructive operation that fires once a year does not cost real productivity; it buys you the audit trail and the gate.
  2. Enforce a Conditional Access policy that limits Intune administrative actions to a small, managed, hardware-backed workstation pool. Even if an operator has stolen a session token, the token will not satisfy the device-compliance condition.
  3. Alert on the wipe Graph call from any non-PIM session, full stop. Microsoft's audit log surfaces the call; the SIEM rule is two lines.
  4. Inventory who in your organization can issue a wipe at all. In most tenants the answer is "more people than the security team realises." Reduce it to a number you can ratify in a meeting.
  5. Treat infostealer-log discovery as a tenant-wide privileged- account incident, not a single-user reset. When credentials for one of your administrators show up in stealer-log marketplaces, the right response is a tenant-wide token- revocation + sign-in review, not a single password reset.

Strategic outlook

Three forward-looking judgments at named confidence:

  • High confidence that Handala / Void Manticore will conduct additional MDM-abuse operations against U.S. and Israeli targets in the next twelve months. The operational ROI is enormous, the TTP works against any organization that has not specifically hardened against it, and the Iranian operational tempo since October 2023 has not slowed.
  • High confidence that other actor categories will adopt the pattern. Russian-speaking ransomware operations in particular have a strong economic incentive to compress dwell time — an MDM-driven mass-wipe is functionally equivalent to a successful encryption rollout from the operator's perspective and arrives in seconds rather than hours.
  • Moderate confidence that Microsoft, Apple, and the major third-party MDM vendors will introduce destructive-action friction (mandatory step-up auth, tenant-wide rate limits, an explicit "destructive change in progress" cooling-off period) within 18 months. The political pressure from a small number of additional Stryker-class incidents will be sufficient to drive it.

References