Além do Óbvio: Utilizando o AdminSDHolder para manter acesso duradouro ao Active Directory

Introdução

Há algum tempo, escrevi sobre o AdminSDHolder e o processo SDProp.

Aos que não leram esse artigo, clique aqui.

Hoje, mostrarei como um atacante pode utilizar esse recurso para manter a persistência no ambiente.

Quando um invasor compromete o Active Directory, seu objetivo é permanecer oculto e manter seu acesso pelo maior tempo possível.

Isso dará a ele o tempo e as condições necessárias para atingir seu objetivo e invariavelmente gerar danos catastróficos aos ambientes atacados.

A persistência é alcançada por meio de técnicas que permitem que um invasor mantenha controle contínuo sobre o ambiente.

Entre as maneiras de manter a persistência no Active Directory temos:

Concessão de Permissões: O invasor pode conceder permissões elevadas  a uma conta pré-existente. Muitas vezes, a conta utilizada é uma conta acima de qualquer suspeita, o que torna a detecção mais difícil.

Criação de Contas de Administrador: O invasor pode criar uma nova conta de administrador no Active Directory, concedendo a essa conta (e, consequentemente a si mesmo) privilégios elevados.

Replicação de Objetos: Uma tática mais avançada envolve replicar um objeto inteiro do AD para um controlador de domínio falso, permitindo que o invasor controle esse objeto sem ser detectado2.

Nesse artigo, mostrarei como isso funciona na pratica, utilizando o AdminSDHolder. 

Aqui, me focarei no primeiro caso: Concessão de Permissões.

Ponto importante: Isso NÃO deve ser utilizado para NENHUM outro fim, senão estudos e a proteção dos mais diversos ambientes tecnológicos que utilizam o Active Directory.

Ambiente de testes

Para essa simulação, criei em um ambiente virtual uma foresta e domínio do Active Directory chamado "Contoso.com", executando o Windows Server 2022 Datacenter, e inseri como membro desse domínio uma estação de trabalho Windows 11 Enterprise com o RSAT instalado.

Não é objetivo desse artigo ensinar como instalar o Windows Server, Windows Client e nem orientar a criação de uma nova floresta do Active Directory.

Ainda assim, os links abaixo lhe ajudará na criação do seu ambiente de estudos:

Download da versão de avaliação do Windows Server 2022: Windows Server 2022 | Centro de Avaliação da Microsoft

Instalação do Windows Server 2022: Implantação, configuração e administração do Windows Server - Training | Microsoft Learn

Download da versão de avaliação do Windows 11: Download Windows 11 (microsoft.com)

Procedimento

Para essa simulação, estou utilizando uma conta privilegiada supostamente comprometida em fases anteriores do ataque.

Lembre-se de que o atacante, em fases anteriores pode enumerar todas as contas do domínio ou somente contas que sejam membros de grupos administrativos e, dessa forma tentar comprometer uma ou mais contas.

Publiquei um artigo bem legal sobre enumeração de contas no Active Directory e como se proteger. Se você não leu, clique aqui antes de prosseguir.

Assim, efetuei logon com uma conta de usuário privilegiada padrão, denominada "administrator" (SID 500), em um controlador de domínio Windows Server 2022 Datacenter, membro de um domínio denominado contoso.com.

1- Abra o  "Active Directory Users and Computers" (dsa.msc);

2- Clique em "View" e a seguir clique em "Advanced Features";

3- Expanda o nome do domínio, clique em "SYSTEM" e a seguir clique com o botão direito do mouse em "AdminSDHolder" e a seguir, clique em "Properties".

4- Nessa simulação, utilizarei uma conta de usuário comum denominada "andre".

Conforme abaixo, essa conta não é membro de nenhum grupo altamente privilegiado.

5- Clique na guia "Security" do objeto "AdminSDHolder" e adicione uma conta de usuário não privilegiada (ou grupo) às permissões de objeto e conceda permissão de "Full Control".

6- Execute o processo "SDProp" manualmente. Para isso:

• No controlador de domínio que hospeda o mestre de operação (FSMO) PDC Emulator, inicie "Ldp.exe". Para isso, clique em "Start" \ "Run" \ digite "ldp.exe" e clique em OK.

Observação: Não é necessário estar conectado diretamente no PDC Emulator, pois o utilitário ldp.exe permite que se faça conexão remota para outros controladores de domínio.

• Na caixa de diálogo Ldp, clique em "Connection" e a seguir, clique em "Connect".

• Na caixa de diálogo "Connect", digite o nome do controlador de domínio que contém a função PDCe (PDC Emulator) e clique em OK.

Após conectado, imagem semelhante a evidenciada abaixo será exibida.

• Clique novamente em "Connection" e a seguir clique em "Bind".

• Na guia "Bind", digite as credenciais de uma conta de usuário que tenha permissão para modificar o objeto rootDSE.

Nesse exemplo, já estou conectado com esse usuário. Assim, basta manter selecionada a opção "Bind as currently logged on user" e clicar em OK.

Se houver êxito, aparecerá imagem semelhante a evidencia abaixo.

• Concluída a etapa anterior, clique em "Browse" e a seguir clique em "Modify".
• Na caixa de diálogo "Modify", deixe o campo DN em branco. No campo "Edit Entry Attribute", digite "RunProtectAdminGroupsTask" e, no campo "Values", digite 1.
• Clique em "Enter" para preencher a lista de entradas, e depois clique em "Run".

Após isso, feche a caixa de dialogo "Modify".

Observação - 01: Por padrão, o processo SDProp é executado a cada 60 minutos no controlador de domínio que hospeda a função de PDC Emulator. Assim, a execução manual do SDProp não é mandatória. Basta ter um pouco de paciência e aguardar a execução automática.

Observação - 02: O intervalo padrão para a execução do SDProp pode ser alterado adicionando uma chave do tipo DWORD denominada "AdminSDProtectFrequency" em "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" e definindo o novo intervalo em segundos.

7- Observe agora que a conta inserida no "AdminSDHolder" (andre) recebeu permissão de controle total não só na conta do administrator padrão, mas também na conta do KRBTGT, no grupo "Domain Admins" e nos demais os grupos protegidos pelo AdminSDHolder.

Isso significa que, embora essa conta não seja membro direto ou indireto de nenhum grupo privilegiado, a partir de agora, ela pode modificar os membros dos grupos protegidos pelo AdminSDHolder e, inclusive inserir a si própria como membro desses grupos. 

E aí, a dor de cabeça pode ser grande!!!

Vejamos abaixo a nova permissão refletida em alguns grupos protegidos pelo AdminSDHolder.

 

  

Agora, vamos para a parte que ninguém mostra!

1- Com a conta denominada "andre" (que não é membro de nenhum grupo privilegiado), me conectei a uma estação de trabalho Windows 11 Enterprise que possui as ferramentas de administração do Active Directory instalada.

2- Na estação de trabalho, abra o "Active Directory Users and Computers" (dsa.msc). Para isso, clique em "Iniciar" \ "Executar" \ digite "dsa.msc" e clique em OK.

                                  

3- No "Active Directory Users and Computers", localize o grupo "Enterprise Admins", clique com o botão direito do mouse sob o grupo e selecione a opção "Propriedades".

4- Na guia "Membros", clique em "Adicionar".

5- Adicione a conta de usuário que até agora não é membro de nenhum grupo privilegiado e que recebeu permissão de "Controle Total" no objeto "AdminSDHolder". Após isso clique em OK duas vezes seguidas.

6- Você pode estar pensando:

Não tem problema!!!

Podemos usar o comando: Add-ADGroupMember -Identity "Domain Admins" -Members andre e dessa forma, uma conta não privilegiada se adicionará ao grupo "Domain Admins".

7- E você pode estar pensando:

Não tem problema!!!

Vamos pelo mais básico: o bom e velho comando net group "Schema Admins" andre /add /domain.

E o resultado será o mesmo!!!

Terei adicionado a minha própria conta ao grupo "Schema Admins".

8- Quando uma conta é inserida a um grupo, é necessário efetuar logoff e um novo logon para que um novo ticket seja emitido e que esse ticket contenha o SID dos grupos aos quais a conta foi inserida.

9- Após o logon, utilizaremos novamente o comando "Get-ADUser andre -Property memberof" para obtermos a informação sobre associação de grupos da conta andre.

Observe que agora a conta "andre" é membro de 03 grupos altamente privilegiados.

10- Com esse método o atacante pode simplesmente resetar a senha do administrator!!!

Vejamos:

Para essa nova simulação, eu removi a conta do usuário andre dos 03 grupos altamente privilegiados, efetuei logoff e um novo logon na estação Windows 11.

Agora estou logado com uma conta comum, certo?

Errado!!!

Essa conta não é membro de nenhum grupo privilegiado, mas lembre-se de que ela recebeu permissão de controle total no AdminSDHolder!!!

E, consequentemente, isso concede a ela controle total na conta do administrator!!!

Para resetar a senha do administrator do domínio, sem ser membro de nenhum grupo privilegiado, basta executar o comando Set-ADAccountPassword -Identity administrator -Reset e alterar a senha.

E sim, essa alteração de senha pode ser efetuada por outros meios além desse comando em powershell.

Conclusão

Nesse artigo, vimos passo a passo como o AdminSDHolder pode ser utilizado para que um atacante se mantenha em um ambiente previamente comprometido.

Esse é um método simples e EXTREMAMENTE eficaz, visto que pouquíssimos administradores do Active Directory conhecem de fato o que é o AdminSDHolder, o processo SDProp e o atributo AdminCount (já mencionado em outro artigo).

Ao entender como o AdminSDHolder funciona, como ele afeta as permissões dos objetos por ele protegidos, e principalmente como um atacante age para se manter no ambiente, você torna-se melhor preparado para proteger esse ambiente adequadamente.

No próximo post falarei sobre como monitorar as ACLs do AdminSDHolder e dessa forma se tornar capaz de detectar alterações.

Lembre-se: Não podemos proteger o que desconhecemos!!!

Espero que tenham gostado e que esse conteúdo contribua de alguma forma para a disseminação do conhecimento na comunidade técnica.

Abraço

Ándré Martins

Enumeração de usuários e grupos do Active Directory

Em um ambiente corporativo, o Active Directory é o serviço de diretório mais utilizado para gerenciamento contas de usuários, grupos e permissões de rede.

Embora o Active Directory seja bastante robusto, ele possui algumas configurações padrão que normalmente são exploradas por invasores que já tenham acesso a uma conta de usuário comum, previamente comprometida.

É certo que, em algum momento o atacante buscará informações sobre contas altamente privilegiadas - como por exemplo, as pertencentes aos grupos "Domain Admins" e "Enterprise Admins" - e para isso, é necessário enumerar usuários e grupos no domínio.

Cenário

Imaginem que uma conta de usuário comum chamada "andre" tenha sido comprometida.

O invasor, agora com acesso ao sistema, tentará enumerar outras contas e grupos no Active Directory para posteriormente tentar uma escalação de privilégios.

Por padrão, qualquer usuário autenticado no domínio possui acesso de leitura ao Active Directory e consequentemente pode fazer essa enumeração.

O objetivo do invasor é encontrar contas com privilégios elevados e utilizar outros métodos para comprometer essas contas.

Por exemplo, ele pode testar a senha "Password1", que pode ser válida devido a políticas de senha fracas, por exemplo.

Este processo pode ser feito sem gerar alertas de bloqueio de contas, pois muitas vezes a enumeração de usuários é permitida por padrão para qualquer usuário autenticado.

Enumeração de Usuários e Grupos: Passo a Passo

Para esse artigo, efetuei logon com uma conta de usuário comum, denominada "andre", em uma estação de trabalho Windows 11 Enterprise, membro de um domínio denominado contoso.com.

Conforme abaixo, o comando "whoami" foi utilizado para exibir quem estava conectado, e o comando "systeminfo" foi utilizado para coletar evidencias do sistema operacional utilizado nessa simulação.

Um outra evidencia importante a apresentar, é que a conta "andre" não é membro de nenhum grupo altamente privilegiado.

Para isso, o comando "Whoami /groups | findstr -i "Builtin" pode nos ajudar.

O comando Whoami /groups lista todos os grupos dos quais o usuário faz parte, mostrando o nível de permissões de cada um.

Mas também podemos fazer essa consulta diretamente no "Active Directory Users and Computers".

Enumerando usuários e grupos do Active Directory

Logado com o usuário andre, utilizarei o comando "net user /domain" e dessa forma, obtenho uma lista de todos os usuários do domínio "contoso.com".

Mas o que interessa mesmo, é obter a lista de usuários membros de grupos privilegiados.

Para obter a lista de membros do grupo "Domain Admins", utilizo o comando "net group "domain admins" /domain".

