Olá a todos, Pat Reeves aqui, de volta ao botsec.net. Estamos em março de 2026, e se vocês são como eu, provavelmente ainda estão um pouco chocados com a ousadia de algumas das atividades de botnet que observamos no ano passado. Enquanto os manchetes focavam em ataques DDoS e na exfiltração de dados, algo mais discretamente surgiu, algo que, francamente, me impede de dormir à noite: as táticas cada vez mais sofisticadas que os bots utilizam para contornar os métodos de autenticação tradicionais, especialmente com a ascensão das passkeys.
Nos dizem que as passkeys são o futuro, certo? Resistentes a phishing, criptograficamente seguras, vinculadas a um dispositivo. E com boas razões, elas atendem a 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 causa de uma falha na criptografia em si, mas pela maneira como é implementado e, acima de tudo, pela forma como os bots aprendem a manipular o elemento humano que o cerca?
O Paradoxo das Passkeys: Uma Nova Fronteira para os Bots
Pense nisso. A promessa das passkeys é que elas eliminam os segredos compartilhados (senhas) e exigem uma interação do usuário em um dispositivo de confiança. Ótimo! Chega de credential stuffing, chega de spraying, chega de ataques simples de dicionário. Mas os bots, como se chamam, não se deixam desencorajar. Eles se adaptam. E o que eu observei, especialmente nas tentativas de takeover de conta (ATO) em plataformas que adotaram totalmente as passkeys, é uma mudança para a engenharia social em larga escala, armada pela automação.
Minha experiência recente com um cliente, uma plataforma de comércio eletrônico de médio porte que adotou completamente as passkeys no verão passado, realmente abriu meus olhos. Eles perceberam uma enorme queda 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 “login falhado” que eram… diferentes. Não eram falhas de senha; eram tentativas de iniciar o registro ou a recuperação de passkeys a partir de dispositivos não reconhecidos, frequentemente seguidas de uma enxurrada de solicitações de suporte por parte de usuários legítimos alegando 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 para que *gerassem* ou *aprovassem* novas passkeys em dispositivos controlados pelo atacante, ou os forçar a redefinir as existentes. É uma variação da antiga fadiga relacionada à MFA do tipo “aprove esta conexão”, mas com riscos maiores, pois uma passkey comprometida significa controle total da conta.
Drenagem de Passkeys pelos Bots: Como Funciona
Vamos detalhar o novo manual dos bots para a comprometimento das passkeys. Não se trata de brute-forcing. Trata-se de engenharia social sofisticada em larga escala, amplificada pela automação.
- Reconhecimento e Spear-Phishing leve: Os bots exploram dados públicos, redes sociais, e até mesmo vazamentos da dark web em busca de endereços de e-mail e números de telefone. Depois, eles cruzam essas informações com as plataformas-alvo. O objetivo não é obter uma senha, mas identificar usuários ativos.
- O truque do “Novo Dispositivo”: Um bot, muitas vezes imitando um navegador ou um aplicativo móvel legítimo, 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 neste dispositivo específico (o ambiente simulado do bot), a plataforma frequentemente solicita um método de verificação alternativo ou para “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 (e-mail, SMS, notificação push do próprio aplicativo), imediatamente segue com uma tentativa de phishing direcionada. Não é um e-mail genérico de “reset sua senha”. É altamente contextual.
Imagine este cenário:
- Você recebe uma notificação push legítima do seu aplicativo bancário: “Tentativa de registro de nova 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 e-mail meticulosamente elaborado, aparentemente da equipe de segurança do seu banco, com um assunto como: “Urgente: Registro de passkey não autorizado detectado – Ação requerida.”
- O conteúdo do e-mail é direcionado, talvez até referindo-se ao horário específico da tentativa de registro. Ele o direciona para uma página de phishing que se parece muito com o portal de segurança do seu banco.
- Nessa página de phishing, você é solicitado a “verificar sua identidade” inserindo sua senha antiga (se o banco ainda a suportar para recuperação), ou, de maneira mais sorrateira, a “revogar as passkeys não autorizadas”, o que na verdade o incentiva a *registrar uma nova passkey* no dispositivo do atacante, disfarçado de medida de segurança.
A chave aqui é o *tempo* e o *contexto*. Os bots coordenam essas ações em larga escala, atingindo milhares de usuários simultaneamente. O usuário, vendo uma notificação legítima do aplicativo e um e-mail muito convincente e oportuno, é muito mais propenso a cair do que por uma tentativa de phishing genérica.
Estratégias de Defesa Práticas Contra o Abuso das Passkeys pelos Bots
Então, o que podemos fazer? Não podemos jogar as passkeys fora; elas ainda representam um imenso avanço. Mas precisamos ser mais inteligentes sobre como as implementamos e as protegemos. Aqui estão algumas dicas que eu dei aos meus clientes, com alguns exemplos práticos.
1. Fortaleça Seu Fluxo de Registro de “Nova Passkey”
Esta é a vulnerabilidade mais crítica. Se um atacante conseguir convencer um usuário a registrar uma nova passkey em seu dispositivo, é o fim. Você precisa de várias camadas de verificação aqui, além do simples prompt de passkey inicial.
- Segundo fator obrigatório para novos registros: Mesmo que um usuário já esteja logado, exigir uma verificação adicional fora da banda (como um código único enviado para um número de telefone ou um endereço de e-mail *pré-registrados*, e não o fornecido durante a tentativa de registro) para *qualquer* novo registro ou substituição de passkey é crucial.
- Atestação do Dispositivo (quando possível): Embora não seja infalível, a incorporação de verificações de atestação do dispositivo durante o registro da passkey pode ajudar a filtrar máquinas virtuais ou emuladores óbvios que os bots possam usar. Não se trata de bloquear usuários legítimos, mas de adicionar atritos para os ambientes conhecidos dos atacantes.
- Limitação de Taxa e Detecção de Anomalias: Isso faz parte da defesa clássica contra bots, mas se aplica ainda mais aqui. Uma limitação de taxa agressiva sobre tentativas de registro de passkeys originadas de endereços IP únicos ou de blocos de IP, combinada com a detecção de anomalias comportamentais (por exemplo, um usuário tentando repentinamente registrar 5 novas passkeys em uma hora de diferentes locais geográficos), 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 adicionar uma MFA adicional
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Aguardar o término da MFA
}
// 2. Validação da atestação FIDO2
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Atestação WebAuthn inválida durante o registro da nova passkey");
return;
}
// 3. Opcional: Verificação da impressão digital do dispositivo (lado do servidor)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Impressão digital do dispositivo suspeita para o registro da nova passkey");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Verificação de limite de taxa para novas passkeys por usuário/IP
if (rateLimitExceeded("new_passkey_registration", userId, request.ip)) {
logSecurityAlert(userId, "Limite de taxa excedido para o registro da nova passkey");
return;
}
// 5. Armazenar a nova passkey
storeUserPasskey(userId, webauthnCredential);
sendUserNotification(userId, "Nova passkey registrada com sucesso.");
}
2. Aprimore os Processos de Recuperação de Conta
A recuperação de conta é um alvo privilegiado. Se um atacante pode iniciar um fluxo de recuperação e manipular o usuário para aprová-lo, ele tem uma porta dos fundos.
- Retardar a Recuperação de Conta: Implemente um período de espera obrigatório (por exemplo, 24-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 este tempo, informe o usuário proativamente por meio de todos os canais de comunicação conhecidos. Isso dá uma chance ao usuário legítimo de intervir.
- Verificação KYC por Vídeo ou Agente ao Vivo para Reconfiguraçã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 por vídeo ao vivo com um agente de suporte. É uma solução de alta fricção, mas para contas críticas, é um poderoso meio de dissuasão contra engenharia social automatizada.
- Passkeys “Quebrar o Vidro”: Para contas administrativas internas ou sistemas altamente sensíveis, considere ter uma passkey física “quebrar o vidro” armazenada em um local seguro e auditável, requerendo várias aprovações para ser utilizada. Não é para contas de consumidores, mas para alvos de alto valor, é indispensável.
3. Conscientização de Usuários que Realmente Funciona
Fazemos “conscientização de usuários” há décadas e, honestamente, na maioria das vezes, isso não funciona. Para as passkeys, precisamos de instruções direcionadas, oportunas e específicas.
- “Guias sobre o que esperar”: Explique claramente aos usuários como são as notificações e os processos legítimos de recuperação de passkey. Mostre capturas de tela.
- “Alertas sobre o que NÃO fazer”: Alerte especificamente os usuários para não aprovarem registros de passkey que não iniciaram, nem clicarem em links em e-mails que afirmam “revogar” passkeys, especialmente se não tentaram uma ação de segurança recentemente.
- Controles de segurança no aplicativo: 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. Torne isso simples e intuitivo.
// Exemplo: Alerta no aplicativo 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, aja imediatamente:
- Vá para suas Configurações de segurança para revisar e revogar as passkeys.
- Altere seus outros métodos de recuperação (por exemplo, senha do 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 defender, pode ser incrivelmente eficaz.
Lições práticas para os profissionais de segurança de bots
O campo dos ataques de bots está em constante evolução. As passkeys são excelentes, mas não são uma solução mágica, e os atacantes já estão encontrando novas formas de explorar o elemento humano que as envolve. Aqui está minha lista de ações 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 de bot. Onde um bot poderia interceptar uma engenharia social?
- A verificação em múltiplas etapas é essencial: Nunca conte com um único fator para ações de alto impacto, como o registro de uma nova passkey ou a recuperação total de uma conta. Adicione uma MFA fora da banda.
- Eduque, não apenas informe: Conceba uma educação ao usuário que seja proativa, altamente específica às ameaças de passkey e integrada diretamente nas funcionalidades de segurança de seu aplicativo.
- Monitore as anomalias: Fique atento aos seus registros para detectar padrões incomuns nas tentativas de registro de passkey, nos pedidos de recuperação e nos tickets de suporte ao usuário associados. Os bots operam em grande escala, e esses padrões vão emergir.
- Não negligencie os fundamentos: Enquanto se concentra nas passkeys, não esqueça suas defesas fundamentais contra bots para outras partes do seu aplicativo: limitação de taxa rigorosa, reputação de IP, análise comportamental e CAPTCHAs onde apropriado. Os bots podem evoluir, mas sempre deixam rastros.
O futuro da autenticação é promissor, mas apenas se anteciparmos como os agentes maliciosos tentarão subvertê-lo. Mantenha-se vigilante, mantenha-se seguro, e nos veremos da próxima vez aqui no botsec.net.
Artigos relacionados
- Proteção da privacidade dos dados dos bots de IA
- Minha opinião: OmniMind IA é um pesadelo de segurança
- Notícias sobre a segurança da IA hoje: Atualizações urgentes & Perspectivas de especialistas
🕒 Published: