Ghost Sender: Risiko für Tenants mit externem Gateway Wie der MX-Record eine offene Flanke am Exchange-Online-Tenant erzeugt

Ghost Sender umgeht vorgeschaltete E-Mail-Gateways, indem Angreifer direkt mit dem Exchange-Online-Annahmepunkt sprechen – SPF, DKIM und DMARC laufen dabei ins Leere. Microsoft sieht keine Schwachstelle, sondern eine architektonische Einschränkung. Was Administratoren jetzt an den Inbound Connectoren prüfen sollten.

Viele Unternehmen leiten eingehende E-Mails nicht direkt an Exchange Online, sondern über ein vorgeschaltetes Secure Email Gateway oder einen externen Filterdienst. Der MX-Record der Domain zeigt dann auf das Gateway, das Mails prüft, bevor sie Microsoft 365 erreichen. Eine Anfang Juni von der Schweizer Sicherheitsfirma InfoGuard Labs veröffentlichte Analyse zeigt, dass genau diese verbreitete Architektur unter bestimmten Konfigurationen eine Flanke öffnet: Der eigentliche Annahmepunkt von Exchange Online bleibt aus dem Internet erreichbar und lässt sich am Gateway vorbei direkt ansprechen.

Der Annahmepunkt bleibt offen

Auch wenn der MX-Record auf ein externes Gateway zeigt, ändert das nichts daran, dass jeder Tenant einen eigenen Annahmepunkt bei Microsoft besitzt, erreichbar unter <tenant>.mail.protection.outlook.com. Dieser Endpunkt nimmt SMTP-Verbindungen aus dem Internet an, unabhängig davon, wohin der MX-Record verweist. Microsoft selbst beschreibt dieses Verhalten als beabsichtigt: Der Endpunkt sei kein Geheimnis, und standardmäßig könne jeder im Internet Mails an den Tenant senden. Der MX-Record ist lediglich ein DNS-Hinweis, an welchen Server legitime Absender ihre Mails schicken sollen. Er ist keine Zugangsbeschränkung.

Ein Angreifer kann den vorgesehenen Weg deshalb umgehen, indem er eine SMTP-Verbindung direkt zum Tenant-Endpunkt aufbaut. Die Nachricht durchläuft das Gateway dann nie. InfoGuard zufolge genügt dafür ein einzeiliger Befehl. Abhängig von der Konfiguration der Inbound Connectoren kann Exchange Online die Nachricht anschließend so behandeln, dass die regulären Authentifizierungs- und Prüfmechanismen auf diesem Zustellpfad nicht wie vorgesehen greifen.

Warum die Authentifizierung ins Leere läuft

Das eigentlich Bemerkenswerte für den Mailflow: Die Nachricht umgeht in dieser Konstellation die übliche Durchsetzung von SPF, DKIM und DMARC. Die entsprechenden Authentifizierungs-Header weisen zwar auf fehlgeschlagene oder fehlende Prüfungen hin, dennoch kann die Nachricht zugestellt werden. Bei internen Absenderadressen löst Outlook sogar das Profilbild auf. Die Ursache liegt nicht darin, dass DMARC grundsätzlich vom MX-Record abhängt, sondern darin, dass die reguläre DMARC-Durchsetzung auf diesem alternativen Zustellpfad in der beschriebenen Konfiguration nicht greift.

Damit eignet sich die Angriffstechnik für Phishing, CEO-Fraud und Business Email Compromise mit beliebigen – auch internen – Absenderadressen. Die Forscher berichten von aktiver Ausnutzung. Nach Angaben von InfoGuard bestätigte der Microsoft-Support, dass dieses oder ein verwandtes Problem bereits in freier Wildbahn missbraucht werde.

Connector-Typ statt Filterregel

An dieser Stelle wird die Konfigurationslogik von Exchange Online entscheidend, und sie ist nicht selbsterklärend. Naheliegende Schutzmechanismen greifen nämlich nicht.

Ein Inbound Connector vom Typ „Your Organization“, wie ihn hybride Umgebungen üblicherweise verwenden, verhindert die Direktzustellung laut InfoGuard nicht – auch dann nicht, wenn Enhanced Filtering for Connectors aktiviert ist. Enhanced Filtering korrigiert die Spam-Bewertung für Mails, die über bekannte Gateway-IPs eintreffen, indem es deren Adressen beim Filtern überspringt. Es adressiert damit ein anderes Problem als den direkten SMTP-Pfad zum Tenant. Ebenso wirkungslos sind Anti-Phishing-Policies mit „Honor DMARC“, solange der MX-Record nicht auf Microsoft 365 zeigt. Auch Microsofts Configuration Analyzer weist auf keine der verwundbaren Konfigurationen hin.

