Entra ID (Azure AD) Angriffe — Token Theft, PRT & Conditional Access Bypass

Token-basierte Angriffe — MFA ist nicht das Ende der Fahnenstange

Die größte Bedrohung für Entra ID im Jahr 2026 sind Token-Theft-Angriffe, die MFA vollständig umgehen. Das Grundprinzip: Nach erfolgreicher Authentifizierung (inkl. MFA) erhält der Benutzer OAuth-Tokens (Access Token, Refresh Token, ID Token). Wer eines dieser Tokens stiehlt, kann sich als der Benutzer ausgeben — ohne das Passwort oder den MFA-Faktor zu kennen. Die häufigsten Token-Theft-Methoden: Adversary-in-the-Middle (AitM) mit Tools wie EvilGinx2 oder Modlishka — ein Reverse-Proxy, der die echte Microsoft-Loginseite spiegelt, die Credentials und die Session-Cookies/Tokens im Transit abfängt. Der Benutzer merkt nichts — er sieht die echte Microsoft-Seite, gibt sein Passwort ein, bestätigt MFA, und der Angreifer erhält das resultierende Token.

Der Primary Refresh Token (PRT) ist das wertvollste Token in der Entra-ID-Architektur: Es ist ein langlebiger Token (14 Tage Gültigkeit, automatisch erneuert), der SSO für alle Microsoft-Cloud-Dienste ermöglicht — ein kompromittierter PRT gewährt Zugriff auf alles, was der Benutzer nutzt: Microsoft 365, Azure Portal, verbundene SaaS-Apps. Auf Windows-Geräten wird der PRT im TPM gespeichert und durch den CloudAP-Broker verwaltet. Angriffstechniken: PRT-Extraction mit Mimikatz oder AADInternals (erfordert SYSTEM-Rechte auf dem Gerät), PRT Cookie Injection (der extrahierte PRT wird in einen Browser-Cookie umgewandelt, der auf einem anderen Gerät funktioniert). Microsoft hat als Gegenmaßnahme Token Protection (Preview 2025) eingeführt, das Tokens kryptographisch an das Gerät bindet — aber die vollständige Durchsetzung erfordert managed Devices mit TPM 2.0.

• AitM Phishing mit EvilGinx2 (Technik): EvilGinx2 operiert als transparenter Reverse-Proxy zwischen Benutzer und Microsoft-Login. Der Angreifer registriert eine ähnliche Domain (z. B. login-microsoftonline.com), sendet eine Phishing-E-Mail mit einem Link, der Benutzer landet auf der EvilGinx-Seite, die die echte login.microsoftonline.com spiegelt. Der Benutzer gibt Passwort + MFA ein, EvilGinx leitet alles an Microsoft weiter und fängt das resultierende Session-Cookie und Access/Refresh-Token ab. Verteidigung: Passkeys/FIDO2 (Origin-gebunden, funktioniert nicht auf der Fake-Domain), Conditional Access mit compliant Device (der Angreifer kann das Token nicht von seinem Gerät nutzen), Continuous Access Evaluation (CAE) für schnelle Token-Revocation.
• Device Code Phishing (OAuth Device Flow): Ein raffinierter Angriff, der keinen Reverse-Proxy benötigt: Der Angreifer initiiert einen OAuth Device Code Flow (legitimes Protokoll für Geräte ohne Browser, z. B. Smart-TVs). Dabei generiert er einen Device Code und sendet diesen per Phishing an das Opfer: „Geben Sie den Code ABCD-1234 auf microsoft.com/devicelogin ein, um Ihr Konto zu verifizieren.“ Der Benutzer öffnet die echte Microsoft-Seite (kein Fake!), gibt den Code ein, authentifiziert sich mit MFA — und der Angreifer erhält das Refresh-Token. Besonders tückisch, weil der Benutzer auf der echten Microsoft-Domain ist.
• Stolen Token Replay — was der Angreifer damit macht: Mit einem gestohlenen Access-Token (1 Stunde gültig) oder Refresh-Token (bis zu 90 Tage): Microsoft Graph API — E-Mails lesen, OneDrive durchsuchen, Teams-Nachrichten abgreifen, SharePoint-Dokumente herunterladen. Azure Management API — wenn der Benutzer Azure-Rechte hat: VMs erstellen (Krypto-Mining), Storage Accounts durchsuchen, Key Vaults auslesen. Lateral Movement — OAuth-Token für verbundene SaaS-Apps (Salesforce, ServiceNow, Workday) anfordern über SSO. Tools: ROADtools (komplettes Entra-ID-Enumeration-Framework), TokenTactics (Token-Manipulation und -Replay).
• Continuous Access Evaluation (CAE): Microsofts wichtigste Verteidigung gegen Token-Theft seit 2024: CAE ermöglicht es Entra ID, Access-Tokens in Echtzeit zu widerrufen — normalerweise sind Access-Tokens bis zu ihrem Ablauf (1 Stunde) gültig, auch wenn der Benutzer gesperrt wird. Mit CAE wird der Resource-Provider (Exchange, SharePoint, Teams) bei kritischen Ereignissen sofort benachrichtigt: Benutzer deaktiviert, Passwort geändert, Standortänderung, IP-Änderung außerhalb des Conditional-Access-Bereichs. Einschränkung: CAE unterstützt nur First-Party-Microsoft-Apps — Third-Party-SaaS-Apps müssen CAE separat implementieren.

