Hunting em Windows e Active Directory

Nota 09 do capítulo 08 (Técnicas de Hunting por TTPs), levando a caça ao par endpoint e diretório, que concentra a superfície de autenticação corporativa.
Levanta a telemetria de Security log e AD, mapeia DCSync, Kerberoasting, Golden Ticket, pass-the-hash e abuso de ACL, com consultas KQL por evento.
Dialoga com a nota 08 em Linux, com a nota 10 em identidade e com os controles TH.11, TH.14 e DAT.1 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O Active Directory continua sendo a autoridade de identidade da maioria das organizações, e quase todo incidente grave em ambiente Windows passa por ele em algum momento: credenciais são extraídas, privilégios são escalados e o controle do diretório é o objetivo implícito do movimento lateral. Por isso a caça em Windows tem duas metades inseparáveis, o endpoint e o diretório, e as técnicas de maior valor prático vivem justamente na fronteira entre elas, onde um logon usa credenciais roubadas ou uma consulta de replicação sai de um host que não é controlador de domínio. Esta nota organiza essas metades em eventos, hipóteses e consultas.

O posicionamento na biblioteca segue a sequência do capítulo: as notas 06 e 07 cobriram a camada de rede, a nota 08 transferiu o exercício para Linux, e esta nota consolida a pilha Windows com foco em eventos de segurança numerados, que são o contrato mais estável da indústria. A nota 10 dá continuidade nos serviços de identidade modernos, onde o mesmo adversário aparece com tokens em vez de tickets, e os controles TH.11 e TH.14 do capítulo 15 recebem daqui o material de cobertura de endpoint e de autenticação.

2. Telemetria de Windows e Active Directory

A telemetria de AD se concentra no log Security dos controladores de domínio, complementada pelo Sysmon nos endpoints e por fontes estruturais como o NTDS.dit, a replicação e os objetos de política de grupo no SYSVOL. A força dessa telemetria é a estabilidade dos identificadores de evento, que permitem consultas precisas e duradouras; a fraqueza é que a auditoria correta precisa ser habilitada deliberadamente, porque políticas padrão deixam desligado justamente o que o hunting precisa, como auditoria de acesso a objetos do diretório. A tabela consolida os eventos de referência.

Três prerequisitos de configuração definem se essa tabela funciona. A auditoria avançada precisa cobrir acesso a objetos do diretório, senão os eventos 4662 e 5136 não existem; o Sysmon com configuração de processo e de rede precisa cobrir estações administrativas, porque é de lá que saem os logons com credenciais explícitas; e os logs dos controladores de domínio precisam ser centralizados em prazo curto, porque o adversário com controle do DC limpa o log local. O capítulo 02 descreve a coleta, e o controle DAT.1 exige a verificação de cobertura antes de qualquer caça nestas consultas.

3. TTPs de Diretório e suas Assinaturas por Evento

As técnicas de maior incidência em relatórios públicos têm assinatura de evento bem definida, e é essa definição que permite consultas curtas e confiáveis. DCSync solicita replicação com os GUIDs de estendido direito de replicação e só faz sentido vindo de host que não é DC; Kerberoasting pede TGS para muitos contas de serviço com criptografia RC4, que é o tipo 0x17, em rajada por origem; Golden Ticket é forjado fora do DC e aparece como uso de ticket sem concessão registrada; pass-the-hash produz logon tipo 9 com processo NewCredentials ou logon NTLM a partir de ferramenta de movimento lateral; e o abuso de ACL aparece como modificação de atributo ou de descritor de segurança em objeto sensível. A tabela liga cada técnica ao evento e ao filtro essencial.

A leitura de hunting da tabela é que cada técnica pede um par de filtro e contexto, porque o evento sozinho é legítimo com frequência. 4769 com 0x17 acontece o dia inteiro em qualquer AD; 4769 com 0x17 vindo da mesma origem para dezenas de SPN em minutos é Kerberoasting. 4624 tipo 9 é usado por ferramentas administrativas legítimas; tipo 9 com processo desconhecido e credencial de conta de administrador em estação comum é pass-the-hash. É esse padrão de evento mais contexto que as consultas da seção seguinte implementam.

4. Consultas KQL por Evento

A primeira consulta caça DCSync no evento 4662, filtrando pelos GUIDs de Direito Estendido de replicação e excluindo contas de máquina, que representam a replicação legítima entre controladores de domínio. Qualquer linha restante é suspeita por construção, porque usuário interativo solicitando replicação de credenciais do domínio não é operação administrativa normal.

// DCSync: replicacao solicitada por conta que nao e controlador de dominio
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4662 and ObjectServer =~ "DS"
| where Properties has_any ("1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
                            "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
                            "89e95b76-564d-4462-a34c-9e26207b12e7")
| where not(SubjectUserName endswith "$")
| project TimeGenerated, Sujeito = SubjectUserName, Alvo = ObjectName, Origem = IpAddress, Computer
| order by TimeGenerated desc

A segunda consulta caça Kerberoasting agregando o evento 4769 por origem, exigindo criptografia RC4 e muitos SPN distintos, que é o padrão de ferramenta de extração de hashes de serviço. O limiar de 10 SPN em 15 minutos é conservador e calibrável pelo baseline de scripts de inventário que também pedem TGS em rajada.

// Kerberoasting: muitos TGS com RC4 pedidos pela mesma origem
SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4769 and TicketEncryptionType =~ "0x17"
| where ServiceName !endswith "$"
| summarize SPNUnicos = dcount(ServiceName), Contas = dcount(TargetUserName),
            Ultimo = max(TimeGenerated)
            by IpAddress, Sujeito = SubjectUserName, Janela = bin(TimeGenerated, 15m)
| where SPNUnicos >= 10
| order by SPNUnicos desc

A terceira consulta cobre pass-the-hash no formato tipo de logon 9, que registra o uso de credenciais alternativas em sessão existente, padrão de runas com /netonly e de ferramentas de movimento lateral que injetam credencial. O filtro por processo exclui os casos de sistema que emitem o evento em rotina legítima, e a presença de conta privilegiada em estação de usuário comum é o critério de escalonamento.

// Pass-the-hash: logon tipo 9 com credencial privilegiada em estacao comum
SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4624 and LogonType == 9
| where AuthenticationPackageName =~ "Negotiate"
| where not(TargetUserName endswith "$")
| where ProcessName !in~ ("c:\\windows\\system32\\lsass.exe", "c:\\windows\\system32\\svchost.exe")
| join kind=leftanti (
    SecurityEvent
    | where TimeGenerated > ago(7d) and EventID == 4624 and LogonType == 9
    | summarize by Computer
) on Computer  // estacoes com uso administrativo documentado ficam de fora
| project TimeGenerated, Computer, Conta = TargetUserName, Processo = ProcessName, Origem = IpAddress

Para Golden Ticket, a caça parte da assimetria entre concessão e uso: 4624 tipo 3 com conta que não tem 4768 correspondente na janela anterior indica ticket que não veio do DC, e lifetime de TGT acima do padrão configurado reforça a hipótese. Como a rotação de senha do krbtgt não é rotina, a nota registra também o critério estrutural: domínio com krbtgt sem rotação desde a criação carrega risco permanente de Golden Ticket, porque qualquer hash antigo continua válido. O evento 4648 completa o quadro de movimento lateral: origem única usando credenciais explícitas para dezenas de destinos em minutos é ferramenta de varredura com credencial roubada, e a consulta abaixo implementa esse critério com a mesma disciplina de janela curta por origem.

// Movimento lateral em massa: credenciais explicitas para muitos destinos pela mesma origem
SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4648
| summarize Destinos = dcount(TargetServerName), Contas = dcount(TargetUserName),
            Ultimo = max(TimeGenerated)
            by WorkstationName, Origem = IpAddress, Processo = ProcessName,
               Janela = bin(TimeGenerated, 15m)
| where Destinos >= 10 or Contas >= 10
| order by Destinos desc

5. BloodHound e Análise de Caminhos de Ataque

O BloodHound materializa o grafo do diretório em consultas prontas de caminho de ataque, e é a ferramenta de referência para priorizar onde a caça de abuso de ACL deve olhar. As coleções SharpHound mapeiam relações de membership, delegação, ACL e sessão, e as consultas clássicas de caminho mais curto para Domain Admins, de controle de saída de grupos operacionais e de caminhos a partir de princípios comprometidos transformam milhares de relacionamentos em listas curtas de arestas de risco. A prática recomendada é colecionar periodicamente com identidade de leitura de baixo privilégio, guardar o histórico e comparar edições para detectar arestas novas, que são exatamente o que o abuso de ACL plantado aparece.

O BloodHound mostra possibilidade e não execução, e essa distinção disciplina o fluxo de hunting: uma aresta GenericAll de um grupo operacional para Domain Admins é hipótese, e a confirmação vem dos eventos 5136, 4662 e 4728 do diretório, que registram a modificação e o uso reais. A correspondência entre aresta do grafo e evento de auditoria também corrige os limites da ferramenta, porque sessões e privilégios locais envelhecem rápido e produzem caminhos irreais, e o cruzamento com o evento de logon da janela do caso é o que separa risco teórico de uso efetivo. O capítulo 09 descreve a ferramenta em detalhe operacional; aqui, o papel dela é fornecer a lista priorizada de objetos que as consultas da seção 4 monitoram.

6. Exemplo de Caça de Abuso de Privilégio

O caso simula a investigação de rumor de conta operacional com poder sobre administradores de domínio. A hipótese estruturada é: se um princípio de baixo privilégio recebeu controle sobre objeto sensível do AD, então o evento 5136 registra a modificação de ACL ou de membership em janela próxima a um logon privilegiado subsequente do mesmo sujeito, e a linha do tempo conecta ambas. O roteiro segue quatro passos com critérios de fechamento.

