Bom dia a todos, Pat Reeves aqui, novamente no botsec.net. Estamos em março de 2026, e se você é como eu, provavelmente ainda está um pouco chocado com a audácia de algumas das atividades dos botnets que observamos no ano passado. Enquanto os principais títulos se concentravam em ataques DDoS e na exfiltração de dados, algo mais surgiu silenciosamente, algo que, francamente, 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 a ascensão das passkeys.
Nos dizem que as passkeys são o futuro, certo? Resistentes a phishing, criptograficamente seguras, ligadas a um dispositivo. E por boas razões, elas atendem 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 pelo modo como é implementado e, principalmente, por 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 segredos compartilhados (as senhas) e requerem uma interação do usuário em um dispositivo de confiança. Ótimo! Chega de credential stuffing, chega de spraying, chega de ataques simples por dicionário. Mas os bots, como se chamam, não se deixam desencorajar. Eles se adaptam. E o que eu observei, em particular nas tentativas de takeover de contas (ATO) em plataformas que adotaram completamente as passkeys, é uma mudança rumo à engenharia social em larga escala, potencializada pela automação.
Minha experiência recente com um cliente, uma plataforma de e-commerce de médio porte que adotou completamente as passkeys no verão passado, realmente abriu meus olhos. Eles registraram uma enorme queda nos ataques baseados em credenciais tradicionais, o que é fantástico. Mas então, cerca de três meses atrás, eles começaram a notar um aumento nos tentativas de “acesso não autorizado” que eram… diferentes. Não eram erros de senha; eram tentativas de iniciar o registro ou a recuperação de passkeys de dispositivos não reconhecidos, muitas vezes seguidas por uma frenesí de pedidos de suporte de usuários legítimos que afirmavam que suas contas haviam sido “hackeadas” apesar da ativação das passkeys.
O que descobrimos foi um ataque em várias fases. Os bots não estavam tentando adivinhar as passkeys; eles tentavam enganar os usuários para que *gerassem* ou *aprovassem* novas passkeys em dispositivos controlados pelo atacante, ou forçá-los a redefinir as existentes. É uma variação da velha fadiga relacionada ao MFA do tipo “aprova esta conexão”, mas com apostas mais altas porque uma passkey comprometida significa controle total da conta.
Desvio de Passkeys por Bots: Como Funciona
Vamos analisar o novo manual dos bots para a compromissão de 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 fuçam em dados públicos, redes sociais e até em dumps da dark web por endereços de e-mail e números de telefone. 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 app 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 possui uma passkey registrada em este dispositivo específico (o ambiente simulado do bot), a plataforma frequentemente solicita um método de verificação alternativo ou de “adicionar uma nova passkey”.
- Engenharia Social Automática (ASE): É aqui que acontece a mágica (ou melhor, a ameaça). O bot, após ativar uma notificação de sistema legítima (e-mail, SMS, notificação push do próprio app), segue imediatamente com uma tentativa de phishing direcionada. Não se trata de um e-mail genérico para “recuperar sua senha”. É altamente contextual.
Imagine este cenário:
“`html
- Receba uma notificação push legítima do seu aplicativo bancário: “Tentativa de registro de nova chave de acesso detectada de um dispositivo desconhecido. Se for você, aprove. Caso contrário, clique aqui para proteger sua conta.”
- Simultaneamente, receba um e-mail meticulosamente projetado, aparentemente da equipe de segurança do banco, com um assunto como: “Urgente: Registro de chave de acesso não autorizada detectada – Ação necessária.”
- O conteúdo do e-mail é direcionado, talvez fazendo referência ao horário específico da tentativa de registro. Ele redireciona você 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 suportar para recuperação), ou, mais sutilmente, a “revogar as chaves de acesso não autorizadas”, o que na verdade o induz a *registrar uma nova chave de acesso* 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 simultaneamente. O usuário, ao ver 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 de Defesa Práticas Contra o Abuso das Chaves de Acesso pelos Bots
Então, o que podemos fazer? Não podemos abandonar as chaves de acesso; elas ainda representam um enorme progresso. Mas precisamos ser mais inteligentes sobre como as distribuímos e protegemos. Aqui estão algumas dicas que eu dei para meus clientes, com alguns exemplos práticos.
1. Reforce Seu Fluxo de Registro de “Nova Chave de Acesso”
Esta é a vulnerabilidade mais crítica. Se um atacante conseguir convencer um usuário a registrar uma nova chave de acesso em seu dispositivo, é o fim. Você precisa de mais níveis de verificação aqui, além do simples prompt inicial de chave de acesso.
- Segundo fator obrigatório para novos registros: Mesmo que um usuário já esteja conectado, solicitar uma verificação adicional fora de banda (como um código único enviado para um número de telefone ou um endereço de e-mail *pré-registrados*, não aquele fornecido durante a tentativa de registro) para *qualquer* novo registro ou substituição de chave de acesso é 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 chave de acesso pode ajudar a filtrar máquinas virtuais ou emuladores evidentes que os bots possam usar. Não se trata de bloquear usuários legítimos, mas de adicionar fricções para os ambientes conhecidos dos atacantes.
- Limites de Frequência e Detecção de Anomalias: Isso faz parte da defesa clássica contra bots, mas se aplica ainda mais aqui. Uma limitação de frequência agressiva nos tentativas de registro de chaves de acesso provenientes de endereços IP únicos ou intervalos de IP, combinada com a detecção de anomalias comportamentais (por exemplo, um usuário que de repente tenta registrar 5 novas chaves de acesso em uma hora a partir de diferentes locais geográficos), 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. Verificação da sessão existente e da força da autenticação
if (!isAuthenticatedStrongly(userId)) {
// Forçar a re-autenticação ou adicionar 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 chave de acesso”);
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 chave de acesso”);
initiateMFAChallenge(userId, “suspicious_device_new_passkey”);
return;
}
// 4. Verificação do limite de frequência para novas chaves de acesso por usuário/IP
if (rateLimitExceeded(“new_passkey_registration”, userId, request.ip)) {
logSecurityAlert(userId, “Limite de frequência excedido para o registro da 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 é outra área de vulnerabilidade. Se um atacante pode iniciar um fluxo de recuperação e então manipular o usuário para aprová-lo, ele tem uma porta de acesso.
- 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 chaves de acesso existentes. Durante esse tempo, informe proativamente o usuário através de todos os canais de comunicação conhecidos. Isso oferece ao usuário legítimo a oportunidade de intervir.
- Verificação KYC por Vídeo ou Agente ao Vivo para Redefinição Completa: 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 de vídeo ao vivo com um agente de suporte. É uma solução que exige mais esforço, mas para contas críticas é um potente dissuasor contra engenharia social automatizada.
- Chave de Acesso “Quebra de Vidro”: Para contas administrativas internas ou sistemas altamente sensíveis, considere ter uma chave de acesso física “quebra de vidro” armazenada em um local seguro e auditado, exigindo mais aprovações para ser utilizada. Isso não é para contas de consumidores, mas para contas de alto valor, é indispensável.
3. Conscientização dos Usuários que Funciona de Verdade
Fazemos “conscientização dos usuários” há décadas e, honestamente, na maioria das vezes não funciona. Para as chaves de acesso, precisamos de instruções direcionadas, oportunas e específicas.
- “Guias sobre o que esperar”: Explique claramente aos usuários como aparecem as notificações e os processos de recuperação da chave de acesso legítimos. Mostre capturas de tela.
- “Alertas sobre o que NÃO fazer”: Avise especificamente os usuários para não aprovar registros de chaves de acesso que não iniciaram, nem clicar em links em e-mails que afirmam “revogar” chaves de acesso, especialmente se não tentaram recentemente realizar uma ação de segurança.
- Verificações de segurança na aplicação: Forneça uma seção fácil de encontrar em sua aplicação 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.
“`html
// Exemplo: Aviso no app 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}) às ${activityDetails.timestamp}.
Se você foi, pode ignorar com segurança. Se NÃO foi você, por favor, aja imediatamente:
- Vá em suas Configurações de segurança para revisar e revogar as chaves de acesso.
- Altere seus outros métodos de recuperação (por exemplo, senha de e-mail).
- Entre em contato com o suporte se precisar de ajuda.
“““html
`;
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.
Lições práticas para profissionais de segurança de bots
O campo dos ataques de bots está em constante evolução. As chaves de acesso são ótimas, mas não são uma solução única, e os atacantes já encontram novas maneiras de explorar o elemento humano que as rodeia. Aqui está minha lista de ações para vocês:
- Auditem seus fluxos de chaves de acesso: Examine cada fluxo relacionado às chaves de acesso – registro, login, recuperação, revogação – com a mentalidade de um atacante de bot. Onde um bot poderia interceptar engenharia social?
- A verificação multifator é fundamental: Nunca conte apenas com um único fator para ações de alto impacto como o registro de uma nova chave de acesso ou a recuperação completa de uma conta. Adicione uma MFA fora de banda.
- Eduque, não se limite a informar: Projete uma instrução para os usuários que seja proativa, altamente específica para as ameaças das chaves de acesso, e integrada diretamente nas funcionalidades de segurança de sua aplicação.
- Monitore as anomalias: Fique de olho em seus logs para detectar padrões incomuns nas tentativas de registro de chaves de acesso, nas solicitações de recuperação e nos tickets de suporte associados. Os bots operam em grande escala e esses padrões irão emergir.
- Não negligencie as bases: Enquanto você se concentra nas chaves de acesso, não esqueça suas defesas fundamentais contra bots para outras partes de sua aplicação: limitação rigorosa de frequência, reputação de IP, análise comportamental e CAPTCHA onde apropriado. Os bots podem evoluir, mas sempre deixam rastros.
O futuro da autenticação é promissor, mas apenas se anteciparmos como os atores mal-intencionados tentarão subvertê-lo. Mantenha-se vigilante, fique seguro, e até a próxima aqui no botsec.net.
Artigos relacionados
- Proteção da privacidade dos dados dos bots IA
- Minha opinião: OmniMind IA é um pesadelo de segurança
- Notícias sobre a segurança da IA hoje: Atualizações urgentes & Prospetivas de especialistas
“`
🕒 Published: