Por Ícaro César: Neste relatório você vai acompanhar uma Pesquisa de Segurança – Emulação e Detecção, com a Técnica de LLMNR (Link Local Multicast Name Resolution) e NBT-NS (NetBIOS Name Service), Spoofing e Poisoning, que são dois métodos muito eficazes para capturar hashes NTLMv1, NTLMv2 ou LM (Lan Manager) de usuários. Este tipo de ataque é categorizado como Man-in-the-Middle.
Primeiramente, precisamos compreender: o que é LLMNR e NBT-NS Spoofing/Poisoning? O LLMNR é o sucessor do NBT-NS e foi introduzido no ecossistema do Windows a partir do Windows Vista.
Tanto o LLMNR quanto o NBT-NS permitem que as máquinas dentro de uma rede Windows se encontrem, e é essencialmente um protocolo de “retorno” usado para a resolução de nomes de hosts em uma rede, quando a resolução de nomes de host por meio de DNS falha.
Esse processo de hosts revertendo o fluxo para transmissões LLMNR ou NBT-NS para encontrar determinados hosts na rede resulta no envio de hashes NTLMv1/v2 pela rede, oferecendo a um adversário no mesmo segmento de rede a oportunidade de interceptar e reproduzir ataques como Pass-The-Hash em outros dispositivos, ou, crackear as hashes interceptadas de forma offline.
Um cenário típico de ataque às transmissões de LLMNR ou NBT-NS, estes funcionam da seguinte forma:
1. O Host A solicita um compartilhamento SMB na rede identificado como “intranet”, mas em vez de digitar “intranet” erroneamente digita “intrnet”.
2. Como “intrnet” não pode ser resolvido pelo DNS, pois é um host e um compartilhamento que não existe, o Host A volta a enviar uma mensagem de broadcast LLMNR ou NBT-NS, solicitando a todo o segmento de rede o endereço IP do host/compartilhamento “intrnet”, solicitado anteriormente de forma errônea.
3. O Adversário (Host B) responde a esta mensagem de broadcast alegando ser o sistema que contém o recurso “intrnet”.
4. O Host A, ao receber a resposta do Adversário (Host B), envia ao Host B (o adversário) seu nome de usuário e o hash NTLMv1 ou v2 para que o Host B realize o processo de validação de autorização de acesso ao “recurso solicitado”.
Emulação da técnica – T1557.001
Para que possamos executar os Procedimentos desta Técnica, podemos utilizar as ferramentas Responder, desenvolvido em Python, ou a ferramenta Inveigh, desenvolvida em Powershell. Nesta emulação, utilizamos a ferramenta Responder para a execução desse procedimento, mas, independentemente da ferramenta utilizada para executar os procedimentos, o ataque LLMNR e NBT-NS Poisoning/Spoofing continua tendo o mesmo resultado.
O laboratório no qual iremos realizar a emulação desta técnica contém a seguinte topologia:
O Responder contém um arquivo de configuração que nos permite configurar quais são os serviços que irão ser executados para realizar a captura, Spoofing e Poisoning dos pacotes trafegados naquele segmento de rede. Isto permite ao atacante subir exatamente os serviços que ele precisa para executar o ataque Man-in-the-Middle.
Ao executar o Responder na rede (conforme é ilustrado na imagem abaixo), o adversário irá executar servidores de diversos serviços especificados no arquivo de configuração, que irão ficar escutando determinadas requisições de broadcast na rede para que, então, ele possa responder e se passar pelo recurso daquela solicitação com o objetivo de capturar informações referentes aos usuários. No contexto de nossa emulação, o objetivo do adversário é capturar hash NTLMv2 de usuários.
Conforme ilustrado nas imagens acima, o adversário executou o Responder em seu dispositivo, no qual subiu diversos servidores, inclusive um SMB Server, e Poisoners que irão ‘envenenar’ os pacotes dos protocolos indicados na imagem acima.
Ao executar de forma simples o Responder, o adversário agora só precisa esperar algum usuário digitar o nome errado de um host/compartilhamento para que o dispositivo do usuário envie broadcasts LLMNR e/ou NBT-NS, com o objetivo de encontrar aquele host/compartilhamento. Assim o adversário que escutará o tráfego de broadcast irá capturar esse pacote e respondê-lo, com o objetivo de se passar do host/compartilhamento solicitado, e por fim, capturar o Hash do usuário.
Outra maneira de executar esta Técnica seria através do desenvolvimento de uma campanha de phishing do adversário, no qual possa induzir o usuário a clicar em um link que possa abrir um compartilhamento não-existente na rede, ou executar um código malicioso através de um documento para que o dispositivo do usuário envie broadcasts LLMNR e NBT-NS pelo segmento de rede.
No nosso cenário, a aquisição de hashes foi causada por um erro de digitação do usuário.
Na imagem acima, podemos observar que há um compartilhamento ativo no DC01 que pode ser acesso através do ‘\\DC01\Production\’.
Por falta de atenção, o usuário com o objetivo de acessar este compartilhamento digitou em seu Windows Explorer apenas ‘\\Production\’. Esse simples erro deu ao adversário o seu hash NTLMv2.
A partir deste momento, o adversário pode tentar realizar o cracking da hash de forma offline, ou conduzir procedimentos referentes às Técnicas de Movimentação Lateral como Pass-The-Hash, onde o adversário tentará realizar autenticações em outros dispositivos, utilizando a Hash capturada.
Detecção de execução da técnica
A Técnica que estamos abordando é extremamente complexa de se detectar através de Event IDs, pois teoricamente trata-se de um comportamento normal da rede, com o adversário subvertendo o seu funcionamento para alcançar os seus objetivos.
Neste tópico, iremos abordar soluções de detecção, demonstrando a importância da captura de pacotes, e a detecção através do Hunting proativo, com o intuito de encontrar dispositivos que estejam executando Servidores com Serviços Falsos com o objetivo de capturar informações críticas dos usuários.
OBS.: Este exercício de detecção e Hunting também foi executado na mesma infraestrutura de laboratório ilustrada anteriormente.
Captura de pacotes
A captura de pacotes é importante uma vez que permite identificar o comportamento da execução desta Técnica, analisando requisições ao DNS e, durante a falha na resolução do nome, o envio de broadcast LLMNR para o segmento de rede, que consequentemente nos leva à resposta do adversário.
Abaixo, podemos observar o comportamento da tentativa de resolução de nome para o host/recurso \\Production\, solicitado acidentalmente pelo usuário. Conforme na imagem acima, podemos identificar que ele tenta fazer a resolução através do DNS e, como este host/recurso não existe, o dispositivo envia um broadcast LLMNR para o segmento de rede, solicitando que o host/recurso responda.
É aí que nosso adversário entra em ação. Ao receber o broadcast (por estar no mesmo segmento de rede), podemos observar na imagem acima que ele responde àquele do dispositivo do usuário e, logo após a sua resposta, o usuário tenta uma conexão através da porta 445 (SMB).
Na imagem acima, vemos a segunda fase da execução desta técnica. Podemos observar que, após o adversário responder ao broadcast, é iniciada uma negociação através do protocolo SMB, onde o adversário informa ao dispositivo do usuário que precisará de um NTLM Challenge para que o dispositivo do usuário consiga ter acesso ao recurso solicitado. Ao receber esse NTLM Challenge, o usuário envia sua hash para que o host de destino valide se o usuário tem autorização de acesso ao recurso solicitado.
Após receber a hash do usuário, o adversário informa que o usuário não tem permissão de acesso ao recurso, e então finaliza a conexão.
Para o usuário, isso parece um pequeno incômodo, mas ele acabou de dar suas credenciais para o adversário.
Possíveis detecções através de captura de pacotes
Para criar detecções para esta técnica utilizando captura de pacotes, primeiramente o seu SIEM deve estar habilitado para realizar este tipo de atividade. Você também deve estar ciente de quais dispositivos possui na infraestrutura, para que consiga identificar quando um dispositivo responder uma solicitação de recurso que não existe.
Sugerimos que a detecção deva ser feita analisando o processo de não resolução através do DNS, sendo seguido pelo envio de broadcast LLMNR para o segmento de rede e, então, detectando o dispositivo que responder a este broadcast.
Se o servidor DNS não realizou a resolução de nome de um dispositivo que está hospedando um recurso compartilhado na rede, é porque ele não deveria existir ou não responder de outra forma. Por isso, a análise para desenvolver a detecção deve ser focada neste aspecto do ataque.
Conveigh – ferramenta de threat hunting
Caso você não tenha infraestrutura para realizar grandes capturas de pacotes, ou caso o Hunter queira adotar uma tática mais proativa durante o seu processo de validação de hipótese, a ferramenta Conveigh é uma ótima aquisição para a detecção de dispositivos que estão hospedando Servidores com serviços falsos na rede, com o objetivo de capturar hashes do máximo de usuários.
A seguir, vamos visualizar como essa ferramenta pode nos ajudar a encontrar o adversário executando a Técnica na sua infraestrutura.
O Hunter cria a hipótese de que algum adversário possa estar executando a Técnica de Envenenamento e Spoofing de requisições LLMNR e/ou NBT-NS, e o analista pode utilizar-se de ferramentas desenvolvidas para enviar requisições LLMNR e/ou NBT-NS falsas.
Este é um exemplo de utilização para a ferramenta Conveigh. No entanto, a mesma ferramenta pode ser utilizada em diversos contextos como durante a fase de Identificação e Análise em uma Resposta a Incidentes, ou a execução de forma periódica desta ferramenta em um dispositivo que esteja em um ponto estratégico da rede, com sua placa de rede em modo promíscuo, tanto para realizar captura de pacotes, ou, para executar ferramentas como a Conveigh para enviar falsas requisições para aquele segmento de rede, e então realizar a gravação de logs para futuras análises ou encaminhamento para um Servidor de Logs.
Para a execução do Conveigh, primeiramente devemos seguir alguns procedimentos:
- Executar o Powershell como Administrador;
- Permitir a execução de scripts em Powershell, utilizando as opções ‘-ep bypass’;
- Importar o módulo do Conveigh, para o contexto de sessão do Powershell;
- Executar o Conveigh através do comando ‘Invoke-Conveigh’ sem parâmetros, de forma padrão.
Na imagem a seguir, podemos observar a execução dos procedimentos detalhados acima, e consequentemente a detecção do nosso adversário identificado com o endereço IP 10.0.0.107.
Abaixo podemos observar que o adversário recebeu e respondeu as requisições LLMNR e NBT-NS falsas, enviadas pelo Conveigh, denunciando sua presença na infraestrutura.
Mitigação
As mitigações para a execução da Técnica T1557.001 são baseadas em desabilitação de features de ambientes Windows, e na aquisição de softwares de segurança para os Desktops que realizam inspeção de ataques a nível de pacotes. Abaixo, segue nossas sugestões de mitigações:
• Desabilitação do LLMNR e o NetBIOS nas configurações de segurança do computador local ou por política de grupo se não forem necessários em um ambiente.
• Habilitar a SMB Signing para interromper ataques de retransmissão NTLMv2 (Pass-The-Hash, SMB Relay etc).
• Aquisição e implementação de software de segurança para Desktops, com o objetivo de bloquear o tráfego LLMNR/NetBIOS.
• A realização de uma revisão referente à segmentação de rede pode ser útil para isolar dispositivos de infraestrutura crítica, e dispositivos que não exigem amplo acesso à rede. Isso pode mitigar, ou pelo menos aliviar, ataques Man-in-the-Middle.
• Também é possível que um EDR detecte a presença de softwares conhecidos como o Responder. É importante a criação de políticas para o bloqueio de hashes de ferramentas conhecidas.
Referências
- Conveigh: https://github.com/Kevin-Robertson/Conveigh
- Pyramid of Pain: http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
- LLMNR/NBT-NS Poisoning and SMB Relay: https://attack.mitre.org/techniques/T1557/001/
- Responder Toolkit: https://github.com/lgandx/Responder
- Link Local Multicast Name Resolution: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-llmnrp/6806998e-034d-4c39-8398-5af8bfd52d7e
- SMB Signing: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing
- Wireshark: https://www.wireshark.org/