TeamPCP is not looking like a short-lived opportunistic crew. New research reported by The Hacker News says Oligo Security has connected the actor’s recent software supply chain activity to older internet-facing infrastructure attacks, including Redis compromises dating back to 2020. For defenders, the important lesson is not the name attached to the campaign; it is the operating pattern. The same habits used to break into exposed services can later be reused to compromise build pipelines, steal tokens, poison packages, and scale attacks through legitimate cloud infrastructure.

The report describes overlapping domains, malware delivery paths, staging methods, backend infrastructure, and tradecraft across multiple campaigns. Those links tie TeamPCP to activity against Redis, Ray, Docker, React Server Components, Next.js, Kubernetes environments, and open-source development workflows. In practical terms, organizations should treat this as another warning that cloud exposure management and software supply chain security are now the same conversation.

What researchers connected

According to the reporting, Oligo linked TeamPCP to campaigns observed in the second half of 2025, including ShadowRay 2.0, also known as IronErn, and TA-NATALSTATUS. ShadowRay 2.0 involved the hijacking of artificial intelligence infrastructure into a self-propagating botnet, while TA-NATALSTATUS focused on exposed Redis servers and cryptocurrency mining. Oligo also assessed that TA-NATALSTATUS evolved from Redis-focused activity described in 2020, suggesting a much longer operational history than the TeamPCP label alone would imply.

The activity did not remain limited to one product or one technique. The same ecosystem reportedly abused known weaknesses and risky deployments across Redis, Docker, Ray, React, and Kubernetes. Later operations expanded into supply chain compromise by abusing GitHub Actions workflows and stolen tokens to poison open-source libraries. That evolution makes sense from an attacker’s perspective: once a group has scanning infrastructure, cloud footholds, malware staging, and automation, package ecosystems and CI/CD systems become high-leverage targets.

Why Redis and similar services keep appearing

Redis is a recurring target because it is often deployed as fast infrastructure first and hardened later, if at all. When Redis, Docker APIs, Ray dashboards, Kubernetes control components, or development services are exposed to the internet without strict authentication and network controls, they become easy candidates for automated exploitation. Attackers do not need a novel zero-day if they can find thousands of misconfigured or unpatched services.

This matters for security teams because public exposure is frequently accidental. A test instance is moved into production, a security group is widened during troubleshooting, a container image defaults to permissive binding, or a developer spins up an AI workload outside the standard platform. The resulting service may be visible for only a short time, but modern botnets and cloud-focused actors scan continuously.

The supply chain turn raises the blast radius

TeamPCP’s reported shift into open-source package compromise is especially concerning because it changes the victim model. An exposed server gives the attacker one organization’s compute, secrets, or data. A poisoned library can reach every downstream developer, build server, and deployment process that consumes it. If CI tokens, package publishing credentials, GitHub Actions secrets, or cloud keys are captured, the attack can jump from one repository to many environments.

The reported overlap between IronErn identities and later TeamPCP infrastructure also shows why defenders should avoid treating campaigns as isolated incidents. A cryptomining alert on a Redis host, a suspicious GitHub Actions workflow edit, and unexpected Kubernetes DaemonSet behavior may look unrelated inside separate dashboards. Correlating them across identity, DNS, command-and-control infrastructure, token use, and runtime telemetry can reveal a larger intrusion chain.

Kubernetes warning signs

The report also highlights malware updates aimed at Kubernetes environments, including a Python script referred to as kube.py. Earlier versions reportedly focused on propagation and persistence, while newer variants observed in 2026 added destructive logic in some circumstances. That is a reminder that cryptomining and proxy abuse should not be dismissed as low-impact nuisance activity. The same initial access can be repurposed for data theft, extortion, ransomware staging, or destructive operations.

Security teams should review Kubernetes clusters for unexpected DaemonSets, privileged pods, unfamiliar service accounts, suspicious image pulls, and workloads running from unusual namespaces. Runtime detections should be paired with cloud audit logs so teams can determine whether the attacker modified IAM roles, extracted secrets, or created new persistence mechanisms.

Practical defensive actions

Start with external exposure. Inventory internet-facing Redis, Ray, Docker, Kubernetes, CI/CD, and development services. Remove public access wherever possible, require strong authentication, restrict management interfaces to VPN or private networks, and use cloud security posture tooling to catch newly exposed ports quickly.

Next, patch and harden the services that TeamPCP-linked activity has repeatedly targeted. Known vulnerabilities and unsafe defaults are attractive because they can be automated. Disable unauthenticated Redis access, avoid binding administrative services to public interfaces, restrict Docker socket access, and ensure AI and data-science infrastructure follows the same security baseline as production applications.

For the software supply chain, rotate long-lived tokens, move package publishing to short-lived trusted publishing flows where supported, require branch protection, and review GitHub Actions permissions. Workflows should use least privilege by default, and secrets should not be available to jobs that do not need them. Monitor for unexpected package releases, changes to maintainers, modified build scripts, and new workflow files.

Finally, connect cloud, endpoint, repository, and package telemetry. A practical detection program should look for combinations: scanning from a new cloud instance, suspicious Redis commands, outbound connections to unfamiliar staging domains, GitHub token use from unusual geographies, and Kubernetes workloads that appear shortly after a CI event. The distinctive defensive takeaway is simple: TeamPCP-style operations thrive in the seams between infrastructure security and developer security.

Bottom line

The TeamPCP reporting reinforces a trend defenders can no longer ignore. Attackers that start with exposed services can mature into supply chain operators because both paths reward automation, stolen credentials, and cloud-scale infrastructure. Organizations should respond by reducing public attack surface, securing CI/CD identities, and investigating “minor” cryptomining or proxy incidents as possible indicators of a broader operational ecosystem.

Source: The Hacker News source