Hunting Timezone Heuristics: The CanisterWorm Locale Check
Just caught the KrebsOnSecurity report on ‘CanisterWorm’ targeting Iranian systems. It’s a concerning shift from pure financially motivated extortion to leveraging geopolitical tension. The group is utilizing a worm that propagates through poorly secured cloud services—likely misconfigured storage buckets or exposed APIs—to deploy a wiper.
What stands out technically is the targeting precision. The malware doesn’t immediately wipe upon execution; it performs an environmental check first. If the system matches Asia/Tehran timezone or has Farsi set as the default language, the destructive payload triggers. Otherwise, it likely holds off or sticks to data exfiltration.
For detection, relying solely on network signatures isn't enough given the cloud propagation vector. We need to hunt for the specific logic used to identify the target locale. On Linux endpoints, we should be monitoring for processes reading /etc/timezone or querying locale settings unexpectedly followed by mass file deletion.
Here is a rough simulation of the check we might see in the wild:
import os
import locale
def is_target_environment():
# Check Timezone symlink
try:
tz_path = os.path.realpath('/etc/localtime')
if 'Asia/Tehran' in tz_path:
return True
except:
pass
# Check System Locale
sys_lang = locale.getdefaultlocale()[0]
if sys_lang and sys_lang.startswith('fa'):
return True
return False
if is_target_environment():
# Wiper logic triggered
pass
If you are hunting this, consider a KQL rule for processes spawned by cloud agents that invoke shell commands checking `date` or `locale`:
DeviceProcessEvents
| where FolderPath endswith "/bash" or FolderPath endswith "/sh"
| where ProcessCommandLine contains "locale" or ProcessCommandLine contains "timedatectl"
| where InitiatingProcessFileName in~("python", "perl", "node")
Given the reliance on cloud misconfigurations for spread, is anyone else seeing an increase in automated scans for open cloud APIs in their telemetry, or is this flying under the radar?
Solid breakdown. We noticed similar behavior during the NotPetya incident regarding locale checks. The tricky part here is the cloud worm aspect. If they are leveraging metadata services (like AWS Instance Metadata Service) to determine location, simple EDR on the OS might miss the initial recon if it's done via a curl request to the cloud IP.
We've added a specific SIEM alert for any internal server making a request to 169.254.169.254 (metadata) immediately followed by a process execution of a script interpreter. It’s noisy if you have autoscaling groups, but vital for catching cloud-native worm propagation.
The pivot from financial extortion to wiper attacks is a significant escalation. It makes attribution harder but the intent clearer.
On the defensive side, strictly enforcing cloud segmentation is key. If the worm is moving via 'poorly secured cloud services,' that usually implies open S3 buckets or overly permissive IAM roles.
Here’s a quick PowerShell snippet to audit local timezones on Windows endpoints in your fleet, just in case you have traveling laptops that might fall into the target criteria:
Get-TimeZone | Select-Object Id, DisplayName
You can pipe that into a central log to flag any systems suddenly shifting to the Iran Standard Time zone.
That Python snippet is exactly what I feared. It's low-tech but highly effective for avoiding collateral damage, which is often a priority for groups wanting to avoid international backlash.
I’d add that monitoring for unexpected chattr (Linux) or cipher /w (Windows) commands is crucial here. If they bypass the locale check, the wiping mechanism is standard. We use a Falcon rule that triggers on chattr +i usage outside of known admin maintenance windows, as immutable file attributes are often used by wipers to prevent recovery.
Building on Nico’s point about metadata services, enforcing IMDSv2 is critical here. Without it, an attacker can easily grab the availability zone to infer local time via a simple HTTP GET. You can audit your posture for this exposure using the AWS CLI:
aws ec2 describe-instances --query "Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens]"
If you see 'optional', you're vulnerable. Upgrading to 'required' blocks the unauthenticated retrieval these worms rely on for their targeting logic.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access