A equipe forense da Varonis Threat Labs descobriu uma campanha de phishing que mirou mais de 70 organizações – predominantemente nos Estados Unidos – explorando um recurso legítimo do Microsoft 365 de uma forma que a maioria das equipes de segurança não havia antecipado. O ataque não exigiu credenciais roubadas, contas comprometidas nem qualquer vulnerabilidade de software no sentido tradicional. Bastou um endpoint previsível, um roteamento de e-mail permissivo e uma compreensão incompleta de como o Microsoft 365 processa mensagens que chegam pela sua própria infraestrutura.
Esse recurso se chama Direct Send.
O que é o Direct Send e para que foi criado
Direct Send é um método de fluxo de e-mail no Microsoft 365 que permite que impressoras, scanners, dispositivos de rede, aplicações empresariais e serviços internos enviem e-mail sem se autenticar no Exchange Online. Um scanner que envia um documento digitalizado, um sistema de ponto de venda que gera um recibo ou uma ferramenta de monitoramento que emite um alerta – estes são os casos de uso previstos.
O mecanismo funciona por meio de um endpoint previsível: [nomedetenant].mail.protection.outlook.com. Qualquer dispositivo ou aplicação capaz de se conectar à porta 25 nesse endereço pode injetar e-mail no fluxo do tenant sem fornecer credenciais. A Microsoft projetou dessa forma para acomodar hardware legado e sistemas internos que não conseguem realizar autenticação moderna.
O formato do endpoint é completamente previsível a partir do nome do tenant da organização, que geralmente pode ser descoberto consultando o registro MX público do domínio.
Como os invasores transformaram isso em um vetor de falsificação
A campanha da Varonis, ativa desde pelo menos maio de 2025, funcionou da seguinte forma: os invasores identificaram os endpoints de tenant das organizações-alvo, conectaram-se a esses endpoints a partir de endereços IP externos e enviaram mensagens com cabeçalhos From: configurados com nomes de colaboradores reais dentro da organização. Essas mensagens trafegaram pela infraestrutura da própria Microsoft e, sob determinadas configurações de roteamento, foram entregues a destinatários dentro da mesma organização com aparência de virem de um remetente interno confiável.
Como as mensagens transitaram pelos servidores do Microsoft 365, os filtros receptores as trataram de forma diferente do e-mail externo comum. A própria telemetria da Microsoft revelou a combinação específica de cabeçalhos que sinaliza essa condição: InternalOrgSender=True aparecendo junto com MessageDirectionality=Incoming. A mensagem parece gerada internamente para o Exchange Online Protection – mesmo tendo se originado de um invasor externo.
A verificação SPF falha. O IP remetente não consta no registro SPF da organização. O DKIM está ausente. Não há chave privada para assinar. O DMARC falha. Tanto o SPF quanto o DKIM falham, portanto o alinhamento não pode ser estabelecido. Mas nada disso importa se a organização possui uma regra de fluxo de e-mail que define o Spam Confidence Level (SCL) em -1 para o tráfego do conector de entrada, ou se a configuração de roteamento não aplica validação estrita de autenticação ao que o Exchange Online Protection já classificou como tráfego de aparência interna.
Ambientes vulneráveis exibem cabeçalhos de autenticação como spf=fail e dmarc=fail action=none reason=905. Ambientes protegidos mostram dmarc=fail action=reject ou oreject em vez disso. Essa diferença – action=none versus action=reject – é a diferença entre uma mensagem que chega à caixa de entrada e uma que é bloqueada.
Como esses e-mails de phishing aparecem para os destinatários
A Varonis documentou os iscas específicas usadas na campanha. O formato mais comum foi uma notificação de correio de voz: uma mensagem aparentemente enviada por um sistema de TI interno informando o destinatário que havia uma nova mensagem de voz disponível. O e-mail continha um arquivo PDF anexo. Dentro do PDF havia um código QR. Ao escanear o código QR, o destinatário era direcionado a um site de phishing construído sobre a infraestrutura Tycoon2FA – uma plataforma de phishing como serviço que inclui bypass de CAPTCHA e páginas de captura de credenciais do Microsoft 365.
A análise da Microsoft de campanhas relacionadas documentou tipos adicionais de isca:
Falsificação do DocuSign. Mensagens indicando que um documento aguarda a assinatura do destinatário, usando a identidade visual do Microsoft 365 e um endereço de remetente interno falso para estabelecer credibilidade.
Falsificação de Recursos Humanos. Avisos de que um prazo de inscrição em benefícios está se aproximando ou que é necessária a aceitação de uma política, usando nomes de contatos internos de RH como remetente aparente.
Comprometimento de e-mail corporativo (BEC). Mensagens falsificadas que parecem vir do CEO orientando a equipe de finanças a pagar faturas fabricadas, acompanhadas de formulários W-9 falsificados e cartas bancárias inventadas solicitando transferências ACH.
Todas essas mensagens compartilhavam uma característica visível da perspectiva do destinatário: o endereço do remetente era o de um colega real ou um sistema interno reconhecível. O domínio coincidía. O roteamento parecia interno. Não havia nenhum sinal visível de que algo estava errado.
Quais organizações estão expostas
Nem todos os tenants do Microsoft 365 são vulneráveis. Organizações cujos registros MX apontam diretamente para o Microsoft 365 são protegidas pela detecção nativa de falsificação do Exchange Online Protection, que identifica a anomalia de roteamento e bloqueia tentativas de Direct Send não autenticadas antes que cheguem à caixa de entrada.
O ataque funciona especificamente contra organizações que se enquadram em uma ou mais destas condições:
- O e-mail de entrada é roteado por meio de um gateway de segurança de e-mail de terceiros antes de chegar ao Exchange Online (configurações comuns com Proofpoint, Mimecast ou Barracuda como destino MX)
- A política DMARC está definida como
p=noneem vez dep=quarantineoup=reject - Regras de fluxo de e-mail atribuem SCL -1 ao tráfego que chega por determinados conectores, desabilitando efetivamente todos os filtros de spam e falsificação para esse caminho
- A configuração organizacional
RejectDirectSendintroduzida pela Microsoft em abril de 2025 não foi habilitada
A configuração com gateway de terceiros é especialmente comum em organizações maiores, que frequentemente roteiam o e-mail de entrada por dispositivos externos antes de ele entrar no Exchange Online. Essa topologia cria a lacuna que o ataque explora.
Como fechar essa lacuna
A Microsoft introduziu uma configuração específica para endereçar essa classe de ataque em abril de 2025:
Set-OrganizationConfig -RejectDirectSend $true
Esse comando, agora habilitado por padrão em tenants criados recentemente, rejeita tentativas de Direct Send não autenticadas aproximadamente 30 minutos após ser aplicado. Tenants criados antes de abril de 2025 podem não ter essa configuração habilitada e devem verificar seu status no Centro de Administração do Exchange.
Essa configuração aborda especificamente o vetor Direct Send. Fechar a classe mais ampla de desvios de autenticação baseados em roteamento exige uma abordagem em camadas:
DMARC em p=reject. A campanha da Varonis foi mais eficaz contra organizações com políticas p=none. Migrar para p=reject significa que uma falha de DMARC produz uma ação de rejeição em vez de apenas um evento de relatório.
Revisar cada conector de fluxo de e-mail. Cada conector de entrada no Exchange Online deve ser auditado para confirmar que não aplica configurações SCL:-1 globais ao tráfego que poderia ser injetado externamente. As exceções baseadas em conector devem ser limitadas apenas a intervalos de IP verificados.
SPF com falha rígida. Configurar -all (hard fail) em vez de ~all (soft fail) envia um sinal de rejeição mais forte e reduz a ambiguidade que conectores permissivos podem explorar.
MFA resistente a phishing. Se as credenciais de um colaborador forem capturadas por uma página Tycoon2FA, chaves de hardware FIDO2, passkeys ou o Windows Hello for Business impedem que essas credenciais sejam reutilizadas mesmo que o invasor possua um token de sessão válido. Códigos TOTP padrão não oferecem essa proteção contra interceptação de intermediários.
A lacuna estrutural que as estatísticas de DMARC não mostram
A exploração do Direct Send expõe algo que os números globais de adoção de DMARC tendem a ocultar: os registros de autenticação definem o que deveria acontecer quando um e-mail não autenticado chega. Eles não impedem os invasores de encontrar caminhos pela infraestrutura de e-mail que tratam mensagens maliciosas como se fossem autenticadas.
Uma política DMARC em p=reject em um domínio com configuração de roteamento MX não padrão pode nunca ser ativada – porque a mensagem com falha chega por um caminho de conector ao qual a política de rejeição jamais é aplicada. A política existe no DNS. A proteção não existe no fluxo de e-mail.
Monitorar o que a camada de autenticação do seu domínio realmente faz – e não apenas o que seus registros DNS publicados dizem que deveria fazer – é a diferença entre DMARC como documento de conformidade e DMARC como defesa operacional. A campanha da Varonis encontrou essa lacuna em 70 organizações. As condições técnicas que a criaram não são raras.
Invasores estão roteando phishing pela sua própria infraestrutura de e-mail. O Excello Mail mostra o que realmente acontece na camada de autenticação do seu domínio – não apenas o que seus registros DNS declaram. Cadastre-se gratuitamente no Excello Mail e tenha uma visão completa de quem envia em nome do seu domínio e como sua autenticação funciona no mundo real.