Encontre a Invasão: Como Ler um Padrão de Brute-Force em Logs de Autenticação
O desafio
Estes são seus logs de autenticação web. Um IP martelou o login com falhas e de repente recebeu um 200 - a invasão. Filtre o ruído (tente status:401), confirme que é uma única origem, e envie o endereço IP do atacante.
O que você vai aprender
- Filtrar um fluxo de logs ruidoso por campo para isolar eventos relevantes
- Reconhecer a assinatura de falhas seguidas de sucesso de um brute force bem-sucedido
- Atribuir uma invasão a um único IP de origem
- Avançar do sucesso de login para a próxima ação do atacante
Habilidades testadas
Pré-requisitos
- Entendimento de códigos de status HTTP (200 vs 401)
- Familiaridade com fluxos de login
Como funciona
A maior parte do trabalho de segurança começa nos logs, e a habilidade central é separar sinal de ruído. Um servidor web em produção gera um fluxo constante de tráfego comum - requisições GET para páginas e recursos, retornando na maioria das vezes 200 ou 304, vindas de muitos endereços diferentes. Um ataque se esconde dentro desse ruído, então você filtra o fluxo até chegar aos eventos que importam.
Um brute force de credenciais ou password-spray tem um formato inconfundível: muitas tentativas de autenticação falhas (401) contra o endpoint de login, vindas de uma única origem, seguidas de um sucesso (200). Filtrar por status:401 reduz o ruído e faz essa sequência aparecer na hora - e aqui toda falha carrega o mesmo IP, o que é a atribuição. O momento decisivo é a transição: esse mesmo IP finalmente recebe um 200 em /login, e imediatamente solicita uma página autenticada (/admin/users). Essa é a invasão e a primeira ação pós-comprometimento.
A tabela do SIEM aceita busca livre por texto e filtros field:value, além de chips rápidos. Você não lê cada linha, você consulta pelo padrão, confirma a origem única, e a segue através da fronteira do sucesso.
Erros comuns
- Ler linha por linha em vez de filtrar. Rolar o log inteiro desperdiça tempo; consulte
status:401e deixe o padrão aparecer. - Parar nas falhas. As falhas mostram a tentativa; o
200vindo do mesmo IP mostra a invasão de fato. - Culpar um IP benigno. O ruído são GETs de muitos endereços; o atacante é quem repete POSTs para /login.
- Enviar um path ou status em vez do IP. A pergunta pede quem, o endereço de origem.
Como se proteger
Do ponto de vista defensivo, esse padrão é exatamente o que rate limiting, bloqueio de conta e alertas de anomalia existem para impedir. O mesmo filtro usado para encontrar isso depois do fato pode virar uma detecção automatizada.
- Aplique rate limit e bloqueie progressivamente logins falhos repetidos por origem e por conta.
- Gere alerta para uma rajada de 401s seguida de um 200 do mesmo IP, a assinatura de sucesso de um brute force.
- Exija MFA para que uma única senha adivinhada não seja suficiente para invadir.