Num caso atendido pelo nosso time, a conta de um único usuário registrou nove logins bem-sucedidos em quatro minutos. Os acessos vinham de mais de trinta cidades dos Estados Unidos ao mesmo tempo, com saltos fisicamente impossíveis: Orlando para San Gabriel, 2.200 km em três minutos; Seattle para Los Angeles, 1.300 km em um minuto. Entre 05:15 e 05:19 UTC houve 59 autenticações no serviço de identidade.
Nenhum login falhou. As credenciais estavam corretas e em uso ativo, vindas de IPs residenciais sem histórico de abuso — proxies contratados justamente para não parecer ataque.
O ponto que interessa nesse caso não é a técnica, que é conhecida: credential stuffing com botnet distribuída. É o relógio. Entre a primeira autenticação anômala e a contenção existe um intervalo, e é o tamanho desse intervalo que decide se o incidente foi um susto ou um vazamento.
Por que o intervalo existe
O intervalo tem três pedaços, e cada um falha por um motivo diferente.
O primeiro é o tempo até detectar. Nenhum dos 59 eventos, isolado, era suspeito: login bem-sucedido com senha certa é o evento mais comum de qualquer ambiente. O que denuncia é a correlação — mesma identidade, origens geográficas incompatíveis, janela de minutos. Sem regra que ligue esses três atributos, o alerta simplesmente não nasce, e o ambiente segue com o painel verde.
O segundo é o tempo até decidir. O alerta chega e alguém precisa dizer o que fazer: derrubar as sessões daquele usuário, resetar a credencial, bloquear a conta. Se essa autoridade não estiver escrita antes, o alerta viaja pelo grupo de mensagens até encontrar alguém disposto a assumir a consequência de interromper o trabalho de um usuário legítimo — que pode ser um diretor em viagem.
O terceiro é o tempo até executar. Revogar sessão ativa, forçar reautenticação, isolar host: parece trivial e não é, quando depende de acesso administrativo que só duas pessoas têm e nenhuma está de turno.
Somados, os três explicam por que ambientes com boa ferramenta ainda perdem dados. O que falha raramente é o sensor.
Detecção é regra escrita, não painel comprado
Uma plataforma entrega telemetria e um conjunto de regras genéricas. O que pega o caso acima é uma regra que conhece o seu ambiente: quais países fazem sentido para a sua operação, qual velocidade de deslocamento é impossível, quantas autenticações por minuto são normais para um usuário humano.
Vale o mesmo para o resto da cadeia de identidade. Consentimento OAuth concedido fora do fluxo de aprovação, regra de encaminhamento criada no e-mail depois de um login novo, consulta em massa ao diretório: todos são eventos legítimos em separado e sinais claros em conjunto. Detecção é o trabalho de escrever essas combinações, testá-las contra tráfego real e mantê-las quando o ambiente muda.
No caso da Vólus, empresa de meios de pagamento com mais de 25 anos de operação, foi esse tipo de regra que pegou um comportamento anormal — excesso de requisições concentradas em um único usuário — e permitiu bloquear os acessos antes da evolução do incidente. A empresa cita como principal ganho a visibilidade centralizada: com os logs concentrados no SIEM, o tempo de investigação caiu.
Decisão precisa de alçada, não de reunião
O segundo pedaço do intervalo é organizacional e se resolve com três linhas escritas antes do primeiro alerta.
O que pode ser executado sem consulta, e em que janela: derrubar sessão, bloquear conta comprometida, isolar host com processo malicioso ativo. O que exige aprovação, de quem, com prazo definido para resposta. E o que acontece quando ninguém responde — porque a madrugada de sábado existe e o incidente não espera pelo expediente.
Sem essas linhas, o time técnico faz a única coisa razoável: espera. E a espera é a parte mais cara do incidente.
Automação com limite claro
Parte do intervalo se elimina automatizando, desde que o gatilho seja preciso. Em outro caso do nosso time, um servidor de contabilidade recebeu tentativa de conexão SMB na porta 445 vinda de um IP classificado como indicador de comprometimento ativo, com 100% de confiança na base de inteligência. O bloqueio foi aplicado automaticamente, sem intervenção humana, e a tentativa de autenticação falhou porque a conta-alvo estava desativada.
Esse é o caso em que automação funciona: indicador com alta confiança, ação reversível, escopo estreito. O oposto — automação disparada por regra genérica, com ação de impacto amplo — produz indisponibilidade autoinfligida e, em pouco tempo, alguém desliga a automação. A régua é simples: quanto maior o impacto da ação, mais alta precisa ser a confiança do gatilho.
Turno é pré-requisito do intervalo curto
Há um limite físico para reduzir o intervalo sem cobertura contínua. O caso das 59 autenticações aconteceu entre 05:15 e 05:19 UTC — de madrugada, no fuso de quem opera no Brasil. Nenhuma regra de detecção resolve o que não tem alguém para ler.
Cobrir 24 horas por dia, sete dias por semana, com atenção comparável em todo o período, exige de cinco a seis pessoas em escala. É por isso que a conta raramente fecha internamente: o time de infraestrutura cobre o expediente com atenção plena e o resto com boa vontade, o que funciona até a madrugada em que a análise precisa ser feita agora, com contexto, por alguém que não acabou de acordar.
A diferença entre conter às duas da manhã e conter às oito não é de eficiência. Em seis horas, credencial comprometida vira acesso persistente, e contenção vira recuperação.
O que não encurta o intervalo
Vale registrar o que costuma ser comprado com essa expectativa e não entrega.
Mais sensor no mesmo ponto da cadeia. Dobrar a coleta sem escrever regra nova aumenta volume de evento e tempo de triagem.
Painel executivo. Ele melhora a conversa com a diretoria e não muda um minuto do intervalo.
Alerta por e-mail para lista grande. Aviso enviado para muita gente é aviso sem dono; o efeito prático é que ninguém age primeiro.
O que medir depois
Quatro números descrevem o intervalo e são os que valem numa reunião de diretoria.
Tempo até a detecção, contado do primeiro sinal disponível no log até o alerta existir. Tempo até a contenção, do alerta à ação efetiva. Percentual de alertas que geraram ação — se for muito baixo, a calibração está errada e o time está sendo treinado a ignorar aviso. E cobertura real: quantos ativos críticos têm log chegando, verificado por amostragem em vez de relatório de ferramenta.
Nenhum dos quatro exige ferramenta nova para começar a ser medido. Exige registrar horário.
O que muda para quem opera
A consequência prática é que o investimento em segurança muda de lugar. Comprar mais sensor reduz o primeiro pedaço do intervalo até um limite, e depois não reduz mais nada. Os outros dois pedaços — decisão e execução — são processo, turno e alçada, e não estão em nenhuma licença.
A segunda consequência é sobre a conversa interna. Quando os quatro números acima existem, a discussão sai do terreno da opinião. Deixa de ser “estamos seguros?” e passa a ser “nosso intervalo entre alerta e contenção caiu de seis horas para vinte minutos, e o próximo gargalo é a alçada de madrugada”.
O próximo passo
Pegue o último incidente do seu ambiente e escreva quatro horários: quando o primeiro sinal apareceu no log, quando alguém olhou, quando a decisão foi tomada e quando a ação foi executada. A maior distância entre dois desses horários é o seu gargalo, e ele quase nunca está onde o time imagina.
Esse é o assunto do webinar que fazemos junto com o time da CrowdStrike em 26 de agosto. Inscrições em https://lp.infomach.com.br/pt/webinar_crowdstrike_agosto2026.
