InfoGuard zufolge akzeptiert Exchange Online standardmäßig eingehende E-Mails, wenn eine Organisation einen externen MX-Eintrag verwendet. In dieser Konstellation reiche ein einzeiliger PowerShell-Befehl aus, um eine Nachricht im Namen eines beliebigen Nutzers zu versenden. Das betreffe sowohl externe als auch interne Absenderadressen. Als Beispiel zeigte InfoGuard eine E-Mail, die angeblich vom offiziellen „noreply“-Konto von Microsoft stammte.
Die Forscher betonen, dass Schutzmechanismen der vorgetäuschten Domain das Problem nicht verhindern. Laut InfoGuard gilt das „unabhängig von den konfigurierten SPF-, DKIM- und DMARC-Richtlinien der vorgetäuschten Absenderdomain“, und die E-Mails würden ohne zusätzliche Warnung zugestellt. Auch der Konfigurationsanalysator von Microsoft gebe demnach keine Warnungen oder Empfehlungen aus, obwohl eine Konfiguration anfällig sein könne. Nach Darstellung von InfoGuard verhindern weder erweitertes Filtering noch die Exchange-Schutzeinstellungen „Strict“ und „Standard“ das Problem.
InfoGuard hält die Fehlkonfiguration für weit verbreitet. Zwar gebe es Gegenmaßnahmen, doch laut den Forschern hat weniger als die Hälfte der Organisationen mit extern sichtbarem MX-Eintrag eine solche Absicherung umgesetzt. Zudem erklärte InfoGuard unter Berufung auf Informationen aus dem Microsoft-Support, das Problem oder ein verwandter Fehler werde offenbar bereits aktiv missbraucht. Das Unternehmen behauptet außerdem, Microsoft habe eine Gegenmaßnahme gegen den beobachteten Spoofing-Angriff ausgerollt und später wieder zurückgenommen.
Für die Absicherung nennt InfoGuard zwei Wege für Organisationen mit Exchange Online oder lokalem Microsoft Exchange im Hybridbetrieb. Zum einen können sie einen Connector für Partnerorganisationen einrichten, der für an beliebige Organisationen gesendete E-Mails gilt oder Nachrichten anhand von IP-Adresse oder zertifikatsbasierter Prüfung zurückweist. Alternativ können Administratoren eine Mail-Flow-Regel erstellen, die alle E-Mails in Quarantäne verschiebt, bei denen der Header „X-MS-Exchange-Organization-AuthAs“ nicht auf „Internal“ gesetzt ist und deren IP-Adresse nicht zu einer erwarteten Quelle für E-Mails an Exchange Online gehört, etwa dem Mailserver, auf den der MX-Eintrag zeigt.
Zusätzlich empfiehlt InfoGuard, die Funktion Direct Send zu deaktivieren, weil dies zumindest gegen internes Spoofing schütze. Um die Wirksamkeit der Gegenmaßnahmen zu prüfen, hat das Unternehmen ein Testwerkzeug bereitgestellt, das Domänen scannt und E-Mails an autorisierte Nutzer sendet.
Im Zeitablauf des Falls schreibt InfoGuard, das Unternehmen habe das Problem zunächst im April an das Microsoft Security Response Center gemeldet. Microsoft habe den Vorgang jedoch als keinen Fall für das MSRC geschlossen, weil das Unternehmen dies angeblich nicht als Sicherheitslücke eingestuft habe. Anschließend sei InfoGuard an den allgemeinen Microsoft-Support verwiesen worden. Dort habe Microsoft am 29. Mai laut Blogbeitrag erklärt, Ghost-Sender sei keine Produktschwachstelle, sondern eine bekannte architektonische Einschränkung. Als Abhilfe habe Microsoft demnach vorgeschlagen, entweder den MX-Eintrag auf M365 umzustellen oder zusätzliche Header in weitergeleiteten E-Mails zu ergänzen, was das Problem laut InfoGuard nicht behebe.
Auf Nachfrage von Dark Reading erklärte ein Sprecher von RedTeam InfoGuard, verlässliche Kompromittierungsindikatoren seien nach dem Einspielen von Gegenmaßnahmen schwer zu finden. Als einen möglichen Ansatz nannte er die Prüfung der Empfangs-Header aller eingehenden E-Mails auf Unstimmigkeiten im Ablauf über das Mail-Gateway. Um diese Informationen bei einem Ghost-Send korrekt zu fälschen, brauche ein Angreifer interne Details wie interne IP-Adressen und interne Hostnamen der Systeme entlang des Mailpfads.