In der Cloud-Identitaetsplattform Microsoft Entra ID ist eine Sicherheitsluecke entdeckt worden, die unter bestimmten Bedingungen zur kompletten Uebernahme privilegierter Konten fuehren konnte. Betroffen war die neue privilegierte Rolle Agent ID Administrator, die eigentlich nur fuer die Verwaltung von AI-Agenten-Identitaeten vorgesehen ist, tatsaechlich aber Zugriff farblich ueber ihr Ziel hinaus erhielt.
Agent Identity in Microsoft Entra ID und die Rolle Agent ID Administrator
Mit der Plattform agent identity erweitert Microsoft Entra ID seine Faehigkeiten um AI-Agenten: nicht-menschliche Identitaeten, die von Anwendungen, Services oder Automatisierungen genutzt werden. Diese Agenten muessen sich authentifizieren, Berechtigungen erhalten und sicher mit Ressourcen und anderen Agenten innerhalb eines Mandanten (Tenant) interagieren koennen.
Die Rolle Agent ID Administrator wurde als integrierte, privilegierte Rolle eingefuehrt, die den gesamten Lebenszyklus dieser AI-Agenten-Identitaeten abdeckt: Erstellung, Aktualisierung, Verwaltung von Schluesseln und weiteren Anmeldeinformationen. Vom Design her sollten sich die Rechte dieser Rolle strikt auf diese spezialisierten Agentenidentitaeten beschraenken.
Technische Analyse: Fehlkonfiguration des Rollen-Scopes fuehrt zu Privilegieneskalation
Sicherheitsforscher von Silverfort stellten fest, dass der Scope der Rolle Agent ID Administrator zu weit gefasst war. Statt nur auf Agenten-Identitaeten beschraenkt zu sein, konnte die Rolle auf beliebige Service Principals zugreifen – also auf jene speziellen Konten, die Anwendungen und Dienste fuer den Zugriff auf Cloud-Ressourcen verwenden.
Laut der Analyse konnte ein Benutzer mit der Rolle Agent ID Administrator sich selbst als Owner eines beliebigen Service Principal eintragen, auch wenn dieser nichts mit AI-Agenten zu tun hatte. Anschliessend war es moeglich, eigene Schluessel oder Zertifikate als Anmeldeinformationen zu hinterlegen und sich damit im Namen dieses Service Principals zu authentifizieren. Praktisch entsprach dies einer vollstaendigen Kontouebernahme mitsamt aller bereits zugewiesenen Berechtigungen in Microsoft Entra ID.
Besonders kritisch wurde diese Schwachstelle, wenn der betroffene Service Principal bereits hochprivilegierte Rechte besass – etwa Mitgliedschaft in privilegierten Verzeichnisrollen oder weitreichende Microsoft-Graph-Berechtigungen. In diesem Fall konnte ein Angreifer die Luecke zur Privilegieneskalation nutzen und schrittweise die Kontrolle ueber weitere Ressourcen und Identitaeten im Tenant ausbauen.
Warum kompromittierte Service Principals ein hohes Risiko darstellen
In modernen Cloud-Umgebungen sind Service Principals ein zentrales Element fuer Automatisierung, CI/CD-Pipelines, SaaS-Integrationen, Backup-Loesungen und geschäftskritische Anwendungen. Aus Praktikabilitaetsgruenden erhalten diese Konten in vielen Organisationen breitere Rechte als menschliche Benutzer, um stoerungsfreie Prozesse zu gewaehren.
Wird ein solcher Service Principal kompromittiert, erhaelt der Angreifer typischerweise Zugriff auf dieselben Daten und Operationen wie die legitime Anwendung: von der Konfigurationsaenderung im Verzeichnis ueber den Zugriff auf E-Mails, Kalender und Dateien bis hin zu Geheimnissen in Key Vaults. Studien wie der Verizon Data Breach Investigations Report zeigen seit Jahren, dass der Missbrauch von Anmeldeinformationen zu den haeufigsten Angriffsvektoren gehoert; nicht-menschliche Identitaeten sind dabei besonders attraktiv, weil sie oft weniger streng ueberwacht werden.
In Kombination mit Rechten zum Verwalten weiterer Identitaetsobjekte entstehen stabile Vektoren fuer laterale Bewegung und Persistence. Ein Angreifer kann neue Zugangspfade schaffen, Logs manipulieren, weitere privilegierte Konten kompromittieren und sich langfristig in der Infrastruktur verankern.
Reaktion von Microsoft und aktuelle Bewertung der Schwachstelle
Silverfort meldete die Schwachstelle Microsoft am 1. Maerz 2026 im Rahmen eines verantwortungsvollen Offenlegungsprozesses. Nach der Analyse stellte Microsoft am 9. April 2026 ein globale Fix in allen betroffenen Cloud-Umgebungen bereit, der den unzureichend begrenzten Scope der Rolle Agent ID Administrator korrigiert.
Seit diesem Update wird jeder Versuch, mit der Rolle Agent ID Administrator die Eigentuemerschaft eines nicht-_agentischen_ Service Principal zu ueberschreiben, mit HTTP 403 Forbidden blockiert. Damit ist der direkte Angriffsweg geschlossen. Das Restrisiko haengt jedoch weiterhin stark von der generellen Sicherheitslage des Tenants ab – insbesondere von der Anzahl und den Rechten existierender, hochprivilegierter Service Principals und der bisherigen Verwaltung ihrer Anmeldeinformationen.
Best Practices: So reduzieren Organisationen Risiken in Microsoft Entra ID
1. Nutzung sensibler Rollen konsequent ueberwachen. Aktionen rund um Service-Principals, insbesondere Aenderungen an Ownern und Anmeldeinformationen, sollten engmaschig protokolliert und durch automatisierte Alarme begleitet werden. Ungewoehnliche Zuweisungen an Rollen wie Agent ID Administrator sind ein wichtiger Indikator fuer Missbrauch.
2. Eigentuemer und Berechtigungen von Service Principals regelmaessig pruefen. Jede Aenderung der Owner-Struktur – vor allem ausserhalb eines kleinen, vertrauenswuerdigen Administratorenkreises – sollte zeitnah nachvollzogen und verifiziert werden. Ein formalisierter Freigabeprozess hilft, Fehlkonfigurationen fruehzeitig zu erkennen.
3. Privilegierte Service Principals absichern. Rechte sollten strikt nach dem Least-Privilege-Prinzip vergeben werden. Dazu gehoeren regelmaessige Berechtigungsreviews, Entfernung ungenutzter Rechte, die Nutzung sicherer Secret-Stores fuer Schluessel und Zertifikate sowie – wo moeglich – der Einsatz von kurzlebigen Anmeldeinformationen und Managed Identities.
4. Erstellung und Aktualisierung von Credentials auditieren. Die Protokollierung in Microsoft Entra ID und die Integration in ein zentrales SIEM sollten ermoeglichen, die Erstellung, Rotation und Loeschung von Schluesseln, Zertifikaten und Passwoertern transparent nachzuvollziehen. Auffaellige Muster, wie haeufige Credential-Rotationen oder das Hinzufuegen zusaetzlicher Schluessel, muessen untersucht werden.
5. Rollenarchitektur fuer nicht-menschliche Identitaeten schaerfen. Neue Identitaetstypen wie AI-Agenten sollten nicht unreflektiert auf bestehenden Mechanismen wie Service Principals aufsetzen, ohne eine klare Trennung der Rechte zu implementieren. Security-Design-Reviews vor Rollout neuer Funktionen sind hier entscheidend.
Die entdeckte Schwachstelle in der Rolle Agent ID Administrator fuehrt deutlich vor Augen, wie sensibel das Zusammenspiel von Rollen, Berechtigungen und nicht-menschlichen Identitaeten in der Cloud ist. Organisationen sollten die Gelegenheit nutzen, ihre Rollen- und Rechtearchitektur in Microsoft Entra ID kritisch zu ueberpruefen, Logging und Monitoring gezielt auf Service Principals und AI-Agenten auszurichten und interne Prozesse fuer Berechtigungsreviews zu etablieren. Wer fruehzeitig in robuste Kontrollen investiert, reduziert nicht nur das Risiko aehnlicher Zero-Day-Effekte, sondern schafft die Grundlage fuer ein belastbares Identitaets- und Zugriffsmanagement in einer zunehmend automatisierten, AI-getriebenen Infrastruktur.
