PCPJack Cloud SMTP Relay Campaign: Detection, Hunting, and Hardening

Overview

Threat actor PCPJack has hijacked hundreds of cloud servers across AWS, Google Cloud, and Azure to build a covert SMTP relay network. Compromised business servers are being converted into proxies and synced to a downstream consumer every five minutes. Defenders must immediately audit outbound mail traffic and cron job schedules to identify active abuse.

Introduction

A concerning trend has emerged in 2026: the weaponization of legitimate cloud infrastructure for covert communication channels. According to recent intelligence by Hunt.io, the actor known as PCPJack has successfully hijacked approximately 230 cloud servers—spanning AWS, Google Cloud Platform (GCP), and Microsoft Azure—across the U.S., Europe, and Asia.

Unlike traditional ransomware operations that prioritize encryption or data theft, PCPJack’s objective is infrastructural repurposing. The attackers are quietly converting compromised business servers into SMTP proxies. Once converted, these servers are verified for mail relay capability and synchronized with a downstream command-and-control (C2) or consumer node on a rigorous five-minute interval. This activity allows actors to bypass IP-based reputation lists and launch massive phishing campaigns with high deliverability rates, shifting the blame—and the potential blacklisting—to victim organizations.

Technical Analysis

Affected Platforms

Amazon Web Services (AWS)
Google Cloud Platform (GCP)
Microsoft Azure

Attack Chain & TTPs

While the initial access vector (e.g., exposed credentials, vulnerable web applications) varies, the post-exploitation behavior is distinct and consistent:

Persistence & Proxy Installation: Attackers gain initial access and deploy SMTP proxy software. This often involves modifying mail server configurations (Postfix, Sendmail) or installing custom binaries that listen on standard mail ports (25, 587, 465) or arbitrary high ports.
Verification Loop: The compromised server performs a verification handshake to confirm it can relay mail externally.
The "Five-Minute" Sync: A critical behavioral indicator is the synchronization cadence. The article notes servers are "synced to a downstream consumer every five minutes." In a Linux environment, this strongly suggests the deployment of a cron job or a systemd timer set to */5 * * * *.
Traffic Patterns: The compromised servers initiate high-volume outbound TCP connections on port 25 (SMTP) and 587 (Submission) to a diverse set of destination mail servers, acting as an open relay.

Exploitation Status

This is an Active Campaign (Active Exploitation). There is no CVE associated with this specific repurposing activity; it is an abuse of access and configuration. The "vulnerability" is the lack of egress filtering and monitoring within the cloud environment.

Detection & Response

SIGMA Rules

These rules target the specific behavior of high-frequency cron jobs (the 5-minute sync) and the suspicious execution of mail transfer agents (MTAs) by non-standard users or processes.

YAML

---
title: PCPJack - Linux Cron Job with 5-Minute Interval
id: 8d2f4a1c-9e6b-4c3d-a1b2-3e4f5a6b7c8d
status: experimental
description: Detects the creation or modification of cron jobs scheduled to run every 5 minutes, consistent with PCPJack sync behavior.
references:
 - https://thehackernews.com/2026/06/pcpjack-hijacks-230-aws-google-cloud.html
author: Security Arsenal
date: 2026/06/15
tags:
 - attack.persistence
 - attack.t1053.003
logsource:
  product: linux
  service: cron
detection:
  selection:
    command|contains:
      - '*/5'
      - '*/5 *'
  condition: selection
falsepositives:
  - Legitimate monitoring agents or log rotation scripts
level: high
---
title: PCPJack - Suspicious SMTP Process Execution
id: 9e3f5b2d-0f7c-4d4e-b2c3-4f5a6b7c8d9e
status: experimental
description: Detects execution of mail server binaries (sendmail, postfix, exim) initiated by unusual parent processes or users.
references:
 - https://thehackernews.com/2026/06/pcpjack-hijacks-230-aws-google-cloud.html
author: Security Arsenal
date: 2026/06/15
tags:
 - attack.execution
 - attack.t1059.004
logsource:
  product: linux
  category: process_creation
detection:
  selection_img:
    Image|endswith:
      - '/sendmail'
      - '/postfix'
      - '/sendmail.postfix'
      - '/exim4'
  selection_user:
    User|startswith:
      - 'www-data'
      - 'nginx'
      - 'apache'
  condition: all of selection_*
