MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange Versionen analysieren

Wer Exchange Server OnPremises betreibt und seine Anwender auch von extern einen Zugriff ohne VPN- oder IPSec-Zwang erlaubt, muss per HTTPS erreichbar sein. Angreifer und Schwachstellenscanner sind kontinuierlich auf der Suche nach "schwachen" Exchange Servern. Seit den 14. Okt 2025 steigt das Risiko für Exchange 2019 und 2016, da Microsoft keine Security Updates mehr liefern will. Spätestens beim ersten Update für Exchange SE wird es damit gefährlich die nicht weiter patchbaren Server zu betreiben. Was sie bösen Akteure sowieso tun, können wir auch.

Die folgende Beschreibung eignet sich natürlich auch für einen internen Scan auf Exchange Server und deren Version.

Das Nutzung diese Kenntnisse zur Vorbereitung von Straftaten dürfte schon strafbar sein. Fragen Sie ihren Rechtsbeistand zu Details.
Übertragen gesagt: Ich erkläre ihnen, wie Sie Türen mit einem veralteten und vielleicht unsicheren Schloss erkennen, um diese als Inhaber zu sichern. Das vergleiche ich mit einem Spaziergang auf der Straße und eine Blick auf das Schloss. Ich stecke aber keinen Dietrich oder Lockpicking-Werkzeug in das Schloss.

Letztlich scheint auch das BSI entsprechende Tools zu nutzen, um die Exchange Server zu erkennen.

Wer nutzt welche Exchange Version?

Wenn ein Exchange Server aus dem Internet z.B. per ActiveSync erreichbar ist oder auch nur "Autodiscover" bereit stellt und kein Reverse Proxy davor die HTTP-Requests filtert oder verändert, dann können Sie sehr einfach per PowerShell ermitteln, welche Version hinter einer Domain genutzt wird. Hier ein Aufruf, die meist funktioniert:

# Abfrage von Autodiscover
Invoke-Webrequest https://autodiscover.<DNS-Domain>/autodiscover/autodiscover.svc
$error[-1].exception.response.headers

Sie können natürlich auch gängige Namen wie "webmail", "owa", "mobil", "eas", "outlook", "exchange" etc. vor einen Domainnamen setzen, wenn das Ziel keinen Autodiscover-Eintrag nutzt. Meist finden Sie so schon den Exchange Server. Wer tiefer gehen möchte, kann auch eine Mail an die Domain senden und anhand der NDR-Meldung vielleicht den Servernamen ermitteln. Aber selbst eine Ermittlung des Provider-Subnetzes und ein klassischer Scan auf Port 443 und Prüfung der Zertifikate liefert oft einen Hinweis. Gerade die Firmen, die heute noch ältere Exchange-Versionen nutzen, sind vermutlich auch nicht besonders abgesichert. Hier eine Beispielausgabe:

Sie können hier sehr gut sehen, dass die "X-OWA-Version: 15.1.2507.59" noch auf einen Exchange Server 2016 CU23 Sep25HU verweist.

Das soll nun keine Aufforderung sein, sich eine Liste der Domain in ihrer Stadt zu besorgen und nach möglichen Opfern, sei es zum Angriff oder für Vertriebsaktivitäten zu suchen.

Schutzmöglichkeiten

Natürlich ist ein aktuell gepatchter Service eine wichtige und richtige Schutzfunktion. Das ist der wichtige und einfach zu erklärende Wege eine lokale Exchange Umgebung zumindest grundlegend abzusichern. Aber das ist nicht der einzige Schutzlevel. Sie können durchaus weitere Funktionen umsetzen.

Hinweis: Dies hier beschriebenen Sachverhalten beziehen sich allein auf HTTP/HTTPS und behandeln keinen Schutz der SMTP-Verbindungen

Schutz Beschreibung Umgesetzt
VPN/IPSec
Source-IP

Der einfachste Weg ist natürlich den Exchange Server gar nicht von jedem Client erreichbar zu machen. Sie veröffentlichen Exchange nur für Clients, die sich per VPN oder per IPSec ausgewiesen haben. Das funktioniert natürlich nicht gut, wenn sie private Geräte (BYOD) erlauben oder die eingesetzten mobilen Geräte kein VPN nutzen sollen.

Eine zweite Herausforderung ist, dass auch der Exchange "Classic Hybrid Mode" auch von Exchange Online über das Internet auf ihren Exchange Server auf "/EWS" zugreift. Wobei sie hier entweder einen Filter auf die Source-IP der Exchange Online Datacenter oder "Modern Hybrid" mit einem lokalen Agenten nutzen können. Eine Erreichbarkeit per SMTP bleibt aber weiter erforderlich.

Reverse Proxy

Layer7-LB

