Minha luta de 2026: Bots & Autenticação por Engenharia Social

Olá a todos, Pat Reeves aqui, de volta ao botsec.net. Estamos em março de 2026, e tenho a impressão de que estamos em um constante cabo de guerra com ameaças alimentadas por bots. Logo quando você pensa que dominou um ângulo, outro surge. Hoje, quero falar sobre algo que não me deixa dormir à noite: a utilização cada vez mais sofisticada de bots na engenharia social, especialmente no que diz respeito à violação dos fluxos de autenticação. Não estamos mais falando apenas de stuffing simples de credenciais. Estamos falando de bots que se tornam estranhamente habilidosos em imitar a interação humana para contornar o MFA. Vamos chamar isso de “Social Bot-neering.”

Além da força bruta: o crescimento do Social Bot-neering na autenticação

Durante anos, quando falávamos sobre bots atacando a autenticação, nossa mente imediatamente ia para ataques de força bruta, stuffing de credenciais, ou talvez alguma maneira astuta de contornar CAPTCHA. Essas ameaças ainda existem, não se enganem. Mas ultimamente, observei uma tendência preocupante que vai além desses exploits puramente técnicos. Estamos testemunhando a evolução de bots projetados para interagir com usuários, ou até mesmo com a equipe de suporte técnico, de uma forma que os leva a abrir o acesso ou contornar as medidas de segurança.

Pense nisso. Investimos muito na autenticação de múltiplos fatores (MFA). Temos TOTP, notificações push, chaves FIDO – tudo isso é ótimo. Mas o que acontece quando o elo mais fraco não é a tecnologia, mas o humano do outro lado, convencido por um bot de que ele precisa “verificar” algo, ou pior, que está falando com um agente de suporte legítimo?

Meu próprio contato com um bot inteligente

Tive uma experiência pessoal sobre isso há alguns meses que realmente me abriu os olhos. Recebi uma mensagem de texto, aparentemente de meu banco. Dizia algo como: “Urgente: atividade incomum detectada em sua conta. Por favor, verifique as transações recentes em [link malicioso].” Agora, geralmente sou bastante bom em identificar phishing. O link parecia suspeito, e eu não cliquei. Mas então, cerca de 20 minutos depois, meu telefone tocou. Número desconhecido. Atendi, e era uma voz de IA surpreendentemente convincente, calma e profissional, alegando vir do departamento de fraude do meu banco, referindo-se à exata “atividade incomum” da mensagem.

Ela me pediu para confirmar minha identidade, não dando uma senha, mas “verificando um código enviado para meu telefone.” Recebi um SMS autêntico do meu banco com um código MFA legítimo, como se estivesse me conectando. O bot ao telefone então me pediu para ler esse código. Nesse momento, percebi. Não era apenas uma tentativa de phishing. Era um ataque coordenado. O bot havia iniciado uma tentativa de login na minha conta, acionado o MFA e agora tentava me manipular socialmente para que eu fornecesse o código. Se eu tivesse lido esse código em voz alta, eles teriam acessado. Foi terrivelmente eficaz.

Não era trabalho de um script kiddie. Era uma operação sofisticada, provavelmente controlada por uma fazenda de bots, capaz de iniciar tentativas de login, enviar SMS direcionados e, em seguida, executar um bot vocal alimentado por IA para extrair o MFA. Isso contornou todas as minhas proteções técnicas porque explorava minha confiança e meu senso de urgência.

Como os bots sociais contornam o MFA

Vamos decompor alguns dos vetores que estou observando:

1. Phishing MFA com um toque diferente

Foi o que me aconteceu. Os bots iniciam uma verdadeira conexão, acionando um pedido de MFA legítimo (SMS, notificação push, solicitação TOTP). Simultaneamente, o bot contata o usuário por outro canal (SMS, e-mail, chamada de voz) se passando por uma entidade confiável (banco, suporte de TI, plataforma de redes sociais). O bot então persuadiu o usuário a fornecer o código MFA, a aprovar a notificação push ou até a escanear um código QR malicioso.

