PCPJack Turns 230 Cloud Servers Into a Covert SMTP Relay Network

A threat actor tracked as PCPJack has quietly compromised at least 230 cloud servers across Amazon Web Services, Google Cloud Platform, and Microsoft Azure, repurposing them as a covert SMTP email relay network, according to The Hacker News.

What Happened

Business servers across the U.S., Europe, and Asia were silently converted into SMTP relay nodes without the account owners' knowledge. PCPJack appears to have gained initial access through exposed credentials, misconfigured cloud services, or vulnerable public-facing applications, then deployed lightweight relay software that blends into normal server traffic. The 230-server count is a confirmed floor — cloud provider security teams are still mapping the full scope of the campaign.

Why It Matters

If your instances are among the compromised hosts, the consequences stack fast.

IP reputation damage. Your server's IP is now associated with bulk email campaigns — likely spam or phishing. Major email providers will blocklist your IP, breaking legitimate outbound mail for your entire organization. Delisting petitions can take days to weeks.

Account suspension risk. AWS, GCP, and Azure all prohibit using their infrastructure for unsolicited bulk email. A compromised instance caught relaying spam can trigger resource suspension or full account termination.

Persistent foothold. An active SMTP relay implies ongoing access. The same entry point used to install relay software can be used to exfiltrate data, deploy ransomware, or pivot laterally to other systems on the same VPC or subnet.

Compliance exposure. If relayed emails are phishing campaigns originating from your IP space, your organization may face regulatory scrutiny depending on your industry and jurisdiction.

What to Do Now

1. Audit outbound SMTP rules immediately. Check your security groups and firewall rules for any instances allowing outbound connections on ports 25, 465, or 587 that you did not explicitly authorize. In most architectures, only a dedicated mail relay should have this permission — block everything else.

2. Review running processes and installed software. On any instance with unnecessary SMTP ports open, look for unfamiliar processes, recently added cron jobs, or binaries dropped in /tmp, /var/tmp, or world-writable directories.

3. Check provider abuse dashboards. AWS has an abuse notification channel; GCP and Azure have equivalent security alert streams. If PCPJack touched your account, a notice may already be waiting.

4. Rotate credentials. Any API keys, SSH keys, or service account tokens accessible from potentially compromised instances should be rotated now, not after you finish investigating.

5. Enable VPC flow logs if you haven't already. This campaign would have appeared as anomalous outbound traffic volume on any monitored network. Flow logs are the baseline for detecting lateral movement and exfiltration going forward — if you're flying blind, this is the moment to fix that.

The PCPJack campaign is a direct demonstration that a cloud instance with a public IP and loose egress controls is infrastructure that belongs to whoever finds it first. Locking down outbound ports on non-mail servers is a five-minute change that closes a significant and commonly overlooked attack surface.