Die Gruppierung PCPJack hat nach Angaben der Forschenden von Hunt.io etwa 230 Cloud-Server auf den Plattformen Amazon Web Services, Google Cloud und Microsoft Azure kompromittiert und sie in ein verdecktes Netzwerk von SMTP-Proxys zur Weiterleitung von E-Mails verwandelt. Die kompromittierten Business-Server in den USA, Europa und Asien wurden dem Bericht zufolge unauffällig zu SMTP-Relays umfunktioniert, und die Listen verifizierter Proxys wurden alle fünf Minuten mit einem externen Server synchronisiert. Organisationen, die Linux-basierte Cloud-Infrastruktur einsetzen, sollten ihre Server auf die nachfolgend beschriebenen Indikatoren einer Kompromittierung überprüfen.
Wie die Infrastruktur entdeckt wurde
Die Operation wurde aufgedeckt, nachdem der Angreifer auf einem Command-and-Control-Server (213.136.80[.]73) zwei offene Verzeichnisse ohne jegliche Authentifizierung zurückgelassen hatte. Darin fanden die Forschenden Quellcode, kompilierte Binärdateien, Deployment-Logs, Scanner, Exploitation-Tooling sowie eine aktive Konfiguration des Frameworks Sliver. Nach Angaben von Hunt.io war die Infrastruktur zum Zeitpunkt der Entdeckung weiterhin in Betrieb.
Technische Architektur des Angriffs
Bereitstellungstoolkit
In den offenen Verzeichnissen befand sich ein Toolkit zur Bereitstellung von SMTP-Proxys, integriert in Sliver – ein Framework zur Steuerung kompromittierter Systeme. Darüber hinaus wurden Chisel-Binärdateien für Tunneling und Proxying gefunden, kompiliert für die gängigen Linux-Architekturen AMD64, ARM64 und x86. Auf der Opferseite wurde die Binärdatei als versteckte Datei mit führendem Punkt im Namen abgelegt und unter dem Pfad /var/tmp/.xs persistent gemacht.
Verwaltung der Beacons und Routing
Die Deployment-Skripte luden die Sliver-C2-Clientkonfiguration und filterten Beacons auf Linux-Systemen, die in den letzten zehn Minuten aktiv geworden waren. Jeder Beacon erhielt einen SOCKS5-Proxyport, der deterministisch aus dem MD5-Hash seiner Sliver-UUID berechnet und in den Bereich 10000–14999 abgebildet wurde. Dieser Ansatz stellte sicher, dass ein und derselbe Beacon stets denselben Port erhält, wodurch ein zentraler Port-Index überflüssig wurde.
Die Beacons wurden stapelweise in Gruppen von 50 verarbeitet, mit einer Pause von 25 Minuten nach dem Hochladen der Dateien und 15 Minuten nach dem Versenden der Ausführungsbefehle – so wurden Verzögerungen durch Beacons mit langem Rückmeldeintervall kompensiert.
Qualitätskontrolle der SMTP-Weiterleitung
Ein zentrales Element der Pipeline war ein SMTP-„Qualitätsschleusen“-Skript, das die Möglichkeit einer ausgehenden Verbindung zu smtp.gmail[.]com:587 prüfte. Hosts, die diesen Test nicht bestanden, wurden übersprungen. Wie die Forschenden feststellten, definierte dies letztlich das Ziel der Operation: Hosts, die keine E-Mails weiterleiten konnten, waren für diese Pipeline wertlos.
Bemerkenswert ist, dass in späteren Versionen der Skripte der SMTP-Gateway-Check und die Stapelverarbeitungslogik entfernt wurden, was auf eine Weiterentwicklung der Taktik oder eine Ausweitung der Zielsetzung der Operation hindeuten könnte.
Verifizierung und Anreicherung der Daten
Auf dem Command-and-Control-Server lief ein Python-Daemon chisel_verifier.py, der im Abstand von 60 Sekunden die aktiven Tunnel-Ports von Chisel mittels des Befehls ss -tlnp auflistete, jeden neuen Port auf SMTP-Kompatibilität testete und nicht funktionierende oder verlorene Tunnel aus dem Pool entfernte.
Verifizierte Proxys wurden mit Metadaten angereichert – Exit-IP-Adresse, Land und ASN – über die Dienste api.ipify[.]org und ip-api[.]com. Die fertigen Proxy-Listen wurden alle fünf Minuten per SCP-Protokoll auf einen separaten Server (38.242.204[.]245) synchronisiert, der zum Zeitpunkt der Veröffentlichung des Berichts nicht erreichbar war.
Ein Diagnoseskript wählte fünf aktive Beacons aus und prüfte auf jedem von ihnen:
- Vorhandensein der Chisel-Binärdateien an bekannten Pfaden
- Laufender Chisel-Prozess
- Freier Speicherplatz auf dem Datenträger
- Erreichbarkeit von Port 9000 auf dem C2-Server
- Vorhandensein von Persistenz-Artefakten – Cron-Einträge oder systemd-Services
Bedrohungskontext und Attribution
Hunt.io charakterisierte die Kampagne als opportunistisch. Das Ergebnis von 230 Knoten ist der beobachtbare Endstand der Operation; die Forschenden weisen jedoch darauf hin, dass sich anhand der rekonstruierten Dateien nicht feststellen lässt, ob ein einzelner Operator seine Werkzeuge iterativ verbessert oder mehrere Akteure eine gemeinsame Infrastruktur nutzen.
Das Endziel der Operation bleibt unklar. Wie die Forschenden jedoch betonten, wurde die verifizierte Proxy-Liste alle fünf Minuten mit einem externen Server synchronisiert, und jemand nutzte sie – sei es für Spam, Phishing oder andere Zwecke; die Infrastruktur für die massenhafte Zustellung von E-Mails war voll funktionsfähig.
Wichtig zu beachten: Die Zuordnung der Aktivität zur Gruppierung PCPJack basiert auf den Daten einer einzigen Forschungsquelle und ist nicht unabhängig bestätigt. Die Cloud-Provider haben zu diesem Vorfall keine offiziellen Mitteilungen veröffentlicht.
Einschätzung der Auswirkungen
Am stärksten gefährdet sind Organisationen, die Linux-Server in Cloud-Umgebungen von AWS, Google Cloud und Azure betreiben, insbesondere mit unzureichend abgesichertem ausgehendem SMTP-Traffic. Die kompromittierten Server wurden zur Weiterleitung von E-Mails im Namen legitimer Business-Domains genutzt, was potenziell die Absenderreputation untergräbt, zu Einträgen in Blacklists führt und rechtliche Risiken für die Inhaber der Infrastruktur schafft.
Praktische Empfehlungen
- Auf Artefakte prüfen: Suchen Sie auf allen Linux-Servern der Cloud-Infrastruktur nach der versteckten Datei unter dem Pfad
/var/tmp/.xs - Persistenzmechanismen prüfen: Analysieren Sie crontab-Einträge und systemd-Services auf unbekannte Aufgaben
- Audit ausgehender SMTP-Verbindungen: Blockieren oder beschränken Sie ausgehenden Traffic auf Port 587 für Server, die keinen E-Mail-Versand benötigen
- Überwachung der Netzwerkverbindungen: Prüfen Sie in den Logs der Netzwerkinfrastruktur auf Verbindungen zu den IP-Adressen
213.136.80[.]73und38.242.204[.]245 - Tunnel-Erkennung: Identifizieren Sie Chisel-Prozesse und ungewöhnliche SOCKS5-Proxys im Portbereich 10000–14999 mit dem Befehl
ss -tlnp - Angriffsfläche reduzieren: Stellen Sie sicher, dass Server keine offenen Verzeichnisse bereitstellen und dass der Zugriff auf Management-Interfaces durch Authentifizierung geschützt ist
Die von Hunt.io entdeckte Operation zeigt ein konkretes Modell zur Monetarisierung von Cloud-Kompromittierungen – die Umwandlung übernommener Server in eine E-Mail-Zustellinfrastruktur, die sich für Spam oder Phishing im industriellen Maßstab eignet. Vorrangige Maßnahme für Security-Teams ist die umgehende Überprüfung der Linux-Server in der Cloud auf das Vorhandensein der Datei /var/tmp/.xs, nicht autorisierter Chisel-Prozesse und anomalen ausgehenden SMTP-Traffic auf Port 587 sowie die Blockierung der genannten IP-Adressen auf Ebene der Netzwerkrichtlinien.
