A força bruta clássica faz muitas tentativas de senha em pouco tempo a partir de um único IP. O credential stuffing tenta a mesma lista de senhas distribuída por muitos IPs. Ataques low-and-slow fazem um pequeno número de tentativas ao longo de horas. As tentativas de sequestro de sessão se revelam após um login bem-sucedido por meio de mudanças no IP, user agent ou comportamento. Capturar tudo isso com a mesma regra de rate limit não é realista.
Usar apenas bloqueio baseado em IP permite que o credential stuffing distribuído passe e afeta injustamente usuários legítimos em redes compartilhadas. Usar apenas bloqueio baseado em usuário permite que atacantes intencionalmente acionem o bloqueio de conta como negação de serviço. Usar apenas CAPTCHA transforma cada tentativa de login em fricção desnecessária e degrada a experiência do usuário.
Muitas soluções olham apenas para o momento do login. No entanto, o risco de account takeover continua após o login: se ações sensíveis como mudança de senha, mudança de e-mail, adição de método de pagamento, geração de token de API ou transferência de fundos chegam em um novo contexto, isso é um sinal de abuso pós-login. Esse comportamento deve ser avaliado junto com a vinculação de sessão e o MFA step-up.
A abordagem correta é usar a combinação de escopo e sinal adequada para cada classe de ataque. Os escopos IP, nome de usuário, username_ip e composto devem trabalhar juntos com pontuação de bot, velocidade de falha de autenticação, reputação de IP e divergência de vinculação de sessão.
TR7 Account Takeover Protection entrega esse modelo: combina sinais de tráfego WAAP com políticas de acesso AAM e gerencia o risco ATO por meio de um gráfico de política multicamada em vez de uma única regra.
TR7 aplica defesa ATO por meio de pontuação multi-sinal, seleção de escopo específica por classe de ataque, escalada graduada e coordenação com AAM.
Pontuação de bot, velocidade de falha de autenticação, reputação de IP e divergência de vinculação de sessão são todos avaliados no mesmo caminho de decisão. As decisões são tomadas com base na forma comportamental real do ataque — não apenas no IP ou apenas no nome de usuário.
O escopo de IP rastreia tentativas de força bruta de fonte única, o escopo de nome de usuário rastreia credential stuffing distribuído, o escopo username_ip rastreia ataques direcionados, e o escopo composto rastreia combinações de IP, user agent e headers. Cada escopo opera com seus próprios contadores e comportamento de limiar.
No primeiro estágio o evento é registrado na trilha de auditoria, depois o CAPTCHA auto-hospedado é ativado e, finalmente, o bloqueio é aplicado. Esse modelo desacelera o atacante enquanto minimiza a fricção desnecessária para usuários legítimos.
Os sinais de tráfego WAAP podem trabalhar junto com as políticas de bloqueio e MFA step-up do AAM. Verificação adicional pode ser acionada para usuários que se aproximam do limiar de CAPTCHA ou exibem uma mudança de contexto de sessão.
Account Takeover Protection reúne o risco de tráfego pré-login, falhas de login e comportamento de sessão pós-login na mesma cadeia de proteção.
TR7 torna a defesa ATO graduada pelo fluxo aviso → CAPTCHA → bloqueio. O estágio de aviso produz trilha de auditoria sem apresentar fricção ao usuário. O estágio CAPTCHA desafia a automação e oferece aos usuários legítimos uma etapa de verificação controlada. O estágio de bloqueio interrompe temporariamente a capacidade de tentativa para o escopo específico.
Ataques ATO não podem ser capturados por um único escopo. TR7 pode rodar políticas de escopo baseado em IP, baseado em nome de usuário, baseado em IP+nome de usuário e escopo composto simultaneamente no mesmo endpoint. Força bruta de IP único, credential stuffing de múltiplos IPs e ataques de conta direcionados são rastreados separadamente. Mesmo se um atacante ficar abaixo de um escopo, o outro escopo ainda pode detectar o comportamento.
O gatilho failedAuthAttempts conta falhas em uma janela de tempo definida. Esse contador pode ser rastreado por usuário, por IP ou por escopo composto. Janelas curtas expõem tentativas rápidas de força bruta; janelas longas revelam comportamento ATO low-and-slow. Tanto o total de contagem quanto a densidade de tentativas ao longo do tempo alimentam a decisão.
TR7 pode considerar análise de user agent, reputação de IP, análise de comportamento, path suspeito, impressão digital de header, anomalias de protocolo, inconsistência de sinal, nó de saída Tor, impressão digital TLS e IP de datacenter ao calcular a pontuação de bot. Quando a pontuação atinge um nível definido, uma ação CAPTCHA ou de bloqueio pode ser acionada. As tentativas de login são avaliadas não apenas como erros de senha, mas também como comportamento de automação, trazendo a qualidade do tráfego para a defesa ATO.
Subcategorias de reputação de IP como proxy aberto, bot malicioso, ataque, reconhecimento, spam e IP de VPN podem ser usadas como sinais de risco nas decisões ATO. Essas categorias não precisam produzir bloqueio obrigatório por si só; elas são avaliadas junto com pontuação de bot e políticas de bloqueio. Tentativas de login de infraestrutura sabidamente maliciosa podem ser submetidas a fricção mais cedo. Essa abordagem funciona em combinação com outros sinais para reduzir o risco de falso positivo.
Hammering de path, requisições rápidas, alta taxa de 404, requisições de mutation sem referer e uso inesperado de método HTTP podem ser sinais de risco na superfície de login. Esses indicadores ajudam a distinguir credential stuffing, enumeração de conta e comportamento de varredura automatizada. Os sinais não são avaliados isoladamente — eles funcionam junto com pontuação de bot e contadores de falha de autenticação. O ataque torna-se visível não apenas por erros de senha, mas também pelo comportamento do tráfego.
Quando o limiar de CAPTCHA é ultrapassado, o TR7 pode ativar seu próprio fluxo de desafio. Um desafio controlado é apresentado ao usuário sem enviar dados para um serviço de verificação externo. Respostas incorretas de CAPTCHA podem ser adicionadas ao contador de tentativas e acelerar a escalada. Isso fornece um modelo mais controlado para organizações com sensibilidade a residência de dados e requisitos regulatórios.
TR7 pode coordenar os sinais de bot e bloqueio do WAAP com as políticas de acesso do AAM. O MFA step-up pode ser acionado para usuários que se aproximam do limiar de CAPTCHA, gerando uma anomalia de vinculação de sessão ou realizando uma ação sensível. Essa abordagem leva o risco do momento de login para as operações pós-login também. Mesmo se o atacante souber a senha correta, ainda enfrenta a barreira de verificação adicional.
Uma sessão pode ser associada a IP, IP+user agent ou um contexto composto. Se o IP, user agent ou contexto muda inesperadamente após o login, uma anomalia de vinculação de sessão pode ser gerada. Esse sinal é particularmente importante em cenários de sequestro de sessão e reutilização de token. Re-autenticação ou controles adicionais podem ser acionados em endpoints sensíveis.
O attemptWindowDuration define por quanto tempo as falhas de tentativa continuam sendo contadas. Se um usuário cometer alguns erros de senha hoje, poderá retornar a um comportamento limpo assim que a janela expirar. Um atacante que acumula tentativas suficientes dentro da mesma janela encontra CAPTCHA ou bloqueio. Esse modelo estabelece um equilíbrio mais saudável entre segurança e experiência do usuário.
Para cada tentativa de login, timestamp, IP de origem, user agent, escopo, ID de política e resultado podem ser registrados. Resultados como aviso, CAPTCHA, bloqueio ou passagem bem-sucedida são distinguidos durante a revisão de incidentes. Detalhes do destinatário como e-mail ou número de telefone são mascarados para que o log de auditoria não se torne um canal secundário de vazamento de dados. As equipes SOC rastreiam fluxos de ataque usando registros estruturados.
Se uma ação de quarentena for definida após o término do período de bloqueio, o cliente ou escopo pode ser colocado sob escrutínio adicional. Isso dificulta que atacantes repitam as mesmas tentativas cada vez que a duração do bloqueio terminar. A quarentena fornece rastreamento contínuo de risco além do comportamento de bloqueio clássico e é uma camada extra útil em campanhas ATO de longa duração.
A proteção ATO é operada junto com presets de política prontos, contadores nativos, curva de pontuação de bot, isolamento de pool, escopo composto e compartilhamento de contador com AAM.
TR7 pode fornecer exemplos de política de bloqueio prontos para os escopos de nome de usuário, IP e username_ip. O escopo de nome de usuário foca em credential stuffing com uma janela mais longa; o escopo de IP foca em comportamento de força bruta com uma janela mais curta. Todos os limiares, durações e ações podem ser ajustados às necessidades do serviço.
As tentativas de login falhadas são rastreadas usando estruturas de contador rápido. Essa abordagem reduz a dependência de chamadas a banco de dados externo e fornece baixa latência no caminho de login. Replicar contadores para nós pares em um ambiente de cluster é importante para a continuidade da proteção após failover.
A pontuação de bot pode ser interpretada como sensível em níveis baixos de sinal e saturando conforme o risco se acumula em níveis altos. Essa abordagem permite que muitos sinais pequenos se somem em risco significativo. Quando um novo sinal é adicionado, a necessidade de redesenhar do zero o limiar de toda a política é reduzida.
Cada pool pode ser vinculado ao seu próprio perfil de proteção de tráfego. Um sinal ATO em um tenant ou serviço não afeta os contadores de outro tenant. Esse isolamento é crítico em cenários SaaS multi-tenant e MSP.
O escopo composto pode combinar IP, user agent, accept-language ou componentes de header similares em uma única chave de rastreamento. Esse modelo fornece rastreamento mais contextual quando apenas IP ou apenas nome de usuário não é suficiente. Oferece visibilidade adicional contra user agents rotativos ou comportamento variável de cliente.
Os contadores de falha de autenticação do WAAP podem ser coordenados com as políticas de bloqueio do AAM. Mesmo que um atacante vise diferentes endpoints de login diretamente, o mesmo comportamento de risco pode ser avaliado no contador e no caminho de política compartilhados. Isso torna a proteção ATO consistente não apenas na camada de tráfego, mas em todo o fluxo de identidade.
As equipes bancárias podem monitorar endpoints de login com escopo de IP e comportamento de conexão SSL juntos. Quando limiares definidos são ultrapassados, CAPTCHA, bloqueio ou MFA step-up do AAM é ativado.
Bots fazendo um pequeno número de tentativas de muitos IPs podem não aparecer sob o escopo de IP. O escopo de nome de usuário captura falhas acumulando na mesma conta e aplica CAPTCHA ou bloqueio no nível da conta.
Tentativas de baixo volume mas focadas contra uma conta de CFO ou administrador podem ser rastreadas com escopo username_ip ou composto. Quando o risco aumenta, o MFA step-up é acionado pelo AAM.
Se o IP ou user agent muda inesperadamente imediatamente após um usuário fazer login, uma anomalia de vinculação de sessão pode ser gerada. Re-autenticação pode ser necessária para ações como transferências de fundos, mudanças de e-mail ou geração de token.
Defesa ATO integrada contra credential stuffing, força bruta, low-and-slow e sequestro de sessão. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.