Hunting de Identidade e Autenticação

Nota 02 do capítulo 26, que leva o hunting para o plano de controle das identidades, onde a maior parte das intrusões modernas começa.
O foco são os sinais de caça em autenticação, as fontes de telemetria de IdP e as consultas KQL que transformam hipóteses em buscas.
Dialoga com a nota 01 deste capítulo, com a nota 10 do capítulo 08 e com as notas de hipóteses do capítulo 06.

1. Contexto e Posicionamento na Biblioteca

A identidade assumiu o lugar que a rede ocupava na década anterior como principal plano de controle da intrusão: o atacante que obtém uma sessão válida dispensa exploração de vulnerabilidade, evita a EDR e opera com as ferramentas nativas do ambiente. O hunting de identidade é, por isso, a capacidade proativa de maior retorno em ambientes modernos, e a sua matéria-prima é a telemetria de autenticação, que existe em volume abundante em praticamente toda organização com IdP centralizado. Esta nota organiza os sinais de caça, as fontes e as consultas, e executa um caso completo de caça de token replay.

A nota pressupõe o ciclo de caça do capítulo 06 para a formulação de hipóteses e usa a sintaxe KQL introduzida na nota 03 do capítulo 09. A nota 03 deste capítulo estende o tema ao ambiente híbrido AD e Entra ID, e a nota 04 aprofunda os tokens e o OAuth, mecanismo por trás de vários sinais aqui tratados. A disciplina central é a mesma de todo hunting: hipótese explícita, dados nomeados, resultado documentado e produto que fecha o loop com a inteligência.

2. Identidade como Novo Perímetro

O perímetro moderno não é a fronteira de rede, mas o conjunto de identidades capazes de acessar recursos: contas humanas, contas de serviço, aplicativos federados e as credenciais que os representam. O atacante segue a mesma lógica do defensor econômico: roubar identidade custa menos que explorar código, escala melhor e deixa menos rastro binário. É por isso que o catálogo de intrusões recentes é dominado por password spray, roubo de sessão via AiTM, consenso fraudulento de aplicativo e abuso de ajuda técnica, e não por exploits de dia zero em servidores.

Para o hunter, essa realidade muda o desenho da caça. A pergunta deixa de ser "qual processo anômalo rodou no host" e passa a ser "qual comportamento de autenticação não combina com a identidade e com o recurso acessado". A resposta exige baseline: horas habituais, países habituais, dispositivos habituais e aplicações habituais por usuário, porque os sinais de identidade são relacionais e não absolutos. O hunting de identidade sem baseline gera filas de viagens impossíveis falsas causadas por VPN e por cache de CDNs de autenticação.

O baseline é a ferramenta central do hunting de identidade, e a sua construção é mais simples do que parece: para cada usuário ou grupo funcional, a organização conhece os países de acesso, os ASNs habituais, os dispositivos registrados, as aplicações consumidas e os horários de operação. O sinal de identidade ganha significado apenas na comparação com esse perfil, e um logon de Amsterdã às 3h pode ser rotina para o time de plantão e anomalia grave para a contabilidade. A caça madura começa pela modelagem do normal, e não pela lista de ataques possíveis.

3. Catálogo de Sinais de Caça

O catálogo abaixo reúne os sete sinais de maior produtividade no hunting de identidade, com a descrição operacional e o falso positivo frequente de cada um. A coluna de falso positivo não é detalhe: é ela que define o enriquecimento obrigatório de qualquer regra derivada destes sinais.

A priorização entre sinais segue o risco do recurso acessado e não apenas a raridade do evento: um sign-in anômalo em conta de administrador global de IdP vale dezenas de alertas em conta padrão. Essa ponderação conecta o catálogo com a priorização de hipóteses do framework THRIVE e do capítulo 06, e com a pirâmide de dor, porque sinais comportamentais como token replay doem mais para o atacante do que os IPs que ele troca semanalmente.

