Was Microsoft beobachtet haben will
Microsoft Threat Intelligence veröffentlichte den Bericht am 5. November 2026. Laut Unternehmen nutzten Bedrohungsakteure ein agentisches Framework, um öffentliche GitHub-Repositories nach offengelegten Zugangsdaten zu durchsuchen, darunter Anwendungsschlüssel und KI-Inferenzschlüssel, Ergebnisse auszuwerten und Folgeaktivitäten vorzunehmen. In einem Fall sei ein Agent innerhalb von fünf Minuten von der Repository-Suche zur Datenexfiltration aus Azure Key Vault gelangt. Das sind Microsofts Incident-Angaben; CherTra News hat die Fälle nicht unabhängig verifiziert.
Microsoft berichtet außerdem von erfolgreichen Service-Principal-Anmeldungen bei einigen betroffenen Kunden ab dem 28. Oktober und anschließender Erkundung von Cloud-Ressourcen sowie Zugriff auf Key Vault und Storage. Manche kompromittierten Zugangsdaten stammten demnach aus einer mandantenfähigen Anwendung eines Anbieters. Das bedeutet nicht, dass jedes öffentliche Geheimnis automatisch missbraucht wird; das Löschen aus dem Repository allein beendet eine Offenlegung jedoch nicht.
Gefundene Zugangsdaten als kompromittiert behandeln
Taucht ein Zugang in öffentlichem Code auf, sollte man annehmen, dass er kopiert wurde, selbst wenn das Repository schnell privat oder der Commit umgeschrieben wird. Den Zugang zuerst widerrufen oder deaktivieren und danach über das freigegebene Verfahren ersetzen. Abhängige Dienste sicher aktualisieren, die Ungültigkeit des alten Zugangs bestätigen und Protokolle nach ungewöhnlichen Zeiten, Orten, Identitäten oder Ressourcenmustern prüfen.
Ermitteln, worauf der Zugang Zugriff hatte und ob er über Umgebungen hinweg wiederverwendet wurde. Ein Entwicklungsschlüssel sollte keine Produktionsrechte besitzen. Bei Service Principal oder Anbieter erfragen, welche Anwendungen und Mandanten dieselbe Identität nutzen. Auditbelege aufbewahren und die zuständige Incident-Response-Stelle einbeziehen; eine saubere wirkende Git-Historie beweist nicht, dass die Offenlegung beendet ist.
Weitere Offenlegungen unwahrscheinlicher machen
Secret Scanning und Push Protection in unterstützten Repositories aktivieren, gegebenenfalls auch die Überwachung öffentlicher Repositories. Zugangsdaten in einem verwalteten Secret Store aufbewahren, jeder Identität nur notwendige Berechtigungen geben und nach Möglichkeit kurzlebige Zugangsdaten oder Workload Identity nutzen. Test und Produktion trennen, Verantwortliche und Ablaufdaten festlegen und ungewöhnliche Anmeldungen oder Datenzugriffe überwachen.
Auch automatisierte Jobs, Forks, Build-Protokolle, Issue-Anhänge und Deployment-Konfiguration prüfen. Scanning erkennt unterstützte Formate, kann aber nicht belegen, dass jede Art von Geheimnis fehlt. Ein regelmäßiges Inventar und eine Zugriffsprüfung bleiben besonders für Anbieterintegrationen und Maschinenidentitäten nötig.
Reaktionscheckliste für kleine Teams
1) Offen gelegtes Geheimnis widerrufen. 2) Ersetzen und den legitimen Dienst über einen vertrauenswürdigen Kanal aktualisieren. 3) Identitäts- und Cloud-Protokolle auf die alte Kennung und verbundene Konten prüfen. 4) Verdächtige Zugriffe begrenzen oder aussetzen und Belege sichern. 5) Kontrollierte Repositories und Build-Systeme nach Kopien durchsuchen. 6) Scanning und Push Protection aktivieren und Berechtigungen sowie Ablaufzeiten überprüfen.
Könnten Kundendaten oder Kundenumgebungen betroffen sein, den Incident- und Benachrichtigungsprozess der Organisation anwenden und qualifizierte Sicherheitsunterstützung einbeziehen. Microsofts Beitrag enthält Erkennungsdetails für Verteidiger; dieser Artikel beschränkt sich bewusst auf defensive Maßnahmen. Ein Geheimnis ist eine Identität: Nach einer Offenlegung muss diese erneuert und ihr möglicher Zugriffsbereich untersucht werden.
Quellen und weiterführende Informationen
Einen sachlichen Fehler melden oder eine Quelle vorschlagen? Redaktion kontaktieren.
