Medtech Under Fire: Stryker and the Iran-Linked Wiper Threat
Saw the breaking news from Krebs regarding the alleged Iran-backed wiper attack on Stryker. The reports of 5,000 staff being sent home in Ireland and the "building emergency" at their US HQ suggest this isn't just a data breach—it's a severe operational disruption.
We've seen Iran-linked actors (like Pioneer Kitten or Agrius) pivot from espionage to destructive attacks in critical infrastructure sectors. If this is a wiper (similar to ZeroCleare or Dustman), they are likely targeting the Master Boot Record (MBR) or using disk-level encryption to render hardware inoperable, which complicates recovery significantly compared to standard ransomware.
If you are defending healthcare or manufacturing environments, you should be hunting for signs of disk-level interaction or VSS shadow copy deletions. Wipers often try to disable recovery mechanisms immediately.
Here is a KQL query to hunt for processes attempting to delete Volume Shadow Copies via vssadmin:
DeviceProcessEvents
| where FolderPath endswith "\\vssadmin.exe"
| where ProcessCommandLine has "delete" and ProcessCommandLine has "shadows"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
You should also look for unusual usage of `wbadmin`:
# Check command line arguments for backup deletion attempts
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -match 'wbadmin.*delete.*catalog'}
Given the timing and the target profile, I suspect the initial vector might have been phishing or exploiting a public-facing vulnerability. Has anyone seen specific IOCs associated with this group, or is everyone still waiting for the technical drop?
Solid queries. In my SOC experience, we've noticed that wiper variants often utilize signed binaries to bypass application allow-listing. Keep an eye on certutil.exe or bitsadmin.exe downloading random payloads from internal SMB shares. We automated a hunt for unsigned binaries masquerading as system utilities, which caught a variant of ZeroCleare last month during a simulation.
I manage IT for a smaller clinic chain. This is exactly why we enforce immutable backups (WORM storage) now. If they hit the hypervisor or the MBR, you can't just restore files—you need bare metal recovery. For anyone in Medtech, verify your offline backup isolation today. If it's connected to the domain during a wiper event, it's gone.
Valid points. From an MSP operational view, we focus on halting lateral movement fast before the wiping starts. We often see these actors abusing scheduled tasks for execution. If you're hunting, check for tasks created recently by non-standard users using this snippet:
Get-ScheduledTask | Where-Object {$_.Date -gt (Get-Date).AddDays(-1)} | Select-Object TaskName, Author, Date
Has anyone looked into disabling WinRM on critical endpoints yet as a preventative measure?
Great insights on lateral movement and backups. To add a DevSecOps perspective, we should monitor for anomalous file system mass-deletion events, which often precede total disk corruption. Wipers frequently attempt to disable endpoint logging first, so alerting on sudden stops in agent telemetry is crucial. If you're hunting for rapid file deletion spikes on critical servers, check your EDR or run this KQL query:
DeviceFileEvents
| where ActionType == "FileDeleted"
| summarize Count = count() by DeviceName, bin(Timestamp, 5m)
| where Count > 100
Excellent insights. To build on the detection side, wipers often force mass service stops to unlock files for deletion. Hunting for Event ID 7036 occurring in rapid succession can provide early warning. Here is a quick KQL query to identify this anomalous behavior:
SecurityEvent
| where EventID == 7036
| where Message contains "stopped"
| summarize count() by bin(TimeGenerated, 1m), Computer
| where count_ > 10
Solid points on the operational impact. From an intel perspective, these Iran-linked actors often rely heavily on obfuscated PowerShell for the initial payload delivery, distinct from the wiper execution. We should hunt for high-entropy command lines common to Agrius tooling. This query helps detect the staging phase:
title: Obfuscated PowerShell Base64
selection:
CommandLine|contains: 'powershell.exe'
CommandLine|contains: 'FromBase64String'
condition: selection
Catching the staging phase is crucial before the wiper executes.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access