TeamPCP: Inside the Worm That Treats AWS, Azure, and GCP as One Attack Surface

Most cloud threat actors still operate inside a single provider’s boundary. TeamPCP does not. Security researchers tracking the campaign describe it as the first genuinely multi-cloud-native worm — one that has compromised more than 60,000 servers across AWS, Azure, and GCP by treating the seams between providers as a single, continuous attack surface rather than three separate perimeters to breach independently. Azure and AWS account for roughly 97% of confirmed victims, split about 61% Azure and 36% AWS, with GCP infrastructure also targeted.

The campaign matters less for any single novel exploit than for what it demonstrates: a fully automated pipeline from internet-wide scanning, to exploitation, to credential harvesting, to cross-cloud lateral movement, to monetization via cryptomining and ransomware C2 — all without a human operator in the loop for most infections.

How the worm gets in

TeamPCP’s initial access relies on infrastructure that was never supposed to be internet-facing in the first place, plus one high-severity application vulnerability:

Exposed Docker Engine APIs. Docker’s remote API, when bound to 0.0.0.0 without TLS client-certificate authentication, allows anyone who can reach the port to create and run containers with host-level privileges. TeamPCP’s scanner.py component sweeps CIDR ranges pulled from public cloud provider IP lists looking for these endpoints.
Misconfigured Kubernetes control planes. Clusters with anonymous or weakly authenticated API server access let the worm’s kube.py module enumerate service accounts, harvest mounted credentials, and deploy privileged pods for persistence.
Exposed Ray dashboards and Redis instances, both frequently left unauthenticated in ML and caching deployments, are scanned and exploited the same way.
CVE-2025-55182 (“React2Shell”), a CVSS 10.0 insecure-deserialization flaw in React Server Components’ Flight protocol affecting React 19.0.0–19.2.0, gives the worm unauthenticated RCE against any internet-facing app built on RSC.
CVE-2025-29927, the Next.js middleware authorization bypass (fixed in 12.3.5, 13.5.9, 14.2.25, 15.2.3), is chained in to skip authentication middleware entirely by spoofing the x-middleware-subrequest header.

Once a container, pod, or application server is popped, pcpcat.py drops a base64-encoded payload, proxy.sh installs proxy/tunneling utilities and fingerprints the environment for Kubernetes, and the worm pivots outward — scanning the local cloud’s metadata range and any reachable peer networks for the next host.

Why “multi-cloud” is the actual threat model

The dangerous part isn’t any individual exploit — Docker API exposure and unpatched Next.js instances are old news individually. It’s that TeamPCP’s operators built tooling that doesn’t care which provider a target sits in. A compromised EC2 instance’s harvested IAM credentials get tried against S3 and Secrets Manager; a compromised AKS node’s managed identity token gets tried against Azure Storage and Key Vault. Cloud metadata services (IMDS on AWS, IMDS on Azure, the metadata server on GCP) are queried indiscriminately to escalate from container/pod compromise to cloud account compromise.

Most detection stacks are still organized around single-cloud telemetry — a SIEM tuned for CloudTrail doesn’t see an Azure Activity Log anomaly, and vice versa. TeamPCP exploits exactly that visibility gap.

Closing the exposure

Find and lock down exposed Docker APIs.

# Confirm the daemon isn't listening unauthenticated on the network
sudo ss -tlnp | grep 2375

# If it must be remote-accessible, require TLS client certs
# /etc/docker/daemon.json
{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2376"],
  "tls": true,
  "tlsverify": true,
  "tlscacert": "/etc/docker/ca.pem",
  "tlscert": "/etc/docker/server-cert.pem",
  "tlskey": "/etc/docker/server-key.pem"
}

Restrict Kubernetes API server exposure. Never expose the API server to 0.0.0.0/0; use security groups or firewall rules scoped to known admin/CI CIDRs, and disable anonymous auth:

kubectl get --raw /api/v1 --insecure-skip-tls-verify 2>&1 | head -1  # sanity-check anon access is refused

# kube-apiserver flag
--anonymous-auth=false

Patch React/Next.js immediately. If you can’t patch same-day, strip the spoofable header at the edge:

# Reverse proxy / load balancer rule
proxy_set_header x-middleware-subrequest "";

Deny outbound access to the cloud metadata endpoint from workloads that don’t need it. For containers/pods this is the highest-leverage single control against the credential-harvesting stage:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "IpAddress": { "aws:SourceIp": "169.254.169.254/32" }
  }
}

On EC2, enforce IMDSv2 fleet-wide:

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

Correlate across clouds, not within one. Feed CloudTrail, Azure Activity Log, and GCP Audit Logs into a single detection pipeline and alert on the pattern that matters here: outbound scanning traffic from a workload immediately followed by a metadata-service query and a new IAM/service-principal credential use from an unfamiliar source. Enable VPC Flow Logs (AWS/Azure) and VPC Flow Logs equivalents (GCP) across every environment — TeamPCP’s cross-account pivots show up there before they show up anywhere else.

TeamPCP is a preview of where cloud-native threats are headed: automated, provider-agnostic, and built to exploit the fact that most organizations still secure and monitor each cloud in isolation.