PCPJack Hijacked 230 AWS, Google Cloud, and Azure Servers Into a Covert SMTP Relay

This is infrastructure theft for abuse: legitimate cloud servers quietly turned into trusted-looking mail relays, lending spam and phishing the reputation of real corporate infrastructure — and an SMTP relay running unnoticed on your cloud estate is both a breach indicator and a reputational liability.

WINTER PARK, FLORIDA — A threat actor tracked as PCPJack has hijacked roughly 230 cloud servers across Amazon Web Services, Google Cloud and Microsoft Azure to build a covert SMTP email-relay network, per The Hacker News citing research from Hunt.io (June 5, 2026). Compromised business servers across the United States, Europe and Asia were quietly converted into SMTP proxies, verified for mail-relay capability, and synced to a downstream consumer every five minutes. Hunt.io discovered the operation by chance: PCPJack left two directories on an internet-facing command-and-control server accessible with no password, exposing a complete twelve-file toolkit — source code, compiled binaries, and deployment state — on an open HTTP directory.

The deployment state told the story plainly. A version-3 state file confirmed 230 successful uploads and executions in a single deployment run in March 2026. Before a compromised server joins the pool, it has to pass a quality check: the deployer probes the host for outbound access to smtp.gmail.com on port 587, and any server that cannot relay mail is skipped entirely. That gate defines the operation's whole purpose — hosts that cannot send email have no value to this pipeline.

What Happened

Per Hunt.io, PCPJack's pipeline is a small, purpose-built system for turning compromised cloud servers into a verified pool of mail relays. The deployer loads a Sliver command-and-control client configuration, filters for Linux implants that have checked in within the last ten minutes, and assigns each one a dedicated SMTP proxy port. Each beacon receives a SOCKS5 proxy port derived deterministically from an MD5 hash of its Sliver UUID, mapped into the range 10000-14999. Before a host is added to the pool it must pass the relay quality check — outbound access to smtp.gmail.com on port 587 — and a Python script, chisel_verifier.py, runs as a persistent background process on the C2 server, enumerating active tunnel ports every 60 seconds, testing each for SMTP capability, and dropping any that fail or go offline. Verified proxies are enriched with exit IP address, country and ASN using services like api.ipify.org and ip-api.com, then synced every five minutes via SCP to a separate downstream server.

The campaign's scale and discovery are both notable. A version-3 state file recovered by Hunt.io confirmed 230 successful uploads and executions in a single deployment run in March 2026, across AWS, Google Cloud and Azure servers belonging to victims in the US, Europe and Asia. Hunt.io found the operation not through victim reports but because PCPJack left two directories on an internet-facing C2 server accessible without authentication — a complete twelve-file toolkit including source code, compiled binaries and deployment state, sitting on an open HTTP directory. That operational-security lapse is what exposed the inner workings, including the Sliver-and-Chisel tunneling architecture and the SMTP verification logic. PCPJack is not new to researchers: earlier reporting documented a PCPJack credential stealer that exploits multiple CVEs to spread worm-like across cloud systems, which is consistent with how compromised servers end up in this relay pool in the first place.

The Mechanism: Borrowing the Reputation of Real Infrastructure

The value of this operation to PCPJack is not the servers' compute — it is their reputation. Mail sent through a legitimate business's cloud server inherits that server's sending reputation, its clean IP history, and the implicit trust that receiving systems extend to established corporate infrastructure. Spam and phishing relayed this way are far more likely to reach inboxes than mail sent from known-bad hosts. The selection gate makes the intent unambiguous: a host that cannot relay mail is discarded, because the only thing PCPJack wants from a compromised server is its ability to send trusted-looking email. This is the same logic behind the malicious-infrastructure economy The CyberSignal documented in the takedown of Stark Industries, a bulletproof hoster tied to Russia — except here the infrastructure is stolen from legitimate owners rather than rented from a complicit provider.

A Breach Indicator Hiding in Plain Sight

For the organizations whose servers are in the pool, the relay is a breach indicator they may not be monitoring for. Most cloud workloads have no business sending outbound SMTP at all, so a server quietly making mail connections is a high-fidelity sign of compromise — but only if someone is watching the right port. The deployment's own design hands defenders the detection: it standardizes on port 587 to smtp.gmail.com for its quality check and relays over per-beacon SOCKS5 ports. An organization that alerts on unexpected outbound SMTP from non-mail systems would catch exactly this activity. The pattern echoes other recent abuse of cloud and identity platforms, including the Kali365 phishing kit's expansion across AWS, Okta and other platforms — attackers increasingly operate from inside the cloud services defenders trust.

The Reputational and Abuse Liability

Beyond the breach itself, a hijacked relay is a business liability. When a compromised server starts relaying spam, its IP address — and potentially the organization's broader IP space — can be added to email blocklists, quietly degrading the company's own ability to deliver legitimate mail. The damage can outlast the intrusion: cleaning the compromise does not automatically restore a torched sending reputation, which can take significant effort to rebuild. This is the under-appreciated cost of infrastructure-abuse campaigns like PCPJack and the compromised-site networks The CyberSignal covered in the DriveSurge pay-per-install operation: the victim absorbs not just the breach but the downstream reputational harm of being used as a launch point against others.