Wirksam ist laut InfoGuard ein anderer Ansatz. Erstens ein Inbound Connector vom Typ „Partner Organization“, der eingehende Verbindungen ausschließlich von den autorisierten Gateway-IPs oder über definierte TLS-Zertifikate akzeptiert. Microsoft empfiehlt für diesen Weg die Connector-Einstellungen RestrictDomainsToIPAddresses beziehungsweise RestrictDomainsToCertificate. Nur Verbindungen aus dem vorgesehenen Mailpfad werden dann angenommen; direkte SMTP-Verbindungen zum Tenant-Endpunkt werden abgewiesen. Zweitens, als Alternative, eine Transportregel mit höchster Priorität, die eingehende Mails in Quarantäne verschiebt, sofern sie nicht aus den zugelassenen IP-Ranges stammen und nicht als intern authentifiziert markiert sind. Beide Ansätze setzen am Annahmepunkt an, nicht an der nachgelagerten Inhaltsfilterung – das ist der konzeptionelle Unterschied.

Microsoft sieht Architektur, keine Schwachstelle

InfoGuard meldete das Problem am 21. April 2026 an das Microsoft Security Response Center. Laut der veröffentlichten Disclosure-Timeline schloss MSRC den Report noch am selben Tag als Nicht-Schwachstelle und verwies an den allgemeinen Support. Dieser offenbarte am 22. April eine aktive, weitverbreitete Spoofing-Kampagne, die einen Tag zuvor begonnen hatte. Eine Mitigation gegen das Spoofing interner Absender wurde am 22. April ausgerollt und am 27. April wieder zurückgenommen; externes Spoofing blieb durchgehend möglich. Am 29. Mai erklärte der Microsoft-Support schließlich, es handele sich nicht um eine Produktschwachstelle, sondern um eine bekannte architektonische Einschränkung. Ein CVE wurde nicht vergeben, ein plattformseitiger Fix nicht angekündigt. Erst einen Tag nach der Veröffentlichung der Analyse, am 10. Juni, öffnete MSRC den Fall wieder.

Die Absicherung liegt damit bei den Administratoren betroffener Tenants. Nach Angaben von InfoGuard ist nicht jeder Exchange-Online-Tenant betroffen, sondern insbesondere Umgebungen mit externem MX-Record und ohne entsprechend restriktiv konfigurierten Inbound Connector. Zur Verbreitung nennt InfoGuard zwei Zahlen: Bei weniger als der Hälfte der Umgebungen mit externem MX-Record sei eine Mitigation aktiv, über 20 Prozent der gescannten Bug-Bounty-Domains mit Exchange Online seien verwundbar.

Fünf Schritte zur Absicherung

Sören Schulte, E-Mail-Security-Experte bei Retarus, nennt fünf Schritte, die IT-Verantwortliche jetzt prüfen sollten. Sie decken sich im Kern mit den von InfoGuard und Microsoft empfohlenen Mitigationen.

• 1. Die Anfälligkeit prüfen. InfoGuard hat zur Veröffentlichung das Testtool ghost-sender.com bereitgestellt, das prüft, ob ein Tenant über den direkten Pfad erreichbar ist und ob die Partner-Connector-Mitigation greift. Gegen fremde Domains sollte das Tool nicht eingesetzt werden.

• 2. Den Zustellpfad eindeutig definieren. Der MX-Record sollte eingehende Mails über das Gateway führen, und in Exchange Online sollte ein passender Inbound Connector diesen Weg technisch absichern.

• 3. Den Connector restriktiv konfigurieren – über einen Partner-Organization-Connector mit Beschränkung auf Gateway-IPs oder TLS-Zertifikate.

• 4. Direkte SMTP-Zustellung unterbinden, ergänzend über die Transportregel mit höchster Priorität. Nach der Anpassung sollte praktisch geprüft werden, ob Direktzustellungen tatsächlich blockiert werden.

• 5. Fünftens: die Senderauthentifizierung überprüfen. Eine restriktive DMARC-Policy bleibt eine wichtige Schutzmaßnahme gegen viele Spoofing-Angriffe. Gegen die Ghost-Sender-Problematik allein schützt sie jedoch nicht, weil die reguläre DMARC-Durchsetzung auf dem alternativen Zustellpfad umgangen werden kann. Ergänzend lässt sich seit Kurzemdie Funktion „Reject Direct Send“ aktivieren, die anonyme Mails von der eigenen akzeptierten Domain blockiert. Sie adressiert allerdings nur das Spoofing eigener Domains, nicht die Impersonation externer Absender.

Ghost Sender ist weniger das Versagen eines einzelnen Schutzmechanismus als eine Fehlannahme über den Mailflow: Der externe MX-Record legt den vorgesehenen Zustellpfad fest, schließt den direkten Zugriff auf den Exchange-Online-Endpunkt jedoch nicht aus. Betroffen sind insbesondere Tenants, die externe E-Mail-Gateways einsetzen, ohne den Microsoft-Annahmepunkt zusätzlich über restriktive Inbound Connectoren oder vergleichbare Maßnahmen abzusichern. Solange Microsoft das Verhalten als architektonische Einschränkung und nicht als Schwachstelle bewertet, bleibt diese Absicherung Aufgabe der Administratoren – und zwar am Annahmepunkt, nicht erst in der nachgelagerten Filterung.

(ID:50884562)