\n\n\n\n Mon combat de 2026 : Bots & Autenticação por Engenharia Social - BotSec \n

Mon combat de 2026 : Bots & Autenticação por Engenharia Social

📖 11 min read2,070 wordsUpdated Mar 31, 2026

Olá a todos, Pat Reeves aqui, de volta no botsec.net. Estamos em março de 2026, e tenho a impressão de que estamos envolvidos em uma luta sem fim contra ameaças impulsionadas por bots. Justo quando você acha que dominou um aspecto, outro aparece. Hoje, quero falar sobre algo que não me deixa dormir à noite: o uso cada vez mais sofisticado de bots em engenharia social, especialmente quando se trata de contornar fluxos de autenticação. Não estamos mais falando apenas de preenchimento de dados de identificação. Estamos falando de bots que estão se tornando estranhamente bons em imitar a interação humana para contornar a MFA. Vamos chamar isso de “Social Bot-neering.”

Além da Força Bruta: A Ascensão do Social Bot-neering na Autenticação

Durante anos, quando falávamos sobre bots atacando a autenticação, nossa mente ia diretamente para ataques de força bruta, preenchimento de dados de identificação, ou talvez um contorno sofisticado de CAPTCHA. Essas ainda são ameaças muito reais, não se engane. Mas recentemente, observei uma tendência preocupante que vai além dessas explorações técnicas puras. Estamos testemunhando a evolução de bots projetados para interagir com usuários, ou até mesmo com o pessoal de suporte técnico, de uma forma que os convença a renunciar ao acesso ou a contornar medidas de segurança.

Pense nisso. Investimos massivamente em autenticação multifatorial (MFA). Temos TOTP, notificações push, chaves FIDO – tudo isso é excelente. 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 precisa “verificar” algo, ou pior, de que está falando com um agente de suporte legítimo?

Meu Próprio Contato com um Bot Astuto

Tive uma experiência pessoal com isso há alguns meses que realmente abriu meus olhos. Recebi uma mensagem de texto, aparentemente do meu banco. Ela dizia algo como: “Urgente: Atividade incomum detectada na sua conta. Por favor, verifique as transações recentes em [link malicioso].” Agora, costumo ser 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. Respondi, e era uma voz AI surpreendentemente convincente, calma e profissional, afirmando vir do serviço de fraude do meu banco, referindo-se à “atividade incomum” exata mencionada na mensagem.

A voz me pediu para confirmar minha identidade, não por meio de uma senha, mas “verificando um código enviado ao meu telefone.” Recebi um SMS legítimo do meu banco com um código MFA, como se eu estivesse fazendo login. O bot ao telefone então me pediu para ler esse código. Neste momento, eu percebi. Não era apenas uma tentativa de phishing. Era um ataque coordenado. O bot havia lançado uma tentativa de login na minha conta, desencadeado a MFA, e agora tentava me incentivar a fornecer o código. Se eu tivesse lido esse código, eles teriam acesso. Era terrivelmente eficaz.

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

Como os Bots Sociais Contornam a MFA

Vamos decompor alguns dos vetores que estou observando:

1. Phishing MFA com um Toque

Foi isso que me aconteceu. Os bots iniciam uma verdadeira conexão, acionando um prompt de MFA legítimo (SMS, push, solicitação TOTP). Ao mesmo tempo, o bot contata o usuário por outro canal (SMS, e-mail, chamada de voz) se passando por uma entidade de confiança (banco, suporte de TI, plataforma de mídia social). O bot então persuade o usuário a fornecer o código MFA, aprovar a notificação push ou até mesmo escanear um código QR malicioso.


# Pseudo-código simplificado para uma tentativa de phishing MFA pilotada por um bot
function bot_orchestrate_mfa_phishing(target_user_id, bank_url, phishing_sms_template, ai_voice_script):
 # Etapa 1: Inicia 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 AI
 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()

Isso não é mais uma simples página de phishing estática. É dinâmica, interativa 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 helpdesks. O bot, se passando por um usuário legítimo, pode afirmar ter perdido seu telefone, esquecido sua senha ou estar bloqueado de sua conta. Eles terão apenas informações pessoais suficientes (frequentemente provenientes de violações de dados) para parecerem convincentes. O objetivo deles? Convencer um agente humano de suporte a redefinir a MFA, registrar um novo dispositivo ou conceder acesso temporário. Vi relatos de bots até gerando “historinhas tristes” ou expressando “frustração” para suscitar a simpatia dos agentes.


# Roteiro de bot hipotético para a engenharia social do suporte técnico (abreviado)
def bot_helpdesk_interaction(target_user_info):
 dialogue_flow = [
 {"bot": "Olá, parece que estou bloqueado da minha conta, user_id {user_id}. Meu telefone está quebrado e não posso 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": "Tudo bem, isso confere. Como deseja prosseguir?"},
 {"bot": "Você poderia, por favor, desativar temporariamente a MFA ou enviar um novo link de registro 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 

Isso é particularmente perigoso porque os agentes de suporte técnico estã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 de fundo e detalhes pessoais (roubados) precisos.

3. Tomada de Controle Automatizada de Contas via Fluxos de “Redefinição de Senha”

Embora isso não seja estritamente um contorno da MFA, muitas vezes é um prelúdio. 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 violações), os bots podem automatizar esse processo. Uma vez que tenham redefinido a senha, podem então fazer login e enfrentar o desafio da MFA, neste ponto, podem passar para uma das táticas de social bot-neering acima.

Como se Defender Contra o Social Bot-neer

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

1. Educar, Educar, Educar (Seus Usuários E Seu Pessoal)

  • 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 pelo telefone ou que o digite em um link que eles lhe enviaram. As notificações push sempre devem ser verificadas em relação à tentativa de login legítima que você iniciou. Faça-os entender que, se não iniciaram um login, 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 mudanças de acesso às contas. Implemente uma verificação em múltiplos níveis para essas ações sensíveis (por exemplo, retornar uma ligação para um número registrado, exigir verificação pessoal para contas de alto valor). Enfatize que um “desespero” ou uma “urgência” de um usuário nunca deve prevalecer sobre os protocolos de segurança.

2. Implementar uma Detecção de Bots Mais Eficiente na Fronteira e Nos Fluxos de Autenticação

  • Análise Comportamental: Procure por padrões incomuns. Um usuário inicia um login de um novo endereço IP, imediatamente seguido de uma chamada ao suporte pedindo uma redefinição de MFA? Existem várias tentativas de login falhadas seguidas de uma aprovação após uma interação “suporte”?
  • Limitações de Taxa e Throttling: Isso sempre 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 por um único usuário em um período de tempo determinado.
  • Impressão de Dispositivos: Se uma conexão é tentada de um dispositivo não reconhecido, mesmo que a MFA seja fornecida, isso deve acionar um alerta mais alto.
  • Mecanismos de Desafio-Resposta: Além do CAPTCHA, considere desafios de bot mais sofisticados antes mesmo de permitir uma tentativa de login ou emitir um desafio de MFA.

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

  • Vá além dos OTP por SMS: SMS são notoriamente vulneráveis a clonagem de SIM e interceptação. Notificações push com informações contextuais (por exemplo, “Tentativa de login de Nova York, 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 criptograficamente a origem da solicitação de login. O usuário não digita um código; ele apenas confirma sua presença no site correto. Minha escolha pessoal para contas críticas.
  • Biometria: Embora não seja uma solução mágica, combinar biometria com uma forte autenticação de dispositivos adiciona uma camada extra de dificuldade para os atacantes.

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

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 camadas para a recuperação de conta, potencialmente exigindo documentos, chamadas de vídeo ou presença física para contas sensíveis.

O caminho à frente

A corrida armamentista entre profissionais de segurança e bots maliciosos está se acelerando. À medida que nossas defesas técnicas melhoram, os atacantes simplesmente direcionam sua atenção para o elemento humano, usando bots sofisticados para expandir 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 diante de explorações técnicas e sociais.

Meu conselho? Presuma que os bots se tornem mais inteligentes. Presuma que eles são capazes de manter conversas convincentes. E então construa suas defesas – tanto as tecnológicas quanto as focadas no humano – mantendo essa suposição em mente. Fique atento, fique seguro!

Pat Reeves, concluído.

🕒 Published:

✍️
Written by Jake Chen

AI technology writer and researcher.

Learn more →
Browse Topics: AI Security | compliance | guardrails | safety | security
Scroll to Top