CanisterWorm: The Risk of Locale-Based Wiping for Global Travelers

Has anyone else dug into the technical details of the CanisterWorm campaign targeting Iranian systems? While the 'cloud worm' aspect is getting attention due to the propagation via poorly secured cloud services, I'm more concerned about the rudimentary but effective triggering mechanism.

Based on the latest reports, the malware checks for Asia/Tehran timezones or Farsi language settings before executing the wiper logic. This creates a unique risk for global organizations with traveling employees or multi-region cloud deployments. If a road warrior's device is infected while connected to an insecure network abroad, and they happen to sync their clock or have specific locale packs installed, they could be hit by the 'collateral damage' of a geo-targeted attack.

I’ve been looking at ways to detect this pre-execution check. The malware typically queries the system locale via standard APIs. We can potentially catch this using Sysmon for API monitoring or looking for specific process behaviors.

Here is a basic Sigma rule concept to catch the locale check behavior often seen in these wipers:

detection:
  selection:
    EventID: 7 # Image loaded
    ImageLoaded|endswith: '\kernel32.dll'
    OriginalFileName: 'kernel32.dll'
  filter:
    # suspicious GetLocaleInfo or GetTimeZoneInformation calls
    CallTrace|contains:
      - 'GetLocaleInfo'
      - 'GetTimeZoneInformation'
  condition: selection and filter

Has anyone started blocking access to specific cloud metadata services (like the AWS IMDS) as a mitigation? Since the worm spreads through misconfigurations, locking down the metadata endpoint (requiring IMDSv2) seems like the best immediate preventive measure to stop the worm from identifying sibling instances.

How are you guys handling locale-based detection logic in your EDR policies? Is this something you're alerting on, or just relying on AV signatures?