Olá a todos, Pat Reeves aqui, de volta ao botsec.net. Estamos em março de 2026, e se você é como eu, provavelmente ainda sente um pouco os efeitos da pura audácia de algumas atividades de botnet que observamos no ano passado. Enquanto as manchetes se concentravam em ataques DDoS e exfiltração de dados, outras coisas surgiram discretamente, algo que, para ser honesto, me impede de dormir à noite: as táticas cada vez mais sofisticadas que os bots usam para contornar os métodos de autenticação tradicionais, especialmente com a ascensão das passkeys.
Nos disseram que as passkeys são o futuro, não é? Resistentes a phishing, criptograficamente seguras, vinculadas a dispositivos. E por boas razões, elas abordam muitos pontos de dor antigos. Mas o que acontece quando o próprio mecanismo projetado para nos proteger se torna um vetor de comprometimento, não por um defeito na criptografia em si, mas na forma como é implementado e, principalmente, na maneira como os bots aprendem a manipular o elemento humano ao redor disso?
O paradoxo das passkeys: uma nova fronteira para os bots
Pense nisso. A promessa das passkeys é que elas eliminam os segredos compartilhados (senhas) e requerem interação do usuário em um dispositivo confiável. Ótimo! Sem mais credential stuffing, sem mais spraying, sem mais ataques de dicionário simples. Mas os bots, esses pequenos núcleos digitais persistentes, não desistem facilmente. Eles se adaptam. E o que observei, principalmente nas tentativas de takeover de contas (ATO) em plataformas que adotaram plenamente as passkeys, é uma virada para a engenharia social em grande escala, armada pela automação.
Minha experiência recente com um cliente, uma plataforma de e-commerce de tamanho médio que investiu massivamente em passkeys no verão passado, realmente me abriu os olhos. Eles viram uma queda massiva nos ataques baseados em credenciais tradicionais, o que foi fantástico. Mas então, há cerca de três meses, começaram a notar um aumento nas tentativas de “conexões falhadas” que eram… diferentes. Não eram falhas de senhas; eram tentativas de iniciar o registro de passkeys ou de recuperação a partir de dispositivos não reconhecidos, muitas vezes seguidas de uma multitude de solicitações de assistência de usuários legítimos afirmando que suas contas haviam sido “hackeadas”, apesar da ativação das passkeys.
O que descobrimos foi um ataque em várias etapas. Os bots não estavam tentando adivinhar as passkeys; eles estavam tentando enganar os usuários *gerando* ou *aprovando* novas passkeys em dispositivos controlados pelos atacantes, ou coagindo-os a redefinir as existentes. É uma variante da fadiga MFA “aprove essa conexão”, mas com riscos maiores, pois uma passkey comprometida significa controle total da conta.
Os desvio de passkeys guiados por bots: como isso funciona
Vamos detalhar o novo manual dos bots para a comprometimento das passkeys. Não se trata de bruteforcing. Trata-se de uma engenharia social sofisticada em grande escala, amplificada pela automação.
- Reconhecimento e Spear-Phishing leve: Os bots coletam dados públicos, redes sociais e até mesmo dumps do dark web para recuperar endereços de email e números de telefone. Eles então cruzam esses dados com as plataformas-alvo. O objetivo não é obter uma senha, mas identificar usuários ativos.
- O isca do “Novo Dispositivo”: Um bot, muitas vezes imitando um navegador legítimo ou um aplicativo móvel, tenta iniciar uma conexão ou registro de passkey para um usuário conhecido na plataforma alvo. Como o usuário não tem uma passkey registrada em este dispositivo específico (o ambiente simulado do bot), a plataforma frequentemente solicita um método de verificação alternativa ou de “adicionar uma nova passkey”.
- Engenharia Social Automatizada (ASE): É aqui que a mágica (ou melhor, a ameaça) acontece. O bot, tendo acionado uma notificação de sistema legítima (email, SMS, notificação push do próprio aplicativo), imediatamente segue com uma tentativa de phishing direcionada. Não é um email genérico “redefina sua senha”. É altamente contextual.
Imagine este cenário:
- Você recebe uma notificação push legítima do seu aplicativo bancário: “Nova tentativa de registro de passkey detectada a partir de um dispositivo desconhecido. Se foi você, aprove. Caso contrário, clique aqui para proteger sua conta.”
- Simultaneamente, você recebe um email minuciosamente redigido, aparentemente da equipe de segurança do seu banco, com um assunto como: “Urgente: Registro não autorizado de passkey detectado – Ação necessária.”
- O conteúdo do email é personalizado, talvez até fazendo referência à hora exata da tentativa de registro. Ele te direciona para uma página de phishing que se parece identicamente com o portal de segurança do seu banco.
- Nesta página de phishing, você é solicitado a “verificar sua identidade” inserindo sua antiga senha (se o banco ainda a aceita para recuperação), ou, mais insidiosamente, a “revogar passkeys não autorizadas”, o que na verdade te leva a *registrar uma nova passkey* no dispositivo do atacante, disfarçado como uma medida de segurança.
A chave aqui é o *momento* e o *contexto*. Os bots coordenam essas ações em grande escala, visando milhares de usuários simultaneamente. O usuário, ao ver uma notificação legítima do aplicativo e um email muito convincente e oportuno, é muito mais propenso a cair na armadilha do que com um phishing genérico.
Estratégias de defesa práticas contra o abuso de passkeys guiado por bots
Então, o que podemos fazer? Não podemos descartar as passkeys; elas ainda representam um grande avanço. Mas precisamos ser mais inteligentes na forma como as implementamos e as protegemos. Aqui estão alguns pontos que eu aconselhei meus clientes, com exemplos práticos.
1. Reforce seu fluxo de registro de “Nova Passkey”
Essa é a vulnerabilidade mais crítica. Se um atacante pode enganar um usuário para que ele registre uma nova passkey em seu dispositivo, já era. Você precisa de várias camadas de verificação aqui, além do convite inicial de passkey.
- Fator Secundário Obrigatório para Novos Registros: Mesmo que um usuário já esteja conectado, exigir uma verificação adicional, fora de banda (como um código único enviado para um número de telefone ou um email *pré-registrado*, não aquele fornecido durante a tentativa de registro) para *qualquer* novo registro ou substituição de passkey é crucial.
- Atestação do Dispositivo (onde for possível): Embora não seja infalível, a incorporação de verificações de atestação do dispositivo durante o registro de passkeys pode ajudar a filtrar máquinas virtuais ou emuladores evidentes que os bots podem usar. Não se trata de bloquear usuários legítimos, mas de adicionar um atrito para os ambientes de atacantes conhecidos.
- Limitação de Taxa e Detecção de Anomalias: Essa é uma defesa clássica contra bots, mas se aplica ainda mais aqui. Limitar agressivamente a taxa de tentativas de registro de passkeys provenientes de endereços IP únicos ou de faixas de endereços IP, juntamente com detecção de anomalias comportamentais (por exemplo, um usuário tentando repentinamente registrar 5 novas passkeys em uma hora a partir de locais geográficos diferentes), pode sinalizar uma atividade suspeita.
// Exemplo: Pseudocódigo para um bom fluxo de registro de nova passkey
function registerNewPasskey(userId, webauthnCredential) {
// 1. Verificar a sessão existente e a força da autenticação
if (!isAuthenticatedStrongly(userId)) {
// Forçar a re-autenticação ou uma MFA adicional
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Aguardar a conclusão da MFA
}
// 2. Realizar a validação da atestação FIDO2
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Atestação WebAuthn inválida ao registrar nova passkey");
return;
}
// 3. Opcional: Verificação da impressão do dispositivo / atestação (lado servidor)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Impressão de dispositivo suspeita para registro de nova passkey");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Verificação dos limites de taxa para novas passkeys por usuário/IP
if (rateLimitExceeded("new_passkey_registration", userId, request.ip)) {
logSecurityAlert(userId, "Limite de taxa excedido para registro de nova passkey");
return;
}
// 5. Armazenar a nova passkey
storeUserPasskey(userId, webauthnCredential);
sendUserNotification(userId, "Nova passkey registrada com sucesso.");
}
2. Melhore os processos de recuperação de conta
A recuperação de conta é outro alvo principal. Se um atacante consegue iniciar um fluxo de recuperação e depois manipular o usuário para que a aprove, ele tem acesso secundário.
- Adiar a recuperação de conta: Imponha um período de espera obrigatório (por exemplo, de 24 a 48 horas) para ações críticas de recuperação de conta, especialmente aquelas que envolvem a substituição de todas as passkeys existentes. Durante esse tempo, notifique o usuário proativamente através de todos os canais de comunicação conhecidos. Isso dá ao usuário legítimo a chance de intervir.
- Verificação KYC por Vídeo ou por Agente ao Vivo para Redefinição Completa: Para situações em que um usuário perdeu todas as suas passkeys e outros métodos de recuperação, considere exigir uma verificação de vídeo ao vivo com um agente de suporte. Essa é uma solução que requer mais esforço, mas para contas críticas, é um forte meio de dissuasão contra a engenharia social automatizada.
- Passkeys de “Cassa-Vitra”: Para contas administrativas internas ou sistemas altamente sensíveis, considere ter uma passkey física de “cassa-vitra” armazenada em um local seguro e auditado, necessitando de várias aprovações para ser utilizada. Isso não é para contas de consumidores, mas para alvos de alto valor, é indispensável.
3. Educação de usuários que realmente funciona
Fazemos “educação de usuários” há décadas e, honestamente, a maior parte disso falha. Para as passkeys, precisamos de orientações direcionadas, oportunas e específicas.
- “O Que Esperar” Guias: Explique claramente aos usuários como são as notificações de passkey legítimas e os processos de recuperação. Mostre capturas de tela.
- “O Que NÃO Fazer” Alertas: Alerte especificamente os usuários para não aprovarem registros de passkey que não iniciaram, nem clicarem em links em e-mails que alegam “revogar” passkeys, especialmente se não tiverem tentado uma ação de segurança por conta própria.
- Verificações de Segurança no App: Forneça uma seção de fácil acesso em seu aplicativo ou site onde os usuários possam ver todas as passkeys registradas, sua origem (se possível) e revogá-las. Mantenha isso simples e intuitivo.
// Exemplo: Alerta no app para atividade suspeita
function displaySuspiciousActivityWarning(userId, activityDetails) {
const warningMessage = `
⚠ Atividade Suspeita Detectada!
Detectamos uma tentativa de registro de uma nova passkey para sua conta a partir de um dispositivo não reconhecido (${activityDetails.ipAddress} - ${activityDetails.location}) em ${activityDetails.timestamp}.
Se foi você, pode ignorar com segurança. Se NÃO foi você, por favor, tome uma ação imediata:
- Vá para suas Configurações de Segurança para revisar e revogar as passkeys.
- Troque seus outros métodos de recuperação (por exemplo, senha de e-mail).
- Entre em contato com o suporte se precisar de ajuda.
`;
document.getElementById('security-alert-banner').innerHTML = warningMessage;
document.getElementById('security-alert-banner').style.display = 'block';
}
Esse tipo de aviso direto no aplicativo, acionado pela mesma atividade de bot contra a qual estamos tentando nos proteger, pode ser extremamente eficaz.
Dicas Ação para Especialistas em Segurança de Bots
O campo das ataques de bots está em constante evolução. As passkeys são excelentes, mas não são uma solução milagrosa, e os atacantes já estão encontrando novas formas de explorar o elemento humano que as cerca. Aqui está minha lista de verificação para você:
- Audite seus Fluxos de Passkey: Revise cada fluxo relacionado às passkeys – registro, login, recuperação, revogação – com a mentalidade de um atacante por bot. Onde um bot pode interferir na engenharia social?
- A Verificação em Camadas é Essencial: Nunca confie em um único fator para ações de alto impacto, como registrar uma nova passkey ou recuperar completamente a conta. Adicione uma MFA fora da banda.
- Eduque, não se Limite a Informar: Desenvolva uma educação para usuários que seja proativa, muito específica às ameaças de passkeys, e integrada diretamente nas funcionalidades de segurança do seu aplicativo.
- Monitore as Anomalias: Fique atento aos seus logs para detectar padrões incomuns nas tentativas de registro de passkeys, solicitações de recuperação e tickets de suporte de usuário associados. Os bots operam em grande escala, e esses padrões vão surgir.
- Não Esqueça o Básico: Enquanto se concentra nas passkeys, não negligencie suas defesas fundamentais contra bots para outras partes do seu aplicativo: limitação rigorosa de taxa, reputação de IP, análise comportamental e CAPTCHAs quando apropriado. Os bots podem evoluir, mas ainda deixam rastros.
O futuro da autenticação é promissor, mas apenas se anteciparmos como os atores maliciosos vão tentar contorná-lo. Mantenha-se alerta, mantenha-se seguro, e nos veremos da próxima vez aqui no botsec.net.
Artigos Relacionados
- Proteção da privacidade de dados de bots AI
- Minha Opinião: OmniMind AI é um Pesadelo para a Segurança
- Notícias sobre Segurança AI Hoje: Atualizações Urgentes & Perspectivas de Especialistas
🕒 Published: