TH.14 - Análise de Autenticação e Credenciais

Nota do grupo HNT (Threat Hunting) do Framework CTH, seção "15 - Framework CTH - Controles".
Deriva do Capítulo 13, controle TH.14, e opera sobre os logs de autenticação centralizados em DAT.1 e DAT.4.
Papel no programa: expor o movimento lateral e o abuso de identidade, estágio em que o adversário já
tem credencial válida e a assinatura clássica de comprometimento desaparece do radar automatizado.

1. Contexto e Posicionamento no Framework CTH

O hunting de autenticação é o controle TH.14 do grupo HNT e atua na fase da intrusão em que a
detecção tradicional perde força. Depois do acesso inicial, a maioria dos adversários abandona o
exploit e passa a operar com credenciais válidas, seja hash capturado, ticket forjado, token roubado
ou senha obtida por phishing. Nesse estágio, o acesso é legítimo na forma e anômalo no contexto, e é
o contexto, horário, origem, frequência e relação entre entidades, que o hunter caça. Ataques de
credencial estão entre os vetores mais eficazes descritos em relatos de incidentes, e a trilha de
autenticação é a única fonte que registra toda a trajetória de movimento lateral de ponta a ponta.

Este controle consome a telemetria de DAT.1 (eventos de segurança do Windows, auditoria do Active
Directory) e os logs de plataforma de identidade da nuvem, e opera em par com TH.15, que transforma
esses mesmos dados em perfis comportamentais. A diferença de abordagem é importante: aqui o hunter
parte de padrões conhecidos de abuso, com hipóteses do método TH.6 e sinais específicos por técnica;
no TH.15 o sistema propõe desvios estatísticos sem técnica previamente definida. Os dois caminhos
convergem na qualificação de achado e na abertura de caso no IR.x.

2. Autenticação como Trilha de Ouro do Movimento Lateral

Todo movimento lateral gera pelo menos um evento de autenticação no destino, e frequentemente um no
controlador de domínio. Isso faz dos logs de autenticação a fonte de maior cobertura temporal e
espacial sobre a movimentação: enquanto a telemetria de processo existe apenas nos hosts com agente,
os eventos 4624, 4625, 4768, 4769 e 4770 se concentram nos controladores de domínio, que estão
sempre no inventário e sempre telemetrados. Caçar na autenticação é, na prática, caçar a rede de
relações entre identidades e sistemas.

A hipótese típica deste controle tem formato direto: SE uma conta de serviço inicia logon
interativo, ENTÃO há abuso de credencial; SE uma conta de usuário autentica em dezenas de hosts em
minutos, ENTÃO há movimento lateral automatizado; SE um usuário solicita tickets com encriptação
antiga para muitos serviços, ENTÃO há kerberoasting. Cada formato se traduz em consulta repetível,
com volume e cadência acordados na fila de TH.5.

3. Eventos do Windows e Tipos de Logon

Os eventos centrais do Windows são 4624 (logon bem-sucedido) e 4625 (logon falho), e o campo mais
valioso para o hunter é o Logon Type, que revela a natureza da sessão. O evento 4625 alimenta
detecções de força bruta e varredura de senha, e o 4624 alimenta a maior parte do hunting lateral.
Eventos complementares incluem 4648 (logon com credenciais explícitas, marca de ferramentas como
runas e PsExec), 4672 (privilégios especiais atribuídos) e 4634/4647 (encerramento de sessão).

Os padrões de caça derivam direto da tabela: conta de serviço com tipo 2 ou 10, logon tipo 3 de
estações de usuário, tipo 9 executado por conta que nunca o usou e tipo 10 que não parte dos hosts
de administração definidos no baseline. Cada um desses desvios costuma ser benigno isoladamente em
ambiente grande, e é a combinação com origem, horário e conta que fecha a hipótese.

4. Kerberos e Ataques Clássicos

4.1 Kerberoasting

O kerberoasting solicita tickets de serviço (TGS) para SPNs com conta de domínio e quebra a senha
offline, aproveitando que a encriptação do ticket segue a configuração da conta alvo. O sinal de
caça é o evento 4769 com encryption type RC4 (0x17) em volume anômalo por usuário solicitante,
especialmente quando o mesmo usuário pede tickets de muitos SPNs distintos em minutos. A mitigação
estrutural é contas de serviço com AES e senhas longas ou gMSA, e o hunt continua válido porque
ambientes reais carregam legado RC4 por anos.

4.2 Pass-the-hash e pass-the-ticket

O pass-the-hash usa o hash NTLM como credencial direta, produzindo logon tipo 3 sem interação prévia
com a senha. Sinais de caça: logon tipo 3 com NTLM de origem que não é o host normal da conta,
sessão iniciada sem autenticação interativa correspondente imediatamente anterior e uso simultâneo
da mesma conta de vários hosts. O pass-the-ticket reutiliza tickets Kerberos roubados, e aparece
como uso do mesmo ticket de origens diferentes ou ticket de sessão que sobrevive à troca de senha da
conta. Ambos os padrões exigem correlação com o endpoint de origem, pois o logon por si não
distingue a ferramenta usada.

4.3 DCSync

