# The Group That Mined Redis Servers for Years Before Hitting the Supply Chain
Five years is a long time to operate in the open before anyone pieces it together. That's the timeline now attached to TeamPCP, a threat actor whose history of hammering exposed Redis instances apparently goes back to 2020 — well before the group turned its attention to the software supply chain, where the real damage multiplies.
New analysis connecting those two campaigns is overdue. And its implications are less about this particular group and more about how long determined attackers can operate at the infrastructure layer before defenders notice the progression.
## From Exposed Databases to Package Poisoning
The link between TeamPCP's early Redis exploitation and its later supply chain work rests on a cluster of technical indicators: overlapping domains, shared malware deployment paths, consistent staging techniques, and backend infrastructure that didn't change much between campaigns. These aren't weak correlations. When threat actors reuse the same staging servers or C2 domains across years and campaigns, it's usually laziness — or confidence that nobody's watching closely enough to connect the dots.
Redis has been a target of choice for opportunistic attackers for the better part of a decade. The reasons are mechanical: the database runs on port 6379, frequently binds to 0.0.0.0 by default, and historically shipped with no authentication required out of the box. A Shodan search at any given moment reveals tens of thousands of exposed instances. The attack pattern is almost ritual — scan, authenticate as an empty string, write a cron job or SSH key, establish persistence, deploy whatever payload you came with. In 2020, that payload was usually a cryptominer. Monero was the coin of choice; Redis servers are modest hardware but they're always on.
What makes TeamPCP's story more interesting than a standard cryptomining crew is the pivot. At some point between those early infrastructure attacks and the supply chain campaign, something changed. Either the group's tasking shifted, or they got better, or both. Supply chain attacks require a different skill set than scanning for open Redis ports — you need to understand how package registries work, how maintainers authenticate, how CI/CD pipelines pull dependencies, and where the trust gaps are.
## The Maturation Pattern Nobody Talks About
Here's what the incident reports consistently miss: groups that spend years running commodity attacks on exposed infrastructure aren't just running commodity attacks. They're learning. Every compromised server is a foothold for additional reconnaissance. Every cryptomining campaign teaches you something about detection thresholds — what triggers an alert, what gets ignored, how long you can run a CPU-intensive process before someone notices. Redis specifically taught attackers how to establish persistence through config file manipulation, a technique that transfers to other environments.
TeamPCP's five-year timeline isn't surprising to anyone who's tracked groups like TeamTNT or Rocke, both of which started with exposed cloud services and escalated over time. TeamTNT, which ran sophisticated cloud credential theft operations, emerged from the same opportunistic cloud infrastructure targeting that defined the 2019-2021 period. The pattern is consistent: initial access via exposed service, persistence establishment, lateral movement, and eventually a capability upgrade that takes the group to a higher-value target class.
The supply chain move is the capability upgrade that matters here. An attacker who can compromise a software package — even a modestly popular one — multiplies their reach in ways that scanning for open Redis ports never could. A single poisoned package can land malware on thousands of developer workstations before anyone notices. If those developers work in fintech, healthcare, or government, the downstream exposure is substantial.
## What Defenders Are Still Getting Wrong
The coverage of TeamPCP's Redis campaign will predictably focus on the historical timeline and the technical indicators. What it won't focus on is the structural problem that made this campaign possible for five years: exposed Redis instances are still everywhere.
The Redis project added authentication requirements as a default in version 7.0, released in 2022. That's two years into TeamPCP's apparent campaign. A meaningful percentage of the exposed instances that were vulnerable in 2020 are still vulnerable today — not because administrators haven't patched, but because nobody patched the underlying configuration problem. Authentication on, network binding restricted, firewall rules in place. Check your infrastructure now, not after the next attribution report.
For the supply chain exposure: the defensive calculus is harder but not hopeless. If your build pipeline pulls from public registries without pinning exact hashes, you're trusting the current state of those packages at build time — which means you're trusting that every maintainer's account is secure, that the registry itself hasn't been compromised, and that no typosquatted or dependency-confused package has slipped in. That's a lot of trust.
## HackWire Analysis
The TeamPCP attribution matters primarily as a case study in how threat actor maturation actually works in practice — and why the industry's tendency to track groups by their most recent campaign actively obscures the risk.
Most threat intelligence focuses on the headline: a supply chain attack, a ransomware deployment, a nation-state intrusion. The backstory — years of quiet infrastructure exploitation that funded capability development and provided operational security lessons — gets compressed into a paragraph or dropped entirely. The result is a distorted picture of threat actor sophistication. Groups don't spontaneously appear with supply chain attack capabilities. They earn them.
The overlapping infrastructure between TeamPCP's Redis campaigns and their supply chain work is actually the more important finding here. It tells us the group didn't compartmentalize. They were comfortable reusing domains and staging infrastructure across very different campaign types over a five-year span. That's either operational sloppiness or confidence in low detection rates. Either way, it's an indicator that similar infrastructure reuse is probably present in campaigns we haven't attributed yet.
For security teams, the actionable read isn't "patch Redis" — though you should. It's that your threat intelligence program needs longitudinal visibility. Attackers who've been in your network category for five years don't start their campaign the day you detect them. They started years ago. Building detection rules that catch low-and-slow infrastructure scanning and persistence establishment is harder than catching ransomware deployment, but it's also where the clock actually starts.
The supply chain question for defenders is specific: do you know which packages in your build pipeline have had maintainer account changes in the last 12 months? Because that's the attack surface. Not the package itself — the human who controls the package's publish credentials.
— HackWire Editorial
## Related Coverage