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.
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 –
Leave a Reply