Hunting de Identidade e Autenticação

Nota 10 do capítulo 08 (Técnicas de Hunting por TTPs), levando a caça ao plano de identidade em serviços modernos, onde o token substituiu o ticket.
Levanta os sinais de identidade (SSO, logs de entrada do Entra ID, MFA), organiza os padrões de abuso e entrega consultas KQL e o caso de password spray.
Dialoga com a nota 09 em Active Directory, com a nota 11 em cloud e SaaS e com o controle TH.14 (Análise de Autenticação) do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O plano de identidade é hoje a fronteira mais contestada do ataque corporativo: o adversário moderno compra credenciais, phisha consentimento, rouba token de sessão e entra como usuário legítimo, sem malware e sem exploit, e a pergunta do hunting muda de o que rodou na máquina para quem entrou com o quê de onde. Incidentes públicos recentes, de campanhas contra suporte de help desk a roubo de token de MFA, mostram que a identidade comprometida é o vetor de entrada dominante e que a telemetria de autenticação é a fonte mais decisiva da investigação inteira. Esta nota organiza esses sinais em padrões caçáveis e consultas executáveis.

O posicionamento na biblioteca é o de continuação natural da nota 09: lá o contrato era Kerberos e eventos numerados do log Security, aqui o contrato é SSO, logs de entrada do provedor de identidade e tokens OAuth. A nota 11 herda o material para cloud e SaaS, porque o mesmo token que abriu o painel abre o portal do provedor, e o controle TH.14 do capítulo 15 é o destino institucional deste conteúdo na disciplina de análise de autenticação e credenciais.

2. Sinais de Identidade Disponíveis para Caça

A pilha de identidade produz telemetria estruturada em poucas fontes bem definidas, e a qualidade do hunting depende de todas estarem ingeridas, porque o padrão que denuncia o abuso costuma cruzar duas delas. Os logs de entrada interativa registram o usuário digitando ou respondendo MFA; os logs não interativos registram o uso silencioso de token, que é onde token roubado e refresh abuse aparecem; os logs de auditoria registram mudanças de configuração, consenso de aplicativo e criação de credencial; e os eventos de proteção de identidade entregam risco calculado por entrada. A tabela consolida as fontes no vocabulário do Entra ID, com equivalentes conceituais em qualquer IdP.

Três configurações determinam se essas fontes sustentam caça real. O log não interativo precisa estar habilitado, porque é ele que mostra a sessão usada depois do roubo; a política de acesso condicional precisa estar em modo de relatório ou aplicado com log completo, porque o resultado de acesso condicional é o contexto que separa ataque bloqueado de ataque bem-sucedido; e a retenção precisa cobrir janelas de campanha de semanas, porque spray e consent phishing acontecem em séries. Sem essas três peças, as consultas seguintes caçam sobre telemetria parcial e as conclusões perdem validade.

3. Padrões de Abuso de Identidade

Os padrões dominantes formam um repertório curto e estável, e cada um tem um sinal específico que a consulta explora. A viagem impossível é a mesma conta em posições geograficamente incompatíveis em janela curta; o password spray é uma origem tentando poucas senhas em muitas contas, invertendo a geometria da força bruta; o MFA fatigue é rajada de solicitações de push até o usuário aprovar; o consent phishing é aplicativo OAuth com escopo perigoso consentido por usuário; e o abuso de token é a sessão que continua funcionando sem interação depois de evento de risco ou de troca de credencial. A tabela liga cada padrão ao sinal e à fonte.

A leitura operacional da tabela é que nenhum padrão fecha caso sozinho: viagem impossível engana com VPN e dispositivos móveis, spray engana com provedores residenciais, e aprovação de MFA legítima existe. O desenho correto é sempre o mesmo do capítulo: a consulta produz candidatos, o enriquecimento com risco, dispositivo e histórico produz prioridade, e a linha do tempo de autenticação da conta produz veredicto. As consultas da seção seguinte implementam os quatro primeiros padrões e a identidade não humana cobre o quinto.

4. Consultas KQL para o Entra ID

A consulta de password spray agrega falhas 50126 por origem, exigindo muitas contas distintas tocadas, e cruza com sucessos da mesma origem, porque spray sem sucesso é campanha e spray com sucesso é incidente. O limiar de 20 contas em 24 horas é ponto de partida que o baseline de portal de serviço e scripts legítimos vai ajustar.

