Uma abordagem prática aos Ataques AD

Se você deseja entender o AD e seus conceitos de segurança associados, primeiro precisa conhecer a anatomia das violações do AD de uma maneira extremamente clínica. Para isso, vamos dar uma olhada na metodologia de ataque AD da perspectiva de um invasor:

• Sua estratégia final: O objetivo final dos invasores AD é obter o controle do ambiente AD da vítima.

• O ganho lucrativo: a superfície de ataque do AD, uma vez exposta, fornece aos invasores acesso às contas e serviços mais críticos do AD. Com esse acesso privilegiado, os invasores obtêm passagem não regulamentada para identidades confidenciais e seus dados associados para maior comprometimento e exploração.

• A abordagem escolhida: os invasores buscam acesso a dados altamente confidenciais ou a contas e grupos de usuários altamente privilegiados. Os invasores assumem o controle, comprometem a infraestrutura do AD por meio das táticas abordadas abaixo e, em seguida, fazem demandas de natureza monetária e outras que acabam prejudicando a vítima.

• As táticas empregadas: os invasores procuram criar, modificar e gerenciar a infraestrutura do AD, ou seja, se passar por administradores de domínio e operar dentro da rede comprometida, exercendo os mais altos privilégios de acesso. As táticas usadas para obter a entrada inicial podem ser realizadas por meio de e-mails de phishing, ferramentas de script de código aberto, como Mimikatz, ou por meio de portas abertas vulneráveis, como no caso de ataques RDP.
• As próximas etapas: quando um invasor obtém acesso ao ambiente AD, ele se move lateralmente e trabalha para fortalecer seu controle sobre recursos e dados que não são destinados a eles. E é assim que sua exploração começa.

Nesse estágio, os invasores podem fazer quase tudo de dentro da infraestrutura do AD.

Eles podem:

• • Passar despercebidos para monitorar e explorar quaisquer configurações incorretas no design do AD.
  • Alterar a associação de grupo de grupos de administradores de domínio para entorpecer o controle do AD por seus administradores legítimos. Por exemplo, após fazer a entrada inicial, o grupo de administradores de domínio pode ser monitorado quanto a quaisquer vulnerabilidades, incluindo usuários com privilégios excessivos ou outras configurações de associação de grupo não gerenciadas e não monitoradas. Por meio de ataques de exploração de credenciais ou implantação de malware, várias permissões, configurações de segurança e configurações de associação podem ser alteradas pelos invasores.
  • Alterar senhas, valores de atributo e modificar as configurações de gerenciamento de Diretiva de Grupo e associações de grupos do AD, interferindo assim com direitos de acesso, permissões e privilégios disponíveis para usuários e grupos do AD.
  • Implantar ransomware por meio da circulação de e-mails de phishing, entrega de downloads drive-by por meio de uma infraestrutura da Web comprometida ou por meio da instalação de malware para download em estações de trabalho AD comprometidas.

Alguns exemplos notáveis de ataque AD

Ataques DCSync e DCShadow

Esses ataques do AD são executados principalmente por meio da exploração do modelo de replicação do AD.

Semelhança: Ambos são caracterizados por invasores que obtêm controle ilícito de um controlador de domínio (DC), estendendo subsequentemente seu controle sobre todos os outros DCs no domínio.

Diferença principal: enquanto os invasores do DCSync dependem apenas da replicação para abrir as credenciais de autenticação necessárias para representar os administradores de domínio, os invasores do DCShadow vão um passo adiante e registram um novo DC falso antes de cancelar o registro após o ataque. A natureza do ataque também garante que eles sejam mais rápidos e discretos.

Ataques DCSync

• Durante um ataque DCSync, os invasores obtêm as credenciais de autenticação de cada um dos outros DCs na floresta do AD. Eles fazem isso usando o comando DCSync na ferramenta de script de código aberto chamada Mimikatz.

• Como alternativa, o protocolo remoto do serviço de replicação de diretório (DRS) pode ser o primeiro ponto de contato para exploração. O protocolo DRS é um protocolo de comunicação usado para gerenciar a replicação de dados no AD.

• Com acesso a todos os DCs em cada domínio, os invasores comprometem a topologia de replicação.
• Os invasores então elevam seus privilégios e permissões de acesso para obter controle e gerenciar todos os usuários, grupos e contas de computador do AD; configurações; e configurações de Diretiva de Grupo. O serviço AD está agora à mercê de seu controle ilegal.

Ataques DCShadow

• Durante um ataque DCShadow, os invasores obtêm furtivamente o controle de qualquer DC, parceiro de servidor de replicação ou usuário com poucos privilégios ou sua estação de trabalho, e usam o comando DCShadow para registrar um DC “desonesto” com direitos de replicação. Eles fazem isso usando ferramentas como Mimikatz ou Remote Server Administration Tools.

• Os invasores lançam alterações maliciosas que serão replicadas em todo o domínio. Eles também podem adicionar backdoors no esquema do AD.

• Os invasores podem cobrir imediatamente seus rastros cancelando o registro dos DCs rouge, tornando esses ataques mais difíceis de rastrear e monitorar.

Kerberoasting

Cada aspecto do fluxo do protocolo Kerberos pode ser explorado por invasores para comprometer a configuração do AD.

Kerberoasting é um dos muitos métodos de exploração do AD bem documentados. Nessa técnica, os invasores obtêm acesso e se autenticam de forma ilegítima em uma rede corporativa. Eles adquirem um ticket de concessão válido (TGT) representando qualquer cliente que esteja se autenticando no ambiente AD durante o procedimento de autenticação Kerberos primário.

O usuário comprometido aqui pode ser qualquer usuário de domínio válido. Não é necessário que esse usuário seja um usuário privilegiado, como um administrador de domínio. O invasor posteriormente solicita tickets de serviço do centro de distribuição de chaves (KDC) para um serviço específico associado ao nome principal de serviço (SPN) necessário. Ele é criptografado com uma chave secreta do servidor ou a senha da conta de serviço associada ao SPN. Essa chave é acessada do banco de dados do KDC.

Somente o KDC (que é essencialmente o DC que autentica o cliente) e o servidor de destino que fornece o serviço necessário conhecem essa chave secreta.

O invasor, imitando o cliente ou usuário, envia esse tíquete de serviço ao servidor de destino. Nesse ponto, o servidor verificará as credenciais e estabelecerá uma sessão exclusiva para entrega de serviço.

O invasor, no entanto, pode explorar ainda mais essa situação e usar vários meios para abrir as credenciais da conta de serviço. Eles podem fazer isso adotando ferramentas de quebra de senha offline. Eles podem até farejar o tráfego de rede para outros TGTs Kerberos ou recuperar hashes de senha da memória do usuário para essa finalidade.

Como resultado, eles podem obter acesso a contas de serviço e seus serviços associados sem precisar entrar em contato com o servidor de destino para o serviço. Na maioria das vezes, as contas de serviço recebem permissões que vão além do pretendido e geralmente são monitoradas com pouca frequência.

A conta de usuário comprometida aqui pode não estar realmente autorizada a acessar o serviço. E, no entanto, sem nenhum mecanismo implementado durante o fluxo do protocolo Kerberos que confirme a validade da solicitação de acesso de qualquer cliente a determinados serviços, essa vulnerabilidade é frequentemente explorada por invasores.

As senhas de contas de serviço são vulneráveis ao comprometimento de invasores porque as senhas SPN do usuário geralmente são definidas manualmente como senhas de caracteres simples e curtas (geralmente com menos de 25 caracteres) que são alteradas com pouca frequência e, portanto, são mais fáceis de explorar.

Depois que os invasores obtêm acesso às contas de serviço, eles também podem obter acesso administrativo injustificado. Eles passam de um usuário de domínio com poucos privilégios para um administrador de domínio com privilégios altos, que pode prosseguir lateralmente pelos domínios do AD para penetrar ainda mais.

Ataques de extração de senha do Ntds.dit

O núcleo de um serviço AD são os dados armazenados no arquivo de banco de dados, ntds.dit, no caminho do arquivo C:\Windows\NTDS\. Esse banco de dados armazena todos os tipos de objetos do AD, incluindo usuários do AD, computadores, grupos, UOs e configurações de Diretiva de Grupo.

Os hashes de senha para cada uma das contas de usuário no AD também são armazenados aqui em cada DC dos domínios do AD.

Obter acesso não autorizado a esse arquivo de banco de dados abre uma série de oportunidades para os adversários. Os invasores geralmente planejam ataques futuros, como ataques de passagem de hash, de dentro da rede comprometida com a ajuda desses hashes de senha.

Nessa técnica, que é um tipo de dumping de credenciais, os invasores inicialmente fazem uma cópia do arquivo ntds.dit usando vários métodos. Alguns deles podem ser por meio dos comandos ntdsutil ou por meio de módulos de teste de penetração do PowerShell, como Invoke-NinjaCopy de scripts do PowerSploit.

Os invasores extraem os hashes de senha e cobrem seus rastros.

Os hashes de senha podem ser encaminhados para ferramentas como o Mimikatz para realizar novos ataques ou podem ser extraídos para seu texto simples, de forma legível por meio de outras ferramentas como Hashcat ou John the Ripper.

O conhecimento dos hashes de senha ou de suas versões de texto simples é valioso para os invasores comprometerem os usuários do domínio, obterem acesso privilegiado e, por fim, obterem acesso de administrador do domínio para controlar o ambiente AD.

Existem muitas outras metodologias de ataque por aí. No entanto, é importante entender o mecanismo geral de ataque por meio de alguns ataques bem documentados, como os listados acima e, em seguida, desenvolver esse conhecimento para aprofundar outros métodos de exploração usados por invasores do AD. Para proteger sua infraestrutura e gerenciar seu AD de forma eficaz, não deixe de ver mais sobre as soluções da ManageEngine.