PCPJack: How Attackers Hijacked 230 Cloud Servers for Covert Email Relay

Key Findings

• Threat actor PCPJack compromised 230 cloud servers across AWS, Google Cloud, and Microsoft Azure and converted them into covert SMTP relay proxies

• Complete toolkit, source code, and live command-and-control configuration were accidentally exposed in an unauthenticated directory on a C2 server

• The operation used Sliver C2 framework combined with Chisel tunneling to create a self-healing, monitored email relay network that synced verified proxies every five minutes

• Verified proxies were enriched with geolocation data and synced to a downstream server, indicating active consumption of the network by unknown parties

• The intended use case remains unclear but likely involves spam, phishing, or large-scale email delivery

Background

Hunt.io researchers discovered the PCPJack operation after the threat actor left two directories on command-and-control server 213.136.80.73 completely open without any authentication. The exposed folders contained a complete 12-file toolkit including source code, compiled binaries, deployment logs, internet scanning tools, exploitation utilities, and active Sliver C2 configuration files. PCPJack was first identified by SentinelOne in April 2026 while investigating a credential theft framework targeting cloud services. During that same investigation, analysts observed PCPJack actively removing artifacts associated with TeamPCP, another notorious hacking group focused on supply chain attacks, suggesting the two groups may share infrastructure or compete for the same resources.

Compromise Scope and Geographic Distribution

The 230 compromised servers were spread across business networks in the United States, Europe, and Asia. The victim selection appeared opportunistic rather than targeted, with the only real requirement being that servers had outbound SMTP relay capability. The March 2026 deployment state file confirmed 230 successful uploads and executions in a single coordinated deployment run, indicating either a single well-organized operator or multiple actors sharing the same infrastructure.

Technical Operation and Deployment Method

PCPJack used a methodical approach to convert compromised servers into functional SMTP proxies. The Sliver-integrated deployment toolkit included compiled Chisel tunneling binaries for most Linux architectures including AMD64, ARM64, and x86. On victim machines, the binary dropped as a hidden dot-prefixed file at /var/tmp/.xs and persisted through either cron jobs or systemd services to survive system reboots. The deployer scripts loaded Sliver C2 client configurations and filtered for Linux beacons that had checked in within the last ten minutes. Each beacon received a deterministically derived SOCKS5 proxy port based on an MD5 hash of its Sliver UUID, mapped into the range 10000-14999. This approach meant the same beacon always mapped to the same port across runs, eliminating the need for a shared port registry.

Quality Assurance and Email Relay Verification

Before servers were added to the active proxy pool, they had to pass a critical verification step. The deployment script probed for outbound access to smtp.gmail.com on port 587 to confirm SMTP relay capability. Any host that failed this test was immediately skipped with an exit code of zero. Early versions of the deployer processed beacons in batches of 50, with a 25-minute wait after uploads and 15 minutes after execution commands to accommodate slow-interval beacon check-ins. Later iterations removed both the SMTP gate and batching logic, suggesting the operator was rapidly adapting tactics and requirements.

Infrastructure Monitoring and Maintenance

A Python script named chisel_verifier.py ran as a persistent background daemon on the C2 server to keep the network operational. Every 60 seconds, it enumerated active Chisel tunnel ports via ss -tlnp, tested each port for SMTP capability, and removed any failed or dropped tunnels from the active pool. This self-healing approach kept the network functioning without manual intervention. A separate diagnostic script selected five active beacons at random and executed shell commands to verify Chisel binary presence, confirm running processes, check available disk space, test reachability of port 9000 on the C2 server, and confirm persistence artifacts remained in place. This health-check routine indicated the operator was actively managing infrastructure they valued.

Data Enrichment and Downstream Distribution

Verified proxies were enriched with exit IP address, country, and ASN information using public services like api.ipify.org and ip-api.com. The compiled proxy lists were then synchronized every five minutes via Secure Copy Protocol to a separate downstream server at 38.242.204.245. That downstream server was offline when Hunt.io discovered the operation, but evidence clearly showed the sync process had been running continuously. The five-minute refresh cycle suggested someone was actively consuming the proxy list in real time, though the downstream server remained inaccessible for analysis.

Unclear End Purpose

The ultimate objective of the operation remains unknown. Hunt.io recovered evidence that someone was actively consuming the verified proxy list every five minutes, but determining the actual use case proved impossible from the recovered files. The options range from spam and phishing campaigns to other large-scale email delivery schemes. Whether the 230-node network represented the work of a single operator iterating on tactics or multiple actors sharing infrastructure could not be determined. What is certain is that a sophisticated, self-monitoring, and self-healing email relay infrastructure was actively running and being used when discovered.

Sources

• https://thehackernews.com/2026/06/pcpjack-hijacks-230-aws-google-cloud.html

• https://securityaffairs.com/193189/cyber-crime/pcpjack-exposed-researchers-uncover-230-node-cloud-email-relay-network.html

• https://x.com/VivekIntel/status/2062789902916563005

• https://www.collector.com.tr/994567364

• https://radar.offseq.com/threat/how-pcpjack-converted-230-compromised-cloud-server-8dac97ce

• https://www.reddit.com/r/cybersecurity/comments/1tvupjr/pcpjack_hijacked_230_cloud_servers_to_send_email