PCPJack wurde laut SentinelOne erstmals im April 2026 identifiziert. Damals stieß das Unternehmen auf ein Framework zum Diebstahl von Zugangsdaten, das gezielt auf Cloud-Dienste ausgerichtet war. SentinelOne zufolge versuchte PCPJack zudem, Prozesse und Artefakte von TeamPCP zu beenden und zu entfernen. Diese andere Hackergruppe war in den vergangenen Monaten durch Angriffe auf die Software-Lieferkette aufgefallen.
In einem der offen erreichbaren Verzeichnisse entdeckte Hunt.io ein mit Sliver integriertes Toolkit zur Bereitstellung von SMTP-Proxys. Dazu kamen Chisel-Binärdateien für Tunneling und Proxy-Funktionen für gängige Linux-Architekturen wie AMD64, ARM64 und x86. Auf kompromittierten Systemen werde die Binärdatei als versteckte Datei mit Punkt-Präfix abgelegt und unter “/var/tmp/.xs” dauerhaft verankert.
Außerdem fanden die Forscher Deployerskripte, die die Sliver-Client-Konfiguration laden und Linux-Beacons filtern, die sich innerhalb der vergangenen zehn Minuten beim C2 gemeldet haben. Solche Beacons sind Implantate, die sich in festen Intervallen beim Steuerungsserver zurückmelden und Befehle abrufen. Gegenüber The Hacker News erklärte Hunt.io, diese Skripte bildeten die Automatisierungsschicht, die kompromittierte Linux-Server in SOCKS5-Proxys verwandle: Sie verbänden sich mit dem lokalen Sliver-C2, zögen eine Liste aktiver Linux-Beacons, kopierten eine Chisel-Datei auf jedes System und installierten sie als dauerhaften Dienst.
Für jeden Beacon werde der SOCKS5-Port laut Hunt.io deterministisch aus einem MD5-Hash der Sliver-UUID abgeleitet und in den Bereich 10000 bis 14999 abgebildet. Dadurch lande derselbe Beacon bei wiederholten Läufen immer auf demselben Port, ohne dass eine gemeinsame Port-Registrierung nötig sei.
Eine weitere Funktion der Skripte ist ein SMTP-Qualitätsfilter. Dabei wird geprüft, ob ausgehende Verbindungen zu smtp.gmail[.]com:587 möglich sind. Systeme, die diesen Test nicht bestehen, werden mit Rückgabecode null übersprungen. Für Hunt.io zeigt genau dieser Schritt den Zweck der Operation: Systeme, die keine E-Mails weiterleiten können, seien für diese Pipeline wertlos. Die Beacons würden in Gruppen von 50 verarbeitet, mit 25 Minuten Wartezeit nach dem Hochladen und weiteren 15 Minuten nach Ausführungsbefehlen, um langsame Beacon-Intervalle zu berücksichtigen.
Spätere Versionen der Deployerskripte verzichteten nach Angaben von Hunt.io sowohl auf den SMTP-Filter als auch auf die Stapelverarbeitung. Zusätzlich lag in den Verzeichnissen ein Diagnoseskript, das fünf aktive Beacons auswählt und auf jedem einen Shell-Befehl ausführt.
Auf dem C2-Server lief zudem dauerhaft ein Python-Skript namens “chisel_verifier.py” im Hintergrund. Es ermittelt alle 60 Sekunden über ss -tlnp aktive Chisel-Tunnel-Ports, testet neue Ports auf SMTP-Fähigkeit und entfernt fehlgeschlagene oder abgebrochene Tunnel aus dem aktiven Pool. Verifizierte Proxys werden anschließend mit Exit-IP-Adresse, Land und ASN angereichert, unter anderem über api.ipify[.]org und ip-api[.]com.
Die Proxy-Listen werden danach alle fünf Minuten per Secure Copy Protocol auf einen separaten nachgelagerten Server unter 38.242.204[.]245 übertragen. Dieser Server ist inzwischen nicht mehr erreichbar. Was das eigentliche Ziel der Operation war, ist laut Hunt.io derzeit offen. Das Unternehmen betont jedoch, dass die Liste verifizierter Proxys im Fünf-Minuten-Takt synchronisiert wurde und jemand sie nutzte. Ob für Spam, Phishing oder etwas anderes, lasse sich auf Basis der vorliegenden Erkenntnisse nicht abschließend sagen.