PCPJack Hijacked 230 AWS, GCP, and Azure Servers to Run a Hidden SMTP Relay Network

SentinelOne documented PCPJack in April 2026, covering how the campaign gains initial access and harvests credentials from compromised Linux servers. What that report didn't cover was what happens next.

During a routine infrastructure hunting session, our team found an open directory on 213.136.80[.]73, a server already tied to PCPJack's C2 infrastructure. No authentication required. Twelve files sitting exposed on port 8444, including source code, compiled binaries, and deployment state logs.

A second open directory on port 9443 exposed the operator's live working directory, active scanners, exploitation tooling, and a Sliver C2 configuration, all accessible at the same time.

The following summarizes what we recovered and what it reveals about the operation.

Key Takeaways

• A complete 12-file toolkit, source code, compiled binaries, and deployment state, was sitting on an open HTTP directory with no authentication required.

• The version 3 state file confirms 230 successful uploads and executions in a single deployment run in March 2026.

• Four of five ports in chisel_verified.json fall outside the range used by the recovered deployers, and their timestamps predate the first documented run, indicating earlier operations not captured in this collection.

• An SMTP quality gate in version 1 and a standalone verification daemon confirm the network's purpose is email relay.

• Verified proxy lists sync every five minutes via SCP to a separate downstream server at 38.242.204[.]245, which was not accessible during analysis.

• All three Chisel binaries are unmodified stock builds from the public jpillora/chisel repository.

Discovery and Initial Triage

Hunt.io's AttackCapture File Manager surfaced 213.136.80[.]73 (Contabo GmbH, AS51167, Lauterbourg, France) hosting an open directory on port 8444

The IP was already tagged as PCPJack infrastructure from the SentinelOne report, ruling out a random misconfiguration.

Further scanning uncovered a second open directory on port 9443 serving the operator's live /tmp directory. Both directories were downloaded in full before analysis.

Port 8444 contained a complete Sliver-integrated SMTP proxy deployment toolkit. Port 9443 contained an active operation: internet-scale scanners, Spring Boot exploitation tooling, a JVM heap dump credential parser, an Apache Parquet credential database with exactly 300 shards, and a live Sliver C2 server with configuration exposed.

Port 8444 is where the monetization layer lives. Here's what each file does.

The Proxy Conversion Engine: File-by-File Analysis

Multi-Architecture Binary Preparation for Universal Cloud Coverage

The directory contains three Chisel binaries: chisel_amd64, chisel_arm64, and chisel_386. Together they cover every major Linux CPU architecture in cloud use - x86-64 for the majority of VMs, ARM64 for AWS Graviton instances, and 32-bit x86 for older or containerized workloads.

Chisel is an open-source TCP tunneling tool developed by Jamie Pillora. It supports a client-server model where a remote client establishes a reverse tunnel back to a server; in SOCKS5 mode, that tunnel becomes a full network proxy. All three binaries are stock builds - the github.com/jpillora/chisel import path string is intact in each binary, confirming no modifications were made.

Using unmodified binaries means file hashes match the upstream project and may not trigger hash-based detections. Filenames are unobfuscated on the staging server. On the victim side, the binary is dropped as a hidden dot-prefixed file and persists at /var/tmp/.xs.

Beacon-Integrated Deployment Pipeline: Three Generations of Evolving Automation

Operational baseline. The first deployer loads the Sliver C2 client configuration from /root/.sliver-client/configs/root_localhost.cfg, connects to the local Sliver API, and filters for Linux beacons checked in within the last ten minutes. Infrastructure is defined by hardcoded constants at the top of the script:

Each beacon receives a SOCKS5 proxy port derived deterministically from an MD5 hash of its Sliver UUID, mapped into the range 10000-14999. The same beacon always maps to the same port across runs, eliminating the need for a shared port registry.

The filter exclusion list (9000, 8080, 2053) identifies the ports the Chisel server itself listens on. Port 9000 is the primary; port 8080 passes most corporate web proxies; port 2053 blends into firewall rules that pass traffic near the DNS port range.

Before deploying, the script runs an SMTP quality gate - a shell probe testing outbound access to smtp.gmail.com:587. Hosts that fail are silently skipped with exit 0.

This gate defines the operation's purpose: hosts that cannot relay email have no value to this pipeline. 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.

Refinement under operational pressure. Version two removes the SMTP gate entirely, deploying to all active Linux beacons regardless of mail relay capability. Assessment: this is consistent with a decision to deploy broadly and let chisel_verifier.py handle SMTP filtering post-deployment.

The key structural change is splitting state tracking into two separate lists - uploaded and executed - making each phase independently resumable. The recovered state file shows 50 uploads and zero executions, indicating the run was interrupted between phases.

The pgrep idempotency pattern changed from R:0.0.0.0:{port}:socks to R:.*:{port}:socks - a regex broadening that catches the tunnel regardless of bind address. These changes are consistent with iterative testing between runs, where observed edge cases prompted targeted fixes.

Scale over precision. Version three removes batching entirely. The script uploads to all active beacons in a single sequential loop, waits 30 minutes, then executes on all in a second pass. Per-beacon metadata tracking is dropped - only the port map and aggregate counts are saved. The IsIOC = False flag set on every upload may reflect deliberate avoidance of Sliver's internal IOC tracking, though it could also be a default pattern from public API examples. The state file confirms: "uploaded": 230, "executed": 230.

The execution payload picks up from there.

Persistence Mechanisms in Depth

The execution payload searches for a usable Chisel binary across /tmp/.ch5, /tmp/.ch4, /tmp/.ch3, /tmp/.ch2, and /tmp/.ch in order. Once found, the binary is copied to /var/tmp/.xs - preferred over /tmp because many Linux distributions mount /tmp as tmpfs with the noexec flag, preventing execution of binaries stored there.

Privilege detection uses a single id -u check. Root context installs a systemd service named xsync; non-root installs a five-minute cron watchdog. The name xsync resembles rsync and blends into typical Linux service listings. The # xsync comment in the crontab entry acts as a marker, allowing subsequent runs to find and replace it without accumulating duplicate entries.

Fleet Diagnostics and Continuous SMTP Proxy Qualification

Post-deployment health checking. The diagnostic script randomly selects five active beacons and tasks each with a shell command that checks for Chisel binaries at known drop paths, whether a Chisel process is running, disk space, reachability of port 9000 on the C2, and whether the xsync cron entry or systemd service is present.

It waits 12 minutes for results, calibrated to Sliver's default beacon check-in interval. The existence of this script indicates that deployments did not always succeed and the operator built tooling to diagnose why.

Continuous SMTP verification. chisel_verifier.py runs as a persistent background daemon on the C2 server. Every 60 seconds it enumerates active Chisel tunnel ports via ss -tlnp, tests each new port for SMTP capability, and removes failed or dropped tunnels from the active pool.

The SMTP test connects through the SOCKS5 proxy to smtp.gmail.com:587, reads the 220 banner, sends an EHLO greeting, and attempts STARTTLS - a full protocol handshake, not just a port check. Verified proxies are enriched with exit IP, country, and ASN via api.ipify.org and ip-api.com, then synchronized via SCP to /root/excalibur/smtp_proxies.csv on 38.242.204[.]245 every five minutes.

The four JSON files left on the server fill in what actually ran.

Operational State Artifacts: Reconstructing the Victim Fleet

Fifty Deployed Proxies with Full Victim Metadata

The version 1 state file contains 50 entries, each storing the assigned port, hostname, CPU architecture, remote address as seen by the Sliver server, and deployment timestamp. All 50 share the timestamp 2026-03-10T09:05:20Z, consistent with a single batch completing simultaneously. The architecture breakdown is 46 amd64 and 4 arm64; no 386 targets appear.

