Stryker Incident: When Wipers Hit Medtech and Physical Security
Just caught the breaking news regarding Stryker. Reports indicate an Iran-backed group is claiming a wiper attack, leading to the evacuation of 5,000 staff in Ireland and a "building emergency" at their US HQ.
Unlike ransomware, where the goal is extortion, wipers aim for pure destruction. For medtech, this is terrifying—it disrupts not just data but life-critical supply chains. If attribution holds, this aligns with the trend of state-sponsored actors targeting critical infrastructure for maximum disruption.
We don't have specific IOCs for this strain yet, but standard wiper precursors involve disabling recovery. If you're hunting, watch for mass usage of vssadmin or bcdedit to delete shadow copies and disable recovery options.
Here is a KQL query to spot potential wiper precursors in your environment via Microsoft Sentinel:
DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName in~ ("vssadmin.exe", "wbadmin.exe", "bcdedit.exe")
| where ProcessCommandLine contains "delete" or ProcessCommandLine contains "off" or ProcessCommandLine contains "shadowstorage"
| project DeviceName, InitiatingProcessAccountName, ProcessCommandLine, Timestamp
The physical aspect is what's getting me. Sending 5,000 people home suggests OT convergence—badging systems, HVAC, or physical access controls might have been hit too.
Is anyone else seeing a shift from "data theft" to "operational paralysis" in their threat models? How do you defend against a wiper that doesn't care about encryption keys?
The OT angle is critical here. When a 'building emergency' triggers a full evacuation, it usually implies the Physical Access Control System (PACS) is compromised or unpredictable. We've seen wipers like CaddyWiper target the Master Boot Record, but if they bridged the air gap to the badge readers, that's a massive failure in network segmentation.
If you manage facilities, I'd recommend auditing your VLANs between IT and Building Automation Systems (BAS) immediately. Don't assume a wiper will stay on the corporate LAN.
Solid KQL query. I'd add wevtutil.exe to that watchlist as well. Wipers often try to clear the Security and System event logs to hide their tracks right before destruction.
Also, for those in healthcare right now: Verify your offline backups. Wipers don't always give you the courtesy of encrypting files first; they just corrupt the MFT. If you rely on continuous data protection that isn't truly immutable (air-gapped), you could be looking at rolling back to a pre-infection state from weeks ago.
This sounds exactly like the TTPs we've seen associated with 'Agrius' or similar Iranian groups in the past—using wipers like 'Fantasy' or similar variants to masquerade as ransomware but actually just destroying data.
The speed of this attack is the scary part. 5,000 workers sent home implies they lost control of the environment fast. It reinforces that detection response times (DTR) need to be in minutes, not hours. Once that disk擦除 script starts executing, it's game over.
The escalation to physical evacuation highlights the convergence of IT and OT risks. Beyond the PACS concerns, we should focus on the destructive payload's precursors. These wipers almost always target Volume Shadow Copies to ensure data is unrecoverable.
I recommend hunting for vssadmin or wmic executions with deletion arguments. Spotting these before the corruption hits is critical.
DeviceProcessEvents
| where FileName in~ ("vssadmin.exe", "wmic.exe")
| where CommandLine contains "delete" and CommandLine contains "shadows"
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access