Oi pessoal, Pat Reeves aqui, de volta no botsec.net. É março de 2026 e, se você é como eu, provavelmente ainda está um pouco atordoado com a ousadia de algumas das atividades de botnet que vimos no ano passado. Enquanto as grandes manchetes se concentravam nos ataques DDoS e na exfiltração de dados, algo mais vem borbulhando discretamente sob a superfície, algo que, francamente, não me deixa dormir à noite: as táticas cada vez mais sofisticadas que os bots estão usando para contornar métodos tradicionais de autenticação, especialmente com o aumento das passkeys.
Nos disseram que as passkeys são o futuro, certo? Resistentes a phishing, criptograficamente seguras, vinculadas a dispositivos. E com boas razões, elas abordam muitos problemas antigos. Mas o que acontece quando o próprio mecanismo projetado para nos proteger se torna um vetor para comprometimento, não por uma falha na criptografia em si, mas na forma como é implementado e, crucialmente, em como os bots aprendem a manipular o elemento humano ao redor disso?
O Paradoxo da Passkey: Uma Nova Fronteira para Bots
Pense nisso. A promessa das passkeys é que elas eliminam segredos compartilhados (senhas) e exigem interação do usuário em um dispositivo confiável. Ótimo! Sem mais preenchimento de credenciais, sem mais ataques de spray, sem mais ataques simples de dicionário. Mas os bots, abençoados sejam seus corações digitais persistentes, não se rendem facilmente. Eles se adaptam. E o que tenho visto, particularmente em tentativas de takeover de contas (ATO) em plataformas que adotaram completamente as passkeys, é uma mudança em direção à engenharia social em larga escala, armada pela automação.
Minha própria experiência recente com um cliente, uma plataforma de e-commerce de médio porte que investiu totalmente nas passkeys no último verão, realmente abriu meus olhos. Eles notaram uma queda maciça em ataques tradicionais baseados em credenciais, 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 da passkey a partir de dispositivos não reconhecidos, muitas vezes seguidas por uma enxurrada de solicitações de suporte de usuários legítimos afirmando que suas contas estavam sendo “hackeadas” apesar de terem as passkeys ativadas.
O que descobrimos foi um ataque em múltiplas etapas. Os bots não estavam tentando adivinhar as passkeys; estavam tentando enganar os usuários para *gerar* ou *aprovar* novas passkeys em dispositivos controlados pelos atacantes, ou coagi-los a redefinir as existentes. É uma reviravolta na velha fadiga de MFA de “aprovar este login”, mas com maiores riscos porque uma passkey comprometida significa controle total da conta.
Sequestros de Passkey Impulsos por Bots: Como Funciona
Vamos detalhar o novo manual de estratégias de bots para comprometer passkeys. Não se trata de força bruta. Trata-se de engenharia social sofisticada em larga escala, amplificada pela automação.
- Reconhecimento e Spear-Phishing Leve: Os bots coletam dados públicos, redes sociais e até dumps da dark web em busca de endereços de e-mail e números de telefone. Eles então cruzam essas informações com plataformas-alvo. 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 aplicativo móvel, tenta iniciar um login ou registro de passkey para um usuário conhecido na plataforma-alvo. Como o usuário não tem uma passkey registrada naquele dispositivo específico (o ambiente simulado do bot), a plataforma geralmente pede 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 legítima do sistema (e-mail, SMS, notificação por push do próprio aplicativo), imediatamente a segue com uma tentativa de phishing direcionada. Este não é um e-mail genérico de “redefina sua senha”. É altamente contextual.
Imagine este cenário:
- Você recebe uma notificação de push legítima do seu aplicativo bancário: “Tentativa de registro de nova passkey detectada de um dispositivo desconhecido. Se foi você, aprove. Se não, 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 Necessária.”
- O conteúdo do e-mail é adaptado, talvez até mencionando a hora específica da tentativa de registro. Ele direciona você para uma página de phishing que parece idêntica ao 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 suporta para recuperação), ou, de maneira mais insidiosa, a “revogar passkeys não autorizadas”, o que, na verdade, o leva a *registrar uma nova passkey* no dispositivo do atacante, disfarçado como uma 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 ao mesmo tempo. O usuário, ao ver uma notificação legítima do aplicativo e um e-mail muito convincente e oportuno, tem muito mais chances de cair na armadilha do que em um golpe genérico de phishing.
Estratégias Práticas de Defesa Contra o Abuso de Passkeys Impulsionado por Bots
Então, o que podemos fazer? Não podemos descartar as passkeys; elas ainda são um enorme avanço. Mas precisamos ser mais inteligentes sobre como as implementamos e protegemos. Aqui estão algumas coisas que tenho aconselhado os clientes, com alguns exemplos práticos.
1. Fortalecer Seu Fluxo de Registro de “Nova Passkey”
Esta é a vulnerabilidade mais crítica. Se um atacante conseguir enganar um usuário para registrar uma nova passkey em seu dispositivo, acabou. Você precisa de várias camadas de verificação aqui, além do simples prompt inicial da passkey.
- Segundo Fator Obrigatório para Novos Registros: Mesmo que um usuário já esteja conectado, exigir uma verificação adicional fora da banda (como um código de uso único enviado para um número de telefone ou e-mail *pré-registrado*, não um fornecido durante a tentativa de registro) para *qualquer* novo registro ou substituição de passkey é crucial.
- Atestação de Dispositivo (quando possível): Embora não seja à prova de falhas, incorporar verificações de atestação de dispositivo durante o registro de passkey pode ajudar a filtrar máquinas virtuais ou emuladores óbvios que os bots possam estar usando. Isso não se trata de bloquear usuários legítimos, mas de adicionar atrito a ambientes conhecidos de atacantes.
- Limitação de Taxa e Detecção de Anomalias: Isso é defesa clássica contra bots, mas se aplica ainda mais aqui. Limitação agressiva da taxa em tentativas de registro de passkey a partir de IPs ou intervalos de IP únicos, juntamente com a detecção de anomalias comportamentais (por exemplo, um usuário tentando registrar repentinamente 5 novas passkeys em uma hora de diferentes locais geográficos), pode sinalizar atividade suspeita.
// Exemplo: Pseudocódigo para um fluxo sólido de registro de nova passkey
function registerNewPasskey(userId, webauthnCredential) {
// 1. Verifique a sessão existente e a força da autenticação
if (!isAuthenticatedStrongly(userId)) {
// Force re-autenticação ou MFA adicional
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Aguarde a conclusão da MFA
}
// 2. Realize a validação de atestação FIDO2
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Atestação WebAuthn inválida durante o registro da nova passkey");
return;
}
// 3. Opcional: Verificação de impressão digital/atestação de dispositivo (lado do servidor)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Impressão digital de dispositivo suspeita para registro de nova passkey");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Verificar limitação 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 credencial de passkey
storeUserPasskey(userId, webauthnCredential);
sendUserNotification(userId, "Nova passkey registrada com sucesso.");
}
2. Aprimorar Processos de Recuperação de Conta
A recuperação de conta é outro alvo principal. Se um atacante conseguir iniciar um fluxo de recuperação e, em seguida, usar engenharia social para que o usuário a aprove, ele terá uma backdoor.
- 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 passkeys existentes. Durante esse tempo, notifique o usuário de forma agressiva por todos os canais de comunicação conhecidos. Isso dá ao usuário legítimo uma chance de intervir.
- Verificação de KYC por Vídeo ou Verificação com Agente Ao Vivo para Redefinição Completa: Para situações em que o usuário perdeu todas as 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 com alto atrito, mas para contas críticas, é um forte impedimento contra engenharia social automatizada.
- Passkeys “Quebrar Vidro”: Para contas administrativas internas ou sistemas altamente sensíveis, considere ter uma passkey física “quebrar vidro” armazenada em um local seguro e auditável, exigindo múltiplas aprovações para uso. Isso não se aplica a contas de consumidores, mas é imprescindível para alvos de alto valor.
3. Educação do Usuário Que Realmente Funciona
Temos feito “educação do usuário” por décadas e, honestamente, a maior parte falha. Para passkeys, precisamos de orientações direcionadas, oportunas e específicas.
- “Guias do que Esperar”: 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.
- “Alertas do que NÃO Fazer”: Alerta especificamente os usuários sobre a aprovação de registros de passkey que eles não iniciaram, ou clicar em links de e-mails que afirmam “revogar” passkeys, especialmente se eles não tentaram uma ação de segurança recentemente.
- Verificações de Segurança no App: Forneça uma seção fácil de encontrar no seu aplicativo ou site onde os usuários possam visualizar todas as passkeys registradas, sua origem (se possível) e revogá-las. Mantenha simples e intuitivo.
// Exemplo: Aviso no app para atividade suspeita
function displaySuspiciousActivityWarning(userId, activityDetails) {
const warningMessage = `
⚠ Atividade Suspeita Detectada!
Detectamos uma tentativa de registrar 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 isso com segurança. Se NÃO foi você, por favor, tome uma ação imediatamente:
- Vá para suas Configurações de Segurança para revisar e revogar passkeys.
- Altere seus outros métodos de recuperação (por exemplo, senhas 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 app, acionado pela mesma atividade de bot que estamos tentando defender, pode ser extremamente eficaz.
Lições Práticas para Profissionais de Segurança de Bots
O espaço de ataques de bots está sempre mudando. As passkeys são ótimas, mas não são uma solução mágica, e os atacantes já estão encontrando novas formas de explorar o elemento humano ao redor delas. Aqui está minha lista de tarefas para você:
- Audite seus Fluxos de Passkeys: Passe por cada fluxo relacionado a passkey – registro, login, recuperação, revogação – com a mentalidade de um atacante de bot. Onde um bot pode intervir com engenharia social?
- Verificação em Camadas é Fundamental: Nunca confie em um único fator para ações de alto impacto, como registro de nova passkey ou recuperação total de conta. Adicione MFA fora de banda.
- Eduque, Não Apenas Informe: Crie uma educação para usuários que seja proativa, altamente específica sobre ameaças de passkeys, e integrada diretamente nas funcionalidades de segurança da sua aplicação.
- Monitore por Anomalias: Fique atento aos seus logs para padrões incomuns em tentativas de registro de passkeys, solicitações de recuperação e tickets de suporte ao usuário relacionados a isso. Bots operam em escala, e esses padrões aparecerão.
- Não Esqueça o Básico: Enquanto se concentra nas passkeys, não neglecte suas defesas fundamentais contra bots em outras partes da sua aplicação: limitação de taxa forte, reputação de IP, análise comportamental e CAPTCHAs quando apropriado. Os bots podem estar evoluindo, mas ainda deixam rastros.
O futuro da autenticação é forte, mas somente se anteciparmos como os maus atores tentarão subvertê-lo. Mantenha-se vigilante, mantenha-se seguro, e nos encontramos na próxima vez aqui no botsec.net.
Artigos Relacionados
- Proteção de privacidade de dados de bots de IA
- Minha Opinião: OmniMind AI é um Pesadelo de Segurança
- Notícias de Segurança de IA Hoje: Atualizações Urgentes & Insights de Especialistas
🕒 Published: