Az - Device Registration

Unterstütze HackTricks

Grundlegende Informationen

Wenn ein Gerät AzureAD beitritt, wird ein neues Objekt in AzureAD erstellt.

Bei der Registrierung eines Geräts wird der Benutzer aufgefordert, sich mit seinem Konto anzumelden (bei Bedarf mit MFA), dann werden Token für den Geräteregistrierungsdienst angefordert und schließlich eine letzte Bestätigungsaufforderung gestellt.

Dann werden im Gerät zwei RSA-Schlüsselpaaren generiert: Der Geräteschlüssel (öffentlicher Schlüssel), der an AzureAD gesendet wird, und der Transportschlüssel (privater Schlüssel), der, wenn möglich, im TPM gespeichert wird.

Dann wird das Objekt in AzureAD (nicht in Intune) generiert und AzureAD gibt dem Gerät ein von ihm signiertes Zertifikat zurück. Du kannst überprüfen, dass das Gerät AzureAD beigetreten ist und Informationen über das Zertifikat (wie ob es durch TPM geschützt ist) einsehen.:

dsregcmd /status

Nach der Geräte-Registrierung wird ein Primary Refresh Token vom LSASS CloudAP-Modul angefordert und dem Gerät zugewiesen. Mit dem PRT wird auch der Sitzungsschlüssel verschlüsselt geliefert, sodass nur das Gerät ihn entschlüsseln kann (unter Verwendung des öffentlichen Schlüssels des Transportschlüssels) und er wird benötigt, um das PRT zu verwenden.

Für weitere Informationen darüber, was ein PRT ist, siehe:

Az - Primary Refresh Token (PRT)

TPM - Trusted Platform Module

Das TPM schützt vor der Extraktion von Schlüsseln aus einem ausgeschalteten Gerät (wenn durch PIN geschützt) und vor der Extraktion des privaten Materials aus der Betriebssystemschicht. Aber es schützt nicht vor dem Abhören der physischen Verbindung zwischen dem TPM und der CPU oder der Verwendung des kryptografischen Materials im TPM, während das System von einem Prozess mit SYSTEM-Rechten läuft.

Wenn du die folgende Seite überprüfst, wirst du sehen, dass das Stehlen des PRT verwendet werden kann, um wie der Benutzer zuzugreifen, was großartig ist, weil das PRT sich auf Geräten befindet, sodass es von ihnen gestohlen werden kann (oder wenn nicht gestohlen, missbraucht werden kann, um neue Signaturschlüssel zu generieren):

Az - Pass the PRT

Registrierung eines Geräts mit SSO-Tokens

Es wäre möglich, dass ein Angreifer ein Token für den Microsoft-Geräteregistrierungsdienst vom kompromittierten Gerät anfordert und es registriert:

# Initialize SSO flow
roadrecon auth prt-init
.\ROADtoken.exe <nonce>

# Request token with PRT with PRT cookie
roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>

# Custom pyhton script to register a device (check roadtx)
registerdevice.py

Welches Ihnen ein Zertifikat gibt, das Sie in Zukunft verwenden können, um PRTs anzufordern. Dadurch wird Persistenz aufrechterhalten und MFA umgangen, da das ursprüngliche PRT-Token, das zur Registrierung des neuen Geräts verwendet wurde, bereits MFA-Berechtigungen erteilt hatte.

Beachten Sie, dass Sie für diesen Angriff Berechtigungen zum Registrieren neuer Geräte benötigen. Außerdem bedeutet die Registrierung eines Geräts nicht, dass das Gerät in Intune aufgenommen werden darf.

Dieser Angriff wurde im September 2021 behoben, da Sie keine neuen Geräte mehr mit SSO-Tokens registrieren können. Es ist jedoch weiterhin möglich, Geräte auf legitime Weise zu registrieren (mit Benutzername, Passwort und MFA, falls erforderlich). Überprüfen Sie: roadtx.

Überschreiben eines Gerätetickets

Es war möglich, ein Geräteticket anzufordern, das aktuelle des Geräts zu überschreiben und während des Ablaufs das PRT zu stehlen (es ist also nicht notwendig, es aus dem TPM zu stehlen). Weitere Informationen finden Sie in diesem Vortrag.

Dies wurde jedoch behoben.

WHFB-Schlüssel überschreiben

Überprüfen Sie hier die Originalfolien

Angriffszusammenfassung:

  • Es ist möglich, den registrierten WHFB-Schlüssel eines Geräts über SSO zu überschreiben

  • Es umgeht den TPM-Schutz, da der Schlüssel während der Generierung des neuen Schlüssels abgefangen wird

  • Dies bietet auch Persistenz

Benutzer können ihre eigene searchableDeviceKey-Eigenschaft über den Azure AD Graph ändern, jedoch muss der Angreifer ein Gerät im Mandanten haben (registriert im Handumdrehen oder gestohlenes Zertifikat + Schlüssel von einem legitimen Gerät) und ein gültiges Zugriffstoken für den AAD Graph.

Dann ist es möglich, einen neuen Schlüssel zu generieren mit:

roadtx genhellokey -d <device id> -k tempkey.key

und dann die Informationen des searchableDeviceKey PATCHen:

Es ist möglich, ein Zugriffstoken von einem Benutzer über device code phishing zu erhalten und die vorherigen Schritte zu missbrauchen, um seinen Zugriff zu stehlen. Weitere Informationen finden Sie unter:

Az - Phishing Primary Refresh Token (Microsoft Entra)

Referenzen

Unterstützen Sie HackTricks

Last updated