Nur sehr kleine lokale Exchange Installationen werden ihren Server mit einem Bein ins Internet stellen oder per NAT erreichbar machen, Die meisten Firmen werden einen Reverse Proxy zwischen Internet und Exchange stellen, der HTTPS-Anfragen annimmt, die TLS-Verbindung terminiert und den Request nach einer Prüfung zum internen Exchange weiter gibt. Diese Funktion kann auch ein Layer-7-Loadbalancer sein, der die Last auf mehrere Exchange Server verteilt.

In diesem Fall können die meisten Produkte sowohl die HTTP-Requests als auch die Antworten verändern und steuern.

  • Angriffsmuster blockieren
    Wenn der Vektor der Schwachstelle im Exchange Server z.B. anhand des Requests schon erkannt werden kann, dann könnte so eine Schutzlösung den Zugriff verwerfen. Das ist gelebte Praxis um nur gewisse URLs zuzulassen. Microsoft macht so etwas mit seinem EEMS - Exchange Emergency Mitigation Service.
  • Exchange Version in der Antwort
    Es hindert sie niemand daran, den Header "X-OWA-Version" aus der Antwort an den Client zu entfernen und damit eine Erkennung von alten Versionen zu unterbinden. Das gilt auch für das Feld "X-FEServer" u.a. Diese Maßnahmen fallen aber eher unter Obscurity aber weniger unter einen aktiven Schutz.

Das sind nur zwei Möglichkeiten, die mein Skript nicht mehr erkennen lassen. Denken Sie beim Aufbrechen aber auch an Exchange Extended Protection und

Extended Protection mit internen Zertifikaten, damit Sie Anmeldungen per NTLM nicht stören.

PreAuth

Eine dritte Option ist eine vorgelagerte Authentifizierung und damit verbundene Autorisierung des anfragenden Clients. Dies ist die leistungsfähigste Option, da die Anfragen erst nach erfolgter Anmeldung beim Exchange ankommen. Denken Sie dabei aber auch an Anfragen, die nicht von einem Benutzer mit Browser kommen, z.B. Outlook Clients oder auch Microsoft Online Zugriffe auf Free/Busy, Teams Kalender oder MRSProxy für Migrationen. Hier sollten Sie einen Bypass für bestimmte Source-IP-Adressen ermöglichen oder die Anmeldung auf OAUTH/SAML umstellen, so dass ihr Schutzsystem das Token prüfen kann.

Autodiscover verbergen?

Sie können einen Exchange Server auch ohne die Funktion "autodiscover" bereitstellen. Über eine MDM-Lösung für mobile Clients oder Gruppenrichtlinien und Installationsskripte oder schlicht eine manuelle Konfiguration können Sie ihren Clients den direkten Weg zum Exchange Server weisen und damit auf eine Veröffentlichung von "autodiscover.<firmendomain>" verzichten. Das ist aber nur eine "Security by Obscurity" und kein echter Schutz.

Es ist nicht schwer, die Firma zu einem Subnetz zu ermitteln und dann per Scan über die IP-Adressen und Ports einen erreichbaren Exchange Server ermitteln.
"Security by Obscurity" funktioniert nicht.

Stichprobe?

Jede Firma, die heute eine Präsenz im Internet unterhält und per Mail erreichbar ist, hat einen MX-Record. Das ist mein erster Anhaltspunkt, dass es einen Mailserver geben muss. Danach habe ich mit gängigen Hostname ("autodiscover", "webmail", "mail", "exchange", "email", "intranet", "portal", "remote", "owa", "ecp", "mapi", "ews", "oab", "public", "rpc", "microsoft") die verschiedenen URLs abgerufen und auf 401,403 oder 404 Fehler gehofft, die mir etwas zu "X-OWA-Version" liefern.

Auf der Seite DMARC DNS-Record-Analyse habe ich gezeigt, wie ich eine Liste von Domains erhalten kann und mit etwas PowerShell könnte ich dann die verschiedenen Hostnamen und URLs durchprobieren und versuchen zu ermitteln, welche Exchange Version diese Domain noch nutzt.

Nur weil man etwas könnte, sollten Sie immer überlegen, welchen Sinn es hat und welches Risiko (Störung, Strafbarkeit) damit verbunden ist.

Ich habe ja nichts davon, jemandem an einen Pranger zu stellen, nur weil er seine eigene Umgebung nicht zeitnah aktuell hält. Eine Besonderheit gibt es aber für Firmen, die Exchange für Kunden hosten. Das war bis Exchange 2016 noch "offiziell" möglich aber mit Exchange 2019 schon nicht mehr supportet und das Statement hat sich mit Exchange SE meines Wissens nicht geändert. Zum OVH Exchange Hosting hat mein Test ende Okt 2025 ergeben, dass Sie zumindest für die extern erreichbaren Exchange Server auf Exchange SE (Build 15.2.2562.29) setzen. Einige andere Firmen, die bislang bei einem Hoster waren, sind entweder selbst oder mithilfe des Hosters zu Exchange Online gewechselt.

Weitere Links