Imersão no AD: analisamos ataques avançados no Microsoft Active Directory e como detectá-los

Imagem: Pexels

Nos últimos quatro anos, nenhum Black Hat ou DEF CON ficou sem relatórios sobre ataques ao Microsoft Active Directory. Os participantes falam sobre novos vetores e suas invenções, mas não esquecem dicas sobre como detectá-los e evitá-los. Neste artigo, examinaremos maneiras populares de atacar o AD e forneceremos recomendações que ajudarão a proteger contra eles.

Seis ataques do AD que você não pode ignorar

Muitos fabricantes de software de monitoramento de segurança já oferecem suporte a uma variedade de técnicas de ataque em seus produtos. Vamos considerar alguns deles.

Pass-the-hash

Essa técnica é possível devido aos recursos arquitetônicos do protocolo de autenticação NTLM, desenvolvido pela Microsoft nos anos noventa do século passado. Para fazer login em um host remoto, é usado um hash de senha, que é armazenado na memória do computador no qual a autenticação ocorre. Consequentemente, pode ser extraído de lá.

Mimikatz

Para uma operação conveniente do Pass-the-Hash, o pesquisador francês Benjamin Delpy (Benjamin Delpy) em 2014 desenvolveu o utilitário mimikatz. Ele permite descarregar senhas de texto não criptografado e hashes NTLM da memória.

Força bruta

Se o invasor não tiver credenciais suficientes para extrair de um host, ele poderá recorrer a uma técnica grosseira, mas eficaz, de adivinhação de senha.

usuário / domínio da rede

Onde obter um dicionário de nomes de usuário para realizar a Força Bruta? Qualquer membro do domínio pode usar o comando net user / domain, que retorna uma lista completa de nomes de usuário do AD.

Kerberoasting

Se o domínio usar o Kerberos como protocolo de autenticação, o invasor poderá recorrer a um ataque de Kerberoasting. Qualquer usuário autenticado no domínio pode solicitar um ticket Kerberos para acessar o Serviço de Concessão de Ticket. O TGS é criptografado com o hash da senha da conta na qual o serviço de destino está sendo executado. Um invasor que obteve o TGS agora pode descriptografá-lo, escolhendo uma senha e não tendo medo de bloquear, pois o faz offline. Após um resultado bem-sucedido, ele recebe uma senha da conta associada ao serviço, que geralmente é privilegiada.

Psexec

Depois que o invasor recebe as credenciais necessárias, ele se depara com a tarefa de executar comandos remotamente. O utilitário PsExec do conjunto Sysinternals é adequado para isso. Ele se provou tanto entre administradores de TI quanto entre atacantes.

Sete feitiços de ataque para capturar o Active Directory

Agora estamos migrando para sete feitiços, graças aos quais os invasores podem assumir o controle completo do Active Directory. Vamos dividi-los em quatro etapas:

1. Inteligência.
2. Promoção no AD.
3. Operação.
4. Captura de domínio.

No diagrama, você pode ver todos os quatro, bem como as técnicas usadas neles. Vamos considerar cada um em detalhes.

Etapa 1. Exploração

Vamos começar com o estágio de inteligência.

Powerview

Essa ferramenta faz parte da popular estrutura de teste de penetração do PowerShell - PowerSploit . Ele também conta com a ferramenta BloodHound , que cria um gráfico de relacionamentos de objetos no AD.



Representação gráfica de relacionamentos de objetos do Active Directory

Bloodhound fornece imediatamente esses recursos:

• Encontre contas de todos os administradores de domínio;
• encontre hosts nos quais os administradores de domínio estejam conectados;
• crie o caminho mais curto do host do invasor para o host com a sessão de administração do domínio.

O último parágrafo fornece uma resposta para a pergunta de quais hosts precisam ser invadidos por hackers para acessar a conta de administrador do domínio. Essa abordagem reduz bastante o tempo para obter controle total sobre o domínio.

O PowerView difere dos utilitários internos para recuperar dados sobre objetos do AD (por exemplo, net.exe), na medida em que é executado no protocolo LDAP, não no SAMR. O evento 1644 de um controlador de domínio é adequado para detectar essa atividade. O log deste evento é ativado adicionando o valor apropriado no registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostic\\15 Field Engineering = 5



