C
Security

PCPJack: Wie 230 Cloud-Server zum heimlichen E-Mail-Relay wurden

Ein Threat Actor namens PCPJack kaperte hunderte Server von AWS, Azure und Google Cloud für ein verdecktes SMTP-Netzwerk. Ein fataler OPSEC-Fehler entlarvte die hochautomatisierte Infrastruktur.

CR
Codekiste Redaktion5. Juni 2026

Cloud-Infrastrukturen von Amazon Web Services (AWS), Google Cloud und Microsoft Azure gelten als das Rückgrat der modernen IT. Doch genau ihre Reputation – und die oft großzügigen E-Mail-Versandkontingente – machen sie zu attraktiven Zielen für Cyberkriminelle. Ein aktueller Vorfall zeigt eindrucksvoll, wie Angreifer hunderte Unternehmensserver weltweit unbemerkt in ein hochspezialisiertes Proxy-Netzwerk umwandelten. Die Bedrohungsakteure hinter der Operation – bekannt unter dem Namen PCPJack – hinterließen dabei eine hochentwickelte Automatisierung, machten jedoch einen fatalen Fehler.

Ein offenes Verzeichnis als Einfallstor für Forscher

Das Cybersecurity-Unternehmen Hunt.io stieß auf die Operation, nachdem die Akteure hinter PCPJack zwei Verzeichnisse auf ihrem Command-and-Control (C2) Server völlig ungesichert und ohne jegliche Authentifizierung im Internet offen gelassen hatten. Ein klassischer OPSEC-Fehler (Operational Security), der Forschern einen detaillierten Blick in die Werkzeugkiste der Angreifer ermöglichte. Auf dem Server unter der IP 213.136.80[.]73 fanden sich Quellcode, kompilierte Binaries, Deployment-Logs, Internet-Scanner, Exploit-Tooling und eine aktive Sliver-Konfiguration.

Sliver, ein beliebtes Open-Source-C2-Framework, diente als Rückgrat der Operation. Die Angreifer integrierten ein SMTP-Proxy-Deployment-Toolkit in Sliver und nutzten Chisel – ein Tunneling- und Proxy-Tool – für diverse Linux-Architekturen wie AMD64, ARM64 und x86. Auf der Seite der Opfer wurde die Malware als versteckte Datei (Dot-Prefixed) unter /var/tmp/.xs abgelegt und persistiert.

Die Architektur des SMTP-Proxys

Besonders interessant ist die technische Raffinesse, mit der PCPJack das Netzwerk aufbaute. Die Deployer-Skripte luden die Sliver-C2-Konfiguration und filterten nach Linux-Beacons, die sich innerhalb der letzten zehn Minuten gemeldet hatten. Diese Beacons – also Implants, die regelmäßig mit dem C2-Server kommunizieren – erhielten jeweils einen SOCKS5-Proxy-Port.

Dieser Port wurde deterministisch aus einem MD5-Hash der Sliver-UUID in den Port-Bereich 10000-14999 gemappt. Ein cleverer Schachzug: Da derselbe Beacon immer denselben Port erhält, entfällt die Notwendigkeit einer zentralen Port-Registry. Das System ist dezentral und widerstandsfähig gegen Ausfälle.

Qualitätskontrolle für kriminelle Zwecke

Das Alleinstellungsmerkmal dieser Kampagne ist ihre strikte Ausrichtung auf einen einzigen Zweck: den E-Mail-Versand. Das Deployment-Skript enthält ein sogenanntes „SMTP Quality Gate“. Dieses testet proaktiv, ob der kompromittierte Server ausgehenden Zugriff auf smtp.gmail[.]com:587 hat. Schlägt dieser Test fehl, wird das System übersprungen.

„Dieses Gate definiert den Zweck der Operation: Hosts, die keine E-Mails weiterleiten können, haben für diese Pipeline keinen Wert“, erklärte Hunt.io. Die Beacons wurden in Batches von 50 verarbeitet, mit strategischen Wartezeiten von 25 und 15 Minuten, um langsame Beacon-Check-Ins zu berücksichtigen und nicht aufzufallen.

Spätere Versionen der Skripte zeigten, dass die Angreifer das Quality Gate und die Batching-Logik entfernten – möglicherweise ein Zeichen dafür, dass sich die Operation weiterentwickelte oder auf andere Ziele ausgedehnt wurde. Ein Diagnose-Skript prüfte zudem die Lebensfähigkeit der Infrastruktur, indem es das Vorhandensein von Chisel-Binaries, laufende Prozesse, Speicherplatz und Persistenz-Artefakte wie Cron-Jobs oder systemd-Services validierte.

Auf C2-Seite lief ein Python-Daemon namens chisel_verifier.py, der alle 60 Sekunden aktive Chisel-Tunnel-Ports enumerierte, diese auf SMTP-Fähigkeiten testte und unbrauchbare Verbindungen aus dem Pool entfernte. Verifizierte Proxys wurden mit Exit-IP, Land und ASN via externer APIs angereichert.

Konkurrenzkampf im Untergrund

Ein weiteres faszinierendes Detail betrifft die Beziehung zu anderen Akteuren. PCPJack wurde erstmals im April 2026 von SentinelOne identifiziert, als ein Credential-Theft-Framework entdeckt wurde, das gezielt Cloud-Services angriff. Bemerkenswert ist, dass PCPJack aktiv Spuren einer anderen Hackergruppe, TeamPCP, entfernte und deren Prozesse terminierte. TeamPCP ist für Software-Supply-Chain-Angriffe bekannt. Es scheint, als würden die Akteure die kompromittierten Server nicht nur für sich nutzen, sondern sie auch „säubern“, um Konkurrenten aus dem Weg zu räumen.

Fazit: Opportunismus auf hohem Niveau

Die verifizierten Proxy-Listen wurden alle fünf Minuten via Secure Copy Protocol (SCP) an einen Downstream-Server unter 38.242.204[.]245 synchronisiert. Dieser Server ist derzeit nicht erreichbar. Was der Endzweck der Operation ist – Spam, Phishing oder etwas anderes –, bleibt spekulativ.

230 kompromittierte Server mögen für einen traditionellen Botnet-Betreiber klein klingen, für ein hochqualitatives SMTP-Relay-Netzwerk ist es jedoch eine beträchtliche Ausbeute. Cloud-IPs haben eine hohe Reputation bei E-Mail-Anbietern, was die Zustellraten für Spam oder Phishing drastisch erhöht. Die Infrastruktur war klar darauf ausgelegt, „at Scale“ zu liefern.

Ob es sich um einen einzelnen Operator handelt, der seine Taktiken iteriert, oder um mehrere Akteure, die dieselbe Infrastruktur teilen, lässt sich nicht mit Sicherheit sagen. Fest steht jedoch: Die Operation war opportunistisch, technisch ausgereift und – bis zum offenen Verzeichnis – äußerst unauffällig. Der Vorfall ist eine erneute Mahnung an Cloud-Administratoren: Die eigenen Server sind nicht nur Rechenleistung, sondern auch eine Währung im kriminellen Untergrund.

Quelle: The Hacker News

QUELLEN
The Hacker News
Pro-Feature

Melde dich an und werde Pro-Mitglied, um dieses Feature zu nutzen.

Anmelden
CR
Codekiste Redaktion

Automatisierte Content-Kuratierung für tech-news.

Kommentare

WEITERLESEN
Security

DeepSeek als günstige KI-Alternative: Warum US-Firmen Daten riskieren

Security

Kritische Root-Lücke in Cisco Unified CM: PoC veröffentlicht

Security

Ein Issue reicht zur Repo-Übernahme: Schwachstelle in Claude Code GitHub Action