GitHub-Leak: Entwicklergeräte werden zum Einfallstor : TeamPCP erbeutet interne Repositories über manipulierte Erweiterung

GitHub prüft derzeit einen Sicherheitsvorfall. Der Auslöser: Die Angreifergruppe TeamPCP behauptet, internen Quellcode und interne GitHub-Strukturen erbeutet zu haben, und bot diese Daten in einem Cybercrime-Forum zum Verkauf an.

Nach bisherigem Stand sieht GitHub keine Hinweise darauf, dass Kundendaten außerhalb der internen GitHub-Repositories betroffen sind. Das heißt: Unternehmensbereiche, Organisationen und Repositories von GitHub-Kunden sollen nach aktueller Einschätzung nicht kompromittiert worden sein.

Sollte sich im weiteren Verlauf der Untersuchung doch zeigen, dass Kunden betroffen sind, will GitHub diese über die üblichen Sicherheits- und Benachrichtigungskanäle informieren.

Angriff über Entwicklerarbeitsplatz

Besonders heikel ist der Weg, über den die Angreifer offenbar Zugriff erhielten. GitHub zufolge wurde ein Gerät eines Mitarbeiters kompromittiert. Der Angriff lief demnach über eine manipulierte Erweiterung für Microsoft Visual Studio Code. Solche Erweiterungen sind Zusatzmodule für Entwicklungsumgebungen. Sie werden genutzt, um Funktionen nachzurüsten, Arbeitsabläufe zu automatisieren oder Code schneller zu bearbeiten.

GitHub nannte den Namen der betroffenen Erweiterung für Visual Studio Code nicht. Auffällig ist jedoch, dass kurz zuvor Nx Console kompromittiert worden war. Bei diesem Vorfall konnten Angreifer einen mehrstufigen Credential-Stealer sowie ein Werkzeug zur Manipulation der Softwarelieferkette einschleusen. Das Nx-Team erklärte später, dass nur „sehr wenige Nutzer“ betroffen gewesen seien.

Nach dem Vorfall meldete sich ein X-Konto zu Wort, das TeamPCP zugerechnet wird. Unter dem Namen xploitrsturtle2 behauptete es: „GitHub wusste seit Stunden Bescheid, hat die Information an euch verzögert weitergegeben und wird auch künftig nicht ehrlich sein. Was für ein unglaublicher Lauf. Es war eine Ehre, in den vergangenen Monaten mit den Katzen zu spielen.“

Nach der Entdeckung des Vorfalls hat GitHub den Angriff nach eigenen Angaben eingedämmt und besonders kritische Zugangsdaten erneuert. Gemeint sind damit zum Beispiel Tokens, Schlüssel oder Passwörter, mit denen interne Systeme oder Dienste erreicht werden können. Vorrang hatten dabei Zugangsdaten, mit denen Angreifer besonders großen Schaden hätten anrichten können.

Nach aktueller Einschätzung wurden ausschließlich interne GitHub-Repositories kopiert. Die von den Angreifern behauptete Zahl von rund 3.800 Repositories passt laut GitHub grob zu den bisherigen Untersuchungsergebnissen.

TeamPCP hatte die Daten zuvor für mindestens 50.000 US-Dollar in einem Cybercrime-Forum angeboten. Die Gruppe stellte das Angebot nicht als klassische Erpressung dar. Sinngemäß erklärte sie: „Wir wollen GitHub nicht erpressen. Ein Käufer genügt, dann löschen wir die Daten bei uns.“ Später tauchte ein gemeinsames Verkaufsangebot von TeamPCP und LAPSUS$ für 95.000 US-Dollar auf. Dazu behaupteten die Angreifer, es sei „alles für die Hauptplattform“ enthalten.

Interne Projekte im Fokus

Nach Angaben des Sicherheitsforschers Rakesh Krishnan sollen die geleakten Repositories unterschiedliche Bereiche betreffen:

• GitHub Actions
• agentische Workflows
• interne Copilot-Projekte
• CodeQL-Werkzeuge
• interne Infrastruktur
• Sicherheitswerkzeuge
• Marketing
• GitHub-nahe Programme wie Codespaces und Dependabot
• ein Rails Controller
• ein Pull Requests Controller zur Verwaltung von Organisationen und Pull Requests

Damit geht es nicht nur um Quellcode, sondern potenziell auch um interne Automatisierung, Sicherheitslogik und Entwicklungsprozesse. Gerade solche Artefakte können Angreifern helfen, Plattformarchitekturen besser zu verstehen, Schwachstellen vorzubereiten oder Folgeangriffe glaubwürdiger zu tarnen.

Lieferkettenangriff auf Python-Paket

Parallel dazu soll TeamPCP seine Malware-Kampagne Mini Shai-Hulud weiter ausgebaut haben. Dabei handelt es sich um Schadsoftware, die sich selbst weiterverbreiten kann, sobald sie in einer Entwicklungsumgebung oder einer Cloud-Infrastruktur ausgeführt wird.

Betroffen ist unter anderem durabletask. Das ist ein offizieller Python-Client von Microsoft für das Durable-Task-Framework, mit dem sich langlebige, verteilte Arbeitsabläufe steuern lassen. Angreifer brachten manipulierte Versionen dieses Pakets in Umlauf. Drei schädliche Versionen wurden bislang identifiziert:

• 1.4.1
• 1.4.2
• 1.4.3

