PCPJack ist ein neues Framework zum Diebstahl von Zugangsdaten, das auf offen erreichbare Cloud-Services (Docker, Kubernetes, Redis, MongoDB, RayML, verwundbare Web‑Anwendungen) abzielt, das nicht nur massenhaft Zugänge zu Cloud-, Container-, Entwickler-, Office- und Finanzdiensten stiehlt, sondern auch gezielt Artefakte entfernt, die mit der Gruppierung TeamPCP verbunden sind, und damit faktisch Konkurrenten aus kompromittierten Umgebungen „herausschmeißt“. Betreiber von Cloud-Infrastrukturen müssen bereits jetzt exponierte Services inventarisieren, den Zugriff auf Metadaten von Instanzen strikt einschränken und Systeme auf Spuren automatischer Installationsskripte sowie des Tools Sliver prüfen.

Technische Details zu PCPJack

In der veröffentlichten Analyse wird ein vollständiger, modularer Werkzeugsatz beschrieben, der mehrstufig arbeitet und auf Cloud-Infrastrukturen ausgerichtet ist.

Erstzugriff und Vorbereitung der Umgebung

Der Angriff wird über ein Bootstrap‑Shell‑Skript gestartet, das:

• die Laufzeitumgebung vorbereitet und den Host für weitere Downloads konfiguriert;
• die nächste Stufe der Werkzeuge herunterlädt (einschließlich sechs Python‑Skripten);
• versucht, auch die eigene Infrastruktur des Angreifers zu infizieren (was auf wurmartige Eigenschaften hinweist);
• Prozesse erkennt und stoppt sowie Artefakte entfernt, die mit TeamPCP in Verbindung stehen;
• Python installiert und einen Persistenzmechanismus einrichtet;
• ein orchestrierendes Python‑Skript startet und sich anschließend selbst löscht, um Spuren zu minimieren.

Die Ziele für die Ausbreitung sind offen erreichbare und/oder falsch konfigurierte:

• Cloud-Services und Instanzen;
• Docker– und Kubernetes-Umgebungen;
• Datenspeicherdienste wie Redis, MongoDB;
• die Plattform RayML und verwundbare Web‑Anwendungen.

Orchestrierung und Nutzung von Common Crawl

Ein zentrales Merkmal: Der Orchestrator des Wurms bezieht seine Zielliste nicht aus einem eigenen Scanner, sondern aus Parquet‑Dateien, die direkt aus dem öffentlichen Datensatz von Common Crawl heruntergeladen werden. Dies ermöglicht es:

• die Kampagne mit Hilfe bereits vorliegender großer Listen von Domains und URLs zu skalieren;
• einen Teil der „Crawler‑Arbeit“ im Internet auf ein legitimes Projekt auszulagern;
• die Logik der Zielauswahl als gewöhnliche Arbeit mit offenen Daten zu tarnen.

Ein solches Vorgehen passt gut zur Technik T1595 (Active Scanning), stützt sich dabei jedoch auf externe Quellen für Aufklärungsdaten.

Diebstahl von Zugangsdaten und Erfolgsmetriken

Das Framework sammelt systematisch:

• Systeminformationen vom Opfer;
• Zugangsdaten zu Cloud-, Container-, Entwickler-, Office- und Finanzdiensten;
• einzelne „erfolgreiche“ Ereignisse, einschließlich eines speziellen Felds „PCP replaced“, das an den Command-and-Control‑Server (C2) übermittelt wird und widerspiegelt, ob TeamPCP auf einem bestimmten Host verdrängt werden konnte.

Das Verhaltensmuster lässt sich den Techniken MITRE ATT&CK T1552 (Unsecured Credentials) und T1555 (Credentials from Password Stores) zuordnen: ein systematisches Durchsuchen von Quellen für Geheimnisse in Cloud- und Container-Umgebungen.

Zusätzliches Skript check.sh und Sliver

In der Infrastruktur des Operators wurde ein zusätzliches Shell‑Skript check.sh entdeckt, das:

• die CPU-Architektur ermittelt und die passende Binärdatei von Sliver lädt – einem bekannten, plattformübergreifenden Framework für Command-and-Control‑Infrastrukturen, dessen Quellcode im Repository Sliver auf GitHub verfügbar ist;
• den Instance Metadata Service (IMDS) in Cloud-Umgebungen scannt;
• Kubernetes Service Accounts abfragt;
• Docker-Umgebungen analysiert, um Konfigurationen und Tokens zu finden.

Ziel ist die Extraktion von Zugangsdaten und Tokens, die mit folgenden Diensten verbunden sind:

• Anthropic, OpenAI, Google API;
• Digital Ocean, Grafana Cloud, HashiCorp Vault;
• Discord, OnePassword und anderen Diensten.

Alle gefundenen Secrets werden an einen externen Server zur Steuerung und zum Speichern der gestohlenen Daten übertragen.

INDICATORS OF COMPROMISE (IOC) werden im ursprünglichen Bericht nicht aufgeführt, sodass sich die Erkennung derzeit auf Verhaltensmerkmale und Artefakte stützt (Skripte bootstrap/check.sh, Netzwerkinteraktion von Sliver, Zugriffe auf Common Crawl).

Bedrohungskontext und Bezug zu TeamPCP

Die Forschenden weisen auf eine erhebliche Überschneidung der Ziele von PCPJack mit der früheren Gruppierung TeamPCP hin, die aktiv Schwachstellen (einschließlich React2Shell) und Fehlkonfigurationen in Cloud-Diensten ausnutzte, um ein verteiltes Netz von Hosts für anschließenden Datendiebstahl und weitere Aktivitäten nach der Kompromittierung aufzubauen.

Zentrale Unterschiede zwischen PCPJack und TeamPCP:

• kein Cryptomining – im Unterschied zur früheren Kampagne entfernt das neue Framework ausdrücklich Mining-Funktionen, die zuvor von TeamPCP eingesetzt wurden;
• Fokus auf den Diebstahl und die Monetarisierung von Zugangsdaten durch Betrug, Spam, Erpressung oder Weiterverkauf von Zugängen statt auf direktes Mining;
• antikompetitives Verhalten: das explizite Entfernen von Prozessen und Artefakten von TeamPCP und das Sammeln der Telemetrie „PCP replaced“, was zeigt, dass das Ziel nicht nur Masseninfektionen, sondern die Ablösung konkurrierender Infrastrukturen ist.

Die Forschenden nehmen an, dass die Ähnlichkeit der Codebasis und der Taktiken auf eine mögliche Verbindung zu einem früheren Mitglied von TeamPCP hindeuten könnte, betonen jedoch, dass es sich hierbei um eine Einschätzung handelt: Eine bestätigte technische Attribution liegt nicht vor.

Auswirkungsanalyse und Risikoprofil

Am verwundbarsten erscheinen Organisationen, die:

• öffentlich zugängliche Docker/Kubernetes/Redis/MongoDB-Dienste ohne strenge Authentifizierungsrichtlinien und Netzsegmentierung betreiben;
• den Instance Metadata Service standardmäßig ohne Einschränkungen und Proxy-Schichten nutzen;
• kritische Tokens (API‑Schlüssel für Anthropic, OpenAI, Google API, Grafana Cloud, Digital Ocean, HashiCorp Vault u. a.) in Umgebungsvariablen, Container-Konfigurationsdateien oder Kubernetes Service Accounts speichern;
• langfristige oder zeitlich unbegrenzte Zugriffstokens ohne Rotation verwenden.

Mögliche Folgen eines erfolgreichen Angriffs:

• Kompromittierung der Lieferkette und der Entwicklungsprozesse – Zugriff auf Repositories, CI/CD, Secrets in Vault und Passwortmanagern;
• Kompromittierung von Kundendaten durch Zugriffe auf Datenbanken, Monitoring-Panels und Speichersysteme;
• sekundärer Missbrauch von Zugangsdaten: Versand von Spam, Angriffe auf Dritte, Erpressung, Betrug mit Finanzdiensten;
• Reputations- und Compliance-Risiken, wenn über gestohlene Schlüssel externe Kunden oder Partner angegriffen werden.

Besondere Aufmerksamkeit verdient die Tiefe des Zugriffs, den der Diebstahl von Tokens für Anbieter wie Anthropic oder OpenAI ermöglicht: unkontrollierte Nutzung von Ressourcen, Diebstahl interner Prompts und Konfigurationen sowie möglicher Missbrauch von Daten, die an die Modelle gesendet werden.