falsepositives:
  - Legitimate web application form mailers (rare, usually requires specific allowlisting)
level: high

KQL (Microsoft Sentinel)

This query hunts for outbound SMTP traffic originating from Linux servers via Syslog or CEF data, and processes creating connections on mail ports.

KQL — Microsoft Sentinel / Defender

// Hunt for outbound SMTP traffic (Port 25, 587, 465)
let SMTPPorts = dynamic([25, 587, 465]);
DeviceNetworkEvents
| where DeviceType in ("Linux", "Workstation", "Server") // Broad scope for cloud environments
| where Direction == "Outbound"
| where RemotePort in (SMTPPorts)
| where InitiatingProcessVersionInfoCompanyName != "" or InitiatingProcessFileName !in ("java", "python", "node", "sshd")
| summarize count() by DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort
| order by count_ desc

// Alternative: Hunt for cron modifications in Syslog (if auditd is enabled)
Syslog
| where ProcessName contains "crontab"
| where SyslogMessage contains "*/5" or SyslogMessage contains "REPLACE"
| project TimeGenerated, ComputerName, ProcessName, SyslogMessage

Velociraptor VQL

This artifact hunts for processes listening on SMTP ports and inspects cron files for the 5-minute interval pattern.

VQL — Velociraptor

-- Hunt for processes listening on standard SMTP ports
SELECT Pid, Name, CommandLine, Exe, Username
FROM listen_sockets()
WHERE Port IN (25, 587, 465)
   AND Family == 2  -- IPv4

-- Hunt for Cron entries with 5-minute intervals
SELECT FullPath, Mtime, Data
FROM glob(globs="/var/spool/cron/*", root="/")
WHERE Data =~ "\*/5"
   OR Data =~ "\*\/5"

Remediation Script (Bash)

Run this script on potentially compromised Linux cloud instances to audit for SMTP proxy indicators.

Bash / Shell

#!/bin/bash

# PCPJack SMTP Relay Audit Script
# Usage: sudo ./audit_smtp_relay.sh

echo "[+] Starting SMTP Relay Audit..."

# 1. Check for processes listening on SMTP ports (25, 587, 465)
echo "[1/4] Checking for listeners on SMTP ports (25, 587, 465)..."
netstat -tulnp | grep -E ':(25|587|465)\s' | grep LISTEN

# 2. Check for suspicious cron jobs (5-minute intervals)
echo "[2/4] Checking user crontabs for '*/5' patterns..."
for user in $(cut -f1 -d: /etc/passwd); do
  crontab -u $user -l 2>/dev/null | grep -q "\*/5"
  if [ $? -eq 0 ]; then
    echo "User $user has a 5-minute cron job:"
    crontab -u $user -l 2>/dev/null | grep "\*/5"
  fi
done

echo "[3/4] Checking system cron directories for '*/5' patterns..."
grep -r "\*/5" /etc/cron* 2>/dev/null

# 3. Check for mail queue size (indication of bulk sending)
echo "[4/4] Checking Postfix mail queue (if installed)..."
if command -v mailq &> /dev/null; then
  mailq | tail -n 1
fi

echo "[+] Audit complete."

Remediation

To defend against PCPJack and similar covert relay campaigns, apply the following hardening measures immediately:

Egress Filtering (Critical): Implement strict Security Groups (AWS), Network Security Groups (Azure), or VPC Firewalls (GCP) to block outbound traffic on TCP ports 25, 587, and 465 from all instances except your designated mail gateway servers. This is the single most effective control to stop a compromised server from functioning as a relay.
Audit SMTP Configurations: Review mail server configurations (/etc/postfix/main.cf, /etc/exim4/exim4.conf.template) on all instances. Ensure mynetworks is set to loopback only (127.0.0.0/8) and that the server is not configured as an open relay (smtpd_relay_restrictions in Postfix).
Cron Job Hygiene: Audit all scheduled tasks. Remove any cron jobs running at high-frequency (e.g., */5) that cannot be attributed to legitimate system administration or monitoring tools.
Identity & Access Management: Rotate API keys and access credentials for any cloud accounts that may have been exposed during the initial compromise window. Enforce MFA for all console access.
Isolation & Rebuild: If a server is confirmed to be compromised, do not attempt to clean it. Isolate the instance, snapshot the disk for forensics, and terminate the instance. Rebuild the workload from a known good, hardened image.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub