A threat actor known as PCPJack has been observed hijacking cloud servers across Amazon Web Services, Google Cloud, and Microsoft Azure to create a covert SMTP relay network.
According to Hunt.io, compromised business servers across the United States, Europe, and Asia were quietly converted into SMTP proxies. These hosts were verified for outbound mail relay capability and then synced to a downstream consumer every five minutes.
The operation appeared to have been active when researchers discovered it, showing that the infrastructure was not theoretical or dormant. It was running, organized, and designed to support email delivery at scale.
What Was Discovered?
Hunt.io discovered the operation after finding two open directories on a command-and-control server located at:
213.136.80[.]73
The directories were exposed without authentication and contained a significant amount of operational material.
Researchers found:
- source code
- compiled binaries
- deployment logs
- internet scanners
- exploitation tooling
- Sliver C2 configuration
- SMTP proxy deployment tools
- Chisel tunneling binaries
- scripts for automating deployment across compromised Linux systems
This exposed data gave researchers a rare look into how the attackers were turning compromised cloud servers into a relay infrastructure.
Who Is PCPJack?
PCPJack was first documented by SentinelOne in April 2026.
At that time, the group was associated with a credential theft framework targeting cloud services. The framework also appeared to terminate and remove processes or artifacts linked to TeamPCP, another hacking group known for software supply chain attacks.
The relationship between PCPJack and TeamPCP remains unclear, but the overlap is notable. It suggests competition, cleanup, or conflict inside the broader cybercriminal ecosystem.
The latest activity shows PCPJack moving beyond credential theft and into infrastructure abuse, using compromised servers to build a cloud-based relay network.
Turning Cloud Servers Into SMTP Proxies
The recovered files show that PCPJack used compromised Linux servers as proxy nodes.
The attackers relied on Sliver, a command-and-control framework, to manage infected hosts. They also used Chisel, a tunneling tool, to create SOCKS5 proxy functionality across compromised systems.
On victim machines, the Chisel binary was dropped as a hidden dot-prefixed file and persisted at:
/var/tmp/.xs
This naming and location are designed to keep the file less visible during casual inspection.
The deployer scripts connected to the local Sliver C2, listed active Linux beacons that had checked in recently, pushed Chisel binaries to them, and installed Chisel as a persistent service.
In short, the scripts automated the conversion of compromised Linux servers into proxy infrastructure.
How the Automation Worked
The deployer scripts filtered for Linux beacons that had checked in within the last ten minutes.
Each active beacon represented a compromised host that could receive commands.
The scripts then:
- Identified active Linux beacons.
- Uploaded a Chisel binary to each host.
- Installed Chisel as a persistent service.
- Assigned each host a SOCKS5 proxy port.
- Tested whether the host could reach SMTP services.
- Added working hosts to the usable proxy pool.
The SOCKS5 proxy port was generated deterministically from an MD5 hash of the Sliver UUID and mapped into the port range 10000–14999.
This meant the same compromised host always mapped to the same port across runs, removing the need for a shared central port registry.
That is a small but important operational detail. It shows that the toolkit was built for repeatability and scale.
The SMTP Quality Gate
One of the most revealing parts of the operation was the SMTP quality gate.
The script tested whether each compromised host could connect outbound to:
smtp.gmail[.]com:587
Hosts that failed the test were skipped.
This shows the operation’s core purpose: only systems capable of relaying email had value to the pipeline.
A compromised server might be useful for many things, but for this operation, the key question was whether it could send mail through outbound SMTP paths.
The tooling processed beacons in batches of 50, with wait periods built in to account for slower beacon check-ins.
Later versions of the deployer scripts reportedly removed the SMTP gate and batching logic, suggesting the tooling was evolving as the operation matured.
Continuous Verification of Proxy Nodes
The C2 server also ran a Python daemon named:
chisel_verifier.py
This script repeatedly enumerated active Chisel tunnel ports using:
ss -tlnp
Every 60 seconds, it tested new ports for SMTP capability. Failed or dropped tunnels were removed from the active pool.
Verified proxies were enriched with:
- exit IP address
- country
- ASN
The enrichment relied on public services such as:
api.ipify[.]orgip-api[.]com
The verified proxy lists were then synced every five minutes using SCP to a downstream server at:
38.242.204[.]245
That server was not accessible when researchers reported the activity, but the repeated sync strongly suggests that another system or actor was consuming the proxy list.
What Was the Network Used For?
The final purpose of the operation remains unclear.
However, a covert SMTP relay network could support several types of malicious activity, including:
- spam campaigns
- phishing delivery
- business email compromise infrastructure
- malware delivery emails
- credential harvesting campaigns
- account registration abuse
- email reputation laundering
- large-scale social engineering
Using compromised business cloud servers helps attackers avoid the reputation problems that come with obvious spam infrastructure.
Cloud servers may have cleaner IP reputations, reliable uptime, and global distribution. That makes them attractive for email abuse.
Why Cloud Servers Are Valuable to Attackers
Cloud environments are attractive targets because they provide scalable compute, global reach, and trusted network positioning.
A compromised cloud server may be useful for:
- proxying traffic
- hosting malware
- scanning the internet
- staging payloads
- running command-and-control infrastructure
- relaying email
- tunneling into internal systems
- hiding attacker activity behind legitimate providers
When attackers compromise business cloud workloads, defenders may overlook outbound traffic because it appears to come from a legitimate organization.
This is especially dangerous when the traffic uses common tools and expected ports.
Why SMTP Relay Abuse Matters
SMTP relay abuse is not new, but PCPJack’s approach shows a modern cloud-native version of the problem.
Instead of relying on a small set of attacker-owned mail servers, the group built a distributed pool of compromised servers and continuously verified which ones could relay mail.
This makes takedown and blocking harder.
If one node is removed, others may remain active. If one cloud provider blocks traffic, the operator may continue using nodes in another provider. If IP reputation drops, new compromised servers can replace failed ones.
The five-minute sync cycle suggests the downstream consumer needed a fresh, working list of relay-capable proxies at all times.
Defensive Lessons for Cloud Teams
Cloud defenders should treat unexpected SMTP capability as a high-risk signal.
Many cloud workloads do not need outbound SMTP at all. Where possible, organizations should restrict outbound connections to mail services unless the workload has a clear business requirement.
Recommended controls include:
- block outbound SMTP by default
- allow SMTP only from approved mail systems
- monitor outbound connections to port 587
- alert on unusual connections to
smtp.gmail.com - detect Chisel, FRP, and other tunneling tools
- monitor hidden binaries in
/var/tmp - alert on unknown dot-prefixed executable files
- monitor systemd service creation
- monitor suspicious cron persistence
- inspect unexpected SOCKS5 proxy listeners
- track new listening ports in the 10000–14999 range
- monitor for Sliver beacon activity
- investigate unknown long-running processes on Linux servers
Cloud workloads should be treated as potential infrastructure abuse targets, not only as application hosts.
What to Hunt For
Security teams should look for signs of PCPJack-style behavior across Linux cloud servers.
Useful indicators include:
- hidden binaries such as
/var/tmp/.xs - Chisel binaries or processes
- unexpected SOCKS5 proxy services
- outbound SMTP testing activity
- repeated connections to
smtp.gmail[.]com:587 - new systemd services linked to unknown binaries
- suspicious cron entries
- Sliver beacon behavior
- unusual outbound SCP transfers
- connections to known C2 or downstream infrastructure
- unexpected use of
ss -tlnpfrom scripts - IP reputation changes tied to cloud workloads
Detection should focus on behavior as well as hashes. Tools like Chisel and Sliver can be renamed or rebuilt.
Why Open Directories Matter
The operation was exposed because the attacker left directories open on a C2 server.
This kind of operational mistake can give defenders valuable insight into attacker tooling, infrastructure, and workflow.
Open directories often reveal:
- payloads
- scripts
- logs
- victim lists
- configuration files
- infrastructure maps
- operator habits
- development history
In this case, the exposed files showed not only what the malware did, but how the operator automated the conversion of compromised hosts into relay-capable infrastructure.
That kind of visibility is rare and valuable for defenders.
Recommendations for Organizations
Organizations running cloud infrastructure should review whether any servers have been abused as proxies or SMTP relays.
Recommended actions include:
- inventory all internet-facing Linux servers
- review outbound firewall rules
- block unnecessary SMTP egress
- monitor cloud flow logs for unusual mail traffic
- review systemd services and cron jobs
- scan for tunneling tools
- check for hidden executables in temporary directories
- rotate credentials on suspicious hosts
- rebuild compromised servers from known-good images
- inspect cloud IAM activity for credential theft
- enforce least privilege on cloud service accounts
- deploy runtime monitoring for Linux workloads
- centralize logs from cloud instances
If a server has been used as a proxy, assume deeper compromise until proven otherwise.
Final Thoughts
The PCPJack operation shows how attackers are turning compromised cloud servers into disposable infrastructure for email relay and proxy abuse.
By combining Sliver, Chisel, automated deployment scripts, SMTP verification, and five-minute sync cycles, the attackers built a practical relay network from hijacked business servers across multiple cloud providers.
The end goal is not fully confirmed, but the infrastructure could support spam, phishing, fraud, malware delivery, or other email-based abuse at scale.
Cloud servers need strong outbound monitoring, not only inbound protection. If a workload does not need to send email, it should not be able to relay SMTP traffic. In cloud security, preventing abuse means watching what your servers do after compromise — not only how attackers get in.