Habilitando o log de eventos LDAP 1644



Evento 1644 com parâmetros de solicitação LDAP

Vale a pena prestar atenção ao fato de que pode haver muitos desses eventos, e uma boa alternativa à detecção de eventos é a detecção de tráfego, pois o LDAP é um protocolo de texto não criptografado; portanto, todas as solicitações no tráfego são perfeitamente visíveis.



LDAP SearchRequest (clique para abrir a imagem em tamanho real)

Outro recurso importante dessa estrutura é que ela é escrita no PowerShell puro e não possui dependências. E aqui, para detecção, o recurso avançado de auditoria introduzido no PowerShell versão 5 nos ajudará. O evento 4104 mostra o corpo de um script no qual podemos procurar nomes de funções específicas do PowerView.

Verificação SPN

Ele pode substituir o nmap de inicialização do invasor. Depois que o invasor descobrir quais usuários e grupos estão no AD, para concluir a imagem, ele precisará de informações sobre quais serviços estão disponíveis.



Isso geralmente é resolvido varrendo as portas com o nmap. Mas agora essas informações também podem ser obtidas no AD - elas já estão armazenadas lá. Você pode ver o resultado dessa solicitação: retorne o chamado SPN (Service Principal Names). O SPN consiste em uma classe de serviço, é exclusivo para cada tipo de serviço e, em seguida, vem o nome do host na forma de FQDN e, para alguns serviços - porta.



Exemplos de spn Lista completa de nomes principais de serviço

Para detectar a verificação do SPN, a auditoria de eventos LDAP também vem ao resgate.
É importante observar que a verificação do SPN tem uma vantagem distinta sobre a verificação do nmap: é menos barulhenta. Ao usar o nmap, você precisa se conectar a cada nó e enviar pacotes para o intervalo de portas que você especificou. E para obter a lista de SPN, você precisa enviar apenas uma solicitação.

Enumeração de sessões remotas

Uma tarefa importante para um invasor no estágio de movimento lateral é determinar qual usuário está conectado a qual máquina. Ou ele já possui credenciais de usuário (hash ou tíquete Kerberos) e está procurando hosts nos quais você pode fazer login sem impedimentos. Ou ele está em busca de um host em que haja uma sessão de administrador de domínio ativo.

Então o cenário funciona: caçando -> comprometendo qualquer host -> Golfo de Mimikatz -> lucro.

Você pode usar 2 eventos para detectar esta técnica. 4624 é um logon bem-sucedido em um sistema remoto com um logon do tipo 3, bem como eventos de acesso à rede IPC $, e a nuance é o nome do pipe - srvsvc. Por que um tubo é chamado pode ser entendido a partir do tráfego.



Clique para abrir a imagem em tamanho real.

No lado esquerdo, nos quadros vermelhos, acesse SMB e, em seguida, acesse pipe - srvsvc. Esse canal permite que você interaja usando o Protocolo remoto de serviço de servidor especial. Permite que os hosts finais recebam várias informações administrativas, incluindo Entre as consultas, há uma chamada NetSessEnum. Como resultado dessa solicitação, uma lista completa de usuários conectados ao sistema remoto com IP e nomes de usuário é retornada.



No MaxPatrol SIEM, fizemos uma detecção com base em uma combinação desses dois eventos, levando em consideração srvsvc. E uma detecção de tráfego semelhante no PT Network Attack Discovery.

Etapa 2. Promoção do AD

Overpass-the-hash

A reencarnação de Pass-the-Hash. Continuando o tema do movimento lateral. O que um invasor pode fazer se tiver um hash NTLM? Ele pode realizar um ataque Pass-the-Hash - mas já existem detecções nela. Portanto, um novo vetor foi encontrado - o ataque Overpass-the-Hash.