Laut Wiz kompromittierte der Angreifer zunächst ein GitHub-Konto, las Geheimnisse aus einem Repository aus und erlangte dadurch Zugriff auf ein Token für Python Package Index (PyPI). So konnte der Angreifer direkt schädliche Versionen veröffentlichen. Der eingebettete Dropper lädt eine zweite Stufe namens „rope.pyz“ von einer externen Domain nach.

Malware mit Cloud- und CI-Fokus

Die Schadsoftware zielt auf Linux-Systeme und versucht, Zugangsdaten aus Cloud-Umgebungen, Passwortmanagern und Entwicklerwerkzeugen abzugreifen. SafeDepbeschreibt Funktionen zum Auslesen von HashiCorp Vault KV-Secrets, 1Password– und Bitwarden-Tresoren, SSH-Schlüsseln, Docker-Zugangsdaten, VPN-Konfigurationen und Shell-Historien.

Besonders gefährlich ist die Ausbreitungslogik. In Amazon Web Services nutzt die Malware den Systems Manager, um sich über EC2-Instanzen weiterzuverbreiten. In Kubernetes erfolgt die Ausführung über kubectl exec. Aikido Security beschreibt zudem eine destruktive Komponente: Erkennt die Malware israelische oder iranische Systemeinstellungen, bestehe eine Chance von eins zu sechs, dass sie Audio abspielt und anschließend „rm -rf /*“ ausführt.

Warum der Fall für Unternehmen relevant ist

Der Vorfall macht deutlich, wie anfällig moderne Entwicklungsumgebungen inzwischen sind. Entwickler arbeiten heute nicht mehr nur mit lokalem Quellcode. Ihre Rechner sind oft direkt mit internen Repositories, Paketquellen, Cloud-Diensten, Build-Systemen und Automatisierungsplattformen verbunden. Wird ein solches Gerät kompromittiert, kann daraus schnell ein Zugangspunkt zu vielen weiteren Systemen werden.

Besonders gefährlich sind dabei Zugangsdaten wie Tokens, Schlüssel oder Passwörter. Sie werden benötigt, damit Entwicklungswerkzeuge automatisch auf interne Dienste zugreifen können. Genau diese Automatisierung ist im Alltag praktisch, wird im Angriffsfall aber zum Risiko: Gelingt es Angreifern, solche Zugangsdaten auszulesen, können sie unter Umständen Quellcode kopieren, Pakete verändern, Build-Prozesse manipulieren oder sich in Cloud-Umgebungen weiterbewegen.

Hinzu kommt ein weiteres Problem: Viele Entwicklungs- und Produktionsprozesse laufen heute automatisch ab. Pakete werden aus öffentlichen oder internen Quellen geladen, Bibliotheken beim Start einer Anwendung importiert und Build-Pipelines ohne manuelle Kontrolle ausgeführt. Bei dem betroffenen Paket ist das besonders kritisch, weil es laut Endor Labs rund 417.000 Mal pro Monat heruntergeladen wird. Der schädliche Code wird bereits beim Import des Pakets gestartet. Für Nutzer ist das kaum erkennbar, weil keine Fehlermeldung erscheint und es keine sichtbaren Hinweise auf eine Kompromittierung gibt.

Konkrete Folgen

Für Unternehmen hat das klare Konsequenzen. Jede Maschine und jede Pipeline, auf der eine der betroffenen Paketversionen installiert wurde, sollte zunächst als vollständig kompromittiert gelten. Es reicht nicht, das Paket einfach zu entfernen oder auf eine saubere Version zu aktualisieren. Zunächst muss untersucht werden, welche Zugangsdaten auf dem System vorhanden waren, welche Prozesse ausgeführt wurden und ob Daten abgeflossen sind.

Dazu gehören eine forensische Analyse der betroffenen Systeme, die Erneuerung aller erreichbaren Geheimnisse sowie die Prüfung von Protokollen aus Continuous Integration und Continuous Delivery. Diese Protokolle können zeigen, ob ungewöhnliche Befehle ausgeführt, Pakete unerwartet nachgeladen oder externe Server kontaktiert wurden. Ebenso wichtig ist Paket-Pinning. Dabei werden Abhängigkeiten nicht nur grob nach Versionsbereichen eingebunden, sondern auf konkrete, geprüfte Versionen festgelegt. So lässt sich verhindern, dass Build-Prozesse automatisch eine manipulierte neue Version übernehmen.

Auch der Umgang mit Entwicklererweiterungen muss strenger kontrolliert werden. Erweiterungen für Entwicklungsumgebungen können tief in Arbeitsabläufe eingreifen, Dateien lesen, Befehle ausführen und Zugangsdaten berühren. Deshalb sollten Unternehmen klare Freigabeprozesse, geprüfte Erweiterungslisten und regelmäßige Kontrollen einführen. Zusätzlich sollten Tokens kontinuierlich überwacht werden: Wo werden sie genutzt, von welchen Systemen aus, zu welchen Zeiten und für welche Aktionen?

Der Fall ist damit weit mehr als ein isolierter Sicherheitsvorfall bei GitHub. Er zeigt ein strukturelles Risiko der gesamten Softwarelieferkette. Sobald Angreifer Entwicklergeräte, Pakete oder automatisierte Build-Prozesse kompromittieren, können sie nicht nur einzelne Systeme treffen, sondern den Weg in viele nachgelagerte Anwendungen, Dienste und Kundenumgebungen öffnen.