CanisterWorm’s latest evolution turns TeamPCP’s cloud-native toolkit into a geopolitically tuned wiper, capable of bricking entire Kubernetes clusters when it lands on systems configured for Iran.
The campaign reuses the same Internet Computer Protocol (ICP) canister C2 and backdoor infrastructure seen in the earlier Trivy and NPM CanisterWorm incidents. However, it now adds selective destruction logic that pivots on timezone and locale checks.
The new payload stages from Cloudflare-backed infrastructure, first pulling a bash stager (kamikaze.sh) that ensures kubectl is present and then fetching a Python controller script (kube.py) that contains the real logic.
The script talks to the familiar ICP canister at tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io, using the same /tmp/pglog drop path and backdoor code profile documented in the initial CanisterWorm wave.
This ties the activity directly to TeamPCP’s previous supply-chain compromise of Trivy and the NPM propagation campaign, confirming it as an expansion of the same arsenal, not a copycat.
According to the report, the campaign reuses the same Internet Computer Protocol (ICP) canister C2 and backdoor infrastructure seen in the earlier Trivy and NPM CanisterWorm incidents. However, it now adds selective destruction logic that pivots on timezone and locale checks.
The controller script begins by fingerprinting its environment to decide between espionage and destruction.
It detects Kubernetes by checking for the default service account mount and KUBERNETES_SERVICE_HOST, then classifies geography by reading /etc/timezone, querying timedatectl, and inspecting the LANG environment for fa_IR.
If the host is both Kubernetes and Iran-aligned, the payload arms a wiper; if it’s Kubernetes elsewhere, it deploys a persistent backdoor; if it’s a non-K8s Iranian host, it executes rm -rf / –no-preserve-root, and on all other systems it cleanly exits.
Kubernetes wiper via DaemonSets
On Iranian Kubernetes clusters, the script creates a privileged DaemonSet named host-provisioner-iran in kube-system, with a container bluntly called kamikaze.
The pod mounts the host root filesystem at /mnt/host, runs a find-based wipe of top-level directories, and then forcefully reboots the node, with tolerations set so it schedules across every node, including control-plane components.
A single kubectl apply is enough to propagate this DaemonSet cluster-wide, effectively bricking the entire environment within minutes.
For non-Iranian clusters, a separate DaemonSet, host-provisioner-std, focuses on persistence rather than destruction. ICP canister every 50 minutes for a binary URL, downloads and executes whatever it’s told.
It writes a base64-encoded Python backdoor into a host directory, registers it as a systemd service with an innocuous description, and enables it via chrooted systemctl calls so it survives reboots and blends into normal operations.
Outside Kubernetes, geography still dictates impact. On Iranian hosts, the poison_pill function attempts to wipe the filesystem using rm -rf / –no-preserve-root, first as root and then via passwordless sudo, falling back to whatever the current user can destroy.
Non-Kubernetes systems in other locales are spared entirely, underscoring the actor’s intent to escalate beyond monetization and access-building into regional disruption selectively.
Lateral movement and PostgreSQL disguise
A third iteration removes the dependency on Kubernetes altogether, swapping DaemonSet-based spread for classic network worm behaviour.
The new prop.py stage parses /var/log/auth.log and /var/log/secure for Accepted SSH logins to derive user/IP pairs, harvests local SSH private keys, and then attempts passwordless SSH to replay a base64-encoded payload across known and guessed targets (root, ubuntu, admin, ec2-user) on the local /24 subnet.
In parallel, it scans for exposed Docker APIs on port 2375 and abuses them to launch privileged containers with the host root mounted, executing the same logic via chroot.
In every case, the remote logic repeats the Iran check: Iranian systems are wiped using a find-based deletion plus reboot -f, while others receive a backdoor now camouflaged as PostgreSQL monitoring tooling.
Service names have shifted from internal-monitor to pgmonitor, with binaries and scripts dropped under /var/lib/pgmon/ and process names like pglog and pg_state mimicking common PostgreSQL artefacts.
This aligns with TeamPCP broader tradecraft of using cloud-native tooling and benign-looking services to maintain stealth in noisy production environments.
Defenders should immediately audit kube-system DaemonSets for unexpected entries, especially any hostPath: / mounts running privileged containers such as host-provisioner-iran or host-provisioner-std.
On hosts, investigate for systemd services named internal-monitor or pgmonitor, files under /var/lib/svc_internal/ or /var/lib/pgmon/, suspicious pglog processes in /tmp, outbound traffic to icp0[.]io, and unsanctioned Cloudflare tunnel domains delivering shell or Python payloads.
Given the latest variant’s network-propagation capabilities, organizations should also monitor for anomalous SSH activity sourced from compromised nodes and lock down any exposed Docker APIs on port 2375 to prevent privileged container abuse.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
