PCPJack: the worm turning cloud servers into a hidden spam network

A squatter who tidies the house before moving in

Every so often a campaign comes along that's worth stopping and checking your servers over. This week it's PCPJack, a worm discovered by SentinelOne's researchers with an almost comical twist: before installing itself on a compromised machine, it evicts the previous tenant. It hunts down and removes the infections of another group (TeamPCP) and keeps the house for itself.

What it does next isn't funny at all: it steals credentials and turns the server into one more node of a hidden SMTP relay network. In other words, your server sending email for someone else — spam, phishing — with your IP and your reputation. It's already up to more than 230 hijacked servers across AWS, Google Cloud and Azure.

In one sentence

PCPJack scans for poorly exposed services, gets in, steals every credential it can find (cloud, container, developer tooling), tries to spread to more machines like a worm and, along the way, stands up a mail proxy on the server that syncs with its network every few minutes to share out the sending load.

It doesn't need an exotic 0-day: it lives off what we leave open.

How it gets in

Here's the real lesson. PCPJack doesn't force anything sophisticated; it exploits internet-exposed services that shouldn't be:

• Docker with the API exposed without authentication.
• Kubernetes with the API server or kubelet reachable.
• Redis with no password.
• MongoDB left open.
• ML platforms (RayML) and vulnerable web applications.

Sound familiar? It's exactly the "I opened it for a second to test something" collection that ends up open forever. Once inside, it harvests credentials from cloud services, containers, developer tools and even financial services, and exfiltrates them to attacker-controlled infrastructure.

Why the SMTP relay is so damaging

Having your server used to send email isn't just "annoying":

1. Your IP ends up blacklisted. The day you need your own legitimate mail to land, it goes straight to spam. Recovering IP reputation is slow and tedious.
2. It burns your resources and your bill. Bandwidth and compute you pay for so someone else can run campaigns.
3. It can land you in legal trouble. Spam and phishing leave, in everyone's eyes, from your server.
4. If they steal your cloud credentials, the relay is the least of it. With your AWS/GCP/Azure keys they can spin up more machines, run up the bill and move laterally.

How to tell if your server is affected

No panic, but be methodical. Check:

1. Are you sending mail you shouldn't be?

# Outbound connections to port 25 (SMTP) from your server
sudo ss -tnp | grep ':25'

# Unusually full mail queue (if you run Postfix)
mailq | tail -n 1

A server that isn't a mail server has no business opening outbound connections to port 25 to odd destinations. If you see them, that's a bad sign.

2. Do you have open services you don't remember?

# What's listening and on which interface
sudo ss -tlnp

# Is the Docker API exposed?
sudo ss -tlnp | grep -E ':2375|:2376'

Port 2375 (Docker without TLS) open to 0.0.0.0 is a textbook way in. Redis on 6379 and Mongo on 27017 reachable from outside, same story.

3. Suspicious processes and cron jobs

# Processes eating CPU that you don't recognise
top -b -n1 | head -n 20

# Injected scheduled tasks (a classic persistence vector)
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done

What to do today to lock down

Defending against PCPJack is, almost point for point, basic server hygiene. Here's what we apply:

Close what shouldn't be open

• Docker: never expose the API (2375/2376) to the internet. Use the local Unix socket and, if you need remote access, an SSH tunnel or TLS with client certificates.
• Redis / MongoDB: bind to 127.0.0.1 only if they're local, password mandatory, firewall in front. Never on 0.0.0.0 without auth.
• Kubernetes: API server not public, RBAC tightly scoped, kubelet protected.

Block outbound port 25 if you don't send mail

If the server doesn't send legitimate mail, cut outbound access to port 25. It's the most direct mitigation against it becoming a relay:

# Block outbound SMTP (adapt to your firewall)
sudo iptables -A OUTPUT -p tcp --dport 25 -j REJECT

Many cloud providers already block outbound 25 by default for exactly this reason. If yours doesn't, do it yourself.

Rotate credentials and review access

If you find any indication, assume compromise: rotate cloud keys (AWS/GCP/Azure), database and SSH credentials, and review access logs and your provider's billing for machines or spend you don't recognise.

Put a firewall in front of everything

The golden rule: a service only listens where it needs to listen. If a database or an orchestration API is reachable from the internet without needing to be, it's only a matter of time before someone — or some worm — finds it.

The underlying lesson

PCPJack is no evil genius: it's a patient collector of oversights. Each of its 230 nodes was, at some point, a service someone left exposed "just for a sec". The difference between being on that list or not is almost never a sophisticated exploit; it's a closed port, a password set and a firewall doing its job.

At Atenea Systems this is part of the routine review of the servers we manage: what's listening, where to, with what authentication and with what firewall in front. If you can't say for sure what you have exposed on your machines, that's exactly the first place to look. And if you'd like us to review it with you, get in touch.

References

• PCPJack Hijacks 230 AWS, Google Cloud, and Azure Servers for Covert SMTP Relay Network — The Hacker News
• Cloud Worm Evicts TeamPCP and Steals Credentials at Scale — SentinelOne Labs
• PCPJack Hijacked 230 Cloud Servers to Run a Hidden SMTP Relay Network — Hunt.io
• New PCPJack worm steals credentials, cleans TeamPCP infections — BleepingComputer