PCPJack Turns 230 Hijacked Cloud Servers Into a Stealth SMTP Relay Grid
Compromised AWS, Google Cloud, and Azure instances were quietly converted into verified mail relays and resold downstream every five minutes.
A threat actor tracked as PCPJack has quietly assembled an SMTP relay network out of hijacked cloud infrastructure across three of the largest providers.
Researchers at Hunt.io documented the campaign, which converted roughly 230 compromised business servers running on AWS, Google Cloud, and Microsoft Azure into covert mail relays. The hijacked machines sit in the United States, Europe, and Asia.
The workflow is industrial.
Each compromised host is scanned, verified for open mail-relay capability, and then synced to a downstream consumer on a five-minute cadence. That consumer — almost certainly a spam or phishing operator paying for clean infrastructure — gets a steady drip of fresh, reputable IPs to push email through.
The appeal is obvious. Mail sent from AWS, GCP, and Azure netblocks tends to clear reputation filters that would shred traffic from known bulletproof hosts or residential proxies. SPF, DKIM, and DMARC checks against a legitimately owned cloud tenant frequently pass. Abuse takedowns, when they happen, hit the victim's account first.
Hunt.io's analysis indicates PCPJack is not exploiting a single CVE. The pattern looks like opportunistic access: exposed admin panels, weak or reused credentials, and misconfigured services on internet-facing cloud workloads. Once inside, the actor installs or enables an SMTP relay component and registers the host with the management backend.
What actually leaks here is operational rather than personal. The victims are businesses whose cloud accounts are being billed for outbound traffic and whose IP reputation is being burned. Downstream recipients of the relayed mail — likely phishing targets — are the second-order victims.
Jurisdiction is messy. The FTC and state AGs in the U.S. can pursue unauthorized-access angles where U.S. tenants are involved. In the EU and UK, breached organizations may owe GDPR Article 33 notifications to their supervisory authority within 72 hours if any personal data sat on the compromised hosts. Australian tenants fall under the OAIC's Notifiable Data Breaches scheme.
Cloud providers have their own abuse channels, and all three publish acceptable-use terms that this activity violates outright.
What affected operators should do
- Audit outbound SMTP (TCP/25, 465, 587) from cloud workloads that have no business sending mail, and block it at the security group or VPC firewall by default.
- Rotate credentials and API keys on any instance flagged with unexpected mail traffic, and check for unauthorized IAM users, persistence via cron or systemd units, and modified Postfix or sendmail configs.
- Review provider abuse notifications you may have ignored. AWS, Google, and Microsoft send them, and they are usually the first signal.
- Check sender reputation on tools like Cisco Talos and Spamhaus before your domain ends up on a blocklist you'll spend weeks getting off.
If your cloud bill spiked this quarter and you can't explain the egress, this is one reason to consider.
