# Sophisticated Cloud Credential Theft Discovered: PCPJack Hijacks 230 Cloud Servers for Covert SMTP Relay Network
A sophisticated credential theft operation has compromised 230 servers across Amazon Web Services (AWS), Google Cloud, and Microsoft Azure, converting them into covert SMTP email relay proxies in what researchers say is a carefully orchestrated infrastructure designed to support large-scale phishing and spam campaigns. The threat actor group known as PCPJack left critical operational infrastructure exposed through unsecured directories on their command-and-control server, allowing security researchers at Hunt.io to document the full scope and technical sophistication of the operation.
The hijacked servers were scattered across business networks in the United States, Europe, and Asia, with attackers implementing automated systems to verify each compromised host's capability to relay email before adding it to the operational pool. Every five minutes, a verified list of working proxies was synchronized to a downstream server, providing attackers with a constantly refreshed network of email relay nodes ready for deployment in phishing, spam, or malware distribution campaigns.
## The Threat: How 230 Cloud Servers Became an Email Relay Network
PCPJack's operation represents a significant escalation in how threat actors are weaponizing compromised cloud infrastructure. Rather than operating a single email relay service, the attackers created a distributed SMTP proxy network that leveraged hundreds of legitimate business servers to mask the true origin of outbound email traffic.
The technical approach was methodical:
/var/tmp/.xs)The sophistication of this automation suggests either a well-resourced threat actor or multiple operators working in concert using the same infrastructure.
## Background and Context: PCPJack and the Credential Theft Ecosystem
PCPJack first entered the threat landscape in April 2026, when SentinelOne identified a credential theft framework specifically designed to target cloud services. The discovery linked PCPJack to efforts to dismantle and absorb infrastructure from TeamPCP, another notorious hacking group that had garnered significant attention for supply chain attacks against software development pipelines.
This operational evolution—where one group dismantles competitors and absorbs their capabilities—reflects an increasingly professionalized cybercriminal ecosystem. Rather than operating in isolation, modern threat actors are consolidating infrastructure, sharing tools, and standardizing on proven exploitation techniques.
The 230-node network represents the observable outcome, though researchers cannot determine whether this reflects a single operator iterating on their toolkit or multiple independent actors sharing access to the same compromised infrastructure. This ambiguity is itself a security risk: organizations may face threats from multiple threat actors using the same relay network simultaneously.
## Technical Details: A Deep Dive into the Infrastructure
### The Deployment Toolkit
Researchers recovered deployment scripts, compiled binaries, and configuration files that reveal the technical precision of PCPJack's operation:
| Component | Purpose | Details |
|-----------|---------|---------|
| Sliver C2 Framework | Remote command execution | Integrated SMTP proxy deployment; configuration synced to beacons |
| Chisel Tunneling | Encrypted communication | Binaries compiled for AMD64, ARM64, and x86 architectures |
| SOCKS5 Proxy Ports | Traffic redirection | Ports 10000-14999 deterministically mapped from MD5 hash of beacon UUID |
| Diagnostic Scripts | Health monitoring | Tests for Chisel binaries, disk space, C2 reachability, persistence artifacts |
| Quality Gates | SMTP verification | Probes outbound access to smtp.gmail.com:587; skips non-functional hosts |
### The Command & Control Architecture
The C2 server (213.136.80.73) operated a Python daemon called chisel_verifier.py that continuously monitored tunnel health. Every 60 seconds, the script would:
1. Enumerate active Chisel tunnel ports using ss -tlnp
2. Test each port for SMTP relay capability
3. Remove failed or non-responsive tunnels from the operational pool
4. Enrich proxy data with geolocation and ASN information via public IP lookup services
This automation eliminated the need for manual proxy management and allowed the infrastructure to remain operational with minimal operator intervention—a critical design goal for maintaining a large distributed network.
### The Security Oversight That Exposed Everything
The breakthrough came when PCPJack left two directories on their C2 server completely open to the internet, lacking even basic authentication. Researchers discovered:
This operational security failure—leaving development and operational files in plaintext on an exposed server—mirrors similar breaches of other major threat groups, suggesting either complacency, organizational pressure to move quickly, or a deliberate decision to keep infrastructure accessible from multiple locations.
## Implications: Who Is at Risk and What Does This Mean?
### For Cloud Infrastructure Operators
Organizations using AWS, Google Cloud, and Azure face a direct risk: their own cloud infrastructure is being weaponized against their customers and peers. The 230 compromised servers represent 230 organizations that had security gaps allowing credential theft and persistent access.
The reliance on Gmail's SMTP servers as the quality gate suggests attackers expected to use the network for phishing campaigns, potentially against users with Google Workspace accounts or users who trust Gmail authentication.
### For Email Security Teams
Defenders must now account for a new vector of compromised relay infrastructure. Traditional email gateway filtering based on IP reputation becomes less effective when attackers are using legitimate cloud provider IPs stolen from customer environments. Authentication mechanisms like DMARC, DKIM, and SPF become more critical—and must be properly implemented—to prevent spoofing from these relay networks.
### For Incident Response Teams
Organizations running Linux servers in cloud environments should immediately audit:
/var/tmp/ (particularly dot-prefixed files like .xs)## Recommendations: Immediate Actions for Organizations
### For Cloud Environment Owners
1. Audit credential access logs for all IAM users, service accounts, and API keys in the last 30-60 days
2. Review cloud security group and network rules for unexpected outbound SMTP access
3. Scan all Linux systems for Chisel binaries and the .xs file artifact in /var/tmp/
4. Implement cloud workload protection platforms (CWPP) that detect suspicious processes and network connections in real-time
5. Enforce credential rotation for any accounts with access to public cloud environments
6. Require multi-factor authentication on all cloud console accounts and API access
### For Email Security Teams
1. Implement DMARC enforcement (reject mode, not quarantine) to prevent spoofing from unauthorized relays
2. Monitor for email traffic from cloud provider IP ranges destined for external recipients—legitimate traffic should be minimal
3. Alert on SMTP connections to port 587 originating from cloud instances outside of approved email infrastructure
4. Validate SMTP authentication logs for any connections not matching expected application or service accounts
### For Security Operations Centers
1. Add Sliver C2 indicators to network detection and response (NDR) systems
2. Monitor for Chisel tunnel traffic (typically on high-numbered ports in 10000-14999 range) on internal networks
3. Track the downstream server (38.242.204.245) for any outbound SCP connections—this indicates potential exfiltration of verified proxy lists
## HackWire Analysis
The PCPJack operation exposes a systemic vulnerability in how cloud infrastructure is secured: defenders often focus on protecting data within cloud environments, but neglect to monitor for compromised instances being repurposed as attack infrastructure against others. The fact that 230 servers remained operational for months without detection suggests most organizations lack basic process monitoring or network egress controls.
What makes this case particularly significant is the operational maturity. This isn't random exploitation—it's a deliberate, carefully instrumented pipeline designed to sustain a large-scale email relay network. The use of deterministic SOCKS5 port mapping, batch processing with scheduled delays, and automated health checks indicates threat actors have industrialized their infrastructure operations. They're not manually managing compromised hosts; they're running a distributed service platform.
The timeline is also telling: PCPJack began consolidating TeamPCP's infrastructure around April 2026, suggesting a territorial shift in the cybercriminal ecosystem. As groups consolidate, the services they provide—like email relay networks—become more standardized and potentially sold to multiple downstream customers. A single network could be supporting phishing campaigns from multiple unrelated threat actors simultaneously.
For defenders, the uncomfortable reality is that your cloud infrastructure may already be part of a relay network without your knowledge. The 230 discovered nodes are likely the tip of a larger iceberg. Organizations should assume their Linux systems in public cloud environments are targets for this type of compromise and act accordingly: implement runtime monitoring, enforce strict outbound network policies, and rotate credentials regularly.
— HackWire Editorial
## Related Coverage