Sicherheit der Outlook Web App: Exchange mit MFA schützen

Einleitung

Die meisten Diskussionen über Sicherheit beim Fernzugriff beginnen mit dem VPN. Kaum eine davon beginnt mit der Outlook Web App (OWA), und das ist eine merkwürdige Lücke, wenn man bedenkt, was OWA eigentlich ist: ein Anmeldeformular für Unternehmens-E-Mails, das im offenen Internet liegt und von jedem Browser auf jedem Gerät und von überall aus erreichbar ist. Es gibt keinen VPN-Client zu konfigurieren, keine Firewall-Regel zu umgehen, kein Netzwerksegment zu durchqueren – nur ein Feld für den Benutzernamen, ein Feld für das Passwort und was auch immer der Exchange-Server akzeptiert.

Für einen Angreifer ist das so gut wie ein direkter Weg in ein Postfach. Ein kompromittierter OWA-Anmeldezugang erfordert keine laterale Bewegung, um gefährlich zu werden – er ist bereits sofort gefährlich, da das Postfach selbst das Ziel ist. Business-E-Mail-Compromise benötigt keine Malware, keinen Exploit und löst die meisten Erkennungswerkzeuge, die für Netzwerkeinbrüche entwickelt wurden, nicht aus. Es benötigt lediglich einen Satz gültiger Anmeldedaten und eine Anmeldeseite, die nach nichts anderem fragt.

Warum On-Premise- und Hybrid-Exchange-Umgebungen keine kostenlose MFA erhalten

Die Verwirrung ist hier verständlich, denn Microsoft 365-Mandanten, die Exchange Online nutzen, erhalten tatsächlich fast automatisch eine starke Authentifizierung – Entra ID-Richtlinien für den bedingten Zugriff können MFA auf der Identitäts-Ebene verlangen, bevor überhaupt ein Sitzungstoken ausgestellt wird, und dieser Schutz erstreckt sich ohne jegliche Exchange-spezifische Konfiguration auch auf Outlook im Web. Sicherheitsteams, die bisher ausschließlich in einer reinen Cloud-Umgebung gearbeitet haben, gehen vernünftigerweise davon aus, dass MFA für Webmail einfach zur Funktionsweise von Exchange gehört.

On-Premises- und Hybrid-Exchange übernehmen dieses Verhalten nicht. Der Exchange Server-eigene Authentifizierungsstack – die Rolle „Clientzugriffsdienste“, die OWA und das Exchange Admin Center verwaltet – gleicht Benutzernamen und Passwort mit Active Directory ab, und ohne zusätzliche Konfiguration ist damit die gesamte Authentifizierungsentscheidung getroffen. In die lokale OWA-Anmeldung ist kein nativer zweiter Authentifizierungsfaktor integriert. Hybridbereitstellungen verkomplizieren dies noch weiter: Einige Postfächer wurden möglicherweise bereits zu Exchange Online migriert und unterliegen dem bedingten Zugriff, während andere lokal verbleiben und möglicherweise weiterhin auf den eigenen Authentifizierungspfad des Exchange-Servers zurückgreifen, sofern nicht ausdrücklich die hybride moderne Authentifizierung oder eine andere MFA-Lösung konfiguriert wurde. Es ist durchaus möglich, dass ein Unternehmen davon ausgeht, seine E-Mails seien „durch MFA geschützt“, da dies für den Mandanten zutrifft, während ein nicht unerheblicher Teil der Postfächer weiterhin hinter einer rein passwortbasierten lokalen OWA-Anmeldung steht.

Dies ist die Lücke, die im operativen Betrieb von Bedeutung ist – nicht, weil der lokale Exchange von Grund auf weniger sicher konzipiert ist, sondern weil die Verantwortung für das Hinzufügen eines zweiten Authentifizierungsfaktors vollständig beim Exchange-Administrator liegt, ohne dass es eine Standardlösung gibt, auf die man zurückgreifen könnte.

Was ein kompromittiertes OWA- oder EAC-Konto einem Angreifer tatsächlich ermöglicht

