Account takeover e credential stuffing: como detectar e impedir com inteligência de IP (2026)
Como detectar e impedir account takeover e credential stuffing usando inteligência de IP como sinal de risco ponderado, e não como bloqueio direto, seguindo OWASP e NIST.

A sua página de login é a superfície mais atacada que você tem, e a maioria dos ataques não está tentando adivinhar senhas. Eles já as têm. Bilhões de credenciais vazadas em violações anteriores são empacotadas em "combolists" e reaproveitadas contra todos os sites da internet, em busca da pequena fração de usuários que reutilizou uma senha. Quando uma funciona, isso é um account takeover.
Este guia explica como o credential stuffing e o ATO realmente funcionam em 2026, por que a defesa óbvia (bloquear os IPs ruins) falha por si só e como usar a inteligência de IP do jeito certo: como um sinal, normalmente uma pontuação de fraude de IP lida em faixas, e não como veredito, dentro de uma defesa em camadas e baseada em risco. Tudo aqui se apoia em fontes primárias: OWASP, NIST, o Verizon DBIR e medições de ameaças de 2026.

Credential stuffing e account takeover: as definições
Esses termos são usados como sinônimos, mas são distintos:
- Credential stuffing é o método de ataque. A OWASP o classifica como OAT-008: as "tentativas de login em massa usadas para verificar a validade de pares de usuário e senha roubados". O ponto crucial é que ele "não envolve nenhuma força bruta nem adivinhação". As credenciais são conhecidas, coletadas de outras violações, e simplesmente testadas para ver se foram reutilizadas.
- Account takeover (ATO) é o resultado: um atacante assume o controle da conta de um usuário real. O credential stuffing é o caminho mais comum para o ATO, mas phishing, malware e sequestro de sessão também levam até lá.
Vale distinguir os dois de seus primos: password spraying (uma senha comum testada contra muitas contas) e força bruta (muitos palpites de senha contra uma única conta). O credential stuffing é mais perigoso que ambos porque explora uma verdade humana (as pessoas reutilizam senhas) e não senhas fracas.
Como o ataque realmente funciona
A cadeia moderna de credential stuffing é industrializada:
- Obter credenciais. Os atacantes compram ou baixam combolists de dumps de vazamentos e de mercados criminosos, bilhões de pares de cada vez.
- Automatizar em escala. Kits de ferramentas prontos (o antigo Sentry MBA, e hoje o OpenBullet2 e o SilverBullet) reaplicam esses pares contra endpoints de login milhares de vezes por minuto.
- Rotacionar IPs para ficar invisível. Este é o movimento-chave. Como a OWASP documenta, esses kits "oferecem uso integrado de redes de proxy para distribuir as requisições por um grande volume de endereços IP únicos. Isso pode derrotar tanto as listas de bloqueio de IP quanto a limitação de taxa, pois o volume de requisições por IP pode permanecer relativamente baixo, mesmo em ataques de alto volume."
- Monetizar os acertos. Um login bem-sucedido vira roubo de fundos, abuso de pagamentos armazenados, drenagem de pontos de fidelidade ou simplesmente uma conta verificada revendida ao próximo criminoso.
As taxas de sucesso por tentativa são minúsculas (uma fração de um por cento), mas com milhões de tentativas essa fração significa milhares de contas comprometidas.
A escala em 2026
Os números de medições confiáveis são preocupantes:
| Métrica | Valor | Fonte |
|---|---|---|
| Violações que começam com credenciais comprometidas | 22% (principal vetor de acesso inicial) | Verizon DBIR 2025 |
| Credential stuffing como parcela dos logins diários | Mediana de 19% (até 44% em dias de pico) | Verizon DBIR 2025 |
| Tentativas de comprometimento de conta pós-login por organização (2025) | Mais de 400.000, mais de 4x o de 2024 | HUMAN Security, 2026 |
| Parcela automatizada (bots) de todo o tráfego da web | Mais de 53% em 2025 | Imperva / Thales |
| Incidentes de account takeover que atingem serviços financeiros | 46% de todos os incidentes de ATO | Imperva / Thales |
(Os últimos números são estimativas de telemetria de rede de fornecedores: evidência direcional forte, atribuída como tal, e não um censo de toda a internet.) A HUMAN também constatou que a parcela do tráfego de login que tenta um ATO teve o maior salto em anos, passando de 13% na região EMEA, contra menos de 3,5% globalmente. A página de login é, de forma mensurável, um campo de batalha.
Por que é tão difícil impedir em 2026: proxies residenciais
O motivo pelo qual as defesas de ontem falham é a rede de proxies residenciais. Em vez de atacar a partir de IPs óbvios de datacenter, os atacantes fazem o tráfego de credential stuffing passar por milhões de dispositivos reais de consumidores (roteadores domésticos, celulares, smart TVs), de modo que cada requisição chega de um endereço de ISP com aparência legítima.
Isso não é teoria. Em janeiro de 2026, o Threat Intelligence Group do Google, com a Cloudflare e outros, desarticulou a rede IPIDEA, "uma das maiores redes de proxies residenciais do mundo", reduzindo em milhões o conjunto de dispositivos dos operadores. Nas palavras do GTIG, "ao rotear o tráfego por uma série de dispositivos de consumidores no mundo todo, os atacantes conseguem mascarar sua atividade maliciosa sequestrando esses endereços IP", gerando "desafios significativos para os defensores de rede". O FBI dos EUA emitiu um alerta de utilidade pública sobre como evitar redes de proxies residenciais em março de 2026.
A consequência prática: uma lista de bloqueio de IPs é estruturalmente lenta demais e grosseira demais. O volume por IP do atacante é baixo, os IPs são casas reais e eles mudam o tempo todo. Não dá para sair dessa só bloqueando.
Onde a inteligência de IP ajuda
Isso não torna os dados de IP inúteis. Torna-os um sinal, não um veredito. E é um sinal com o selo de aprovação dos padrões. O NIST SP 800-63B-4 (finalizado em julho de 2025) endossa explicitamente a autenticação baseada em risco usando "o endereço IP do requerente, a geolocalização, os padrões de tempo das requisições ou os metadados do navegador", e observa que "a autenticação a partir de uma geolocalização ou de um bloco de endereços IP inesperado (por exemplo, um serviço de nuvem) pode motivar o uso de controles adicionais baseados em risco".
Os sinais de IP de alto valor em um endpoint de login ou de redefinição de senha:
- Tipo de conexão. Um login vindo de uma faixa de datacenter ou de nuvem é muito mais suspeito do que um vindo de um ISP residencial. A maioria dos usuários reais não faz login a partir da AWS.
- Detecção de VPN e proxy. Tráfego anonimizado no endpoint de login eleva bastante o risco. Proxies residenciais são a ferramenta preferida de quem faz credential stuffing e se parecem com tráfego comum de ISP, e é por isso que as camadas de dispositivo e de comportamento abaixo são importantes.
- Reputação do ASN. Concentrações de abuso se associam a redes específicas; o sistema autônomo por trás de um IP é um sinal duradouro.
- Geolocalização para viagem impossível. Um login de um país minutos depois de outro, vindo de outro país, indica um provável comprometimento.
- Uma pontuação de risco composta. Ela combina os itens acima em um único número que você pode usar como limite, em vez de analisar cada indicador manualmente.
A armadilha dos falsos positivos (a parte que a maioria dos guias pula)
Aqui está a ressalva honesta, e é por isso que a inteligência de IP deve embasar uma decisão de risco em vez de um bloqueio rígido: defesas baseadas apenas em IP punem sistematicamente clientes reais.
Um único endereço de CGNAT (NAT de nível de operadora) pode atender centenas ou milhares de usuários reais, e o mesmo vale para um gateway móvel ou um relay de privacidade. A telemetria de 2025 da Cloudflare é impressionante: IPs de CGNAT têm uma taxa de bots praticamente idêntica à de IPs sem CGNAT (mediana de 4,8% contra 4,7%) e uma média menor (7% contra 13,1%), e mesmo assim sofrem limitação de taxa três vezes mais. Em outras palavras, controles grosseiros de IP bloqueiam uma multidão de usuários legítimos para impedir um atacante escondido entre eles. O mesmo bloqueio excessivo atinge redes móveis e o Apple iCloud Private Relay, exatamente o tráfego legítimo que abordamos em detectar tráfego anonimizado sem bloquear clientes reais.
Então a regra é: um sinal de IP arriscado deve aumentar a fricção (um desafio adicional), não fechar a porta. Tipos de conexão benignos, mas compartilhados, devem ser isentos, não penalizados.
O guia em camadas (alinhado a OWASP e NIST)
Nenhum controle isolado impede o credential stuffing. As defesas que funcionam, tiradas diretamente dos padrões:
- Bloqueie senhas vazadas. O NIST SP 800-63B-4 exige que os verificadores comparem novas senhas com uma lista de bloqueio de credenciais sabidamente comprometidas. Se a senha reutilizada não puder ser definida, testá-la depois vai falhar.
- Limite tentativas que falharam. O NIST exige limitar tentativas consecutivas que falharam (no máximo 100 por conta) com atrasos progressivos, desacelerando a automação sem bloquear usuários reais.
- Adicione MFA adicional baseado em risco. Acione um fator extra apenas quando os sinais de risco (IP, dispositivo, geolocalização, velocidade) indicarem: proteção forte com fricção mínima para logins normais.
- Faça fingerprinting de dispositivos e observe o comportamento. Bots reutilizam ambientes e agem em velocidades não humanas; sinais de dispositivo e de comportamento capturam o que a camada de IP deixa passar sobre bots.
- Incorpore a inteligência de IP à pontuação. Tipo de conexão, indicadores de anonimizador e reputação do ASN como entradas da decisão de risco, nunca como único filtro, com limites separados para login, cadastro e checkout.
- Proteja todo endpoint relevante. Login, redefinição de senha e checkout precisam do mesmo escrutínio; os atacantes migram para o que estiver mais fraco.
O que uma consulta de IP no momento do login retorna
O GeoIPHub fornece a camada de inteligência de IP dessa pilha, projetada para ser ponderada, não grosseira. Uma única consulta no seu endpoint de login ou de redefinição de senha retorna o tipo de conexão, os indicadores de anonimizador, o ASN e uma pontuação de risco explicável com uma ação recomendada, para que você possa desafiar o que é realmente arriscado e deixar os clientes reais passarem. Aqui está uma consulta real de 102.129.235.17, o endereço de um servidor VPN, reduzida aos campos que uma verificação de login lê:
{
"ip": "102.129.235.17",
"geo": { "country_code": "US", "city": "Washington D.C." },
"asn": { "asn": 174, "isp": "COGENT-174 - Cogent Communications, LLC",
"connection_type": "datacenter" },
"detection": { "is_vpn": true, "is_proxy": false, "is_tor": false },
"scoring": { "fraud_score": 92, "confidence": 0.76, "recommended_action": "block",
"detection_methods": ["known_vpn_server", "openvpn_open", "ipsec_open"] }
}
Um login vindo de um servidor VPN em datacenter que responde a handshakes de OpenVPN e IPsec, como este, cai na faixa de bloqueio (acima de 75). Pontuações na faixa intermediária recebem um desafio adicional, e uma conexão residencial limpa com uma localização normal passa sem problemas. Isso é autenticação baseada em risco, do jeito que o NIST descreve. Você pode testar qualquer endereço no verificador gratuito de pontuação de fraude de IP e no teste de detecção de VPN e proxy, integrá-lo com a API ou ler como a pontuação é construída na nossa metodologia.
Pegue o atacante na multidão, não a multidão
O credential stuffing transformou o account takeover em um negócio industrial e automatizado, e os proxies residenciais tornaram o velho reflexo (bloquear os IPs ruins) ineficaz e prejudicial para usuários reais. A defesa que realmente se sustenta em 2026 é em camadas e baseada em risco: barre senhas vazadas na origem, limite e desafie de forma inteligente e trate a inteligência de IP como um sinal de alto valor que alimenta uma decisão adaptativa. Pegue o atacante escondido na multidão; não puna a multidão.
Perguntas frequentes
Qual é a diferença entre credential stuffing e account takeover?
Credential stuffing é o método de ataque: bots testando em massa pares de usuário e senha roubados em vazamentos anteriores para encontrar aqueles que um usuário reutilizou no seu site (a OWASP o classifica como OAT-008). Account takeover (ATO, tomada de conta) é o resultado, quando um par válido funciona e um atacante assume o controle da conta. Credential stuffing é o caminho mais comum para o ATO, mas o ATO também pode vir de phishing, malware ou sequestro de sessão.
Posso simplesmente bloquear os endereços IP por trás do credential stuffing?
Não. A OWASP alerta explicitamente que o bloqueio de IP 'não deve ser usado como a única defesa nem como a principal'. Os kits de ferramentas modernos fazem cada requisição passar por um IP de proxy residencial diferente, então o volume por IP fica baixo o bastante para escapar de listas de bloqueio e de limites de taxa. Pior: bloqueios diretos de IP atingem endereços compartilhados de CGNAT e de redes móveis que atendem milhares de usuários reais. A inteligência de IP pertence a uma pontuação de risco, não a um bloqueio rígido.
Qual é o tamanho do problema de account takeover em 2026?
Grande e crescente. Credenciais comprometidas foram o vetor de acesso inicial em 22% das violações no Verizon DBIR de 2025, e o credential stuffing representou uma mediana de 19% das tentativas diárias de autenticação. A HUMAN Security registrou mais de 400.000 tentativas de comprometimento de conta pós-login por organização em 2025 (mais que o quádruplo de 2024), e o tráfego automatizado passou de 53% de todo o tráfego da web (Imperva/Thales).
Como a inteligência de IP ajuda a detectar account takeover?
Ela fornece sinais de risco que o NIST endossa para autenticação adaptativa: o tipo de conexão (datacenter/nuvem ou residencial), a detecção de VPN/proxy, a reputação do ASN e a geolocalização para verificações de viagem impossível. Uma tentativa de login vinda de um datacenter em nuvem, de um anonimizador conhecido ou de um local implausível tem risco maior: é motivo para exigir uma etapa adicional de MFA, não necessariamente para bloquear.
Como impedir o credential stuffing sem bloquear clientes reais?
Use uma abordagem em camadas e baseada em risco: bloqueie senhas sabidamente vazadas (obrigatório pelo NIST), limite tentativas que falharam, adicione MFA adicional em logins arriscados, faça fingerprinting de dispositivos e incorpore os sinais de IP a uma pontuação de risco em vez de bloquear de forma rígida. Reserve bloqueios diretos para casos de alta confiança e isente IPs compartilhados, móveis e de relays de privacidade para que usuários legítimos passem.
A equipe por trás da API do GeoIPHub
Escrito pela equipe do GeoIPHub, as pessoas que constroem a API de inteligência de IP do GeoIPHub e seu scanner. Os rascunhos são preparados com auxílio de IA e editados pela equipe; os exemplos de API são consultas reais à API em produção, salvo quando indicados como ilustrativos.


