Um alerta de login suspeito é o começo de uma investigação, não uma conclusão. Um acesso fora do horário habitual pode ser legítimo; uma autenticação aparentemente comum pode fazer parte de uma invasão. A triagem precisa reunir contexto suficiente para distinguir os dois cenários.
Este artigo apresenta uma sequência de triagem — dos campos que você precisa até a decisão documentada.
Comece pelo evento original
Registre horário com fuso, conta, origem, destino, resultado da autenticação e método utilizado. Um evento de autenticação útil contém, no mínimo:
| Campo | Por que importa |
|---|---|
| Horário com fuso | Correlação entre sistemas depende disso |
| Identificador da conta | O sujeito da investigação |
| Endereço de origem e ASN | O ASN diz mais que o IP — nuvem, operadora, VPN |
| Agente/dispositivo | Mudança de dispositivo é sinal, não prova |
| Resultado | Sucesso, falha e o motivo da falha |
| Método de autenticação | Senha, MFA, token, chave — e qual fator foi usado |
| Identificador de sessão | Conecta o login ao que veio depois |
| Aplicação ou serviço de destino | Nem todo acesso tem o mesmo peso |
Campos ausentes são uma limitação da análise e devem aparecer na conclusão. Se o sistema não registra o dispositivo, escreva isso — é diferente de “o dispositivo era conhecido”.
O motivo da falha merece destaque. “Senha incorreta” e “senha correta, MFA negado” contam histórias opostas: a segunda indica que a credencial já está comprometida e que o segundo fator está segurando o acesso. Muitas plataformas separam esses códigos, e a distinção costuma passar despercebida.
Evite avaliar um evento isolado. Procure tentativas anteriores e posteriores da mesma conta, origem ou dispositivo. Uma sequência de falhas seguida de sucesso pode indicar tentativa de senha — mas também pode ser um usuário que corrigiu uma credencial antiga.
Distinga os padrões de tentativa
Três padrões parecidos no volume, diferentes na intenção:
| Padrão | Assinatura | O que sugere |
|---|---|---|
| Força bruta | Muitas senhas contra uma conta | Alvo específico |
| Pulverização de senha | Uma senha comum contra muitas contas | Varredura ampla, silenciosa |
| Preenchimento de credenciais | Pares usuário/senha de vazamentos | Reuso de senha entre serviços |
A pulverização é a mais fácil de não ver: cada conta registra uma ou duas falhas, sem disparar bloqueio por tentativas. Ela só aparece ao olhar o conjunto — muitas contas falhando a partir da mesma origem em uma janela curta. Se a sua detecção é por conta, ela é cega para esse caso.
Compare com o comportamento esperado
Pergunte se a conta costuma acessar aquele serviço, se houve mudança recente de dispositivo e se a origem é compatível com o trabalho da pessoa.
Endereço IP e localização aproximada são sinais imperfeitos. VPNs corporativas, redes móveis, serviços de nuvem e viagens alteram a aparência do acesso. Geolocalização por IP erra com frequência, e tratar “país diferente” como comprometimento produz muito falso positivo.
O sinal de “viagem impossível” — dois acessos geograficamente incompatíveis com o tempo decorrido — é mais forte que a localização isolada, mas ainda quebra com VPN: a pessoa desconecta a VPN e aparece em outro país em segundos.
Busque sinais independentes do próprio login:
- criação de sessão nova em serviço não habitual;
- alteração de fatores de autenticação ou de métodos de recuperação;
- criação de regra de encaminhamento de e-mail;
- acesso a volume incomum de dados;
- ações administrativas logo após o login;
- concessão de permissão a uma aplicação.
O segundo item é o mais valioso da lista. Registrar um novo método de MFA é uma das ações mais consistentes de quem acabou de obter acesso — é como o acesso é mantido depois da troca de senha. Um login estranho seguido de novo fator cadastrado é um sinal muito mais forte que qualquer um dos dois sozinho.
Formule hipóteses verificáveis
Escreva hipóteses que possam ser confirmadas ou refutadas, com o teste explícito:
| Hipótese | Confirmaria | Enfraqueceria |
|---|---|---|
| Titular em dispositivo novo | Pessoa confirma; MFA aprovado na 1ª tentativa; segue padrão de uso | Nenhuma atividade posterior compatível com o trabalho |
| Credencial obtida por terceiro | Novo fator MFA; encaminhamento criado; acesso atípico | Atividade idêntica ao histórico da conta |
| Sessão roubada | Sessão ativa sem evento de autenticação correspondente | Login normal registrado antes da sessão |
A terceira merece atenção: quando um atacante importa um cookie de sessão válido, não há evento de login — ele já entra autenticado. Investigação que só olha eventos de autenticação não enxerga esse caso. O sinal está na sessão que existe sem um login que a explique.
Isso impede que a investigação vire apenas uma coleção de indicadores. Se o risco for alto e houver evidência suficiente, siga o procedimento de resposta da organização — preservando os registros relevantes antes de ações que alterem o estado da sessão.
Um cuidado com a confirmação pelo usuário: perguntar “foi você?” é útil, mas a resposta não encerra o caso sozinha. A pessoa pode ter aprovado um MFA sob engenharia social e responder sinceramente que sim.
Nem todo login estranho é ataque
Antes de escalar, vale conhecer as explicações benignas que produzem exatamente os mesmos sinais. Elas são a maioria dos casos:
| Sinal observado | Explicação benigna comum |
|---|---|
| Origem em datacenter ou nuvem | VPN corporativa, iCloud Relay, proxy da empresa |
| Vários países no mesmo dia | VPN ligada e desligada, roaming de operadora |
| Rajada de autenticações idênticas | Cliente de e-mail reconectando após queda |
| Login fora do horário | Fuso de quem viaja, trabalho assíncrono, plantão |
| Dispositivo desconhecido | Atualização de sistema, navegador novo, troca de aparelho |
| Falhas repetidas seguidas de sucesso | Senha antiga salva em um segundo dispositivo |
A penúltima linha causa muito ruído: uma atualização de sistema operacional pode alterar o identificador do dispositivo e fazer um aparelho conhecido parecer novo.
A última merece um teste específico. Se as falhas vêm de um dispositivo que também tem sessões legítimas ativas, a hipótese mais provável é credencial desatualizada em um cliente — não tentativa de invasão. Verificar se as falhas param depois que a pessoa troca a senha costuma encerrar o caso.
Conhecer essas explicações não é motivo para descartar alertas. É o que permite descartar com fundamento, escrevendo qual hipótese benigna foi verificada e como — a diferença entre fechar um caso e ignorá-lo.
Uma sequência simples de triagem
Antes de aprofundar, responda em ordem:
- O evento aconteceu mesmo? Erro de coleta e duplicação existem.
- A identidade e o ativo fazem sentido naquele contexto?
- Há sinais de continuidade ou impacto?
- Qual ação reduz o risco agora?
A sequência separa validação, análise e decisão — assim uma observação incomum não vira automaticamente “comprometimento”. A ordem também evita o erro mais caro da triagem: escalar com base em um evento que a coleta registrou errado.
Termine com uma decisão documentada
Registre linha do tempo, fontes consultadas, grau de confiança e ação tomada. Um registro útil contém fato observado, hipótese, evidência que falta, responsável e horário da próxima revisão. Se houver incerteza, escreva-a.
A qualidade da investigação melhora quando outra pessoa consegue entender por que uma sessão foi mantida, encerrada ou escalada — inclusive você, três meses depois, quando o mesmo padrão reaparecer.
Se faltaram dados, indique quais registros ou correlações melhorariam a próxima investigação. Essa anotação é o que transforma triagem em melhoria de processo: uma lista de campos ausentes, acumulada ao longo de alguns casos, é o argumento mais concreto que existe para melhorar a telemetria.
Próximo passo
Pegue o último alerta de autenticação que você investigou e confira quantos dos campos da primeira tabela o seu ambiente realmente registra. A resposta define o teto da sua capacidade de investigação — e costuma ser mais baixa do que se imagina antes de conferir.
Investigue apenas sistemas sob sua responsabilidade ou com autorização explícita.
