TeamPCP’s Kubernetes wiper shows how C2 and cluster trust collapse

At a glance

What this is: Aikido describes a TeamPCP payload that turns Kubernetes control into a destructive or persistent foothold, with the key finding being that the same canister C2 now supports both wiper behavior and broader lateral movement.

Why it matters: This matters because Kubernetes privilege, exposed Docker APIs, and host access become one attack surface when identity and orchestration trust are weak, which is exactly where IAM and NHI governance intersect with cluster security.

Context

Kubernetes trust breaks when a single privileged workload can reach the cluster control plane, mount host filesystems, and move from orchestration into the node layer. In that state, identity is not just a login problem. It becomes a question of which service account, node privilege, or host control can be abused to turn a management plane into an execution plane.

This article sits at the intersection of cloud security and machine identity governance because the payload relies on Kubernetes-native privilege, SSH keys, and exposed Docker APIs to spread. The starting position is unfortunately typical of real-world cloud compromise: once host access and privileged orchestration are both available, the attacker can choose between persistence and destruction.

Key questions

Q: What breaks when a privileged Kubernetes DaemonSet can mount the host filesystem?

A: The cluster boundary breaks. A privileged DaemonSet with hostPath '/', hostNetwork, or hostPID can execute actions on every node, including control-plane systems, so one deployment becomes node-wide control. That means the security question is not whether the pod is isolated, but whether it can cross from orchestration into the host runtime at all.

Q: Why do exposed Docker APIs and stolen SSH keys increase lateral movement risk?

A: Because they convert existing administration paths into propagation channels. SSH keys let attackers reuse trusted access without guessing passwords, while an unauthenticated Docker API can start privileged containers on remote hosts. When both exist in the same environment, compromise spreads through legitimate-looking control planes instead of noisy exploit traffic.

Q: What are the signs that cluster trust has failed in practice?

A: Look for privileged DaemonSets in namespaces that should not run infrastructure agents, unexpected host mounts, new systemd services on nodes, and outbound connections to dead-drop infrastructure. A second signal is when a single host’s access artifacts, such as SSH keys or local auth logs, are enough to reach multiple other systems.

Q: How should security teams respond when destructive and persistent payloads share the same control infrastructure?

A: Treat the environment as conditionally compromised and segment response by trust path, not by malware family. If one control channel can deliver both a wiper and a backdoor, the immediate question is which identities, endpoints, and management services remain exposed. Containment should start with those trust anchors, not with the visible payload alone.

Technical breakdown

How privileged DaemonSets turn cluster trust into node-level execution

A DaemonSet is a Kubernetes controller that ensures a copy of a pod runs on each eligible node. When that pod is privileged, uses hostNetwork, hostPID, and mounts hostPath '/', it stops being ordinary application logic and becomes node-level execution with broad reach. In this payload, that mechanism lets the attacker deploy a container once and affect every node, including control-plane hosts. The security failure is not Kubernetes itself. It is the assumption that cluster-admin level access is operationally contained when the workload can cross the pod-to-host boundary.

Practical implication: Treat any privileged DaemonSet with host mounts as a cluster-wide compromise path, not a normal workload.

Why exposed Docker APIs and SSH keys become lateral movement accelerants

The payload’s later variant drops the DaemonSet requirement and instead spreads through two host-level trust channels: SSH keys harvested from local files and successful login logs, and the unauthenticated Docker API on port 2375. SSH keys let the attacker reuse legitimate access paths, while the Docker API enables privileged container creation with the host filesystem mounted. Both mechanisms convert existing operational trust into propagation. The important architectural lesson is that machine credentials and management endpoints are not separate problems when they can be chained into remote code execution across a subnet.

Practical implication: Inventory and restrict Docker APIs and SSH key material as lateral movement infrastructure, not just access tooling.

What the canister C2 and disguise layer say about persistence design

The same ICP canister dead-drop repeatedly delivers payload logic, while systemd services and PostgreSQL-themed file names provide persistence and camouflage on compromised hosts. This is a classic separation of control and payload: the canister acts as a remote command broker, while the local service ensures the implant survives reboots and blends into routine administration. The design matters because defenders often look for a single malware binary, but this pattern uses infrastructure, service registration, and naming abuse as the persistence layer.

Practical implication: Look for persistence as a combination of remote tasking infrastructure, service registration, and misleading local process names.

Threat narrative

Attacker objective: The objective is to gain repeatable control over Kubernetes and adjacent hosts, with the option to destroy Iranian systems while preserving persistence elsewhere.

1. Entry occurs through exposed Kubernetes management surfaces, host-mounted privileged DaemonSets, or unmanaged Docker and SSH access on local hosts.
2. Credential and access reuse then lets the payload spread through stolen SSH keys, successful login records, and unauthenticated Docker API calls.
3. Escalation happens when the attacker creates privileged containers or systemd services that extend control from a single host to the wider cluster or subnet.
4. Impact is either cluster wiping and forced reboot on Iranian targets or durable backdoor installation on non-Iranian systems.

Breaches seen in the wild