A matriz de priorização considera dois eixos: a raridade do sinal no parque e o valor do recurso acessado. O sinal raro em conta de administrador global do IdP sai na frente do sinal frequente em conta padrão, e a mesma lógica vale para contas de serviço com escopos altos. O hunter registra a matriz junto com as hipóteses, porque a ordem de execução da caça é decisão analítica e não ordem de chegada de alertas.

4. Fontes de Dados de Identidade

A telemetria de identidade está distribuída em quatro fontes principais, e o hunter precisa conhecer os campos decisivos de cada uma antes de escrever consultas. A tabela abaixo organiza as fontes com os campos-chave e a cobertura que oferecem.

A última linha da tabela é a mais subestimada: o sinal de autenticação confirma a porta, mas é o log de recurso que prova o crime. A correlação entre logon e consequência, exibida no caso da seção 6, é o que separa a caça de identidade madura da pilha de alertas de viagem impossível.

A retenção das fontes orienta a logística da caça: os logs de sign-in do Entra ID ficam disponíveis nativamente por janela curta, e o envio para o SIEM é o que garante histórico suficiente para hipóteses de médio prazo. O hunter verifica três condições antes de iniciar: cobertura completa de usuários e aplicativos na fonte, campos de sessão e de token preservados no transporte e relógios sincronizados entre fontes para a correlação entre autenticação e consequência. Faltando qualquer uma das três, a hipótese é adiada e a lacuna de dados vira requisito formal junto ao time de plataforma.

5. Consultas KQL de Exemplo

As consultas abaixo ilustram o padrão de caça sobre a telemetria do Entra ID, cada uma ancorada em um sinal do catálogo da seção 3. Elas devem ser executadas com a janela temporal ajustada ao escopo da hipótese, e os limiares são pontos de partida a calibrar com o baseline da organização.

// Password spray: um IP, muitos usuários, rajada de falhas em 10 minutos
SigninLogs
| where ResultType in (50126, 50053)
| summarize tentativas = count(), usuarios = dcount(UserPrincipalName),
            apps = dcount(AppDisplayName) by IPAddress, bin(TimeGenerated, 10m)
| where tentativas >= 20 and usuarios >= 5
| order by tentativas desc

// MFA fatigue: rajada de solicitações de segundo fator por usuário e IP em 1 hora
SigninLogs
| where ResultType == 50074
| summarize pushes = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where pushes >= 8
| project TimeGenerated, UserPrincipalName, IPAddress, pushes
| order by pushes desc

// Sign-in anômalo: dois países e três ASNs distintos na mesma hora por usuário
SigninLogs
| where ResultType == 0
| summarize paises = dcount(Country), asns = dcount(ASN),
            dispositivos = dcount(tostring(DeviceDetail.deviceId))
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where paises >= 2 or asns >= 3
| order by paises desc

Cada consulta vira detecção permanente quando o falso positivo está controlado e a hipótese se confirma repetidamente, seguindo a ponte caça para deteção do capítulo 18. O inverso também vale: quando a consulta não produz nada por um trimestre, ela se aposenta do cronograma e fica registrada como hipótese testada, mantendo o catálogo de caça honesto e enxuto.

6. Caso de Caça: Token Replay

A hipótese que abre o caso nasceu de intel do capítulo anterior: grupos de acesso inicial roubam sessão via AiTM e reusam token dentro de minutos, e o sinal distintivo não é o logon anômalo, que o atacante evita, mas o uso do mesmo identificador de token em contexto geográfico incompatível. A caça seguiu o plano abaixo, e o resultado ilustrado é fictício, mas fiel ao padrão operacional real.

// Correlação interativo + não interativo para o usuário alvo, 24 horas
union SigninLogs, AADNonInteractiveUserSignInLogs
| where ResultType == 0 and UserPrincipalName == "diretoria@empresa.example"
| project TimeGenerated, OperationName, AppDisplayName, IPAddress,
          Country, SessionId, UniqueTokenIdentifier
| order by TimeGenerated asc

A leitura da saída revelou a assinatura do replay: o token com UniqueTokenIdentifier 0aF3...b91 foi usado às 14h07 em São Paulo, com dispositivo registrado e MFA de phishing resistente, e às 14h15 o mesmo identificador apareceu consultando o Microsoft Graph a partir de um ASN de hosting em Amsterdã, sem dispositivo e sem MFA, porque o token dispensa reautenticação. Os logs de auditoria da caixa seguintes mostraram a consequência: uma busca de conteúdo criada às 14h19 e um download de anexos às 14h22, ambos iniciados pela mesma sessão. A resposta executou a revogação de sessões, a redefinição de credenciais e a revisão de regras de caixa, e o produto da caça incluiu a detecção permanente de replay por UniqueTokenIdentifier, a atualização do perfil de ameaça no TIP e a recomendação de proteção de token, detalhada na nota 04 deste capítulo.

O caso ilustra a estrutura que toda caça de identidade deve ter: hipótese com origem declarada, consulta que correlaciona autenticação com consequência, linha do tempo fechada e produto em três camadas, deteção, resposta e inteligência. A ausência de qualquer uma das camadas reduz a caça a curiosidade analítica.

O protocolo de resposta ao achado abaixo formaliza a transição da caça para a resposta, e cada passo tem dono definido no playbook de identidade.

1. Confirmar a anomalia com a linha do tempo completa de autenticação e consequência.
2. Revogar sessões e refresh tokens do usuário afetado antes de qualquer comunicação.
3. Redefinir credenciais e revalidar os fatores de segurança registrados.
4. Revisar regras de caixa, permissões OAuth e registros de dispositivo criados na janela.
5. Registrar a cadeia no TIP e no caso de incidente, com carimbos e evidências.
6. Alimentar a deteção permanente e o ciclo de inteligência com o novo padrão.

7. Erros Comuns e Pontos de Atenção

O erro mais comum é caçar sem baseline e transformar o catálogo da seção 3 em fábrica de viagens impossíveis falsas, descredenciando a caça de identidade junto ao SOC. O erro mais grave é parar no sinal de autenticação sem examinar a consequência, encerrando o caso na pergunta errada. Ambos se corrigem com a mesma disciplina: enriquecer o sinal com o contexto de identidade e sempre correlacionar com o log do recurso acessado.

Completam a lista os itens abaixo.

• Tratar ASN de CDN de autenticação como hostil, gerando volume impossível de manter.
• Ignorar contas de serviço e aplicativos federados no escopo da caça, que ficam com o perímetro apenas humano.
• Usar limiares copiados de consultas públicas sem calibrar com o parque da organização.
• Não revogar sessões após o achado, deixando o token vivo enquanto a senha é trocada.
• Fechar o caso sem documentar a hipótese testada, perdendo o acervo que evita retrabalho futuro.

• Não devolver o achado ao TIP, deixando a inteligência sem o feedback que abre o próximo PIR.

• Tratar todo alerta de identidade como incidente, esgotando a capacidade de resposta antes das hipóteses de maior valor.

• Aplicar o mesmo limiar a contas humanas e de serviço, ignorando que as de serviço têm padrão de uso próprio.

• Tratar os logs de recurso como opcional, encerrando a caça na porta sem examinar o que a sessão fez.

• Não calibrar a janela temporal das consultas, propondo hipóteses que o histórico disponível não consegue responder.

• Executar a caça com conta de leitura ampla fora de ambiente controlado, expondo dados sensíveis de identidade.

8. Integração com o Restante da Biblioteca

A nota consome intel da nota 01 deste capítulo e do capítulo 05 para priorizar hipóteses, e produz deteções para o capítulo 18 pela ponte caça para deteção. A nota 10 do capítulo 08 cobre o mesmo domínio pela perspectiva de TTPs ATT&CK, e a nota 03 deste capítulo estende a caça ao ambiente híbrido AD e Entra ID, onde a sincronização cria pontes de ataque próprias. A nota 04 aprofunda os mecanismos de token e OAuth que explicam sinais como replay e consent abuse. No framework CTH, a caça de identidade alimenta os controles do grupo HNT e a resposta aos achados ancora no ciclo de resposta do capítulo 07, fechando o circuito proativo que o capítulo 26 se propõe a montar.