Technical breakdown of PCPJack, a predatory cloud worm that active removes rival malware in Kubernetes clusters before exfiltrating credentials.
What PCPJack Does Differently
PCPJack is a cloud-oriented worm that targets Kubernetes clusters. Unlike malware that only steals secrets and moves on, it first hunts for other malicious workloads already running in the environment. It treats rival implants as competition for the same credentials, compute, and network access. Once those rivals are cleared, it focuses on harvesting and exfiltrating credentials that give durable access to cloud and cluster resources.
That predatory step matters because many clusters already host leftover miners, reverse shells, or poorly cleaned post-exploitation tools. A worm that actively removes those rivals can look quieter in aggregate metrics while still expanding its own foothold. Defenders who only look for “noisy” crypto-mining spikes may miss a quieter actor that is cleaning house before it steals keys.
How a Predatory Worm Operates in a Cluster
In Kubernetes, privilege is often granted through service accounts, secrets mounted into pods, node identity, and cloud IAM bindings. A worm that can schedule or compromise pods can read those materials, then use them to spread laterally across namespaces or nodes. PCPJack-style behavior typically chains discovery of existing malicious pods or processes, termination or eviction of those rivals, and collection of credentials from the surviving high-value surfaces.
Credential targets usually include Kubernetes secrets, tokens mounted under standard service-account paths, cloud provider metadata endpoints reachable from pods, and configuration files that developers leave on nodes or in images. After collection, exfiltration tends to use outbound HTTPS or other traffic that blends with normal cluster egress. The worm’s “predatory” phase is what sets it apart: it reduces competition and may also remove noisy rivals that would have triggered earlier alerts.
- Enumerate workloads and processes that look like known malware families or unauthorized miners
- Disable or delete rival pods, jobs, and persistence mechanisms when permissions allow
- Harvest service-account tokens, secrets, and cloud credentials from remaining access paths
- Exfiltrate material and expand to other nodes or namespaces using the stolen identity
What Defenders Should Inspect First
Detection should assume that credential theft may follow a short period of internal cleanup. Watch for unexpected pod deletions, abrupt stops of long-running unauthorized workloads, and bursty kube-api calls that list secrets, create pods, or patch RBAC. Correlate those events with new outbound connections from nodes or pods that rarely leave the cluster. A drop in known-bad miner activity is not always good news if it coincides with fresh secret access from an unknown identity.
Hardening reduces both the worm’s hunting range and its payoff. Prefer least-privilege service accounts, avoid mounting broad secrets into many pods, restrict access to the cloud metadata service, and enforce network policies that limit egress to known destinations. Runtime admission controls should block privileged containers, hostPath mounts, and unusual capability sets. Continuous secret rotation and short-lived tokens shrink the value of anything that is exfiltrated.
Practical Response If You Suspect Infection
Isolate affected nodes and namespaces from outbound traffic while you preserve evidence. Snapshot relevant logs, audit API events, and capture process lists before tearing down pods. Rotate every credential that may have been mounted or readable from compromised workloads, including cloud keys, registry tokens, and cluster service-account secrets. Rebuild nodes from known-good images rather than trusting in-place cleanup when a worm with self-spreading behavior is involved.
After containment, review how the initial foothold appeared: exposed dashboards, weak RBAC, vulnerable images, or supply-chain implants. Closing that path matters as much as removing the current payload. Predatory malware like PCPJack shows that modern cluster threats can compete with each other for your secrets. Your monitoring and least-privilege design need to treat internal cleanup, secret access, and unusual egress as a single story—not three unrelated noise events.