Der Wert einzelner OWA-Anmeldedaten wird leicht unterschätzt, wenn man sie als „nur E-Mail“ betrachtet. In der Praxis ist ein kompromittiertes Postfachkonto ein Einstiegspunkt, von dem mehrere unterschiedliche Angriffspfade abzweigen.

Business E-Mail Compromise (BEC) ist finanziell gesehen der direkteste Angriff.

Business Email Compromise (BEC) ist finanziell gesehen der direkteste Angriff. Das Internet Crime Complaint Center des FBI verzeichnete im Jahr 2025 in den Vereinigten Staaten gemeldete BEC-Verluste in Höhe von 3,046 Milliarden US-Dollar – die zweithöchste Verlustkategorie hinter Anlagebetrug –, verteilt auf rund 24.768 Beschwerden – ein durchschnittlicher Verlust von über 120.000 US-Dollar pro bestätigtem Vorfall. BEC-Angriffe kommen typischerweise ohne Malware und ohne bösartige Links aus, die von einem Sicherheitsfilter abgefangen werden könnten; der Angreifer befindet sich in einem legitimen Postfach, versendet E-Mails von einer legitimen Adresse und antwortet oft innerhalb eines bestehenden E-Mail-Threads mit einer geänderten Bankleitzahl oder einer umgeleiteten Rechnung. Regeln für den E-Mail-Fluss erschweren es, diese Technik im Nachhinein aufzudecken – ein Angreifer mit Zugriff auf das Postfach kann eine Posteingangsregel erstellen, die Nachrichten, die Wörter wie „Rechnung“, „Überweisung“ oder „Zahlung“ enthalten, unbemerkt weiterleitet oder löscht, wodurch der Angriff für den Kontoinhaber unsichtbar bleibt, während die betrügerische Korrespondenz parallel weiterläuft.

Der delegierte Zugriff verstärkt das Risiko zusätzlich.

Der delegierte Zugriff verstärkt das Risiko. Assistenten der Geschäftsleitung und Mitglieder des Finanzteams verfügen im Rahmen des normalen Arbeitsablaufs häufig über Delegations- oder „Als … senden“-Berechtigungen für die Postfächer der Führungskräfte. Das bedeutet, dass ein einziges kompromittiertes Assistentenkonto dazu genutzt werden kann, Mitteilungen zu versenden, die den Anschein erwecken, direkt vom Finanzvorstand oder CEO zu stammen, ohne dass die Anmeldedaten dieser Führungskraft jemals berührt werden.

Datenoffenlegung ist das stillere Risiko

Die Offenlegung von Daten ist das stillere Risiko und für regulierte Organisationen oft das mit den schwerwiegenderen Folgen. In einem Postfach sammeln sich über Jahre hinweg Anhänge, interne Memos, Personal korrespondenz und Kundenkommunikation an, auf die ein Angreifer nach der Authentifizierung über die OWA-Oberfläche selbst zugreifen kann – es sind keine separaten Exfiltrations-Tools erforderlich, da der Angreifer mithilfe legitimer OWA-Funktionen auf den Inhalt des Postfachs zugreifen und diesen herunterladen kann.

Ansatz 1: MFA direkt auf die OWA- und EAC-Anmeldung angewendet

Die zielgerichteteste Lösung befasst sich mit der spezifischen Angriffsfläche, ohne andere mit Active Directory verbundene Komponenten zu berühren. Die MFA für die Outlook Web App und das Exchange Admin Center wird als Komponente der Exchange-Clientzugriffsdienste-Rolle installiert und wird vor den bestehenden OWA- und EAC-Anmeldeseiten geschaltet, anstatt den Authentifizierungsmechanismus von Exchange vollständig zu ersetzen. Nach der Installation authentifizieren sich Benutzer zunächst mit ihrem normalen AD-Benutzernamen und -Passwort und führen dann einen zweiten Authentifizierungsschritt durch – beispielsweise durch Eingabe eines OTP aus einer Authentifizierungs-App oder einem Hardware-Token oder durch Bestätigen einer Push-Benachrichtigung –, bevor die Sitzung freigegeben wird.

