Leve-me ao seu controlador de domínio: como os invasores se movem lateralmente pelo seu ambiente

Dan Gould também contribuiu para esta postagem.

Na primeira parte desta série de blogs, vimos diferentes maneiras pelas quais um agente de ameaças pode realizar a fase de descoberta da estrutura ATT&CK para obter uma visão geral após uma infecção inicial. Isso fornece informações importantes sobre a rede e o domínio, mesmo com privilégios de domínio padrão. Também observamos alguns dos componentes usados por um controlador de domínio que podem ser atacados diretamente ou aproveitados como parte de um ataque.

Aqui, vamos elaborar isso para mostrar exemplos de ataques e ferramentas que podem ser usadas contra esses componentes para executar a próxima fase de um ataque: movimento lateral.

Com essas informações úteis, como as mostradas na postagem anterior na fase de descoberta, o agente da ameaça agora pode tentar com confiança um movimento lateral no caminho até o controlador de domínio. No entanto, eles precisarão das credenciais necessárias, dos sistemas de destino intermediários e das informações dos componentes, combinados com as ferramentas de ataque correspondentes, para alcançar seu alvo final.

ATT&CK: Movimento lateral

O movimento lateral, especialmente em um domínio Windows, pode ocorrer em dois níveis. Primeiro, o nível do aplicativo, em que o invasor pode usar técnicas baseadas em credenciais, como pass-the-hash ou pass-the-ticket, o que, por sua vez, aproveita o nível da rede em que ele realmente se move de uma máquina para outra até o alvo final, que neste caso é o controlador de domínio.

Isso nos leva às técnicas baseadas em credenciais.

Técnicas baseadas em credenciais para movimento lateral

Francamente, quando as credenciais de administrador do domínio são descobertas, o controlador de domínio normalmente está a um prompt de comando de distância.

Os invasores buscam despejar credenciais armazenadas em cache em locais comuns, como o Serviço de Subsistema da Autoridade de Segurança Local (LSASS), usadas para autenticar usuários, logins e permissões no Windows. Por que as credenciais (senhas e tickets com hash) são mantidas na memória? Para o login único, é para que os usuários não precisem se autenticar novamente o tempo todo.

Se os atacantes tiverem sorte, eles comprometem um sistema que ainda tem logins de administrador anteriores na memória. Essas credenciais de login podem ser obtidas com o Mimikatz ou ferramentas similares de sondagem de memória LSASS. Como você já sabe, o Mimikatz e ferramentas similares permitem que os agentes de ameaças encontrem e extraiam credenciais de autenticação, como hashes NTLM e informações de tíquetes Kerberos, da memória kernel de um computador em execução usada pelo LSASS.

O exemplo abaixo mostra o despejo de credenciais usando o Mimikatz.

Na maioria dos casos, a conta inicialmente comprometida só precisa ser uma conta de administrador local na máquina Windows para poder executar com êxito ferramentas como o Mimikatz. Isso significa que ele terá os privilégios necessários, como o privilégio de depuração do Windows, para ler o kernel ou a memória privilegiada para certos processos cruciais do Windows, como o LSASS. Conforme mencionado anteriormente, os domínios do Windows dependem muito do recurso de login único para oferecer uma experiência quase perfeita para usuários e máquinas que solicitam recursos em todo o domínio. Para facilitar isso, o Windows tem usado a capacidade de armazenar credenciais com hash na memória e, nas versões mais antigas, senhas de texto simples na memória. Essa é uma das principais maneiras pelas quais ferramentas como o Mimikatz conseguem recuperar hashes NTLM e, em alguns casos, senhas de texto simples para técnicas como ataques pass-the-hash e pass-the-ticket.

Veja como é o despejo de tíquetes Kerberos da memória:

Outra ferramenta que pode ser usada para ataques relacionados a tickets Kerberos é o Rubeus. Ele tem recursos como solicitações de tíquetes Kerberos, que recuperam um Ticket-Granting-Ticket (TGT) com base na senha/hash de um usuário em uma instância ou com base no armazenamento de certificados de um usuário. O Rubeus também pode ser usado para abusar da delegação restrita em domínios do Windows executando a delegação restrita de serviço para usuário (S4U) em um domínio específico ou até mesmo entre domínios em uma floresta.

No exemplo abaixo, podemos ver que o agente da ameaça é capaz de despejar informações de hash de credenciais da memória e localizar um nome de conta específico identificado como uma conta de administrador. Essa conta estará presente porque ela teria se conectado à máquina em algum momento.

Esse despejo específico também incluirá informações como o servidor de logon no domínio. Isso pode ser corroborado com as informações coletadas durante a fase de descoberta para confirmar o controlador de domínio de destino.

No exemplo abaixo, do “administrador de TI” O hash NTLM da conta que foi descartado anteriormente, conseguimos passar esse hash para iniciar um novo processo cmd do Windows com o token privilegiado de administrador elevado. Isso significa que o novo processo cmd pode realizar ações no contexto de uma conta privilegiada, mesmo que o usuário real conectado tenha apenas direitos de administrador local na máquina comprometida.

Esse novo processo será executado com o token elevado “itadmin”, o que significa que podemos usá-lo para executar outras ferramentas de acesso remoto para direcionar e conectar-se ao controlador de domínio pela rede. Na imagem abaixo, podemos ver que, após um ataque bem-sucedido de pass-the-hash, uma ferramenta secundária, como a do power admin Apexec pode ser usado para realizar o resto do ataque conectando-se remotamente ao controlador de domínio. O comando hostname na imagem confirma o movimento lateral bem-sucedido nos níveis do aplicativo e da rede.

Podemos verificar os serviços em execução na máquina controladora de domínio para verificar se o PAExec fez uma conexão com um processo correspondente. A técnica pass-the-hash usada para gerar o token elevado pelo administrador no laptop comprometido, que foi então usada para executar a ferramenta de gerenciamento remoto PAExec, teve sucesso, conforme mostrado na imagem abaixo.

Essa é uma demonstração simples de como os invasores podem se mover lateralmente, do nível do aplicativo (roubo de credenciais na memória do processo) para o nível da rede (travessia de máquina smb, msrpc ou http), para atingir o alvo final — o controlador de domínio.

ATT&CK: Impacto

Nesse ponto, depois de acessar o controlador de domínio, o invasor está no comando. Eles podem continuar copiando arquivos maliciosos adicionais para o controlador de domínio remotamente. Por exemplo, agora eles poderiam copiar o Mimikatz no controlador de domínio e usá-lo para extrair o hash da conta de usuário KRBTGT embutida — além de outras informações de domínio — para iniciar o ataque Golden Ticket. Isso pode então ser usado para ataques “pass-the-ticket” em todo o domínio.

O invasor pode até mesmo usar as ferramentas já existentes, vivendo fora da terra, para implantar algo como ransomware e se conectar a outros servidores confidenciais, como servidores de banco de dados ou de aplicativos, para extrair ainda mais os dados. Isso pode ser PsExec, PowerShell, SCCM — qualquer ferramenta de administração de TI que possa implantar software.

Dependendo da sofisticação do ataque, um invasor pode usar todas as ferramentas personalizadas ou executar o código somente na memória, de modo que a análise de assinaturas de ferramentas como o Mimikatz se torna difícil para qualquer ferramenta de segurança detectar e evitar. Da mesma forma, a análise comportamental também pode consumir muitos recursos, portanto, essas técnicas de análise podem ser desativadas, especialmente em ambientes de servidores ou sistemas operacionais legados que executam aplicativos essenciais legados.

Assista à nossa próxima postagem que examina as mitigações desses ataques.