CanisterWorm: Cloud Hygiene & the Rise of Geo-Located Wipers

Solid query. Just a heads up though—legitimate localization scripts often query Get-Culture or tzutil. If you run this in a heterogeneous environment, you might drown in false positives from dev machines or LOB apps.

I'd recommend correlating it with a network connection to known bad IPs or a spike in sdelete/cipher usage right after the locale check. We've been using this Sigma rule logic to filter out the noise:

detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: 'fa-IR'
  condition: selection and not filter_legit_apps

The cloud vector is what keeps me up. Misconfigured S3 buckets or Azure blobs are basically open doors for this worm to propagate.

We started deploying automated preventative checks using Scout Suite to ensure our public-facing storage is strictly read-only and blocking anonymous write access. If you haven't automated your cloud hygiene scans yet, this is your wake-up call. Financial actors turning destructive changes the risk model entirely.

Interesting that they went after the timezone. Usually, these groups look for keyboard layouts or installed language packs. I wonder if there's a way to spoof the timezone to trick the worm into self-destructing or dormant mode?

Probably a stretch, but worth a lab test. In the meantime, I'm just glad we enforce strict MFA on our cloud admin consoles. The worm needs valid credentials to spread, right?

Agreed on the cloud hygiene front, ZeroDayHunter. To complement that, we need to catch the execution logic before impact. Since locale checks alone are noisy, as Amy noted, we’re correlating ProcessCreation events where tzutil is called followed by massive file deletions within a short window.

DeviceProcessEvents
| where ProcessCommandLine contains "tzutil"
| join kind=inner (
    DeviceFileEvents
    | where ActionType == "FileDeleted"
) on DeviceId
| project Timestamp, DeviceName, ProcessCommandLine

This helps filter out standard admin tasks.

The destructive pivot is alarming, but let's harden the entry point. Since the worm relies on open storage APIs to propagate, we should aggressively audit IAM policies. Beyond basic hygiene, implementing strict API allow-lists can prevent lateral movement.

You can quickly audit your AWS S3 buckets for public read access using this CLI command:

aws s3api list-buckets --query 'Buckets[*].Name' --output text | xargs -I {} aws s3api get-bucket-policy-status --bucket {} --query 'PolicyStatus.IsPublic' --output text

If any return `true`, you're vulnerable.

Building on Zara’s evasion idea—be careful assuming simple timezone spoofing works. In our testing of similar geo-locked wipers, the payload often queries an external NTP server to verify the time zone offset before detonating, ignoring the OS setting. You might need to block egress NTP or redirect the query to truly sandbox it. We usually verify this by monitoring for outbound UDP port 123, but checking the registry helps confirm the OS stance too:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation'

To build on the IAM point, the worm exploits loose permissions. I suggest aggressively auditing for public s3:PutObject grants. A quick way to scan for this in your AWS environment is using the Access Analyzer API:

aws accessanalyzer list-findings --filter '{"resourceType":{"eq":"AWS::S3::Bucket"},"isPublic":{"eq":"TRUE"}}'

This helps catch misconfigurations before the worm finds them.