Der Geltungsbereich wird bei der Installation über die Active-Directory-Gruppenmitgliedschaft festgelegt: Ein Administrator kann MFA sofort für die gesamte Benutzergruppe vorschreiben oder sie zunächst nur für eine einzelne AD-Gruppe aktivieren – beispielsweise eine Pilotgruppe oder speziell die Gruppe mit Zugriff auf das Exchange Admin Center –, während die breitere Einführung geplant wird. Diese Unterscheidung ist in der Praxis von Bedeutung, da EAC-Konten ein erheblich höheres organisatorisches Risiko bergen als ein einzelnes Postfach; ein Administratorkonto mit EAC-Zugriff kann Mailflow-Regeln erstellen, Berechtigungen ändern oder Daten in der gesamten Exchange-Umgebung exportieren – genau aus diesem Grund hat der Schutz von EAC-Anmeldungen in der Regel Priorität, auch wenn die vollständige Einführung für alle Benutzer länger dauert.

Das Sitzungsverhalten ist konfigurierbar und nicht fest vorgegeben. Administratoren legen fest, wie oft Benutzer zur Eingabe eines neuen OTP aufgefordert werden – beispielsweise alle 12 Stunden bei fortgesetzter OWA-Nutzung –, und wägen dabei den Aufwand durch wiederholte Authentifizierung gegen das Risiko einer lang andauernden, unbeaufsichtigten Sitzung auf einem gemeinsam genutzten oder nicht verwalteten Gerät ab. Die Komponente unterstützt HOTP, TOTP und das Challenge-Response-Verfahren OCRA und bietet damit Flexibilität für Unternehmen, die verschiedene Arten von OTP-Tokens verwenden.

Ansatz 2: MFA auf Active-Directory-Ebene, die OWA zusammen mit allem anderen abdeckt

Eine spezifischere Frage, die es vor der Bereitstellung der OWA-spezifischen Komponente zu stellen lohnt: Ist OWA tatsächlich der einzige mit Active Directory verbundene Dienst, der sich noch allein über ein Passwort authentifiziert? Für die meisten lokalen Umgebungen lautet die ehrliche Antwort „nein“ – Winlogon, RDP und oft auch interne, LDAP-gebundene Anwendungen befinden sich in derselben Lage und sind durch nichts anderes geschützt als die von Active Directory erzwungene Passwortrichtlinie.

Die Multi-Faktor-Authentifizierung auf Verzeichnisebene behebt diese umfassendere Sicherheitslücke, indem sie direkt in Active Directory integriert wird und nicht auf der Anmeldeseite jedes einzelnen Dienstes. Anstelle einer Reihe separater MFA-Implementierungen – eine Komponente für OWA, ein anderer Agent für RDP, ein RADIUS-Proxy für VPN, die jeweils unabhängig voneinander installiert, konfiguriert und gewartet werden müssen – verändert eine Integration auf Verzeichnisebene die Funktionsweise von Benutzeranmeldedaten in Active Directory, indem statische Passwörter durch zeitbasierte dynamische Passwörter ersetzt werden, sodass mit AD verbundene Dienste dieselben dynamischen Anmeldedaten verwenden können, ohne dass für jeden Dienst separate MFA-Komponenten erforderlich sind. OWA wird nicht deshalb abgedeckt, weil es gezielt ins Visier genommen wurde, sondern weil es – wie alles andere, was auf AD verweist – nun dieselbe dynamische Anmeldeprüfung erfüllen muss.

Der Kompromiss verläuft in die entgegengesetzte Richtung wie bei Ansatz 1: eine breitere Abdeckung im Austausch für eine weitreichendere Änderung des Verhaltens der AD-Authentifizierung in der gesamten Umgebung, was in der Regel sorgfältigere Tests und eine schrittweise Einführung erfordert als bei einer OWA-Komponente, die nur einen einzelnen Dienst betrifft. Die richtige Wahl zwischen den beiden hängt tatsächlich vom Umfang ab – eine Organisation, deren einzige ungeschützte, mit AD verbundene Schnittstelle OWA ist, muss das Verzeichnis nicht antasten, um dies zu beheben; eine Organisation, die feststellt, dass OWA, RDP und Winlogon alle auf einer reinen Passwortauthentifizierung basieren, hat ein umfassenderes Problem, das sich nicht durch eine Korrektur an einem einzelnen Dienst lösen lässt.