• CanisterSprawl npm worm 2026: The CanisterSprawl worm stole npm and PyPI publish tokens from installs of pgserve and Namastex packages and republished victims' packages.
• Stryker Microsoft Intune Wiper Attack: Compromised Microsoft Intune credentials enable wiper attack wiping 200,000 Stryker devices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cluster trust collapse is the right concept for this payload. The article shows that the attacker is not relying on one vulnerability, but on the convergence of privileged orchestration, host access, and remote tasking infrastructure. Once a DaemonSet can reach the host root filesystem or a Docker API can create privileged containers, the boundary between platform management and full compromise disappears. Practitioners should treat cluster trust as an attack surface that spans identity, orchestration, and host control.

Machine identity is the hidden control point here. Kubernetes service accounts, node permissions, SSH keys, and API endpoints all act as non-human identities or identity-bound access paths in practice. When those paths are over-privileged or unmanaged, the attacker does not need to defeat a human login flow to achieve scale. The governance failure is lifecycle control over machine access, not just malware detection.

Posture management is only useful if it includes runtime privilege shape. A cluster can look healthy in a scan while still allowing a privileged DaemonSet, an open Docker socket, or host-mounted persistence. That gap matters because the malicious action is encoded in runtime authority, not in static configuration alone. Practitioners need governance that follows the execution path, not just the inventory.

Destructive intent and persistence now coexist in the same campaign logic. The same payload can wipe Iranian systems and install a backdoor elsewhere, which means defenders must assume conditional behavior rather than one fixed outcome. This changes response priorities because the control objective is not only to detect malware but to understand which trust decisions let one payload branch into multiple effects.

OWASP-NHI and Kubernetes governance meet at the point of overreach. Service account scope, node privilege, and access to management endpoints are the practical NHI issues this article exposes. When machine identities can drive cluster-wide execution, the problem is not just exposed secrets. It is the absence of enforced boundaries on what those identities are allowed to command.

From our research library:

• Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.

What this signals

Cluster trust collapse is becoming a practical cloud-security pattern. The article shows that once machine identities can drive privileged orchestration and host access at the same time, the distinction between platform management and compromise disappears. Security teams should therefore govern Kubernetes service accounts, node authority, and remote management endpoints as one trust chain, not as separate controls.

Non-human identity governance now extends into runtime control paths. Service accounts, Docker access, SSH keys, and systemd services are all non-human access mechanisms with lifecycle and scope decisions attached to them. That is why the relevant control question is not only whether secrets are rotated, but whether any machine identity can command host-level execution outside its intended boundary.

For practitioners

• Audit privileged DaemonSets Search kube-system and workload namespaces for DaemonSets that use privileged: true, hostPath mounts, hostNetwork, or hostPID. Any object that can mount / on the host should be treated as a high-risk control-plane bridge until it is explicitly justified.
• Disable unauthenticated Docker access Remove or isolate port 2375 wherever it is exposed, and confirm that no workload can create containers on adjacent hosts without strong authentication and policy enforcement. Exposed Docker APIs are direct lateral movement channels, not administrative conveniences.
• Rotate and scope SSH key material Review SSH private keys on servers, limit passwordless and key-based reuse across subnets, and correlate accepted logins with unexpected fan-out from a single host. The attacker in this case used both stolen keys and login logs to expand reach.
• Monitor for hidden persistence services Look for unexpected systemd services, especially ones masquerading as monitoring or PostgreSQL tooling, and tie them back to their on-disk binaries and startup paths. Persistence here is built from service registration plus camouflage, not just a single malicious executable.
• Treat canister-based tasking as a command channel Block or investigate repeated outbound traffic to the ICP canister domain family and any dead-drop infrastructure used to fetch follow-on payloads. If a host is polling for instructions, the compromise is already beyond initial intrusion.

Key takeaways

• The article shows a campaign that can either wipe or persist, depending on the target, which makes runtime trust boundaries the central control issue.
• The same canister C2, privileged Kubernetes execution, SSH key reuse, and exposed Docker APIs together create a multi-path propagation model.
• Stopping this class of attack requires tighter control over privileged orchestration, host access, and machine-identity scope, not just malware detection.

Key terms

• Privileged DaemonSet: A DaemonSet is a Kubernetes controller that runs one pod per node. When it is privileged and can mount the host filesystem, it becomes a node-level execution vehicle rather than a normal workload, which makes it attractive to attackers seeking cluster-wide control.
• HostPath Volume: A hostPath volume mounts a directory from the node filesystem into a pod. It is a powerful mechanism because it can expose the underlying host directly, so governance must focus on where the mount points and what directories the pod can touch, not only on pod privilege flags.
• Lateral Movement: A post-compromise technique where an attacker uses a compromised NHI to move through a network, accessing additional systems and escalating impact without triggering detection.
• Dead-Drop Control Channel: A dead-drop control channel is an indirect way for malware to receive instructions without hardcoding a fixed command server. The malicious code retrieves configuration from an external source, then uses that data to assemble its next stage actions. This approach helps attackers rotate infrastructure without republishing the package.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect machine identity controls to wider security governance.