Resumo: roubo de credenciais
- Roubo versus stuffing: o roubo é como os atacantes obtêm credenciais válidas. O stuffing é o que fazem a seguir. Sinais diferentes, pilhas de deteção diferentes.
- O ponto cego do MFA: o MFA padrão não trava as quatro técnicas dominantes: páginas de phishing, proxies AiTM à Evilginx, scripts de terceiros comprometidos e malware infostealer.
- A sua própria página de autenticação: a superfície pior defendida é a sua própria página de início de sessão. Um script de terceiros comprometido lê o formulário enquanto o utilizador escreve, e os controlos de servidor nunca o veem.
Pouco tempo? Veja a deteção de tomada de conta da cside. Cobre tudo o que se segue numa única implementação.
Roubo de credenciais não é credential stuffing (e a diferença importa)
Imagine que um fornecedor antifraude lhe diz que «trava os ataques a credenciais». Pergunte qual das metades: o roubo ou o stuffing. Se não souber responder com clareza, está a vender-lhe limitação de pedidos disfarçada de plataforma de ameaças.
O roubo está no topo do funil. Os atacantes recolhem credenciais válidas. O stuffing está na base. Os atacantes testam essas credenciais em sites-alvo. Uma única operação de roubo alimenta milhares de campanhas de stuffing. Uma única credencial roubada pode ser testada em todos os comerciantes da internet.
Os sinais de deteção são diferentes:
- O roubo aparece no SEU site como atividade suspeita de scripts na página de autenticação, ou como exfiltração de dados para um domínio de terceiros desconhecido.
- O stuffing aparece no SEU site como tentativas de autenticação em massa, velocidade por IP e padrões distribuídos, lentos e discretos.
A limitação de pedidos trava o stuffing. Não toca no roubo. Se a sua única defesa contra ataques a credenciais for um limite de pedidos em /api/login, está a apanhar a segunda metade do ataque e a deixar a primeira seguir sem oposição.
Quatro técnicas de roubo de 2026 que o seu MFA não trava
1. Páginas de phishing (ainda o vetor número um)
Os atacantes registam um domínio semelhante (veja o nosso artigo sobre ataques homóglifos e o truque dos carateres cirílicos), clonam o HTML da sua autenticação e geram tráfego por SMS ou e-mail. O utilizador escreve a palavra-passe numa página idêntica à sua. A credencial vai para o atacante.
O MFA padrão reduz o valor da palavra-passe roubada, mas não a zero. Se o utilizador a reutilizar noutros sítios (cerca de 65 % fazem-no, segundo todos os estudos sobre reutilização), o atacante acabou de obter acesso ao e-mail, ao banco ou ao conjunto de SaaS dessa pessoa.
2. Adversário no meio à Evilginx (AiTM)
O Evilginx é uma framework de phishing de código aberto que corre um proxy inverso entre a vítima e a página de autenticação real. A vítima escreve a palavra-passe. O Evilginx reencaminha-a para o site real. O site real devolve o pedido de MFA. A vítima resolve o MFA. O Evilginx reencaminha-o. O site real devolve o cookie de sessão. O Evilginx rouba o cookie de sessão.
Isto derrota o MFA por TOTP, OTP por SMS e notificação push. Não derrota passkeys nem chaves de hardware FIDO2, porque estas ligam-se criptograficamente ao domínio de origem e recusam autenticar num site servido por proxy.
Se a sua base de utilizadores não estiver em MFA resistente a phishing em 2026, os ataques da classe Evilginx são baratíssimos para os atacantes. A framework é de código aberto, os modelos de phishing são banais e o retorno é contornar qualquer implementação de MFA que não seja FIDO2.
3. Script de terceiros comprometido na sua própria página de autenticação
Esta é a que a maioria das defesas falha. A sua página de autenticação está limpa. O seu código de servidor está limpo. Os seus certificados são válidos.
Mas a sua página de autenticação carrega scripts. Google Tag Manager. Um widget de chat. Analítica. Testes A/B. Qualquer um deles, ou qualquer uma das suas dependências transitivas, pode ser atualizado pelo respetivo proprietário sem o avisar. Quando um é comprometido, seja por um ataque à cadeia de fornecimento como o Polyfill[.]io (mais de 490 000 sites afetados em 2024), seja por uma alteração de regra no gestor de etiquetas, o script comprometido passa a correr no mesmo contexto JavaScript do seu formulário de autenticação.
Pode ler os campos do formulário. Pode ligar um listener ao evento de submissão. Pode enviar as credenciais para um domínio controlado pelo atacante antes mesmo de o seu endpoint de autenticação ver o pedido.
O seu WAF não vê isto. Os seus registos de servidor não veem isto. O seu SIEM não vê isto. O único sítio onde a exfiltração é visível é dentro da sessão do navegador do visitante, no momento em que acontece.
4. Malware infostealer no dispositivo do utilizador
Infostealers como o RedLine, o Raccoon e o LummaC2 recolhem palavras-passe guardadas nos navegadores, cookies dos armazenamentos de sessão locais e tokens MFA das aplicações de autenticação. Uma vez instalados no dispositivo da vítima, correm continuamente e enviam as credenciais recolhidas para a infraestrutura do atacante.
Não consegue travar este ataque do seu lado do cabo. O que PODE fazer é detetar a utilização a jusante: uma autenticação bem-sucedida a partir de uma impressão digital de dispositivo ou de uma origem geográfica incoerentes com o histórico da conta.
O conjunto de dados que os atacantes usam mesmo em 2026
O RockYou2024 é o corpus de referência. Publicado em meados de 2024, contém cerca de 10 mil milhões de palavras-passe únicas em texto simples. Um agregado de todas as compilações de fugas relevantes anteriores, sem duplicados e normalizado. Qualquer compilação anterior (Collections #1 a #5, Pwned Passwords do Have I Been Pwned, as várias fugas «COMB») é um subconjunto.
Os atacantes não lançam 10 mil milhões de credenciais contra a sua autenticação. Isso acionaria qualquer limite de pedidos. O que fazem é:
- Filtrar as credenciais correspondentes ao seu domínio (pelos metadados da fuga de origem)
- Filtrar as credenciais criadas nos últimos 24 meses (maior probabilidade de continuarem válidas)
- Filtrar as palavras-passe que passam heurísticas básicas de robustez (os atacantes assumem que o utilizador reutilizou uma palavra-passe «a sério», não
password123) - Testar o subconjunto filtrado em lotes lentos e discretos a partir de IP residenciais
É por isto que a reputação de IP não o ajuda a apanhar o credential stuffing moderno. O IP é de um fornecedor residencial. A velocidade por IP são 2 a 3 tentativas por hora. Só a correlação entre contas o apanha.
O que deteta realmente o roubo de credenciais
Quatro fontes de sinal, por ordem de retorno.
1. Monitorização em sessão da sua página de autenticação
A única defesa que apanha a técnica número três (script de terceiros comprometido) é observar o que os scripts leem de facto do formulário de autenticação, na sessão do navegador de um utilizador real. É isto que faz a plataforma de segurança do lado do cliente da cside. Um sensor first party observa leituras do DOM, acessos a campos do formulário e atividade de rede de saída em cada sessão real, e sinaliza qualquer script que toque nos campos de credenciais sem constar da lista autorizada.
Isto não se constrói por conta própria como um exercício pontual. É precisa observação contínua em todas as sessões reais, porque o atacante só ativa a exfiltração num subconjunto de visitantes (geografia específica, navegador específico, tipo de conta específico) para escapar aos scanners de deteção.
2. Inteligência de dispositivo na autenticação
No endpoint de autenticação, calcule uma impressão digital de dispositivo a partir de atributos do navegador, impressão TLS ou JA e cadência comportamental. Compare-a com o histórico de dispositivos da conta. Um dispositivo novo, a partir de uma geografia nova, a tentar autenticar-se é um sinal forte de que algo está errado, venha de um AiTM à Evilginx ou de uma recolha recente por infostealer.
A nossa introdução à inteligência de dispositivo percorre a pilha de sinais. Em resumo: mais de 40 atributos do navegador combinados num ID de dispositivo estável que sobrevive à limpeza de cookies e às janelas privadas.
3. Consulta ao Have I Been Pwned na autenticação (ou melhor, no registo)
O Have I Been Pwned publica uma API de consulta por intervalo que permite verificar se uma palavra-passe consta de algum corpus de fugas conhecido sem enviar a palavra-passe real (através de um prefixo SHA-1 com k-anonimato). Isto devia ser um passo em qualquer fluxo de autenticação acima de certa pontuação de risco.
Se um utilizador se autenticar com uma palavra-passe que consta do RockYou2024, trate isso como prova prima facie de roubo. Force a reposição da palavra-passe e escale para MFA resistente a phishing na autenticação seguinte.
4. Correlação entre contas
O sinal mais fiável é o mesmo dispositivo, a mesma impressão digital ou o mesmo padrão comportamental tentarem autenticar-se em várias contas da sua plataforma numa janela curta. A limitação por conta não vê isto. A limitação por IP também não, porque os proxies residenciais rodam a cada 30 segundos. Só a correlação de sinais de dispositivo o apanha.
Onde o MFA ainda ajuda (e onde não)
O MFA resistente a phishing (WebAuthn, chaves de hardware FIDO2, passkeys) trava mesmo os casos da página de phishing e do Evilginx. Se a sua base de utilizadores não lá estiver no final de 2026, está a manter um anacronismo.
Mas o MFA resistente a phishing não ajuda contra:
- Script de terceiros comprometido na sua própria página de autenticação (o script lê o campo da palavra-passe seja qual for o tipo de MFA)
- Malware infostealer no dispositivo do utilizador (o malware exfiltra a semente da passkey ou o cookie de sessão após a autenticação)
- Ataques de correlação entre contas (a credencial já é válida; o MFA na primeira autenticação não é o estrangulamento)
A deteção em camadas (MFA mais monitorização em sessão mais inteligência de dispositivo mais consulta ao HIBP) é o que fecha as quatro falhas. Nenhum controlo isolado o faz.
O que dizemos a quem pergunta se a cside é «mais um fornecedor de MFA»
Não somos. O MFA é o que acontece no seu endpoint de autenticação. A cside é o que acontece na sessão do navegador, nos sete segundos entre o utilizador escrever a palavra-passe e carregar em enviar. Vemos os scripts que leem o formulário. Vemos as chamadas de rede de saída. Vemos as tentativas de exfiltração que nunca chegam aos seus registos de servidor.
Se a sua defesa parar no endpoint de autenticação, não está a ver a técnica número três. É o caso de cerca de 90 % das autenticações de comércio eletrónico, fintech e SaaS em 2026. Corrija isso e fecha a maior falha desatendida da cadeia de ataque a credenciais.
Leitura relacionada
- Credential stuffing: como detetá-lo e travá-lo na autenticação
- O que é o fingerprinting de dispositivo: o guia definitivo de 2026
- Prevenção da fraude por tomada de conta: o guia completo de 2026
- Como o Polyfill[.]io comprometeu 490 000 sites (ataque à cadeia de fornecimento do navegador)
- Ataques homóglifos: o problema аpple.com
