A minha luta de 2026: Bots & Autenticação através de Engenharia Social

Olá a todos, Pat Reeves aqui, novamente no botsec.net. Estamos em março de 2026, e tenho a impressão de que estamos em uma batalha constante contra ameaças alimentadas por bots. Assim que você pensa que conseguiu controlar um aspecto, outro surge. Hoje quero falar sobre algo que me mantém acordado à noite: o uso cada vez mais sofisticado de bots na engenharia social, especialmente em relação à violação dos fluxos de autenticação. Não estamos mais falando apenas de um simples credential stuffing. Estamos falando de bots que se tornam surpreendentemente bons em imitar a interação humana para eludir o MFA. Vamos chamar isso de “Social Bot-neering.”

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

Por anos, quando falávamos de bots atacando a autenticação, nossa mente imediatamente se direcionava para ataques de força bruta, credential stuffing, ou talvez um habilidoso bypass do CAPTCHA. Essas ameaças ainda existem, não me entenda mal. Mas recentemente, observei uma tendência preocupante que vai além dessas explorações puramente técnicas. Estamos assistindo à evolução de bots projetados para interagir com os usuários, ou até mesmo com a equipe de suporte técnico, de forma a induzi-los a abandonar o acesso ou a contornar as medidas de segurança.

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

Meu contato com um bot inteligente

Tive uma experiência pessoal a respeito alguns meses atrás que realmente abriu meus olhos. Recebi uma mensagem de texto, aparentemente do meu banco. Dizia algo como: “Urgente: atividade suspeita detectada em sua conta. Verifique por favor as transações recentes em [link malicioso].” Agora, geralmente sou bastante hábil em reconhecer 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 de IA extremamente convincente, calma e profissional, que dizia ser do departamento de fraudes do meu banco, fazendo referência à exata “atividade suspeita” da mensagem.

Ela me pediu para confirmar minha identidade, não fornecendo 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 efetuando o login. O bot ao telefone então me pediu para ler aquele código. Nesse ponto, percebi. Não era apenas uma tentativa de phishing. Era um ataque coordenado. O bot havia iniciado uma tentativa de login na minha conta, ativado o MFA e agora tentava me manipular socialmente para que eu fornecesse o código. Se eu tivesse lido aquele código em voz alta, eles teriam acesso. Foi terrivelmente eficaz.

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

Como os bots sociais eludem o MFA

Vamos analisar alguns dos vetores que observo:

1. Phishing MFA com um toque diferente

Isso é o que aconteceu comigo. Os bots iniciam uma verdadeira conexão, ativando uma solicitação de MFA legítima (SMS, notificação push, solicitação TOTP). Ao mesmo tempo, o bot contata o usuário através de 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 persuadiu o usuário a fornecer o código MFA, aprovar a notificação push ou até mesmo escanear um código QR malicioso.

“`html

# 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):
 # Passo 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()
 
 # Passo 2: Enviar um SMS de phishing direcionado
 send_sms(target_user_id.phone_number, phishing_sms_template.format(bank_name="Seu Banco"))
 
 # Passo 3: Iniciar uma chamada de voz IA
 ai_call_session = make_ai_voice_call(target_user_id.phone_number, ai_voice_script)
 
 # Passo 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()
 
 # Passo 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 de phishing estática. É dinâmico, interativo e aproveita a confiança pré-existente do usuário em seus mecanismos MFA.

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

Os bots agora são usados para automatizar chamadas ou chats com os centros de suporte. O bot, se passando por um usuário legítimo, pode afirmar ter perdido seu telefone, esquecido sua senha ou estar trancado fora de sua conta. Possuir informações pessoais suficientes (frequentemente provenientes de vazamentos de dados) para parecer crível. Qual é o objetivo? Convencer um agente humano do suporte técnico a redefinir o MFA, registrar um novo dispositivo ou conceder acesso temporário. Tenho visto relatos de bots que até geram “histórias tristes” ou expressam “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": "Oi, parece que não consigo acessar minha conta, 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": "Certo, isso confere. Como você deseja prosseguir?"},
 {"bot": "Você poderia desabilitar temporariamente o MFA ou enviar um novo link de registro para meu email de emergência {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:
 # Essa parte envolveria o processamento de linguagem natural para compreender a resposta do agente
 # e selecionar a resposta apropriada seguinte 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 dificuldades de um bot bem programado, especialmente quando o bot tem uma boa história e detalhes pessoais exatos (roubados).

3. Controle automatizado da conta através de fluxos de “Redefinição de senha”

Embora não seja estritamente uma violação do MFA, muitas vezes é um precursor. Os bots exploram fluxos de “senha esquecida” mal configurados. Se um sistema permitir muitas solicitações de redefinição de senha ou se as perguntas de segurança forem facilmente adivinháveis (ou se as respostas estiverem disponíveis em vazamentos de dados), os bots podem automatizar este processo. Uma vez que a senha é redefinida, eles podem acessar e enfrentar o desafio do MFA, momento em que podem recorrer a uma das táticas de engenharia social mencionadas acima.

Defender 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 seu pessoal)

“““html

• Para os usuários: Reforcem o mantra “nunca compartilhe seu código MFA”. Enfatizem que serviços legítimos *nunca* pedirão que você leia um código MFA pelo telefone ou o insira em um link que eles enviaram. As notificações push devem sempre ser comparadas com a tentativa de acesso legítima que você iniciou. Deixe claro que se não iniciaram um acesso, devem recusar a solicitação.
• Para a equipe de suporte técnico: Isso é fundamental. Treinem rigorosamente a equipe sobre táticas de engenharia social. Forneçam protocolos claros e não negociáveis para redefinições de MFA ou mudanças de acesso à conta. Implementem uma verificação em múltiplos níveis para essas ações sensíveis (por exemplo, ligar para um número registrado, solicitar uma verificação presencial para contas de alto valor). Insistam que um “mal-entendido” ou uma “emergência” de um usuário nunca deve prevalecer sobre os protocolos de segurança.

2. Implementar uma detecção mais eficaz de bots nas fronteiras e nos fluxos de autenticação

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

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

• Avancem 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 conexão de Nova York, iPhone 15 Pro”) são melhores, mas ainda são vulneráveis à engenharia social.
• Chaves de segurança de hardware (FIDO2/WebAuthn): Essas são muito mais resistentes ao phishing e à engenharia social, pois a chave verifica criptograficamente a origem da solicitação de acesso. O usuário não precisa digitar um código; apenas confirma sua presença no site correto. É minha escolha pessoal para contas críticas.
• Biometria: Embora não seja uma solução milagrosa, combinar biometria com uma sólida autenticação de dispositivos adiciona uma camada adicional de complexidade para os agressores.

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

Reavaliem seus processos de recuperação de conta. As perguntas de segurança são simples demais? É fácil demais para alguém provar sua identidade pelo telefone? Implementem uma verificação em múltiplas etapas para a recuperação de conta, que pode exigir documentos, videochamadas ou uma presença física para contas sensíveis.

O caminho a seguir

A corrida armamentista entre profissionais de segurança e bots maliciosos está se intensificando. À medida que nossas defesas técnicas melhoram, os agressores simplesmente mudam sua atenção para o elemento humano, utilizando bots sofisticados para amplificar seus esforços de engenharia social. Não é mais suficiente bloquear os IPs ou detectar o preenchimento automático. Precisamos pensar como os agressores, entender suas táticas em evolução e construir defesas resilientes contra exploits técnicos e sociais.

Meu conselho? Suponham que os bots se tornem mais inteligentes. Suponham que sejam capazes de conduzir conversas convincentes. E então, construam suas defesas – tanto técnicas quanto humanas – com essa suposição em mente. Mantenham-se vigilantes, mantenham-se seguros!

Pat Reeves concluiu.

🕒 Published: April 5, 2026