The remote address field reveals many victims connected through Cloudflare edge IPs (172.70.x.x, 172.71.x.x, 162.158.x.x). The format tcp(CLOUDFLARE_EDGE:PORT)->VICTIM_IP indicates web servers behind Cloudflare's reverse proxy, consistent with web application exploitation for initial access. Representative entries include a GCP managed instance group node (ddx-instance-group-1-4xfx, 35.223.238.76), an AWS Graviton instance in ap-south-1 (ip-172-31-37-239, 65.0.48.45), and a named business server (ui.westwardtrade, US commercial IP).

Upload Phase Captured Mid-Run: Interrupted Before Execution

The version 2 state file shows 50 beacon IDs in uploaded and an empty executed list - the script was interrupted after uploads completed but before execution commands were issued. The port_map section contains entries for over 100 beacon IDs, including many not in the uploaded list. These were assigned ports during initialization before uploads began, giving a partial view into the broader beacon pool at the time this run started.

230-Node Fleet Confirmed: Single-Wave Deployment at Peak Scale

The version 3 state file contains a beacon_ports dictionary with 230 unique beacon IDs and summary fields confirming: "uploaded": 230 and "executed": 230. Unlike version 1, no per-beacon metadata is stored - only the port map and aggregate counts. The port distribution spans the full 10000-14999 range with no clustering, consistent with MD5-based deterministic assignment. 230 beacons use less than 5% of the 5,000 available port slots.

SMTP-Verified Proxy Inventory: Ground Truth and Evidence of Prior Operations

chisel_verified.json (748 bytes) is the live output of the verification daemon at time of capture. It contains five entries: three with smtp_ok: false and two with smtp_ok: true. Both verified proxies share the same exit IP - 48.217.21[.]105 (AS8075, Microsoft Corporation, Azure) - meaning two separate Chisel tunnels were active on the same victim host under different beacon IDs.

Four of the five ports fall outside the 10000-14999 range used by all recovered deployers:

Ports 9212 and 11212 were verified at 08:33-08:34 UTC, 31 minutes before the version 1 deployment was completed at 09:05:20. Those tunnels were already active when the first recovered deployer ran, indicating at least one earlier deployment using a different port range and a script not present in the recovered collection.

Operational Evolution

The three deployers show targeted changes between runs, with the state artifacts providing ground truth about what each run produced.

Assessment - version one: The SMTP pre-filter, batch size of 50, and 25-minute upload wait are consistent with an initial run where deployment reliability was not yet established. Pre-filtering for SMTP capability may reflect an early preference for a smaller, higher-quality proxy pool. These are structural inferences from the code; the actual rationale is unknown.

Assessment - version two: Removing the SMTP gate and splitting state into uploaded/executed lists is consistent with delegating SMTP filtering to chisel_verifier.py and improving run resumability. The interrupted state file - 50 uploads, zero executions - is direct evidence this run did not complete.

Assessment - version three: Removing batching and per-beacon tracking is consistent with prioritizing throughput once deployment mechanics were confirmed. 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.

Infrastructure Analysis

Starting from 213.136.80[.]73, we used JARM TLS fingerprints, SSL certificate pivots, and AttackCapture records to map related servers and uncover additional infrastructure tied to the same campaign.

213.136.80[.]73 is hosted by Contabo GmbH (AS51167) in Lauterbourg, France. Hunt.io flagged it with 1 High Risk (Active Malware: Sliver) and 3 AttackCapture warnings from 2026-03-11. The reverse DNS resolves to vmi3280867.contaboserver.net. Contabo encodes the VM instance ID in PTR records, making this a more durable attribution anchor than the IP alone.

The Pivots tab surfaced 19 available pivots. Among five JARM TLS fingerprints with counts ranging from 3 to 88k, one was worth pursuing: 3fd3fd00000000008c43d43d00043dabadbb43f9614a00c843a4ecd074ab81 appeared on only 3 other IPs.

Fingerprints in the tens of thousands are too broad to be useful. A count of 3 points to a specific TLS configuration shared by a small cluster of related hosts.

Querying the jarm table for that fingerprint within the last 30 days returned three IPs: 45.225.135[.]54, 95.216.111[.]46, and 20.114.38[.]127, all on port 443 and all within the same observation window as the primary C2.

SELECT
  ip, port, min(timestamp), max(timestamp)
  FROM
  jarm
  WHERE
  jarm == "3fd3fd00000000008c43d43d00043dabadbb43f9614a00c843a4ecd074ab81"
  AND
  timestamp > NOW - 30 DAY
  GROUP BY ip, port

                
Copy

Enriching those three IPs separated the signal quickly. 45.225.135[.]54 (RACK SPHERE HOSTING S.A., Netherlands, AS64107) carried 2 prior AttackCapture hits across two months, making it the highest priority. 95.216.111[.]46 (Hetzner Online GmbH, Finland, AS24940) came back with an Active Malware: Sliver flag and reverse DNS resolving to englizm.online. 20.114.38[.]127 (Microsoft Corporation, AS8075) showed no malware flags and was deprioritized pending additional signals.

45.225.135[.]54 had two AttackCapture records worth reviewing. The April 2026 record on port 8888 contained three files: bgd4_fix.tcl, test.tcl, and a 40 KB srv.log with an extension mismatch, file content inconsistent with the .log extension, consistent with a renamed binary payload.

The March 2026 record on port 8080 was more substantial: 79 files across 13 subdirectories totaling 4 MB. Key contents included a pwnkit/ directory with CVE-2021-4034 (834 KB across 7 files), a TLS certificate and private key pair for C2 authentication, and a Python HTTP C2 script. A complete staging directory confirming the operator pursues privilege escalation on compromised hosts.

95.216.111[.]46 (Hetzner Online GmbH, AS24940, Helsinki, Finland) carried 1 High Risk: Active Malware: Sliver, with reverse DNS resolving to englizm.online and Apache HTTPD 2.4.25 running on port 80. The Sliver tag directly links this host to the same C2 ecosystem as 213.136.80[.]73.

20.114.38[.]127 (Microsoft Corporation, AS8075, Moses Lake, Washington) showed no malware flags. A shared JARM fingerprint on Microsoft infrastructure can reflect the underlying TLS library version rather than operator configuration. Noted but deprioritized.

38.242.204[.]245, the Excalibur downstream consumer identified in the XSync toolkit, profiles as Contabo GmbH (AS51167) in Lauterbourg, France, with reverse DNS vmi3053870.contaboserver.net, the same vmiXXXXXXX naming convention as the primary C2. Open ports show nginx 1.24.0 on ports 80 and 443, consistent with a proxy aggregation server.

Querying the certificates table for issuer.common_name == "OpenClaw CA" within the last 30 days returned 6 results across 4 IPs: 38.242.204[.]245 on port 666, 81.71.15[.]27 on ports 8006, 443, and 8443, 203.237.119[.]147 on port 443, and 134.65.231[.]147 on port 443. OpenClaw CA is not associated with any known commercial PKI provider. Its presence across 4 IPs points to a shared certificate template across campaign infrastructure.

SELECT
  ip, port, min(timestamp), max(timestamp)
  FROM
  certificates
  WHERE
  issuer.common_name == "OpenClaw CA"
  AND
  timestamp > NOW - 30 DAY
  GROUP BY ip, port

                
Copy

Output example:

The 4 IPs from the OpenClaw CA pivot: 38.242.204[.]245 confirmed Contabo (AS51167, Lauterbourg, France) with reverse DNS vmi3053870.contaboserver.net and 1 IOC Hunter match; 81.71.15[.]27 is Tencent Cloud Computing in Guangzhou, China (AS45090); 203.237.119[.]147 is Korean Education Network in Gwangju, South Korea (AS9754); 134.65.231[.]147 is Oracle Corporation in Vinhedo, Brazil (AS31898). The Contabo IP is high confidence; the remaining three require individual profile review.

