mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/azure-security/az-device-registrat
This commit is contained in:
Translator
@@ -1,22 +1,22 @@
|
||||
# Az - Geräte Registrierung
|
||||
# Az - Geräte-Registrierung
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Grundlegende Informationen
|
||||
|
||||
Wenn ein Gerät AzureAD beitritt, wird ein neues Objekt in AzureAD erstellt.
|
||||
Wenn sich ein Gerät bei AzureAD anmeldet, wird in AzureAD ein neues Objekt erstellt.
|
||||
|
||||
Bei der Registrierung eines Geräts wird **der Benutzer aufgefordert, sich mit seinem Konto anzumelden** (bei Bedarf wird nach MFA gefragt), dann werden Tokens für den Geräte Registrierungsdienst angefordert und schließlich wird eine letzte Bestätigungsaufforderung angezeigt.
|
||||
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 zwei RSA-Schlüsselpaar in dem Gerät generiert: Der **Geräteschlüssel** (**öffentlicher** Schlüssel), der an **AzureAD** gesendet wird, und der **Transport**-Schlüssel (**privater** Schlüssel), der, wenn möglich, im TPM gespeichert wird.
|
||||
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 **Objekt** in **AzureAD** (nicht in Intune) generiert und AzureAD gibt dem Gerät ein **Zertifikat** zurück, das von ihm signiert ist. Sie können überprüfen, ob das **Gerät AzureAD beigetreten** ist und Informationen über das **Zertifikat** (wie ob es durch TPM geschützt ist) erhalten.
|
||||
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).:
|
||||
```bash
|
||||
dsregcmd /status
|
||||
```
|
||||
Nach der Geräteregistrierung wird ein **Primary Refresh Token** vom LSASS CloudAP-Modul angefordert und dem Gerät übergeben. Mit dem PRT wird auch der **Sitzungsschlüssel geliefert, der so verschlüsselt ist, dass nur das Gerät ihn entschlüsseln kann** (unter Verwendung des öffentlichen Schlüssels des Transport-Schlüssels) und er ist **notwendig, um das PRT zu verwenden.**
|
||||
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 weitere Informationen darüber, was ein PRT ist, siehe:
|
||||
Für mehr Informationen darüber, was ein PRT ist, siehe:
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
@@ -24,18 +24,18 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
|
||||
### TPM - Trusted Platform Module
|
||||
|
||||
Der **TPM** **schützt** vor der Schlüssel-**Extraktion** von einem heruntergefahrenen Gerät (wenn es durch eine PIN geschützt ist) und vor der Extraktion des privaten Materials aus der Betriebssystemschicht.\
|
||||
Aber er **schützt nicht** vor dem **Abhören** der physischen Verbindung zwischen dem TPM und der CPU oder dem **Verwenden des kryptografischen Materials** im TPM, während das System von einem Prozess mit **SYSTEM**-Rechten läuft.
|
||||
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 überprüfen, werden Sie sehen, dass **das Stehlen des PRT** verwendet werden kann, um wie der **Benutzer** zuzugreifen, was großartig ist, da das **PRT sich auf Geräten befindet**, sodass es von ihnen gestohlen werden kann (oder, wenn es nicht gestohlen wird, missbraucht werden kann, um neue Signaturschlüssel zu generieren):
|
||||
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):
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
## Registrierung eines Geräts mit SSO-Token
|
||||
## Registrierung eines Geräts mit SSO-Tokens
|
||||
|
||||
Es wäre möglich für einen Angreifer, ein Token für den Microsoft-Geräteregistrierungsdienst vom kompromittierten Gerät anzufordern und es zu registrieren:
|
||||
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:
|
||||
```bash
|
||||
# Initialize SSO flow
|
||||
roadrecon auth prt-init
|
||||
@@ -47,46 +47,46 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>
|
||||
# Custom pyhton script to register a device (check roadtx)
|
||||
registerdevice.py
|
||||
```
|
||||
Welche Ihnen ein **Zertifikat gibt, das Sie in Zukunft verwenden können, um PRTs anzufordern**. Dadurch wird die Persistenz aufrechterhalten und **MFA umgangen**, da das ursprüngliche PRT-Token, das zur Registrierung des neuen Geräts verwendet wurde, **bereits MFA-Berechtigungen gewährt hatte**.
|
||||
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]
|
||||
> Beachten Sie, dass Sie für diesen Angriff Berechtigungen zur **Registrierung neuer Geräte** benötigen. Außerdem bedeutet die Registrierung eines Geräts nicht, dass das Gerät **in Intune eingeschrieben werden darf**.
|
||||
> 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 Sie keine neuen Geräte mehr mit SSO-Token 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**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md).
|
||||
> 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**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md).
|
||||
|
||||
## Überschreiben eines Gerätescheins
|
||||
## Überschreiben eines Gerätetickets
|
||||
|
||||
Es war möglich, einen **Geräteschein anzufordern**, den aktuellen des Geräts zu **überschreiben** und während des Ablaufs **das PRT zu stehlen** (es ist also nicht notwendig, es vom TPM zu stehlen. Für weitere Informationen [**sehen Sie sich diesen Vortrag an**](https://youtu.be/BduCn8cLV1A).
|
||||
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**](https://youtu.be/BduCn8cLV1A).
|
||||
|
||||
<figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!CAUTION]
|
||||
> Dies wurde jedoch behoben.
|
||||
|
||||
## WHFB-Schlüssel überschreiben
|
||||
## Überschreiben des WHFB-Schlüssels
|
||||
|
||||
[**Überprüfen Sie die ursprünglichen Folien hier**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
|
||||
[**Check the original slides here**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
|
||||
|
||||
Angriffsübersicht:
|
||||
|
||||
- Es ist möglich, den **registrierten WHFB**-Schlüssel von einem **Gerät** ü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**.
|
||||
- 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**
|
||||
|
||||
<figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Benutzer können ihr eigenes searchableDeviceKey-Attribut über das Azure AD Graph ändern, jedoch muss der Angreifer ein Gerät im Mandanten haben (entweder spontan registriert oder ein gestohlenes Zertifikat + Schlüssel von einem legitimen Gerät) und ein gültiges Zugriffstoken für das AAD Graph besitzen.
|
||||
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 ist es möglich, einen neuen Schlüssel zu generieren mit:
|
||||
Dann kann ein neuer Schlüssel mit folgendem Befehl generiert werden:
|
||||
```bash
|
||||
roadtx genhellokey -d <device id> -k tempkey.key
|
||||
```
|
||||
und dann PATCH die Informationen des searchableDeviceKey:
|
||||
und dann mittels PATCH die Informationen des searchableDeviceKey aktualisieren:
|
||||
|
||||
<figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
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**. Für weitere Informationen siehe:
|
||||
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:
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
@@ -94,7 +94,7 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
|
||||
<figure><img src="../../images/image (37).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Referenzen
|
||||
## Quellen
|
||||
|
||||
- [https://youtu.be/BduCn8cLV1A](https://youtu.be/BduCn8cLV1A)
|
||||
- [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
|
||||
|
||||
Reference in New Issue
Block a user