Consent & Federation Attacks — die unsichtbaren Backdoors

Illicit Consent Grant (auch „OAuth App Consent Phishing“) ist eine der elegantesten Angriffstechniken auf Entra ID: Der Angreifer erstellt eine bösartige Azure-AD-Anwendung (Multi-Tenant App) und sendet dem Opfer einen OAuth-Consent-Link. Der Benutzer wird auf die echte Microsoft-Consent-Seite weitergeleitet und soll der App Berechtigungen erteilen (z. B. „Mail.Read“, „Files.ReadWrite“, „User.Read“). Klickt der Benutzer auf „Akzeptieren“, erhält die Angreifer-App einen dauerhaften API-Zugriff auf das Konto des Benutzers — kein Passwort gestohlen, keine MFA umgangen, kein Malware installiert. Der Zugriff bleibt bestehen, bis der Consent widerrufen wird — was oft Monate dauert, da der Angriff in den Audit-Logs schwer zu erkennen ist.

• Midnight Blizzard (SolarWinds/Nobelium) Technik: Die russische APT-Gruppe Midnight Blizzard (ehemals Nobelium/COZY BEAR) nutzte 2023/2024 eine Kombination aus OAuth App Consent + Teams-Phishing: Sie kompromittierten kleine Unternehmen, erstellten dort Azure-AD-Apps mit vertrauenswürdigen Namen („Tailored Access Operations“), und nutzten Microsoft Teams, um Mitarbeitern großer Unternehmen Consent-Links zu senden. Da Teams-Nachrichten von „verifizierten Organisationen“ kamen, war die Akzeptanzrate hoch. Verteidigung: Admin Consent Workflow aktivieren (Benutzer können keine Apps selbst genehmigen), Enterprise App Registrations auf „Admin only“ setzen.
• Federation Trust Abuse (Golden SAML 2.0): Wenn ein Unternehmen Federation zwischen Entra ID und einem On-Premises Identity Provider (AD FS, PingFederate, Okta) konfiguriert hat, kann ein Angreifer, der den Token-Signing-Schlüssel des Federation-Servers stiehlt, beliebige SAML-Tokens fälschen — für jeden Benutzer, inklusive Global Admin. Dies war der Kernmechanismus des SolarWinds-Angriffs (2020). 2026-Empfehlung: Migrieren Sie von AD FS zu Entra ID Cloud Authentication (Password Hash Sync + Seamless SSO oder Pass-Through Authentication) — damit gibt es keinen Federation-Server mehr, dessen Schlüssel gestohlen werden könnte.
• Service Principal Abuse: Service Principals (Enterprise Applications) in Entra ID haben oft übermäßige Berechtigungen: Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Application.ReadWrite.All. Ein Angreifer, der die Client-Secret oder das Zertifikat eines solchen Service Principals kompromittiert (z. B. aus einem Git-Repository, einem Azure DevOps-Pipeline-Log oder einem ungeschützten Key Vault), erhält programmatischen Zugriff auf das gesamte Tenant — ohne Benutzerinteraktion, ohne MFA, ohne Conditional Access (da Service Principals standardmäßig von CAP ausgenommen sind). Lösung: Workload Identity Conditional Access (seit 2024), Managed Identities statt Client Secrets, regelmäßige Credential Rotation.
• Cross-Tenant-Synchronisation als Backdoor: Entra ID ermöglicht Cross-Tenant Synchronization — ein Feature für Multi-Tenant-Organisationen. Ein Angreifer mit Global-Admin-Rechten kann eine Cross-Tenant-Sync-Beziehung zu einem von ihm kontrollierten Tenant einrichten: Damit werden Benutzerkonten aus dem Angreifer-Tenant automatisch in den Opfer-Tenant synchronisiert — inklusive Gruppenmitgliedschaften und Rollen. Eine nahezu unsichtbare Backdoor, die schwer zu erkennen ist, da Cross-Tenant-Sync ein legitimes Feature ist. Erkennung: Regelmäßige Überprüfung der Entra Admin Center → External Identities → Cross-Tenant Access Settings.