Scope and Impact

The documented scope is roughly 230 cloud servers confirmed in a single March 2026 deployment run, spanning AWS, Google Cloud and Azure, with victims in the US, Europe and Asia. Because Hunt.io's visibility came from a recovered state file for one deployment run, the 230 figure is best read as a confirmed floor for that run rather than a ceiling on PCPJack's total activity — the actor's worm-like credential-stealer history suggests an ongoing pipeline that feeds the pool over time. The victims are business servers, which is the point: only hosts capable of relaying mail are retained, so the affected population skews toward organizations with legitimate cloud infrastructure whose sending reputation is worth stealing.

The structural risk is twofold. First, each hijacked server is a compromised asset inside the victim's cloud environment, which means the relay is a symptom of a deeper intrusion that began with whatever initial-access method PCPJack used — consistent with the credential-stealer-exploiting-multiple-CVEs behavior documented in earlier reporting. Second, the abuse externalizes harm: the victim's infrastructure is used to attack third parties, and the victim bears the reputational consequences. The five-minute sync to a downstream consumer indicates an operation built for sustained, automated use rather than a one-off, so a server left in the pool keeps relaying until it is detected and cleaned.

Specifics to confirm against Hunt.io's published research include the precise initial-access vector for the compromised servers, the recommended detection and remediation steps, and the full indicator set — C2 infrastructure, the toolkit's file hashes, and the downstream consumer details. The 230 figure and the March 2026 timing come from a recovered deployment-state file and are reported as Hunt.io's findings; the relationship between this SMTP-relay operation and the previously reported PCPJack credential stealer should be treated as a consistent-but-evolving picture of the same actor rather than a single confirmed campaign chain.

Response and Attribution

For cloud and platform teams, the core detection is simple and underused: alert on unexpected outbound SMTP — TCP ports 25, 465 and 587 — from servers that have no business sending mail. That single control catches the heart of this operation, because the relay cannot function without outbound SMTP and most workloads never legitimately use it. Pair it with an audit of cloud instances for unauthorized mail-relay configurations and listeners, and for unexpected egress to unfamiliar downstream consumers. Then lock down egress with security groups and firewall rules so that only designated mail systems can send outbound SMTP at all — egress filtering turns this from a detection problem into a prevention one. Finally, review initial-access hygiene: exposed management ports, weak or leaked credentials, and unpatched internet-facing services are the usual entry points for the compromise that precedes the relay.

For email, abuse and brand-protection teams, the action is to monitor your own IP space for blocklisting. A hijacked relay can quietly torch the organization's sending reputation, and an appearance on a major email blocklist is sometimes the first externally visible sign that a server has been conscripted. Catching it early limits both the duration of the abuse and the depth of the reputational damage, and gives the security team a concrete lead — the offending IP — to trace back to the compromised host. Treat reputation monitoring as a security signal, not just a deliverability metric.

On attribution, the activity is tracked under the actor label PCPJack by Hunt.io, and the picture is unusually detailed because the actor exposed its own toolkit on an unauthenticated server — an operational-security failure rather than a defender's deep investigation. There is no nation-state attribution in the reporting reviewed for this brief; PCPJack presents as a financially or abuse-motivated operator monetizing stolen infrastructure. The CyberSignal frames the takeaway around detection and egress control because those defenses hold regardless of the actor's identity or motive: a cloud server sending unexpected mail is a problem worth catching whoever is behind it.

The CyberSignal Analysis

Signal 01 — Most Cloud Servers Should Never Send Mail

The single most actionable idea here is a default most organizations have not set: the overwhelming majority of cloud workloads have no legitimate reason to make outbound SMTP connections, so any that do are worth investigating. PCPJack's entire operation depends on outbound SMTP, and a detection rule for unexpected mail traffic from non-mail systems would surface it immediately. The broader lesson is to define what 'normal' egress looks like for each workload class and alert on deviations — egress is where infrastructure-abuse campaigns reveal themselves, and it is one of the least-monitored surfaces in many cloud environments.

Signal 02 — Stolen Reputation Is the Real Product

PCPJack discards any server that cannot relay mail, which makes the operation's purpose unmistakable: it is harvesting the sending reputation of legitimate infrastructure, not its compute. That reframes the harm. The victim is not only breached; their good name is being rented out to deliver attacks against others, and the reputational damage — blocklisting, degraded deliverability — can persist after the intrusion is cleaned. Defenders should treat their organization's IP and domain reputation as an asset attackers actively target, and monitor it as a security signal rather than leaving it to the marketing team's deliverability dashboards.

Signal 03 — The Relay Is a Symptom of a Deeper Intrusion

An SMTP relay does not appear on a server by magic; it is the visible end of a compromise that started somewhere — exposed ports, stolen credentials, or an unpatched service, consistent with PCPJack's worm-like credential-stealer history. Finding a hijacked relay should therefore trigger a full intrusion investigation, not just removal of the relay, because the access that allowed it likely remains and can be reused for worse. The relay is the smoke; the initial-access foothold is the fire, and remediating only the symptom leaves the door open for the actor to return.

Sources