38.242.245[.]147, flagged by SentinelOne as hosting a LastPass phishing domain in the same Contabo subnet, carried 2 Warnings referencing both campaign IOC reports (both per SentinelOne). Its open ports show nginx 1.24.0 and OpenSSH 8.6p1 Ubuntu, an identical software stack to 38.242.204[.]245, confirming it belongs to the same cluster.

A broader sweep using the Sliver default JARM fingerprint returned 26 results across ports 4443, 3389, 8443, and 22. At that volume, not all results belong to this campaign.

SELECT
  ip, port, min(timestamp), max(timestamp)
  FROM
  jarm
  WHERE
  jarm == "00026d000000000000000000000000bc98f8e001b5ed0d7b91de1cdd769719"
  AND
  timestamp > NOW - 30 DAY
  GROUP BY ip, port

                
Copy

Results spanned 15+ countries and providers including Contabo, Vultr, RACK SPHERE HOSTING, Tencent Cloud, Korea Telecom, Oracle, and Microsoft. IPs carrying AttackCapture history or confirmed C2/Malware flags were prioritized for follow-up. Clean IPs on major cloud providers without additional signals were deprioritized.

213.136.80[.]73 appears across every deployer script in the recovered toolkit and is the same address SentinelOne attributed to PCPJack's C2 - which is where the campaign connection begins.

Connection to the PCPJack and TeamPCP Campaigns

TeamPCP is a threat actor known for cloud-focused attacks that spreads via web application exploits, harvests credentials encrypted with ChaCha20-Poly1305, and exfiltrates via Telegram. It uses /var/lib/.spm/ as a working directory and installs persistence as spm-worker. PCPJack, described by SentinelOne as a presumed former TeamPCP operator, runs check.sh to remove TeamPCP artifacts and install its own Sliver beacon in their place. PCPJack uses 213.136.80[.]73 as its C2 address

Assessment (moderate confidence): The shared use of 213.136.80[.]73 across PCPJack implants and every XSync deployment script is the primary basis for connecting these toolsets. The most parsimonious interpretation is that XSync deploys against the same Sliver beacon pool established by PCPJack. This connection should be weighted carefully - Contabo infrastructure is widely abused, and Sliver and Chisel are commodity tools with large legitimate user bases.

The available evidence does not establish shared authentication material, timeline continuity, or common developer artifacts between PCPJack and XSync. The shared C2 address is observed overlap, not proof of operational continuity.

The state files also give a partial picture of who ended up in the beacon pool.

Victimology

The 50 records in the version 1 state file show a consistent target profile: cloud-hosted Linux servers running web applications. AWS EC2 instances (ip-172-31-*), GCP managed instance groups, and Azure-hosted VMs all appear. Named servers such as server.serpsuggest.com, ui.westwardtrade, and hccloud-main-server indicate small and medium businesses operating web services on cloud infrastructure.

Docker container hex IDs appearing as hostnames (abe0f8823c36, 242df035a2b4) indicate some beacons run inside containers, which may explain why certain tunnels failed the SMTP test due to restricted outbound network access. Geographic coverage is broad - European, Asian, American, and Middle Eastern IPs all appear. This is an opportunistic operation, not a geographically targeted one.

The host and network artifacts recovered across both directories are listed below.

Indicators of Compromise

Network

Host

Process

MITRE ATT&CK

The following section summarizes what the full collection tells us about the operation.

Conclusion

The downstream consumer at 38.242.204[.]245 was not accessible during our analysis. 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.

The three deployer versions and their state files point to an operator who tested, iterated, and scaled deliberately - from 50 beacons to 230 in a single wave. The health-check tooling exists because earlier deployments didn't always work. There's operational investment here that goes beyond what the recovered files can fully explain.

If you're running Linux workloads on AWS, GCP, or Azure, the IOCs in this post are worth checking against your environment.

→ Hunt.io's AttackCapture surfaces exactly this kind of exposed infrastructure before it goes dark. Book a demo to see it in action.