O protocolo Kerberos foi projetado especificamente para que as senhas dos usuários, de uma forma ou de outra, não sejam transmitidas pela rede. Para fazer isso, em sua máquina, o usuário coloca sua senha criptografada na solicitação de autenticação. Em resposta, o Centro de Distribuição de Chaves (um serviço especial hospedado no controlador de domínio) emite um ticket para receber outros tickets. O chamado Ticket Granting Ticket (TGT). Agora, o cliente é considerado autenticado e, dentro de 10 horas, pode solicitar tickets para acessar outros serviços. Por conseguinte, se um ataque despejar hash de um usuário que seja membro de um grupo confiável de um serviço de seu interesse, por exemplo, um sistema ERP ou banco de dados, o invasor poderá emitir um passe para si próprio e efetuar login com êxito no serviço de seu interesse.

Como detectar

Se o invasor usar a versão do mimikatz do PowerShell para esse ataque, o registro do corpo do script será útil. Porque Invoke-Mimikatz é uma linha muito característica.





Ou 4688 é um evento de início do processo com auditoria avançada da linha de comandos. Mesmo que o binar seja renomeado, na linha de comando, encontraremos um comando muito característico da mimikatz.



O tráfego de ultrapassar o hash pode ser detectado com base em uma anomalia resultante do fato de a Microsoft recomendar o uso da solicitação de autenticação AES256 para criptografia dos domínios atuais. E mimikatz, quando envia dados de solicitação de autenticação, criptografa os dados usando o ARCFOUR desatualizado.



No trânsito, outra diferença é observada devido às características da mimikatz. Ele se baseia na diferença no conjunto de cifras no domínio legítimo e no que a mimikatz envia.

Bilhete de ouro

O que um invasor pode fazer se tiver um hash de senha de uma conta especial chamada krbtgt? Anteriormente, consideramos o caso em que o usuário não podia ter privilégios. Agora, estamos considerando um usuário com um hash de senha no qual absolutamente todos os tickets para outros tickets (TGT) são assinados. Assim, o atacante não se dirige mais ao Centro de Distribuição de Chaves, ele gera esse ticket por conta própria, já que o Golden Ticket, em essência, é o TGT. Em seguida, ele pode enviar solicitações de autenticação para qualquer serviço dentro do AD e por tempo ilimitado. Como resultado, ele recorre livremente a esse recurso - o Bilhete de Ouro não é sem razão chamado de ouro.

Como detectar por eventos

Há o evento 4768, que diz que o TGT foi emitido, e o evento 4769, que diz que foi emitido um tíquete de serviço, necessário para autenticação em algum serviço dentro do AD.



Aqui podemos jogar a diferença: durante um ataque, o Golden Ticket não solicita um TGT de um controlador de domínio (ele o gera por si próprio) e precisa solicitar um TGS; se encontrarmos uma diferença no TGT e no TGS recebidos, podemos assumir que um ataque do Golden Ticket está ocorrendo.

No MaxPatrol SIEM usando listas de tabelas nas quais registramos todos os TGT e TGS emitidos, conseguimos implementar essa detecção.

Execução remota WMI

Após a resolução da tarefa de autenticação e autorização nos hosts desejados, o invasor pode começar a executar tarefas remotamente. O WMI, como um mecanismo interno e projetado para isso, se encaixa perfeitamente. Nos últimos anos, "viver fora da terra" significa usar os mecanismos internos do Windows em uma tendência. Primeiro de tudo, porque permite que você se disfarce de atividade legítima.



Na captura de tela, o uso do utilitário wmic interno. Ele especifica o endereço do host ao qual você deseja se conectar, credenciais, a instrução de criação de chamada de processo e o comando que deve ser executado no host remoto.

Como detectar

Em vários eventos de um logon remoto 4624 (preste atenção a
mania no ID de logon) e no evento 4688, falando sobre iniciar um processo com a linha de comando. 4688 - você pode ver que o pai do processo iniciado é o WmiPrvSE.exe, um processo especial do serviço WMI usado para administração remota. O comando que enviamos net user / add é visível e o ID de logon corresponde ao evento 4624. Portanto, podemos dizer exatamente de qual host esse comando está sendo executado.

Detecção de Tráfego

