Skip to content
RiverCore
TeamPCP: Six Years of Redis Attacks Now Hit the Supply Chain
TeamPCP supply chainRedis attacksKubernetes wiperTeamPCP Redis cryptomining six yearsopen-source supply chain malware campaign

TeamPCP: Six Years of Redis Attacks Now Hit the Supply Chain

12 Aug 20267 min readSarah Chen

Six years. That is the distance between the April 2020 Trend Micro writeup on Redis servers being turned into cryptominer hosts and the March 2026 discovery of kube.py variants shipping a Kubernetes wiper called Kamikaze. Oligo Security's new analysis argues those two data points sit on the same operational timeline, and the intermediate steps run through Ray, Docker, React, Next.js, GitHub Actions, and a supply chain campaign that reached open-source libraries developers actually depend on.

The Numbers

The headline claim is continuity across roughly 72 months of attacker activity against internet-facing infrastructure, as The Hacker News reported from Oligo researchers Avi Lumelsky and Gal Elbaz. The baseline event is the April 2020 Trend Micro report describing Redis servers being compromised to deploy malware. The current-cycle event is TA-NATALSTATUS, one of two campaigns Oligo attributes to TeamPCP in the second half of 2025, targeting exposed Redis servers to deliver cryptocurrency miners. Same protocol surface, same monetization path, six years apart.

The second 2H 2025 campaign, ShadowRay 2.0 (also tracked as IronErn), pivoted to AI infrastructure, hijacking Ray clusters into a self-propagating botnet. That is a materially different target class from Redis, but the operational plumbing overlaps. Oligo's specific claim: the IronErn GitHub and GitLab identities used in ShadowRay 2.0 correlate with TeamPCP's later infrastructure through GitLab authentication logs, command-and-control endpoints, reverse-shell activity, and malware staging paths.

Between those 2H 2025 campaigns and today, two more branded operations sit on the timeline. Operation PCPcat, disclosed at the end of 2025, tied the group to exploitation of security flaws in React Server Components and Next.js, with credential and data extraction as the payoff. Earlier in 2026, Flare documented a separate campaign against cloud native environments. Flare's Assaf Morag summarized the goals as building a distributed proxy and scanning infrastructure at scale, then compromising servers to exfiltrate data, deploy ransomware, conduct extortion, and mine cryptocurrency. That is a full monetization stack, not a single-purpose crew.

The technology surface list is worth sitting with: Ray, Docker, Redis, React, Next.js, Kubernetes, GitHub Actions. That is not an exotic exploitation portfolio. It is the default stack of a mid-sized fintech, iGaming operator, or ad-tech platform in 2026. What Oligo does not disclose, and what matters for defenders, is the absolute victim count across the six-year window or the dollar volume of cryptocurrency mined. Without those, we can bound the impact only by inference: a self-propagating botnet against Ray clusters plus systematic Redis scanning implies four-to-five-digit compromise counts at minimum, but that is my read, not a sourced figure.

What's Actually New

Two things separate the 2025 to 2026 activity from the 2020 baseline, and both matter for engineering teams more than the attribution question.

The first is the shift from opportunistic infrastructure compromise to software supply chain compromise. Oligo describes TeamPCP weaponizing GitHub Actions and abusing stolen tokens to poison popular open-source libraries, infecting developer systems downstream. That is a different threat model from "someone found your Redis on port 6379". In 2020 the failure mode was an exposed service. In 2026 the failure mode is a trusted dependency in your package.json, pulled through CI that ran a legitimate GitHub Action whose maintainer got compromised three hops upstream. The blast radius scales with the popularity of the library, not with the attack surface of your perimeter.

The second genuinely new element is destructive intent, geographically conditioned. Earlier kube.py variants focused on propagation and persistence, standard botnet behavior. March 2026 variants added a timezone check: if the compromised system was set to Iran time, the malware fires a DaemonSet that wipes every node in the Kubernetes cluster using a wiper named Kamikaze. Non-Kubernetes Iranian systems get a poison_pill() routine that erases the file system. Systems outside Iran get CanisterWorm, a backdoor. That is a bifurcated payload where the same initial access yields either espionage or destruction based on a timezone string, which is a crude but effective targeting primitive.

The engineering implication is uncomfortable. A timezone-conditional wiper means the same compromised container image, the same poisoned npm package, the same exploited Ray endpoint can behave radically differently across your fleet if any of your nodes have drifted timezone configurations. Multi-region operators running Docker images with locale settings inherited from base layers should not assume uniform behavior of a compromise across regions. The source does not disclose whether Kamikaze checks system timezone, container timezone, or an environment variable, which matters because those three answers imply three different mitigation strategies.

What's Priced In for Engineering Teams

Most of the technical primitives here are already familiar to any platform team that has been paying attention. Exposed Redis instances getting cryptomined is a 2020 story that platform engineers have been mitigating for years through auth requirements, network policies, and cloud-provider default hardening. Kubernetes worm behavior via kube.py-style scripts is a well-documented pattern going back to Hildegard and TeamTNT. Supply chain compromise via GitHub Actions and stolen maintainer tokens is the same threat model that produced the tj-actions incident, the ua-parser-js incident, and every npm postinstall hook advisory in recent memory.

What is not priced in, in my view, is the operational implication of Oligo's core finding: that TeamPCP is not a new actor from late 2025 but the continuation of a six-year operational ecosystem. That reframes how you should read future indicators of compromise. If your threat intel feed flags a domain as "TeamPCP infrastructure", the practical question is whether that domain also appeared in 2020-2022 Redis mining logs or 2023-2024 Docker abuse writeups. Retroactive IOC correlation across your own historical telemetry becomes valuable. Teams that discarded firewall and audit logs older than 12 months for cost reasons have just lost the ability to answer whether they were touched by earlier iterations of this same crew.

The second underpriced item is that the group's stated monetization mix, per Flare, is broad: proxy infrastructure, scanning, exfiltration, ransomware, extortion, cryptomining. A defender who models this actor as a "cryptominer" and tunes detection accordingly will miss the extortion path. Detection engineering here has to cover the full stack, which pushes back on any "we only care about high-severity events" posture.

Contrarian View

The consensus reading of Oligo's analysis is that TeamPCP is a durable, sophisticated adversary that has been quietly evolving since 2020. The contrarian reading is that Oligo itself explicitly hedges this: the researchers say whether the continuity reflects a direct rebrand, a shared operator set, or close collaboration between historically related actors "cannot be determined with 100% certainty". That is a meaningful caveat. Overlapping tradecraft, staging techniques, and infrastructure can indicate a single crew, or they can indicate a shared toolkit circulating in a specific criminal ecosystem, the way Cobalt Strike beacons or Mirai variants get reused across unrelated groups.

If the second interpretation is closer to reality, the practical implication flips. You are not defending against one persistent adversary refining their playbook, you are defending against a commoditized toolkit that gets picked up by whoever needs a working Redis scanner or Ray exploit this quarter. That changes attribution's value (down) and raises the value of generic exposure reduction (up). The unanswered question, and I would put a bound on it as follows: if within the next 12 months we see the same kube.py Kamikaze wiper appear in campaigns with clearly different C2 infrastructure and different monetization patterns, the "shared toolkit" hypothesis wins. If not, the "single evolving actor" reading holds.

Key Takeaways

  • The 2020 Trend Micro Redis campaign and the 2025 TA-NATALSTATUS campaign target the same service class with the same monetization, six years apart, which is the strongest single data point in Oligo's continuity argument.
  • The March 2026 kube.py variant introduces a timezone-conditional wiper (Kamikaze for Iran-timezone Kubernetes clusters, CanisterWorm backdoor elsewhere), meaning identical compromises can produce non-identical outcomes across a multi-region fleet.
  • Supply chain reach now runs through GitHub Actions abuse and token theft against popular open-source libraries, so perimeter-only defenses miss the current attack path entirely.
  • Oligo's own hedge, that continuity "cannot be determined with 100% certainty", means engineering teams should treat TeamPCP indicators as a shared-ecosystem signal rather than a single-actor signal.
  • Testable prediction: if the continuity thesis is correct, we should see at least one 2026-disclosed campaign share concrete IOCs (domain, C2 IP, or malware hash) with the 2020 Trend Micro Redis writeup within the next six months. If no such overlap surfaces, the shared-toolkit interpretation gains weight.

Frequently Asked Questions

Q: What is TeamPCP and how far back does its activity go?

TeamPCP is a threat actor that publicly emerged in late 2025, initially linked to Operation PCPcat, an exploitation campaign against React Server Components and Next.js. Oligo Security's August 2026 analysis argues the same operational ecosystem is responsible for Redis compromise activity dating back to a Trend Micro-documented campaign in April 2020, though Oligo notes the continuity cannot be confirmed with 100 percent certainty.

Q: What is the Kamikaze wiper and who does it target?

Kamikaze is destructive code shipped inside new variants of TeamPCP's <code>kube.py</code> Python script, observed as recently as March 2026. It checks whether the compromised system is configured for the Iran timezone, and if so, deploys a DaemonSet that wipes every node in the Kubernetes cluster. Systems outside Iran instead receive a backdoor named CanisterWorm.

Q: Which technologies has TeamPCP targeted?

Per Oligo's analysis, the group has abused known security flaws across Ray, Docker, Redis, and React, with additional exploitation of Next.js and React Server Components under Operation PCPcat. Later activity expanded into supply chain compromise via GitHub Actions abuse and stolen maintainer tokens against popular open-source libraries.

SC
Sarah Chen
RiverCore Analyst · Dublin, Ireland
SHARE
// RELATED ARTICLES
HomeSolutionsWorkAboutContact
News06
Dublin, Ireland · EUGMT+1
LinkedIn
🇬🇧EN▾