## PCPJacks geheime Cloud-Operation aufgedeckt Der als **PCPJack** bekannte Bedrohungsakteur hat eine ausgeklügelte Kampagne orchestriert, bei der Cloud-Server von **Amazon Web Services (AWS)**, **Google Cloud** und **Microsoft Azure** gekapert wurden, um ein riesiges, geheimes SMTP-E-Mail-Relaisnetzwerk zu schmieden. Diese umfangreiche Infrastruktur verwandelte kompromittierte Unternehmensserver in den USA, Europa und Asien stillschweigend in SMTP-Proxys, die dann auf ihre Mail-Relay-Fähigkeiten überprüft und alle fünf Minuten mit einem nachgelagerten Verbraucher synchronisiert wurden. Die Threat-Intelligence-Firma **Hunt.io** deckte die Operation auf und stellte fest, dass die Infrastruktur zum Zeitpunkt der Entdeckung noch voll aktiv war. „Kompromittierte Unternehmensserver in den USA, Europa und Asien wurden stillschweigend in SMTP-Proxys umgewandelt, auf ihre Mail-Relay-Fähigkeiten überprüft und alle fünf Minuten mit einem nachgelagerten Verbraucher synchronisiert“, erklärte **Hunt.io**. „Die Infrastruktur lief noch, als wir sie fanden.“  ## Zufällige Entdeckung: Offener C2-Server legt Taktiken offen Die komplexen Details von **PCPJacks** Kampagne kamen aufgrund eines kritischen Fehlers in der operativen Sicherheit ans Licht. Der Bedrohungsakteur hinterließ zwei offene Verzeichnisse auf einem Command-and-Control (C2)-Server (213.136.80[.]73) ohne jegliche Authentifizierung. Dieses Versäumnis ermöglichte **Hunt.io** den Zugriff auf Quellcode, kompilierte Binärdateien, Bereitstellungsprotokolle, Internet-Scanner, Exploitation-Tools und eine Live-**Sliver**-Konfiguration. **PCPJack** tauchte erstmals im April 2026 auf und wurde von **SentinelOne** als ein auf diebstahl von Anmeldedaten spezialisiertes Framework identifiziert, das gezielt Cloud-Dienste anvisiert. Bemerkenswerterweise unternimmt **PCPJack** auch Schritte, um Artefakte zu entfernen, die mit **TeamPCP** in Verbindung stehen, einer weiteren prominenten Hacking-Gruppe, die für ihre Angriffe auf die Softwarelieferkette bekannt ist, was entweder auf Rivalität oder den Versuch hindeutet, seine Identität zu verschleiern. ## Werkzeuge des Handwerks: Sliver, Chisel und benutzerdefinierte Skripte Unter den in den offenen Verzeichnissen gefundenen Dateien befand sich ein **Sliver**-integriertes SMTP-Proxy-Bereitstellungstoolkit. Dieses Toolkit enthielt **Chisel**-Tunnel- und Proxy-Binärdateien, kompiliert für verschiedene Linux-CPU-Architekturen wie AMD64, ARM64 und x86. Auf den kompromittierten Rechnern wird die Binärdatei diskret als versteckte Datei mit Punktpräfix abgelegt und unter „/var/tmp/.xs“ persistent gemacht. Es wurden auch Bereitstellungsskripte gefunden, die dazu dienten, die **Sliver** C2-Client-Konfiguration zu laden und nach Linux-Beacons zu filtern. Diese Beacons sind Implantate, die sich periodisch mit dem C2-Server verbinden, um sich zu melden und Befehle abzurufen. ## Anspruchsvolles Proxy-Management Die Operation demonstriert fortschrittliche Proxy-Management-Fähigkeiten. „Jeder Beacon erhält einen SOCKS5-Proxy-Port, der deterministisch aus einem MD5-Hash seiner **Sliver**-UUID abgeleitet wird und in den Bereich 10000-14999 abgebildet wird“, erklärte **Hunt.io**. „Derselbe Beacon wird über verschiedene Ausführungen hinweg immer demselben Port zugeordnet, wodurch die Notwendigkeit einer gemeinsamen Portregistrierung entfällt.“  Eine entscheidende Komponente des Bereitstellungsskripts ist ein SMTP-„Qualitätstor“. Dieses Tor prüft auf ausgehenden Zugriff auf `smtp.gmail[.]com:587`. Hosts, die diese Prüfung nicht bestehen, werden übersprungen, da „Hosts, die keine E-Mails weiterleiten können, für diese Pipeline keinen Wert haben“, so das Cybersicherheitsunternehmen. Beacons werden in Stapeln von 50 verarbeitet, mit zeitgesteuerten Verzögerungen, um langsame Check-in-Intervalle zu berücksichtigen. ## Sich entwickelnde Taktiken und Diagnosefähigkeiten Spätere Iterationen der Bereitstellungsskripte zeigen eine Weiterentwicklung mit der Entfernung des SMTP-Tors und der Stapelverarbeitungslogik. Darüber hinaus war ein Diagnose-Skript vorhanden, das dazu diente, fünf aktive Beacons auszuwählen und ihnen Shell-Befehle zuzuweisen, um Folgendes zu überprüfen: * Vorhandensein von **Chisel**-Binärdateien an bekannten Ablageorten * Ein **Chisel**-Prozess läuft aktiv * Verfügbarer Speicherplatz * Erreichbarkeit von Port 9000 auf dem C2 * Vorhandensein von Persistenzartefakten wie Cron-Einträgen oder Systemd-Diensten  Der C2-Server führt außerdem ein Python-Skript, `chisel_verifier.py`, als persistenten Hintergrund-Daemon aus. Dieses Skript zählt alle 60 Sekunden aktive **Chisel**-Tunnelports über `ss -tlnp` auf, testet sie auf SMTP-Fähigkeit und entfernt alle fehlgeschlagenen oder abgebrochenen Tunnel aus dem aktiven Pool. ## Proxy-Anreicherung und unbekanntes Motiv Verifizierte Proxys werden mithilfe von Diensten wie `api.ipify[.]org` und `ip-api[.]com` weiter mit Exit-IP-Adresse, Land und Autonomous System Number (**ASN**)-Daten angereichert. Diese verfeinerten Proxy-Listen werden dann alle fünf Minuten über **Secure Copy Protocol (SCP)** auf einen separaten nachgelagerten Server (38.242.204[.]245) synchronisiert, obwohl dieser Server derzeit nicht zugänglich ist. Der letztendliche Zweck dieser umfangreichen Operation bleibt unklar. **Hunt.io** beschrieb sie als eine opportunistische Kampagne und erklärte: „Das Ergebnis von 230 Knoten ist das beobachtbare Ergebnis. Ob diese Entwicklung auf einen einzelnen Akteur zurückzuführen ist, der iteriert, oder auf mehrere Akteure, die dieselbe Infrastruktur teilen, kann anhand der wiederhergestellten Dateien nicht bestimmt werden.“ Unabhängig von der spezifischen Absicht sind die Auswirkungen erheblich. „Die verifizierte Proxy-Liste wird alle fünf Minuten an diesen Server synchronisiert, und jemand nutzt sie. Ob für Spam, Phishing oder etwas anderes, die Infrastruktur zur groß angelegten Zustellung war eindeutig in Betrieb.“