CanisterWorm Analysis: Locale Checks & Cloud Propagation
Has anyone been tracking the CanisterWorm activity reported by Krebs? It’s a fascinating (albeit destructive) pivot. We're used to seeing financially motivated groups stick to ransomware, but this crew is effectively weaponizing geopolitical tension to deliver a wiper.
The mechanics are concerning because the propagation relies on poorly secured cloud services rather than just phishing. The kill switch is specifically targeting systems set to the Iran time zone or with Farsi as the default language. If the condition is met, it wipes; otherwise, it focuses on data exfiltration for extortion.
From a detection standpoint, the locale check is a distinctive anomaly. We should be hunting for unusual process execution related to timezone enumeration. Here is a basic KQL query I'm testing to catch scripts polling system locale or time zone settings via PowerShell or CMD:
DeviceProcessEvents
| where ProcessCommandLine contains "Get-TimeZone" or ProcessCommandLine contains "Get-WinSystemLocale"
| where InitiatingProcessFileName in ("powershell.exe", "cmd.exe", "python.exe")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
Additionally, if you have exposed cloud storage, ensure you aren't acting as a propagation node.
How are you guys handling locale-based risks in your environments, especially with remote workers traveling? Do you block specific region language packs or rely purely on EDR heuristics?
The cloud propagation vector is the real headache here. We've seen a massive uptick in scripts scanning for open S3 buckets and Azure blobs to use as C2 or staging grounds. I recommend running a quick audit to ensure public access blocks are actually active:
aws s3api get-bucket-policy-status --bucket YourBucketName --profile audit
If `PolicyStatus.IsPublic` is true, you need to lock that down immediately before this worm (or others) uses it for lateral movement.
Good catch on the locale check. From a blue team perspective, it's low-tech but effective. One thing I'd add is monitoring for registry modifications under HKLM\SYSTEM\CurrentControlSet\Control\Nls\Locale. If a non-setup process touches these keys, it's a massive red flag.
Also, don't forget that VMs spun up in the cloud by developers might inherit default locale settings that make them targets even if they aren't physically in Iran.
This feels like a throwback to the early 2000s worms, just modernized for the cloud era. The shift from 'profit only' to 'destruction + profit' is dangerous. We started blocking execution of unsigned scripts that call Get-Culture or Get-WinHomeLocation unless they're part of a known release pipeline. It generates some false positives, but better safe than wiped.
Omar, regarding that registry path, monitoring for modifications is key. For rapid auditing of your fleet to check for the vulnerable locale configuration, I use this PowerShell snippet to inspect the default system language settings:
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Language' | Select-Object Default, InstallLanguage
If you see deviations from your standard baseline there, it could indicate the worm is laying groundwork. Also, consider temporarily blocking anonymous access to your storage blobs to cut off the propagation vector discussed earlier.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access