Sicherheitslücke in Azure AD: Umgehung von Conditional Access durch Phantom-Geräte und PRT-Missbrauch

Technik und Auswirkungen

Azure AD Conditional Access umgangen Laut der umfassenden Recherche Operation mit gültigen Anmeldeinformationen, die explizit durch eine CA-Richtlinie blockiert wurden und somit den Fehler AADSTS53003 auslösten. Um dies zu umgehen, zielten die Forscher auf den DRS-Endpunkt über den Device Code Authentication Flow ab.

Dies war ein durch nicht durchgesetzte Sicherheitsrichtlinien offenes Fenster. Dies ermöglichte ihnen eine erfolgreiche Authentifizierung und den Übergang zur nächsten Angriffsphase. Mit einem einzigen Befehl registrierte das Howler Cell Team ein Phantomgerät mit einem signierten Azure AD-Zertifikat und einem privaten Schlüssel.

Die DRS-API überprüft nicht, ob der Aufrufer eine physische Windows-Maschine ist, wodurch ein Linux-Laptop als legitimer Endpunkt getarnt werden konnte. Dieser Schritt nutzte die MITRE ATT&CK-Technik für Account Manipulation (T1098.005).

Was die Studie zeigt

Nachdem das Phantom-Gerät registriert war, erstellten die Forscher ein Primary Refresh Token (PRT), das gefälschte Geräteangaben enthielt. Als dieses PRT gegen ein Access Token eingetauscht wurde, stellte Azure AD fest, dass die Sitzung geräteauthentifiziert war.

Dies umging vollständig die CA-Richtlinien, die ein konformes oder angeschlossenes Gerät erforderten, und gewährte Zugang zur erweiterten Tenant-Umgebung zur Verzeichnisenumerierung. Um Richtlinien zu umgehen, die streng ein Intune-konformes Gerät vorschreiben, nutzten die Forscher eine bekannte Lücke in den Intune-Enrollment-Beschränkungen aus.

Durch die Behauptung eines Hybrid-Domain-Join-Status umging das Phantom-Gerät die Anforderungen der Vorregistrierung. Kill Chain (Quelle: Cyderes) Intune vertraute der selbst deklarierten Domain-Mitgliedschaft des Clients, ohne diese gegenüber dem lokalen Active Directory zu überprüfen.

Technik und Auswirkungen

Nach der Anmeldung erreichte das Gerät die Konformität, obwohl es weder BitLocker, Secure Boot noch Antivirensoftware besaß.

Zu den entscheidenden Maßnahmen gehören: * Die Durchsetzung von „Report-only“ CA-Richtlinien, die Geräte-Code-Flüsse blockieren und für die Geräteregistrierung MFA vorschreiben. * Die Verpflichtung zur TPM 2.0-Attestierung als strikte Voraussetzung für die Ausstellung aller PRT. * Die Anforderung einer externen Validierung des Gerätezustands über den Microsoft Health Attestation Service, anstatt sich auf selbst gemeldete Daten zu verlassen. * Die Eingrenzung des Zugriffs auf die Graph API auf Benutzerebene, um eine unbefugte Massenverzeichnisenumerierung zu verhindern. * Die Beschränkung privilegierter Verzeichnisrollen ausschließlich auf Cloud-Konten, die über das Privileged Identity Management verwaltet werden.