## PCPJack's Covert Cloud Operation Uncovered The threat actor known as **PCPJack** has orchestrated a sophisticated campaign, hijacking cloud servers across **Amazon Web Services (AWS)**, **Google Cloud**, and **Microsoft Azure** to forge a massive, covert SMTP email relay network. This extensive infrastructure silently converted compromised business servers in the U.S., Europe, and Asia into SMTP proxies, which were then verified for mail relay capabilities and synced to a downstream consumer every five minutes. Threat intelligence firm **Hunt.io** uncovered the operation, noting that the infrastructure was still fully active upon discovery. "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** stated. "The infrastructure was still running when we found it."  ## Accidental Discovery: Open C2 Server Exposes Tactics The intricate details of **PCPJack**'s campaign came to light due to a critical operational security blunder. The threat actor left two open directories on a command-and-control (C2) server (213.136.80[.]73) without any authentication. This oversight allowed **Hunt.io** to access source code, compiled binaries, deployment state logs, internet scanners, exploitation tooling, and a live **Sliver** configuration. **PCPJack** first emerged in April 2026, identified by **SentinelOne** as a credential theft framework specifically targeting cloud services. Notably, **PCPJack** also takes steps to remove artifacts associated with **TeamPCP**, another prominent hacking group known for its software supply chain attacks, suggesting either rivalry or an attempt to obfuscate its identity. ## Tools of the Trade: Sliver, Chisel, and Custom Scripts Among the files discovered in the open directories was a **Sliver**-integrated SMTP proxy deployment toolkit. This toolkit included **Chisel** tunneling and proxy binaries, compiled for various Linux CPU architectures such as AMD64, ARM64, and x86. On victim machines, the binary is discreetly dropped as a hidden dot-prefixed file and persisted at "/var/tmp/.xs." Deployer scripts were also found, designed to load the **Sliver** C2 client configuration and filter for Linux beacons. These beacons are implants that periodically connect to the C2 server to check in and retrieve commands. ## Sophisticated Proxy Management The operation demonstrates advanced proxy management capabilities. "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** explained. "The same beacon always maps to the same port across runs, eliminating the need for a shared port registry."  A crucial component of the deployer script is an SMTP "quality gate." This gate probes for outbound access to `smtp.gmail[.]com:587`. Hosts failing this check are skipped, as "hosts that cannot relay email have no value to this pipeline," according to the cybersecurity company. Beacons are processed in batches of 50, with timed delays to accommodate slow check-in intervals. ## Evolving Tactics and Diagnostic Capabilities Later iterations of the deployer scripts show an evolution, with the removal of the SMTP gate and batching logic. Additionally, a diagnostic script was present, designed to select five active beacons and task them with shell commands to verify: * Presence of **Chisel** binaries at known drop paths * A **Chisel** process is actively running * Available disk space * Reachability of port 9000 on the C2 * Presence of persistence artifacts, such as cron entries or systemd services  The C2 server also runs a Python script, `chisel_verifier.py`, as a persistent background daemon. This script enumerates active **Chisel** tunnel ports via `ss -tlnp` every 60 seconds, tests them for SMTP capability, and removes any failed or dropped tunnels from the active pool. ## Proxy Enrichment and Unknown Motive Verified proxies are further enriched with exit IP address, country, and Autonomous System Number (**ASN**) data using services like `api.ipify[.]org` and `ip-api[.]com`. These refined proxy lists are then synced every five minutes via **Secure Copy Protocol (SCP)** to a separate downstream server (38.242.204[.]245), though this server is currently inaccessible. The ultimate purpose of this extensive operation remains unclear. **Hunt.io** described it as an opportunistic campaign, stating, "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." Regardless of the specific intent, the implications are significant. "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."