In a massive cloud exploitation campaign, a threat group called TeamPCP—also known as PCPcat, ShellForce, and DeadCatx3—has transformed misconfigured infrastructure into a platform for self-propagating cybercrime. Active since late 2025, the group focuses on exposed cloud control planes rather than traditional endpoint malware. The campaign, which targeted exposed Docker APIs, Kubernetes clusters, Ray dashboards, Redis servers, and React2Shell-vulnerable apps (CVE-2025-29927), was noticed by security researchers.

Rather than using zero-day exploits, TeamPCP obtains initial access by abusing vulnerable configurations and openly accessible management interfaces. Around December 25, 2025, the campaign reached its zenith when hundreds of compromised servers started to run containers under the control of the attacker. During one stage of the operation, investigators found at least 185 verified Docker compromises, but infrastructure points to a much wider impact.

Automated Cloud Exploitation Similar to Worms A script called proxy.sh serves as the campaign's operational backbone. It installs tunneling tools like FRPS and gost, launches scanners, creates persistence using system services, and starts looking for more exposed systems after it has been installed on a vulnerable server. The schematic flow of Operation PCPcat (Source: flare) The script deploys a different payload known as kube if it determines that it is operating inside Kubernetes.Py.

By running commands inside each available pod, this module spreads laterally, gathers credentials, and counts cluster resources. Additionally, it installs a privileged DaemonSet that mounts the host filesystem, establishing persistent connectivity throughout the cluster. React.py, another component, takes advantage of React2Shell flaws in Next.js applications.

The scanner is operated by a system service (Source: flare). It extracts environment variables, cloud credentials, SSH keys, Git tokens, and.env files after obtaining remote command execution. The information is exfiltrated to servers under the control of the attacker and occasionally made public.

Several strategies are used to conceal the secondary payload (Source: flare). Additionally, the group makes use of pcpcat.py, a high-volume internet scanner. It searches for exposed Docker and Ray APIs and retrieves enormous CIDR ranges from public provider lists. It automatically launches a malicious container that downloads and runs a proxy when it detects one.Sh.

As a result, each compromised system turns into a new scanner and propagation node, creating a feedback loop akin to a worm. Additionally, TeamPCP uses XMRig cryptominers, which are frequently concealed by double base64 compression and encoding.

Even though mining revenue seems small, it generates passive income while other attacks are conducted on the infrastructure. Data Leaks, Proxies, and Mining in Hybrid Monetization Although there are 15 workers, which is a lot, according to the XMR performance, it appears that XMR mining doesn't produce many profits (Source: flare). There isn't just one source of income for TeamPCP.

Repurposed compromised servers are used for: Nodes that mine cryptocurrency C2 relays for proxy and tunneling infrastructure Platforms for scanning the internet Staging servers for data theft In one instance, a recruitment platform's JSON-formatted records of over 2.3 million job applicants were compromised. Names, dates of birth, work histories, and contact information were among the information. Public cloud providers host the majority of compromised infrastructure.

AWS represents 36% of the observed victims, whereas Azure accounts for roughly 61%, suggesting a strong cloud-first targeting strategy. The group targets cloud workloads that are exposed to the internet, not personal devices. Automation and scale, not creativity, are TeamPCP's strong points.

Most of the tools are open-source projects that have been modified. Flare claims that the methods for abusing Redis, Docker, and Kubernetes services have been known for years. The industrialization of those flaws is what gives this campaign its significance. Cloud-native security measures are necessary to defend against TeamPCP: Limit public access to the Redis, Ray, Docker, and Kubernetes APIs.

Implement network segmentation and authentication. Avoid host mounts and privileged containers. Keep an eye out for any unexpected DaemonContainers, sets, and job submissions Rotate secrets and check pictures for credentials that are visible.