Account takeover em 2026 é um problema de automatização antes de ser um problema de credenciais. Os atacantes agora executam agentes IA dentro de navegadores reais que resolvem desafios, rotam fingerprints de stealth-browser e mudam de tática consoante as defesas reagem. Uma única regra no endpoint de login não consegue acompanhar isso. Este playbook dá-lhe um único modelo operativo que abrange login, recuperação, sessão e post-auth, e aponta para os guias mais aprofundados de cada parte.
A moldura útil: deixe de defender a verificação da palavra-passe e comece a pontuar a sessão. A palavra-passe costuma estar correta. O que está errado é o ambiente do navegador, o caminho de rede, o evento de recuperação ou a ação post-auth que se segue. A cside instrumenta a camada do navegador para capturar sinais de dispositivo e IP real, comportamento de agentes IA e stealth-browser, padrões de VPN/proxy e qualquer script de terceiros que manipule a sua página de login — a evidência que um registo de servidor por si só não mostrará.
O modelo operativo de ATO em quatro etapas
Trate o ATO como um ciclo de vida, não como um evento. Cada etapa tem um responsável, os seus próprios sinais de risco, uma ação de resposta e um rasto de evidência retido. Um sinal fraco numa etapa deve subir o nível na próxima, não desaparecer assim que o login tem sucesso.
| Etapa | Risco principal | Sinais a capturar | Resposta | Evidência a conservar |
|---|---|---|---|---|
| Login | Credential stuffing, bots com agentes IA | Velocidade de tentativas, fingerprint de dispositivo, navigator.webdriver, resultado MFA | Limitar, desafiar, bloquear | Registos de tentativas, fingerprint, resultado MFA |
| Recuperação | Abuso de resets, engenharia social de suporte | Idade do token de reset, reset a partir de dispositivo novo, alteração de email/telefone | Verificação reforçada, período de espera | Eventos de reset, delta de dispositivo, alterações de canal |
| Sessão | Reutilização de token, adversary-in-the-middle | Continuidade sessão-dispositivo, deriva de IP/ASN, deriva de fingerprint | Reautenticar, revogar sessão | Origem da sessão, ruturas de continuidade |
| Post-auth | Alteração de cobro/direção, velocidade de encomendas | Alteração de método de pagamento, compras de gift card, rajadas de encomendas | Reter ação, revisão manual | Histórico de alterações, decisão do analista |
Porque é que o perfil do atacante mudou
A parte barata do ATO ficou mais barata e mais esperta. A investigação da cside concluiu que as instalações de playwright-stealth — um dos muitos kits de stealth-browser usados para derrotar o fingerprinting — cresceram cerca de 10x ao longo de 2025 (relatório de investigação da cside). Essa categoria de ferramentas permite a um agente apresentar-se como uma sessão normal do Chrome ao mesmo tempo que automatiza logins em escala.
Estes agentes não se parecem com os bots de curl-e-proxy de há uns anos. Controlam um motor de renderização real, por isso as verificações ingénuas passam. Os indícios mudam-se para o runtime: incoerências entre o ambiente declarado e o observado, superfícies de controlo de automatização como as fugas de Runtime do Chrome DevTools Protocol (CDP), comportamento de proxy residencial e deriva de fingerprint ao longo de sessões que deveriam ser estáveis. A OWASP continua a descrever o credential stuffing como tentativas automatizadas de início de sessão usando pares conhecidos de utilizador e palavra-passe, e recomenda controlos em camadas — MFA, verificações de palavras-passe fugadas, limitação de velocidade e deteção de bots (cheat sheet da OWASP). As camadas continuam válidas; o que tem de ser reconstruído para os agentes é a camada de deteção de bots.
Onde os programas têm fugas
Uma defesa de login pode ser impecável e, ainda assim, a conta acabar roubada. As fugas agrupam-se em três lugares:
- Fluxos de recuperação — a reposição de palavra-passe e a remoção de dispositivos memorizados costumam ser mais fracas do que o login, e entregam ao atacante um acesso duradouro.
- Continuidade de sessão — um cookie reutilizado ou um proxy adversary-in-the-middle dão uma sessão autenticada sem palavra-passe e sem um novo passo de MFA.
- Ações post-auth de alto valor — alterações de cobro, edições de cartões guardados e compras de gift card são onde uma apropriação silenciosa se transforma em perda.
Pontue estas como as suas próprias superfícies. O NIST SP 800-63B trata a resistência a ataques automatizados como parte do design do autenticador e da sessão, o que coloca a mitigação de bots, a MFA resistente a phishing e os sinais de risco de sessão na mesma pilha de controlos (NIST SP 800-63B).
O plano de implementação de 90 dias
Não precisa de lançar as quatro etapas de uma vez. Sequencie conforme onde a perda aterra primeiro.
- Instrumente antes de impor. Implemente a captura de sinais da camada do navegador em modo apenas-observação em login, recuperação e checkout para ter uma linha de base de dispositivos e redes normais por conta.
- Reforce o login. Exija MFA resistente a phishing para contas de alto valor, bloqueie palavras-passe fugadas conhecidas no registo e no reset, e adicione deteção de agentes IA e stealth-browser no endpoint de login.
- Blinde a recuperação. Trate os resets como superfícies de fraude: verificação reforçada em resets a partir de dispositivo novo, períodos de espera após alterações de email ou telefone, e revisão de analista para recuperação gerida pelo suporte.
- Leve o risco para a sessão. Reautentique quando a continuidade sessão-dispositivo se rompe ou aparece deriva de fingerprint a meio da sessão, e revogue em vez de avisar perante uma reutilização confirmada.
- Barre as ações post-auth. Retenha alterações de cobro, direção e método de pagamento atrás da pontuação de risco de sessão, e exija um novo desafio para as mais arriscadas.
- Feche o ciclo com o suporte. Reveja os falsos positivos com a equipa de suporte todas as semanas, porque a fila deles é onde o bloqueio excessivo aparece primeiro.
Como o cluster se encaixa
Este post é o hub. Cada etapa tem um guia mais aprofundado, e o movimento certo é ler o que corresponde à fuga que está a corrigir.
| Se precisar de… | Leia |
|---|---|
| Montar um programa de ATO ao nível de negócio do zero | Como prevenir o fraude por account takeover |
| Apanhar a apropriação antes do checkout usando a deriva de sessão | Detete o account takeover antes que aconteça |
| Travar a automatização que alimenta as campanhas de stuffing | Credential stuffing: como detetar e parar |
Onde a cside se situa no modelo
A cside é a fonte de sinais da camada do navegador sobre a qual o modelo corre. Captura o contexto de dispositivo e IP real, o comportamento de agentes IA e stealth-browser, os padrões de VPN/proxy e a manipulação de scripts em runtime, e depois entrega esses sinais via API para que a sua lógica de fraude possa pontuar sessões através das quatro etapas. Como vigia o runtime, vê um script de terceiros manipulado a fazer skimming de credenciais na sua página de login — um ataque que um WAF e um registo de servidor ignoram por completo. Encaminhe uma única pontuação partilhada de risco de sessão através de login, recuperação, sessão e post-auth em vez de aparafusar regras separadas a cada um.
Leituras adicionais na cside
- Como prevenir o fraude por account takeover
- Detete o account takeover antes que aconteça
- Credential stuffing: como detetar e parar
- cside AI Agent Detection