# Pseudo-código simplificado para uma tentativa de phishing MFA controlada por um bot
function bot_orchestrate_mfa_phishing(target_user_id, bank_url, phishing_sms_template, ai_voice_script):
 # Etapa 1: Iniciar uma tentativa de login no serviço legítimo
 login_session = initiate_login(bank_url, target_user_id, known_password_or_stolen_credential)
 
 if login_session.requires_mfa():
 mfa_challenge_id = login_session.get_mfa_challenge_id()
 
 # Etapa 2: Enviar um SMS de phishing direcionado
 send_sms(target_user_id.phone_number, phishing_sms_template.format(bank_name="Seu Banco"))
 
 # Etapa 3: Iniciar uma chamada de voz com IA
 ai_call_session = make_ai_voice_call(target_user_id.phone_number, ai_voice_script)
 
 # Etapa 4: Durante a chamada, se o usuário fornecer o código MFA
 if ai_call_session.user_provides_mfa_code():
 mfa_code = ai_call_session.get_provided_mfa_code()
 
 # Etapa 5: Completar o login com o código MFA roubado
 if login_session.verify_mfa(mfa_challenge_id, mfa_code):
 log_compromise_and_access_account(login_session)
 else:
 log_failed_mfa_attempt()
 else:
 log_user_did_not_provide_mfa()
 else:
 log_no_mfa_required()

Não se trata mais apenas de uma página estática de phishing. É dinâmico, interativo, e utiliza a confiança existente do usuário em seus mecanismos de MFA.

2. Usurpação de identidade do suporte técnico e engenharia social

Os bots agora estão sendo usados para automatizar chamadas ou conversas com centros de atendimento. O bot, se passando por um usuário legítimo, pode alegar ter perdido seu telefone, esquecido sua senha ou estar bloqueado fora de sua conta. Eles terão informações pessoais suficientes (geralmente provenientes de violação de dados) para parecerem credíveis. O objetivo deles? Convencer um agente humano do suporte técnico a redefinir o MFA, registrar um novo dispositivo ou conceder acesso temporário. Vi relatos de bots gerando até “histórias tristes” ou expressando “frustração” para suscitar simpatia dos agentes.

# Script hipotético de bot para engenharia social no suporte técnico (abreviado)
def bot_helpdesk_interaction(target_user_info):
 dialogue_flow = [
 {"bot": "Olá, parece que não consigo acessar minha conta, ID {user_id}. Meu telefone está quebrado, e não consigo receber códigos MFA."},
 {"human_agent": "Entendo. Você pode me confirmar alguns detalhes?"},
 {"bot": "Claro. Meu nome completo é {full_name}, e minha data de nascimento é {dob}."},
 {"human_agent": "Certo, isso confere. Como você gostaria de proceder?"},
 {"bot": "Você poderia desativar o MFA temporariamente ou enviar um novo link de inscrição para meu e-mail de recuperação {backup_email}?"},
 # ... mais diálogos para persuadir o agente ...
 ]
 
 for turn in dialogue_flow:
 if "bot" in turn:
 send_message_to_helpdesk(turn["bot"].format(**target_user_info))
 wait_for_response()
 elif "human_agent" in turn:
 # Esta parte envolveria o processamento de linguagem natural para entender a resposta do agente
 # e selecionar a próxima resposta apropriada do bot
 pass 

É particularmente perigoso porque os agentes de suporte técnico são treinados para ajudar os usuários, e é difícil distinguir um humano em apuros de um bot bem programado, especialmente quando o bot tem uma boa história e detalhes pessoais exatos (roubados).

3. Tomada de controle de conta automatizada via fluxos de “Redefinição de senha”

Embora isso não seja estritamente um contorno do MFA, muitas vezes é um precursor. Os bots exploram fluxos de “senha esquecida” mal configurados. Se um sistema permitir muitas tentativas de redefinição de senha, ou se as perguntas de segurança forem facilmente adivinháveis (ou se as respostas forem encontradas em vazamentos de dados), os bots podem automatizar esse processo. Uma vez que eles redefinem a senha, podem então fazer login e enfrentar o desafio do MFA, momento em que poderão recorrer a uma das táticas de social bot-neering mencionadas acima.

Defendendo-se contra o Social Bot-neer