1. Listar modificações de membership e de ACL em grupos sensíveis com o evento 5136, filtrando os atributos member e nTSecurityDescriptor e os objetos de grupos administrativos, e datar cada modificação com usuário e origem, formando a linha de tempo de mudanças de poder no diretório.
2. Cruzar cada modificação com o evento 4662 do mesmo sujeito sobre o mesmo objeto, porque o abuso de ACL exige Direito Estendido ou WriteDacl e deixa esse registro quando a auditoria de acesso a objeto está ligada; a ausência dos dois eventos com a aresta presente no BloodHound muda o achado para risco de configuração e não para incidente.
3. Verificar logons subsequentes com 4624 e 4672 para a conta adicionada ou modificada, conferindo tipo de logon, estação de origem e elevação de token; logon interativo de conta nova a partir de estação fora do padrão de administração é o sinal de uso efetivo do poder plantado.
4. Fechar com varredura reversa de 30 dias para achar a primeira ocorrência do padrão, determinar se a modificação sobreviveu a limpeza e quantas contas foram tocadas, produzindo o escopo para a resposta do capítulo 13 e a correção de delegação com o time de identidade.

// Adicoes a grupos administrativos e logon privilegiado subsequente
let GrupoTocado = SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID in (4728, 4732, 4756)
| where TargetUserName in~ ("Domain Admins", "Administrators", "Enterprise Admins", "Schema Admins")
| project TimeGenerated, Grupo = TargetUserName, Membro = MemberName, Origem = SubjectUserName;
GrupoTocado
| join kind=inner (
    SecurityEvent
    | where TimeGenerated > ago(7d) and EventID == 4624
    | where LogonType in (2, 3, 10) and not(TargetUserName endswith "$")
    | summarize Logons = count(), Estacoes = make_set(Computer, 3) by Conta = TargetUserName
) on $left.Membro == $right.Conta
| project TimeGenerated, Grupo, Membro, Origem, Logons, Estacoes

O veredicto do caso precisa das três evidências concorrentes já padrão do capítulo: a modificação registrada no diretório, o uso de poder registrado em evento de logon e a anomalia de contexto, como estação de origem fora do baseline administrativo. Com uma evidência, o caso vira ajuste de delegação com o time de identidade; com duas, abre-se monitoramento nomeado da conta; com três, o caso segue para contenção imediata, incluindo reset de senha do sujeito, revisão das ACLs tocadas e verificação de persistência no DC com os eventos 7045 e 5136 do período.

7. Erros Comuns e Pontos de Atenção

• Caçar 4662 sem auditoria de acesso a objeto: a política padrão não registra a operação de replicação que o DCSync usa, e a consulta limpa retorna vazio por ausência de dados, e não por ausência de intrusão; verificar a configuração no DC antes de declarar cobertura.
• Agregar Kerberoasting por dia em vez de por rajada: ferramentas legítimas de inventário e serviços de monitoramento pedem TGS em janelas regulares, e a agregação diária mistura tudo; a janela de 15 a 30 minutos por origem é o que separa ferramenta de rotina de extração.
• Tratar o BloodHound como prova de execução: aresta de ataque é possibilidade, e sessões coletadas envelhecem em horas; fechar caso só com evento de auditoria correspondente, ou reclassificar como risco de configuração com dono e prazo.
• Excluir contas de máquina de forma acidental: contas de DC terminam em cifrão e fazem replicação legítima o dia inteiro, mas serviços de aplicação também rodam com contas de máquina; filtrar por sujeito que não é DC com verificação de lista, e não por sufixo sozinho.
• Ignorar o lado do endpoint: movimentação com credencial roubada deixa processo pai, linha de comando e 4648 na estação de origem, e caçar apenas no DC deixa a metade mais rica do caso de fora; a estação administrativa é o melhor lugar para caçar a origem do uso.

8. Integração com o Restante da Biblioteca

Esta nota opera sobre a coleta descrita no capítulo 02 e no controle DAT.1, aplica hipóteses do TH.6 e cobre endpoint e autenticação nos controles TH.11 e TH.14, com as lacunas registradas no MAP.4 para as técnicas da tabela da seção 3. A nota 10 continua a caça de identidade nos serviços modernos, onde os mesmos padrões aparecem como token e consentimento em vez de ticket, e a nota 11 estende para a nuvem, onde o controlador de domínio virou provedor de identidade. O capítulo 09 documenta as ferramentas citadas, inclusive o BloodHound, e o capítulo 18 recebe as consultas estáveis como regras de analytics com os limiares calibrados pelas métricas do MET.2. Quando a caça confirma técnica e infraestrutura, o capítulo 05 orienta a atribuição e o capítulo 13 recebe o caso, fechando o ciclo de hunting para resposta e para inteligência que a biblioteca defende desde o capítulo 01.