Fünf Minuten – mehr braucht es offenbar nicht, um aus einem öffentlich einsehbaren Zugangsschlüssel einen handfesten Cloud-Sicherheitsvorfall zu machen. In einer neuen Sicherheitsanalyse vom 5. November 2026 warnt Microsoft vor Angreifern, die KI-Agenten nutzen, um GitHub-Projekte nach Zugangsdaten zu durchsuchen und danach automatisiert Azure-Dienste anzugreifen.
In einem von Microsoft beschriebenen Fall schaffte es ein KI-Agent in nur fünf Minuten, von der Suche nach Zugangsdaten auf GitHub bis zum Abfluss von Informationen aus Azure Key Vault zu kommen. Bei den untersuchten Angriffen waren unter anderem Microsoft Entra ID, Azure Storage, SharePoint, OneDrive und weitere Microsoft-365-Dienste betroffen. Wir erklären, wie diese Angriffe ablaufen und welche Schutzmaßnahmen Administratoren jetzt prüfen sollten.
Microsoft entdeckt neue Angriffe mit KI-Agenten auf Azure und Microsoft 365
Microsoft Threat Intelligence und Microsoft Security Research haben am 5. November 2026 eine umfangreiche Untersuchung veröffentlicht. Die Forscher beschreiben darin den Einsatz eines agentenbasierten Angriffswerkzeugs namens ARTEX.
Solche KI-Agenten arbeiten anders als ein gewöhnlicher Chatbot. Sie können selbstständig mehrere Arbeitsschritte ausführen, Ergebnisse auswerten und weitere Aktionen vorbereiten. Genau das machen sich Angreifer zunutze.
Bereits seit August 2026 beobachtete Microsoft automatisierte Suchvorgänge nach Zugangsdaten in öffentlichen GitHub-Repositories. Ab dem 28. Oktober wurden außerdem erfolgreiche Anmeldungen mit kompromittierten Anwendungsidentitäten in betroffenen Cloud-Umgebungen festgestellt.
| Merkmal | Bestätigte Angaben |
|---|---|
| Veröffentlichung | 5. November 2026 |
| Herstelleranalyse | Microsoft Threat Intelligence und Security Research |
| Angriffswerkzeug | Agentenbasiertes KI-Framework ARTEX |
| Erste Beobachtungen | August 2026 |
| Weitere bestätigte Angriffe | Seit mindestens 28. Oktober 2026 |
| Schnellste dokumentierte Angriffskette | Fünf Minuten bis zum Abfluss aus Azure Key Vault |
| Betroffene Plattformen | Unter anderem GitHub, Entra ID, Azure und Microsoft 365 |
| CVE-Nummer | Keine konkrete Software-Schwachstelle als Ausgangspunkt erforderlich |
| Sicherheitsupdate oder KB | Kein allgemeiner Patch für diesen Angriffsweg |
Wichtig ist die richtige Einordnung: Microsoft beschreibt bereits beobachtete Angriffe und nicht nur eine theoretische Gefahr. Allerdings ist nicht jede Azure- oder Microsoft-365-Umgebung automatisch betroffen. Der entscheidende Ausgangspunkt sind verwendbare Zugangsdaten, die Angreifer finden oder anderweitig kompromittieren können.
Wie funktioniert ein KI-Angriff über GitHub?
GitHub nutzen Entwickler und Unternehmen, um Programmcode und Konfigurationsdateien zu verwalten. Heikel wird es, wenn dort versehentlich vertrauliche Informationen landen.
Dazu zählen etwa API-Schlüssel, Client Secrets, Kennwörter, Storage-Zugangsschlüssel oder Connection Strings. Solche Daten stecken nicht selten in Skripten, Konfigurationsdateien, Dokumentationen oder auch in der Versionshistorie.
Früher mussten Angreifer solche Informationen oft mühsam von Hand zusammensuchen. KI-Agenten dagegen können viele Repositories automatisch durchsuchen, gefundene Zugangsdaten bewerten und anschließend direkt passende Cloud-Schnittstellen ansprechen.
Vom GitHub-Secret bis zum Azure Key Vault
Microsoft beschreibt eine Angriffskette, bei der zunächst öffentliche GitHub-Inhalte untersucht wurden. Nach dem Auffinden verwendbarer Zugangsdaten konnte der Angreifer eine Anwendung authentifizieren und weitere Azure-Ressourcen erreichen.
Der KI-Agent passte während seiner Arbeit sogar fehlerhafte API-Anfragen an. Wenn eine Cloud-Schnittstelle zunächst einen Fehler zurücklieferte, probierte das System alternative API-Versionen oder Aufrufmethoden aus.
In einem Fall führte diese Automatisierung innerhalb von nur fünf Minuten zum Abfluss von Informationen aus Azure Key Vault. Dort speichern Unternehmen normalerweise besonders schützenswerte Geheimnisse, Zertifikate und Schlüssel.
Damit zeigt sich eine wesentliche Veränderung: Die Geschwindigkeit eines Angriffs hängt nicht mehr ausschließlich davon ab, wie schnell ein Mensch einzelne Befehle ausführen kann.
Welche Microsoft-Dienste wurden angegriffen?
Microsoft hat beobachtet, dass nach der Nutzung kompromittierter Anwendungsidentitäten ganz unterschiedliche Aktivitäten stattfanden. Welche Dienste betroffen waren und was konkret ausgeführt wurde, hing stark davon ab, welche Umgebung die Angreifer erwischt hatten.
| Microsoft-Dienst | Beobachtete Aktivität |
|---|---|
| Entra ID | Anmeldung mit kompromittierten Service Principals |
| Azure Key Vault | Suche nach Geheimnissen und Datenabfluss |
| Azure Storage | Ressourcenerkennung und Zugriff auf Speicherdaten |
| SharePoint und OneDrive | Zugriffe auf Dateien und Downloads |
| Microsoft 365 | Abfragen von Postfachinhalten und Microsoft Graph |
| Azure AI Services | Verdächtige Zugriffe und möglicher Missbrauch von KI-Ressourcen |
| Azure Virtual Machines | Missbrauch von Verwaltungsfunktionen zur Ausführung von Befehlen |
Diese Zugriffe wurden nicht zwangsläufig alle in derselben kompromittierten Umgebung beobachtet. Sie zeigen jedoch, wie weitreichend die Folgen eines gestohlenen Anwendungsgeheimnisses sein können.
Warum Service Principals ein besonderes Sicherheitsrisiko darstellen
Ein Service Principal ist sozusagen die technische Identität einer Anwendung – damit kann sie auf Microsoft-Cloud-Dienste zugreifen. Gebraucht wird das zum Beispiel für Automatisierungen, Schnittstellen und Hintergrunddienste. Anders als ein menschlicher Benutzer meldet sich ein Service Principal häufig mit einem Zertifikat oder einem Client Secret an. Kommt dieses Geheimnis in falsche Hände, kann ein Angreifer unter Umständen mit genau den Rechten agieren, die auch die Anwendung hat.
Eine gewöhnliche Multi-Faktor-Authentifizierung für Benutzerkonten schützt diese technischen Identitäten nicht automatisch. Warum unterschiedliche Arten von Zugangsdaten getrennt abgesichert werden müssen, haben wir bereits im Artikel Storm-3168: KI-Angriff löscht Azure-Ressourcen erklärt.
Auch unser Beitrag EvilTokens: Microsoft 365 durch Phishing gefährdet zeigt, dass moderne Angriffe zunehmend bestehende Anmeldeverfahren und gültige Identitäten missbrauchen.
Microsoft nennt verdächtige IP-Adressen
In seiner Untersuchung dokumentiert Microsoft verschiedene IP-Adressen, die bei den beobachteten Aktivitäten aufgefallen sind. Besonders relevant sind zwei Adressen im Zusammenhang mit Anmeldungen von Service Principals.
| IP-Adresse | Microsofts Beobachtung |
|---|---|
| 199.19.77.84 | Erfolgreiche verdächtige Anwendungsanmeldungen |
| 199.19.77.18 | Weitere Anmeldungen, Tor-Ausgangsknoten |
| 65.87.223.26 | Verdächtige Anfragen und mögliche Exploit-Versuche |
| 157.22.126.128 | Erkundung von Azure-KI-Diensten |
Administratoren können diese Adressen bei der Untersuchung ihrer Sicherheitsprotokolle berücksichtigen. Ein einzelner Treffer beweist jedoch noch keine Kompromittierung. Microsoft weist außerdem darauf hin, dass Angreifer ihre Infrastruktur jederzeit wechseln können.
Die Untersuchung sollte deshalb nicht ausschließlich auf einzelne IP-Adressen beschränkt werden. Ungewöhnliche Anmeldungen, plötzlich verwendete Berechtigungen und auffällige Cloud-API-Aufrufe sind ebenso wichtig.
Azure und Microsoft 365 absichern: Sechs wichtige Prüfungen
1. Anwendungsidentitäten im Entra Admin Center kontrollieren
Melde dich zunächst mit einem passenden Administratorkonto im Microsoft Entra Admin Center an. Gehe dann zu Entra ID und weiter zum Bereich Anwendungen.
Unter App-Registrierungen kannst Du die selbst registrierten Anwendungen prüfen. Unter Unternehmensanwendungen findest Du dagegen alle Service Principals im Tenant – darunter auch viele Anwendungen von Drittanbietern.
Verschaffe dir anschließend einen Überblick über Anwendungen mit besonders weitreichenden Berechtigungen. Prüfe dabei die Besitzer, den Einsatzzweck, hinterlegte Anmeldeinformationen und die tatsächlich benötigten Zugriffsrechte.
2. GitHub und Azure DevOps nach Zugangsdaten durchsuchen
Prüfe öffentliche und private Repositories auf gespeicherte Geheimnisse. Achte besonders auf Konfigurationsdateien, Automatisierungsskripte und versehentlich veröffentlichte Umgebungsvariablen.
Microsoft empfiehlt hierfür die GitHub-Funktionen zur Secret-Erkennung und entsprechende Sicherheitsprüfungen in Azure DevOps. Wo möglich, sollte zusätzlich verhindert werden, dass Zugangsschlüssel überhaupt in ein Repository übertragen werden.
Ein wichtiger Punkt: Das Löschen einer Datei reicht nicht aus, wenn ein darin enthaltener Zugangsschlüssel bereits öffentlich sichtbar war. Auch ältere Commits, Kopien und Zwischenspeicher können die Informationen weiterhin enthalten.
3. Kompromittierte Secrets sofort ersetzen
Wenn Du einen Schlüssel findest, der öffentlich geworden ist, solltest Du davon ausgehen, dass er womöglich schon kopiert wurde. Ersetze oder widerrufe das betroffene Geheimnis und untersuche, wie es bisher verwendet wurde.
Bei einer selbst verwalteten Anwendung kannst Du unter App-Registrierungen im Bereich Zertifikate und Geheimnisse prüfen, welche Anmeldeinformationen hinterlegt sind. Achte beim Austausch darauf, dass die legitime Anwendung danach weiterhin funktioniert.
Bei einem bestätigten Angriff reicht es unter Umständen nicht, nur das ursprünglich gefundene Secret zu ersetzen. Konnte der kompromittierte Service Principal auf Azure Key Vault zugreifen, müssen gegebenenfalls auch die dort erreichbaren Geheimnisse erneuert werden.
4. Anmeldeprotokolle und Cloud-Aktivitäten prüfen
Microsoft Entra ID stellt Anmeldeprotokolle für technische Identitäten bereit. Kontrolliere die Service-Principal-Anmeldungen auf ungewöhnliche IP-Adressen, neue Zugriffsorte und bisher nicht verwendete Anwendungen.
Ergänze diese Kontrolle durch Azure Activity Logs, Key-Vault-Diagnoseprotokolle, Microsoft-365-Auditdaten und gegebenenfalls Azure-DevOps-Protokolle. Welche Daten tatsächlich verfügbar sind, hängt von den aktivierten Protokollierungen, Berechtigungen und Aufbewahrungszeiten ab.
Für die lokale Untersuchung von Windows-Ereignissen findest Du passende Beispiele unter Windows Ereignisanzeige mit PowerShell auslesen. Die Windows-Ereignisanzeige ersetzt allerdings nicht die Cloud-Anmeldeprotokolle von Entra ID.
5. Berechtigungen von Anwendungen reduzieren
Ein Service Principal sollte grundsätzlich nur auf diejenigen Ressourcen zugreifen können, die seine Anwendung tatsächlich benötigt. Besonders kritisch sind umfangreiche Berechtigungen auf ganze Azure-Abonnements oder weitreichende Microsoft-Graph-Berechtigungen.
Kontrolliere auch die Rechte von Drittanbieteranwendungen. Microsoft beschreibt ausdrücklich Fälle, in denen kompromittierte Zugangsdaten einer mandantenübergreifenden Anbieteranwendung für Angriffe auf mehrere Kundenumgebungen verwendet wurden.
Für die Absicherung menschlicher Administratoren bleiben zusätzliche Anmeldeverfahren unverzichtbar. Unser Beitrag Microsoft Entra: Passkeys statt SMS-Anmeldung erklärt die weitere Entwicklung.
6. Microsoft Defender und Conditional Access berücksichtigen
Microsoft rät, für kritische Azure-Ressourcen passende Defender-for-Cloud-Schutzfunktionen einzusetzen – zum Beispiel Schutz und Überwachung für Key Vault, Storage und Resource Manager.
Ergänzend lassen sich mit Conditional-Access-Richtlinien für Workload-Identitäten die Zugriffsmöglichkeiten einzelner Service Principals einschränken. Allerdings braucht man dafür die entsprechenden Lizenzen, und automatisch geschützt sind damit auch nicht alle mandantenübergreifenden Anwendungen.
Wie Microsoft Sicherheitsereignisse aus unterschiedlichen Diensten künftig stärker zusammenführen möchte, erklären wir im Beitrag Microsoft Defender ISOC mit KI-Agenten.
Warum ein Windows-Update allein nicht helfen kann
Der von Microsoft beschriebene Angriffsweg beruht vor allem auf gültigen, aber unzureichend geschützten Zugangsdaten. Deshalb gibt es für diesen Vorfall keine allgemeine Windows-KB-Nummer und auch keine einzelne Softwareversion, deren Installation das Problem vollständig behebt.
Selbst ein vollständig aktualisierter Windows-11-PC verhindert nicht, dass ein öffentlich gespeichertes Azure Client Secret von einem fremden Rechner aus verwendet wird.
Eine gute Windows-Sicherheitskonfiguration bleibt dennoch wichtig. Weitere Grundlagen findest Du unter Windows-Sicherheit richtig verstehen und Windows Credential Guard aktivieren.
Microsoft Defender for Endpoint schützt außerdem die lokalen Geräte und liefert zusätzliche Sicherheitsinformationen. Falls das Onboarding scheitert, hilft unsere Anleitung zum Microsoft Defender for Endpoint Setup-Fehler.
Aus der Administratorpraxis: Technische Konten werden oft unterschätzt
In Unternehmen werden Benutzerkonten oft regelmäßig überprüft – bei Anwendungen und technischen Dienstidentitäten sieht das dagegen nicht immer so aus. Gerade ältere Automatisierungen behalten über Jahre weitreichende Berechtigungen, obwohl sie längst nicht mehr gebraucht werden.
Ich würde deshalb eine zentrale Übersicht aller Service Principals führen. Darin sollte stehen, wer verantwortlich ist, welche Berechtigungen verwendet werden, wofür die Anwendung da ist und wann die nächste Prüfung ansteht. Besonders wichtig ist eine regelmäßige Kontrolle von Anwendungen, die auf mehrere Microsoft-365- oder Azure-Dienste zugreifen dürfen.
Auch ein sauber dokumentiertes Berechtigungskonzept ersetzt die technische Überwachung nicht. Wie häufig gestohlene Identitäten am Anfang größerer Angriffe stehen, zeigt der Microsoft Digital Defense Report 2026.
FAQ: Häufige Fragen zu KI-Angriffen auf Azure und Microsoft 365
Was hat Microsoft am 5. November 2026 veröffentlicht?
Microsoft Threat Intelligence und Microsoft Security Research haben eine neue Untersuchung über Angreifer veröffentlicht, die KI-Agenten zur Suche nach veröffentlichten Zugangsdaten und für automatisierte Cloud-Angriffe verwenden.
Können KI-Agenten wirklich innerhalb von fünf Minuten Daten stehlen?
Ja. Microsoft dokumentiert mindestens einen Fall, bei dem zwischen der Suche nach Zugangsdaten auf GitHub und dem Abfluss von Informationen aus Azure Key Vault nur fünf Minuten vergingen. Das ist ein beobachtetes Beispiel und keine allgemeingültige Angriffsdauer.
Welche Unternehmen sind durch diese Angriffe gefährdet?
Besonders gefährdet sind Organisationen, deren verwendbare Zugangsschlüssel, Client Secrets oder andere Cloud-Anmeldeinformationen öffentlich geworden sind. Die Risiken hängen außerdem von den Berechtigungen der betroffenen Anwendungen ab.
Hilft Multi-Faktor-Authentifizierung gegen solche KI-Angriffe?
MFA ist für menschliche Benutzerkonten wichtig. Technische Anwendungsidentitäten melden sich aber häufig über Client Secrets oder Zertifikate an. Deshalb benötigen Service Principals zusätzliche Schutzmaßnahmen und möglichst eingeschränkte Berechtigungen.
Reicht es, einen veröffentlichten GitHub-Schlüssel zu löschen?
Nein. Ein öffentlich gewordener Schlüssel muss ersetzt oder widerrufen werden. Außerdem solltest Du prüfen, ob er bereits missbraucht wurde. Das ursprüngliche Geheimnis kann noch in Änderungshistorien oder Kopien vorhanden sein.
Gibt es für den Angriff eine CVE oder eine Microsoft-KB-Nummer?
Nein. Die beschriebene Angriffstechnik erfordert nicht zwingend eine bestimmte Software-Sicherheitslücke. Der Schutz besteht vor allem darin, veröffentlichte Zugangsdaten zu ersetzen, Anwendungsrechte zu begrenzen und verdächtige Zugriffe zu erkennen.
Sind auch SharePoint, OneDrive und Outlook betroffen?
Microsoft beobachtete bei betroffenen Organisationen unter anderem Zugriffe auf SharePoint, OneDrive und Postfachinhalte. Welche Daten erreichbar sind, hängt von den jeweiligen Anwendungsberechtigungen ab.
Fazit: KI beschleunigt Cloud-Angriffe erheblich
Microsofts neue Sicherheitsanalyse zeigt: KI-Agenten machen Angreifer nicht nur schneller bei der Suche nach Sicherheitslücken. Sie können gefundene Zugangsdaten auch sofort einsetzen, Cloud-Dienste auskundschaften und danach weitere Schritte einleiten.
Für Unternehmen heißt das vor allem: technische Identitäten und Zugangsschlüssel konsequent im Blick behalten. Öffentlich gewordene Secrets sollten sofort ersetzt, Anwendungsberechtigungen überprüft und ungewöhnliche Zugriffe untersucht werden.
Die vollständige technische Untersuchung mit weiteren Erkennungsmerkmalen und Schutzempfehlungen hat Microsoft am 5. November 2026 im Microsoft Security Blog veröffentlicht.
Neueste Kommentare