PCPJack transforms public cloud into a SMTP relay network for mass spam

The operation attributed to the actor known as PCPJack reveals a worrying trend: the systematic abuse of public cloud infrastructure - Amazon Web Services, Google Cloud and Microsoft Azure - to turn legitimate machines into a hidden network of SMTP relays. Security researchers who analyzed open directories on a command and control server discovered deployment tools, tunnel binaries and an offensive frameworks integration that allow you to convert compromised servers into scale-usable mail proxies.

The modus operandi includes the fall of a persistent binary in the victims, SMTP automatic scanning and verification techniques (e.g. testing smtp.gmail [.] com: 587), and a frequent synchronization mechanism of verified proxy lists to downstream servers. Among the tools identified are Sliver, a post-exploitation framework with public repository https: / / github.com / BishopFox / slide, and Chisel, a utility of tunnels that facilitates the creation of reverse channels between hosts https: / / github.com / jpillora / sisel. In addition to revealing technical artifacts, the finding confirms how attackers can orchestrate a mass mail delivery platform or evasion, without depending on their own visible infrastructure.

The implications are multiple. First, the conversion of cloud servers into SMTP relays makes it possible to avoid black lists and reputational controls, allowing spam campaigns, phishing or the distribution of malicious loads with a higher chance of delivery. Secondly, the abuse of cloud suppliers poses a risk to third parties: legitimate customers may suffer reputational damage if their resources are used for illicit activities. Finally, the evidence points to an opportunistic campaign that exploits weak credentials and configurations, which underlines the importance of governance in identities and egress control in cloud environments.

From the detection perspective, the observed artifacts offer actuable tracks: tunnel processes and binaries (Chisel) listening in ports derived from implantation identifiers, persistent services installed on temporary routes such as / var / tmp with hidden names, and scripts that list sockets with ss-tlnp to verify proxies. Security teams should prioritize the search for these indicators in their inventory of instances and network records, as well as tracking unusual SCP synchronizations to external addresses.

To reduce the attack surface, cloud organizations must apply strict access controls: force multifactor authentication, rotate and audit key and service credentials, implement the principle of less privilege in roles and identities, and limit egress through security groups, VPC firewalls or exit policies that restrict SMTP traffic only to authorized suppliers. Official guides to good cloud practice provide useful frameworks for these measures https: / / docs.aws.amazon.com / whitepapers / latest / aws-security-best-practices /.

In active incidents, the response should combine containment and forensic: isolate committed instances without immediately eliminating them to preserve evidence, capture images and memory spins, collect artifacts in temporary directories and cron / systemd entries, and analyse access records and CloudTrail / AzureActivity / Cloud Audit Logs for commitment chains. Notify the cloud supplier and abuse equipment and, if necessary, CERT and security forces will allow for the coordination of remedies and possible takedown of malicious infrastructure.

E-mail protection equipment also has a key role to play. Implementing and strengthening SPF, DKIM and DMARC helps mitigate the impact of campaigns using external relays; at the same time, mail gateways and antiphishing filters must be configured to detect unusual volume increases and atypical shipping patterns. For internal services requiring mail, it is appropriate to centralize SMTP traffic through managed suppliers and block exit ports 25 / 587 / 465 with justified exceptions.

This operation recalls that cloud security is not just the responsibility of the supplier: the interaction between weak configurations, credentials management and inadequate monitoring creates opportunities for actors such as PCPJack to implement abuse infrastructures. Early detection depends on both monitoring of integrity in endpoints and analysis of network behavior and output traffic.

Finally, the community must maintain a collaborative approach: sharing indicators with intelligence exchange networks, reporting committed servers to cloud supplier abuse channels and keeping the detection rules up to date in EDR / IDS tools. A proactive and coordinated approach reduces the abuse window and makes it difficult for opportunistic campaigns to scale without being detected.