No início de junho de 2026, a empresa suíça de cibersegurança InfoGuard Labs divulgou uma vulnerabilidade que denominaram Ghost-Sender: uma configuração incorreta no Microsoft Exchange Online que permite a um invasor entregar e-mails se passando por qualquer remetente – interno ou externo – diretamente na caixa de entrada de uma organização alvo, contornando completamente a autenticação SPF, DKIM e DMARC.
A Microsoft foi notificada em 21 de abril de 2026. Até 29 de maio de 2026, o Centro de Resposta de Segurança da empresa havia classificado o problema como uma limitação arquitetural conhecida, e não como uma vulnerabilidade de produto. Nenhuma correção em nível de plataforma foi emitida. A responsabilidade pela remediação recai inteiramente sobre os administradores do Exchange Online.
Esta não é uma falha teórica aguardando ser explorada. O suporte da Microsoft confirmou aos pesquisadores que um problema relacionado está sendo ativamente abusado em campo. A análise preliminar sugere que mais de 20 por cento dos ambientes do Exchange Online com registros MX externos não possuem nenhuma mitigação aplicada.
Como o Ghost-Sender Funciona
A vulnerabilidade requer uma configuração específica, mas comum: uma organização que usa o Exchange Online, ou o Exchange local em modo híbrido, onde o registro MX da organização aponta para um gateway de e-mail de terceiros em vez de diretamente para os servidores da Microsoft. Essa configuração é extremamente comum entre organizações que utilizam soluções comerciais de filtragem de spam de fornecedores como Proofpoint, Mimecast, Barracuda ou serviços similares.
Em uma implantação funcionando corretamente, o e-mail de entrada chega primeiro ao gateway de terceiros. O gateway aplica filtragem de spam, aplicação de políticas e verificação de segurança, e então passa o e-mail limpo para o Exchange Online por meio de um caminho de retransmissão configurado. A expectativa é que o Exchange Online receba apenas e-mails que já passaram pelo filtro externo.
O problema é que o endpoint *.mail.protection.outlook.com do Exchange Online é publicamente acessível e aceita conexões SMTP diretas. Um invasor que identifica esse endpoint pode contornar completamente o gateway de terceiros, enviando e-mail diretamente para o Exchange Online enquanto se passa por qualquer endereço de remetente. Como o e-mail chega por meio do que o Exchange trata como um caminho interno confiável, as políticas padrão de antispam e antiphishing – incluindo a configuração “Honor DMARC” – não se aplicam. A mensagem falsificada é entregue na caixa de entrada.
Da perspectiva do destinatário, o e-mail parece vir de um remetente legítimo. O endereço De pode conter qualquer coisa: um colega, um executivo, um fornecedor de confiança, um banco. A infraestrutura de envio real fica invisível, a menos que o destinatário inspecione os cabeçalhos brutos da mensagem.
Por Que a Autenticação Nao Consegue Ajudar Neste Cenário
SPF, DKIM e DMARC são projetados para verificar se uma mensagem que afirma vir de um determinado domínio foi realmente enviada pela infraestrutura autorizada desse domínio. Eles funcionam como verificações do lado do servidor receptor: o servidor de e-mail do destinatário consulta os registros DNS do remetente e verifica as assinaturas na mensagem.
O Ghost-Sender não tenta forjar credenciais que passem pelo DMARC. Ele faz algo diferente: explora o fato de que o processamento de entrada do Exchange Online trata conexões diretas ao seu endpoint de forma diferente das mensagens retransmitidas pelo gateway externo. Quando um e-mail chega diretamente em *.mail.protection.outlook.com nessa configuração, o Exchange Online aplica um contexto de política diferente – um em que a verificação Honor DMARC não é acionada.
Isso significa que mesmo que o domínio falsificado tenha uma política DMARC p=reject, a mensagem ainda assim é entregue. O registro DMARC do remetente diz “rejeitar e-mails não autenticados que afirmem ser deste domínio”, mas o Exchange Online não está fazendo essa consulta em primeiro lugar.
Vale ser preciso sobre o que isso significa. O Ghost-Sender não quebra o DMARC como protocolo. Ele contorna a condição sob a qual o Exchange Online consulta a política DMARC para e-mail de entrada em implantações híbridas. O próprio protocolo funciona corretamente. A lacuna está em como o Exchange Online decide quando aplicá-lo.
A Escala da Exposição
A pesquisa da InfoGuard indica que esta não é uma configuração incorreta de caso extremo. Qualquer organização que use o Exchange Online em conjunto com um registro MX externo – para filtragem de spam, arquivamento, verificação de conformidade ou propósitos de gateway de e-mail – é potencialmente vulnerável se mitigações específicas não foram aplicadas. A análise preliminar de ambientes verificados publicamente sugere que menos da metade das organizações nessa configuração implantou uma mitigação.
A categoria de organizações afetadas é significativa. Gateways de e-mail de terceiros são infraestrutura padrão em serviços financeiros, saúde, jurídico e ambientes corporativos – precisamente as categorias de organizações mais frequentemente falsificadas em campanhas de comprometimento de e-mail empresarial e spear phishing. Um invasor que consegue entregar e-mails que parecem vir de um endereço interno do departamento financeiro, ou de um escritório de advocacia externo de confiança, em um ambiente onde os destinatários não têm motivo para suspeitar de falsificação, contornou uma parte substancial do investimento em segurança de e-mail da organização.
O Que a Microsoft Disse
A InfoGuard contactou a Microsoft em 21 de abril de 2026. O Centro de Resposta de Segurança da Microsoft encerrou o relatório inicial como uma não-vulnerabilidade. O engajamento subsequente resultou no reconhecimento da Microsoft do problema como uma limitação arquitetural conhecida em 29 de maio de 2026, sem compromisso com uma correção em nível de plataforma.
Essa resposta coloca o Ghost-Sender na mesma categoria que vários outros comportamentos arquiteturais do Exchange Online que foram levantados como preocupações de segurança ao longo dos anos: a posição da Microsoft é que a configuração correta do produto evita a vulnerabilidade, e que a responsabilidade pela configuração correta pertence ao cliente.
Seja ou não razoável essa posição, a consequência prática é que cada ambiente do Exchange Online executando um registro MX externo precisa ser verificado e, se necessário, remediado por seu administrador. Não há patch chegando.
As Duas Mitigações
A InfoGuard identificou duas configurações que bloqueiam o Ghost-Sender:
A primeira é implantar um conector de entrada de Organização Parceira com uma correspondência de domínio curinga e restrição de remetente baseada em IP ou certificado. Esse conector instrui o Exchange Online a aceitar e-mail de entrada apenas de intervalos de IP ou certificados especificados, rejeitando conexões diretas de fontes não aprovadas antes do início do processamento de e-mail.
A segunda é criar uma regra de fluxo de e-mail de prioridade 0 – a prioridade mais alta disponível – que coloca em quarentena todo o e-mail de entrada que não se origine de intervalos de IP aprovados ou que não carregue o cabeçalho X-MS-Exchange-Organization-AuthAs: Internal. Essa regra intercepta mensagens que chegam pelo caminho direto e as isola antes de chegarem às caixas de entrada dos destinatários.
Ambas as mitigações requerem acesso administrativo ao Exchange Online e configuração cuidadosa para evitar interromper o fluxo de e-mail legítimo. Implementá-las sem testes pode causar falhas na entrega de e-mails legítimos, portanto, a abordagem recomendada é primeiro configurar a regra de fluxo de e-mail para adicionar um cabeçalho de aviso em vez de colocar em quarentena, verificar se todas as fontes de mensagens legítimas estão corretamente identificadas e então fortalecer para quarentena.
O Que Isso Significa para sua Estratégia DMARC
O Ghost-Sender não muda o valor da aplicação do DMARC. Se seu domínio tem uma política p=reject, ele ainda está impedindo corretamente que sua marca seja usada em campanhas de phishing que passam por caminhos de entrega padrão. A grande maioria da infraestrutura de e-mail na internet aplica verificações DMARC conforme esperado.
O que o Ghost-Sender demonstra é um problema mais restrito: configurações específicas do Exchange Online criam uma condição em que o DMARC não é consultado para e-mail de entrada, independentemente da política do domínio do remetente. Organizações executando o Exchange Online com um registro MX externo precisam verificar se aplicaram mitigações, independentemente do status de implantação do DMARC.
Os relatórios agregados do DMARC podem ajudar aqui de forma indireta. Se seu domínio está em p=reject e seus relatórios agregados mostram fontes de envio incomuns – fontes que você não reconhece e não autorizou – pode indicar que seu domínio está sendo usado em ataques estilo Ghost-Sender direcionados a outras organizações com configurações similares. Os relatórios fornecem visibilidade sobre como seu domínio está sendo usado pela internet, mesmo quando o caminho do ataque contorna a avaliação DMARC no lado receptor.
A lição estrutural do Ghost-Sender é a mesma que emergiu de cada grande divulgação de falsificação de e-mail: lacunas de autenticação existem em cada camada da pilha de infraestrutura de e-mail, e qualquer uma delas pode tornar as outras ineficazes em cenários específicos. As organizações mais bem protegidas são aquelas que combinam a aplicação correta do DMARC em seus próprios domínios com o monitoramento ativo do que está sendo entregue aos seus usuários – não apenas do que está sendo enviado em seu nome.
O Excello Mail fornece análise de relatórios agregados de DMARC, descoberta de fontes de envio e aplicação guiada para cada domínio que você gerencia. Cadastre-se gratuitamente no Excello Mail e obtenha visibilidade completa de quem está enviando e-mail em nome da sua marca – e o que está chegando nas caixas de entrada dos seus usuários.