Notifications
Clear all
Topic starter
02/08/2026 11:52 am
TL;DR: TeamPCP’s latest payload uses the same ICP canister C2 as CanisterWorm, then branches into Kubernetes privilege abuse, SSH key theft, exposed Docker API exploitation, and an Iran-targeted wipe path that can brick clusters or install persistent backdoors, according to Aikido. Cluster trust assumptions break fastest when privileged orchestration and host access are both exposed.
NHIMG editorial — based on content published by Aikido covering TeamPCP's Kubernetes wiper and CanisterWorm variant: CanisterWorm Gets Teeth: TeamPCP's Kubernetes Wiper Targets Iran
Questions worth separating out
Q: What breaks when a privileged Kubernetes DaemonSet is abused for malware delivery?
A: A privileged DaemonSet can turn cluster scheduling into node-level execution.
Q: Why do service accounts and SSH keys create such a large lateral movement risk?
A: Because they are reusable machine identities with no natural friction once stolen.
Q: How do security teams know whether Kubernetes launch controls are actually working?
A: They should test the final rendered workload, not just the upstream request or policy check.
Practitioner guidance
- Lock down privileged DaemonSets Block privileged DaemonSets by default, especially any workload that requests hostPath: /, hostPID, or hostNetwork.
- Hunt for exposed machine credentials Search for SSH private keys, shared service accounts, and unauthenticated Docker API exposure across the fleet.
- Separate benign tooling from trusted execution Do not allow process names like pgmonitor or internal-monitor to justify trust.
What's in the full article
Aikido's full post covers the operational detail this post intentionally leaves for the source:
- Exact payload logic for the Iran-specific wipe branch, including the DaemonSet spec and host-root mount path
- Indicator-of-compromise list for the ICP canister, Cloudflare delivery domains, service names, and on-host file paths
- Command examples for finding suspicious DaemonSets and verifying whether internal-monitor or pgmonitor persistence exists
- Details of the SSH spread and Docker API abuse paths that show how the malware propagates outside Kubernetes
👉 Read Aikido's analysis of TeamPCP's Kubernetes wiper and CanisterWorm variant →
Kubernetes wiper and cluster trust collapse: what teams missed?
Explore further
02/08/2026 1:01 pm
Cluster trust is the real target, not just Kubernetes runtime access. This payload shows that once a privileged DaemonSet is allowed to mount host paths, the cluster becomes an identity enforcement failure rather than a scheduling problem. Kubernetes-native compromise becomes catastrophic when workload identity, node privilege, and control-plane reach are not separately governed. The practitioner conclusion is simple: control-plane trust must be treated as an access boundary, not an operational convenience.
A question worth separating out:
Q: Who is accountable when a cluster compromise leads to destructive host wiping?
A: Accountability usually sits with the team that owns workload governance, platform policy, and exception handling, not just the responders who clean up afterward. If privileged orchestration paths, machine credentials, and exposed management interfaces were left broad, the incident points to a control-design failure that should be visible in risk and audit reporting.
👉 Read our full editorial: TeamPCP’s Kubernetes wiper shows how C2 and cluster trust collapse