Dessa forma, posso ver que, além da conta padrão "Administrator", os usuários "Axl" e "Paul" também são membros do grupo "Domain Admins".

Para listar os membros do grupo Enterprise Admins, utilizo o mesmo comando, trocando somente o nome do grupo. Nesse caso, será: "net group "Enterprise admins" /domain".

Como mitigar essa vulnerabilidade?

Para mitigar essa vulnerabilidade, é necessário negar a permissão de leitura no domínio. 

Podemos fazer isso de forma granular, inserindo explicitamente os usuários que terão essa permissão negada, mas a melhor forma é utilizar um grupo de segurança no Active Directory.

Para isso:

1- Criar um grupo de segurança no AD chamado "Desabilitar Enumeracao" (criatividade zero!!! ... 😂😂😂) e adicionar os usuários a esse grupo. Nesse exemplo, adicionei somente o usuário "andre" ao grupo.

2- Abra o  "Active Directory Users and Computers";

3- Na raiz do domínio, clique com o botão direito do mouse e selecione "Propriedades";

4- Na aba "Security", clique em "Add", e adicione o grupo recém criado. Após isso, negue explicitamente a permissão de "Read". Feito isso, clique em "OK".

3- Repetindo os Comandos Após a mitigação

Após a criação do grupo "Desabilitar enumeração" e a aplicação da permissão restritiva, o usuário "andre" tentará repetir os comandos de enumeração.

Para isso, é necessário efetuar logoff e logon novamente na estação de trabalho, para que um novo ticket seja emitido para o usuário "andre", contendo o SID do grupo recém criado.

Conforme evidencia abaixo, estou logado com o usuário andre (que não é membro de nenhum grupo privilegiado) e através do comando "whoami /groups", posso verificar que a conta é membro do grupo denominado "Desabilitar Enumeracao".

Agora, com o usuário andre, utilizarei novamente o comando "net user /domain" para tentar enumerar todos os usuários do domínio "contoso.com".

Observe que, o mesmo procedimento e comando que antes do bloqueio me permitiu listar todos os usuários do domínio, agora não permite mais.

Conforme abaixo, o mesmo ocorrerá ao tentar listar os membros dos grupos "Domain Admins" e "Enterprise Admins".

Ponto importante: Antes de implementar essa mitigação em larga escala, é importante saber quais são os usuários e grupos que DEVEM possuir permissão para tal enumeração e obviamente não inseri-los ao grupo criado para esse fim.

Além disso, é importante conhecer quais aplicações estão em execução no ambiente e que fazem enumerações legitimas no Active Directory, pois se as contas utilizadas por essas aplicações forem impedidas de enumerar, o funcionamento da aplicação pode ser prejudicado.

Conclusão

A enumeração de usuários e grupos no Active Directory é uma vulnerabilidade comumente explorada quando uma conta de usuário comum é comprometida.

Embora o Active Directory permita a enumeração por padrão, é possível mitigar esse risco restringindo permissões de leitura no domínio.

Medidas como criar grupos restritivos, aplicar políticas de senha robustas e monitorar o comportamento de contas de usuário são importantes para a proteção do ambiente.

Espero que tenham gostado!

Obrigado e até o próximo post.

Perdi a senha do Active Directory. E agora?

PessoALL, me deparei com uma situação bastante delicada há algum tempo: Um amigo foi contratado para atender uma empresa de comércio varejista que teve seu único administrador de rede demitido recentemente.

Embora existisse documentação da rede, as senhas nela contida (o objetivo aqui não é discutir a efetividade de se informar senhas em arquivos diversos), proposital ou não, não condiziam com a realidade.

O resultado prático disso era que simplesmente não era possível acessar os servidores com usuário administrativo e por consequência, executar absolutamente nenhuma tarefa administrativa. Vocês tem noção do impacto disso?

A questão chave era: Sem possuir a senha atual, é possível redefinir a senha do Windows, tanto local, quanto do AD ou perdi definitivamente meu ambiente e teremos que recriar tudo?

E a resposta é bem simples: Sim, é possível redefinir essa senha facilmente utilizando recursos nativos do sistema operacional, sem depender em nada de ferramentas de terceiros.

Com acesso físico ao ambiente, o resto é comigo ... rsrsrsrs.

