Hochschulen und Exchange Version
Bei der Arbeit am Artikel zum DFN-Mailservice mit Exchange Online habe ich mich gefragt, viel viele Exchange Server in Deutschland von Hochschulen betrieben werden und welche Version diese haben. Natürlich gibt es im EDU-Bereich eine starke Fraktion mit Linux ud Open Source Programmen aber auch Exchange ist vertreten. Aber wie sicher werden diese Systeme betrieben?
Autodisccover-Analyse
Um die Sicherheit einer Exchange-Installation zu bewerten, ist eine Versionsabfrage mittels Autodiscover natürlich nicht ausreichend. Ich erhalten damit keine Aussagen zum Active Directory, zum Betriebssystem, Update- und Patch-Prozessen, Monitoring der Server, Absicherungen von Anmeldungen u.a.
Eine zu alte Exchange Build Nummer ist für Angreifer natürlich ein erster Hinweis und mit Webseiten wie "Shodan" etc. auch einfach zu zu ermitteln. Diese Seite ist daher kein "Geheimnis" aber soll zumindest Administratoren etwas aufrütteln.
Domains der Hochschulen
Bei der Arbeit am Artikel zum Mailrouting über den DFN-MailService in Verbindung mit Exchange Online habe ich mich gefragt, wie viele Universitäten denn theoretisch davon betroffen sein könnten und wie alt deren Exchange Server sind. Daher habe ich erst mal eine Quelle für eine Domainliste aller Universitäten gesucht und wurde relativ schnell fündig. Der "hs-kompass.de" liefert eine UTF-8 codiert Liste aller Hochschulen, die ich einfach per PowerShell abrufen kann:
(Invoke-WebRequest ` -URL https://hs-kompass.de/kompass/xml/download/hs_liste_utf8.txt).content ` | ConvertFrom-Csv -Delimiter "`t"
Hier ein Auszug der Rückgabe

Es ist also nicht schwer, aus dem Property "Home Page" den primären Domainnamen zu ermitteln.
Wie immer sind auch diese Stammdaten nicht immer korrekt. Nicht alle URLs und Domain hier sind gültig und ich habe damit natürlich nicht alle Domains aller Hochschulen, sondern nur die primäre Domäne.
Per Skript musste ich hier diesen Inhalt also noch etwas "bereinigen", bis ich die Domains als Liste hatte.
Autodiscover ermittelt Version
Wenn Exchange einfach per NAT oder Reverse Proxy veröffentlicht ist und der Exchange/Firewall-Admin keine URL/Header-Filterung/PreAuth in einem Reverse-Proxy konfiguriert hat, dann landet eine anonyme Anfrage auf "autodiscover.<domain>" beim Exchange Server, welcher dann mit einem "404 Authentication required" antwortet aber im Header die Version verrät. Der Auszug aus meinem Skript zeigt den Abruf per PowerShell Core mit einem TRY/CATCH-Block, um die HTTP-Fehlermeldung abzufangen und dennoch den Header auszuwerten

Auszug aus meinem Code
Sie sehen, das ich mir den Wert aus dem Header "x-owa-version" extrahieren.
Ein Exchange/Firewall-Admin kann natürlich diesen Header aus der Antwort entfernen und dann habe ich diese Information nicht. Da machen aber wohl nur sehr wenige Administratoren.
Das komplette Skript, welches mit mehreren Threads die ganzen Domains abfragt, habe ich bislang nicht veröffentlicht.
Denken Sie daran, dass auch Thunderbird sowohl Autodiscover als auch einen "Autoconfig"-Eintrag ("Automatic Account Configuration | Thunderbird Help", https://support.mozilla.org/en-US/kb/automatic-account-configuration ) nutzen kann. Auch seltener genutzte Optionen wie DNS-SRV-Records, HTTP-Redirects etc. habe ich nicht weiter überprüft. Ebenso habe ich keine OAUTH-Anmeldung versucht, um eine Preauthentication einer Web Application Firewall zu versuchen. Auswertung
Ich kann ihnen aber einen Überblick geben, wie viele Exchange Server sich im Umfeld der Hochschulen im August 2026 betrieben wurden.
Hinweis:
Ich habe nur die primären Domains geprüft. Es kann durchaus
sein, dass Fachbereiche mit einer Subdomain oder andere
verbundene Institute unter eigenen Domains noch weitere
Exchange Server betreiben, die ich so nicht gefunden habe.
Ich könnte diese Server natürlich auch abscannen, indem ich mir einfach die Netzwerke der Universitäten oder der DFN auf WebServer unter HTTPS abfrage und nach "x-owa-version"-header suchen oder Reaktionen auf Autodiscover analysiere. Auch die Auswertung von erhaltenen Zertifikaten auf zusätzliche SAN-Namen etc. könnten Hinweise geben. Das machen die "Bösen" schon zur genüge. Auch meine einfache Auswertung liefert aber Hinweise, dass zumindest bei einigen Hochschulen noch Handlungsbedarf ist.
Auswertung
Ich habe am 25. Juni 2026 die Liste der Domains geladen und 388 DNS-Domains ausgewertet. Davon haben 107 DNS-Domains auf eine Autodiscover-Anfragen reagiert und 104 Server haben sogar eine Version geliefert. Zu den Versionen habe ich die Exchange Build Nummer und den Patchstand ermittelt.
# Exchange Build Nummern von extern erreichbarer Exchange Server vom 25. Juni 2026
Count Name Patchname Releasedate
----- ---- --------- -----------
1 15.1.2507.44 Exchange Server 2016 CU23 Nov24SUv2 27. November 2024
2 15.1.2507.61 Exchange Server 2016 CU23 Oct25SU 14. Oktober 2025
2 15.1.2507.69 Exchange Server 2016 CU23 Jun26SU 9. Juni 2026
1 15.2.1258.34 Exchange Server 2019 CU13 Apr24HU 23. April 2024
1 15.2.1544.36 Exchange Server 2019 CU13 Nov24SU 12. November 2024
1 15.2.1748.26 Exchange Server 2019 CU15 Mai25HU 29. Mai 2025
2 15.2.2562.29 Exchange Server SE RTM Oct25SU 14. Oktober 2025
8 15.2.2562.35 Exchange Server SE RTM Dec25SU 9. Dezember 2025
11 15.2.2562.37 Exchange Server SE RTM Feb26SU 10. Februar 2026
6 15.2.2562.41 Exchange Server SE RTM May26HU 7. Mai 2026
69 15.2.2562.43 Exchange Server SE RTM Jun26SU 9. Juni 2026
14 nicht geprüft Die Server haben ein 200 OK ohne Exchange Version geliefert
267 unknown keine Daten erhalten, da kein DNS, keine Verbindung o.ä.
===========================================================================
107 Exchange Server Total
388 Domains Total
Am 25. Juni 2026 hatten 69 Hochschulen und Universitäten schon Exchange SE mit dem damals aktuellen SU Juni 2026 und 6 weitere Hochschulen waren zumindest bis zum Mai aktuell. Wir sehen aber auch, dass zwei Hochschulen/Universitäten anscheinend das ESU-Programm nutzen. Sonst hätten Sie keinen Zugriff auf "Exchange Server 2016 CU23 Jun26SU" vom "9. Juni 2026". Aber es gibt wohl einige Domains, hinter denen sich ältere Exchange SE und sogar noch Exchange 2019/2016 Server verbergen. Ich habe den Test am 5. August noch einmal wiederholt. Diesmal ist das neue "Exchange SE Juli 2026" auf der Mehrzahl der Server installiert worden.
# Exchange Build Nummern von extern erreichbarer Exchange Server vom 05. Aug 2026
Count Name Patchname Releasedate
----- ---- --------- -----------
1 15.1.2507.44 Exchange Server 2016 CU23 Nov24SUv2 27. November 2024
2 15.1.2507.61 Exchange Server 2016 CU23 Oct25SU 14. Oktober 2025
2 15.1.2507.69 Exchange Server 2016 CU23 Jun26SU 9. Juni 2026
2 15.1.2507.71 Exchange Server 2016 CU23 Jul26SU 9. Juli 2026
1 15.2.1258.34 Exchange Server 2019 CU13 Apr24HU 23. April 2024
1 15.2.1544.36 Exchange Server 2019 CU13 Nov24SU 12. November 2024
1 15.2.1748.26 Exchange Server 2019 CU15 Mai25HU 29. Mai 2025
2 15.2.2562.29 Exchange Server SE RTM Oct25SU 14. Oktober 2025
3 15.2.2562.35 Exchange Server SE RTM Dec25SU 9. Dezember 2025
3 15.2.2562.41 Exchange Server SE RTM May26HU 7. Mai 2026
5 15.2.2562.43 Exchange Server SE RTM Jun26SU 9. Juni 2026
80 15.2.2562.45 Exchange Server SE RTM Jul26SU 14. Juli 2026
13 nicht geprüft Die Server haben ein 200 OK ohne Exchange Version geliefert
272 unknown keine Daten erhalten, da kein DNS, keine Verbindung o.ä.
===========================================================================
103 Exchange Server Total
388 Domains Total
Wie sehen schon, dass ca. 3 Wochen nach dem Release von "Exchange SE Jul26SU" schon 80 Hochschulen das Update auf ihrem Exchange Server SE installiert haben und auch die zwei Hochschulen mit Exchange 2016 ESU aktuell sind.
Aber es ist erschreckend, dass es acht Hochschulen gibt, die nachweislich veraltete Exchange Server betreiben, die seit Okt 2025 keine Updates mehr bekommen haben und 13 Umgebungen schon auf Exchange SE migriert sind aber das aktuelle SU nicht zeitnah aktualisiert eingespielt wird.
Als Teil der Analyse kenne ich natürlich auch die betroffenen Domains und werde den Net at Work Vertrieb bitte, die Ansprechpartner der acht furchtbar veralteten Hochschulen auf das Problem anzusprechen.
- Exchange und Outlook Build Nummern
- Exchange Build Nummer ermitteln
- Exchange Server – Buildnummern und
Veröffentlichungstermine
https://learn.microsoft.com/de-de/exchange/new-features/build-numbers-and-release-dates
Analyse Aug 2026 SU9 Rollout
Wenige Tage nach Veröffentlichung dieser Seite hat Microsoft am 11. August ein Security Update Exchange released. Ich habe dann versucht, das Skripte einmal am Tag zu starten, um das Rollout zu sehen. Die Ziffern sind die letzte Stelle der Buildnummer "15.2.2562.xx". Die Exchange 2019/2016-Zahlen.
| Datum | Total | Pre SE | 17 | 29 | 35 | 41 | 43 | 45 | 46 |
|---|---|---|---|---|---|---|---|---|---|
11. Aug 2026 |
102 |
8 |
1 |
2 |
3 |
3 |
5 |
80 |
na |
12. Aug 2026 |
100 |
8 |
1 |
2 |
3 |
1 |
4 |
76 |
5 |
13. Aug 2026 |
102 |
8 |
1 |
2 |
3 |
1 |
4 |
56 |
27 |
14. Aug 2026 |
103 |
8 |
1 |
1 |
3 |
1 |
3 |
52 |
34 |
17. Aug 2026 |
103 |
8 |
1 |
1 |
3 |
1 |
3 |
42 |
44 |
18. Aug 2026 |
102 |
8 |
1 |
2 |
3 |
0 |
2 |
36 |
50 |
20. Aug 2026 |
102 |
8 |
1 |
1 |
3 |
0 |
2 |
25 |
62 |
22. Aug 2026 |
102 |
8 |
1 |
1 |
3 |
0 |
2 |
19 |
68 |
24. Aug 2026 |
102 |
8 |
1 |
1 |
3 |
0 |
2 |
19 |
68 |
24. Aug 2026 |
102 |
8 |
1 |
1 |
3 |
0 |
2 |
17 |
70 |
Als Grafik ist der Anstieg der grünen und fast identischer Rückgang der gelben Linie gut zu sehen. Die ersten 30-40 Installationen werden aktiv gepflegt aber dann flacht die Update-Rate doch etwas ab und all die "vergessenen Server" schauen wir besser nicht genauer an.

Es scheint also durchaus einige Universitäten mit straffen Patchmanagement zu geben und 3 Tage nach dem Update schon 34 Server aktualisiert. 6 Tage nach dem Release waren es weitere 10 Server und am 18. Aug wurden weitere 6 Server auf das aktuelle CU angehoben. Warum aber die ".29" am 18. Aug zugenommen hat, finde ich suspekt.
Die acht Exchange 2016/219 Server betrachte ich nicht weiter. Ich erwarte hier auch keine Wunder.
Die Zahlen zeigen nur die Version des einen ersten "Frontend Servers", den ich erreicht habe. Der Wert kann auch durch einen Reverse Proxy gespooft werden und in den 272 "unbekannten" Servern könnte es noch viele unerkannte Server geben.
Detailinformationen
Bei der Anfrage per "Invoke-Webrequest" habe ich natürlich noch deutlich mehr unterschiedliche Antworten bekommen, die in in der Detailauswertung protokolliere.
| Antwort | Anzahl | Bedeutung |
|---|---|---|
Unauthorized |
117 |
Das sind die 401-Fehler, die vermutlich aber nicht zwingend auf einen Exchange Server hindeuten könnten. Wenn ich aber im Header eine "x-owa-version" finde, nehme ich diese als BuildNummer |
NameResolutionError |
96 |
Die Domain hat keinen "autodiscover.<domain>"-Eintrag im Internet veröffentlicht. Das bedeutet nicht, dass nicht doch Exchange intern verwendet wird oder unter einem anderen Namen statisch veröffentlicht ist. |
<leer> |
118 |
Diese Verbindungen waren einfach erfolgreich |
Anomym200 |
14 |
Der Zugriff wurde mit einem "200-OK" Status beantwortet. Einige Ziele liefern anonym eine Autodiscover.xml zurück, die für IMAP4-Zugriffe passt. Ein OnPremises Exchange Server möchte schon erst einen angemeldeten Benutzer haben |
NotFound |
7 |
Das ist ein HTTP 404-Fehler, dass es die URL nicht gibt, Der Name wurde aber aufgelöst und auch einen HTTPS-Verbindung ist zustande gekommen. Oft ist ein "Wildcard"-DNS die Ursache, die unbekannte Namen auf einen Default Webserver routet. |
ConnectionError |
22 |
Der Name wurde aufgelöst aber es konnte keine Verbindung zum Host aufgebaut werden. Vielleicht ist es ein vergessener alter Eintrag oder der Zugriff ist durch eine Firewall auf bestimmte Quelladressen beschränkt. |
Forbidden |
7 |
Ein Zugriff auf Autodiscover ohne Credentials sollte einen 401-Fehler liefern. Wenn eine andere Antwort kommt, dann gehe ich nicht von einem Exchange Server auf der anderen Seite aus. |
Unknown |
1 |
Den Fehler habe ich nur sporadisch und wurde nicht weiter analysiert |
BadGateway |
1 |
Da hat wohl ein Reverse Proxy den Request nicht zum Backend-Service weiterleiten können. |
SecureConnectionError |
1 |
Hier gibt es Probleme beim TLS-Handshake |
BadRequest |
2 |
Vermutlich mag eine Web Applikation Firewall meine Anfrage nicht. |
Method Not Allowed |
1 |
Da prüft wohl jemand, ob ich GET, POST oder eine andere Methode nutzen |
ResponseEnded |
1 |
DNS, Connection war wohl ok, aber es kam keine vollständige Verbindung zustande. Die eine Domain lieferte einen TLS-Error, z.B. weil es keine TLS1.2 angeboten hat. |
| Gesamt | 388 |
Ich sehe aber aktuell keinen Sinn darin, diese Details zu veröffentlichen.
Zusammenfassung
Diese Seite sollte zeigen, wie einfach jemand per Skript nicht nur eine Firma, sondern auch eine Liste von Domains auf ihre Exchange OnPremises Nutzung und die Exchange Version prüfen kann, solange ein Administrator keine Gegenmaßnahmen konfiguriert hat. Sie zeigt aber auch, dass es, wie in allen Umgebungen, immer viele gut gepflegte Exchange Server, ein paar Nachzügler und anscheinend wenige vergessene Server gibt. Gerade die letzten Server sind aber oft das Risiko für eine Umgebung, über die Angreifer einen Zugang.
Ich warte mal ab, wie die angesprochenen Hochschulen mit den ganz alten Server reagieren.
Weitere Links
- Exchange - Autodiscover
- Exchange extern absichern
- Autodiscover testen
- Autodiscover veröffentlichen
-
Build Nummern
Exchange und Outlook Versionen im Überblick -
Exchange Build Nummer ermitteln
Viele Wege um die Build-Nummer von Exchange zu ermitteln.















