Contando Contas Comprometidas Distintas em Logs de Autenticação
O desafio
Durante a noite, um endereço externo executou um ataque de preenchimento de credenciais contra o endpoint de login e, ao contrário do scanner barulhento do início da noite, este conseguiu entrar. Seu relatório de incidente não precisa do endereço do atacante, precisa do raio de impacto. Descubra qual endereço externo realmente teve sucesso e conte quantas contas DISTINTAS ele conseguiu acessar. Leia com atenção: uma conta foi acessada duas vezes a partir desse endereço, então o número de logins bem-sucedidos não é o número de contas, e outra conta parou no pedido de segundo fator e nunca chegou a ser acessada. Envie o número de contas distintas.
O que você vai aprender
- Diferenciar um spray malsucedido de um ataque de credential stuffing bem-sucedido
- Filtrar uma tabela de SIEM combinando termos no formato field:value
- Contar entidades distintas em vez de linhas de eventos brutas
- Reconhecer que um login bloqueado pelo MFA não é um comprometimento
- Relatar o raio de impacto como o número que orienta a resposta a incidentes
Habilidades testadas
Pré-requisitos
- Leitura de linhas de log estruturadas
- Compreensão de MFA e credential stuffing
Como funciona
Encontrar o atacante é a metade fácil de uma intrusão. A metade que direciona a resposta é o escopo: quantas contas realmente caíram. Toda decisão subsequente, desde a redefinição forçada de senhas até a notificação de vazamento, é dimensionada por esse número, e é uma contagem de contas, não de eventos.
Dois endereços externos aparecem durante a noite. 203.0.113.91 dispara nomes de usuário genéricos como admin, root e jenkins, e falha em todos eles. É barulhento e inofensivo. 198.51.100.24 percorre nomes reais de funcionários, falhando dezenove vezes e acertando cinco, com os acertos misturados entre os erros. Barulhento não é o mesmo que perigoso, e o endereço mais barulhento é o que não conseguiu nada.
Filtrando por src_ip:198.51.100.24 action:login result:success obtemos cinco linhas, mas apenas quatro nomes distintos, porque j.arnold fez login duas vezes. Uma conta separada, p.novak, aparece duas vezes com result:mfa_required: a senha estava correta, então ela estava na mesma lista vazada, mas o segundo fator bloqueou o login. Essa conta foi atacada, não comprometida. O raio de impacto correto é quatro, e os eventos de exportação que se seguem confirmam isso, já que só vêm de contas que realmente entraram.
Erros comuns
- Responder 5. Esse é o número de eventos de login bem-sucedidos.
j.arnoldaparece duas vezes, então a contagem de contas distintas é um a menos. - Responder 6. Isso conta
p.novak, cujo resultado émfa_required. O segundo fator bloqueou o login, então a conta nunca foi acessada. - Investigar 203.0.113.91. Ele gera o maior número de eventos, mas nunca tem sucesso uma vez sequer. Volume não é impacto.
- Contar sucessos internos. As linhas
10.12.4.xsão logins normais da equipe pela VPN do escritório, antes e depois da janela do incidente. - Filtrar apenas por result:success. Isso mistura logins legítimos do escritório com os do atacante; o endereço de origem precisa fazer parte do filtro.
Como se proteger
Credential stuffing funciona com senhas reutilizadas, então os controles que importam são os que tornam uma senha correta insuficiente.
- Exija um segundo fator para todas as contas e prefira fatores resistentes a phishing. Neste incidente, o MFA é o único motivo pelo qual a contagem é quatro em vez de cinco.
- Verifique senhas novas e existentes contra bases conhecidas de vazamentos e force a redefinição em caso de correspondência.
- Limite a taxa e atrase progressivamente a autenticação por endereço de origem e por conta, para que dezenove falhas de um mesmo endereço nunca cheguem a uma vigésima tentativa.
- Alerte sobre o formato do ataque: muitos nomes de usuário distintos vindos de um mesmo endereço em uma janela curta, especialmente fora do horário comercial.
- Instrumente o que acontece depois de um login, já que a exportação de
payroll_q3.xlsxminutos após um login às 02:31 é um sinal mais forte do que o próprio login. - Construa consultas de delimitação de escopo com antecedência que contem principais distintos, para que os respondentes não precisem calcular o raio de impacto manualmente sob pressão.