Contrariando as boas práticas, o ambiente desse cliente era composto por um único servidor físico com a role de Hyper-V instalada, trabalhando no modo standalone, que hospeda 3 máquinas virtuais (AD, BD e TS).

Para romper essa barreira, tanto na máquina física quanto no AD, o procedimento é o mesmo, bastante simples e detalharei aqui.

Antes disso, me é importantíssimo mencionar que como vocês poderão ver, utilizei recursos nativos do sistema operacional, sem uso de absolutamente nenhuma ferramenta de terceiros. 

Igualmente importante, é mencionar que o objetivo aqui é contribuir com a comunidade técnica, e JAMAIS incentivar práticas delituosas.

Vamos lá ...

Na ocasião, o sistema operacional dos servidores era Windows Server 2012.

Nesse artigo, os testes foram efetuados no Windows 2016 e não houve nenhuma mudança no procedimento, quando comparado ao Windows 2012

Testei novamente hoje (13/09/2024) no Windows 2022 e houve uma pequena mudança que explicarei mais à frente.

O primeiro passo foi baixar uma ISO do Windows Server (disponível em Windows Server 2022 | Centro de Avaliação da Microsoft) e preparar um pen-drive bootável que foi utilizado na máquina física.

Para o servidor que desempenha a função de Active Directory (virtual), basta montar a ISO na máquina virtual responsável pela execução do AD DS.

Mostrarei o passo a passo em meu ambiente de LAB, onde possuo um controlador de domínio denominado SRV1, controlador do domínio MCSE-BRASIL.

Vamos lá: 

1-     Nas propriedades de configuração da máquina virtual, montar a ISO do Windows Server e alterar a ordem de boot para que a máquina virtual inicie pela ISO;

2-     Ao iniciar o servidor, pressionar qualquer tecla para dar boot pelo DVD;

3-     Na tela inicial de instalação do Windows, clicar em Next;

4-     Na tela seguinte, clicar em "Repair Your Computer";

5-     Na tela seguinte, clicar em "Troubleshoot";

6-     Na tela seguinte, clicar em "Command Prompt".

OBS: Em algumas versões de SO, será necessário clicar em "Advanced Options" antes de clicar em "Command Prompt".

 7-     No prompt do DOS executar o seguinte comando: Move C:\Windows\System32\Utilman.exe C:\Windows\System32\Utilman0.exe

8-   Ainda no prompt do DOS executar o seguinte comando: Copy C:\Windows\System32\cmd.exe C:\Windows\System32\Utilman.exe

 9-   No prompt do DOS, executar o comando "exit" para retornar à tela inicial.

10- Na tela inicial, clique em "Continue" para reiniciar o servidor;

11-  Após o startup do servidor, na tela de login, clicar em "Easy of Access" ou pressionar as teclas "Win+U";

 12-  No prompt de comando, digitar o seguinte comando: net user Administrator "Nova_Senha" (Sem aspas) /Domain.

Para essa demonstração, utilizei a senha Pa55w.rd.

13-  Concluído o comando, digitar "exit";

14- Na tela de login, digitar a senha recém definida (nesse caso, Pa55w.rd) para o usuário administrator e comemorar ... rsrsrs.

OBS: Se houver a necessidade de alterar a senha de outro usuário qualquer, basta trocar o nome “Administrator”, pelo nome do usuário no comando net user. Caso a senha a ser alterada senha local, remover o parâmetro /Domain do comando net user.

Além disso, por esse método é possível criar novos usuários no Active Directory e inseri-los em grupos privilegiados.

Simples, não???.

Mas calma lá ... acima, mencionei que no Windows Server 2022 foram necessários alguns passos adicionais.

Ocorre que, ao chegarmos no prompt de comando, o acesso ao C:\ não era possível.

Para contornar essa dificuldade, procedi da seguinte forma:

1- Ainda no prompt, ANTES de executar o comando move, digite "diskpart";

2- A seguir, digite "list volume" para identificar o volume que corresponde ao C:\;

3- A seguir, digite "select volume "ID_do_volume". No meu caso foi "select volume 1"

4- Após isso, atribua uma letra de unidade através do comando "assign letter=C"

5- E por fim, digite "exit" para sair do "diskpart".

Espero mais uma vez ter contribuído com a comunidade técnica em um tema tão relevante quanto esse.

Abraço e até o próximo artigo.