Drei Wochen Domain-Härtung, vierzig Minuten bis zum Global Admin
Die IT präsentiert ein sauberes Tiering-Modell, LAPS auf allen Clients, lange Mindestlänge für Admin-Konten, kein SMB-Signing deaktiviert, Alarmierung auf verdächtige Kerberos-Tickets. Das On-Prem-Active-Directory ist in einem Zustand, für den die meisten Unternehmen zwei Jahre brauchen. Nach anderthalb Tagen im internen Netz gibt es exakt null verwertbare Eskalation.
Also wechselt der Test die Ebene und zielt auf den Tenant, dort, wo die Identitäten tatsächlich leben. Der Entra ID Angriffspfad, den ein Pentest heute findet, beginnt selten bei einem Passwort und fast immer bei einem Objekt, das niemand mehr verwaltet. Die Enumeration läuft über die Microsoft Graph und die Azure REST APIs, mit AzureHound gesammelt und in BloodHound importiert, um Rollen, Besitzverhältnisse und Berechtigungsketten als Graph sichtbar zu machen.
Der Treffer heißt RPA-Rechnungsimport-TEST, angelegt 2021 von einem externen Dienstleister, der seit 2023 nicht mehr im Haus ist. Das Client-Secret ist abgelaufen. Die Berechtigungen nicht. Eigentümer des zugehörigen Service Principals ist ein Buchhaltungs-Konto ohne jede Admin-Rolle, das im Test über eine Phishing-Simulation bereits übernommen war. Genau dieser Weg findet sich in einer aufbereiteten Dokumenation darüber: Eigentümerschaft über einen privilegierten Service Principal genügt, um durch Hinzufügen eines neuen Client-Secrets in dessen Identität zu wechseln.
Der Rest ist Fleißarbeit. Neues Secret anlegen, als Service Principal authentifizieren, Rechte erben, einen Temporary Access Pass für ein Global-Admin-Konto ausstellen, im Azure-Portal anmelden. Gesamtdauer ab dem kompromittierten Buchhaltungskonto: in Etwa vierzig Minuten. Kein Hash, kein Cracking, kein Kerberoasting.
Die gesamte Kette lief ohne ein einziges geknacktes Passwort. Sie lief über Objektbesitz und API-Berechtigungen.
Entra ID ist kein Active Directory mit Weboberfläche
In Entra ID ist das Credential nur eine von mehreren Währungen. Daneben stehen Consent-Grants, Client-Secrets, Zertifikate, Rollenzuweisungen auf Dienstidentitäten und Eigentümerschaften. Alles davon ist API-erreichbar, alles davon überlebt einen Passwort-Reset.
Kompromittierte Zugangsdaten waren der initiale Vektor, und Microsoft begründet die verpflichtende MFA-Registrierung in den Security Defaults damit, dass MFA über 99,2 % der identitätsbasierten Angriffe blockiert. Trotzdem griff Storm-0558 ab Mai 2023 auf E-Mail-Konten von rund 25 Organisationen zu, darunter Regierungsbehörden, und zwar mit gefälschten Tokens statt mit Passwörtern. Die Breite des Themas zeigt auch die Stichprobe des Penetration Testing Intelligence Report 2026 mit 531.770 Schwachstellen aus 4.970 Pentests.
Dazu kommt der Zeitdruck aus der Stadt Redmond. Ab dem 1. Februar 2026 erzwingt Microsoft MFA für administrative Rollen, und für neue Tenants werden Legacy-Authentifizierungsprotokolle bereits ab dem 15. Januar 2026 abgeschaltet. Wer seine Conditional-Access-Richtlinien vorher nicht validiert, riskiert falsche Sicherheit. Regulatorisch zieht NIS2 in dieselbe Richtung: Nach § 30 Abs. 2 Satz 2 Nr. 9 BSIG müssen wichtige und besonders wichtige Einrichtungen Konzepte für Zugriffskontrolle und die Verwaltung von IKT-Systemen dokumentieren. Ein Zugriffskonzept, das App-Registrierungen nicht erwähnt, ist für einen NIS2-Nachweis unvollständig.
Entra ID Angriffspfad im Pentest: fünf Schritte ohne ein einziges Passwort
Schritt 1 ist der unscheinbarste. sog. Illicit Consent Grant bringt der Angreifer das Opfer dazu, einer bösartigen OAuth-App Zugriff auf dessen Daten zu gewähren, woraufhin die App kontoweiten Zugriff erhält, ohne dass je ein Organisationskonto-Passwort abgefragt wurde. Für den Nutzer sieht das aus wie jede andere Microsoft-Anmeldemaske. Für das SIEM sieht es aus wie ein erfolgreicher Login.
Schritt 5 ist der, über den sich Verteidiger am meisten ärgern. Conditional Access gilt vielerorts als Endkontrolle, lässt sich aber über Nested App Authentication mit den Parametern brk_client_id und brk_redirect_uri in einem ansonsten unauffälligen Token-Request umgehen. Der Request tarnt sich als Broker-Flow einer vertrauenswürdigen Host-App gegenüber login.microsoftonline.com.
User.ReadWrite.All oder Directory.ReadWrite.All zugestimmt worden war. Über diese Altlast erstellten sie einen neuen Nutzer-Account und erteilten sich im Tenant weitere Consents. Die Berechtigung war jahrelang gültig, aber nie entzogen worden.Unverwaltete App-Registrierungen sind dauerhafte Zugangswege, die weiter authentifizieren, lange nachdem das Team und der Geschäftszweck verschwunden sind.
Drei Sätze, die man immer wieder hört
- Adressiert Credential-Diebstahl, nicht Objektbesitz
- Consent-Grants liegen außerhalb des Tier-Modells
- Service Principals haben kein Passwort, das ablaufen könnte
- Abgelaufenes Secret bedeutet nicht entzogene Rechte
- Jeder Eigentümer kann ein neues Secret anlegen
- Genau dieser Weg traf Microsoft selbst
- Broker-Flows sehen aus wie legitime Anfragen
- App-Tokens interessieren sich nicht für Gerätekonformität
- Policies werden selten gegen aktuelle Bypässe getestet
Dass auch Microsoft an dieser Stelle nachbessern muss, zeigt ein Befund aus dem laufenden Jahr: Eine Schwachstelle in der Rolle „Agent ID Administrator“ erlaubte die vollständige Übernahme beliebiger Service Principals, indem der Angreifer Eigentümerschaft übernahm und eigene Credentials hinzufügte. Microsoft hat die Rolle inzwischen auf agentenbezogene Objekte beschränkt.
Das Muster bleibt dasselbe. Wer Objekte besitzt, besitzt Identitäten.
Deshalb gehört bei hybriden Umgebungen die Föderationsinfrastruktur in denselben Prüfumfang wie die Domain Controller. Die CISA hat für genau diese Schnittstelle die SCuBA Hybrid Identity Solutions Guidance veröffentlicht.
Was ihr im Tenant prüfen solltet
Die gute Nachricht: Fast alles davon ist Inventar- und Prozessarbeit, kein Produktkauf.
Die schlechte Nachricht: Niemand fühlt sich zuständig, weil App-Registrierungen zwischen IT-Betrieb, Entwicklung und Fachbereich liegen.
- Consent- und Owner-Inventar: Alle OAuth-Berechtigungen und alle Eigentümer von Service Principals auflisten. Besonders auffällig sind Standardnutzer, die Objekte mit Verzeichnisrechten besitzen.
- Lebenszyklus für App-Registrierungen: Owner-Pflicht, Ablaufüberwachung für Secrets, automatischer Entzug bei Nichtnutzung. Unverwaltete Registrierungen bleiben sonst als dauerhafte Zugangswege bestehen.
- Admin-Consent-Workflow: Endnutzer-Consent für Berechtigungen auf Verzeichnisdaten abschalten und Anfragen über einen Freigabeprozess leiten, damit ein Illicit Consent Grant nicht an einem einzigen Klick hängt.
- Conditional Access testen statt annehmen: Policies gegen bekannte Bypässe wie Nested App Authentication.
- MFA und Security Defaults: Für jede privilegierte Rolle erzwingen. Microsoft beziffert die Wirkung auf mehr als 99,2 % blockierter identitätsbasierter Angriffe.
- Föderation als Tier 0: AD-FS-Server wie Domain Controller behandeln und Token-Signing-Zertifikate rotieren.
Ein einziger gut gepflegter Report über Owner und Consents hätte im eingangs geschilderten Test die gesamte Kette unterbrochen. Setzt dafür einen festen Platz im Kalender: jedes Quartal.
Fragen, die CISOs zu Entra-ID-Pentests stellen
Kann man Conditional Access in Entra ID umgehen?
Ja, dokumentiert und ohne Exploit im klassischen Sinn. Über Nested App Authentication lässt sich ein Token-Austausch mit den Parametern brk_client_id und brk_redirect_uri durchführen, der wie eine normale Anfrage einer vertrauenswürdigen Host-App aussieht. Conditional Access ist deshalb eine Schutzschicht, aber keine letzte Verteidigungslinie.
Was ist ein Illicit Consent Grant?
Ein Angriff, bei dem ein Nutzer dazu gebracht wird, einer bösartigen OAuth-Anwendung Zugriff auf seine Daten zu erlauben. Die App erhält danach kontoweiten Zugriff, ohne dass ein Organisationskonto-Passwort benötigt wird. MFA greift nicht, weil der Nutzer sich regulär anmeldet und die Zustimmung bewusst erteilt.
Reicht MFA, um Entra ID abzusichern?
MFA ist die wirksamste Einzelmaßnahme und blockiert nach Microsoft Angaben über 99,2 % der identitätsbasierten Angriffe. Gegen übernommene Service Principals, erteilte Consents und gefälschte Tokens hilft sie jedoch nicht, da diese Pfade keine interaktive Nutzeranmeldung durchlaufen. Beides muss parallel kontrolliert werden.
Objektbesitz ist das neue Passwort
Der Pentest aus der Einleitung endete mit einem Bericht, in dem kein einziger gecrackter Hash stand. Das war für die IT-Leitung die unangenehmste Erkenntnis. Drei Jahre Arbeit am Active Directory waren richtig und haben trotzdem den Weg zum Global Admin nicht versperrt, weil dieser Weg durch einen Tenant führte, für den sich formal niemand zuständig fühlte.
Die großen Fälle folgen demselben Muster. Bei Midnight Blizzard war es eine Testanwendung mit nie entzogenen Graph-Berechtigungen, bei Storm-0558 ein Signierschlüssel, der in einem Crash-Dump landete. In beiden Fällen stand am Anfang ein übersehenes Objekt, kein Passwort.
- Scope erweitern: Wer nur On-Prem testen lässt, bekommt einen sauberen Bericht über die falsche Hälfte der Identitäten im Haus.
- Besitz ist Privileg: Jede Eigentümerschaft an einem Service Principal gehört in dieselbe Risikoklasse wie eine Admin-Rolle.
- Termin setzen: Consent- und App-Review quartalsweise, nicht anlassbezogen.
- Von der Phishing-Mail zur Domain Admin: der klassische On-Prem-Gegenpart zu diesem Angriffspfad
- MFA Bypass Techniken: warum ein zweiter Faktor allein keine Anmeldung schützt
- Verwaiste Zugänge als Dauerrisiko: dasselbe Problem, eine Ebene tiefer im Offboarding
Wisst ihr, wem eure Service Principals gehören?
Wenn Passwörter nicht mehr der Schwachpunkt sind, rücken Identitäten, überprivilegierte Service Principals und schlummernde Rechte in Entra ID in den Fokus. Wir decken eure versteckten Angriffspfade auf, bevor es andere tun.
Erstgespräch anfordern →