Aqui, vemos claramente as palavras características do processo Win32 criadas, bem como a linha de comando, que é enviada para iniciar. Na captura de tela, conhecemos recentemente um malware, distribuído em redes virtuais de acordo com um princípio semelhante ao WannaCry, mas, em vez de criptografia, ele instalou um minerador. Malvar carregava mimikatz e EthernalBlue com ela, ela despejou as contas; com a ajuda delas, ela se conectou a todos os hosts que conseguia acessar na rede. Usando o WMI, ela lançou o PowerShell neles, baixou a carga útil do PowerShell, que novamente continha mimikatz, EthernalBlue e o mineiro. Assim, uma reação em cadeia foi obtida.

Recomendações para os estágios 1-3

1. Senhas longas e complexas (> 25 caracteres) para contas de serviço. Isso não deixará o atacante a chance de realizar um ataque de Kerberoasting, pois vai demorar muito tempo para ser bruto.

2. Registrando o PowerShell . Isso ajudará a detectar o uso de muitas ferramentas modernas para ataques ao AD

3. Mudando para o Windows 10, Windows Server 2016. A Microsoft criou o Credential Guard: não será mais possível despejar hashes NTLM e tickets Kerberos da memória

4. Demarcação estrita de papéis . É perigoso combinar em uma função o administrador do AD, DC, todos os servidores e máquinas que funcionam

5. Alteração da senha dupla krbtgt (é a mesma conta com a qual os tickets do TGT se inscrevem) . Todo ano. E depois que o administrador do AD sai do AD:

• precisa ser alterado duas vezes, porque a senha atual e a anterior são armazenadas,
• mudar todos os anos, incl. depois de sair do administrador do domínio. Mesmo que a rede já esteja comprometida e os invasores tenham emitido o Golden Ticket, a alteração da senha torna esse Ticket inútil. E novamente eles precisam começar tudo de novo.

6. Remédios com uma base de conhecimentos especializados continuamente atualizada . É necessário detectar ataques reais reais.

Etapa 4. Captura de Domínio

DCShadow

Em 24 de janeiro de 2018, na conferência Microsoft BlueHat em Israel, Benjamin Delpy e Vincent Le Toux introduziram o novo módulo mimikatz, que implementa o ataque DCShadow. A essência do ataque é que um controlador de domínio falso é criado para modificar e criar novos objetos no AD por meio da replicação. Os pesquisadores conseguiram isolar o conjunto mínimo de SPNs Kerberos necessários para passar pelo processo de replicação - eles precisam apenas de 2. Além disso, eles apresentaram uma função especial que pode forçar a replicação de controladores. Os autores do ataque o posicionam como um ataque que fará seu SIEM cego. Porque um controlador de domínio falso não envia eventos para o SIEM, o que significa que os invasores podem fazer várias coisas obscuras com o AD e o SIEM não saberá sobre isso.

Padrão de ataque

No sistema com o qual o ataque é realizado, é necessário adicionar 2 SPNs, necessários para que outros controladores de domínio possam se autenticar usando o kerberos para replicação. Porque de acordo com a especificação, o controlador de domínio é representado no banco de dados do AD por um objeto da classe nTDSDSA; é necessário criar esse objeto. Por fim, chame a replicação usando a função DRSReplicaAdd.

Como detectar

Como o DCShadow parece no trânsito. Pelo tráfego, vemos claramente a adição de um novo objeto ao esquema de configuração do tipo de controlador de domínio e, em seguida, o início forçado da replicação



Devido ao fato de nossa correlação conhecer a lista de controladores de domínio legítimos, ela será acionada quando ocorrer a replicação de um controlador de domínio que não esteja incluído nessa lista branca. Por conseguinte, a divisão de segurança da informação pode conduzir uma investigação e já entende que este é um controlador de domínio legítimo que foi adicionado pelo serviço de TI ou pelo ataque do DCShadow.

Conclusão

O exemplo do DCShadow mostra que existem novos vetores de ataque para empresas. Nesse oceano de eventos de segurança da informação, é muito importante permanecer na crista da onda: olhar mais longe e avançar rapidamente. Todos os dias, no PT Expert Security Center, pesquisamos novas ameaças e desenvolvemos métodos e ferramentas de detecção para elas. E estamos prontos para compartilhar essas informações ainda mais.

Postado por Anton Tyurin, chefe da equipe de detecção de ataques, Positive Technologies