Entra ID Hardening 2026 — die Verteidigungsarchitektur

Eine robuste Entra-ID-Sicherheitsarchitektur 2026 basiert auf mehreren Verteidigungsschichten: Conditional Access Policies (CAP) als zentrale Steuerungsebene — jeder Zugriff wird anhand von Bedingungen (Benutzer, Gerät, Standort, Risiko, App) bewertet und nur bei Erfüllung aller Kriterien gewährt. Die wichtigsten Conditional-Access-Policies: Require MFA for all users (Basis), Require compliant device (für sensible Apps — der Token funktioniert nur auf verwalteten Geräten), Require phishing-resistant MFA for admins (Passkeys/FIDO2 oder Certificate-based Auth — kein SMS, kein App-Notification), Block legacy authentication (IMAP, POP3, SMTP Auth — unterstützen kein MFA), Named Locations (Zugriff nur von bestimmten IP-Ranges/Ländern).

• Privileged Identity Management (PIM): Entra ID PIM implementiert Just-in-Time-Zugriff für privilegierte Rollen: Global Admin, Exchange Admin, SharePoint Admin etc. werden nicht permanent zugewiesen, sondern müssen bei Bedarf für einen definierten Zeitraum (z. B. 4 Stunden) aktiviert werden. Aktivierung erfordert: MFA-Bestätigung, Begründung, optionale Manager-Genehmigung. Emergency Access Accounts (Break-Glass): 2 Cloud-only-Accounts mit Global Admin, ohne MFA, mit extremem langen Passwort (40+ Zeichen), physisch im Tresor verwahrt. Conditional Access Policy: Nur von bestimmten IPs zulässig. Monitoring: Jede Nutzung löst sofort einen Alarm aus.
• Entra ID Identity Protection: ML-basierte Risikobewertung für jede Anmeldung: Sign-In Risk (Echtzeit — atypischer Standort, anonyme IP, Malware-verknüpfte IP, Token-Anomalie, AitM-Erkennung) und User Risk (offline berechnet — geleakte Credentials, anomales Benutzerverhalten). Conditional Access Policies können auf Risikostufen reagieren: Medium Risk → MFA erzwingen, High Risk → Passwortänderung erzwingen oder Zugriff blockieren. Wichtig: Alle Risikostufen automatisch remediieren — nicht nur „Review“ — denn in der Praxis werden manuelle Reviews oft nicht zeitnah durchgeführt.
• Token Protection & Global Secure Access: Token Protection (Token Binding): Bindet Access-Tokens kryptographisch an das Gerät — ein gestohlenes Token funktioniert nicht auf einem anderen Gerät. Voraussetzung: Windows 10/11 mit TPM, Entra-joined oder Hybrid-joined. Global Secure Access (Entra Internet Access + Private Access): Microsofts SSE-Lösung (Security Service Edge), die den gesamten Datenverkehr über Microsofts globales Netzwerk tunnelt. Ermöglicht Source-IP-Restoration für Conditional Access (auch hinter NAT sehen Sie die echte Client-IP), Universal CAP (Conditional Access für alle Apps, nicht nur Microsoft-Apps) und Token-Protection für alle Geräte.
• Monitoring & Detection (Entra ID Audit/Sign-In Logs): Kritische Log-Events, die Sie überwachen müssen: Consent to application (OAuth App Consent — Illicit Consent Grant Detection), Add service principal credentials (neue Secrets/Zertifikate für bestehende Apps), Update application (Redirect-URI-Änderungen), Add federated identity credential (neue Federation-Trusts), New Cross-Tenant Access Policy, PIM role activation (insbesondere Global Admin). Export: Diagnostic Settings → Log Analytics Workspace / Microsoft Sentinel → SIEM-Integration. Microsoft Sentinel bietet über 50 vorgefertigte Entra-ID-Detection-Rules.