Olá a todos, Pat Reeves aqui, novamente no botsec.net. É março de 2026 e, se você é como eu, provavelmente ainda está chocado pela pura audácia de algumas das atividades de botnets que vimos no ano passado. Enquanto os grandes títulos se concentravam nos ataques DDoS e na exfiltração de dados, algo mais esteve silenciosamente fervilhando sob a superfície, algo que, francamente, me mantém acordado à noite: as táticas cada vez mais sofisticadas que os bots estão usando para contornar os métodos tradicionais de autenticação, especialmente com o aumento das passkeys.
Disseram-nos que as passkeys são o futuro, certo? Resistentes a phishing, criptograficamente seguras, ligadas a dispositivos. E por boas razões, elas abordam muitos pontos críticos do passado. Mas o que acontece quando justamente o 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, acima de tudo, em 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 (as senhas) e requerem interação do usuário em um dispositivo confiável. Ótimo! Nada mais de credential stuffing, nada mais de spraying, nada mais de ataques de dicionário simples. Mas os bots, abençoados sejam seus coraçõezinhos digitais persistentes, não desistem facilmente. Eles se adaptam. E o que eu vi, especialmente nas tentativas de takeover de contas (ATO) em plataformas que abraçaram completamente as passkeys, é uma mudança para a engenharia social em larga escala, armada pela automação.
Minha recente experiência com um cliente, uma plataforma de e-commerce de tamanho médio que apostou tudo nas passkeys no verão passado, realmente abriu meus olhos. Eles notaram uma enorme diminuição nos ataques tradicionais baseados em credenciais, o que foi ótimo. Mas então, cerca de três meses atrás, 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 de dispositivos não reconhecidos, muitas vezes seguidas por uma série de solicitações de suporte de usuários legítimos que afirmavam que suas contas estavam prestes a ser “hackeadas” apesar de terem ativado as passkeys.
O que descobrimos foi um ataque em múltiplas fases. 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 forçando-os a restaurar as existentes. É uma variação do clássico “aprovar este login” da fadiga de MFA, mas com riscos maiores porque uma passkey comprometida significa controle total da conta.
Desvio das Passkeys Guiado por Bots: Como Funciona
Analisemos o novo manual dos bots para comprometimento de passkeys. Não se trata de força; trata-se de sofisticada engenharia social 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 para endereços de email e números de telefone. Depois cruzam esses dados com as plataformas alvo. O objetivo não é obter uma senha, mas identificar usuários ativos.
- A isca do “Novo Dispositivo”: Um bot, frequentemente imitando um navegador legítimo ou um app móvel, tenta iniciar um acesso ou um registro da passkey para um usuário conhecido na plataforma alvo. Como o usuário não possui uma passkey registrada naquele dispositivo específico (o ambiente simulado do bot), a plataforma muitas vezes solicita um método de verificação alternativo ou de “adicionar uma nova passkey.”
- Engenharia Social Automatizada (ASE): Aqui é onde a mágica acontece (ou melhor, a ameaça). O bot, tendo ativado uma legítima notificação de sistema (email, SMS, notificação push do próprio app), imediatamente segue com uma tentativa de phishing direcionada. Não é um email genérico para “redefinir sua senha”. É altamente contextual.
Imagine este cenário:
- Receba uma notificação push legítima do seu aplicativo bancário: “Tentativa de registrar uma nova chave de acesso detectada de um dispositivo desconhecido. Se foi você, aprove. Caso contrário, clique aqui para proteger sua conta.”
- Ao mesmo tempo, você recebe um e-mail meticulosamente elaborado, aparentemente da equipe de segurança do seu banco, com um assunto como: “Urgência: Registro de Chave de Acesso Não Autorizado Detectado – Ação Requerida.”
- O conteúdo do e-mail é personalizado, talvez até se referindo ao horário específico da tentativa de registro. Ele te direciona para uma página de phishing que parece idêntica ao portal de segurança do seu banco.
- Nessa página de phishing, é solicitado que você “verifique sua identidade” inserindo sua senha antiga (se o banco ainda a suporta para recuperação), ou, de forma mais insidiosa, “revogue chaves de acesso não autorizadas”, que na verdade te convida a *registrar uma nova chave de acesso* no dispositivo do atacante, disfarçada como uma medida de segurança.
A chave aqui é o *tempo* e o *contexto*. Os bots coordenam essas ações em grande escala, atacando milhares de usuários ao mesmo tempo. O usuário, vendo uma notificação legítima do aplicativo e um e-mail muito convincente e oportuno, está muito mais propenso a cair na armadilha em comparação a uma fraude de phishing genérica.
Estratégias Defensivas Práticas Contra o Abuso das Chaves de Acesso Guiado por Bots
Então, o que podemos fazer? Não podemos eliminar as chaves de acesso; elas ainda são um enorme avanço. Mas precisamos ser mais inteligentes sobre como as implementamos e as protegemos. Aqui estão algumas coisas que recomendei aos clientes, com alguns exemplos práticos.
1. Reforce Seu Fluxo de Registro das “Novas Chaves de Acesso”
Esta é a vulnerabilidade mais crítica. Se um atacante conseguir enganar um usuário a registrar uma nova chave de acesso no seu próprio dispositivo, já era. Você precisa de mais níveis de verificação aqui, além do simples prompt inicial da chave de acesso.
- Segundo Fator Obrigatório para Novos Registros: Mesmo que um usuário já esteja logado, é crucial solicitar uma verificação adicional, fora de banda (como um código temporário enviado para um número de telefone ou um e-mail *pré-registrado*, não um fornecido durante a tentativa de registro) para *qualquer* novo registro ou substituição de chave de acesso.
- Atestação do Dispositivo (onde possível): Embora não seja infalível, incorporar controles de atestação do dispositivo durante o registro das chaves de acesso pode ajudar a filtrá-los de máquinas virtuais ou emuladores óbvios que os bots possam usar. Não se trata de bloquear usuários legítimos, mas de adicionar atrito para ambientes de atacantes conhecidos.
- Limitação de Taxas e Detecção de Anomalias: Esta é a defesa clássica contra bots, mas aqui é ainda mais aplicável. Limitações agressivas nas tentativas de registro das chaves de acesso de IPs únicos ou intervalos de IP, junto com detecção comportamental de anomalias (por exemplo, um usuário que tenta repentinamente registrar 5 novas chaves de acesso em uma hora de diferentes localizações geográficas), podem sinalizar atividades suspeitas.
// Exemplo: Pseudocódigo para um fluxo sólido de registro de novas chaves de acesso
function registerNewPasskey(userId, webauthnCredential) {
// 1. Confira a sessão existente e força de autenticação
if (!isAuthenticatedStrongly(userId)) {
// Force uma nova autenticação ou MFA adicional
initiateMFAChallenge(userId, "new_passkey_registration");
return; // Aguarde a conclusão do MFA
}
// 2. Execute a validação de atestação FIDO2
if (!validateWebAuthnAttestation(webauthnCredential)) {
logSecurityAlert(userId, "Atestação WebAuthn inválida durante o registro da nova chave de acesso");
return;
}
// 3. Opcional: Verificação de impressão digital/atestação do dispositivo (lado servidor)
if (isSuspiciousDeviceFingerprint(request.headers['User-Agent'], request.ip)) {
logSecurityAlert(userId, "Impressão digital do dispositivo suspeita para o registro da nova chave de acesso");
initiateMFAChallenge(userId, "suspicious_device_new_passkey");
return;
}
// 4. Verificação de limitação de taxas para novas chaves de acesso por usuário/IP
if (rateLimitExceeded("new_passkey_registration", userId, request.ip)) {
logSecurityAlert(userId, "Limite de taxa excedido para registro de nova chave de acesso");
return;
}
// 5. Armazene a nova credencial da chave de acesso
storeUserPasskey(userId, webauthnCredential);
sendUserNotification(userId, "Nova chave de acesso registrada com sucesso.");
}
2. Melhore os Processos de Recuperação de Contas
A recuperação de contas é outro objetivo principal. Se um atacante pode iniciar um fluxo de recuperação e depois enganar o usuário para aprová-lo, ele tem uma porta de acesso.
- Atrasar a Recuperação da Conta: Implemente um período de espera obrigatório (por exemplo, 24-48 horas) para ações críticas de recuperação da conta, especialmente aquelas que envolvem a substituição de todas as chaves de acesso existentes. Durante esse tempo, notifique o usuário de forma agressiva através de todos os canais de comunicação conhecidos. Isso dá ao usuário legítimo a oportunidade de intervir.
- Verificação de Vídeo KYC ou de Agente ao Vivo para Recuperação Completa: Para situações em que um usuário perdeu todas as chaves de acesso e outros métodos de recuperação, considere solicitar uma verificação de vídeo ao vivo com um agente de suporte. É uma solução de alta fricção, mas para contas críticas, é um forte dissuasor contra a engenharia social automatizada.
- Chave de Acesso “Break Glass”: Para contas administrativas internas ou sistemas altamente sensíveis, considere ter uma chave de acesso física “break glass” guardada em um local seguro e auditado, que requer várias aprovações para ser utilizada. Isso não é para contas de consumidores, mas para objetivos de alto valor, é imprescindível.
3. Educação de Usuários que Funciona de Verdade
Temos feito “educação de usuários” por décadas e, honestamente, grande parte dela falha. Para as chaves de acesso, precisamos de orientações direcionadas, oportunas e específicas.
- Guia “O Que Esperar”: Explique claramente aos usuários quais são as notificações e os processos de recuperação das chaves de acesso legítimas. Mostre imagens de tela.
- Alertas “O Que NÃO Fazer”: Alerta especificamente os usuários para não aprovarem registros de chaves de acesso que não iniciaram, ou para não clicarem em links em e-mails que afirmam “revogar” chaves de acesso, especialmente se não tentaram uma ação de segurança recentemente.
- Controles de Segurança no Aplicativo: Forneça uma seção facilmente acessível no seu aplicativo ou site onde os usuários possam visualizar todas as chaves de acesso registradas, sua origem (se possível) e revogá-las. Mantenha tudo simples e intuitivo.
// Exemplo: Aviso no aplicativo para atividades suspeitas
function displaySuspiciousActivityWarning(userId, activityDetails) {
const warningMessage = `
⚠ Atividade Suspeita Detectada!
Detectamos uma tentativa de registrar uma nova chave de acesso para sua conta a partir de um dispositivo não reconhecido (${activityDetails.ipAddress} - ${activityDetails.location}) às ${activityDetails.timestamp}.
Se você foi, pode ignorar esta mensagem. Se NÃO foi você, por favor, aja imediatamente:
- Vá para suas Configurações de Segurança para revisar e revogar as chaves de acesso.
- Mude seus outros métodos de recuperação (por exemplo, senha de e-mail).
- Entre em contato com o suporte se precisar de assistência.
`;
document.getElementById('security-alert-banner').innerHTML = warningMessage;
document.getElementById('security-alert-banner').style.display = 'block';
}
Esse tipo de aviso direto no aplicativo, ativado pela mesma atividade de bots contra a qual estamos tentando nos proteger, pode ser incrivelmente eficaz.
Dicas Práticas para Profissionais de Segurança de Bots
O panorama dos ataques de bots está sempre em evolução. As chaves de acesso são fantásticas, mas não são uma solução única, e os atacantes já estão encontrando novas maneiras de explorar o elemento humano ao redor delas. Aqui está minha lista de verificação para você:
- Audite seus Fluxos de Passkey: Examine cada fluxo relacionado às passkeys – registro, acesso, recuperação, revogação – com a mentalidade de um atacante bot. Onde um bot pode interferir com engenharia social?
- A Verificação em Nível é Fundamental: Nunca confie em um único fator para ações de alto impacto, como o registro de novas passkeys ou a recuperação completa da conta. Adicione MFA fora de banda.
- Eduque, Não Apenas Informe: Projete uma educação para os usuários que seja proativa, muito específica sobre as ameaças relacionadas às passkeys e integrada diretamente nas funcionalidades de segurança da sua aplicação.
- Monitore por Anomalias: Fique de olho em seus logs para padrões incomuns nas tentativas de registro das passkeys, nas solicitações de recuperação e nos tickets de suporte dos usuários relacionados a esses. Os bots operam em grande escala e esses padrões aparecerão.
- Não Se Esqueça do Básico: Enquanto você se concentra nas passkeys, não negligencie suas defesas básicas contra bots em outras partes da sua aplicação: controle rigoroso de taxas, reputação IP, análise comportamental e CAPTCHA onde for apropriado. Os bots podem evoluir, mas ainda deixam rastros.
O futuro da autenticação é promissor, mas apenas se anteciparmos como os atores mal-intencionados tentarão subvertê-lo. Mantenha-se alerta, mantenha-se seguro, e nos vemos da próxima vez aqui em botsec.net.
Artigos Relacionados
- Proteção da privacidade dos dados dos bots AI
- Minha opinião: OmniMind AI é um pesadelo de segurança
- Notícias sobre Segurança AI Hoje: Atualizações Urgentes & Insights de Especialistas
🕒 Published: