Inside the Stryker Wiper Attack: How Cyber Deception Could Have Stopped Handala Before the Wipe
Kabir11 min read

Inside the Stryker Wiper Attack: How Cyber Deception Could Have Stopped Handala Before the Wipe

Iranian hackers wiped 200,000+ Stryker devices across 79 countries using the company's own Intune console. Mines would have caught them long before the wipe button was pressed.

Share:

On the morning of March 11, 2026, over 56,000 Stryker employees across 79 countries switched on their devices and found them wiped. Login screens displayed the logo of Handala, an Iran-linked hacktivist group tied to Iran's Ministry of Intelligence and Security (MOIS). Corporate laptops, mobile phones enrolled in device management, servers, internal applications — all of it gone. Not encrypted. Not held for ransom. Permanently erased.

The attackers claimed they had wiped more than 200,000 systems and exfiltrated 50 terabytes of data before pulling the trigger. Stryker's Cork, Ireland headquarters — its largest facility outside the United States, with roughly 5,500 employees — took the hardest hit. Workers were sent home. Manufacturing systems went offline. The company's Lifenet electrocardiogram transmission system stopped working across multiple US states, disrupting real-time cardiac data flowing from ambulances to hospitals.

Stryker filed an 8-K with the SEC confirming a cybersecurity incident across its entire Microsoft environment, and said the timeline for full restoration "is not yet known." The company's shares dropped over 3%.

This wasn't ransomware. This was destruction. And here's the detail that should keep every CISO up at night: the attackers didn't write custom malware to wipe 200,000 devices. They used Stryker's own Microsoft Intune console, a legitimate enterprise device management tool, to issue a mass remote wipe command. They turned Stryker's IT infrastructure against itself.

I've sat through enough breach post-mortems to recognize the shape of this one early. The most damaging part of an incident is rarely the payload. It's the weeks of quiet access nobody flagged. Stryker is that pattern at industrial scale.

How Handala took down a $25 billion company

Drawing on reporting from KrebsOnSecurity, BleepingComputer, Palo Alto Networks, and several independent analysts, here's what we know about how the attack played out.

Phase 1: Initial access through compromised credentials. Handala's established TTPs lean on phishing and credential harvesting. Palo Alto Networks assesses the group as an online persona run by Void Manticore, an MOIS-affiliated actor, and the attackers most likely got their first foothold through compromised credentials. Phishing, infostealer malware, or a supply chain foothold — whatever the route, they walked away with valid credentials that opened Stryker's Microsoft environment.

Phase 2: Persistence and privilege escalation via Active Directory. British cybersecurity expert Kevin Beaumont assessed that the attackers reached Stryker's Active Directory services. AD is the crown jewel of any Windows enterprise. Control it and you control user accounts, group policies, authentication, and authorization across the whole organization. From there the attackers could escalate privileges, build persistence, and move freely.

Phase 3: Exfiltration of 50 terabytes. Before the wipe, Handala claims it pulled out 50 terabytes of critical data. Whether the figure is exact matters less than the category: proprietary medical device designs, patient outcome data, procurement records, employee information, clinical trial data, internal communications. Moving that volume isn't quick. It would have meant days or weeks of sustained access to find, stage, and transfer the data.

Phase 4: The kill shot through Intune MDM abuse. This is where the attack broke new ground. Instead of dropping custom wiper malware that EDR might catch, the attackers used Stryker's own Microsoft Intune console, a cloud-based mobile device management platform, to issue remote wipe commands to every enrolled device at once. Every laptop, every corporate-managed phone, every enrolled endpoint received a legitimate administrative command from a trusted platform telling it to factory-reset. Employees with personal phones enrolled for work lost personal data too. Staff were urgently told to remove Intune Company Portal, Teams, and VPN clients from personal devices.

Phase 5: Defacement and psychological impact. The attackers defaced Stryker's Microsoft Entra login page with the Handala logo and emailed company executives to claim responsibility. That's textbook Handala: maximum visibility, maximum psychological impact, timed for geopolitical messaging.

Why traditional security never saw it coming

The Stryker breach lands squarely in a blind spot of modern enterprise security. When attackers operate through legitimate administrative tools, conventional detection has nothing to grab onto.

There was no malware to detect. Stryker's own statement confirmed "no indication of ransomware or malware." The wipe ran through a legitimate channel, Intune, using authorized administrative credentials. EDR exists to spot malicious binaries and suspicious process behavior. A remote wipe command from the Intune console looks like exactly what it appears to be: an admin managing devices. The tool did its job. The problem was whose hands were on it.

Living off the land, at the admin layer. This takes the LOTL idea to its extreme. The attackers skipped PowerShell and PsExec for lateral movement and went straight for the console that manages every device in the company. Once they held privileged access to Intune and Active Directory, they had more power over Stryker's infrastructure than most of Stryker's own IT staff.

A long, quiet exfiltration window. Moving 50 terabytes takes sustained access over time. Throughout that stretch, the attackers were inside with valid credentials, reaching systems through legitimate channels. With no mechanism to catch authorized-looking access that shouldn't be happening, the window stayed open until the attackers decided to close it themselves, by wiping everything.

Nation-state pre-positioning. GovInfoSecurity reported it isn't clear when the attackers first got in, or whether that predated the February 28 start of the US-Israel and Iran conflict. Nation-state operators routinely pre-position inside organizations long before they act. The attackers may have lived in Stryker's network for weeks or months, quietly mapping the environment and staging exfiltration.

Where Mines would have tripped the attack

This is the part of the post-mortem where the alternative timeline gets painful. Mine2's platform seeds Mines — decoy credentials, fake services, bogus resources — throughout an environment. Detection tools try to separate malicious activity from legitimate activity. Mines skip that problem entirely. They're assets no legitimate user or process should ever touch, so any interaction is unauthorized by definition. Zero false positives. A high-fidelity signal the moment someone bites.

Here's where each phase of the Stryker attack would have hit a tripwire, long before the wipe command ever fired.

Credential Mines catch the initial compromise

Stryker's environment almost certainly held stored credentials across workstations, config files, browser credential stores, and shared documentation — the exact spots infostealers and phishing campaigns drain. Mine2 Credential Mines (fake admin credentials, decoy service account passwords, bogus Azure AD tokens) planted in those same places would have been swept up alongside the real ones during the initial compromise. The first time the attackers tried to authenticate with a Credential Mine, the alert fires. The initial access phase Stryker apparently never noticed would have surfaced immediately. This is the same early-warning pattern we break down in our look at stopping ransomware during lateral movement.

AD Mines detect the privilege escalation

Compromising Active Directory is the hinge moment in any enterprise wiper or ransomware attack. The attackers needed to enumerate AD to find privileged accounts, read group policies, and locate the Intune admin console.

Mine2 deploys AD Mines — fake privileged accounts with names like svc_intune_admin, backup_domain_ctrl, or azure_sync_svc — directly in Active Directory. They read like high-value service accounts an attacker would jump on. Any authentication attempt, any enumeration that touches these decoys, throws an immediate alert. As the attackers hunted for accounts with Intune admin rights, AD Mines would have caught the reconnaissance and told the security team that someone was systematically probing for control of device management. We cover this AD detection pattern further in our piece on catching Kerberoasting with AD Mines.

Data Mines detect the 50-terabyte exfiltration

Pulling 50 terabytes means broad access to file shares, databases, document repositories, and internal systems. The attackers couldn't have known exactly where the valuable data sat, so they had to go looking.

Mine2 Data Mines (decoy file shares full of realistic-looking sensitive documents: fake product designs, bogus clinical trial records, honeytoken patient databases) sit scattered across the network. As the attackers enumerated shares and accessed repositories during staging, they would have inevitably touched a Data Mine. The alert fires days or weeks before the wipe, during the exact exfiltration phase traditional tools missed entirely.

MineField decoys catch the network reconnaissance

Before reaching the Intune console, the attackers had to map Stryker's network and find management interfaces, admin portals, and cloud service endpoints. Mine2's MineField deploys decoy services that look like legitimate management interfaces and cloud integration endpoints. Any scan or probe that lands on a MineField decoy fires immediately, exposing the attackers during network mapping, well before they spotted the real Intune console.

