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

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md

@@ -4,15 +4,15 @@
 
 ## Pass the Certificate (Azure)
 
-Na Azure povezanim mašinama, moguće je autentifikovati se sa jedne mašine na drugu koristeći sertifikate koji **moraju biti izdata od Azure AD CA** za potrebnog korisnika (kao subjekat) kada obe mašine podržavaju **NegoEx** mehanizam autentifikacije.
+Na Azure povezanim mašinama, moguće je autentifikovati se sa jedne mašine na drugu koristeći sertifikate koji **moraju biti izdati od strane Entra ID CA** za potrebnog korisnika (kao subjekat) kada obe mašine podržavaju **NegoEx** mehanizam autentifikacije.
 
 U super pojednostavljenim terminima:
 
-- Mašina (klijent) koja inicira vezu **treba sertifikat od Azure AD za korisnika**.
-- Klijent kreira JSON Web Token (JWT) zaglavlje koje sadrži PRT i druge detalje, potpisuje ga koristeći Izvedeni ključ (koristeći sesijski ključ i bezbednosni kontekst) i **šalje ga Azure AD**
-- Azure AD verifikuje JWT potpis koristeći sesijski ključ klijenta i bezbednosni kontekst, proverava validnost PRT i **odgovara** sa **sertifikatom**.
+- Mašina (klijent) koja inicira vezu **treba sertifikat od Entra ID za korisnika**.
+- Klijent kreira JSON Web Token (JWT) zaglavlje koje sadrži PRT i druge detalje, potpisuje ga koristeći Izvedeni ključ (koristeći sesijski ključ i bezbednosni kontekst) i **šalje ga Entra ID**
+- Entra ID verifikuje JWT potpis koristeći sesijski ključ klijenta i bezbednosni kontekst, proverava validnost PRT i **odgovara** sa **sertifikatom**.
 
-U ovom scenariju i nakon prikupljanja svih informacija potrebnih za [**Pass the PRT**](pass-the-prt.md) napad:
+U ovom scenariju i nakon prikupljanja svih potrebnih informacija za [**Pass the PRT**](pass-the-prt.md) napad:
 
 - Korisničko ime
 - Tenant ID