// Password spray: uma origem, muitas contas com falha, e sucesso subsequente
let Janela = 1d;
SigninLogs
| where TimeGenerated > ago(Janela)
| where ResultType == 50126
| summarize ContasFalha = dcount(UserPrincipalName), Tentativas = count() by IPAddress
| where ContasFalha >= 20
| join kind=leftouter (
    SigninLogs
    | where TimeGenerated > ago(Janela) and ResultType == 0
    | summarize Sucessos = count(), ContasOK = dcount(UserPrincipalName) by IPAddress
) on IPAddress
| extend ContasOK = iff(isnull(ContasOK), 0, ContasOK)
| where Sucessos >= 1 or ContasFalha > 100
| project IPAddress, ContasFalha, Tentativas, ContasOK, Sucessos
| order by ContasFalha desc

A consulta de MFA fatigue procura a rajada de segunda fator negado ou interrompido seguida de aprovação, que é o padrão comportamental da técnica. O corte por origem e por usuário distingue o empurrão concentrado em uma vítima da campanha distribuída, e os dois merecem tratamento diferente: o primeiro é caso de resposta imediata, o segundo é caso de contenção de campanha.

// MFA fatigue: rajada de segundo fator negado seguida de aprovação
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in (500121, 50074)
| summarize Negacoes = count() by IPAddress, Usuario = UserPrincipalName
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(1d) and ResultType == 0
    | summarize Aprovacoes = count(), HoraOK = min(TimeGenerated)
              by IPAddress, Usuario = UserPrincipalName
) on IPAddress, Usuario
| where Negacoes >= 10
| project Usuario, IPAddress, Negacoes, Aprovacoes, HoraOK
| order by Negacoes desc

A consulta de consent phishing varre a auditoria por consenso de aplicativo com escopos que dão acesso a correio, arquivos ou papéis, e cruza o consenso com o perfil do consentidor, porque usuário comum concedendo permissão de leitura de todos os correios é o padrão da técnica. Os escopos listados são os de maior dano prático e a lista deve crescer com o inventário de aplicativos homologados da organização.

// Consent phishing: consenso de aplicativo com escopos sensíveis
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName =~ "Consent to application"
| extend Aplicativo = tostring(TargetResources[0].displayName)
| mv-expand Propriedade = TargetResources[0].modifiedProperties
| where tostring(Propriedade.displayName) =~ "Scope"
| extend Escopos = tostring(Propriedade.newValue)
| where Escopos has_any ("Mail.Read", "Mail.Send", "Files.Read.All", "Directory.ReadWrite.All", "RoleManagement.ReadWrite.Directory")
| extend Consentidor = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| project TimeGenerated, Aplicativo, Escopos, Consentidor
| order by TimeGenerated desc

O abuso de token aparece na comparação entre planos de entrada: sessão não interativa bem-sucedida sem entrada interativa correspondente nas horas anteriores, com risco elevado ou dispositivo não registrado, é a assinatura de cookie roubado em uso. A consulta abaixo conta sucessos não interativos por conta e por aplicativo, filtra os que têm interativo recente na mesma origem e prioriza os de acesso condicional não satisfeito, que são os casos em que o token furou a política.

// Token abuse: entrada nao interativa bem-sucedida sem interativo recente correspondente
let Janela = 1d;
let NaoInterativo = AADNonInteractiveSigninLogs
| where TimeGenerated > ago(Janela) and ResultType == 0
| summarize NaoInterativos = count(), IPsNI = dcount(IPAddress), UltimoNI = max(TimeGenerated)
            by Conta = UserPrincipalName, Aplicativo = AppDisplayName;
NaoInterativo
| join kind=leftanti (
    SigninLogs
    | where TimeGenerated > ago(Janela) and ResultType == 0
    | summarize by UserPrincipalName, IPAddress
) on $left.Conta == $right.UserPrincipalName
| where NaoInterativos >= 10
| project Conta, Aplicativo, NaoInterativos, IPsNI, UltimoNI
| order by NaoInterativos desc

5. Identidade Não Humana

Service principals, identidades gerenciadas e aplicações registradas são a identidade que roda sem humano, e o abuso dela é uma das vias mais silenciosas de persistência em cloud, porque ninguém recebe push de MFA para aprovar. Os sinais de caça são a criação de credencial nova em aplicativo existente, que é backdoor clássico; a entrada de service principal de origem que nunca foi vista para aquele aplicativo; e o escopo de permissão desproporcional à função declarada, que o inventário de aplicativos homologados referencia. O evento de auditoria de adição de segredo ou certificado é raro o bastante para valer alerta direto, e a consulta abaixo cobre a entrada anômala.

// Service principal entrando de origem nova ou com volume anômalo
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Entradas = count(), IPs = dcount(IPAddress), Primeira = min(TimeGenerated)
            by AppDisplayName, AppId
| where IPs > 3 or Entradas > 1000
| extend Leitura = strcat(AppDisplayName, " entrou de ", IPs, " IPs distintos com ", Entradas, " entradas")
| order by IPs desc

