Microsoft Threat Intelligence berichtete am 5. November 2026, dass Angreifer ab August öffentliche GitHub-Repositories mit dem agentischen KI-Framework ARTEX nach offengelegten Zugangsdaten durchsuchten und gültige Anwendungszugänge anschließend in Microsoft-Cloud-Umgebungen nutzten. In einem von Microsoft beobachteten Fall vergingen von der GitHub-Suche bis zur Exfiltration von Daten aus Azure Key Vault fünf Minuten. Zugehörige erfolgreiche Anmeldungen von Service Principals beobachtete Microsoft bereits ab dem 28. Oktober. Microsofts Bericht zu ARTEX beschreibt außerdem drei getrennte Wiederholungen von Azure-API-Anfragen und Empfehlungen für die Abwehr.
Für den größeren Zusammenhang zu den Risiken autonom handelnder Systeme gibt es einen Überblick zu autonomen KI-Agenten bei NeoTeo. Der hier beschriebene Bericht handelt konkret davon, wie offengelegte Zugangsdaten den Weg in Cloud-Dienste ebnen können.
Was Microsoft über die GitHub-Suche berichtet
Microsoft zufolge suchten ARTEX-Agenten in öffentlichen Repositories nach Geheimnissen, darunter Zugangsdaten. Die Suchanfragen kombinierten demnach Namen von Zielorganisationen mit Begriffen rund um Geheimnisse sowie Cloud- und KI-Anbieter. Das Framework wertete die Treffer aus und ermöglichte Folgeaktionen mit gültigen Anwendungszugängen.
Der Fünf-Minuten-Fall beschreibt einen einzelnen beobachteten Ablauf, keine allgemeine Dauer für solche Angriffe: Von der Suche nach einem Geheimnis auf GitHub bis zum Abfluss von Daten aus Azure Key Vault vergingen laut Microsoft fünf Minuten.
Wie die Zugangsdaten zu Cloud-Diensten führten
Ein Service Principal ist eine Anwendungsidentität, mit der sich ein Dienst in Microsoft Entra ID anmelden kann. Microsoft berichtete von erfolgreichen Anmeldungen solcher Identitäten über Dutzende zugehörige Anwendungen und mehrere Mandanten hinweg. In einem Fall sei ein Geheimnis für eine mandantenübergreifende Anwendung an der Quelle des Anbieters kompromittiert und anschließend für den Zugriff auf nachgelagerte Mandanten verwendet worden.
Zu den Zielen gehörten laut Microsoft Schlüssel für Speicherkonten, Einstellungen und Zugangsdaten von App Service, Verbindungszeichenfolgen sowie Verbindungen und Datenspeicher für KI und maschinelles Lernen. Auch Benutzerzugangsdaten für Azure Kubernetes Service waren betroffen. Bei Folgezugriffen nennt Microsoft Azure Key Vault, Storage Accounts, Azure AI, Azure DevOps, SharePoint und OneDrive. Die Aktivitäten in SharePoint und OneDrive umfassten demnach Dateidownloads und den Zugriff auf Postfachelemente; Anfragen über Microsoft Graph dienten in manchen Mandanten überwiegend der Suche nach relevanten Inhalten.
Drei getrennte Wiederholungen an Azure-APIs
Microsoft beschrieb drei einzelne Abläufe: Auf eine fehlgeschlagene Anfrage mit HTTP-Status 400 folgte jeweils eine geänderte Anfrage, die den Status 200 zurückgab. Die angegebenen Zeitabstände beziehen sich auf unterschiedliche Dienste und Anfragen.
| Anfrage | Ungefährer Abstand bis zum erneuten Versuch | Erste Anfrage | Erneuter Versuch |
| Metadaten in Azure Key Vault | 28 Sekunden | HTTP 400 | HTTP 200; ARM-API-Version 2023-07-01 |
| Firewallregel für Azure SQL | 60 Sekunden | HTTP 400 | HTTP 200 |
| Abfrage in Application Insights | 80 Sekunden | HTTP 400 | HTTP 200 |
Welche Abwehrmaßnahmen Microsoft empfiehlt
Eine öffentlich gelöschte Datei macht die darin enthaltene Zugangsinformation nicht ungültig. Microsoft empfiehlt, offengelegte Zugangsdaten umgehend zu widerrufen oder zu rotieren und ihre bisherige Verwendung zu prüfen. Sicherheitsteams sollten außerdem Anwendungsgeheimnisse, Zertifikate oder föderierte Zugangsdaten entfernen, die ein Angreifer hinzugefügt haben könnte, sowie Geheimnisse in erreichbaren Key Vaults austauschen. Für Service Principals empfiehlt Microsoft die geringstmöglichen Berechtigungen.
Wird ein Zugangsschlüssel öffentlich, ist er erst nach Widerruf oder Rotation außer Kraft.
Bei der Suche nach Folgeaktivität empfiehlt Microsoft, Anmelde- und Überwachungsprotokolle zusammen auszuwerten: dazu zählen Anmeldungen von Service Principals und nicht interaktiven Konten, Azure Activity, Diagnoseprotokolle für Key Vault und Storage, Entra-Auditdaten sowie die einheitlichen Überwachungsprotokolle von Azure DevOps und Microsoft 365. Als Verhaltenshinweise nennt Microsoft unter anderem eine einzelne IP-Adresse, die sich mit gemischtem Erfolg bei mindestens drei Service Principals anmeldet, und eine Anwendung, die in kurzer Zeit Zugriffstoken für mehrere Cloud-Dienste anfordert. IP-Adressen und User-Agent-Kennungen können sich ändern.
Microsoft führte 199.19.77[.]84 und 199.19.77[.]18 als wichtigste Quellen der Anmeldungen auf. Die zweite Adresse ist laut Microsoft ein Tor-Ausgangsknoten und kann auch mit unabhängiger Aktivität zusammenhängen. Für eine Conditional-Access-Sperre der Adresse 199.19.77[.]84/32 bei Workload-Identitäten ist Workload ID Premium erforderlich; sie gilt nur für Single-Tenant-Anwendungen, die im eigenen Mandanten registriert sind. Bereits ausgegebene Zugriffstoken bleiben bis zu ihrem Ablauf gültig.
Ein anderer Weg: Geheimnisse in Claude-Code-Einstellungen
SavvyNik berichtete am 7. November in einem englischsprachigen Video über einen separaten Fall zu Claude Code und berief sich dabei auf Apiiro. Demnach konnten Befehle mit Passwörtern oder API-Schlüsseln über die Einstellung „Don't Ask Again“ in lokalen JSON-Konfigurationsdateien gespeichert und später in öffentliche GitHub-Repositories übertragen werden. SavvyNik nannte Apiiro zugeschriebene Zahlen von mehr als 1.100 öffentlichen Kopien mit mindestens einem Geheimnis sowie 2.539 echten Geheimnissen in rund 2.000 öffentlichen Repositories.
Bei ARTEX ging es laut Microsoft um die Suche nach bereits offengelegten Geheimnissen. Der Claude-Code-Bericht beschreibt dagegen Zugangsdaten, die durch veröffentlichte lokale Konfigurationsdateien öffentlich wurden.