@@ -20,15 +20,15 @@ U ovom scenariju i nakon prikupljanja svih informacija potrebnih za [**Pass the
 - Bezbednosni kontekst
 - Izvedeni ključ
 
-Moguće je **zatražiti P2P sertifikat** za korisnika pomoću alata [**PrtToCert**](https://github.com/morRubin/PrtToCert)**:**
+Moguće je **zatražiti P2P sertifikat** za korisnika sa alatom [**PrtToCert**](https://github.com/morRubin/PrtToCert)**:**
 ```bash
 RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
 ```
-Sertifikati će trajati isto kao i PRT. Da biste koristili sertifikat, možete koristiti python alat [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) koji će **autentifikovati** na udaljenoj mašini, pokrenuti **PSEXEC** i **otvoriti CMD** na žrtvinoj mašini. Ovo će nam omogućiti da ponovo koristimo Mimikatz da bismo dobili PRT drugog korisnika.
+Sertifikati će trajati isto kao i PRT. Da biste koristili sertifikat, možete koristiti python alat [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) koji će **autentifikovati** na udaljenoj mašini, pokrenuti **PSEXEC** i **otvoriti CMD** na žrtvovoj mašini. Ovo će nam omogućiti da ponovo koristimo Mimikatz da bismo dobili PRT drugog korisnika.
 ```bash
 Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
 ```
-## Reference
+## References
 
 - Za više detalja o tome kako Pass the Certificate funkcioniše, pogledajte originalni post [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
 

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}}
-
-**Proveri:** [**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}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md

@@ -1,7 +1,261 @@
-# Az - Primarni osvežavajući token (PRT)
+# Az - Primary Refresh Token (PRT)
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-**Proverite 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/) iako se drugi post koji objašnjava isto može naći na [**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)
+## Šta je Primary Refresh Token (PRT)?
+
+**Primary Refresh Token (PRT)** je dugotrajni refresh token koji se koristi u Azure AD (Entra ID) autentifikaciji, analogan Kerberos TGT-u. Izdaje se prilikom prijave korisnika na uređaju povezanom sa Azure AD i može se koristiti za zahtevanje pristupnih tokena za razne aplikacije bez ponovnog traženja kredencijala. Svaki PRT je praćen **session key** (takođe nazvan Proof-of-Possession key) -- simetričnim ključem koji se koristi za potpisivanje zahteva i dokazivanje da klijent ima PRT. Sam PRT je neprozirna, enkriptovana blob (nečitljiva od strane klijenta), dok se session key koristi za **potpisivanje** JWT-a koji sadrži PRT prilikom zahteva za tokenima. Drugim rečima, posedovanje PRT-a samo po sebi nije dovoljno; napadač treba session key da bi dokazao legitimnost, slično kao što su potrebni i Kerberos TGT i njegov session key za autentifikaciju.
+
+Na Windows-u, PRT i session key se keširaju u LSASS procesu putem CloudAP plugina. Ako uređaj ima **TPM** (Trusted Platform Module), Azure AD vezuje ključeve za TPM radi dodatne sigurnosti. To znači da se na uređajima opremljenim TPM-om session key čuva ili koristi unutar TPM-a tako da ne može biti direktno pročitan iz memorije pod normalnim okolnostima. Ako TPM nije dostupan (npr. mnoge VM-ove ili stariji sistemi), ključevi se čuvaju u softveru i zaštićeni su DPAPI enkripcijom. U oba slučaja, napadač sa administratorskim privilegijama ili izvršavanjem koda na mašini može pokušati da **izvuče PRT i session key iz memorije** kao deo post-exploitation-a, a zatim ih koristiti za impersonaciju korisnika u oblaku. 
+Za razliku od tipičnih refresh tokena (koji su obično specifični za aplikaciju), PRT je širi, omogućavajući vašem uređaju da zahteva tokene za gotovo svaki Entra ID-integrisani resurs ili uslugu.
+
+## Kako funkcioniše PRT?
+
+Evo pojednostavljenog pregleda kako PRT funkcioniše:
+
+1.  **Registracija uređaja:**
+
+-   Kada vaš uređaj (poput Windows laptopa ili mobilnog telefona) pristupi ili se registruje sa Entra ID, autentifikuje se koristeći vaše kredencijale (korisničko ime/lozinka/MFA).
+
+-   Nakon uspešne autentifikacije, Entra ID izdaje PRT koji je specifično vezan za vaš uređaj.
+
+2.  **Skladištenje tokena:**
+
+-   PRT se sigurno čuva na vašem uređaju, često zaštićen hardverskim funkcijama poput Trusted Platform Module (TPM), osiguravajući da je teško za neovlašćene strane da ga izvuku ili zloupotrebe.
+
+3.  **Jedinstvena prijava (SSO):**
+
+-   Svaki put kada pristupite aplikaciji zaštićenoj Entra ID (npr. Microsoft 365 aplikacije, SharePoint, Teams), vaš uređaj tiho koristi sačuvani PRT da zatraži i dobije specifičan pristupni token za tu aplikaciju.
+
+-   Ne morate ponovo unositi svoje kredencijale jer PRT transparentno upravlja autentifikacijom.
+
+4.  **Obnova i sigurnost:**
+
+-   PRT-ovi imaju dug vek trajanja (obično oko 14 dana), ali se neprekidno obnavljaju sve dok je vaš uređaj aktivno u upotrebi.
+
+-   Ako vaš uređaj postane kompromitovan ili izgubljen, administratori mogu daljinski opozvati vaš PRT, odmah blokirajući neovlašćen pristup.
+
+### Zašto su PRT-ovi moćni?
+
+-   **Univerzalni pristup:** Za razliku od tipičnih tokena koji su ograničeni na jednu aplikaciju ili resurs, PRT može olakšati pristup svim Entra ID-integrisanim uslugama.
+
+-   **Povećana sigurnost:** Sa ugrađenim hardverskim zaštitama (poput TPM), PRT-ovi osiguravaju sigurno skladištenje i korišćenje tokena.
+
+-   **Korisničko iskustvo:** PRT-ovi značajno poboljšavaju korisničko iskustvo smanjenjem učestalih zahteva za autentifikaciju i omogućavanjem pravog besprekornog SSO.
+
+## Kako znati da li je PRT prisutan?
+
+- Proverite da li je PRT prisutan:
+```bash
+# Execute
+dsregcmd /status
+## Check if the value of AzureAdPrt is set to YES
+```
+- Proverite da li je zaštićeno TPM-om:
+```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
+
+Prema [ovom postu](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) na Windows uređajima **bez TPM vezivanja**, PRT i njegov sesijski ključ se nalaze u LSASS (CloudAP dodatak). Sa lokalnim admin/SYSTEM na tom uređaju, PRT blob i DPAPI-kriptovani sesijski ključ mogu se **pročitati iz LSASS, sesijski ključ dekriptovati putem DPAPI, i potpisni ključ izvesti** da bi se stvorio važeći PRT kolačić (`x‑ms‑RefreshTokenCredential`). Potrebni su vam i PRT i njegov sesijski ključ—sama PRT string nije dovoljna.
+
+### Mimikatz
+```bash
+privilege::debug
+sekurlsa::cloudap
+```
+**PRT field** sadrži enkriptovani refresh token (obično base64 string), a KeyValue u ProofOfPossessionKey je DPAPI-enkriptovani sesijski ključ (takođe base64).
+
+Zatim, iz **`sekurlsa::cloudap`** izlaza, kopirajte base64 blob iz **`KeyValue`** unutar polja `ProofOfPossessionKey` (ovo je sesijski ključ enkriptovan DPAPI). Ovaj enkriptovani ključ ne može se koristiti onako kako jeste – mora se dekriptovati koristeći sistemske DPAPI akreditive.
+
+Pošto DPAPI enkripcija za sistemske tajne zahteva sistemski kontekst mašine, podignite svoj token na SYSTEM i koristite Mimikatz-ov DPAPI modul za dekripciju:
+```bash
+token::elevate
+dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
+```
+`token::elevate` će se pretvarati da je SYSTEM, a komanda `dpapi::cloudapkd` sa `/unprotect` će koristiti DPAPI master ključ za dekriptovanje datog KeyValue blob-a. Ovo daje ključ sesije u čistom tekstu, kao i povezani Derived Key i Context koji se koriste za potpisivanje:
+- **Clear key** – 32-bajtni ključ sesije u čistom tekstu (predstavljen kao heksadecimalni string).
+- **Derived Key** – 32-bajtni ključ izveden iz ključa sesije i vrednosti konteksta (više o ovome u nastavku).
+- **Context** – 24-bajtni nasumični kontekst koji je korišćen prilikom izvođenja ključa za potpisivanje za PRT kolačić.
+
+
+> [!NOTE]
+> Ako ovo ne funkcioniše za vas da se pretvarate da ste korisnik, proverite sledeću sekciju koristeći **`AADInternals`**.
+
+Zatim, možete koristiti i mimikatz za generisanje validnog PRT kolačića:
+```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 će ispisati potpisani JWT ( `PRT cookie` ) nakon linije “Signature with key”, koji sadrži PRT i potpisan je korišćenjem dobijenog ključa. Ovaj JWT se može kopirati i zatim koristiti u web sesiji. Na primer, napadač može otvoriti pregledač, otići na `login.microsoftonline.com`, i postaviti kolačić nazvan `x-ms-RefreshTokenCredential` sa vrednošću ovog JWT-a. Kada se pregledač osveži ili navigira, Azure AD će tretirati sesiju kao autentifikovanu (PRT kolačić se prikazuje kao da je došlo do SSO), i izdaće autorizacioni kod ili pristupni token za određeni resurs. U praksi, korisnik bi navigirao do resursa kao što su Office 365 ili Azure portal; prisustvo validnog PRT kolačića znači da će Azure AD omogućiti pristup bez dodatnog prijavljivanja (zaobilazeći MFA, pošto je PRT već autentifikovan).
+
+Takođe možete koristiti **`roadtx`** i **`roadrecon`** sa PRT-om PRT kolačića da biste se pretvarali da ste korisnik *(TODO: Pronaći tačne komande za korišćenje roadtx/roadrecon za dobijanje kredencijala iz PRT-a)*.
+
+
+### AADInternals
+
+**`AADInternals`** PowerShell modul se takođe može koristiti sa prethodno dobijenim PRT-om i sesijskim ključem za generisanje validnog PRT tokena. Ovo je korisno za automatizaciju procesa dobijanja novog PRT tokena sa nonce-om, koji se može koristiti za dobijanje pristupnih tokena za Azure AD Graph API ili druge resurse:
+```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
+
+Despite the mentioned protections, an attacker who has already compromised a device (as a local user or even SYSTEM) can still **abuse the PRT to obtain fresh access tokens** by leveraging Windows' own token broker APIs and security components. Instead of **extracting** the raw PRT or key, the attacker essentially **"asks" Windows to use the PRT on their behalf**. In the sections below, we outline currently valid techniques for abusing PRTs and their session keys on up-to-date Windows devices where TPM protections are in effect. All these techniques assume post-exploitation access on the target machine, and **focus on abusing built-in authentication flows** (no unpatched vulnerabilities needed).
+
+### Windows Token Broker Architecture and SSO Flow
+
+Modern Windows handles cloud authentication via a built-in **token broker** stack, which includes components in both user mode and LSASS (Local Security Authority). Key pieces of this architecture include:
+
+-   **LSASS CloudAP Plugin:** When a device is Azure AD joined, LSASS loads cloud authentication packages (e.g. `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) that manage PRTs and token requests. LSASS (running as SYSTEM) orchestrates PRT storage, renewal, and usage, and interfaces with the TPM to perform cryptographic operations (like signing a PRT challenge with the session key).
+
+-   **Web Account Manager (WAM):** The Windows Web Account Manager is a user-mode framework (accessible via COM/WinRT APIs) that allows applications or browsers to request tokens for cloud accounts without prompting for credentials. WAM acts as a broker between user applications and the secure LSASS/TPM-backed PRT. For example, Microsoft's MSAL library and certain OS components use WAM to silently acquire tokens using the logged-in user's PRT.
+
+-   **BrowserCore.exe and Token Broker COM interfaces:** For browser SSO, Windows includes a component called **BrowserCore.exe** (located under *Windows Security\BrowserCore*). This is a native messaging host used by browsers (Edge, Chrome via an extension, etc.) to obtain a PRT-derived SSO token for Azure AD login. Under the hood, BrowserCore leverages a COM object provided by `MicrosoftAccountTokenProvider.dll` to retrieve a PRT-based cookie/token. In essence, this COM interface is a first-party "token broker" API that any process running as the user can obscall to get an SSO token (provided the user has a valid PRT in LSASS).
+
+When an Azure AD joined user tries to access a resource (say, the Azure Portal), the flow is typically: an application calls into WAM or BrowserCore's COM interface, which in turn communicates with LSASS. LSASS uses the PRT and session key (secured by TPM) to produce an **SSO token** -- often called a **PRT cookie** -- which is then given back to the application or browser. The PRT cookie is a special JWT containing the encrypted PRT and a nonce, signed with a key derived from the PRT's session key. This cookie is sent to Azure AD (in an `x-ms-RefreshTokenCredential` header) to prove the device and user hold a valid PRT, allowing Azure AD to issue standard OAuth refresh and access tokens for various applications. Notably, any Multi-Factor Authentication (MFA) claim present in the PRT will be carried into tokens obtained via this SSO process, meaning PRT-derived tokens can satisfy MFA-protected resources.
+
+### User-Level Token Theft (Non-Admin)
+
+When an attacker has **user-level code execution**, the TPM protection of PRT doesn't stop the attacker from obtaining tokens. The attacker **leverages built-in Windows Token Broker APIs**:
+
+#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
+
+BrowserCore exposes a COM class (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) to fetch PRT cookies. This COM API is invoked legitimately by browsers (Chrome/Edge extensions) for Azure AD SSO.
+
+-   **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
+```bash
+RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
+```
+*(Vraća Azure AD refresh token ili PRT kolačić)*
+
+- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
+```bash
+ROADtoken.exe --nonce <nonce-value>
+roadrecon auth --prt-cookie <cookie>
+```
+*(Generiše nonce, poziva BrowserCore da dobije PRT kolačić, zatim ga otkupljuje putem ROADtools)*
+
+
+### **Web Account Manager (WAM) API**
+
+Napadači koriste legitimne Microsoft biblioteke za autentifikaciju (**MSAL**, **WAM API**, **WebAuthenticationCoreManager**) iz procesa na nivou korisnika da tiho preuzmu tokene koristeći PRT zaštićen TPM-om.
+
+
+-   **[aadprt](https://posts.specterops.io/)**
+```bash
+execute-assembly aadprt.exe
+```
+*(Preuzima PRT kolačić putem COM interfejsa)*
+
+-   **[listwamaccounts](https://posts.specterops.io/)**
+```bash
+execute-assembly listwamaccounts.exe
+```
+*(Lista Azure AD naloga prijavljenih putem WAM; identifikuje ciljeve tokena)*
+
+-   **Generički primer (PowerShell sa 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
+```
+*(Tiho dobija pristupni token koristeći PRT)*
+
+#### Zloupotreba Tokena na Administratorskom / SISTEMskom Nivou
+
+Ako napadač eskalira na **Administrator ili SISTEM**, može direktno imitirati bilo kog korisnika koji je prijavljen na Azure AD i koristiti iste **COM/WAM token broker API-je**. PRT-ovi zaštićeni TPM-om ne sprečavaju ovu legitimnu izdavanje tokena.
+
+### **Imitacija Korisnika i Preuzimanje Tokena**
+
+Admin/SISTEM može imitirati aktivne sesije drugih korisnika kako bi pozvao BrowserCore ili WAM za generisanje tokena.
+
+Za ovo samo imitirati korisnički proces (npr., `explorer.exe`) i pozvati token broker API-je koristeći bilo koju tehniku komentarisanu u prethodnom odeljku.
+
+### **Direktna Interakcija sa LSASS-om i Token Broker-om (Napredno)**
+
+Administrator može i dalje raditi sa LSASS-om kako bi zloupotrebio PRT: na primer, admin bi mogao ubrizgati kod u LSASS ili pozvati interne CloudAP funkcije kako bi naterao LSASS da proizvede token. Istraživanje Dirka-jana je primetilo da admin može “interagovati sa PRT ključevima u LSASS-u koristeći kripto API-je”. U praksi, to bi moglo značiti korišćenje LSASS-ovih vlastitih funkcija (putem tehnike kao što je API hooking ili RPC, ako su dostupni) za generisanje PRT kolačića. Drugi pristup je iskoristiti bilo koji prozor u kojem bi sesijski ključ mogao da se pojavi u memoriji – na primer, u trenutku obnavljanja PRT-a ili registracije uređaja kada je nekriptovan za upotrebu. Takvi napadi su znatno složeniji i situacioni. Jedna jednostavnija taktika admina je zloupotreba postojećih token handle-ova ili keširanja: LSASS kešira nedavno izdate refresh tokene za aplikacije u memoriji (kriptovane sa DPAPI). Određeni napadač iz SISTEMA mogao bi pokušati da izvuče ove DPAPI-zaštićene tokene (koristeći korisnički master ključ, koji admin može dobiti) kako bi direktno ukrao refresh tokene za specifične aplikacije. Međutim, najlakša i najopštija metoda ostaje imitacija i korišćenje dokumentovanih token broker interfejsa, pošto oni garantuju da će Azure AD izdati sveže tokene (sa svim pravilnim zahtevima) umesto pokušaja da se razbije enkripcija.
+
+## Phishing PRT-ova
+
+Zloupotreba **OAuth Device Code** toka koristeći **Microsoft Authentication Broker client ID** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) i **Device Registration Service (DRS)** resurs za dobijanje **refresh tokena koji se može unaprediti u Primarni Refresh Token (PRT)** nakon registracije **rogue uređaja**.
+
+### **Zašto ovo funkcioniše**
+
+-   **PRT** je **vezan za uređaj** i omogućava **SSO za (gotovo) svaku Entra‑zaštićenu aplikaciju**.
+-   Kombinacija **Broker klijenta + DRS** omogućava da se ukradeni **refresh token** **zameni za PRT** nakon registracije uređaja.
+-   **MFA nije zaobiđena**: **korisnik obavlja MFA** tokom phishing-a; **MFA zahtevi se prenose** u rezultantni PRT, omogućavajući napadaču pristup aplikacijama **bez daljih zahteva**.
+
+**Preduslovi**:
+
+-   **Korisnička autentifikacija putem Device Code** koristeći **Broker client ID** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) i **DRS opsege/resurs** (npr., **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** ili **`https://enrollment.manage.microsoft.com/`**).
+-   **Korisnik može registrovati uređaje** u Entra ID (**podrazumevano: dozvoljeno**, ali može biti ograničeno ili kvotirano).
+-   **Nema blokirajućih CA politika** koje **onemogućavaju Device Code** ili **zahtevaju usklađene/hibridne uređaje** za ciljne aplikacije (to neće sprečiti izdavanje PRT-a, ali **hoće** blokirati **korišćenje** za pristup zaštićenim aplikacijama).
+-   **Napadačem kontrolisana mašina** za pokretanje toka i čuvanje tokena/ključeva uređaja.
+
+**Tok napada**:
+
+1.  **Pokreni Device Code autentifikaciju** sa **client_id = Broker** i **DRS opsegom/resursom**; prikaži **korisnički kod** žrtvi.
+```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.  **Žrtva se prijavljuje na Microsoftovom sajtu** (legit UI) i završava **MFA** → **napadač dobija DRS‑opseg refresh token** za Broker klijent.
+
+3.  **Registrujte zlu uređaj** u tenant-u koristeći taj refresh token (objekat uređaja se kreira i povezuje sa žrtvom).
+
+4.  **Nadogradite na PRT** razmenom **refresh token + identitet/ključevi uređaja** → **PRT** vezan za napadačev uređaj.
+
+5.  **(Opcionalna postojanost)**: ako je MFA bila sveža, **registrujte Windows Hello for Business ključ** za održavanje **dugoročnog, bezlozinkastog pristupa**.
+
+6.  **Zloupotreba**: iskoristite **PRT** (ili izradite **PRT kolačić**) da dobijete **pristupne tokene** za **Exchange/Graph/SharePoint/Teams/prilagođene aplikacije** kao korisnik.
+
+
+### Javne alatke i dokazi koncepta
+
+- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Automatizuje OAuth tok, registraciju uređaja i nadogradnje tokena.
+- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Skripta sa jednom komandom koja automatizuje phishing uređajnog koda u PRT+WHfB ključeve.
+
+
+## Reference
+
+- [Dirkjanov blog post o PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
+- [Dirkjanov post o phishing PRT-ima](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
+- [Dirkjanov post o zloupotrebi PRT-a](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
+- SpecterOps post o [Zahtevanju Azure AD Request Tokens](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
+- [AADInternals post o PRT-ima](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}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md

@@ -2,13 +2,13 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## **Osnovne Informacije**
+## **Osnovne informacije**
 
-Kao što je objašnjeno u [**ovom videu**](https://www.youtube.com/watch?v=OHKZkXC4Duw), neki Microsoft softveri sinhronizovani sa cloud-om (Excel, Teams...) mogu **čuvati pristupne tokene u čistom tekstu u memoriji**. Tako da samo **dumpovanje** **memorije** procesa i **pretraga za JWT tokenima** može vam omogućiti pristup raznim resursima žrtve u cloud-u, zaobilazeći MFA.
+Kao što je objašnjeno u [**ovom videu**](https://www.youtube.com/watch?v=OHKZkXC4Duw), neki Microsoft softveri sinhronizovani sa cloud-om (Excel, Teams...) mogu **čuvati pristupne tokene u čistom tekstu u memoriji**. Tako da samo **dumpovanje** **memorije** procesa i **grepovanje za JWT tokene** može vam omogućiti pristup raznim resursima žrtve u cloud-u, zaobilazeći MFA.
 
 Koraci:
 
-1. Dumpujte excel procese sinhronizovane sa EntraID korisnikom koristeći vaš omiljeni alat.
+1. Dumpujte excel procese sinhronizovane sa EntraID korisnikom pomoću vašeg omiljenog alata.
 2. Pokrenite: `string excel.dmp | grep 'eyJ0'` i pronađite nekoliko tokena u izlazu
 3. Pronađite tokene koji vas najviše zanimaju i pokrenite alate nad njima:
 ```bash
@@ -27,9 +27,8 @@ 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>'
 ```
-**Napomena da se ovakvi pristupni tokeni mogu naći i unutar drugih procesa.**
+**Napomena da se ovi tipovi pristupnih tokena mogu naći i unutar drugih procesa.**
 
 {{#include ../../../banners/hacktricks-training.md}}

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 @@
 
 **Ovaj post je sažetak** [**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/) **koji se može proveriti za dodatne informacije o napadu. Ova tehnika je takođe komentarisana u** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.**
 
-## Osnovne informacije
+## Pregled Kerberos Trust odnosa
 
-### Trust
+**Cloud Kerberos Trust (Entra ID -> AD)** -- Ova funkcija (deo Windows Hello for Business) uspostavlja jednostrano poverenje gde on-prem AD **veruje Entra ID** da izdaje Kerberos karte za AD. Aktiviranje stvara **AzureADKerberos$** računar u AD (koji se pojavljuje kao Read-Only Domain Controller) i povezani **`krbtgt_AzureAD`** nalog (sekundarni KRBTGT). Entra ID drži ključeve za ove naloge i može izdavati "delimične" Kerberos TGT-ove za AD korisnike. AD domen kontroleri će poštovati ove karte, ali sa RODC-sličnim ograničenjima: prema zadatku, **grupe sa visokim privilegijama (Domain Admins, Enterprise Admins, itd.) su *odbijene***, dok su obični korisnici dozvoljeni. Ovo sprečava Entra ID da autentifikuje domen administratore putem poverenja pod normalnim uslovima. Međutim, kao što ćemo videti, napadač sa dovoljnim Entra ID privilegijama može zloupotrebiti ovaj dizajn poverenja.
 
-Kada se uspostavi poverenje sa Azure AD, **stvara se Read Only Domain Controller (RODC) u AD-u.** **RODC korisnički nalog**, nazvan **`AzureADKerberos$`**. Takođe, postoji sekundarni `krbtgt` nalog nazvan **`krbtgt_AzureAD`**. Ovaj nalog sadrži **Kerberos ključeve** koji se koriste za karte koje Azure AD kreira.
+## Prebacivanje sa Entra ID na On-Prem AD
 
-Dakle, ako je ovaj nalog kompromitovan, moglo bi biti moguće imitirati bilo kog korisnika... iako to nije tačno jer je ovom nalogu onemogućeno kreiranje karata za bilo koju uobičajenu privilegovanu AD grupu kao što su Domain Admins, Enterprise Admins, Administrators...
+**Scenario:** Ciljna organizacija ima **Cloud Kerberos Trust** omogućen za autentifikaciju bez lozinke. Napadač je stekao **Global Administrator** privilegije u Entra ID (Azure AD) ali još uvek **ne** kontroliše on-prem AD. Napadač takođe ima pristup mreži do Domain Controller-a (putem VPN-a ili Azure VM-a u hibridnoj mreži). Koristeći cloud poverenje, napadač može iskoristiti kontrolu Azure AD da dobije **Domain Admin** nivo pristupa u AD.
 
-> [!CAUTION]
-> Međutim, u stvarnom scenariju biće privilegovanih korisnika koji nisu u tim grupama. Tako da bi **novi krbtgt nalog, ako bude kompromitovan, mogao biti korišćen za imitaciju njih.**
+**Preduslovi:**
 
-### Kerberos TGT
+-   **Cloud Kerberos Trust** je konfigurisan u hibridnom okruženju (indikator: `AzureADKerberos$` RODC nalog postoji u AD).
 
-Štaviše, kada se korisnik autentifikuje na Windows-u koristeći hibridni identitet, **Azure AD će izdati delimičnu Kerberos kartu zajedno sa PRT-om.** TGT je delimičan jer **AzureAD ima ograničene informacije** o korisniku u on-prem AD-u (kao što su identifikator bezbednosti (SID) i ime).\
-Windows može **zameniti ovu delimičnu TGT za punu TGT** tražeći servisnu kartu za `krbtgt` servis.
+-   Napadač ima **Global Admin (ili Hybrid Identity Admin)** prava u Entra ID tenant-u (ove uloge mogu koristiti AD Connect **synchronization API** za modifikaciju Azure AD korisnika).
 
-### NTLM
+-   Bar jedan **hibridni korisnički nalog** (postoji u AD i AAD) na koji se napadač može autentifikovati. Ovo se može dobiti poznavanjem ili resetovanjem njegovih akreditiva ili dodeljivanjem metode bez lozinke (npr. Temporary Access Pass) za generisanje Primary Refresh Token-a (PRT) za njega.
 
-Kako može biti usluga koja ne podržava Kerberos autentifikaciju već NTLM, moguće je zatražiti **delimičnu TGT potpisanu koristeći sekundarni `krbtgt`** ključ uključujući **`KERB-KEY-LIST-REQ`** polje u **PADATA** delu zahteva i zatim dobiti punu TGT potpisanu primarnim `krbtgt` ključem **uključujući NT hash u odgovoru**.
+-   **On-prem AD ciljni nalog** sa visokim privilegijama koji *nije* u podrazumevanoj RODC "odbij" politici. U praksi, odličan cilj je **AD Connect sync nalog** (često nazvan **MSOL_***), koji ima DCSync (replikacija) prava u AD, ali obično nije član ugrađenih administrativnih grupa. Ovaj nalog obično nije sinhronizovan sa Entra ID, što omogućava njegovo SID korišćenje bez sukoba.
 
-## Zloupotreba Cloud Kerberos Trust za dobijanje Domain Admin <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
+**Koraci napada:**
 
-Kada AzureAD generiše **delimičnu TGT**, koristiće detalje koje ima o korisniku. Dakle, ako bi Global Admin mogao da izmeni podatke kao što su **identifikator bezbednosti i ime korisnika u AzureAD**, kada zatraži TGT za tog korisnika, **identifikator bezbednosti bi bio drugačiji**.
+1.  **Dobijanje Azure AD sync API pristupa:** Koristeći Global Admin nalog, pribaviti pristupni token za Azure AD **Provisioning (sync) API**. Ovo se može uraditi pomoću alata kao što su **ROADtools** ili **AADInternals**. Na primer, sa ROADtools (roadtx):
+```bash
+# Using roadtx to get an Azure AD Graph token (no MFA)
+roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
+```
+*(Alternativno, AADInternals' `Connect-AADInt` može se koristiti za autentifikaciju kao Global Admin.)*
 
-Nije moguće to učiniti putem Microsoft Graph-a ili Azure AD Graph-a, ali je moguće koristiti **API koji Active Directory Connect** koristi za kreiranje i ažuriranje sinhronizovanih korisnika, što mogu koristiti Global Admini da **izmene SAM ime i SID bilo kog hibridnog korisnika**, a zatim, ako se autentifikujemo, dobijamo delimičnu TGT koja sadrži izmenjeni SID.
+2.  **Izmenite On-Prem Atribute Hibridnog Korisnika:** Iskoristite Azure AD **synchronization API** da postavite odabrane hibridne korisničke **onPremises Security Identifier (SID)** i **onPremises SAMAccountName** da odgovaraju ciljanom AD nalogu. Ovo efikasno govori Azure AD-u da cloud korisnik odgovara on-prem nalogu koji želimo da imitiramo. Koristeći open-source **ROADtools Hybrid** alat:
+```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` (nepromenljivi ID) korisnika je potreban za identifikaciju Azure AD objekta koji treba izmeniti. Alat postavlja SID i SAM naziv naloga hibridnog korisnika na vrednosti cilja (npr., SID i SAM naloga MSOL_xxxx). Azure AD obično ne dozvoljava promenu ovih atributa putem Graph-a (oni su samo za čitanje), ali API usluge sinhronizacije to dozvoljava i Global Admini mogu da pozovu ovu funkcionalnost sinhronizacije.
 
-Napomena da ovo možemo učiniti sa AADInternals i ažurirati sinhronizovane korisnike putem [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet-a.
+3.  **Dobijanje delimičnog TGT-a iz Azure AD:** Nakon izmene, autentifikujte se kao hibridni korisnik u Azure AD (na primer, dobijanjem PRT-a na uređaju ili korišćenjem njihovih akreditiva). Kada se korisnik prijavi (posebno na uređaju koji je pridružen domeni ili Entra), Azure AD će izdati **delimični Kerberos TGT (TGT**<sub>**AD**</sub>) za taj nalog jer je Cloud Kerberos Trust omogućen. Ovaj delimični TGT je enkriptovan sa AzureADKerberos$ RODC ključem i uključuje **ciljni SID** koji smo postavili. Možemo simulirati ovo traženjem PRT-a za korisnika putem ROADtools:
+```bash
+roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
+```
+Ovo generiše `.prt` datoteku koja sadrži delimični TGT i sesijski ključ. Ako je nalog bio samo za oblak, Azure AD i dalje uključuje TGT_AD u PRT odgovoru.
 
-### Preduslovi za napad <a href="#attack-prerequisites" id="attack-prerequisites"></a>
+4.  **Zamena delimičnog TGT-a za puni TGT (na AD-u):** Delimični TGT se sada može predstaviti lokalnom kontroloru domena da bi se dobio **puni TGT** za ciljni nalog. To radimo tako što izvršavamo TGS zahtev za `krbtgt` servis (primarni TGT servis domena) -- suštinski unapređujući tiket u normalan TGT sa punim PAC-om. Alati su dostupni za automatizaciju ove razmene. Na primer, koristeći skriptu 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
+```
+Ovaj skript (ili ekvivalenti Impacket-a) će kontaktirati Kontroler domena i preuzeti važeći TGT za ciljni AD nalog, uključujući NTLM hash naloga ako se koristi posebna Kerberos ekstenzija. Ekstenzija **`KERB-KEY-LIST-REQ`** se automatski uključuje da zatraži od DC-a da vrati NTLM hash ciljnog naloga u enkriptovanom odgovoru. Rezultat je keš kredencijala (`full_tgt.ccache`) za ciljni nalog *ili* povučeni NTLM hash lozinke.
 
-Uspeh napada i sticanje privilegija Domain Admin zavise od ispunjavanja određenih preduslova:
+5.  **Imitirati cilj i unaprediti se na administratora domena:** Sada napadač efikasno **kontroliše ciljni AD nalog**. Na primer, ako je cilj bio AD Connect **MSOL nalog**, ima prava replikacije na direktorijumu. Napadač može izvršiti **DCSync** napad koristeći kredencijale tog naloga ili Kerberos TGT da izvuče hash lozinki iz AD (uključujući domen KRBTGT nalog). Na primer:
+```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
+```
+Ovo izbacuje sve AD korisničke heš vrednosti lozinki, dajući napadaču KRBTGT heš (omogućavajući im da po volji falsifikuju Kerberos karte domena) i efektivno **Domain Admin** privilegije nad AD. Ako bi ciljni nalog bio neki drugi privilegovani korisnik, napadač bi mogao koristiti puni TGT za pristup bilo kojem resursu domena kao taj korisnik.
 
-- Sposobnost da se menjaju nalozi putem Synchronization API je ključna. To se može postići imajući ulogu Global Admin ili posedujući AD Connect sinhronizovani nalog. Alternativno, uloga Hybrid Identity Administrator bi bila dovoljna, jer omogućava upravljanje AD Connect-om i uspostavljanje novih sinhronizovanih naloga.
-- Prisutnost **hibridnog naloga** je neophodna. Ovaj nalog mora biti podložan izmeni sa podacima žrtvovanog naloga i takođe bi trebao biti dostupan za autentifikaciju.
-- Identifikacija **ciljnog naloga žrtve** unutar Active Directory je neophodna. Iako se napad može izvršiti na bilo kom nalogu koji je već sinhronizovan, Azure AD tenant ne sme imati replicirane on-premises identifikatore bezbednosti, što zahteva izmenu nesinhronizovanog naloga kako bi se dobila karta.
-- Pored toga, ovaj nalog bi trebao imati privilegije jednake privilegijama domain admin-a, ali ne sme biti član tipičnih AD administrator grupa kako bi se izbeglo generisanje nevažećih TGT-ova od strane AzureAD RODC-a.
-- Najpogodniji cilj je **Active Directory nalog koji koristi AD Connect Sync servis**. Ovaj nalog nije sinhronizovan sa Azure AD, ostavljajući njegov SID kao mogući cilj, i inherentno ima privilegije jednake privilegijama domain admin-a zbog svoje uloge u sinhronizaciji hešova lozinki (pod pretpostavkom da je Password Hash Sync aktivan). Za domene sa ekspresnom instalacijom, ovaj nalog je prefiksiran sa **MSOL\_**. Za druge instance, nalog se može identifikovati prebrojavanjem svih naloga koji imaju privilegije Directory Replication na objektu domena.
+6.  **Čišćenje:** Opcionalno, napadač može vratiti izmenjeni Azure AD korisnički `onPremisesSAMAccountName` i SID putem istog API-ja ili jednostavno obrisati bilo kog privremenog korisnika koji je kreiran. U mnogim slučajevima, sledeći Azure AD Connect sinhronizacijski ciklus automatski će vratiti neovlašćene promene na sinhronizovanim atributima. (Međutim, do tog trenutka šteta je učinjena -- napadač ima DA privilegije.)
+
+> [!WARNING]
+> Zloupotrebom mehanizma poverenja i sinhronizacije u oblaku, Global Admin Azure AD može da se pretvara u gotovo *bilo koji* AD nalog koji nije eksplicitno zaštićen RODC politikom, čak i ako taj nalog nikada nije bio sinhronizovan u oblaku. U podrazumevanoj konfiguraciji, ovo **uspostavlja potpuno poverenje od kompromitovanja Azure AD do kompromitovanja lokalnog 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/)
 
-### Potpuni napad <a href="#the-full-attack" id="the-full-attack"></a>
 
-Proverite to u originalnom postu: [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}}

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 - Default Applications
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-**Proverite tehniku na:** [**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)
-
-Blog post raspravlja o ranjivosti eskalacije privilegija u Azure AD, koja omogućava Application Admins ili kompromitovanim On-Premise Sync Accounts da eskaliraju privilegije dodeljivanjem kredencijala aplikacijama. Ranjivost, koja proističe iz "po dizajnu" ponašanja Azure AD u vezi sa upravljanjem aplikacijama i servisnim principalima, posebno utiče na podrazumevane Office 365 aplikacije. Iako je prijavljena, Microsoft ne smatra ovaj problem ranjivošću zbog dokumentacije o ponašanju dodele administratorskih prava. Post pruža detaljne tehničke uvide i savetuje redovne preglede kredencijala servisnih principala u Azure AD okruženjima. Za detaljnije informacije, možete posetiti originalni blog post.
-
-{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md

@@ -1,16 +1,17 @@
-# Az - Federacija
+# Az - Federation
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 ## Osnovne informacije
 
-[Iz dokumenata:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Federacija** je skup **domena** koje su uspostavile **povjerenje**. Nivo povjerenja može varirati, ali obično uključuje **autentifikaciju** i gotovo uvek uključuje **autorizaciju**. Tipična federacija može uključivati **broj organizacija** koje su uspostavile **povjerenje** za **zajednički pristup** skupu resursa.
+[Iz dokumenata:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
 
-Možete **federisati svoje on-premises** okruženje **sa Azure AD** i koristiti ovu federaciju za autentifikaciju i autorizaciju. Ova metoda prijavljivanja osigurava da se sva **autentifikacija korisnika odvija on-premises**. Ova metoda omogućava administratorima da implementiraju rigoroznije nivoe kontrole pristupa. Federacija sa **AD FS** i PingFederate je dostupna.
+>**Federacija** je skup **domena** koje su uspostavile **povjerenje**. Nivo povjerenja može varirati, ali obično uključuje **autentifikaciju** i gotovo uvek uključuje **autorizaciju**. Tipična federacija može uključivati **broj organizacija** koje su uspostavile **povjerenje** za **deljenje pristupa** skupu resursa.
+>Možete **federisati svoje on-premises** okruženje **sa Azure AD** i koristiti ovu federaciju za autentifikaciju i autorizaciju. Ova metoda prijavljivanja osigurava da se sva **autentifikacija korisnika dešava on-premises**. Ova metoda omogućava administratorima da implementiraju rigoroznije nivoe kontrole pristupa. Federacija sa **AD FS** i PingFederate je dostupna.
 
 <figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
 
-U suštini, u Federaciji, sva **autentifikacija** se odvija u **on-prem** okruženju i korisnik doživljava SSO kroz sva poverena okruženja. Stoga, korisnici mogu **pristupiti** **cloud** aplikacijama koristeći svoje **on-prem kredencijale**.
+U suštini, u Federaciji, sva **autentifikacija** se dešava u **on-prem** okruženju i korisnik doživljava SSO kroz sve poverene okruženja. Stoga, korisnici mogu **pristupiti** **cloud** aplikacijama koristeći svoje **on-prem kredencijale**.
 
 **Security Assertion Markup Language (SAML)** se koristi za **razmenu** svih informacija o autentifikaciji i autorizaciji između provajdera.
 
@@ -20,13 +21,11 @@ U bilo kojoj federacijskoj postavci postoje tri strane:
 - Provajder identiteta (IdP)
 - Provajder usluga (SP)
 
-(Slike sa 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="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>
 
-<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
-
-1. Prvo, aplikaciju (Provajder usluga ili SP, kao što je AWS konzola ili vSphere web klijent) pristupa korisnik. Ovaj korak može biti zaobiđen, vodeći klijenta direktno do IdP (Provajder identiteta) u zavisnosti od specifične implementacije.
+1. Prvo, aplikaciju (Provajder usluga ili SP, kao što su AWS konzola ili vSphere web klijent) pristupa korisnik. Ovaj korak može biti zaobiđen, vodeći klijenta direktno do IdP (Provajder identiteta) u zavisnosti od specifične implementacije.
 2. Zatim, SP identifikuje odgovarajući IdP (npr. AD FS, Okta) za autentifikaciju korisnika. Zatim kreira SAML (Security Assertion Markup Language) AuthnRequest i preusmerava klijenta na odabrani IdP.
-3. IdP preuzima, autentifikujući korisnika. Nakon autentifikacije, SAMLResponse formuliše IdP i prosleđuje SP-u kroz korisnika.
+3. IdP preuzima, autentifikujući korisnika. Nakon autentifikacije, SAMLResponse se formira od strane IdP-a i prosleđuje SP-u kroz korisnika.
 4. Na kraju, SP procenjuje SAMLResponse. Ako je uspešno validiran, što implicira odnos poverenja sa IdP-om, korisniku se odobrava pristup. Ovo označava završetak procesa prijavljivanja, omogućavajući korisniku da koristi uslugu.
 
 **Ako želite da saznate više o SAML autentifikaciji i uobičajenim napadima, idite na:**
@@ -35,46 +34,46 @@ U bilo kojoj federacijskoj postavci postoje tri strane:
 https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
 {{#endref}}
 
-## Pivotiranje
+## Pivoting
 
 - AD FS je model identiteta zasnovan na tvrdnjama.
 - "..tvrdnje su jednostavno izjave (na primer, ime, identitet, grupa), koje se daju o korisnicima, a koriste se prvenstveno za autorizaciju pristupa aplikacijama zasnovanim na tvrdnjama smeštenim bilo gde na Internetu."
 - Tvrdnje za korisnika se pišu unutar SAML tokena i zatim se potpisuju kako bi se obezbedila poverljivost od strane IdP-a.
 - Korisnik se identifikuje pomoću ImmutableID. On je globalno jedinstven i čuva se u Azure AD.
-- ImmutableID se čuva on-prem kao ms-DS-ConsistencyGuid za korisnika i/ili se može izvesti iz GUID-a korisnika.
+- ImmutableID se čuva on-premises kao ms-DS-ConsistencyGuid za korisnika i/ili se može izvesti iz GUID-a korisnika.
 - Više informacija na [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)
 
 **Golden SAML napad:**
 
 - U ADFS-u, SAML Response se potpisuje sertifikatom za potpisivanje tokena.
 - Ako je sertifikat kompromitovan, moguće je autentifikovati se na Azure AD kao BILO KOJI korisnik sinhronizovan sa Azure AD!
-- Baš kao i naš PTA zlostavljanje, promena lozinke za korisnika ili MFA neće imati nikakav efekat jer falsifikujemo odgovor na autentifikaciju.
+- Baš kao i naše zlostavljanje PTA, promena lozinke za korisnika ili MFA neće imati nikakav efekat jer falsifikujemo odgovor na autentifikaciju.
 - Sertifikat se može izvući sa AD FS servera sa DA privilegijama i zatim se može koristiti sa bilo kog računara povezanog na internet.
 - Više informacija na [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
 
 ### Golden SAML
 
-Proces u kojem **Provajder identiteta (IdP)** proizvodi **SAMLResponse** za autorizaciju prijavljivanja korisnika je od suštinskog značaja. U zavisnosti od specifične implementacije IdP-a, **odgovor** može biti **potpisan** ili **šifrovan** koristeći **privatni ključ IdP-a**. Ova procedura omogućava **Provajderu usluga (SP)** da potvrdi autentičnost SAMLResponse-a, osiguravajući da je zaista izdat od strane poverenog IdP-a.
+Proces u kojem **Provajder identiteta (IdP)** proizvodi **SAMLResponse** za autorizaciju prijavljivanja korisnika je od suštinskog značaja. U zavisnosti od specifične implementacije IdP-a, **odgovor** može biti **potpisan** ili **kriptovan** koristeći **privatni ključ IdP-a**. Ova procedura omogućava **Provajderu usluga (SP)** da potvrdi autentičnost SAMLResponse-a, osiguravajući da je zaista izdat od strane poverenog IdP-a.
 
-Može se povući paralela sa [napadom zlatne karte](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), gde se ključ koji autentifikuje identitet i dozvole korisnika (KRBTGT za zlatne karte, privatni ključ za potpisivanje tokena za zlatni SAML) može manipulisati da **falsifikuje objekat autentifikacije** (TGT ili SAMLResponse). Ovo omogućava impersonaciju bilo kog korisnika, dajući neovlašćen pristup SP-u.
+Može se povući paralela sa [napadom zlatne karte](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), gde se ključ koji autentifikuje identitet i dozvole korisnika (KRBTGT za zlatne karte, privatni ključ za potpisivanje tokena za zlatne SAML) može manipulisati da **falsifikuje objekat autentifikacije** (TGT ili SAMLResponse). Ovo omogućava impersonaciju bilo kog korisnika, dajući neovlašćen pristup SP-u.
 
-Zlatni SAML nudi određene prednosti:
+Zlatni SAML-ovi nude određene prednosti:
 
 - Mogu se **kreirati na daljinu**, bez potrebe da budu deo domena ili federacije u pitanju.
 - Ostaju efikasni čak i sa **dvofaktorskom autentifikacijom (2FA)** uključenom.
 - Privatni ključ za potpisivanje **tokena se automatski ne obnavlja**.
 - **Promena lozinke korisnika ne poništava** već generisani SAML.
 
-#### AWS + AD FS + Zlatni SAML
+#### AWS + AD FS + Golden SAML
 
 [Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) je Microsoftova usluga koja olakšava **sigurnu razmenu informacija o identitetu** između poverenih poslovnih partnera (federacija). U suštini, omogućava usluzi domena da deli identitete korisnika sa drugim provajderima usluga unutar federacije.
 
 Sa AWS-om koji veruje kompromitovanom domenu (u federaciji), ova ranjivost se može iskoristiti da potencijalno **dobije bilo koje dozvole u AWS okruženju**. Napad zahteva **privatni ključ koji se koristi za potpisivanje SAML objekata**, slično kao što je potrebno KRBTGT u napadu zlatne karte. Pristup AD FS korisničkom nalogu je dovoljan da se dobije ovaj privatni ključ.
 
-Zahtevi za izvođenje napada zlatnog SAML uključuju:
+Zahtevi za izvođenje napada zlatnog SAML-a uključuju:
 
 - **Privatni ključ za potpisivanje tokena**
-- **IdP javni sertifikat**
+- **Javni sertifikat IdP-a**
 - **Ime IdP-a**
 - **Ime uloge (uloga koja se preuzima)**
 - Domen\korisničko ime
@@ -83,7 +82,7 @@ Zahtevi za izvođenje napada zlatnog SAML uključuju:
 
 _Samo stavke u podebljanom su obavezne. Ostale se mogu popuniti po želji._
 
-Da biste dobili **privatni ključ**, potreban je pristup **AD FS korisničkom nalogu**. Odatle, privatni ključ se može **izvesti iz lične biblioteke** koristeći alate kao što je [mimikatz](https://github.com/gentilkiwi/mimikatz). Da biste prikupili druge potrebne informacije, možete koristiti Microsoft.Adfs.Powershell snapin na sledeći način, osiguravajući da ste prijavljeni kao ADFS korisnik:
+Da biste dobili **privatni ključ**, potreban je pristup **AD FS korisničkom nalogu**. Odatle, privatni ključ se može **izvesti iz lične prodavnice** koristeći alate kao što je [mimikatz](https://github.com/gentilkiwi/mimikatz). Da biste prikupili druge potrebne informacije, možete koristiti Microsoft.Adfs.Powershell snapin na sledeći način, osiguravajući da ste prijavljeni kao ADFS korisnik:
 ```bash
 # From an "AD FS" session
 # After having exported the key with mimikatz
@@ -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 -> cloud
 ```bash

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 @@
+# Hibridni identitet razne napade
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+## Prisilna sinhronizacija Entra ID korisnika sa on-prem
+
+Kao što je pomenuto u [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), bilo je moguće promeniti vrednost **`ProxyAddress`** unutar AD korisnika u on-prem AD dodajući email Entra ID admin korisnika i takođe osigurati da se UPN korisnika u AD i u Entra ID poklapaju (ovo je ponovo Entra ID), kao **`SMTP:admin@domain.onmicrosoft.com`**. I ovo bi **prisililo sinhronizaciju ovog korisnika** iz Entra ID u on-prem AD, tako da ako je lozinka korisnika bila poznata, mogla bi se koristiti za **pristup adminu korišćenom u Entra ID.**
+
+Da bi se sinhronizovao novi korisnik iz Entra ID u on-prem AD, ovo su zahtevi, jedini zahtevi su:
+
+- Kontrolisati atribute korisnika u on-prem AD (ili imati dozvole za kreiranje novih korisnika)
+- Poznavati korisnika koji je samo u cloudu da bi se sinhronizovao iz Entra ID u on-prem AD
+- Takođe, možda će biti potrebno promeniti immutableID atribut sa Entra ID korisnika na on-prem AD korisnika da bi se uradio **hard match**.
+
+
+> [!CAUTION]
+> Entra ID više ne dozvoljava sinhronizaciju admina iz Entra ID u on-prem AD.
+> Takođe, ovo **neće zaobići MFA**.
+
+
+
+## Reference
+
+- [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}}

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- Sinhronizacija novih korisnika
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-## Sinhronizacija AzureAD korisnika sa on-prem da bi se eskaliralo sa on-prem na AzureAD
-
-Da bi se sinhronizovao novi korisnik **iz AzureAD u on-prem AD**, potrebni su sledeći uslovi:
-
-- **AzureAD korisnik** treba da ima proxy adresu (jednu **mailbox**)
-- Licenca nije potrebna
-- Ne sme **već biti sinhronizovan**
-```bash
-Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
-```
-Kada se korisnik poput ovih pronađe u AzureAD, da biste **pristupili njemu iz on-prem AD** potrebno je samo da **kreirate novi nalog** sa **proxyAddress** SMTP email-om.
-
-Automatski, ovaj korisnik će biti **sinhronizovan iz AzureAD u on-prem AD korisnika**.
-
-> [!CAUTION]
-> Imajte na umu da za izvođenje ovog napada **ne trebate Domain Admin**, samo su vam potrebne dozvole da **kreirate nove korisnike**.
->
-> Takođe, ovo **neće zaobići MFA**.
->
-> Štaviše, prijavljeno je da **sinhronizacija naloga više nije moguća za admin naloge**.
-
-## References
-
-- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
-
-{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md

@@ -3,7 +3,7 @@
 {{#include ../../../../banners/hacktricks-training.md}}
 
 > [!NOTE]
-> Imajte na umu da **neke granularne dozvole** koje imaju ugrađene uloge u Entra ID **nisu podobne za korišćenje u prilagođenim ulogama.**
+> Imajte na umu da **ne dozvoljavaju sve granularne dozvole** ugrađene u uloge u Entra ID **da se koriste u prilagođenim ulogama.**
 
 ## Uloge
 
@@ -79,7 +79,7 @@ az ad app owner list --id <appId>
 
 Napadač može dodati URI za preusmeravanje aplikacijama koje koriste korisnici tenanta i zatim podeliti sa njima URL-ove za prijavu koji koriste novi URL za preusmeravanje kako bi ukrao njihove tokene. Imajte na umu da, ako je korisnik već bio prijavljen u aplikaciju, autentifikacija će biti automatska bez potrebe da korisnik bilo šta prihvati.
 
-Imajte na umu da je takođe moguće promeniti dozvole koje aplikacija zahteva kako bi dobila više dozvola, ali u ovom slučaju korisnik će morati ponovo da prihvati prompte koji traže sve dozvole.
+Imajte na umu da je takođe moguće promeniti dozvole koje aplikacija zahteva kako bi dobila više dozvola, ali u ovom slučaju korisnik će morati ponovo da prihvati prozor koji traži sve dozvole.
 ```bash
 # Get current redirect uris
 az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUris"
@@ -110,7 +110,7 @@ az ad sp credential reset --id <sp-id> --append
 ```
 ### `microsoft.directory/servicePrincipals/owners/update`
 
-Slično aplikacijama, ova dozvola omogućava dodavanje više vlasnika servisa. Vlasništvo nad servisom omogućava kontrolu nad njegovim akreditivima i dozvolama.
+Slično aplikacijama, ova dozvola omogućava dodavanje više vlasnika servisa. Vlasništvo nad servisnim principalom omogućava kontrolu nad njegovim akreditivima i dozvolama.
 ```bash
 # Add new owner
 spId="<spId>"
@@ -132,11 +132,11 @@ az ad sp owner list --id <spId>
 
 ### `microsoft.directory/servicePrincipals/disable` i `enable`
 
-Ove dozvole omogućavaju onemogućavanje i omogućavanje servisnih principala. Napadač bi mogao iskoristiti ovu dozvolu da omogući servisnog principala do kojem bi mogao doći na neki način kako bi eskalirao privilegije.
+Ove dozvole omogućavaju onemogućavanje i omogućavanje servisnih principala. Napadač bi mogao iskoristiti ovu dozvolu da omogući servisnog principala do kojem bi mogao nekako da dođe kako bi eskalirao privilegije.
 
-Napomena da će za ovu tehniku napadač trebati više dozvola kako bi preuzeo omogućeni servisni principala.
+Napomena: za ovu tehniku napadač će trebati više dozvola kako bi preuzeo omogućeni servisni principala.
 ```bash
-bashCopy code# Disable
+# Disable
 az ad sp update --id <ServicePrincipalId> --account-enabled false
 
 # Enable
@@ -164,6 +164,14 @@ az rest --method POST \
 --headers "Content-Type=application/json" \
 --body "{\"id\": \"$credID\"}"
 ```
+### Aplikacije za eskalaciju privilegija
+
+**Kao što je objašnjeno u [ovom postu](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, bilo je veoma uobičajeno pronaći podrazumevane aplikacije koje imaju **API dozvole** tipa **`Application`** dodeljene njima. API dozvola (kako se naziva u Entra ID konzoli) tipa **`Application`** znači da aplikacija može pristupiti API-ju bez korisničkog konteksta (bez prijave korisnika u aplikaciju), i bez potrebe za Entra ID rolama da bi to omogućila. Stoga, veoma je uobičajeno pronaći **aplikacije sa visokim privilegijama u svakoj Entra ID tenantu**.
+
+Dakle, ako napadač ima bilo koju dozvolu/rolu koja omogućava **ažuriranje kredencijala (tajna ili sertifikat) aplikacije**, napadač može generisati nove kredencijale i zatim ih koristiti da **se autentifikuje kao aplikacija**, stičući sve dozvole koje aplikacija ima.
+
+Napomena da pomenuti blog deli neke **API dozvole** uobičajenih Microsoft podrazumevanih aplikacija, međutim, nakon ovog izveštaja Microsoft je ispravio ovaj problem i sada nije moguće prijaviti se kao Microsoft aplikacije. Ipak, još uvek je moguće pronaći **prilagođene aplikacije sa visokim privilegijama koje bi mogle biti zloupotrebljene**.
+
 ---
 
 ## Grupe
@@ -178,7 +186,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
 
 ### `microsoft.directory/groups/owners/update`
 
-Ova dozvola omogućava postajanje vlasnikom grupa. Vlasnik grupe može kontrolisati članstvo i podešavanja grupe, potencijalno povećavajući privilegije unutar grupe.
+Ova dozvola omogućava postajanje vlasnikom grupa. Vlasnik grupe može kontrolisati članstvo u grupi i podešavanja, potencijalno povećavajući privilegije u grupi.
 ```bash
 az ad group owner add --group <GroupName> --owner-object-id <UserId>
 az ad group member add --group <GroupName> --member-id <UserId>
@@ -187,7 +195,7 @@ az ad group member add --group <GroupName> --member-id <UserId>
 
 ### `microsoft.directory/groups/members/update`
 
-Ova dozvola omogućava dodavanje članova u grupu. Napadač bi mogao da doda sebe ili zlonamerne naloge u privilegovane grupe, što može omogućiti povišen pristup.
+Ova dozvola omogućava dodavanje članova u grupu. Napadač može dodati sebe ili zlonamerne naloge u privilegovane grupe, što može omogućiti povišen pristup.
 ```bash
 az ad group member add --group <GroupName> --member-id <UserId>
 ```
@@ -274,7 +282,7 @@ az rest --method POST \
 ```
 ### `microsoft.directory/deviceLocalCredentials/password/read`
 
-Ova dozvola omogućava napadačima da čitaju svojstva sačuvanih kredencijala lokalnog administratorskog naloga za uređaje povezane sa Microsoft Entra, uključujući lozinku.
+Ova dozvola omogućava napadačima da čitaju svojstva rezervnih lokalnih administratorskih naloga za uređaje povezane sa Microsoft Entra, uključujući lozinku.
 ```bash
 # List deviceLocalCredentials
 az rest --method GET \

src/pentesting-cloud/azure-security/az-services/az-front-door.md

@@ -0,0 +1,18 @@
+# Az - Deljenje fajlova
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## RemoteAddr Bypass
+
+Ovaj **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** objašnjava kako, kada konfigurišete neka mrežna ograničenja sa Azure Front Door, možete filtrirati na osnovu **`RemoteAddr`** ili **`SocketAddr`**. Glavna razlika je u tome što **`RemoteAddr`** zapravo koristi vrednost iz **`X-Forwarded-For`** HTTP header-a, što ga čini veoma lakim za zaobilaženje.
+
+Za zaobilaženje ovog pravila mogu se koristiti automatizovani alati koji **brute-force IP adrese** dok ne pronađu važeću.
+
+Ovo je pomenuto u [Microsoft dokumentaciji](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).
+
+
+## Reference
+
+- [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}}