PCPJack Hijacks 230 AWS, Google Cloud, and Azure Servers for Covert SMTP Relay Network

The threat actor known as PCPJack has hijacked cloud servers associated with Amazon Web Services (AWS), Google Cloud, and Microsoft Azure to create a covert SMTP email relay network.

"Compromised business servers across the U.S., 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 said in a statement. "The infrastructure was still running when we found it."

The threat intelligence company said it found source code, compiled binaries, deployment state logs, internet scanners, exploitation tooling, and a live Sliver configuration after the threat actor behind the operation left two open directories on a command-and-control (C2) server ("213.136.80[.]73") without any authentication.

PCPJack was first discovered by SentinelOne in April 2026 after it identified a credential theft framework that specifically targets cloud services, while taking steps to terminate and remove processes or artifacts associated with TeamPCP, another notorious hacking group that has attracted attention in recent months for its software supply chain attacks.

Staged in one of the open directories Sliver-integrated SMTP proxy deployment toolkit, along with Chisel tunneling and proxy binaries for most Linux CPU architectures, such as AMD64, ARM64, and x86. On the victim side, the binary is dropped as a hidden dot-prefixed file and persisted at "/var/tmp/.xs."

Also found in the directories are deployer scripts designed to load the Sliver C2 client configuration and filter for Linux beacons that have checked in within the last ten minutes. Beacons are implants that periodically phone home to the C2 server at regular intervals to check in and retrieve commands.

"Each beacon receives a SOCKS5 proxy port derived deterministically from an MD5 hash of its Sliver UUID, mapped into the range 10000-14999," Hunt.io noted. "The same beacon always maps to the same port across runs, eliminating the need for a shared port registry."

The script is also capable of running an SMTP quality gate that probes for outbound access to smtp.gmail[.]com:587. Hosts that fail this check are skipped with an exit code of zero.

"This gate defines the operation's purpose: hosts that cannot relay email have no value to this pipeline," the cybersecurity company added. "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."

Subsequent iterations of the deployer scripts have been found to remove the SMTP gate and the batching logic. Also present is a diagnostic script that selects five active beacons and tasks them each a shell command that checks for the following -

• Presence of Chisel binaries at known drop paths
• A Chisel process is running
• Disk space
• Reachability of port 9000 on the C2, and
• Presence of persistence artifacts, such as the cron entry or systemd service

In addition, the C2 server runs a Python script named "chisel_verifier.py" as a persistent background daemon, which enumerates active Chisel tunnel ports via ss -tlnp every 60 seconds, tests each new port for SMTP capability, and removes failed or dropped tunnels from the active pool.

Verified proxies are enriched with exit IP address, country, and ASN via services like api.ipify[.]org and ip-api[.]com. The proxy lists are then synced every five minutes via the Secure Copy Protocol (SCP) to a separate downstream server at 38.242.204[.]245. The server is currently not accessible. The end goal of the operation remains unclear at this stage.

"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," Hunt.io said, describing it as an opportunistic campaign.

"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."