Letzte Woche hat GitHub die Selbstbedienungsfunktion zum Widerruf von Zugangsdaten für Enterprise eingeführt. Mit dieser Funktion können Organisationsinhaber kompromittierte Zugangsdaten organisationsweit mit einem einzigen Schritt sperren, anstatt während eines laufenden Vorfalls einzelne Tokens aufspüren zu müssen.
Diese Korrektur ließ lange auf sich warten, denn die letzten Monate haben gezeigt, was passiert, wenn die Sperrung von Zugangsdaten nur langsam oder unvollständig erfolgt. Der Trivy im März kam zu einer zweiten Runde zurück, weil bei der ersten Bereinigung mindestens ein Zugangsdatensatz unberührt geblieben war, und diese Kettenreaktion erreichte Checkmarx später. Im Juni wurden Microsofts eigene „durabletask“-Repositorys über ein Konto angegriffen, das nach einem früheren Angriff nie vollständig bereinigt worden war.
Microsoft hat in letzter Zeit bei Sicherheitspatches richtig Gas gegeben . Erst vor wenigen Tagen haben sie eine Wartezeit für Veröffentlichungen nach Kontoänderungen eingeführt, und bereits Anfang Juni haben sie npm aktualisiert, um automatische Skripte nach der Installation zu unterbinden. Wir werden weiterhin im Auge behalten, welche weiteren Maßnahmen sie ergreifen und wie sich dies auf Angriffe auf Open-Source-Software auswirkt.
Was GitHub veröffentlicht hat
Unternehmensinhaber mit der Berechtigung „Unternehmenszugangsdaten verwalten“ können nun die Zugangsdaten aller Benutzer in der Organisation in einem Schritt widerrufen oder löschen oder gezielt ein bestimmtes Konto auswählen. Dies umfasst SSO-Autorisierungen für Personal Access Tokens (PATs), SSH-Schlüssel und OAuth-Token. Für Organisationen mit Enterprise Managed Users (EMU) steht eine Option zum vollständigen Löschen zur Verfügung, und REST-APIs auf Organisationsebene ermöglichen eine detailliertere Widerrufung auf Organisationsebene. Jede Aktion erzeugt einen Eintrag im Prüfprotokoll und löst E-Mail-Benachrichtigungen an die betroffenen Benutzer aus.
Einzelmitglieder erhalten eine neue Ansicht unter „Einstellungen > Anmeldedaten“, in der alle mit ihrem Konto verknüpften Anmeldedaten angezeigt werden – sowohl SSO-autorisierte als auch persönliche. Von dort aus können sie mit einem einzigen Schritt den Zugriff all dieser Anmeldedaten auf SSO-geschützte Unternehmensressourcen aufheben, wodurch der zeitaufwändige Vorgang entfällt, eine Token-Liste Eintrag für Eintrag durchzugehen. Mitglieder von EMU-Organisationen erhalten zudem eine separate Option, um alle ihre Token und SSH-Schlüssel dauerhaft zu löschen.
Vor der Einführung dieser „Break-Glass“-Funktion musste man mehrere verschiedene Tools nutzen, um die Anmeldedaten eines Kontos zu sperren. Fein abgestimmte PATs konnten über den Bildschirm „Organisationstoken“ widerrufen werden. Klassische Token konnten nur durch den Widerruf der SSO-Autorisierung pro Token gesperrt werden – und das auch nur, wenn SAML-SSO aktiviert war. Die API zum Widerruf von Anmeldedaten konnte ein Token zwar deaktivieren, jedoch nur, wenn man die Token-Zeichenkette bereits zur Hand hatte – was im Fall eines durchgesickerten Geheimnisses funktioniert, nicht jedoch im Fall eines kompromittierten Kontos (dies kratzt nur an der Oberfläche der Komplexität, aber wir belassen es dabei). Der Punkt ist: Dies führte zu einem ziemlich chaotischen Versuch, Änderungen an Anmeldedaten zu koordinieren.
Hinweis: GitHub-Actions-Token fallen hier nicht in den Betrachtungsbereich, da sie pro Job generiert werden und nach Beendigung des Jobs verfallen – es gibt also nichts, was widerrufen werden könnte. Um den Schaden während eines Vorfalls zu begrenzen, sollten die Actions für das Repository deaktiviert werden.
Warum gerade jetzt?
Die jüngsten Malware-Angriffe haben Microsoft direkt getroffen.
Am 19. Mai nutzten Angreifer zuvor gestohlene Zugangsdaten, um drei schädliche Versionen von Microsofts durabletask Paket auf PyPI, als Teil der Miasma-Wurm-Kampagne. Microsoft entfernte die Pakete innerhalb weniger Stunden. Am 5. Juni veröffentlichte dasselbe Konto jedoch einen bösartigen Commit im GitHub-Repository `Azure/durabletask` und schleuste den Wurm erneut ein. GitHub reagierte darauf mit der Sperrung von 73 Repositories in vier GitHub-Organisationen von Microsoft. Darunter befand sich auch das Azure Functions-Tooling, über das viele Teams ihre Anwendungen bereitstellen, was zu einer Unterbrechung der CI/CD-Pipelines auch außerhalb von Microsoft führte. Forscher nennen mehrere mögliche Erklärungen für die Wiederholung, doch die wahrscheinlichste ist, dass die Anmeldedaten vom Mai nie vollständig ausgetauscht wurden. Ein Überwachungsunternehmen fand später heraus, dass die GitHub-Anmeldedaten des Kontos bereits seit April in den Protokollen eines Infostealers zu finden waren. Unabhängig vom genauen Mechanismus wurde bei beiden Angriffen dasselbe Konto verwendet.
Das ist jedoch nichts Neues, und das Problem ist in diesem Jahr bereits mehrfach aufgetreten. Ende Februar 2026 wurde eine bösartige Ein KI-Bot nutzte eine fehlerhafte Konfiguration aus pull_request_target GitHub-Actions-Workflow im Repository Trivy, wodurch der Angreifer ein PAT mit Schreibzugriff auf mehr als 33 Workflows innerhalb der Aqua Security stehlen konnte. Aqua Security den Vorfall und führte eine Rotation der Zugangsdaten durch. Leider war die Rotation jedoch nicht vollständig, und die Zugangsdaten wurden nicht alle gleichzeitig gesperrt.
Am 19. März nutzten die Angreifer Anmeldedaten, die die unvollständige Rotation überstanden hatten, um 75 von 76 Versions-Tags intrivy zwangsweise in bösartige Commits zu übertragen. Die Payload wurde in jeder Pipeline vor dem eigentlichen Trivy ausgeführt, sodass jeder Workflow den Anschein erweckte, normal abgeschlossen zu sein. CI/CD-Pipelines, auf denen Trivy lief, Trivy Anmeldedaten von ihren eigenen Runners, darunter SSH-Schlüssel, Cloud-Anmeldedaten, Kubernetes-Token und GitHub-PATs.
Vier Tage später wurden gestohlene Anmeldedaten aus diesen Pipelines genutzt, um die GitHub Actions Checkmarx mit einer identischen Stealer-Nutzlast zu infizieren . Checkmarx , dass die Aktivitäten der Angreifer in ihrer Umgebung bis zum 22. April andauerten und die entwendeten Daten am 25. April im Dark Web veröffentlicht wurden.
Checkmarx gesamte Checkmarx Trivy Checkmarx lässt sich auf eine unvollständige Rotation zurückführen. Aqua Security nach dem Sicherheitsvorfall im Februar alle Zugangsdaten für das kompromittierte Dienstkonto sofort sperren können, wäre der Angriff dort gestoppt worden.
Atomrotation – was?
Atomare Rotation bedeutet, dass die Anmeldedaten in einem einzigen „Alles-oder-Nichts“-Vorgang ausgetauscht werden, sodass zu keinem Zeitpunkt sowohl die neuen als auch die alten Anmeldedaten gültig sind. Das Ziel besteht darin, jegliche Ausfallzeiten im System zu vermeiden. Theoretisch klingt das gut. In einem verteilten System funktioniert das jedoch einfach nicht so. Der Koordinationsaufwand ist einfach viel zu groß. Bei einer Organisation von der Größe von GitHub ist eine atomare Rotation unsinnig.
Bei einer echten Rotation wählt man also einen von zwei Wegen, die beide nicht perfekt sind. Bei der routinemäßigen Rotation bleiben beide Zugangsdaten für einen bestimmten Zeitraum gültig, sodass keine Funktionsstörungen auftreten. Das ist in Ordnung, solange alles reibungslos läuft, führt jedoch dazu, dass die alten Zugangsdaten weiterhin bestehen bleiben. Bei der Reaktion auf Sicherheitsvorfälle wird das Gegenteil getan: Die alten Zugangsdaten werden sofort gesperrt, wobei in Kauf genommen wird, dass es zu Funktionsstörungen kommt, bis neue Zugangsdaten ausgestellt werden.
Mit einem „Break-Glass“-Button können Sie das einzige tun, was tatsächlich „atomar“ ist: nämlich alle Zugangsdaten im Geltungsbereich auf einen Schlag zu löschen. Sicher, das bringt CI/CD zum Erliegen. Aber einen Angreifer aus Ihrer Infrastruktur zu entfernen, ist weitaus wichtiger und lohnt sich, auch wenn die Builds dafür ein paar Stunden oder Tage lang nicht funktionieren.
Bislang war es einfach schwierig, alle Zugangsdaten auf einmal zu sperren. Diese neue Sperrfunktion mit nur einem Schritt macht es möglich, dies auch unter Zeitdruck durchzuführen, und obwohl eine vollständig atomare Rotation nach wie vor schwer zu erreichen ist, bringt uns dies dem Idealzustand ein Stück näher.
Was ist zu tun?
Stellen Sie in Ihrer GitHub-Organisation sicher, dass die Berechtigung „Unternehmenszugangsdaten verwalten“ einer Person zugewiesen ist, die sofort handeln kann, und tun Sie dies, bevor ein Vorfall eintritt. Sehen Sie sich jetzt „Einstellungen > Zugangsdaten“ an, damit Sie wissen, was darunter fällt.
Wenn Sie Ihre Sicherheitseinstellungen aktualisieren, sollten Sie Ihre GitHub-Actions außerdem an vollständige Commit-SHAs statt an Versions-Tags binden. Tags können per Force-Push so geändert werden, dass sie auf völlig anderen Code verweisen – genau das ist die Kerntechnik hinter dem Trivy . Ein festgelegter Commit-SHA kann nicht verschoben werden.
Aikido überwacht Ihre Anwendungen in Echtzeit auf kompromittierte Pakete. Wenn etwas in Ihrer Pipeline manipuliert wird, erhalten Sie eine Warnmeldung, noch bevor der Credential Harvester ausgeführt wird. Dies wird durch Aikido ermöglicht, das neue Paketversionen analysiert, sobald sie verfügbar sind.
Vielen Dank für all die Updates, Microsoft. Bitte macht weiter so. 🙏
