Início › Blog › Ameaças

Ameaças

Engenharia social: o ataque que não depende de falha técnica

Nenhum firewall bloqueia um pedido educado. Como funcionam pretexting, vishing, fraude do boleto e sequestro de conversa — e quais controles do Microsoft 365 e do Intune limitam o estrago quando alguém clica.

Atualizado em 12/08/2026 · 8 min de leitura · Por WebOps

Todo ataque de engenharia social explora a mesma coisa: a pessoa que quer fazer o próprio trabalho direito. Alguém pede algo que parece razoável, com urgência que parece legítima, por um canal que parece confiável. Não há vulnerabilidade a corrigir, patch a aplicar nem porta a fechar — porque o atacante não invadiu nada. Ele foi convidado a entrar.

Isso não significa que a resposta seja “treinar o usuário” e torcer. Significa que a defesa se move para outro lugar: reduzir o que um clique consegue causar. É disso que este texto trata.

As formas que mais aparecem

Phishing por link malicioso

O clássico, e ainda o mais eficiente. Um e-mail imita um serviço conhecido — a própria Microsoft, o banco, o sistema de nota fiscal — e leva a uma página de login idêntica à real. O usuário digita a senha ali. Em muitos casos a página até repassa a credencial para o site verdadeiro, e a pessoa entra normalmente, sem nunca desconfiar.

Variação moderna: o link não vai para uma página falsa, vai para um pedido de consentimento legítimo da Microsoft, para um aplicativo controlado pelo atacante. O usuário clica em “Aceitar” e concede leitura permanente da caixa de e-mail. Nenhuma senha foi roubada e a conta segue comprometida.

Pretexting e fraude do boleto

O atacante constrói uma história com contexto real — nomes de pessoas da empresa, número de pedido correto, tom de voz do fornecedor. Aí comunica uma mudança de conta bancária, ou envia um boleto atualizado para um pagamento que de fato existia. O financeiro paga porque tudo bate.

Sequestro de conversa

Este é o mais difícil de perceber. O atacante já comprometeu a caixa de e-mail de um fornecedor e responde dentro de um encadeamento de e-mails verdadeiro, com todo o histórico abaixo. O remetente é conhecido, o assunto é legítimo, a conversa vinha acontecendo há semanas. O anexo, não.

Vishing e clonagem de voz

Ligação da “equipe de TI” pedindo que o usuário aprove uma notificação no celular para “concluir uma atualização”. Ou o áudio de um diretor — clonado a partir de trinta segundos de um vídeo público — pedindo uma transferência fora do processo. A voz certa desliga o ceticismo de quase todo mundo.

Fadiga de MFA

O atacante já tem a senha e dispara aprovações push repetidamente, de madrugada ou durante uma reunião, até alguém tocar em “aprovar” para o telefone parar. Tecnicamente o MFA funcionou. Operacionalmente, não protegeu ninguém.

Por que treinamento sozinho não resolve

Conscientização importa e deve existir. Mas ela tem um teto matemático desconfortável: basta uma pessoa, uma vez, em um dia ruim. Uma empresa de 80 funcionários que recebe algumas dezenas de tentativas por mês vai eventualmente ter um clique. Planejar como se isso não fosse acontecer é planejar mal.

A pergunta correta não é “como impedir que alguém clique?”. É “o que acontece no nosso ambiente depois que alguém clicar?”.

Os controles que limitam o estrago

Todos os itens abaixo existem dentro do licenciamento Microsoft que a maioria das empresas já paga. A questão quase nunca é comprar — é configurar.

Na identidade

• Acesso Condicional exigindo dispositivo compatível: a senha roubada não serve, porque o login vem de uma máquina desconhecida
• Autenticação resistente a phishing (FIDO2, Windows Hello, passkey) para diretoria, financeiro e TI — os três alvos preferidos
• Number matching no Authenticator, que encerra a fadiga de MFA: não existe “aprovar” sem digitar o número que está na tela
• Entra ID Protection forçando reautenticação em login com sinal de risco
• PIM para privilégio administrativo temporário e aprovado — uma conta comprometida sem privilégio permanente causa muito menos dano

No e-mail

• Safe Links e Safe Attachments em modo de bloqueio, com detonação em ambiente isolado
• SPF, DKIM e DMARC com política de rejeição — impede que o seu domínio seja usado contra os seus próprios clientes
• Proteção contra representação de usuários e domínios (impersonation), mirando exatamente a fraude do boleto
• Governança de consentimento: aplicativo de terceiro só entra com aprovação administrativa
• Aviso visual de remetente externo — simples, barato e eficaz contra sequestro de conversa

No dispositivo

• Políticas de compliance do Intune como pré-requisito de acesso: disco criptografado, sistema atualizado, antivírus ativo
• Redução de superfície de ataque no Defender: bloqueio de macro de origem externa e de processo filho criado pelo Office
• App Protection para BYOD: se o celular pessoal for comprometido, o dado corporativo está em contêiner isolado
• Apagamento remoto seletivo, para o desligamento e para o aparelho perdido

No processo

• Dupla verificação obrigatória para pagamento e mudança de dados bancários, sempre por canal diferente do que originou o pedido — se veio por e-mail, confirma por telefone conhecido
• Regra escrita e divulgada: a TI nunca pede senha nem aprovação de MFA por telefone
• Canal fácil e sem culpa para reportar suspeita — quem tem medo de ser repreendido esconde o clique, e o tempo de resposta é tudo
• Runbook de resposta para conta comprometida: revogar sessões, redefinir credencial, revisar regras de caixa de entrada criadas pelo atacante, avaliar exfiltração

Um detalhe que quase todo mundo esquece

Em comprometimento de e-mail, a primeira coisa que o atacante faz é criar uma regra de caixa de entrada que move as respostas do fornecedor para uma pasta oculta. É assim que ele mantém a conversa sequestrada sem o dono da conta perceber. Auditar a criação de regras de encaminhamento e bloquear encaminhamento automático externo é um dos controles de melhor relação custo-benefício que existe — e está desligado na maioria dos tenants.