So funktioniert der Mechanismus auf Verzeichnisebene ohne Endpunkt-Agenten

Es lohnt sich, den Mechanismus hinter der MFA auf Verzeichnisebene an sich zu verstehen, da er erklärt, warum er jeden mit Active Directory verbundenen Dienst erreicht, ohne dass auf einzelnen Arbeitsstationen oder Servern etwas installiert werden muss.

Die dynamische starke Passwortauthentifizierung funktioniert, indem das in Active Directory selbst gespeicherte Passwort geändert wird, anstatt den Authentifizierungsverkehr an jedem Endpunkt abzufangen. Das statische Passwort eines Benutzers wird durch ein rotierendes, TOTP-basiertes dynamisches Passwort ersetzt, das sich automatisch in einem vom Administrator konfigurierten Intervall ändert – ein Wert, der ein Vielfaches von 30 Sekunden sein muss. Das aktuelle dynamische Passwort wird mithilfe des TOTP-Algorithmus generiert und steht dem Benutzer über die Protectimus SMART-App oder einen unterstützten Chatbot zur Verfügung. Da die Änderung direkt im Verzeichnis erfolgt, verwendet jeder Client oder Dienst, der sich gegenüber AD authentifiziert – Winlogon, RDP, OWA, LDAP-gebundene Anwendungen –, automatisch das aktuelle dynamische Passwort, ohne dass dieser Dienst wissen muss, dass sich etwas geändert hat.

Das macht den Ansatz in dem entscheidenden Sinne agentenlos: Es läuft keine Software auf dem Laptop, dem RDP-Host oder dem Exchange-Clientzugriffsserver, die auf einen zweiten Faktor prüft. Das Verzeichnis selbst ist der Durchsetzungspunkt. Der entsprechende Kompromiss besteht darin, dass diese Komponente als Teil einer lokalen Bereitstellung und nicht als reiner Cloud-Dienst läuft, da sie eine direkte Integration mit dem Domänencontroller erfordert.

Festlegung des Anwendungsbereichs: Nur Webmail oder die gesamte AD-Umgebung

Beide Ansätze lösen das zugrunde liegende Problem – ein Passwort allein reicht zur Authentifizierung nicht mehr aus –, aber sie tun dies an unterschiedlichen Stellen im Stack, und die richtige Wahl hängt eher von einer ehrlichen Bestandsaufnahme als von einer Standardpräferenz ab.

Wenn OWA und EAC tatsächlich die einzigen Dienste sind, die sich noch ausschließlich über ein Passwort bei AD authentifizieren – VPN wird bereits über RADIUS abgedeckt, RDP ist bereits abgesichert, keine andere Legacy-Anwendung vertraut stillschweigend auf AD-Anmeldedaten –, schließt die gezielte OWA-Komponente diese spezifische Lücke mit minimaler Beeinträchtigung aller anderen Dienste, die über das Verzeichnis laufen. Wenn die Bestandsaufnahme mehr als einen exponierten Dienst zutage fördert – was häufiger der Fall ist, sobald IT-Teams tatsächlich nachsehen –, schließt die MFA auf Verzeichnisebene alle diese Lücken von einem einzigen Integrationspunkt aus, anstatt für jeden einzelnen ein separates MFA-Produkt anzuschaffen.

So oder so weisen die Zahlen des FBI zu BEC-Schäden auf dieselbe grundlegende Tatsache hin: Eine Anmeldung per Passwort allein bei einem Unternehmenspostfach, das im offenen Internet liegt, ist für keine Organisation mehr vertretbar, die Exchange einsetzt – sei es vor Ort, in einer Hybridumgebung oder anderweitig.