Hijacked Cloud Servers Across AWS, Azure, and GCP Are Secretly Relaying Spam

A threat actor dubbed PCPJack has quietly taken over 230 cloud servers running on AWS, Google Cloud, and Microsoft Azure, converting them into a covert SMTP relay network designed to send spam at scale — and almost nobody noticed.

The operation, still active when discovered, was detailed by threat intelligence firm Hunt.io. Compromised business servers across the U.S., Europe, and Asia were turned into SMTP proxies, tested for email relay capability, and synced to a downstream consumer on a five-minute loop.

How PCPJack Built the Network

The attacker’s infrastructure was unexpectedly exposed. Two open directories on a command-and-control server (213.136.80[.]73) were left accessible without any authentication. Inside, Hunt.io found the full toolkit: source code, compiled binaries, deployment logs, internet scanners, exploitation tools, and a live Sliver C2 configuration.

PCPJack was first identified by SentinelOne in April 2026 as a credential theft framework targeting cloud services. But this operation goes further. Using custom deployer scripts, the attacker automated the process of converting compromised Linux servers into SOCKS5 proxies through the Sliver implant framework.

Here’s the clever part: each compromised “beacon” gets a SOCKS5 proxy port derived from an MD5 hash of its Sliver UUID, mapped into the 10,000–14,999 range. The same beacon always maps to the same port, eliminating the need for a centralized port registry. On the victim side, the malicious binary hides as a dot-prefixed file dropped at /var/tmp/.xs and persists as a service.

The SMTP Quality Gate

Not every hijacked server makes the cut. The deployer scripts run a “quality gate” — an outbound connectivity check to smtp.gmail.com:587. Servers that can’t reach that endpoint are silently skipped. No relay capability, no value. Hosts are processed in batches of 50, with waiting periods built in to accommodate slow check-in intervals from the Sliver beacons.

Later iterations of the scripts stripped out the SMTP gate and batching logic, suggesting the operator was streamlining the pipeline as it matured.

Why This Matters

This isn’t a botnet of home routers. These are legitimate business servers on major cloud platforms — infrastructure that’s supposed to be trusted by email providers and security tools alike. Mail originating from known-good cloud IP ranges has a much higher deliverability rate than obvious spam sources.

The connection to TeamPCP adds another layer. TeamPCP has been linked to software supply chain attacks, and PCPJack’s framework actively terminates and removes artifacts associated with that group’s operations on compromised systems. Whether this is competitive housecleaning or a turf war isn’t clear, but it shows organized thinking behind the campaign.

What Cloud Teams Should Check

If you’re running Linux instances on any major cloud provider, check for unexpected processes, hidden files in /var/tmp/, and unfamiliar systemd services. Specifically look for dot-prefixed binaries and unexpected outbound SMTP connectivity to known mail endpoints. Review your cloud console for instances you don’t recognize and audit IAM credentials that may have been harvested.

What’s Next

Hunt.io’s discovery is significant, but the actor left their infrastructure exposed — that’s not typical of mature operations. It’s likely PCPJack will rebuild with better operational security. Cloud providers will need to improve anomaly detection on outbound SMTP traffic from customer instances. Expect to see more threat actors adopt this model: hijack trusted infrastructure, abuse its reputation for email delivery, and let someone else’s cloud bill foot the cost.