O acompanhamento correto dessa seção é institucional e não só técnico: todo aplicativo com escopo sensível precisa de dono, de justificativa e de data de revisão no inventário, e o hunting compara o uso observado com a justificativa registrada. Service principal sem dono com escopo de escrita em diretório é o equivalente moderno da conta de administrador sem nome no AD, e a caça que o encontra deve virar ticket de governança com prazo, porque a próxima campanha pública vai começar exatamente por ele.

6. Exemplo de Caça de Password Spray

O caso simula a detecção proativa de campanha de spray contra o tenant. A hipótese estruturada é: se um operador sprayia senhas comuns contra o IdP, então existe origem com falhas 50126 distribuídas em dezenas de contas distintas em janela curta, com eventual sucesso seguido de entrada não interativa que revela o alcance real. O roteiro segue quatro passos com critérios de fechamento.

1. Rodar a consulta da seção 4 em janela de 24 horas e listar as origens com mais contas tocadas, separando provedores residenciais de VPNs de datacenter; a mistura de provedores residenciais é o padrão de operação profissional e eleva a prioridade da linha.
2. Extrair a lista de contas com falha e checar, para cada uma, se houve sucesso posterior na mesma origem ou em origem nova nas 48 horas seguintes, usando a entrada interativa e a não interativa; cada conta com sucesso converte a campanha em incidente de conta comprometida e aciona resposta imediata.
3. Abrir a linha do tempo das contas com sucesso, conferindo acesso condicional, MFA usada, dispositivo e aplicativo acessado, porque o spray bem-sucedido raramente para no primeiro acesso e a entrada não interativa mostra o token em uso silencioso.
4. Fechar o caso com o alcance da campanha: contas tocadas, contas comprometidas, origens e janela total, alimentando o bloqueio de origens, a revogação de sessão e o alerta de CTI com as infraestruturas, no formato que o capítulo 02 descreve para compartilhamento.

O veredicto é graduado pela mesma disciplina das notas anteriores: origens com falha e sem sucesso viram bloqueio e monitoramento nomeado, com registro da campanha; qualquer sucesso converte o caso em comprometimento de conta, com revogação de token, reset de senha e revisão de MFA da conta afetada. O erro a evitar é declarar vitória com o bloqueio das origens, porque spray é barato e a origem muda em minutos; o valor do caso está nas contas comprometidas encontradas e nas lições de política, como bloqueio de autenticação legada, que reduzem a superfície da próxima campanha.

7. Erros Comuns e Pontos de Atenção

• Caçar só o log interativo: o uso silencioso de token é onde o comprometimento vivo aparece, e ignorar o log não interativo deixa a caça vendo só a porta da frente enquanto o adversário usa a porta dos fundos.
• Tratar risco calculado como prova: a pontuação do IdP erra nas duas direções, e o hunting que só olha entradas de alto risco perde spray com risco baixo e afoga em falsos positivos de rede residencial; risco é priorizador, e a linha do tempo é a prova.
• Usar viagem impossível sem considerar dispositivos móveis: operadoras e CDN de rede móvel produzem geolocalização errática, e a consulta precisa considerar ISP, ASN e device ID antes de declarar viagem impossível, senão cada viajante corporativo vira caso.
• Bloquear a origem e encerrar: origem de spray é commodity e é trocada na hora; encerrar o caso no bloqueio deixa as contas com sucesso sem revisão, e é exatamente nelas que o incidente real aconteceu.
• Esquecer a identidade não humana: service principal com credencial plantada não recebe MFA e não reclama de push, e a persistência dele dura até alguém auditar; incluir os logs de entrada de aplicativo na rotação de caças mensais, com o inventário como referência.

8. Integração com o Restante da Biblioteca

Esta nota opera sobre a coleta de identidade descrita no capítulo 02, aplica as hipóteses do TH.6 e é a aplicação direta do controle TH.14 de análise de autenticação e credenciais, com cobertura registrada no MAP.4 para as técnicas da tabela da seção 3. A nota 09 fornece a contraparte Kerberos, e a comparação entre ticket e token nas duas notas é material para a formação de analista descrita no capítulo 12; a nota 11 herda a identidade comprometida como porta de entrada do cenário de cloud, e o capítulo 13 recebe os casos com conta confirmada para resposta, incluindo revogação de sessão e contenção de campanha. As consultas maduras viram regras no capítulo 18, o capítulo 05 orienta a expressão de confiança quando a campanha é atribuível, e o ciclo de feedback do controle CTI.9 recebe o resultado da caça como atualização dos PIRs sobre ameaça de identidade, fechando o loop que a biblioteca defende entre inteligência e operação.