Healthcare Under Siege: Analyzing the Stryker Wiper Incident & OT Defenses
Saw the breaking news about Stryker getting hit by what looks like an Iran-linked wiper attack. Sending 5,000 people home in Ireland and declaring a "building emergency" at HQ in Michigan suggests this isn't just data exfil; it's pure destruction. For Medtech, where availability is often prioritized over segmentation, this is a nightmare scenario.
While attribution takes time, the TTPs (Tactics, Techniques, and Procedures) for state-sponsored wipers usually follow a pattern: disabling recovery tools, wiping the MBR, and deleting shadow copies. If you're in Healthcare InfoSec, you need to hunt for precursors immediately.
I recommend checking for suspicious VSS shadow copy deletions via command line. Here is a KQL query for Sentinel/SIEM to detect potential wiper precursors:
DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has "vssadmin"
| where ProcessCommandLine has_any ("delete", "resize", "shadowstorage")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
You should also monitor for direct disk access using PowerShell, which is often used to corrupt the partition table:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4103}
| Where-Object {$_.Message -match "DeviceIOControl" -or $_.Message -match "\\.\PhysicalDrive"}
Given the geopolitical angle, this might escalate. The immediate priority for Medtech orgs is verifying offline backup integrity.
Discussion: How are you handling offline backups for legacy medical devices (PACS, X-ray machines) that can't be easily patched or air-gapped? Is Immutable storage the only play left?
Solid advice on the VSS hunting. I'd also add bcdedit modifications to your watchlist. Many modern wipers (like CaddyWiper or variants we've seen in Eastern Europe) attempt to disable recovery mode or change the boot path to prevent safe mode recovery.
# Look for bcdedit changes in Event Logs
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.CommandLine -like "*bcdedit*"}
If you see `bcdedit /set {default} recoveryenabled No`, trigger an incident response immediately.
The 'building emergency' is the part that terrifies me. It implies they pivoted from IT to OT—potentially hitting HVAC or badging systems. We've seen similar supply chain pivots recently where the initial entry was a standard phishing email, but lateral movement hit the Building Management System (BMS).
If you are an MSP serving healthcare, audit your RMM access logs right now. If the attackers used a known RCE (like the recent n8n flaws) to get in, you might see lateral movement from an unexpected subnet.
Regarding legacy devices: air-gapping is theoretically sound but practically impossible for active imaging suites. We moved to Immutable Object Storage (WORM) for all our PACS backups. If the ransomware or wiper hits, the blob storage cannot be deleted or modified for a set retention period.
It saved us last quarter when a crypto-locker hit our file server. The recovery was slow, but data loss was zero.
On the forensic side, ensure you validate the Master Boot Record (MBR) early in your triage. Wipers frequently target sector 0 to force a rebuild, regardless of recovery settings. A quick sanity check on the disk signature can identify affected hosts faster than full imaging. Here's a snippet for immediate verification:
dd if=/dev/sdX bs=512 count=1 2>/dev/null | tail -c 2 | xxd
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access