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

Source: The Hacker News

Overview

Ravie Lakshmanan – Jun 05, 2026 – Threat Intelligence / Cloud Security

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 left two open directories on a command‑and‑control (C2) server (213.136.80[.]73) without authentication.

PCPJack was first discovered by SentinelOne in April 2026 after it identified a credential‑theft framework that specifically targets cloud services, while also taking steps to terminate and remove processes or artifacts associated with TeamPCP, another notorious hacking group.

Deployment Toolkit

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

The directories also contain deployer scripts that 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 to 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 can also run 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.”

Script Evolution

Later versions of the deployer scripts remove the SMTP gate and the batching logic. They also include a diagnostic script that selects five active beacons and tasks each with a shell command checking for:

• Presence of Chisel binaries at known drop paths
• A running Chisel process
• Disk‑space availability
• Reachability of port 9000 on the C2
• Persistence artifacts such as cron entries or systemd services

C2 Server Operations

The C2 server runs a persistent Python daemon chisel_verifier.py that 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 SCP to a downstream server at 38.242.204[.]245. That server is currently not accessible. The ultimate goal of the operation remains unclear.

“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