Então, o que fazemos? Não é apenas um problema técnico; é um problema humano, exacerbado pela tecnologia.

1. Educar, Educar, Educar (seus usuários E sua equipe)

• Para os usuários: Reforce o mantra “nunca compartilhe seu código MFA”. Enfatize que serviços legítimos *nunca* pedirão que você leia um código MFA ao telefone ou que o insira em um link que eles lhe enviaram. As notificações push devem sempre ser verificadas em relação à tentativa de login legítima que você iniciou. Deixe claro que, se não iniciaram uma conexão, devem recusar a solicitação.
• Para a equipe de suporte técnico: Isso é crítico. Treine-os rigorosamente sobre táticas de engenharia social. Forneça protocolos claros e não negociáveis para redefinições de MFA ou alterações de acesso à conta. Implemente uma verificação em múltiplas camadas para essas ações sensíveis (por exemplo, retornar uma ligação para um número registrado, exigir verificação presencial para contas de alto valor). Insista que um “desespero” ou uma “urgência” de um usuário nunca deve superar os protocolos de segurança.

2. Implementar uma detecção de bot mais forte na periferia e nos fluxos de autenticação

• Analítica comportamental: Procure por padrões incomuns. Um usuário está iniciando uma conexão de um novo endereço IP, imediatamente seguido por uma chamada ao suporte pedindo uma redefinição de MFA? Existem várias tentativas de login falhadas seguidas de uma bem-sucedida após uma interação “suporte”?
• Limitação de taxa e regulação: Isso ainda ajuda. Limite o número de tentativas de login, redefinições de senha, ou desafios de MFA que podem ser iniciados de um único IP ou para um único usuário em um determinado período de tempo.
• Impressão do dispositivo: Se uma conexão é tentada de um dispositivo não reconhecido, mesmo que o MFA seja fornecido, isso deve acionar um alerta mais significativo.
• Mecanismos de desafio-resposta: Além do CAPTCHA, considere desafios para bots mais sofisticados antes mesmo de permitir que uma tentativa de login seja feita ou que um desafio de MFA seja emitido.

3. Modernizar as opções de MFA (e eliminar as mais fracas)

• Progrida além dos SMS OTP: Os SMS são notoriamente vulneráveis a troca de SIM e interceptação. As notificações push com informações contextuais (por exemplo, “Tentativa de login de Nova Iorque, iPhone 15 Pro”) são melhores, mas ainda estão sujeitas à engenharia social.
• Chaves de segurança físicas (FIDO2/WebAuthn): Essas são muito mais resistentes ao phishing e à engenharia social, pois a chave verifica a origem da solicitação de conexão de maneira criptográfica. O usuário não digita um código; ele simplesmente confirma sua presença no site correto. Essa é minha escolha pessoal para contas críticas.
• Biometria: Embora não seja uma solução milagrosa, combinar biometria com uma autenticação sólida dos dispositivos adiciona uma camada adicional de atrito para os atacantes.

4. Políticas rigorosas de recuperação de conta

Reavalie seus processos de recuperação de conta. As perguntas de segurança são fáceis demais? É muito simples para alguém provar sua identidade por telefone? Implemente uma verificação em várias etapas para recuperação de conta, exigindo potencialmente documentos, chamadas de vídeo ou presença física para contas sensíveis.

O caminho a seguir

A corrida armamentista entre os profissionais de segurança e os bots maliciosos está se acelerando. À medida que nossas defesas técnicas melhoram, os atacantes simplesmente deslocam sua atenção para o elemento humano, utilizando bots sofisticados para amplificar seus esforços de engenharia social. Não é mais suficiente bloquear IPs ou detectar preenchimento de credenciais. Precisamos pensar como os atacantes, entender suas táticas em evolução e construir defesas resilientes tanto contra explorações técnicas quanto sociais.

Meu conselho? Pressupõe que os bots se tornem mais inteligentes. Pressupõe que eles sejam capazes de manter conversas convincentes. E então, construa suas defesas – tanto tecnológicas quanto humanas – com essa hipótese em mente. Mantenha-se vigilante, mantenha-se seguro!

Pat Reeves terminado.

🕒 Published: March 31, 2026