Translated ['src/pentesting-cloud/azure-security/az-basic-information/az

src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md

@@ -4,7 +4,7 @@
 
 ## Grundlegende Informationen
 
-Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagement (IAM) Plattform von Microsoft und dient als grundlegendes Authentifizierungs- und Autorisierungssystem für Dienste wie Microsoft 365 und Azure Resource Manager. Azure AD implementiert das OAuth 2.0 Autorisierungsframework und das OpenID Connect (OIDC) Authentifizierungsprotokoll zur Verwaltung des Zugriffs auf Ressourcen.
+Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagement (IAM) Plattform von Microsoft, die als grundlegendes Authentifizierungs- und Autorisierungssystem für Dienste wie Microsoft 365 und Azure Resource Manager dient. Azure AD implementiert das OAuth 2.0 Autorisierungsframework und das OpenID Connect (OIDC) Authentifizierungsprotokoll, um den Zugriff auf Ressourcen zu verwalten.
 
 ### OAuth
 
@@ -28,7 +28,7 @@ Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagement (IAM) Plattfo
 - **Implizite Zustimmung:** Bestimmte Anwendungen erhalten automatisch **Zugriff auf spezifische Scopes ohne ausdrückliche Genehmigung des Benutzers oder Administrators**.
 - Diese vorab genehmigten Scopes sind typischerweise sowohl für Benutzer als auch für Administratoren verborgen, was sie in den Standardverwaltungsoberflächen weniger sichtbar macht.
 
-**Typen von Client-Anwendungen:**
+**Client-Anwendungstypen:**
 
 1. **Vertrauliche Clients:**
 - Besitzen eigene Anmeldeinformationen (z. B. Passwörter oder Zertifikate).
@@ -36,7 +36,7 @@ Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagement (IAM) Plattfo
 2. **Öffentliche Clients:**
 - Haben keine einzigartigen Anmeldeinformationen.
 - Können sich nicht sicher beim Autorisierungsserver authentifizieren.
-- **Sicherheitsimplikation:** Ein Angreifer kann eine öffentliche Client-Anwendung nachahmen, wenn er Tokens anfordert, da es keinen Mechanismus gibt, mit dem der Autorisierungsserver die Legitimität der Anwendung überprüfen kann.
+- **Sicherheitsimplikation:** Ein Angreifer kann eine öffentliche Client-Anwendung nachahmen, wenn er Token anfordert, da es keinen Mechanismus gibt, mit dem der Autorisierungsserver die Legitimität der Anwendung überprüfen kann.
 
 ## Authentifizierungstoken
 
@@ -44,17 +44,17 @@ Es gibt **drei Arten von Tokens**, die in OIDC verwendet werden:
 
 - [**Zugriffstoken**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Der Client präsentiert dieses Token dem Ressourcenserver, um **auf Ressourcen zuzugreifen**. Es kann nur für eine spezifische Kombination aus Benutzer, Client und Ressource verwendet werden und **kann bis zum Ablauf nicht widerrufen werden** - das sind standardmäßig 1 Stunde.
 - **ID-Tokens**: Der Client erhält dieses **Token vom Autorisierungsserver**. Es enthält grundlegende Informationen über den Benutzer. Es ist **an eine spezifische Kombination aus Benutzer und Client gebunden**.
-- **Aktualisierungstokens**: Werden dem Client mit dem Zugriffstoken bereitgestellt. Wird verwendet, um **neue Zugriffs- und ID-Tokens zu erhalten**. Es ist an eine spezifische Kombination aus Benutzer und Client gebunden und kann widerrufen werden. Die Standardablaufzeit beträgt **90 Tage** für inaktive Aktualisierungstokens und **keine Ablaufzeit für aktive Tokens** (es ist möglich, aus einem Aktualisierungstoken neue Aktualisierungstokens zu erhalten).
-- Ein Aktualisierungstoken sollte an ein **`aud`**, an einige **Scopes** und an einen **Mandanten** gebunden sein und sollte nur in der Lage sein, Zugriffstokens für dieses aud, diese Scopes (und nicht mehr) und diesen Mandanten zu generieren. Dies ist jedoch nicht der Fall bei **FOCI-Anwendungstokens**.
+- **Aktualisierungstoken**: Werden dem Client zusammen mit dem Zugriffstoken bereitgestellt. Wird verwendet, um **neue Zugriffs- und ID-Tokens zu erhalten**. Es ist an eine spezifische Kombination aus Benutzer und Client gebunden und kann widerrufen werden. Die Standardablaufzeit beträgt **90 Tage** für inaktive Aktualisierungstoken und **keine Ablaufzeit für aktive Tokens** (es ist möglich, aus einem Aktualisierungstoken neue Aktualisierungstoken zu erhalten).
+- Ein Aktualisierungstoken sollte an ein **`aud`**, an einige **Scopes** und an einen **Mandanten** gebunden sein und sollte nur in der Lage sein, Zugriffstoken für dieses aud, diese Scopes (und nicht mehr) und diesen Mandanten zu generieren. Dies ist jedoch nicht der Fall bei **FOCI-Anwendungstoken**.
 - Ein Aktualisierungstoken ist verschlüsselt und nur Microsoft kann es entschlüsseln.
 - Das Erhalten eines neuen Aktualisierungstokens widerruft das vorherige Aktualisierungstoken nicht.
 
 > [!WARNING]
-> Informationen für **bedingten Zugriff** werden **innerhalb des JWT** **gespeichert**. Wenn Sie also das **Token von einer erlaubten IP-Adresse** anfordern, wird diese **IP** im Token **gespeichert**, und dann können Sie dieses Token von einer **nicht erlaubten IP verwenden, um auf die Ressourcen zuzugreifen**.
+> Informationen für **bedingten Zugriff** sind **innerhalb des JWT gespeichert**. Wenn Sie also das **Token von einer erlaubten IP-Adresse anfordern**, wird diese **IP** im Token **gespeichert**, und dann können Sie dieses Token von einer **nicht erlaubten IP verwenden, um auf die Ressourcen zuzugreifen**.
 
 ### Zugriffstoken "aud"
 
-Das im "aud"-Feld angegebene Feld ist der **Ressourcenserver** (die Anwendung), der verwendet wird, um die Anmeldung durchzuführen.
+Das im "aud"-Feld angegebene Feld ist der **Ressourcenserver** (die Anwendung), die verwendet wird, um die Anmeldung durchzuführen.
 
 Der Befehl `az account get-access-token --resource-type [...]` unterstützt die folgenden Typen, und jeder von ihnen wird ein spezifisches "aud" im resultierenden Zugriffstoken hinzufügen:
 
@@ -65,7 +65,7 @@ Der Befehl `az account get-access-token --resource-type [...]` unterstützt die
 
 <summary>aud Beispiele</summary>
 
-- **aad-graph (Azure Active Directory Graph API)**: Wird verwendet, um auf die veraltete Azure AD Graph API (abgekündigt) zuzugreifen, die Anwendungen ermöglicht, Verzeichnisdaten in Azure Active Directory (Azure AD) zu lesen und zu schreiben.
+- **aad-graph (Azure Active Directory Graph API)**: Wird verwendet, um auf die veraltete Azure AD Graph API (abgekündigt) zuzugreifen, die Anwendungen das Lesen und Schreiben von Verzeichnisdaten in Azure Active Directory (Azure AD) ermöglicht.
 - `https://graph.windows.net/`
 
 * **arm (Azure Resource Manager)**: Wird verwendet, um Azure-Ressourcen über die Azure Resource Manager API zu verwalten. Dazu gehören Operationen wie das Erstellen, Aktualisieren und Löschen von Ressourcen wie virtuellen Maschinen, Speicherkonten und mehr.
@@ -92,7 +92,7 @@ Der Befehl `az account get-access-token --resource-type [...]` unterstützt die
 
 Der Scope eines Zugriffstokens wird im scp-Schlüssel innerhalb des Zugriffstoken-JWT gespeichert. Diese Scopes definieren, auf was das Zugriffstoken Zugriff hat.
 
-Wenn ein JWT berechtigt ist, eine bestimmte API zu kontaktieren, aber **nicht den Scope** hat, um die angeforderte Aktion auszuführen, **kann es die Aktion nicht ausführen** mit diesem JWT.
+Wenn ein JWT berechtigt ist, eine spezifische API zu kontaktieren, aber **nicht den Scope** hat, um die angeforderte Aktion auszuführen, **kann es die Aktion nicht mit diesem JWT ausführen**.
 
 ### Beispiel zum Abrufen von Aktualisierungs- und Zugriffstoken
 ```python
@@ -144,18 +144,19 @@ scopes=["https://graph.microsoft.com/.default"],
 )
 pprint(new_azure_cli_bearer_tokens_for_graph_api)
 ```
-### Andere Zugriffstokenfelder
+### Andere Zugriffs-Token-Felder
 
 - **appid**: Anwendungs-ID, die zur Generierung des Tokens verwendet wird
-- **appidacr**: Der Application Authentication Context Class Reference gibt an, wie der Client authentifiziert wurde. Für einen öffentlichen Client ist der Wert 0, und wenn ein Client-Geheimnis verwendet wird, ist der Wert 1.
+- **appidacr**: Der Application Authentication Context Class Reference gibt an, wie der Client authentifiziert wurde; für einen öffentlichen Client ist der Wert 0, und wenn ein Client-Geheimnis verwendet wird, ist der Wert 1
 - **acr**: Der Authentication Context Class Reference-Anspruch ist "0", wenn die Authentifizierung des Endbenutzers die Anforderungen von ISO/IEC 29115 nicht erfüllt hat.
 - **amr**: Die Authentifizierungsmethode gibt an, wie das Token authentifiziert wurde. Ein Wert von „pwd“ zeigt an, dass ein Passwort verwendet wurde.
 - **groups**: Gibt die Gruppen an, in denen das Principal Mitglied ist.
-- **iss**: Die Ausgabe identifiziert den Sicherheits-Token-Dienst (STS), der das Token generiert hat. z.B. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (die uuid ist die Mandanten-ID)
+- **iss**: Der Aussteller identifiziert den Sicherheits-Token-Dienst (STS), der das Token generiert hat. z.B. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (die uuid ist die Mandanten-ID)
 - **oid**: Die Objekt-ID des Principals
 - **tid**: Mandanten-ID
 - **iat, nbf, exp**: Ausgestellt am (wann es ausgestellt wurde), Nicht vor (kann vor dieser Zeit nicht verwendet werden, normalerweise derselbe Wert wie iat), Ablaufzeit.
 
+
 ## FOCI-Token Privilegieneskalation
 
 Früher wurde erwähnt, dass Refresh-Token an die **Scopes** gebunden sein sollten, mit denen sie generiert wurden, an die **Anwendung** und den **Mandanten**, für die sie generiert wurden. Wenn eine dieser Grenzen überschritten wird, ist es möglich, Privilegien zu eskalieren, da es möglich sein wird, Zugriffstoken für andere Ressourcen und Mandanten zu generieren, auf die der Benutzer Zugriff hat, und mit mehr Scopes, als ursprünglich beabsichtigt.
@@ -164,11 +165,11 @@ Darüber hinaus **ist dies mit allen Refresh-Token** in der [Microsoft identity
 
 Darüber hinaus beachten Sie, dass die FOCI-Anwendungen öffentliche Anwendungen sind, sodass **kein Geheimnis erforderlich ist**, um sich beim Server zu authentifizieren.
 
-Dann bekannte FOCI-Clients, die in der [**ursprünglichen Forschung**](https://github.com/secureworks/family-of-client-ids-research/tree/main) berichtet wurden, können [**hier gefunden werden**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).
+Bekannte FOCI-Clients, die in der [**ursprünglichen Forschung**](https://github.com/secureworks/family-of-client-ids-research/tree/main) berichtet wurden, können [**hier gefunden werden**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).
 
 ### Anderen Scope abrufen
 
-Folgend mit dem vorherigen Beispielcode wird in diesem Code ein neues Token für einen anderen Scope angefordert:
+Im Folgenden wird im vorherigen Beispielcode ein neues Token für einen anderen Scope angefordert:
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 azure_cli_bearer_tokens_for_outlook_api = (
@@ -201,6 +202,26 @@ scopes=["https://graph.microsoft.com/.default"],
 # How is this possible?
 pprint(microsoft_office_bearer_tokens_for_graph_api)
 ```
+## Wo man Tokens findet
+
+Aus der Perspektive eines Angreifers ist es sehr interessant zu wissen, wo es möglich ist, Zugriffs- und Aktualisierungstokens zu finden, wenn beispielsweise der PC eines Opfers kompromittiert ist:
+
+- In **`<HOME>/.Azure`**
+- **`azureProfile.json`** enthält Informationen über angemeldete Benutzer aus der Vergangenheit
+- **`clouds.config` enthält** Informationen über Abonnements
+- **`service_principal_entries.json`** enthält Anwendungsanmeldeinformationen (Mandanten-ID, Clients und Geheimnis). Nur in Linux & macOS
+- **`msal_token_cache.json`** enthält Zugriffs- und Aktualisierungstokens. Nur in Linux & macOS
+- **`service_principal_entries.bin`** und **`msal_token_cache.bin`** werden in Windows verwendet und sind mit DPAPI verschlüsselt
+- **`msal_http_cache.bin`** ist ein Cache von HTTP-Anfragen
+- Lade es: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
+- **`AzureRmContext.json`** enthält Informationen über frühere Anmeldungen mit Az PowerShell (aber keine Anmeldeinformationen)
+- In **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** befinden sich mehrere `.bin`-Dateien mit **Zugriffstokens**, ID-Tokens und Kontoinformationen, die mit dem DPAPI des Benutzers verschlüsselt sind.
+- Es ist möglich, weitere **Zugriffstokens** in den `.tbres`-Dateien innerhalb von **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** zu finden, die ein mit DPAPI verschlüsseltes base64 mit Zugriffstokens enthalten.
+- In Linux und macOS können Sie **Zugriffstokens, Aktualisierungstokens und ID-Tokens** von Az PowerShell (wenn verwendet) erhalten, indem Sie `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"` ausführen.
+- In Windows generiert dies nur ID-Tokens.
+- Es ist möglich zu sehen, ob Az PowerShell in Linux und macOS verwendet wurde, indem überprüft wird, ob `$HOME/.local/share/.IdentityService/` existiert (obwohl die enthaltenen Dateien leer und nutzlos sind).
+- Wenn der Benutzer **im Browser bei Azure angemeldet ist**, ist es laut diesem [**Beitrag**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) möglich, den Authentifizierungsfluss mit einer **Weiterleitung zu localhost** zu starten, den Browser automatisch die Anmeldung autorisieren zu lassen und das Aktualisierungstoken zu erhalten. Beachten Sie, dass es nur wenige FOCI-Anwendungen gibt, die eine Weiterleitung zu localhost erlauben (wie az cli oder das PowerShell-Modul), sodass diese Anwendungen erlaubt sein müssen.
+
 ## Referenzen
 
 - [https://github.com/secureworks/family-of-client-ids-research](https://github.com/secureworks/family-of-client-ids-research)