Thought Leadership
Der Akteur PCPJack hat 230 Cloud-Server von AWS, Google und Azure gekapert, um ein geheimes Netzwerk für die SMTP-E-Mail-Weiterleitung aufzubauen.
Das IT-Sicherheitsunternehmen Hunt.io hat eine großflächige Kaperung von Cloud-Infrastrukturen dokumentiert. Der als PCPJack bekannte Angreifer hat insgesamt 230 virtuelle Server bei den großen Cloud-Anbietern Amazon Web Services, Google Cloud und Microsoft Azure kompromittiert. Ziel der Operation war der Aufbau eines verdeckten Netzwerks zur Weiterleitung von E-Mails über das SMTP-Protokoll. Die Entdeckung gelang den Analysten, weil die Hintermänner zwei ungeschützte Verzeichnisse auf ihrem zentralen Befehls- und Kontrollserver mit der IP-Adresse 213.136.80.73 hinterlassen hatten. In diesen Verzeichnissen befanden sich Quellcodes, ausführbare Binärdateien, Protokolle zum Bereitstellungsstatus, Internet-Scanner, Werkzeuge zur Ausnutzung von Schwachstellen sowie eine aktive Konfiguration des legitimen Sicherheitswerkzeugs Sliver, das hier zweckentfremdet wurde.
PCPJack wurde erstmals im April 2026 von SentinelOne identifiziert. Damals fiel die Gruppe durch ein Framework zum Diebstahl von Zugangsdaten in Cloud-Diensten auf, bei dem gezielt Prozesse einer konkurrierenden Hackergruppe namens TeamPCP gelöscht wurden. Zu der aktuellen Entdeckung erklärte Hunt.io in einer Mitteilung: „Kompromittierte Geschäftsserver in den USA, Europa und Asien wurden stillschweigend in SMTP-Proxies umgewandelt, auf ihre Fähigkeit zur E-Mail-Weiterleitung überprüft und alle fünf Minuten mit einem nachgelagerten Verbraucher synchronisiert. Die Infrastruktur lief noch, als wir sie fanden.“
Automatisierte Bereitstellung und Prüfung der Cloud-Serverfunktionen
In den offenen Verzeichnissen des Angreifers befand sich ein automatisiertes Toolkit zur Bereitstellung von SMTP-Proxies. Dieses enthielt unter anderem Tunnel- und Proxy-Binärdateien der Software Chisel für gängige Linux-Prozessorarchitekturen wie AMD64, ARM64 und x86. Auf den betroffenen Opfersystemen wird die Binärdatei als versteckte Datei unter dem Pfad /var/tmp/.xs abgelegt und dauerhaft im System verankert. Die Bereitstellungsskripte filtern automatisch nach Linux-Beacons, die sich innerhalb der letzten zehn Minuten am Kontrollserver gemeldet haben. Jedem dieser infizierten Systeme wird deterministisch ein SOCKS5-Proxy-Port zugewiesen, der auf einem MD5-Hash der eindeutigen Sliver-Identifikationsnummer basiert und im Portbereich zwischen 10000 und 14999 liegt. Dadurch entfällt die Notwendigkeit einer zentralen Port-Registrierung.
Die Skripte enthielten zudem eine Prüfroutine, die testet, ob die gekaperten Server eine ausgehende Verbindung zum Google-Mailserver über den Port 587 herstellen können. Systeme, bei denen dieser Test fehlschlug, wurden aussortiert. Das Cybersicherheitsunternehmen kommentierte diesen Schritt: „Dieses Gateway definiert den Zweck der Operation: Hosts, die keine E-Mails weiterleiten können, haben für diese Pipeline keinen Wert.“ In neueren Versionen des Skripts wurde diese Überprüfung jedoch entfernt.
Kontinuierliche Validierung und Datenexport an Folgeserver
Auf dem Kontrollserver der Angreifer läuft im Hintergrund ein Python-Skript namens chisel_verifier.py als dauerhafter Systemdienst. Dieses Programm überprüft alle 60 Sekunden die aktiven Chisel-Tunnelports über den Systembefehl ss. Es testet jeden neuen Port auf seine SMTP-Fähigkeit und entfernt fehlerhafte oder abgebrochene Tunnel aus dem aktiven Pool. Erfolgreich verifizierte Proxies werden automatisiert mit zusätzlichen Standortdaten angereichert. Hierzu rufen die Skripte externe Dienste wie api.ipify.org und ip-api.com auf, um die ausgehende IP-Adresse, das Herkunftsland und die autonome Systemnummer zu erfassen.
Die bereinigten Listen der funktionierenden Proxies werden anschließend alle fünf Minuten über das verschlüsselte Secure Copy Protocol auf einen separaten Folgeserver mit der IP-Adresse 38.242.204.245 übertragen. Dieser Server ist derzeit nicht mehr erreichbar. Das endgültige Ziel der Kampagne, etwa der Massenversand von Spam-Mails oder Phishing-Kampagnen, ist zum aktuellen Zeitpunkt unklar.
„Das Ergebnis mit 230 Knoten ist das beobachtbare Resultat. Ob diese Entwicklung auf einen einzelnen Betreiber zurückzuführen ist, der Iterationen durchführt, oder auf mehrere Akteure, die dieselbe Infrastruktur nutzen, lässt sich aus den wiederhergestellten Dateien nicht bestimmen.“ Das Unternehmen betonte zudem: „Die verifizierte Proxy-Liste wird alle fünf Minuten mit diesem Server synchronisiert, und jemand konsumiert sie. Ob für Spam, Phishing oder etwas anderes, die Infrastruktur für die Bereitstellung in großem Maßstab lief eindeutig.“
Hunt.io
