Cyberbedrohungen
Supply-Chain-Angriffe von TeamPCP in CI/CD-Umgebungen
Eine umfassende Supply-Chain-Kampagne von TeamPCP ist auf den Diebstahl von Anmeldedaten ausgelegt. Unsere Analyse zeigt, wie der Angreifer vertrauenswürdige CI/CD- und Release-Workflows dafür missbrauchte.
Save to Folio
Wichtige Erkenntnisse
- Diese Kampagne ist auf den Diebstahl von Anmeldedaten in großem Umfang ausgelegt. Die Payloads zielen auf GitHub-PATs, npm-Token, Cloud-Anmeldedaten, SSH-Schlüssel, Kubernetes-Geheimnisse, Datenbank-Anmeldedaten, Geheimnisse von Entwicklertools, Infrastructure-as-Code (IaC)-Dateien und Keystores von Kryptowährungs-Wallets ab.
- Organisationen, die GitHub Actions, PyPI, Docker Hub, GHCR, VS Code-Erweiterungen und Cloud verbundene CI-Runner nutzen, sind diesem Risiko ausgesetzt.
- Die Durchsetzung des Prinzips der geringsten Berechtigungen hilft, den Schaden zu begrenzen, wenn ein vertrauenswürdiger Workflow, ein Artefakt oder ein Release-Prozess missbraucht wird.
TeamPCP führte im März und April eine koordinierte Kampagne in mindestens sieben Wellen durch. Die Gruppe findet vertrauenswürdige Artefakte in Entwickler-Toolketten, vergiftet den Vertriebskanal unter Nutzung der projektinternen Infrastruktur und sammelt Anmeldedaten, bevor die Projektbetreuer oder die Sicherheitsüberwachung die Manipulation bemerken. Die Ziele erstrecken sich über fünf Programmier-Ökosysteme und drei Registry-Typen.
Wir haben die Vorfälle bei Checkmarx Keeping Infrastructure as Code Secure (KICS) am 22. April und bei elementary-data am 24. April als zwei Fallstudien im Rahmen dieser Supply-Chain-Kampagne analysiert. Bei KICS kam es zu einem Multichannel-Poisoning über Docker Hub, VS Code/OpenVSX und GitHub Actions hinweg, gefolgt von einer nachgelagerten Übernahme von @bitwarden/cli unter Verwendung gestohlener npm-Token. Bei elementary-data wurde eine Skript-Injektion in GitHub Actions genutzt, um die projektinterne Release-Pipeline auszulösen, wodurch ein bösartiges Paket erzeugt wurde, das von einer legitimen CI signiert und im Python Package Index (PyPI) sowie in der GitHub Container Registry (GHCR) veröffentlicht wurde.
Was die beiden jüngsten Operationen auszeichnet, ist die Art und Weise, wie der Akteur trotz unterschiedlicher Methoden zum gleichen Ergebnis gelangte. Der KICS-Angriff war operativ komplex, mit gleichzeitiger Manipulation über drei Vertriebskanäle hinweg, einer verschleierten Payload, die über eine heruntergeladene Laufzeitumgebung ausgeführt wurde, und einer nachgelagerten npm-Übernahme, die innerhalb von 24 Stunden unter Verwendung gestohlener Anmeldedaten durchgeführt wurde.
Der Angriff auf elementary-data war technisch einfacher, aber vielleicht besorgniserregender. Ein einziger Kommentar zu einem GitHub-Pull-Request reichte aus, um ein Runner-Token zu erhalten, einen getaggten Release-Commit zu fälschen und die projektinterne Signaturinfrastruktur aufzurufen. Das resultierende Paket bestand jede standardmäßige PyPI-Prüfung, da es vom Projekt selbst erstellt wurde.
TeamPCP ist eine finanziell motivierte Gruppe von Angreifern, die TrendAI™ Research im Rahmen einer Reihe von Vorfällen in der Lieferkette als SHADOW-WATER-058 verfolgt hat. Die Einzelheiten zur Zuordnungssicherheit beinhaltet der Originalbeitrag.
Analyse der Kampagne
Über alle bestätigten TeamPCP-Wellen hinweg waren gemeinsame Vorgehensweisen in den verschiedenen Ökosystemen erkennbar, wobei drei Muster unabhängig von der Sprache, der Registry oder dem Vertriebskanal, auf den der Akteur abzielte, konstant blieben:
CI/CD-Vertrauen als Angriffsfläche: Jeder Eintrittsvektor nutzt etwas aus, dem eine Build-Pipeline implizit vertraut. Dazu gehören ein Docker-Image, eine VS-Code-Erweiterung von einem bekannten Anbieter oder ein GitHub-Actions-Workflow sowie ein PyPI-Paket, das von der projektinternen CI signiert und veröffentlicht wurde. Der Angreifer musste in keiner der bestätigten Wellen die Endbenutzersysteme direkt kompromittieren. Die Pipeline erledigt die Arbeit.
Diebstahl von Anmeldedaten als einziges Ziel: Die Komplexität der Payload variiert je nach Welle, aber das Ergebnis ist immer dasselbe komprimierte Archiv mit Entwickler-Anmeldedaten, Schlüsseln von Cloud-Anbietern, SSH-Material und CI/CD-Tokens. Dieses wird an einen vom Angreifer kontrollierten Endpunkt exfiltriert, bevor die Pipeline abgeschlossen ist. Der Akteur behandelt gestohlene Anmeldedaten als fungible Assets mit sofortigem Wiederverwendungswert.
In die Payloads eingebettetes Branding des Akteurs: Der Header „X-Rise-To-The-Trinny: agree“, der Archivname „trin.tar.gz“, „X-Filename: tpcp.tar.gz“, die wiederverwendete Sitzungskennung im XOR-Schlüssel und die Staging-Repositorys mit Dune-Thema sind keine operativen Anforderungen, sondern konsistente Signaturen des Akteurs, die absichtlich gewählt wirken. Dieses Muster hat sich über Kampagnen hinweg über einen Zeitraum von sechs Wochen hinweg gezeigt, was ungewöhnlich ist, da die meisten finanziell motivierten Akteure identifizierbare Marker minimieren. Die Beharrlichkeit deutet entweder auf ein hohes Maß an operativem Selbstvertrauen oder auf eine Vorliebe für Bekanntheit neben der Monetarisierung hin.
Im Originalbeitrag finden Sie die Beschreibung beider Ereignisse als Fallstudien innerhalb einer einzigen Kampagne, die gemeinsamen Vorgehensweisen, Unterschiede bei den Payloads und bietet eine teilweise MITRE ATT&CK-Zuordnung sowie einen einheitlichen Satz von Indikatoren und Abhilfemaßnahmen. Zudem finden Sie dort
Sicherheitsempfehlungen
Die folgenden Abhilfemaßnahmen gelten für beide Vorfälle. Unternehmen sollten Sicherheitsmaßnahmen danach priorisieren, bei welchen Artefakten sie eine Gefährdung bestätigt haben:
Für den Checkmarx-KICS-Vorfall (Docker Hub, VS Code, GitHub Actions, 22. April):
- Behandeln Sie jede Umgebung, die zwischen ca. 12:35 und 15:41 UTC am 22. April Docker-Tags von checkmarx/kics (alpine, debian, latest, v2.1.20, v2.1.20-debian, v2.1.21 oder v2.1.21-debian) abgerufen hat, als vollständig kompromittiert. Das Gleiche gilt für jede Umgebung, in der die VS Code-Erweiterungen cx-dev-assist v1.17.0 oder v1.19.0, ast-results v2.63.0 oder v2.66.0 installiert wurden, checkmarx/ast-github-action vor Version 2.3.36 verwendet wurde oder @bitwarden/cli v2026.4.0 installiert wurde.
- Wechseln Sie die Anmeldedaten von einem sauberen Host aus, nicht aus der potenziell kompromittierten CI-Umgebung heraus.
- Aktualisieren Sie auf sichere Versionen von Docker checkmarx/kics:v2.1.20 (wiederhergestellt: vor der Verwendung anhand des bekannten sauberen Digests überprüfen), VS Code cx-dev-assist v1.18.0, ast-results v2.64.0, GitHub Action checkmarx/ast-github-action@v2.3.36, npm @bitwarden/cli v2026.3.0 oder früher.
- Überprüfen Sie die GitHub Actions-Protokolle auf Ausführungen des Workflows „format-check.yml“. Suchen Sie nach automatisch erstellten öffentlichen Repositorys, die dem Dune-bezogenen Namensmuster <Wort>-<Wort>-<3 Ziffern> entsprechen und die Beschreibung „Shai-Hulud: The Third Coming“ enthalten. Diese könnten verschlüsselte Anmelde-Blobs enthalten, die der Angreifer noch nicht abgerufen hat.
- Suchen Sie nach Bun-Laufzeitartefakten. Das Vorhandensein einer bun- oder bun.exe-Binärdatei in unerwarteten Arbeitsverzeichnissen deutet darauf hin, dass die Ausführung der Payload stattgefunden hat, selbst wenn die Exfiltration unterbrochen wurde.
- Blockieren Sie die dokumentierte C&C-Infrastruktur am Netzwerkperimeter.
Für den elementary-data-Vorfall (PyPI, GHCR, 24. April)
- Behandeln Sie jeden Host, auf dem elementary-data==0.23.3 installiert war oder auf dem während des Expositionszeitraums ein von ghcr[.]io/elementary-data/elementary:0[.]23[.]3 oder :latest heruntergeladener Container lief, als vollständig kompromittiert.
- Wechseln Sie die folgenden Elemente in der Reihenfolge ihrer Priorität aus: AWS-Zugriffsschlüssel und Sitzungstoken, GCP-Dienstkontoschlüssel, Azure-Anmeldedaten, Kubernetes-Dienstkontotoken, aktualisieren Sie anschließend authorized_keys auf verbundenen Hosts, GitHub-PATs, HashiCorp-Vault-Token, npm-Token sowie alle .env- und .env.production-Geheimnisse. Private Schlüssel von Kryptowährungs-Wallets sollten als potenziell offengelegt behandelt werden, wenn sie auf dem Host vorhanden sind, da Gelder möglicherweise bereits gefährdet sind.
- Prüfen Sie auf Payload-Artefakte, einschließlich einer Persistenz-Marker-Datei in $TMPDIR (siehe Abschnitt „IoC“) und aller elementary.pth-Dateien in Python-Site-Paketen, die größer als 100 KB sind.
- Installieren Sie elementary-data==0.23.4 (vom Maintainer als sicher bestätigt). Für Docker sollten Sie auf den im Abschnitt „IoC“ aufgeführten Digest der Baseline vor der Kompromittierung fixieren.
- Überprüfen Sie die Netzwerkprotokolle auf ausgehende Verbindungen zu den dokumentierten Exfil- und Stager-Domains.
Strukturelle Korrekturen für beide Vorfälle
- Überprüfen Sie alle GitHub-Actions-Workflows in den Repositorys der Organisation auf benutzergesteuerte Ausdrücke, die direkt in run: blocks interpoliert sind (${{ github.event.comment.body }}, ${{ github.event.issue.title }} und ähnliche Muster). Dies ist die strukturelle Schwachstelle, die den Angriff auf elementary-data ermöglichte, und das Muster ist in Open-Source-Projekten weit verbreitet.
- Binden Sie alle Docker-Image-Abrufe an einen verifizierten Digest statt an einen Tag. Wenden Sie Netzwerk-Ausgangskontrollen auf die CI-Agent-Umgebungen an. Keine der beiden Payloads hätte Daten von einem Runner exfiltrieren können, wenn ausgehendes HTTPS zu Endpunkten, die nicht auf der Whitelist stehen, blockiert worden wäre.
Kunden von TrendAI Vision One finden im Originalbeitrag zudem weitere Anweisungen für Maßnahmen.