O DCSync abusa do protocolo de replicação para pedir todos os hashes do domínio com uma solicitação
de replicação direta. O sinal é o evento 4662 com GUID de replicação de diretório
(DS-Replication-Get-Changes e Get-Changes-All) solicitado por conta que não é controlador de domínio
nem conta de serviço de replicação. Qualquer origem de replicação fora da lista fixa de DCs é achado
de alta prioridade, porque contas comprometidas com esse direito se tornam senhoras do domínio em
silêncio.

5. NTLM versus Kerberos

O NTLM é o protocolo que viabiliza pass-the-hash, relay e responder, e o Kerberos, quando bem
configurado, reduz parte dessa superfície com tickets curtos e criptografia forte. Restringir NTLM,
desabilitando onde possível e auditando onde não, é medida que melhora a postura e simplifica o
hunting, porque os eventos NTLM restantes deixam de ser ruído de aplicação e passam a ser exceções
investigáveis. O evento 4624 com pacote NTLM v1 ou o uso de NTLM por contas administrativas são
hunts permanentes em ambientes em transição. A auditoria inicial mapeia quem ainda depende de NTLM,
a política elimina dependências por ondas e o hunt verifica que a redução se sustenta no tempo.

6. Contas de Serviço e gMSA

Contas de serviço com senha estática são o elo fraco da autenticação corporativa: senha longa nunca
rotacionada, compartilhada entre sistemas e consultável em atributos legados. O hunting prioriza
contas de serviço com logon interativo, contas de serviço logando em hosts fora da lista esperada e
contas de serviço usadas como conta de usuário em autenticação interativa. A introdução de gMSA, com
senha gerenciada e rotacionada automaticamente, reduz a superfície e cria padrão de autenticação
mais regular, o que melhora a sensibilidade do baseline. O mapa de conta de serviço para host
esperado, mantido em conjunto com o time de infraestrutura, é o referencial que transforma consultas
genéricas em hunts precisos.

7. Entra ID e Ambiente de Nuvem

A identidade em nuvem estende o campo de caça além do Active Directory. Os sinais prioritários em
Entra ID são: sign-ins de localização impossível, autenticação bem-sucedida em protocolo legado que
não suporta MFA, consentimento de aplicação OAuth com permissões de leitura de e-mail e arquivos
(consent phishing), reuso de token em contexto diferente do emitido e padrão de MFA fatigue com
sequência anômala de pushes negados seguidos de aprovação. Cada plataforma expõe esses eventos com
nomes próprios de campo, e o hunt deve abstrair a consulta do nome comercial do log, focando na
semântica: origem, aplicação, resultado, desafio MFA e dispositivo.

A consulta abaixo exemplifica a anomalia de logon mais clássica do hunting de identidade: o mesmo
usuário autenticando em muitos hosts distintos em janela curta, padrão de movimento lateral ou de
conta compartilhada.

SecurityEvent
| where TimeGenerated > ago(4h)
| where EventID == 4624 and LogonType in (3, 10)
| summarize Hosts = dcount(Computer), SampleHosts = make_set(Computer, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by Account = tostring(TargetUserName)
| where Hosts >= 10
| extend DurationMinutes = datetime_diff("minute", LastSeen, FirstSeen)
| where DurationMinutes <= 30
| sort by Hosts desc

8. Baseline de Autenticação

Baseline de autenticação é o mapa do que é normal: lista de contas por função com hosts esperados,
tipos de logon esperados por conta, horários típicos por perfil funcional, origens geográficas de
VPN e lista fixa de controladores de domínio e contas de replicação. O baseline alimenta as
consultas por exclusão, reduz falsos positivos e serve de referência rápida na qualificação.
Construído em duas etapas, primeiro estatístico a partir de 30 a 90 dias de dados, depois validado
com os donos de cada sistema, ele precisa ser versionado e revisado, como define o controle TH.2,
com revisão a cada mudança relevante de infraestrutura de identidade. Sem baseline, todo hunt de
autenticação afunda em exceções legítimas; com baseline, a caça se concentra no resíduo que sobra.

9. Salvaguardas por Nível de Maturidade

As salvaguardas seguem o padrão de subcontroles do framework, do Básico ao Avançado.

10. Erros Comuns e Pontos de Atenção

O erro mais comum é olhar só para 4625 e ignorar 4624, concentrando o hunting em ataques ruidosos de
força bruta e perdendo o adversário silencioso que já acertou a senha na primeira tentativa. Falhas
são sinal de tentativa; sucesso anômalo é sinal de comprometimento. O segundo erro é aplicar
contagens absolutas de eventos sem normalizar por conta e por função: em ambiente grande, uma conta
de sistema legítima gera mais logons por minuto do que qualquer adversário, e a ausência de baseline
transforma a consulta em lamento estatístico.

O terceiro erro é tratar identidade de nuvem e identidade on-premises como universos separados,
quando o adversário pivota entre os dois com contas sincronizadas e tokens de aplicação. A
correlação entre o mundo híbrido é exatamente onde a maioria dos ambientes tem cegueira. O quarto
erro é caçar senhas fracas quando o problema real é senha reutilizada e credencial vazada; a análise
de Exposure de credenciais e a revisão de relações de confiança de aplicação OAuth complementam o
hunt de logon. A integração natural deste controle é com TH.15, que estatiza os mesmos dados, com
PRT.x, que endurece a superfície de autenticação, e com IR.x, quando o padrão confirmado de abuso de
identidade abre caso com prioridade de resposta imediata.