A threat actor called PCPJack quietly converted over 230 business cloud servers into SMTP email relays — and left the entire operational toolkit sitting in unauthenticated open directories on its own command-and-control infrastructure.
What Hunt.io Found on an Open C2 Server
The discovery came from threat intelligence firm Hunt.io, which located two open directories on a C2 server at IP address 213.136.80[.]73. No authentication was required to access them. Inside: source code, compiled binaries, deployment state logs, internet scanners, exploitation tooling, and a live Sliver C2 configuration. The infrastructure was still actively running at the time of discovery.
What made the exposure operationally significant wasn’t just the presence of tools — it was that those tools revealed the full pipeline. From initial compromise through SMTP verification and downstream proxy synchronization, the entire architecture was readable in those directories. PCPJack had handed over its own operational blueprint through basic opsec failure.
SentinelOne had first identified PCPJack in April 2026, flagging a credential theft framework built specifically to target cloud services — AWS, Google Cloud, and Azure. That report also noted behavior designed to terminate and remove artifacts tied to TeamPCP, a separate hacking group that has drawn attention for software supply chain attacks. The connection between PCPJack and TeamPCP is not fully established, but the deliberate effort to erase TeamPCP traces suggests awareness of, or competition with, that group’s footprint.
The compromised servers span the United States, Europe, and Asia. All were business-owned cloud instances that were silently repurposed without disrupting their primary functions — making detection harder and dwell time longer.
How the Infrastructure Was Built and Operated
The toolkit staged in the open directories centers on a Sliver-integrated SMTP proxy deployment system, bundled with Chisel tunneling binaries compiled for multiple Linux CPU architectures: AMD64, ARM64, and x86. On a compromised host, the Chisel binary drops as a hidden dot-prefixed file and persists at /var/tmp/.xs.
The deployer scripts form the automation layer. They connect to the local Sliver C2 server, pull a list of active Linux beacons that have checked in within the last ten minutes, push a Chisel binary to each one, and install it as a persistent service. Beacons — implants that periodically contact the C2 to receive commands — are processed in batches of 50. The scripts introduce a 25-minute wait after uploads and a 15-minute pause after issuing execution commands, deliberately pacing operations to accommodate slower beacon check-in intervals.
Port assignment is deterministic rather than registry-based. Each beacon receives a SOCKS5 proxy port derived from an MD5 hash of its Sliver UUID, mapped into the range 10000–14999. The same beacon maps to the same port across every run. This design eliminates any need for a shared port registry, reducing coordination overhead and limiting the data that needs to be centrally stored.
Before a compromised host enters the active relay pool, it passes through an SMTP quality gate. The deployer scripts probe outbound access to smtp.gmail[.]com:587. Any host that fails this test is skipped with an exit code of zero — no retry, no noise, no wasted effort. As Hunt.io put it directly: hosts that cannot relay email have no value to this pipeline. Later iterations of the deployer scripts removed this gate and the batching logic entirely, suggesting the operation matured and the operator grew more confident in the upstream filtering.
A Python script named chisel_verifier.py runs as a persistent background daemon on the C2 server. Every 60 seconds it enumerates active Chisel tunnel ports using ss -tlnp, tests each new port for SMTP relay capability, and removes failed or dropped tunnels from the active pool. Verified proxies are then enriched with exit IP address, country of origin, and ASN data pulled from api.ipify[.]org and ip-api[.]com. The completed proxy list synchronizes every five minutes via SCP to a downstream server at 38.242.204[.]245 — which was not accessible at the time of reporting.
Diagnostics, Persistence, and What’s Still Unknown
A separate diagnostic script rounds out the toolkit. It selects five active beacons and issues shell commands to verify six conditions: whether Chisel binaries are present at known drop paths, whether a Chisel process is currently running, available disk space, reachability of port 9000 on the C2, and whether persistence artifacts — cron entries or systemd services — are in place. This is operational health monitoring built directly into the attack chain, not a secondary tool.
The persistence mechanism at /var/tmp/.xs is straightforward but durable. The /var/tmp directory is typically excluded from automated cleanup routines that sweep /tmp, and the dot-prefix hides the file from casual inspection. Combined with systemd service installation or cron persistence depending on the target host’s configuration, a compromised server stays inside the relay network through reboots and routine maintenance without obvious signals.
What the 230-node network was ultimately built to do remains an open question. A covert SMTP relay network of this scale has obvious utility for high-volume spam campaigns, phishing infrastructure, or business email compromise operations — but Hunt.io has not confirmed a specific end use. The downstream server at 38.242.204[.]245, which received the synced proxy lists every five minutes, was unreachable when researchers examined it. Whatever was consuming those lists had either shut down or relocated.
The operational security failure that exposed all of this — two unauthenticated open directories on the C2 — is worth holding separately from the sophistication of the tooling itself. The Sliver integration, the deterministic port mapping, the SMTP quality gate, the automated verification daemon: these reflect careful engineering. Leaving the directory index open without authentication does not. It is not the first time a well-resourced threat actor has been undone by a misconfigured server, and the gap between technical capability and basic infrastructure hygiene continues to produce exactly these kinds of exposures.
The chisel_verifier.py daemon was still running when Hunt.io documented the server — probing ports, testing relay capability, and updating the proxy list every 60 seconds.
