Az - Geräte-Registrierung

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

Wenn sich ein Gerät bei AzureAD anmeldet, wird in AzureAD ein neues Objekt erstellt.

Beim Registrieren eines Geräts wird der Benutzer aufgefordert, sich mit seinem Konto anzumelden (MFA wird bei Bedarf abgefragt), anschließend werden Tokens für den device registration service angefordert und schließlich eine abschließende Bestätigungsaufforderung angezeigt.

Dann werden auf dem Gerät zwei RSA-Schlüsselpaar erzeugt: Der device key (public key), der an AzureAD gesendet wird, und der transport key (private key), der, wenn möglich, im TPM gespeichert wird.

Dann wird das object in AzureAD erzeugt (nicht in Intune) und AzureAD gibt dem Gerät ein von ihr signiertes certificate zurück. Sie können prüfen, ob das device AzureAD joined ist und Informationen über das certificate (z. B. ob es durch TPM geschützt ist).:

dsregcmd /status

Nach der Geräte-Registrierung wird ein Primary Refresh Token vom LSASS CloudAP-Modul angefordert und dem Gerät übergeben. Mit dem PRT wird außerdem der Sitzungsschlüssel geliefert, verschlüsselt so dass nur das Gerät ihn entschlüsseln kann (unter Verwendung des public key des transport key) und er ist notwendig, um das PRT zu verwenden.

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

Az - Primary Refresh Token (PRT)

TPM - Trusted Platform Module

Der TPM schützt vor der Schlüssel-Extraktion von einem ausgeschalteten Gerät (falls durch PIN geschützt) und davor, privates Material aus der OS-Ebene zu extrahieren.
Er schützt jedoch nicht vor dem Sniffing der physischen Verbindung zwischen TPM und CPU oder davor, das kryptographische Material im TPM zu verwenden, während das System läuft, aus einem Prozess mit SYSTEM-Rechten.

Wenn Sie die folgende Seite prüfen, sehen Sie, dass das Stehlen des PRT genutzt werden kann, um wie der Benutzer auf Ressourcen zuzugreifen — was problematisch ist, weil das PRT auf Geräten gespeichert ist, sodass es von diesen gestohlen werden kann (oder, falls nicht gestohlen, missbraucht werden kann, um neue Signing-Keys zu erzeugen):

Az - Primary Refresh Token (PRT)

Registrierung eines Geräts mit SSO-Tokens

Es wäre für einen Angreifer möglich, ein Token für den Microsoft device registration service vom kompromittierten Gerät anzufordern und das Gerät zu registrieren:

# 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

Was dir ein Zertifikat gibt, das du verwenden kannst, um künftig PRTs anzufordern. Dadurch wird Persistenz aufrechterhalten und bypassing MFA, weil das ursprüngliche PRT-Token, das zur Registrierung des neuen Geräts verwendet wurde, bereits MFA-Berechtigungen hatte.

Tip

Beachte, dass du für die Durchführung dieses Angriffs Berechtigungen zum Registrieren neuer Geräte benötigst. Außerdem bedeutet das Registrieren eines Geräts nicht automatisch, dass das Gerät in Intune eingeschrieben werden darf.

Caution

Dieser Angriff wurde im September 2021 behoben, da man neue Geräte nicht mehr mit SSO tokens registrieren kann. Es ist jedoch weiterhin möglich, Geräte auf legitime Weise zu registrieren (mit Benutzername, Passwort und ggf. MFA). Check: roadtx.

Überschreiben eines Gerätetickets

Es war möglich, ein device ticket anzufordern, das aktuelle des Geräts zu überschreiben und während des Ablaufs das PRT zu stehlen (es ist also nicht nötig, es aus dem TPM zu stehlen). Für mehr Infos check this talk.

Caution

Dies wurde jedoch behoben.

Überschreiben des WHFB-Schlüssels

Check the original slides here

Angriffsübersicht:

  • Es ist möglich, den registrierten WHFB-Schlüssel eines Geräts per SSO zu überschreiben
  • Er umgeht den TPM-Schutz, da der Schlüssel während der Erzeugung des neuen Schlüssels abgefangen wird
  • Das verschafft außerdem Persistenz

Benutzer können ihre eigene searchableDeviceKey-Eigenschaft über den Azure AD Graph ändern, jedoch muss der Angreifer ein Gerät im Tenant haben (on-the-fly registriert oder mit gestohlenem cert + key von einem legitimen Gerät) und ein gültiges Access-Token für den AAD Graph.

Dann kann ein neuer Schlüssel mit folgendem Befehl generiert werden:

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

und dann mittels PATCH die Informationen des searchableDeviceKey aktualisieren:

Es ist möglich, ein access token von einem Benutzer über device code phishing zu erhalten und die vorherigen Schritte zu missbrauchen, um seinen Zugriff zu stehlen. Für weitere Informationen siehe:

Az - Primary Refresh Token (PRT)

Quellen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks