Olá a todos, Pat Reeves aqui, novamente no botsec.net. Estamos em março de 2026, e se vocês são como eu, provavelmente ainda sentem um pouco os efeitos da pura audácia de algumas atividades de botnet que observamos no ano passado. Enquanto os títulos dos jornais se concentravam nos ataques DDoS e na exfiltração de dados, outras coisas emergiram discretamente, algo que, honestamente, me impede de dormir à noite: as táticas cada vez mais sofisticadas que os bots usam para eludir os métodos de autenticação tradicionais, especialmente com o aumento das passkeys.
Nos disseram que as passkeys são o futuro, certo? Resistentes a phishing, criptograficamente seguras, ligadas a dispositivos. E por boas razões, elas respondem a muitos pontos problemáticos 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 pela forma como é implementado e, sobretudo, pela maneira como os bots aprendem a manipular o elemento humano em torno disso?
O paradoxo das passkeys: uma nova fronteira para os bots
Pensem nisso. A promessa das passkeys é que eliminam os segredos compartilhados (senhas) e exigem uma interação do usuário em um dispositivo de confiança. Ótimo! Nada mais de credential stuffing, nada mais de spraying, nada mais de ataques de dicionário simples. Mas os bots, esses pequenos corações digitais persistentes, não desistem facilmente. Eles se adaptam. E o que eu observei, particularmente nas tentativas de takeover de contas (ATO) em plataformas que adotaram completamente as passkeys, é uma devolução para a engenharia social em larga escala, armada pela automação.
Minha experiência recente com um cliente, uma plataforma de e-commerce de médio porte que investiu massivamente nas passkeys no verão passado, realmente me abriu os olhos. Eles viram uma queda massiva nos ataques baseados em credenciais tradicionais, o que foi incrível. Mas cerca de três meses atrás, começaram a notar um aumento nos tentativas de “acesso falhado” que eram… diferentes. Não eram falhas de senha; eram tentativas de iniciar o registro de passkeys ou de recuperação de dispositivos não reconhecidos, muitas vezes seguidas por uma série de solicitações de suporte de usuários legítimos afirmando que suas contas estavam “hackeadas” apesar da ativação das passkeys.
O que descobrimos foi um ataque em mais fases. Os bots não estavam tentando adivinhar as passkeys; estavam tentando enganar os usuários gerando ou aprovando novas passkeys em dispositivos controlados pelos invasores, ou coercionando a redefinir as existentes. É uma variante da fadiga MFA “aprovar este acesso”, mas com riscos mais elevados, uma vez que uma passkey comprometida significa controle total da conta.
Os sequestros de passkeys guiados por bots: como funciona
Vamos decompor o novo manual dos bots para a comprometimento de passkeys. Não se trata de força bruta. Trata-se de uma engenharia social sofisticada em larga escala, amplificada pela automação.
- Reconhecimento e Spear-Phishing leve: Os bots coletam dados públicos, das redes sociais e até de dumps da dark web para recuperar endereços de e-mail e números de telefone. Depois cruzam esses dados com as plataformas visadas. O objetivo não é obter uma senha, mas identificar usuários ativos.
- A isca do “Novo Dispositivo”: Um bot, muitas vezes imitando um navegador legítimo ou um aplicativo móvel, tenta iniciar uma conexão ou um registro de passkey para um usuário conhecido na plataforma alvo. Como o usuário não possui uma passkey registrada neste dispositivo específico (o ambiente simulado pelo bot), a plataforma muitas vezes exige um método de verificação alternativo ou de “adicionar uma nova passkey”.
- Engenharia Social Automatizada (ASE): É aqui que acontece a mágica (ou melhor, a ameaça). O bot, tendo ativado uma notificação de sistema legítima (e-mail, SMS, notificação push do próprio aplicativo), segue imediatamente com uma tentativa de phishing direcionada. Não é um e-mail genérico “renove sua senha”. É altamente contextualizado.
Imagine este cenário:
“`html
- Receba uma notificação push legítima do seu app bancário: “Nova tentativa de registro de passkey detectada de um dispositivo desconhecido. Se foi você, aprove. Caso contrário, clique aqui para proteger sua conta.”
- Ao mesmo tempo, receba um e-mail cuidadosamente redigido, aparentemente da equipe de segurança do seu banco, com um assunto do tipo: “Urgente: Registro não autorizado de passkey detectado – Ação necessária.”
- O conteúdo do e-mail é personalizado, talvez até fazendo referência à hora exata da tentativa de registro. Ele te direciona a uma página de phishing que se parece exatamente com o portal de segurança do seu banco.
- Nesta página de phishing, você é solicitado a “verificar sua identidade” inserindo sua senha antiga (se o banco ainda a apoiar para recuperação), ou, de forma mais traiçoeira, a “revogar passkeys não autorizadas”, na verdade te empurrando 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, mirando milhares de usuários simultaneamente. O usuário, ao ver uma notificação legítima do app e um e-mail muito convincente e oportuno, está muito mais propenso a cair na armadilha em comparação a 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 abandonar as passkeys; ainda representam um grande avanço. Mas precisamos ser mais astutos na maneira como as implementamos e protegemos. Aqui estão alguns pontos que eu recomendei aos meus clientes, com exemplos práticos.
1. Reforce seu fluxo de registro de « Nova Passkey »
Esta é a vulnerabilidade mais crítica. Se um agressor consegue enganar um usuário para registrar uma nova passkey em seu dispositivo, está acabado. Você precisa de mais camadas de verificação aqui, além do convite inicial para a 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 a um número de telefone ou a um e-mail *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 possível): Mesmo que não seja infalível, a incorporação de verificações de atestação do dispositivo durante o registro das passkeys pode ajudar a filtrar máquinas virtuais ou emuladores óbvios que os bots poderiam utilizar. Não se trata de bloquear usuários legítimos, mas de adicionar atrito para os ambientes de atacantes conhecidos.
- Limitação de Taxa e Detecção de Anomalias: Esta é uma defesa clássica contra bots, mas se aplica ainda mais aqui. Limitar agressivamente o número de tentativas de registro de passkey provenientes de endereços IP únicos ou de intervalos de endereços IP, combinado com uma detecção de anomalias comportamentais (por exemplo, um usuário que de repente tenta registrar 5 novas passkeys em uma hora de localizações geográficas diferentes), pode sinalizar uma atividade suspeita.
“““html
// Exemplo: Pseudocódigo para um bom fluxo de registro de uma nova chave de acesso
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 um MFA adicional
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Aguardar o término do MFA
}
// 2. Realizar a validação da atestação FIDO2
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Atestação WebAuthn inválida durante o registro de uma nova chave de acesso");
return;
}
// 3. Opcional: Verificação da impressão do dispositivo / atestação (lado do servidor)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Impressão do dispositivo suspeita para o registro de uma nova chave de acesso");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Verificação dos limites de taxa para novas chaves de acesso por usuário/IP
if (rateLimitExceeded("new_passkey_registration", userId, request.ip)) {
logSecurityAlert(userId, "Limite de taxa excedido para o registro de uma nova chave de acesso");
return;
}
// 5. Armazenar a nova chave de acesso
storeUserPasskey(userId, webauthnCredential);
sendUserNotification(userId, "Nova chave de acesso registrada com sucesso.");
}
2. Melhorar os processos de recuperação de conta
A recuperação de conta é outro alvo principal. Se um atacante pode iniciar um fluxo de recuperação e depois manipular o usuário para que o aprove, ele obtém um acesso secundário.
- Atrasar 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 chaves de acesso existentes. Enquanto isso, notifique proativamente o usuário por meio de todos os canais de comunicação conhecidos. Isso oferece ao usuário legítimo a chance de intervir.
- Verificação KYC via Vídeo ou Agente ao Vivo para Reset Completo: Para situações em que um usuário perdeu todas as suas chaves de acesso e outros métodos de recuperação, considere solicitar uma verificação por vídeo ao vivo com um agente de suporte. É uma solução de alto atrito, mas para contas críticas, é um forte impedimento contra engenharia social automatizada.
- Chave de “Vitrine”: Para contas administrativas internas ou sistemas altamente sensíveis, considere ter uma chave física de “vitrine” armazenada em um local seguro e auditado, exigindo múltiplas aprovações para ser utilizada. Não é para contas de consumidores, mas para alvos de alto valor, é indispensável.
3. Educação dos usuários que realmente funciona
Há décadas fazemos “educação dos usuários” e, honestamente, a maior parte dela falha. Para as chaves de acesso, precisamos de orientações direcionadas, oportunas e específicas.
- Guias “O que Esperar”: Explique claramente aos usuários como são as notificações de chaves de acesso legítimas e os processos de recuperação. Mostre capturas de tela.
- Alertas “O que NÃO Fazer”: Avise especificamente os usuários para não aprovarem registros de chaves de acesso que não iniciaram, nem cliquem em links em e-mails que afirmam “revogar” chaves de acesso, especialmente se não tentaram uma ação de segurança.
- Verificações de Segurança no App: Forneça uma seção facilmente acessível em seu aplicativo ou site onde os usuários possam ver todas as chaves de acesso registradas, sua origem (se possível) e revogá-las. Torne isso simples e intuitivo.
// Exemplo: Aviso no aplicativo para atividades suspeitas
function displaySuspiciousActivityWarning(userId, activityDetails) {
const warningMessage = `
⚠ Atividade Suspeita Detectada!
Detectamos uma tentativa de registro de uma nova chave de acesso para sua conta 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Ê, pedimos que aja imediatamente:
- Vá nas suas Configurações de Segurança para revisar e revogar as chaves de acesso.
- Altere seus outros métodos de recuperação (por exemplo, email de senha).
- Contate o suporte se precisar de ajuda.
``````html
`;
document.getElementById('security-alert-banner').innerHTML = warningMessage;
document.getElementById('security-alert-banner').style.display = 'block';
}
Este tipo de aviso direto no app, ativado pela mesma atividade de bot contra a qual estamos tentando nos defender, pode ser extremamente eficaz.
Dicas Ações para Especialistas em Segurança de Bots
O campo dos ataques de bots está sempre em evolução. As chaves de acesso são excelentes, mas não são uma solução milagrosa, e os atacantes já estão encontrando novos modos de explorar o elemento humano ao seu redor. Aqui está a minha lista de verificação para você:
- Audite seus Fluxos de Chave de Acesso: Revise cada fluxo relacionado às chaves de acesso – registro, login, recuperação, revogação – com a mente de um atacante de bot. Onde um bot pode interferir na engenharia social?
- A Verificação em Camadas é Essencial: Nunca conte com um único fator para ações de alto impacto, como o registro de uma nova chave de acesso ou a recuperação total da conta. Adicione uma MFA fora de banda.
- Eduque, não se Limite a Informar: Projete uma educação dos usuários que seja proativa, muito específica para as ameaças das chaves de acesso, e integrada diretamente nas funcionalidades de segurança da sua aplicação.
- Monitore Anomalias: Fique de olho nos seus registros para detectar padrões incomuns nas tentativas de registro de chaves de acesso, solicitações de recuperação e tickets de suporte associados. Os bots operam em larga escala e esses padrões emergirão.
- Não Esqueça as Bases: Enquanto se concentra nas chaves de acesso, não negligencie suas defesas fundamentais contra bots para outras partes da sua aplicação: limitação rigorosa de taxas, reputação de IP, análise comportamental e CAPTCHA quando apropriado. Os bots podem evoluir, mas ainda deixam rastros.
O futuro da autenticação é promissor, mas apenas se anteciparmos como os atores maliciosos tentarão contorná-la. Mantenha-se vigilante, fique seguro e nos vemos da próxima vez aqui em 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 Segurança de IA Hoje: Atualizações Urgentes & Perspectivas de Especialistas
“`
🕒 Published: