CanisterWorm Deep Dive: Detecting the Persian Timezone Logic
Has anyone else dug into the technical details of the 'CanisterWorm' activity reported by Krebs? It’s a fascinating pivot. We're seeing a financially motivated group effectively repurpose their cloud worm infrastructure to act as a geopolitical wiper.
The targeting mechanism is crude but effective: the malware checks the system locale. If it detects Farsi or the Iran Standard Time timezone, it triggers the payload instead of exfiltration. Based on the existing threads here and IOCs floating around, the propagation vector seems to rely heavily on exploiting unpatched edge devices—specifically looking at the CVE-2026-3055 (NetScaler) vulnerabilities discussed in other threads.
For those hunting this in their environments, specifically if you have global footprints, checking for these locale manipulation API calls is key. Here is a basic KQL query I've drafted to look for suspicious process execution involving kernel32.dll calls related to timezone or locale checks, followed by rapid file deletion events:
DeviceProcessEvents
| where ProcessCommandLine has "GetSystemDefaultLangID" or ProcessCommandLine has "GetTimeZoneInformation"
| join kind=inner (DeviceFileEvents
| where ActionType == "FileDeleted"
| project DeviceId, FileName, Timestamp) on DeviceId, Timestamp
| where Timestamp > ago(1d)
| project DeviceId, InitiatingProcessFileName, FileName, Timestamp
(Note: This is a heuristic; you'll need to tune for false positives based on legit admin tools).
The scary part isn't the wiper itself, but the cloud propagation. How are folks validating their NetScaler configs? Are we assuming that if we aren't in the Middle East, we are safe from the worm's propagation, or is the worm just lying dormant on compromised systems outside the target zone?
Solid query. We're actually seeing the propagation attempt regardless of locale. It hits the box, checks the clock, and then decides to wipe or loot. Don't assume you're safe just because you aren't in Tehran. The worm is likely using valid credentials or session tokens stolen via the NetScaler exploit to move laterally. Patching CVE-2026-3055 is priority zero, regardless of geography.
I ran the query and caught a few false positives with our deployment scripts, so watch out. The real tell for us was the 'cloud service' connection. The worm attempts to self-propagate by enumerating other cloud instances. We blocked the specific C2 domains and IP ranges mentioned in the Krebs article at the perimeter. It's a classic case of hygiene—if you have exposed RDP or management interfaces, this thing will find you.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access