Cloud Mines detect the cloud admin abuse

Stryker's Microsoft environment — Azure AD, Intune, Entra — is cloud-based administrative infrastructure. Mine2's Cloud Mines plant decoy cloud resources and honeytoken cloud credentials that fire when someone tries to enumerate or reach cloud management infrastructure. As the attackers probed Stryker's Azure environment to find the Intune console and gauge their access, Cloud Mines would have caught the enumeration, the last warning before they reached the kill switch.

Mines buy the one thing Stryker didn't have: time

The Stryker attack worked because the attackers had unlimited time. They moved through the environment undetected, exfiltrated huge volumes, identified the most destructive path (Intune admin abuse), and pulled the trigger on their own schedule.

Mines collapse that timeline. A single triggered Mine, at any phase, would have given Stryker's team the signal to investigate, contain, and eject the attackers before the wipe. That's the part defenders underestimate: Mines don't need to catch every phase. They need one interaction, anywhere in the kill chain, to break the attack.

Walk through the detection opportunities:

  • Credential Mine during initial access → investigate compromised accounts, reset credentials, hunt for persistence
  • AD Mine during privilege escalation → lock down admin accounts, audit Intune admin access, isolate affected systems
  • Data Mine during exfiltration → identify compromised data paths, sever attacker access, start incident response
  • MineField decoy during reconnaissance → map attacker movement, find compromised hosts, contain lateral spread
  • Cloud Mine during cloud admin enumeration → emergency lockdown of Intune admin access, revoke privileged sessions

Any single one of those breaks the kill chain before the catastrophic wipe.

Lessons for every enterprise: don't wait for the wipe

The Stryker attack hands urgent lessons to any organization running cloud-based device management.

Your MDM console is a weapon. Microsoft Intune, VMware Workspace ONE, Jamf — any MDM platform can wipe every device you own. Treat admin access to these platforms with the same paranoia you'd reserve for domain admin credentials. Wrap Mines around MDM infrastructure to detect unauthorized access before it gets weaponized.

Nation-state attackers pre-position. The Stryker attackers may have lived in the network for weeks before the wipe. Detection that fixates on the moment of impact misses the whole reconnaissance, escalation, and exfiltration chain. Mines catch attackers during the quiet phases, while they're still exploring and haven't yet decided to pull the trigger. The Marriott breach settlement tells a similar story about long dwell times going unnoticed.

Wiper attacks leave nothing to recover. Encrypted data can sometimes be recovered with a decryption key. Wiped data can't. Recovery depends entirely on backup integrity. The best defense against a wiper is catching the attacker before the wipe command is issued, and Mines provide that detection.

Harden, then deceive. Use Mine2's Fortify to strip unnecessary admin access, enforce MFA on every cloud management console, restrict Intune administrative actions to known IP ranges and break-glass accounts, and watch for anomalous bulk device commands. Then layer Mines on top, so that even when an attacker slips past hardening, the next step they take hits a tripwire.

What I'd take away from this one

The Stryker wiper attack is a blunt reminder that the most devastating cyber attacks don't need sophisticated malware. They need privileged access to legitimate tools. Handala didn't need a zero-day. They needed admin credentials for Microsoft Intune, and the time to use them.

Mine2's Mines would have caught the attackers at every phase of this kill chain: during the initial credential compromise, during Active Directory reconnaissance, during exfiltration, during network mapping, and during cloud admin enumeration. Any single triggered Mine would have alerted Stryker's team in time to stop a wipe that took down 200,000 devices across 79 countries.

When nation-state actors are openly targeting US companies with destructive operations, detection that only fires after the damage is done isn't detection. It's a post-mortem like this one. Mines fire while the attacker is still exploring, still escalating, still deciding what to do next. That's the window where defense actually works.


Don't wait for the wipe. Put Mines across your environment before an attacker reaches your admin console. See how Mine2's cyber deception platform works →

M2

Kabir

Incident Response Lead, Mine2

Kabir leads incident response work at Mine2, dissecting breaches after the fact to show where earlier detection would have changed the outcome.

Share this article

Secure Your Network Today

Ready to implement advanced cyber deception in your organization? See how MINE2 can transform your threat detection capabilities.