PCPJack Exposed: Researchers Uncover 230-Node Cloud Email Relay Network

Researchers uncovered a 230-node cloud-based email relay network after the actor PCPJack accidentally exposed tools, logs, and C2 files online

A threat actor tracked as PCPJack compromised 230 cloud servers across Amazon Web Services, Google Cloud, and Microsoft Azure and turned them into a covert email relay network. Hunt.io researchers discovered the operation because PCPJack accidentally left two directories on an internet-facing command-and-control server accessible without any password or authentication.

“A complete 12-file toolkit, source code, compiled binaries, and deployment state, was sitting on an open HTTP directory with no authentication required.” reads the report published by Hunt.io.

“The version 3 state file confirms 230 successful uploads and executions in a single deployment run in March 2026.”

The exposed folders contained source code, malware binaries, deployment logs, scanning tools, exploitation utilities, and a live Sliver command-and-control configuration. In short, the attackers left behind a detailed view of how the entire operation worked.

SentinelOne first identified PCPJack in April 2026 while investigating a credential theft framework built specifically to target cloud services. During that investigation, analysts noticed the group was also actively terminating processes linked to TeamPCP, another hacking group known for software supply chain attacks. The two groups appear to share or compete over the same infrastructure, though the relationship remains unclear.

The toolkit Hunt.io recovered from the open directories tells you exactly how the operation worked. The attacker used Sliver, an open-source command-and-control framework, combined with Chisel tunneling binaries compiled for most Linux CPU architectures: AMD64, ARM64, and x86. On compromised servers, the binary drops as a hidden dot-prefixed file and persists at /var/tmp/.xs, using either a cron job or a systemd service to survive reboots.

The deployer scripts are methodical. They load the Sliver C2 client configuration, filter for Linux implants that have checked in within the last ten minutes, and then assign 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. The same beacon always maps to the same port across runs, eliminating the need for a shared port registry.” continues the report.

Before a compromised server gets added to the pool, it has to pass a quality check. The deployer probes for outbound access to smtp.gmail.com on port 587. Fail that test and the host gets skipped entirely.

“This gate defines the operation’s purpose: hosts that cannot relay email have no value to this pipeline.” continues the report. “Beacons are processed in batches of 50, with a 25-minute wait after uploads and 15 minutes after execution commands, to accommodate slow-interval beacon check-ins.”

Later versions of the deployer removed this gate and the batching logic, suggesting the operator was quickly adapting his tactic.

A Python script called chisel_verifier.py runs as a persistent background process on the C2 server. Every 60 seconds it enumerates active tunnel ports, tests each one for SMTP capability, and drops any that fail or go offline. Verified proxies get 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 at 38.242.204[.]245. That server was offline when Hunt.io checked, but the sync was clearly running before they found it.

A separate diagnostic script rounds out the toolkit. It selects five active beacons at random and runs a shell command on each to verify the presence of Chisel binaries at known drop paths, confirm a Chisel process is running, check available disk space, test reachability of port 9000 on the C2, and confirm persistence artifacts are still in place. It’s the kind of health-check script you write when you’re managing infrastructure you care about keeping alive.

“The verified proxy list is being synced every five minutes to that server, and someone is consuming it. Whether for spam, phishing, or something else, the infrastructure to deliver at scale was clearly running.” states Hunt.io.

Hunt.io describes the campaign as opportunistic, targeting business servers across the US, Europe, and Asia without a clear pattern of victim selection beyond the requirement that they can relay email. What the downstream consumer was actually doing with 230 verified cloud-hosted SMTP proxies, refreshed every five minutes, remains unknown. The options aren’t great.

The investigation shows a 230-node network, but it’s unclear whether it was run by one operator or multiple groups using the same infrastructure. What is certain is that someone built a working, monitored, self-healing email relay system across major cloud providers, and it was discovered only because an open directory was left without a password.

“The 230-node outcome is the observable result. Whether this progression reflects a single operator iterating or multiple actors sharing the same infrastructure cannot be determined from the recovered files.” concludes the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, PCPJack)