Praktische Schutzempfehlungen

1. Reduzierung der Angriffsfläche in Cloud- und Container-Umgebungen

• Inventarisierung aller öffentlich erreichbaren Services durchführen (Docker API, Kubernetes API, Redis, MongoDB, RayML, Administrationsoberflächen von Web‑Anwendungen).
• Anonymen und „Default“-Zugriff deaktivieren, unnötige Ports auf Ebene von Cloud-Firewalls und Security Groups schließen.
• Den Zugriff auf Kubernetes API und den Docker-Socket strikt auf authentifizierte Kanäle beschränken.

2. Schutz von Instance Metadata Service und Service Accounts

• Den Zugriff auf IMDS einschränken (z. B. nur von vertrauenswürdigen Services/Sidecar‑Proxys), den Einsatz von Metadaten zur Beschaffung langlebiger Tokens minimieren.
• Die Rechte der Kubernetes Service Accounts überprüfen, übermäßige Privilegien entfernen und den Grundsatz minimaler Rechte anwenden.
• Netzwerk-Policies im Cluster konfigurieren, um zu verhindern, dass Container beliebig auf IMDS und Kubernetes API zugreifen können.

3. Umgang mit Secrets und Tokens

• API‑Schlüssel (Anthropic, OpenAI, Google API, Digital Ocean, Grafana Cloud, HashiCorp Vault, OnePassword u. a.) aus Umgebungsvariablen und statischen Konfigurationen in spezialisierte Secret-Stores auslagern.
• Tokenrotation aktivieren, insbesondere für hochprivilegierte und zeitlich unbegrenzte Schlüssel.
• Monitoring für anomale Schlüsselverwendung bei den Providern einführen (Sprünge im Anfragevolumen, neue Geografien, untypische Nutzungsszenarien).

4. Erkennung von PCPJack und verwandten Aktivitäten

• In Logs und Dateisystemen nach Spuren der Ausführung unbekannter Shell‑Skripte suchen, insbesondere mit dem Verhalten „Download von Python, Einrichtung von Persistenz, Selbstlöschung“.
• Auf Netzwerkebene überwachen:
  • ungewöhnliche Zugriffe auf Common Crawl (Download von Parquet‑Dateien mit großen Domainlisten);
  • Verbindungen und Traffic, die für Sliver typisch sind (C2‑Muster, Mutual TLS, ungewöhnliche Steuerungs-Domains).
• Bekannte Sliver-Detektoren und MITRE‑orientierte Regeln (z. B. für die Techniken T1105 (Ingress Tool Transfer) und T1552/T1555) in SIEM- und IDS/IPS‑Systemen einsetzen.

5. Reaktion und Priorisierung

• Hohe Priorität (Frist – Tage, nicht Wochen): Schließen offen zugänglicher Docker/Kubernetes/Redis/MongoDB/IMDS‑Dienste, Überprüfung von Tokens und Schlüsseln für die genannten Services, Prüfung auf das Vorhandensein von Sliver und verdächtigen Shell‑Skripten.
• Bei festgestellter Kompromittierung:
  • alle potenziell kompromittierten Schlüssel und Tokens umgehend widerrufen und rotieren;
  • stark betroffene Instanzen aus vertrauenswürdigen Images mit neuer Secret-Basis neu aufsetzen;
  • eine rückblickende Log-Analyse durchführen, um mit den gestohlenen Zugangsdaten durchgeführte Aktivitäten aufzudecken.

Zentrale Schlussfolgerung: PCPJack verdeutlicht eine Verlagerung des Fokus vom groben Cryptomining hin zu einer profitableren und weniger auffälligen Monetarisierung über den Diebstahl von Cloud- und API‑Zugangsdaten. Daher sollten Sicherheitsteams in naher Zukunft prioritär offen zugängliche Docker-/Kubernetes-/IMDS‑Endpunkte schließen, eine sofortige Überprüfung und Rotation von Tokens für Cloud- und AI‑Services vornehmen und verhaltensbasiertes Monitoring einführen, um anomale Zugriffe auf Metadaten sowie die Ausführung von Sliver zu erkennen.