Passkeys gelten als das Ende des Passwort-Phishings. Kein geteiltes Geheimnis, keine wiederverwendbaren Passwörter, keine abfangbaren Einmalcodes – stattdessen ein privater Schlüssel, der das Gerät nie verlässt. Ein neues White Paper von Michael Grafnetter (SpecterOps), vorgestellt auf der Black Hat USA 2026, zeigt jedoch: Die kryptografische Stärke von WebAuthn nützt wenig, wenn die Implementierung drumherum patzt. Grafnetter fasst die Schwächen unter dem Begriff Pass-the-Passkey zusammen – bewusst in Anlehnung an die aus der Windows-Welt bekannten Angriffe Pass-the-Hash und NTLM-Relay.

Für IT-Verantwortliche und Berater ist die Kernbotschaft doppelt: Passkeys bleiben der richtige Weg – aber ihre Einführung ersetzt weder eine saubere Server-Implementierung noch eine durchdachte Endpoint-Härtung. Der Name ist bewusst gewählt: Wie bei Pass-the-Hash und NTLM-Relay zielt der Angriff nicht auf die Kryptografie, sondern auf die Schicht darum herum.

Das Wichtigste in Kürze

• Passkeys sind nicht „kaputt“. Sie bleiben ein deutlicher Fortschritt gegenüber Passwörtern. Das Problem liegt, wie so oft, in der Umsetzung, nicht im Konzept.
• Drei Zero-Days in Windows 11 und Microsoft Entra ID, davon zwei als Replay-Kette kombinierbar.
• Zwei sind gepatcht, eine bleibt offen: Das Credential-UI-Window-Handle-Spoofing wurde von Microsoft als „Low / Defense in Depth“ bewertet und nicht behoben.
• Malware-basiertes Passkey-Phishing funktioniert ganz ohne Microsoft-Bug – es genügt Schadcode auf dem Endgerät.
• Synchronisierte Passkeys sind bequemer, aber exponierter. Für privilegierte Konten gehören gerätegebundene Authenticatoren mit Attestation her.

Warum WebAuthn eigentlich phishing-resistent ist

Stellen wir uns einen Passkey als Schlüssel vor, der fest im Türschloss verbaut ist – er lässt sich nicht herausziehen, nicht kopieren und nicht mitnehmen. Sie können damit auf- und zusperren, aber niemand kann Ihnen den Schlüssel selbst entwenden. Genau das ist der private Schlüssel eines Passkeys: Er verlässt das Gerät nie.

Der Schutz ruht im Kern auf zwei Design-Entscheidungen.

Origin-Binding (Phishing-Schutz): Der Browser trägt die echte Herkunft der aufrufenden Seite in die signierten Daten ein, nicht die Webseite selbst. Im Bild gesprochen passt Ihr Schlüssel nur in das Schloss einer bestimmten Haustür. Baut ein Betrüger eine täuschend echte Kulisse Ihres Hauses nach, bleibt sein nachgemachtes Schloss außen vor – Ihr Schlüssel dreht sich dort schlicht nicht. Eine Phishing-Seite kann deshalb keine gültige Assertion erzeugen.

Frische Challenges und Signaturzähler (Replay-Schutz): Jede Anmeldung nutzt eine einmalige Zufalls-Challenge. Das ist wie ein Pförtner, der Ihnen bei jedem Besuch einen neuen, frisch gestempelten Losungszettel gibt – ein alter Zettel von gestern ist wertlos. Zusätzlich führen Hardware-Authenticatoren einen hochzählenden Zähler mit, vergleichbar mit einem Kilometerzähler: Tauchen plötzlich zwei Schlüssel mit demselben Zählerstand auf, muss einer davon eine Kopie sein.

Der entscheidende Haken: Diese Garantien sind nur so stark wie die Prüflogik der Gegenstelle. Es nützt der beste Losungszettel nichts, wenn der Pförtner gar nicht kontrolliert, ob er schon einmal benutzt wurde. Die WebAuthn-Spezifikation definiert ein 25-Schritte-Verfahren zur Verifikation einer Assertion. Lässt ein Betreiber wichtige Prüfungen weg – Einmaligkeit der Challenge, Bindung an die Session, Zählerkontrolle – degradiert das „unphishbare“ Verfahren still und leise zu etwas, das sich weiterleiten oder erneut abspielen lässt.

Drei Passkey-Schwachstellen in Windows 11 und Entra ID

Das Herzstück der Forschung sind drei praktisch ausnutzbare Schwachstellen. Zwei davon bilden zusammen eine komplette Replay-Kette.

1. Vollständige Assertions im Windows Event Log (CVE-2026-34348)

Bildlich gesprochen notierte hier der Pförtner den kompletten geheimen Handschlag inklusive Losungswort in ein Logbuch, das im ganzen Gebäude offen auslag. Konkret: Windows 11 schrieb vollständige WebAuthn-Assertions im Klartext in das Ereignisprotokoll Microsoft-Windows-WebAuthN/Operational.

Das betraf praktisch alle Authenticator-Typen – Windows Hello, YubiKeys, Passwort-Manager-Plugins und hybride Flows via Smartphone. Ausgenommen waren nur private Browserfenster (InPrivate/Inkognito) und einige Passwort-Manager, die den Windows-WebAuthn-Weg umgehen.

Brisant ist die Berechtigungslage: Lokal reicht Mitgliedschaft in der Gruppe „Benutzer“, remote genügen bereits Gruppen wie „Ereignisprotokollleser“ oder „Remotedesktopbenutzer“. Ein Angreifer mit geringen Rechten auf einem geteilten Rechner konnte so die Assertion eines dort angemeldeten Global Admins auslesen – ein klassischer Privilege-Escalation-Pfad in die Cloud.

Der Forscher meldete das Ganze als Privilege Escalation (CVSS 8.6). Microsoft stufte es abweichend als „Information Disclosure“ ein (CVSS 6.5, CWE-693), zahlte 1.000 US-Dollar Bounty und lieferte am 14. Juli 2026 einen Fix, der die Signatur in den geloggten Assertions auf sechs Bytes kürzt – gerade genug fürs Debugging, zu wenig für einen Replay.

2. Fehlender Replay-Schutz in Microsoft Entra ID

Genau hier machte der Pförtner den entscheidenden Fehler: Er kontrollierte nicht, ob ein Losungszettel schon einmal vorgelegt wurde. Entra ID prüfte weder die Wiederverwendung von Challenges noch Signaturzähler.

Statt Challenges serverseitig zu speichern, setzte Microsoft aus Skalierungsgründen auf kurzlebige, signierte JWT-Tokens – nominell fünf Minuten gültig, in der Praxis bis zu zehn Minuten akzeptiert (zum Ausgleich von Zeitversatz). Für automatisierte Angriffe ist das ein komfortables Zeitfenster.

Für sich genommen ist diese Lücke moderat, weil ein Angreifer zunächst HTTPS-Verkehr abfangen müsste. Kombiniert mit der Event-Log-Schwäche (Nr. 1) entsteht jedoch eine praktikable Angriffskette, die phishing-resistente MFA aushebelt – ohne dass die getesteten XDR-Lösungen (inklusive Defender for Identity unter Microsoft 365 E5) Alarm schlugen.

Microsoft rollte im Mai 2026 stillschweigend eine Zähler-Prüfung aus – allerdings nur für FIDO2-Sicherheitsschlüssel und VBS-basiertes Windows Hello. Reguläre Windows-Hello-Passkeys bleiben anfällig, weil sie stets den Zählerwert 0 senden. Auch manche synchronisierten Passkeys (etwa aus KeePassXC) unterstützen keine Zähler.

3. Credential-UI-Window-Handle-Spoofing (ungepatcht)

Man stelle sich einen unbekannten Handwerker vor, der seinen Auftragszettel direkt unter das Firmenschild eines vertrauten Unternehmens hält – schon wirkt er seriös. Technisch: Die Windows-API WebAuthNAuthenticatorGetAssertionvalidiert das übergebene Fenster-Handle (hWnd) nicht sauber. Angreifer können den Passkey-Dialog dadurch in den Kontext einer anderen, vertrauenswürdigen Anwendung – etwa des Browsers – einhängen, selbst über Benutzergrenzen hinweg.

Microsoft stufte die Schwachstelle als „Low“ in der Kategorie „Defense in Depth“ ein und schloss den Fall, ohne einen Fix zu liefern (der Forscher bewertet sie mit CVSS 8.0). Genau diese offene Lücke macht die folgenden Phishing-Techniken so überzeugend.

Passkey-Phishing: Der Angriff, der keinen Bug braucht

Der praxisrelevanteste Teil des Papers sind Angriffe, die keine spezifische Microsoft-Lücke voraussetzen – nur Malware auf dem Endgerät des Opfers.

Der Kerngedanke lässt sich wieder mit dem eingebauten Schlüssel erklären: Der Angreifer muss ihn gar nicht herausbrechen. Es reicht, im richtigen Moment höflich zu fragen „Würden Sie bitte kurz aufsperren?“ – und der Bewohner sperrt reflexartig auf. Übertragen: Ein Angreifer muss den privaten Schlüssel nicht extrahieren. Es genügt, das Betriebssystem um eine signierte Assertion zu bitten.

Ruft eine gewöhnliche Anwendung die Windows-WebAuthn-API direkt auf, gibt sie den Origin selbst an – anders als ein Browser ist sie nicht an die echte Seitenherkunft gebunden. Sie kann also eine Assertion für login.microsoft.com, github.comoder jeden beliebigen Dienst anfordern. Aus Sicht des Opfers sieht alles normal aus: Der gewohnte Windows-Hello-Dialog erscheint, man legt den Finger auf den Sensor – und die Malware erhält die fertige Assertion und reicht sie an den Operator weiter.

Mehrere Bausteine machen das alltagstauglich und gefährlich:

• Prompt Flooding – das Passkey-Äquivalent zur MFA-Fatigue, im Grunde ein Angreifer, der so lange Sturm klingelt, bis man nur zum Ruhigwerden öffnet. Nach jedem Abbrechen startet er die Zeremonie neu, bis die Challenge abläuft. Grafnetter merkt an, dass selbst erfahrene Security-Leute solche Prompts reflexartig bestätigen.
• Application-Metadata-Spoofing – der im Dialog angezeigte Anwendungsname stammt aus den Versionsinformationen der EXE. Wenige Zeilen im .NET-Projekt (AssemblyTitle, Authors) genügen, damit „Requested by Microsoft Edge (Microsoft Corporation)“ erscheint.
• Window-Handle-Injection – dank der ungepatchten Lücke (Nr. 3) erscheint der Prompt als modaler Dialog des echten Browsers und wird so nahezu ununterscheidbar von einer legitimen Anfrage.
• Remote-Desktop-Phishing – Windows leitet Passkey-Anfragen standardmäßig über RDP und Hyper-V-Enhanced-Session weiter (via MS-RDPEWA). Läuft Malware auf dem entfernten Host, kann sie den Prompt lokal beim Nutzer auslösen.

Ergänzend beschreibt das Paper den Passkey Detour Attack: Eine mit Microsoft Detours in webauthn.dll eingeklinkte Hook leitet die Zeremonie in Echtzeit um – wahlweise zum Abgreifen der Assertion, zum Unterschieben einer eigenen Challenge oder beidem gleichzeitig.

Eng verwandt ist der Angriff auf den Registrierungsprozess: Statt eine einzelne Anmeldung abzugreifen, hinterlegt ein Angreifer mit ausreichenden Rechten einen eigenen, dauerhaften Passkey im Konto des Opfers (im Paper als Shadow Passkey bezeichnet). Wie sich dieser Persistenz-Mechanismus in der Praxis über Social Engineering und legitime Registrierungs-Flows ausnutzen lässt, zeigen die realen Kampagnen in unseren Beiträgen zu Windows-Hello-Schlüsseln als Angriffsfläche und zur Passkey-Vishing-Masche gegen Microsoft 365.

Synchronisierte vs. gerätegebundene Passkeys

Ein eigenes Kapitel gilt Software-Authenticatoren. Gerätegebundene Passkeys verlassen ihre Hardware nie – der Schlüssel bleibt fest im Schloss. Synchronisierte Passkeys sind eher wie Kopien Ihres Hausschlüssels, die Sie in einem Cloud-Schließfach ablegen, damit Sie von Handy, Tablet und Laptop aus hineinkommen. Bequem – aber die ganze Sammlung ist nur so sicher wie das Zahlenschloss am Schließfach, also das Konto-Passwort des Vaults. Das kehrt das Sicherheitsversprechen um: Ein phishing-resistentes Credential wird aus einem phishbaren Passwort abgeleitet.

Das Paper zeigt konkret, wie Exportformate zum Problem werden: KeePassXC exportiert Passkeys im Klartext (immerhin mit deutlicher Warnung), Bitwarden schreibt sie im standardmäßig unverschlüsselten JSON-Export offen heraus, und auch das aufkommende Credential Exchange Format (CXF) legt das Schlüsselmaterial offen, sobald eine Datei außerhalb des geschützten Transfers landet. Malware, die Laufwerke gezielt nach solchen Dateien durchsucht, ist leicht vorstellbar.

Die klare Empfehlung: Für hochwertige Konten – der Entra-ID-Global-Admin ist das Paradebeispiel – gehören gerätegebundene Authenticatoren her, nicht synchronisierte.

Handlungsempfehlungen für die Praxis

Grafnetter bleibt trotz allem ausdrücklich optimistisch: Passkeys sind ein klarer Fortschritt gegenüber Passwörtern, und der Umstieg sollte weitergehen. Die Botschaft ist nicht „Passkeys sind unsicher“, sondern „Passkeys allein reichen nicht“.

Für Web-Application-Entwickler:

• Alle serverseitigen Prüfungen gemäß WebAuthn-Spezifikation implementieren – inklusive Erkennung wiederverwendeter Challenges und geklonter Schlüssel.
• Challenges an die Nutzer-Session binden.
• Bewährte WebAuthn-SDKs statt Eigenbau einsetzen.
• Keine sensiblen Authentifizierungsdaten in Logs schreiben.

Für Pentester und Red Teamer:

• Passkey-Implementierungen aktiv in Engagements aufnehmen.
• Gezielt auf Replay- und Relay-Schwächen prüfen.
• Assertion-Tampering testen (UV-/UP-Flags, Signatur, Zähler).

Für IT-Administratoren:

• Windows 11 konsequent aktuell halten.
• In Conditional-Access-Policies nicht allein auf das Kriterium „phishing-resistente MFA“ vertrauen (siehe dazu auch unsere Analyse der identitätsbasierten Cloud-Angriffe rund um Storm-2949).
• Ausführung nicht autorisierter Anwendungen und Installation ungeprüfter Browser-Erweiterungen unterbinden.
• Passkey-Attestation für hochwertige Nutzer erzwingen und gerätegebundene Authenticatoren bevorzugen.
• WebAuthn-Nutzung durch Nicht-Browser-Anwendungen über die Windows-Ereignisprotokolle detektieren.
• Anwender sensibilisieren, unerwartete Passkey-Prompts nicht reflexartig zu bestätigen.

FAQ zu Passkey-Sicherheit

Sind Passkeys unsicher? Nein. Passkeys sind weiterhin deutlich sicherer als Passwörter. Die Pass-the-Passkey-Forschung zeigt Schwächen in der Implementierung (Windows 11, Entra ID, Passwort-Manager-Exporte), nicht im kryptografischen Konzept von WebAuthn selbst.

Was ist Pass-the-Passkey? Ein Sammelbegriff für Angriffe, bei denen gültige WebAuthn-Assertions abgegriffen, weitergeleitet oder erneut abgespielt werden – analog zu Pass-the-Hash und NTLM-Relay. Ziel ist es, eine Identität zu übernehmen, ohne den privaten Schlüssel je zu besitzen.

Bin ich als Anwender betroffen? Zwei der drei Schwachstellen sind mit aktuellen Windows- und Entra-ID-Updates behoben. Das Credential-UI-Window-Handle-Spoofing bleibt offen. Der wirksamste Schutz ist Wachsamkeit bei unerwarteten Passkey-Dialogen plus eine gehärtete Endpoint-Umgebung.

Synchronisierte oder gerätegebundene Passkeys – was ist besser? Für Alltagskonten sind synchronisierte Passkeys ein guter, bequemer Kompromiss. Für privilegierte oder hochsensible Konten sollten gerätegebundene Authenticatoren (z. B. FIDO2-Sicherheitsschlüssel oder TPM-gestütztes Windows Hello) mit erzwungener Attestation verwendet werden.

Reicht „phishing-resistente MFA“ in Conditional-Access-Policies als Schutz? Nicht allein. Die Forschung zeigt, dass sich dieses Kriterium unter bestimmten Bedingungen erfüllen lässt, obwohl die Identität kompromittiert wurde. Es sollte Teil eines mehrschichtigen Konzepts sein.

Weiterführende Artikel auf diesem Blog

• Wenn passwortlose Authentifizierung zur Angriffsfläche wird – „Borrowing Windows Hello Keys“ – warum nicht die Kryptografie, sondern der Registrierungsprozess das Ziel ist.
• Neue Passkey-Betrugsmasche gegen Microsoft 365 (Vishing) – Social Engineering gegen die Entra-Passkey-Registrierung.
• Storm-2949: Identität als Sicherheitsperimeter – Conditional Access, Device-Code-Phishing und phishing-resistente MFA im Kontext realer Cloud-Angriffe.
• KerberLoss und ResetNightmare – Identity-Confusion-Angriffe auf Active Directory als verwandtes Muster.

Fazit

Die Pass-the-Passkey-Reihe ist ein Lehrstück dafür, dass Sicherheitsversprechen an der Umsetzung hängen. WebAuthn ist kryptografisch solide – aber ausgelassene Server-Prüfungen, ein zu geschwätziges Event Log und ein nicht validiertes Fenster-Handle reichen, um phishing-resistente MFA praktisch zu umgehen. Wer Passkeys einführt (und das sollte man), plant serverseitige Konformität, Endpoint-Härtung und Monitoring von Anfang an mit ein. Für die wirklich kritischen Identitäten führt an gerätegebundenen Authenticatoren mit Attestation kaum ein Weg vorbei.

---

Quelle: Michael Grafnetter, „Pass-the-Passkey Family of Attacks“, SpecterOps / Black Hat USA 2026. Stand der Angaben: White Paper Version 1.0 vom 17. Juli 2026 – Microsoft kann seither weitere Mitigationen ausgerollt haben.

Stand: 7. August 2026 – beide Schwachstellen sind gepatcht (März bzw. April 2026)

Kurzfassung: Auf der Black Hat USA 2026 hat Semperis-Researcher Shai Laron zwei Active-Directory-Schwachstellen offengelegt, die er bereits Ende 2025 an Microsoft gemeldet hatte. KerberLoss (CVE-2026-25177, CVSS 8.8) und ResetNightmare (CVE-2026-27912, CVSS 8.0) nutzen beide dasselbe Grundmuster: unsichtbare Unicode-Zeichen bringen Domänencontroller dazu, zwei unterschiedliche Objekte für dasselbe zu halten. Ergebnis: Kerberos-Downgrade auf NTLM, Denial of Service – und im schlimmsten Fall vollständige Domänenübernahme. Microsoft hat beide Lücken geschlossen. Wer seine Domänencontroller auf einem Cumulative Update ab April 2026 hält, ist geschützt. Wer nicht, hat ein akutes Problem: Die technischen Details und ein PoC sind jetzt öffentlich.

---

Warum Active Directory hier so empfindlich ist

Seit Windows 2000 ist Kerberos das Standardprotokoll für die Authentifizierung innerhalb einer AD-Domäne. Es übernimmt die sichere Authentifizierung von Benutzern und Computern, stellt kryptografische Tickets aus, ermöglicht Single Sign-on und vermeidet die Übertragung von Kennwörtern über das Netz.

Damit das funktioniert, muss der Domänencontroller Identitäten eindeutig auflösen können. Genau an dieser Stelle setzen beide Schwachstellen an – nicht an der Kryptografie.

Eine wichtige Präzisierung, die in vielen Meldungen untergeht: Der eigentliche Fehler liegt nicht im Kerberos-Protokoll selbst, sondern in der Namensvalidierung von Active Directory Domain Services. Das NVD ordnet CVE-2026-25177 der Kategorie CWE-641 zu – „improper restriction of names for files and other resources“. Kerberos ist der Weg, über den sich der Fehler auswirkt.

Das gemeinsame Grundmuster: Identity Confusion

Laron ging der Frage nach, welche Unicode-Zeichen in AD-Objektnamen zulässig sind, dabei aber unsichtbar bleiben. Das Ergebnis: Es existieren Zeichen, die serverseitig durch die LDAP-Verarbeitung rutschen und dazu führen, dass zwei Werte optisch identisch, logisch aber verschieden sind. Prüfungen auf Eindeutigkeit greifen damit ins Leere.

Aus dieser einen Beobachtung entstehen zwei Angriffe.

KerberLoss (CVE-2026-25177): kollidierende SPNs

Service Principal Names identifizieren Dienstinstanzen gegenüber Kerberos – etwa cifs für SMB-Freigaben, TERMSRV für RDP, dazu LDAP und HTTP. SPNs müssen domänenweit eindeutig sein, sonst kann Kerberos ein Ticket nicht dem richtigen Dienstkonto zuordnen.

Über eingeschleuste unsichtbare Zeichen lässt sich diese Eindeutigkeitsprüfung umgehen und ein kollidierender SPN registrieren. Die Folgen gestaffelt:

• Kerberos-Downgrade: Der DC kann den SPN nicht sauber auflösen, die Kerberos-Authentifizierung schlägt fehl, Clients fallen auf NTLM zurück.
• Denial of Service: Betroffene Dienste sind nicht mehr per Kerberos erreichbar.
• Rechteausweitung: Microsoft stuft die Lücke als Elevation of Privilege ein.

Bewertung durch Microsoft: Wichtig, CVSS v3.1 8.8, Vektor AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Also netzwerkbasiert, geringe Privilegien nötig, keine Nutzerinteraktion, hohe Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit.

Warum der NTLM-Fallback der eigentliche Hebel ist: NTLM wird aus Kompatibilitätsgründen weiterhin unterstützt, ist aber seit Jahren Ziel von NTLM-Relay- und Pass-the-Hash-Angriffen. Ein erzwungener Downgrade entfaltet seine Wirkung erst dann, wenn NTLM in der Umgebung überhaupt noch verfügbar ist.

ResetNightmare (CVE-2026-27912): UPN gegen sAMAccountName

Die zweite Schwachstelle ist die kritischere. Hier wird einem kontrollierten Objekt ein UserPrincipalName zugewiesen, der dem sAMAccountName eines anderen – beliebigen – Kontos entspricht. Der DC verwechselt daraufhin die Identitäten, was bis zur Übernahme von Domain-Admin-Konten führt.

Was ein Angreifer dafür braucht:

1. GenericWrite-Berechtigungen auf ein beliebiges Benutzer- oder Computerobjekt der Domäne – oder die Möglichkeit, solche Objekte anzulegen (ohne Rückgriff auf MachineAccountQuota).
2. Ein Zielkonto, dessen Passwort ausreichend alt ist. Da die Minimum Password Age in AD standardmäßig bei einem Tag liegt, ist diese Bedingung in der Praxis fast immer erfüllt.

Punkt 1 ist die entscheidende Einschränkung – und zugleich der Grund, warum die Lücke in vielen gewachsenen Umgebungen trotzdem trägt: Delegierte Schreibrechte auf OUs, Helpdesk-Gruppen mit zu weiten ACLs und historisch vergebene GenericWrite-Rechte sind eher die Regel als die Ausnahme.

Microsoft führt die Lücke als Privilege-Escalation in Windows Kerberos mit CVSS 8.0. In der Advisory-Beschreibung ist von einer fehlerhaften Autorisierung bei der Prüfung von Kerberos-Service-Ticket-Anfragen die Rede, über die ein authentifizierter Angreifer Sicherheitsprüfungen umgehen und bis zu Domain-Admin-Rechten aufsteigen kann. Semperis beschreibt denselben Sachverhalt konkreter aus Angreifersicht – über den kollidierenden UPN.

Bemerkenswert ist die Fehlerklasse: kein Speicherfehler, kein Buffer Overflow, sondern ein Logikfehler im Identitäts-Handling. Solche Schwachstellen umgehen bestehende Schutzmechanismen, ohne dass Schadcode auf einem Domänencontroller ausgeführt werden muss – klassische EDR-Erkennung greift hier nicht.

Zeitleiste und Patch-Status

	KerberLoss	ResetNightmare
CVE	CVE-2026-25177	CVE-2026-27912
An MSRC gemeldet	26.11.2025	17.12.2025
Von MSRC bestätigt	17.01.2026	09.01.2026
Patch verfügbar	10.03.2026 (Patchday)	14.04.2026 (Patchday)
Microsoft-Kategorie	Active Directory Domain Services, Elevation of Privilege	Windows Kerberos, Elevation of Privilege
CVSS v3.1	8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)	8.0
Betroffen	alle unterstützten Windows-Server-Versionen in der DC-Rolle – die exakte Produkt- und KB-Liste steht im MSRC Update Guide unter „Security Updates“	dito

Die Offenlegung auf der Black Hat USA 2026 (4.–6. August, Mandalay Bay, Las Vegas) erfolgte damit koordiniert und rund vier Monate nach dem letzten Patch.

Konkrete Maßnahmen

Priorität 1 – Patchstand der Domänencontroller prüfen. Beide Fehler liegen serverseitig: KerberLoss in AD DS, ResetNightmare im Kerberos-KDC. Entscheidend ist damit ausschließlich der Patchstand der DCs, nicht der von Member-Servern oder Clients.

Da Windows-Updates kumulativ sind, deckt jedes Cumulative Update ab dem 14. April 2026 beide CVEs ab – der März-Fix ist darin enthalten. Prüfen Sie explizit auch selten gepatchte DCs in Außenstellen, DR-Standorten und RODCs.

Eine praktische Falle: Nicht jedes April-Update ist das richtige. KB5082123 stammt zwar aus dem April 2026, behebt CVE-2026-25177 aber nicht – es adressiert die auslaufenden Secure-Boot-Zertifikate. Wer nur dieses Paket eingespielt hat, bleibt exponiert. Verifizieren Sie den Build-Stand pro DC gegen die im MSRC Update Guide gelistete KB, statt sich auf „im April gepatcht“ zu verlassen.

Sonderfall Altsysteme: Windows Server 2012 und 2012 R2 erhalten Updates nur noch bei aktivem ESU-Vertrag, und dieses Programm endet im Herbst 2026. DCs auf nicht mehr unterstützten Versionen bekommen keinen Fix – dort bleibt nur die Härtung der Berechtigungen, und mittelfristig die Migration.

Priorität 2 – Erkennung einrichten. Ohne spezialisiertes Tooling führt der Weg über SACLs zur Überwachung von AD-Objektänderungen. Ist die SACL konfiguriert, zeigt Event ID 5136 („A directory service object was modified“) im Security-Log der DCs die relevanten Änderungen:

• KerberLoss: Hinzufügen eines ServicePrincipalName, der mit einem bestehenden kollidiert.
• ResetNightmare: Hinzufügen eines UserPrincipalName, der dem sAMAccountName eines anderen Kontos entspricht.

Ergänzend: Event ID 11 im System-Log meldet erkannte doppelte SPNs; setspn -X findet Kollisionen im Bestand.

Priorität 3 – Angriffsfläche verkleinern.

• Nicht-Standard-Berechtigungen auf Benutzer- und Computerobjekten inventarisieren, insbesondere GenericWrite und Write-Property. Least Privilege macht beide Angriffe deutlich aufwendiger.
• MachineAccountQuota auf 0 setzen und Computerkonten kontrolliert über delegierte Prozesse anlegen.
• NTLM reduzieren oder abschalten, wo möglich – erst per Audit-Modus messen, dann blockieren. Ein Kerberos-Downgrade ins Leere läuft, wenn NTLM nicht mehr akzeptiert wird.
• Tiering und Privileged Access Workstations für administrative Konten konsequent umsetzen.
• AD regelmäßig auf Fehlkonfigurationen prüfen – Werkzeuge wie Purple Knight oder PingCastle liefern einen belastbaren Ausgangsbefund.

Einordnung

Der eigentliche Lerneffekt liegt nicht in den beiden CVEs, sondern im Muster. Angreifer verlagern ihren Fokus seit Jahren von Endpunkten und Servern hin zu Identitäten, Authentifizierungsprotokollen, Vertrauensbeziehungen, Active Directory und Entra ID. Ein Browser-Bug liefert Codeausführung auf einem Endgerät. Ein Fehler in der Identitätsschicht verändert dagegen, wie Vertrauen in der gesamten Umgebung aufgelöst wird.

Beide Schwachstellen zeigen außerdem, wie wenig es dafür braucht: kein Exploit-Code, kein Speicherfehler, sondern ein Zeichen, das niemand sieht. Für Unternehmen heißt das, Active Directory nicht als Verzeichnisdienst zu betrachten, sondern als geschäftskritische Sicherheitskomponente mit eigenem Monitoring, eigenem Patch-SLA und eigenem Berechtigungskonzept.

Quellen

• Semperis Security Research (Shai Laron): Identity Crisis: Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover – semperis.com/blog
• Black Hat USA 2026, Briefing vom August 2026, Mandalay Bay Convention Center, Las Vegas
• Microsoft Security Response Center, Update Guide: CVE-2026-25177 (Patchday 10.03.2026) und CVE-2026-27912 (Patchday 14.04.2026) – dort auch die maßgebliche Liste betroffener Produkte und KB-Nummern
• NVD: CVE-2026-25177 (CVSS v3.1 8.8, CWE-641), veröffentlicht 10.03.2026, CPE-Anreicherung 13.03.2026

Passwortlose Authentifizierung gilt als einer der wichtigsten Fortschritte der letzten Jahre. Technologien wie Windows Hello for Business (WHfB) und FIDO2-Passkeys schützen Benutzer vor Phishing, Credential Stuffing und vielen klassischen Passwortangriffen.

Die aktuelle Forschung von Security-Researcher Dirk-jan Mollema zeigt jedoch eindrucksvoll: Nicht immer ist die Kryptographie das schwächste Glied – häufig sind es die Identitäts- und Provisionierungsprozesse.

Windows Hello und FIDO2 – sicher, aber unterschiedlich

Windows Hello for Business und FIDO2 basieren beide auf asymmetrischer Kryptographie.

Statt eines Passworts existiert ein Schlüsselpaar:

• Der private Schlüssel verbleibt auf dem Gerät.
• Der öffentliche Schlüssel wird beim Identitätsanbieter registriert.
• Die Anmeldung erfolgt über eine kryptographische Signatur statt über ein Passwort.

Dennoch unterscheiden sich beide Technologien:

Windows Hello for Business ist eng mit Microsoft Entra ID, der Geräteidentität und dem Primary Refresh Token (PRT) verzahnt. Es dient nicht nur der Anmeldung am Gerät, sondern auch als Grundlage für Single Sign-on innerhalb der Microsoft-Welt.

FIDO2-Passkeys hingegen folgen dem offenen WebAuthn-/CTAP2-Standard und können auf Hardware-Sicherheitsschlüsseln, Smartphones oder Plattformen wie Windows, Android oder iOS gespeichert werden.

Beide gelten weiterhin als phishing-resistent. Genau diese Aussage wird durch die Forschung auch nicht widerlegt.

Der Angriff richtet sich nicht gegen die Kryptographie

Der Titel „Borrowing Windows Hello Keys“ ist bewusst provokant gewählt.

Tatsächlich werden keine TPM-geschützten Schlüssel ausgelesen oder gestohlen.

Auch die Kryptographie von Windows Hello oder FIDO2 wird nicht gebrochen.

Stattdessen nutzt der Angriff die Möglichkeit aus, einen neuen Authentifizierungsschlüssel im Namen eines Benutzers zu registrieren.

Damit verschiebt sich die Angriffsfläche von der eigentlichen Authentifizierung hin zur Identitätsverwaltung.

Die Schlüsselrolle des Primary Refresh Tokens

Im Mittelpunkt steht der Primary Refresh Token (PRT).

Ein PRT ist weit mehr als ein gewöhnlicher OAuth-Refresh-Token. Er bildet die Vertrauensbasis für:

• Single Sign-on
• Gerätezustand
• Windows Hello for Business
• Tokenanforderungen gegenüber Microsoft Entra ID

Kann ein Angreifer unter geeigneten Voraussetzungen einen gültigen PRT oder einen vergleichbaren Vertrauensstatus erlangen, lassen sich Microsoft-interne Registrierungsprozesse nutzen, um neue Authentifizierungsschlüssel zu hinterlegen.

Genau darin liegt die eigentliche Erkenntnis der Forschung.

Warum “Borrowing” treffender ist als “Stealing”

Der Begriff „Borrowing“ beschreibt den Angriff deutlich besser als „Stealing“.

Der ursprüngliche Windows-Hello-Schlüssel bleibt unverändert auf dem Gerät des Benutzers gespeichert.

Stattdessen registriert der Angreifer einen zusätzlichen Schlüssel für dasselbe Benutzerkonto.

Der legitime Benutzer kann sich weiterhin anmelden.

Gleichzeitig besitzt nun aber auch der Angreifer einen gültigen kryptographischen Nachweis für dieses Konto.

Aus Sicht von Microsoft Entra ID handelt es sich um einen legitim registrierten Authentifizierungsschlüssel.

Betrifft das auch FIDO2?

Hier lohnt sich eine differenzierte Betrachtung.

Der Angriff bricht nicht den FIDO2-Standard und kompromittiert auch keine bereits registrierten Hardware-Sicherheitsschlüssel.

Ein YubiKey oder ein anderer FIDO2-Token lässt sich dadurch weder klonen noch auslesen.

Allerdings zeigt die Forschung, dass nicht die Authentifizierung selbst, sondern der Registrierungsprozess neuer Credentials zum Angriffsziel werden kann.

Je nachdem, welche Microsoft-Authentifizierungsmethode verwendet wird – Windows Hello for Business oder Entra-Passkeys auf Basis von FIDO2 –, können ähnliche Provisionierungsmechanismen betroffen sein.

Die eigentliche Schwachstelle liegt also nicht im kryptographischen Verfahren, sondern in den Prozessen, mit denen neue Vertrauensbeziehungen geschaffen werden.

Warum das für Unternehmen relevant ist

Viele Organisationen konzentrieren sich verständlicherweise auf den Schutz der Endgeräte:

• TPM
• Secure Boot
• Biometrie
• FIDO2
• Multifaktor-Authentifizierung

Diese Schutzmaßnahmen bleiben wichtig.

Die Forschung macht jedoch deutlich, dass ebenso viel Aufmerksamkeit auf die Identitätsplattform gelegt werden muss.

Wer neue Geräte oder Authentifizierungsschlüssel registrieren darf, welche Token hierfür verwendet werden und wie diese Vorgänge überwacht werden, ist mindestens genauso entscheidend.

Empfehlungen für Administratoren

Unternehmen sollten insbesondere folgende Bereiche überprüfen:

• Conditional-Access-Richtlinien konsequent einsetzen.
• Registrierungen neuer Geräte überwachen.
• Neue Windows-Hello- und Passkey-Registrierungen protokollieren.
• Aktivitäten rund um Primary Refresh Tokens beobachten.
• Microsoft Defender for Identity und Microsoft Entra Audit Logs aktiv auswerten.
• Registrierungsprozesse regelmäßig überprüfen und unnötige Berechtigungen entfernen.

Fazit

Die Forschung von Dirk-jan Mollema zeigt keine Schwäche in Windows Hello oder FIDO2 selbst.

Stattdessen macht sie deutlich, dass moderne passwortlose Authentifizierung nur so sicher ist wie die Prozesse, mit denen neue Authentifizierungsschlüssel registriert und Vertrauensbeziehungen aufgebaut werden.

Für Unternehmen bedeutet das: TPM, Biometrie und FIDO2 bleiben zentrale Sicherheitsbausteine. Gleichzeitig müssen aber auch Identitätsplattformen wie Microsoft Entra ID, Primary Refresh Tokens und die Registrierung neuer Credentials genauso sorgfältig geschützt und überwacht werden.

Passwortlose Authentifizierung ist damit keineswegs unsicher – sie erfordert lediglich einen erweiterten Blick auf die gesamte Vertrauenskette.

Quellen und weiterführende Informationen

Die in diesem Artikel beschriebenen Erkenntnisse basieren auf der Forschung von Dirk-jan Mollema, einem renommierten Security Researcher im Bereich Microsoft Entra ID, Active Directory und Identity Security.

Originalartikel:

• Borrowing Windows Hello Keys – https://dirkjanm.io/borrowing-windows-hello-keys/

Weitere Informationen:

• Microsoft Learn: Windows Hello for Business
• Microsoft Learn: Microsoft Entra Passkeys (FIDO2)
• Microsoft Learn: Primary Refresh Tokens (PRT)

Microsoft beendet die Exchange Web Services in Exchange Online. Am 1. Oktober 2026 beginnt die technische Durchsetzung, am 1. April 2027 wird EWS endgültig abgeschaltet.

Der entscheidende Termin liegt jedoch früher: Wer bis Ende August 2026 eine geprüfte Zulassungsliste konfiguriert und EWSEnabled auf True setzt, wird von der automatischen Abschaltung am 1. Oktober ausgenommen. Wer die Frist verstreichen lässt, gibt die Kontrolle über den Zeitpunkt aus der Hand.

Für Unternehmen bedeutet das: bestehende Anwendungen, Integrationen und Dienste mit EWS-Zugriff müssen jetzt identifiziert und bewertet werden. Andernfalls können geschäftskritische Lösungen ab Oktober 2026 unerwartet den Zugriff auf Exchange Online verlieren.

Mit EWSAllowedAppIDs steht seit Sommer 2026 die passende Konfigurationsmöglichkeit bereit. Sie ermöglicht es Administratoren, gezielt festzulegen, welche Anwendungen EWS vorübergehend weiterhin verwenden dürfen.

Ein wichtiger Hinweis zum Geltungsbereich: Die Abschaltung betrifft ausschließlich Exchange Online. Exchange Server in lokalen Installationen ist nicht betroffen und behält EWS unverändert.

Warum die EWS-Abschaltung relevant ist

EWS wird seit fast zwanzig Jahren für den Zugriff auf Exchange-Daten eingesetzt. Dazu gehören unter anderem Postfächer, Kalender, Kontakte und weitere Exchange-Funktionen.

In vielen Umgebungen wird EWS noch durch ältere Anwendungen, Archivlösungen, Backup-Produkte, Workflow-Systeme oder individuelle Integrationen verwendet. Häufig sind diese Abhängigkeiten nicht vollständig dokumentiert.

Genau darin liegt das Risiko. Eine Anwendung kann technisch unauffällig funktionieren und dennoch von EWS abhängig sein. Wird der Zugriff im Rahmen der Abschaltung blockiert, fällt die Abhängigkeit möglicherweise erst durch eine Störung auf.

Unternehmen sollten daher nicht bis 2027 warten. Die ersten konkreten Auswirkungen können bereits ab Oktober 2026 auftreten — und die Vorbereitungsfrist endet noch früher.

Die wichtigsten Termine im Überblick

Termin	Was passiert
Juni 2026	EWSAllowedAppIDs wird ausgerollt und kann konfiguriert werden
Ende August 2026	Letzte Frist: Allow List konfigurieren und EWSEnabled=True setzen, um von der Umstellung am 1. Oktober ausgenommen zu werden
September 2026	Microsoft befüllt Allow Lists automatisch für Mandanten, die selbst keine erstellt haben — auf Basis der erkannten Nutzung
1. Oktober 2026	Beginn der technischen Durchsetzung. Mandanten mit EWSEnabled=Null werden auf False umgestellt, EWS wird blockiert
1. April 2027	Endgültige Abschaltung. Die Steuerung über EWSEnabled wird Administratoren entzogen. Keine Ausnahmen

Die automatische Befüllung durch Microsoft im September ist ausdrücklich kein Ersatz für eigene Arbeit. Microsoft übernimmt keine Verantwortung für die Richtigkeit der Liste, und es können Anwendungen enthalten sein, die man gar nicht zulassen möchte. Die Verantwortung für den Inhalt bleibt beim Administrator.

Sollte die August-Frist verpasst werden, ist die Lage nicht aussichtslos: EWS lässt sich nach dem 1. Oktober durch Setzen von EWSEnabled=True wieder aktivieren. Dabei kommt es allerdings zu einer Serviceunterbrechung, und diese Option besteht nur bis zum 1. April 2027.

Was ist EWSAllowedAppIDs?

EWSAllowedAppIDs ist eine mandantenweite Zulassungsliste für Anwendungs-IDs aus Microsoft Entra ID.

Administratoren können damit festlegen, welche Anwendungen weiterhin über EWS auf Exchange Online zugreifen dürfen. Anwendungen, die nicht in dieser Liste enthalten sind, werden ab Beginn der Durchsetzung blockiert.

Die Funktion unterstützt Unternehmen in drei Bereichen. Sie hilft dabei, vorhandene EWS-Abhängigkeiten sichtbar zu machen, sie begrenzt den Zugriff auf ausdrücklich genehmigte Anwendungen, und sie reduziert das Risiko ungeplanter Ausfälle während der Abschaltungsphase.

Abgrenzung zur bestehenden EwsAllowList

Wichtig ist die Unterscheidung von der EwsAllowList, die Exchange schon seit vielen Jahren kennt. Diese arbeitet auf Basis des User-Agent-Strings, also einer Textkennung im HTTP-Header, die sich leicht fälschen lässt. EWSAllowedAppIDs stützt sich dagegen auf die in Entra ID registrierte Anwendungs-ID und ist damit deutlich belastbarer.

Beide Mechanismen können parallel wirksam sein. Eine Anwendung muss beide Prüfungen bestehen, um Zugriff zu erhalten, wobei die neue AppID-Liste Vorrang hat. Wer bereits eine EwsApplicationAccessPolicy konfiguriert hat, sollte diese Konstellation vor der Umstellung gezielt prüfen.

Geltungsbereich des Parameters

EWSAllowedAppIDs wirkt ausschließlich auf direkte EWS-Verbindungen über SOAP. Anfragen über Microsoft Graph oder den REST-Endpunkt sind davon nicht betroffen.

Was ändert sich ab Oktober 2026?

Verhalten vor Oktober 2026

Das aktuelle Verhalten ist bewusst durchlässig gestaltet, damit Administratoren die Konfiguration testen können, ohne den Produktivbetrieb zu gefährden.

• Ist EWSEnabled nicht konfiguriert (Null), wird der gesamte EWS-Datenverkehr zugelassen. Eine konfigurierte Zulassungsliste hat in diesem Fall keinerlei Wirkung.
• Ist EWSEnabled auf True gesetzt und keine Zulassungsliste vorhanden, wird ebenfalls der gesamte EWS-Datenverkehr zugelassen.
• Ist EWSEnabled auf True gesetzt und eine Zulassungsliste konfiguriert, sind grundsätzlich nur die eingetragenen Anwendungen vorgesehen. Die Durchsetzung ist in dieser Phase jedoch noch nicht vollständig scharf geschaltet.
• Ist EWSEnabled auf False gesetzt, wird EWS vollständig blockiert.

Verhalten ab Oktober 2026

• Ist EWSEnabled auf True gesetzt, aber keine Zulassungsliste konfiguriert, wird der gesamte EWS-Datenverkehr blockiert.
• Ist EWSEnabled auf True gesetzt und eine Zulassungsliste vorhanden, dürfen ausschließlich die enthaltenen Anwendungen EWS verwenden.
• Ist EWSEnabled auf False gesetzt, bleibt EWS vollständig blockiert.
• Bei Mandanten, deren EWSEnabled am 1. Oktober 2026 noch auf Null steht, wird der Wert im Rahmen des stufenweisen Rollouts auf False geändert. Damit wird EWS für alle Anwendungen des Mandanten blockiert.

Die wichtigste Änderung lautet daher:

EWSEnabled=True reicht ab Oktober 2026 nicht mehr aus, um EWS-Zugriff allgemein zu erlauben. Aus einer Konfiguration, die heute „alles erlauben“ bedeutet, wird dann „nichts erlauben“.

Unternehmen, die EWS nach diesem Zeitpunkt weiterhin benötigen, müssen eine vollständige und geprüfte EWSAllowedAppIDs-Liste konfigurieren.

Scream Tests: Störungen vor dem eigentlichen Stichtag

Microsoft hat angekündigt, vor der endgültigen Abschaltung sogenannte Scream Tests durchführen zu können. Dabei wird EWS für kurze Zeiträume deaktiviert und anschließend wieder aktiviert, um versteckte Abhängigkeiten sichtbar zu machen.

Für Unternehmen ist das ein weiteres Argument für frühzeitiges Handeln: Wer EWSEnabled bereits jetzt auf True setzt, ist von diesen Tests nicht betroffen.

Welche Unternehmen sind betroffen?

Betroffen sind grundsätzlich alle Organisationen, die Exchange Online einsetzen und Anwendungen oder Dienste mit EWS-Zugriff betreiben.

Dazu zählen häufig:

• Archivierungslösungen
• Backup-Anwendungen
• Kalender- und Terminlösungen
• Workflow-Systeme
• CRM- und ERP-Integrationen
• Individuell entwickelte Anwendungen und Skripte
• Ältere Microsoft-365-Integrationen
• Multifunktionsgeräte und Raumbuchungssysteme

Auch Microsoft-Erstanbieter-Anwendungen können weiterhin EWS verwenden. Microsoft nennt hier ausdrücklich Beispiele wie Office-Clients oder Power Query für Excel. Werden sie im EWS-Nutzungsbericht angezeigt und weiterhin benötigt, müssen auch deren Anwendungs-IDs in die Liste aufgenommen werden.

Verantwortlich für die Vorbereitung sind nicht nur Exchange-Administratoren. Ebenso eingebunden werden sollten Application Owner, Software-Hersteller, interne Entwickler, Betriebsteams und externe Dienstleister.

Schritt 1: EWS-Nutzung erfassen

Der erste Schritt besteht darin, alle aktiven EWS-Abhängigkeiten im Mandanten zu identifizieren. Dafür stehen mehrere Quellen zur Verfügung:

• Der EWS-Nutzungsbericht im Microsoft 365 Admin Center
• Die monatlichen Message-Center-Beiträge, in denen Microsoft mandantenspezifische Nutzungszusammenfassungen bereitstellt
• Die Anmeldeprotokolle in Microsoft Entra ID, gefiltert auf EWS-Aktivität
• Die von Microsoft veröffentlichten Skripte aus dem Beitrag „Notes From the Field: Finding and Remediating EWS App Usage Before Retirement“

Die Nutzungsberichte liefern Anwendungs-IDs, aber nicht immer verständliche Namen. Zur Auflösung eignet sich das Microsoft Graph PowerShell-Modul:

powershell

Get-MgServicePrincipal -Filter "appId eq '11111111-2222-3333-4444-555555555555'" |
    Select-Object DisplayName, AppId

Einzelne IDs gehören zu internen Microsoft-Komponenten und lassen sich darüber nicht immer sinnvoll auflösen. Microsoft pflegt eine Referenzliste der Erstanbieter-Anwendungs-IDs, die in diesen Fällen weiterhilft.

Für jede gefundene Anwendung sollten mindestens folgende Fragen beantwortet werden:

• Wer ist für die Anwendung verantwortlich?
• Welche Geschäftsprozesse hängen von ihr ab?
• Welche Funktionen werden über EWS genutzt?
• Ist die Anwendung weiterhin erforderlich?
• Gibt es bereits eine Version mit Microsoft-Graph-Unterstützung?
• Ist eine Migration geplant?

Ohne diese Zuordnung besteht die Gefahr, Anwendungen vorschnell zuzulassen oder kritische Abhängigkeiten zu übersehen.

Schritt 2: Anwendungen bewerten

Nicht jede EWS-Anwendung sollte automatisch in die Zulassungsliste aufgenommen werden.

Zunächst sollte geprüft werden, ob die Anwendung noch benötigt wird. Anschließend ist zu klären, ob eine aktuelle Version oder eine alternative Lösung verfügbar ist, die Microsoft Graph verwendet.

Microsoft Graph ist für die meisten Exchange- und Microsoft-365-Szenarien die strategisch vorgesehene Schnittstelle. Für einzelne administrative Aufgaben kommen alternativ die Exchange Online Admin API oder Exchange Online PowerShell in Frage. EWSAllowedAppIDs sollte in keinem Fall als dauerhafte Zukunftslösung verstanden werden.

Die Zulassungsliste schafft vor allem Zeit für eine kontrollierte Migration. Sie verhindert kurzfristige Ausfälle, ersetzt aber nicht die Modernisierung bestehender Integrationen.

Ein besonderer Hinweis zu Herstellern: Ein Software-Hersteller, der lediglich empfiehlt, seine Anwendungs-ID auf die Liste zu setzen, hat damit noch keine Migrationsperspektive geliefert. Ein tragfähiger Plan umfasst einen konkreten Migrationspfad, betroffene Produktversionen, benötigte Graph-Berechtigungen und dokumentierte Funktionslücken. Fehlt das bei einer geschäftskritischen Anwendung, sollte jetzt eskaliert werden — nicht erst während einer von Microsoft gesteuerten Abschaltungswelle.

Schritt 3: EWSAllowedAppIDs konfigurieren

Alle Anwendungen, die vorübergehend weiterhin EWS verwenden müssen, werden mit ihrer Anwendungs-ID in EWSAllowedAppIDs eingetragen.

Ein zentraler Punkt vorab: Die Zulassungsliste ist wirkungslos, solange EWSEnabled nicht auf True gesetzt ist. Bei EWSEnabled=Null hat der Parameter keinerlei Effekt. Beide Einstellungen gehören daher zusammen.

Die einfachste Variante, wenn die vollständige Liste bereits bekannt ist:

powershell

Set-OrganizationConfig -EwsEnabled $true `
    -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

Dabei ist ein wichtiger Punkt zu beachten:

Eine Änderung an EWSAllowedAppIDs ersetzt die vorhandene Liste vollständig. Es gibt keine Operation zum einzelnen Hinzufügen oder Entfernen. Wird eine bestehende ID versehentlich weggelassen, verliert die zugehörige Anwendung den Zugriff auf EWS.

Für Ergänzungen ist deshalb immer das Muster Auslesen, Ändern, Zurückschreiben erforderlich:

powershell

# Neue Anwendungs-ID, die ergänzt werden soll
$neueAppId = "22222222-3333-4444-5555-666666666666"

# Bestehende Liste auslesen
$aktuell = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
    Select-Object -ExpandProperty EwsAllowedAppIDs)

# In Einzelwerte zerlegen (leere Liste, falls noch nichts gesetzt ist)
if ([string]::IsNullOrWhiteSpace($aktuell)) {
    $bestehend = @()
} else {
    $bestehend = $aktuell -split "," | ForEach-Object { $_.Trim() }
}

# Nur ergänzen, wenn die ID noch nicht enthalten ist
if ($bestehend -notcontains $neueAppId) {
    $bestehend += $neueAppId
    Write-Host "$neueAppId wurde ergaenzt"
} else {
    Write-Host "$neueAppId ist bereits enthalten"
}

# Vollständige Liste zurückschreiben
Set-OrganizationConfig -EwsAllowedAppIDs ($bestehend -join ",")

Vor jeder Änderung sollte die aktuelle Konfiguration ausgelesen, exportiert und dokumentiert werden. Die Zulassungsliste ist eher wie ein Regelwerk einer Firewall oder eine Conditional-Access-Richtlinie zu behandeln als wie eine beiläufige Exchange-Einstellung — inklusive Change-Prozess und Freigabe.

Soll die Einschränkung nach Anwendungs-ID vollständig aufgehoben werden, wird der Parameter auf $null gesetzt. Zu beachten ist, dass genau diese Konfiguration ab Oktober 2026 in Kombination mit EWSEnabled=True zu einer vollständigen Blockade führt.

Als Alternative zur PowerShell-Konfiguration lässt sich die Einstellung auch über den Baseline Security Mode verwalten.

Schritt 4: Konfiguration kontrollieren

Die konfigurierte Zulassungsliste lässt sich über Exchange Online PowerShell abrufen:

powershell

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Der Parameter RetrieveEwsOperationAccessPolicy ist zwingend erforderlich. Die Liste wird aus Performancegründen nur geladen, wenn sie ausdrücklich angefordert wird. Ohne diesen Parameter erscheint das Feld leer, obwohl eine Konfiguration vorhanden ist — eine häufige Fehlerquelle bei der Prüfung.

Ergänzend sollte auch der zugehörige Schalter kontrolliert werden:

powershell

Get-OrganizationConfig | Format-List EwsEnabled, EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList

Ein leerer Wert bei EwsEnabled bedeutet Null und damit die Standardkonfiguration, die im Oktober automatisch auf False umgestellt wird.

Schritt 5: Zugriff testen

Nach der Konfiguration sollte jede zugelassene Anwendung technisch getestet werden.

Dabei ist eine Besonderheit der aktuellen Phase entscheidend: Ein Negativtest ist vor Oktober 2026 nicht aussagekräftig. Da das Verhalten bis dahin bewusst durchlässig bleibt, werden nicht gelistete Anwendungen noch nicht blockiert — auch dann nicht, wenn EWSEnabled auf True steht und eine Liste konfiguriert ist.

Wer daraus schließt, die Konfiguration greife nicht, konfiguriert unter Umständen unnötig nach. Wer umgekehrt daraus schließt, es sei alles in Ordnung, erlebt im Oktober eine Überraschung.

Sinnvoll ist deshalb ein zweistufiges Vorgehen:

Vor Oktober 2026: Prüfen, ob alle freigegebenen Anwendungen weiterhin funktionieren, und die Vollständigkeit der Liste gegen die Nutzungsberichte abgleichen. Der eigentliche Zweck dieser Phase ist Bestandsaufnahme, nicht Absicherung.

Ab Beginn der Durchsetzung: Prüfen, ob nicht freigegebene Anwendungen tatsächlich blockiert werden, und ob die freigegebenen Anwendungen weiterhin vollständig arbeiten.

In beiden Fällen gilt: Eine erfolgreiche Anmeldung allein bestätigt nicht, dass jede benötigte EWS-Funktion verfügbar ist. Getestet werden sollten die tatsächlichen Geschäftsprozesse — vollständige Postfachsynchronisation, Kalenderzugriffe, Berechtigungslogik, Fehlerbehandlung.

Änderungen an der Konfiguration sollten nach Möglichkeit zunächst in einem Testmandanten erprobt werden, bevor sie in der Produktion angewendet werden.

Dokumentation nicht vergessen

Die finale EWSAllowedAppIDs-Liste sollte nicht nur technisch hinterlegt, sondern auch nachvollziehbar dokumentiert werden.

Für jede Anwendung sollten mindestens folgende Informationen festgehalten werden:

• Name der Anwendung
• Anwendungs-ID
• Application Owner
• Technischer Ansprechpartner
• Herstellerkontakt, sofern relevant
• Verwendete EWS-Funktionen
• Geschäftliche Relevanz
• Geplantes Migrationsdatum
• Zieltechnologie
• Letzter erfolgreicher Test
• Nächster Überprüfungstermin

Diese Dokumentation wird besonders wichtig, wenn mehrere Teams oder Dienstleister an der Exchange-Online-Umgebung arbeiten. Da jede Änderung die gesamte Liste überschreibt, ist ein aktueller Stand die Voraussetzung dafür, dass eine Anpassung nicht versehentlich andere Anwendungen aussperrt.

Empfehlenswert ist außerdem, die Einträge in regelmäßigem Abstand zu überprüfen. Jede Zeile auf der Liste ist eine Ausnahme mit Ablaufdatum, kein Dauerzustand.

EWSAllowedAppIDs ist keine langfristige Lösung

Die Zulassungsliste reduziert das Risiko kurzfristiger Störungen. Sie ändert jedoch nichts daran, dass EWS am 1. April 2027 vollständig außer Betrieb genommen wird. Zu diesem Zeitpunkt entfällt auch die Möglichkeit, über EWSEnabled noch einzugreifen.

Unternehmen sollten EWSAllowedAppIDs deshalb als kontrollierten Übergangsmechanismus betrachten, der maximal sechs Monate zusätzliche Zeit verschafft.

Das eigentliche Ziel bleibt die Migration auf Microsoft Graph oder eine andere unterstützte Schnittstelle. Anwendungen ohne realistische Migrationsperspektive sollten kritisch bewertet und gegebenenfalls ersetzt werden.

Empfohlenes Vorgehen für Unternehmen

Ein strukturiertes EWS-Projekt sollte vier Arbeitspakete umfassen:

1. Analyse: Die tatsächliche EWS-Nutzung im Mandanten erfassen und jeder Abhängigkeit einen Verantwortlichen zuordnen.
2. Bewertung: Anwendungen technisch und fachlich bewerten und über Migration, Ablösung oder befristete Freigabe entscheiden.
3. Konfiguration: EWSAllowedAppIDs konfigurieren, EWSEnabled auf True setzen und die Konfiguration testen. Dieses Paket sollte bis Ende August 2026 abgeschlossen sein.
4. Migration: Für jede verbleibende Abhängigkeit eine Migration oder Ablösung planen und umsetzen.

Besonders wichtig ist die Zusammenarbeit zwischen IT-Betrieb, Fachbereichen, Application Ownern, Entwicklern und Software-Herstellern. Die technische Analyse allein reicht häufig nicht aus, um die geschäftliche Bedeutung einer Integration zu verstehen.

Typische Risiken in Kundenumgebungen

In der Praxis treten bei solchen Umstellungen häufig ähnliche Herausforderungen auf:

• Anwendungen sind technisch vorhanden, aber keinem verantwortlichen Team zugeordnet.
• EWS wird durch eine ältere Softwareversion verwendet, obwohl eine aktuelle Version bereits Microsoft Graph unterstützt.
• Eine Integration wurde vor Jahren eingerichtet und ist nicht mehr dokumentiert.
• Test- und Produktionsumgebungen verwenden unterschiedliche Anwendungs-IDs.
• Eine Änderung an EWSAllowedAppIDs überschreibt versehentlich vorhandene Einträge.
• Die Liste ist konfiguriert, EWSEnabled steht aber weiterhin auf Null — die Konfiguration ist damit wirkungslos.
• Die Konfiguration wird ohne den Parameter RetrieveEwsOperationAccessPolicy geprüft und erscheint fälschlich als leer.
• Aus dem durchlässigen Verhalten vor Oktober wird geschlossen, die Konfiguration sei bereits wirksam.
• Eine bestehende EwsApplicationAccessPolicy auf Basis von User Agents blockiert eine Anwendung, obwohl deren Anwendungs-ID freigegeben ist.
• Eine Anwendung wird zugelassen, aber es existiert kein Plan für die spätere Migration.

Diese Risiken lassen sich durch eine frühzeitige Bestandsaufnahme und eine saubere Dokumentation deutlich reduzieren.

Fazit

Die Abschaltung von EWS in Exchange Online ist keine Ankündigung mehr, sondern ein laufender Prozess mit festen Terminen.

Der wichtigste Termin ist nicht der 1. April 2027 und auch nicht der 1. Oktober 2026, sondern das Ende August 2026. Bis dahin entscheidet sich, ob ein Unternehmen die Umstellung selbst steuert oder ob Microsoft sie im Oktober übernimmt.

Der erste Schritt ist eine vollständige Analyse der vorhandenen EWS-Nutzung. Anschließend sollten nur noch notwendige Anwendungen gezielt freigegeben, technisch getestet und mit einem konkreten Migrationsplan versehen werden.

Wer diese Arbeiten frühzeitig beginnt, reduziert das Risiko von Betriebsunterbrechungen und schafft gleichzeitig eine gute Grundlage für die weitere Modernisierung der eigenen Microsoft-365-Landschaft.

Die Schwachstelle Certighost ermöglicht unter bestimmten Bedingungen die Übernahme einer Active-Directory-Domäne. Was Unternehmen jetzt prüfen müssen.

Ein kompromittiertes Benutzerkonto ohne administrative Berechtigungen gilt normalerweise noch nicht als vollständige Katastrophe. Bei der neu veröffentlichten Schwachstelle Certighost, geführt als CVE-2026-54121, kann jedoch genau ein solches Standardkonto der Ausgangspunkt für eine vollständige Übernahme der Active-Directory-Domäne sein.

Betroffen ist nicht der Domain Controller selbst, sondern eine besonders sensible Vertrauenskomponente: die Active Directory Certificate Services, kurz AD CS. Unter bestimmten Voraussetzungen kann ein Angreifer die Zertifizierungsstelle dazu bringen, ein gültiges Zertifikat für einen Domain Controller auszustellen.

Der Angreifer kann sich anschließend gegenüber Kerberos als dieser Domain Controller authentifizieren. Damit stehen ihm im schlimmsten Fall Replikationsrechte und der Zugriff auf zentrale Domänengeheimnisse offen.

Microsoft veröffentlichte den Sicherheitspatch am 14. Juli 2026. Am 24. Juli 2026 veröffentlichten die Sicherheitsforscher H0j3n und Aniq Fakhrul eine technische Analyse sowie einen funktionierenden Proof of Concept. Der CVSS-Wert der Schwachstelle liegt bei 8,8 von 10 Punkten. (Gist)

Was ist Certighost?

Certighost bezeichnet eine Schwachstelle in der Verarbeitung von Zertifikatsanfragen durch eine Microsoft Enterprise Certification Authority.

AD CS stellt Zertifikate aus, die innerhalb einer Windows-Domäne unter anderem für Authentifizierung, Verschlüsselung und digitale Signaturen eingesetzt werden. Ein solches Zertifikat ist nicht lediglich eine Datei, sondern ein kryptografischer Identitätsnachweis.

Genau hier liegt das Problem: Wer ein gültiges Authentifizierungszertifikat für einen privilegierten Benutzer oder einen Domain Controller besitzt, kann sich gegenüber anderen Systemen als diese Identität ausgeben.

Die Schwachstelle befindet sich in einem als „Chase“ bezeichneten Ausweichmechanismus. Kann die Zertifizierungsstelle die Informationen zu einem Antragsteller nicht direkt auflösen, darf die Zertifikatsanfrage über die Attribute cdc und rmd angeben, welchen Verzeichnisserver die CA kontaktieren und welches Objekt sie dort suchen soll.

Vor dem Juli-Update überprüfte die CA nicht ausreichend, ob das vom Antragsteller angegebene Ziel tatsächlich ein legitimer Domain Controller war. Dadurch konnte sie Verzeichnisinformationen von einem durch den Angreifer kontrollierten System übernehmen. (Gist)

Wie läuft der Angriff ab?

Für das Verständnis des Risikos reicht eine vereinfachte Darstellung der Angriffskette:

1. Ein Angreifer erlangt Zugriff auf ein gewöhnliches Domänenkonto.
2. Er erstellt oder kontrolliert zusätzlich ein Computerkonto innerhalb der Domäne.
3. Über eine manipulierte Zertifikatsanfrage veranlasst er die Enterprise CA, einen von ihm kontrollierten Host zu kontaktieren.
4. Dieser Host liefert Identitätsinformationen eines echten Domain Controllers zurück.
5. Die Zertifizierungsstelle übernimmt diese Informationen und stellt ein Zertifikat aus, das den Angreifer als Domain Controller ausweist.
6. Das Zertifikat wird zur Kerberos-Authentifizierung über PKINIT verwendet.
7. Mit der Identität des Domain Controllers kann der Angreifer Verzeichnisreplikationsfunktionen wie DCSync missbrauchen und unter anderem auf das Geheimnis des krbtgt-Kontos zugreifen.

Der veröffentlichte Proof of Concept automatisiert weite Teile dieser Kette. Er kann ein Computerkonto anlegen, die erforderlichen Netzwerkdienste bereitstellen, die Zertifikatsanfrage übermitteln und anschließend Kerberos-Anmeldedaten für den Ziel-Domain-Controller erzeugen. (Gist)

Der entscheidende Punkt: Für den Einstieg sind weder Domain-Admin-Rechte noch eine Interaktion eines Benutzers notwendig. Ein gültiges, niedrig privilegiertes Domänenkonto kann unter den passenden Rahmenbedingungen ausreichen.

Warum ist die Schwachstelle so gefährlich?

Viele Angriffe auf Active Directory bestehen aus mehreren Eskalationsstufen. Angreifer kompromittieren zunächst einen Arbeitsplatz, sammeln Zugangsdaten, bewegen sich seitlich durch das Netzwerk und suchen nach immer höheren Berechtigungen.

Certighost kann diesen Weg erheblich verkürzen.

Statt verschiedene administrative Konten zu übernehmen, greift der Angreifer die Identitäts- und Vertrauensinfrastruktur selbst an. Die Zertifizierungsstelle bestätigt ihm anschließend kryptografisch eine Identität, die er eigentlich nicht besitzen dürfte.

Das macht den Angriff aus drei Gründen besonders kritisch:

Die Ausgangsberechtigung ist niedrig.
Ein normales Domänenkonto kann genügen. Solche Konten sind durch Phishing, infizierte Endgeräte, Passwort-Wiederverwendung oder gestohlene Sessions vergleichsweise häufig erreichbar.

Das ausgestellte Zertifikat ist ein legitimer Identitätsnachweis.
Für nachgelagerte Systeme sieht die Authentifizierung zunächst gültig aus. Der Angreifer verwendet kein erratenes Domain-Admin-Passwort, sondern ein von der internen CA signiertes Zertifikat.

Das mögliche Ergebnis ist eine vollständige Domänenkompromittierung.
Durch die Identität eines Domain Controllers erhält der Angreifer Zugriff auf besonders weitreichende Active-Directory-Funktionen. Dazu kann die Replikation von Passwort-Hashes und anderen sensiblen Verzeichnisdaten gehören. (Gist)

Ist jede Active-Directory-Umgebung betroffen?

Nein. Eine vorhandene Windows-Domäne allein reicht für den Angriff nicht aus.

Die Forscher demonstrierten die Angriffskette in einer Umgebung mit folgenden Eigenschaften:

• Eine Microsoft Enterprise Certification Authority war vorhanden.
• Die CA nutzte den verwundbaren Chase-Verarbeitungspfad.
• Das standardmäßige Machine-Zertifikatstemplate konnte verwendet werden.
• Das Konto durfte ein Computerkonto erstellen oder kontrollierte bereits eines.
• Die Zertifizierungsstelle konnte die vom Angreifer bereitgestellten SMB- und LDAP-Dienste erreichen.
• Die Sicherheitsupdates vom Juli 2026 waren auf dem AD-CS-System noch nicht wirksam.

Im Test nutzten die Forscher außerdem den Standardwert des Attributs ms-DS-MachineAccountQuota. Dieser erlaubt Domänenbenutzern üblicherweise die Erstellung von bis zu zehn Computerkonten. Die Existenz dieses Standardwerts bedeutet jedoch nicht automatisch, dass jede Umgebung erfolgreich ausnutzbar ist. Die gesamte Zertifikats- und Netzwerkkonfiguration muss betrachtet werden. (Gist)

Unternehmen sollten daher weder in Panik verfallen noch das Problem vorschnell als „nicht relevant“ einstufen. Entscheidend ist eine gezielte Prüfung der eigenen AD-CS-Architektur.

Was verändert der Microsoft-Patch?

Mit den Sicherheitsupdates vom 14. Juli 2026 ergänzt Microsoft eine Validierung des angegebenen Chase-Ziels.

Die Zertifizierungsstelle prüft nun, ob der übermittelte Hostname tatsächlich zu einem eindeutigen Computerobjekt in Active Directory gehört, das als Domain Controller gekennzeichnet ist. Zusätzlich werden unter anderem IP-Adressen, überlange Hostnamen und bestimmte LDAP-Sonderzeichen abgewiesen. Eine weitere SID-Prüfung soll verhindern, dass ein anderes Verzeichnisobjekt untergeschoben wird.

Der grundlegende Vertrauensfehler wird damit geschlossen: Die Zertifizierungsstelle akzeptiert einen erreichbaren Host nicht mehr allein deshalb als Domain Controller, weil dieser auf die Anfrage antwortet. (Gist)

Was Unternehmen jetzt tun sollten

1. Vorhandene AD-CS-Systeme identifizieren

Zunächst muss geklärt werden, ob im Unternehmen überhaupt Active Directory Certificate Services betrieben werden.

Besonders relevant sind Enterprise CAs, die Zertifikate für Benutzer und Computer innerhalb der Domäne ausstellen. Dabei sollten auch historisch gewachsene PKI-Systeme, untergeordnete CAs und nur noch selten genutzte Zertifizierungsstellen berücksichtigt werden.

Eine CA, die niemand mehr aktiv betreut, ist nicht automatisch ungefährlich.

2. Juli-Updates auf den CA-Systemen installieren

Die höchste Priorität hat die Installation der Microsoft-Sicherheitsupdates vom 14. Juli 2026 auf allen betroffenen AD-CS-Hosts.

Es genügt nicht, lediglich die Domain Controller zu aktualisieren. Die verwundbare Verarbeitung findet auf dem System statt, das die Enterprise Certification Authority betreibt.

Nach der Installation sollte kontrolliert werden, ob das Update tatsächlich erfolgreich angewendet wurde und ob alle erforderlichen Neustarts beziehungsweise Dienstneustarts erfolgt sind.

3. Zertifikatstemplates und Enrollment-Rechte überprüfen

Unternehmen sollten prüfen, welche Benutzer und Gruppen Zertifikate über Maschinen- und Authentifizierungstemplates anfordern dürfen.

Dabei geht es nicht nur um Certighost. Zu weit gefasste Enrollment-Rechte, unsichere Template-Einstellungen und unzureichend kontrollierte Subject-Informationen sind seit Jahren ein häufiger Ausgangspunkt für Angriffe auf AD CS.

Die PKI sollte daher als Teil der privilegierten Active-Directory-Infrastruktur behandelt und regelmäßig auditiert werden.

4. Machine Account Quota bewerten

Der Standardwert von ms-DS-MachineAccountQuota sollte nicht ungeprüft übernommen werden.

Benötigen normale Benutzer wirklich das Recht, selbstständig Computerobjekte in der Domäne anzulegen? In vielen Unternehmensumgebungen lautet die Antwort: nein.

Eine Reduzierung auf null kann die Angriffsfläche verkleinern. Vor einer Änderung müssen allerdings bestehende Deployment-, Imaging- und Join-Prozesse geprüft werden. Die Maßnahme ersetzt außerdem nicht den Microsoft-Patch.

5. Netzwerkzugriffe der Zertifizierungsstelle einschränken

Aus dem veröffentlichten Angriffspfad lässt sich eine wichtige Architekturmaßnahme ableiten: Eine Zertifizierungsstelle sollte nicht beliebige Systeme über SMB oder LDAP erreichen können.

Ausgehende Verbindungen der CA sollten auf die tatsächlich benötigten Domain Controller und administrativen Dienste begrenzt werden. Erreicht die CA ohne Einschränkungen Benutzer-, Client- oder Servernetzwerke, ist die Segmentierung wahrscheinlich zu großzügig.

Eine CA gehört in ein besonders geschütztes Netzwerksegment und sollte ähnlich restriktiv behandelt werden wie Domain Controller.

6. Verdächtige Aktivitäten überwachen

Security-Teams sollten insbesondere auf folgende Auffälligkeiten achten:

• unerwartete Erstellung neuer Computerkonten,
• ungewöhnliche Zertifikatsanfragen über Machine-Templates,
• Verbindungen der CA zu nicht autorisierten SMB- oder LDAP-Systemen,
• Zertifikate mit Identitätsmerkmalen eines Domain Controllers,
• ungewöhnliche PKINIT-Authentifizierungen,
• verdächtige Verzeichnisreplikationsaktivitäten.

Diese Indikatoren sind aus der veröffentlichten Angriffskette abgeleitet. Einzelne Ereignisse beweisen noch keinen Angriff, können aber wertvolle Hinweise für die Untersuchung liefern. (Gist)

Was tun, wenn der Patch nicht sofort installiert werden kann?

Die Forscher beschreiben als vorübergehende Mitigation das Abschalten des Chase-Fallbacks:

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC

Restart-Service CertSvc -Force

Diese Maßnahme wurde nach Angaben der Forscher nur in einer kontrollierten Laborumgebung getestet. Sie kann legitime Zertifikatsanforderungen beeinträchtigen, die auf diesen Ausweichmechanismus angewiesen sind.

Eine Umsetzung sollte daher zunächst in einer repräsentativen Testumgebung erfolgen. Das Deaktivieren des Features ist ausdrücklich kein Ersatz für das Sicherheitsupdate. (Gist)

Einordnung aus IT-Consulting-Sicht

Certighost ist ein gutes Beispiel dafür, warum Active-Directory-Sicherheit nicht bei Domain-Admin-Konten und Gruppenrichtlinien endet.

Die interne Zertifizierungsinfrastruktur bildet eine zweite Identitätsebene. Ein Unternehmen kann seine Passwörter, privilegierten Gruppen und Domain Controller sorgfältig absichern – und dennoch über eine falsch konfigurierte oder ungepatchte CA vollständig kompromittiert werden.

In vielen Organisationen wird AD CS allerdings weiterhin wie ein statischer Infrastrukturdienst behandelt: einmal installiert, selten verändert und nur dann beachtet, wenn ein Zertifikat abläuft.

Dieser Ansatz ist nicht mehr vertretbar.

Zertifizierungsstellen, Templates, Enrollment-Berechtigungen, private Schlüssel, Netzwerkverbindungen und Protokolldaten müssen Bestandteil des regulären Identity-Security- und Vulnerability-Managements sein. Dazu gehören dokumentierte Verantwortlichkeiten, regelmäßige Reviews und getestete Notfallprozesse.

Fazit

Certighost zeigt, wie schnell sich eine vermeintlich geringe Ausgangsberechtigung in eine vollständige Kompromittierung der Windows-Domäne verwandeln kann.

Die gute Nachricht: Microsoft hat die Schwachstelle bereits am 14. Juli 2026 geschlossen.

Die schlechte Nachricht: Seit dem 24. Juli steht ein funktionierender Proof of Concept öffentlich zur Verfügung. Zum Zeitpunkt seiner Veröffentlichung lagen zwar keine öffentlich bestätigten Berichte über eine aktive Ausnutzung vor. Das ist jedoch kein Grund, mit der Behebung zu warten. (The Hacker News)

Unternehmen mit einer Microsoft Enterprise CA sollten deshalb unverzüglich den Patchstand prüfen. Gleichzeitig bietet der Vorfall einen sinnvollen Anlass, die gesamte AD-CS-Architektur zu überprüfen.

Denn eine interne Zertifizierungsstelle ist kein gewöhnlicher Windows-Server. Sie entscheidet darüber, welchen Identitäten das Unternehmen vertraut.

Microsoft hat am 14. Juli 2026 die aktuellen Sicherheitsupdates für Exchange Server veröffentlicht. Das Update schließt mehrere sicherheitsrelevante Schwachstellen, darunter eine Remote Code Execution (CVE-2026-55005), zwei Elevation-of-Privilege-Schwachstellen (CVE-2026-55006 und CVE-2026-55009) sowie eine Spoofing-Schwachstelle (CVE-2026-55008).

Doch wie so oft gilt: Das Einspielen des Updates allein reicht nicht aus.

Die vergangenen Jahre – angefangen bei ProxyLogon, ProxyShell oder OWASSRF – haben gezeigt, dass Exchange-Server ein bevorzugtes Ziel professioneller Angreifer sind. Wer Exchange On-Premises betreibt, benötigt daher nicht nur ein funktionierendes Patchmanagement, sondern ein ganzheitliches Sicherheitskonzept.

In diesem Artikel zeigen wir, welche Risiken das aktuelle Update adressiert, welche Maßnahmen Administratoren jetzt ergreifen sollten und wie sich eine Exchange-Infrastruktur dauerhaft absichern lässt.

Welche Schwachstellen werden behoben?

Das Juli-Update beseitigt insgesamt vier sicherheitsrelevante Schwachstellen.

CVE-2026-55005 – Remote Code Execution

Die kritischste Schwachstelle ermöglicht unter bestimmten Voraussetzungen die Ausführung von Code auf dem Exchange-Server.

Remote Code Execution zählt zu den gefährlichsten Schwachstellen überhaupt. Gelingt einem Angreifer die Ausnutzung, kann dies – abhängig von den vorhandenen Berechtigungen und der Umgebung – bis zur vollständigen Kompromittierung des Exchange-Servers führen.

Da Exchange in nahezu jeder Active-Directory-Umgebung eine zentrale Rolle einnimmt, ist das Risiko entsprechend hoch.

CVE-2026-55006 und CVE-2026-55009 – Rechteausweitung

Diese Schwachstellen ermöglichen Angreifern, ihre Berechtigungen innerhalb des Systems zu erweitern.

Solche Sicherheitslücken sind besonders gefährlich, wenn sie mit anderen Schwachstellen kombiniert werden. Moderne Angriffe bestehen selten aus einer einzelnen Exploit-Kette – stattdessen werden mehrere Schwachstellen miteinander kombiniert.

CVE-2026-55008 – Spoofing

Diese Schwachstelle erleichtert Identitäts- oder Inhaltsmanipulationen.

Gerade bei E-Mail-Systemen können Spoofing-Angriffe die Grundlage für Phishing-Kampagnen oder Business-E-Mail-Compromise-Angriffe bilden.

Das Update ersetzt bisherige Mitigations

Administratoren erinnern sich vermutlich noch an die im Mai veröffentlichte OWA-Schwachstelle CVE-2026-42897.

Damals empfahl Microsoft verschiedene temporäre Gegenmaßnahmen, um Exchange kurzfristig abzusichern.

Mit dem Juli-Update werden diese Workarounds durch eine dauerhafte Fehlerbehebung ersetzt. Nach erfolgreicher Installation können die temporären Mitigations entsprechend der Microsoft-Dokumentation wieder entfernt werden.

Wer ist betroffen?

Betroffen sind grundsätzlich alle unterstützten On-Premises-Versionen:

• Exchange Server Subscription Edition (SE)
• Exchange Server 2019 (mit gültigem ESU)
• Exchange Server 2016 (mit gültigem ESU)

Unternehmen ohne Extended Security Updates erhalten für Exchange 2016 und 2019 keine neuen Sicherheitsupdates mehr. Microsoft empfiehlt daher ausdrücklich den Umstieg auf Exchange Server Subscription Edition (SE).

Was sollten Administratoren jetzt tun?

1. Sicherheitsupdate umgehend installieren

Der wichtigste Schritt ist selbstverständlich die Installation des aktuellen Security Updates.

Vorher sollten Sie:

• aktuelle Backups prüfen
• den Exchange Health Checker ausführen
• freien Speicherplatz kontrollieren
• Windows-Updates prüfen
• Wartungsfenster einplanen

Nach der Installation empfiehlt sich:

• Neustart des Servers
• Kontrolle aller Exchange-Dienste
• Test von Outlook, Outlook on the Web (OWA), ActiveSync und SMTP
• Prüfung der Ereignisanzeige
• Überprüfung der Exchange-Version mittels Get-ExchangeServer

2. Exchange Health Checker regelmäßig ausführen

Microsoft stellt mit dem Exchange Health Checker ein kostenloses PowerShell-Skript bereit.

Dieses überprüft unter anderem:

• fehlende Sicherheitsupdates
• unterstützte Cumulative Updates
• TLS-Konfiguration
• Zertifikate
• Extended Protection
• IIS-Konfiguration
• bekannte Fehlkonfigurationen

Viele Administratoren nutzen das Skript leider erst dann, wenn bereits Probleme auftreten.

Unser Rat:

Mindestens einmal pro Monat ausführen.

3. Extended Protection aktivieren

Microsoft empfiehlt inzwischen ausdrücklich die Aktivierung von Extended Protection.

Diese Funktion erschwert verschiedene Relay- und Authentifizierungsangriffe erheblich.

Seit mehreren Exchange-Versionen gehört Extended Protection praktisch zu den Mindestanforderungen für einen sicheren Betrieb.

Falls Extended Protection noch nicht aktiviert wurde, sollte dies zeitnah nachgeholt werden.

MFA schützt Administratoren – aber nicht den Exchange-Server

Ein häufiger Irrtum lautet:

“Wir nutzen doch Multi-Faktor-Authentifizierung.”

Das ist gut – schützt aber nicht jede Angriffsklasse.

MFA verhindert kompromittierte Benutzerkonten und erschwert Passwortangriffe erheblich. Gegen Schwachstellen innerhalb des Exchange-Servers selbst hilft MFA jedoch nicht.

Deshalb gilt:

• MFA für alle Administratoren
• MFA für privilegierte Benutzer
• keine Legacy Authentication
• möglichst keine Basic Authentication mehr

MFA ist ein wichtiger Bestandteil der Sicherheitsstrategie – ersetzt aber niemals zeitnahe Sicherheitsupdates.

Exchange niemals unnötig veröffentlichen

Viele Unternehmen veröffentlichen sämtliche Exchange-Dienste direkt ins Internet.

Dabei sollte kritisch hinterfragt werden:

Benötigen wirklich alle Benutzer:

• Exchange Admin Center?
• Exchange PowerShell?
• EWS?
• Autodiscover?
• Outlook Anywhere?

Je kleiner die öffentlich erreichbare Angriffsfläche, desto geringer das Risiko.

Ein bewährtes Prinzip lautet:

Nur veröffentlichen, was tatsächlich benötigt wird.

Reverse Proxy oder Web Application Firewall einsetzen

Microsoft unterstützt Exchange nicht hinter jeder beliebigen Web Application Firewall. Dennoch kann ein Reverse Proxy oder – sofern kompatibel – eine WAF einen zusätzlichen Schutz bieten.

Beispielsweise können damit:

• bekannte Angriffsparameter erkannt,
• ungewöhnliche Requests blockiert,
• Geo-Blocking umgesetzt,
• Rate Limiting aktiviert,
• Bots gefiltert,
• verdächtige Zugriffe protokolliert

werden.

Wichtig ist jedoch:

Eine WAF ersetzt niemals Sicherheitsupdates.

Sie reduziert lediglich die Angriffsfläche.

Netzwerksegmentierung nutzen

Ein Exchange-Server sollte niemals “irgendwo im Servernetz” stehen.

Empfehlenswert sind:

• eigene Server-VLANs
• restriktive Firewall-Regeln
• minimale eingehende Ports
• keine unnötigen administrativen Freigaben

Je weniger Systeme direkten Zugriff auf Exchange besitzen, desto schwieriger wird eine laterale Bewegung im Netzwerk.

Administrator-Konten absichern

Administratorkonten sollten grundsätzlich:

• individuelle Benutzerkonten sein
• MFA verwenden
• keine tägliche Office-Arbeitskonten sein
• mit Privileged Access Workstations (PAW) verwendet werden
• über starke Kennwortrichtlinien verfügen

Ein kompromittiertes Exchange-Administratorkonto stellt häufig den schnellsten Weg zur vollständigen Active-Directory-Kompromittierung dar.

Logging und Monitoring nicht vergessen

Viele Unternehmen bemerken erfolgreiche Angriffe erst Wochen später.

Deshalb sollten mindestens folgende Komponenten überwacht werden:

• Windows Event Logs
• IIS Logs
• Exchange Message Tracking
• Defender for Endpoint
• Microsoft Sentinel oder ein SIEM
• ungewöhnliche PowerShell-Aktivitäten
• neue Administratoren
• Änderungen an Exchange Virtual Directories

Wer Logs zwar sammelt, aber nie auswertet, gewinnt daraus keinen Sicherheitsvorteil.

Regelmäßige Schwachstellen-Scans durchführen

Mindestens quartalsweise sollten interne und externe Schwachstellen-Scans durchgeführt werden.

Dabei werden häufig entdeckt:

• fehlende Exchange Updates
• schwache TLS-Konfigurationen
• offene Managementschnittstellen
• veraltete Zertifikate
• unnötig veröffentlichte Dienste

Ein Scan ersetzt zwar kein Penetration Testing, liefert aber frühzeitig Hinweise auf Konfigurationsfehler.

Langfristig führt kein Weg an Exchange Server SE vorbei

Neben den aktuellen Sicherheitsupdates sendet Microsoft eine klare Botschaft:

Die Zukunft von Exchange On-Premises ist Exchange Server Subscription Edition (SE).

Exchange 2016 und 2019 befinden sich außerhalb des regulären Supports und erhalten Sicherheitsupdates nur noch im Rahmen des Extended Security Updates (ESU)-Programms.

Wer Exchange langfristig betreiben möchte, sollte deshalb den Wechsel auf Exchange SE zeitnah planen.

Dadurch profitieren Unternehmen von:

• kontinuierlichen Sicherheitsupdates
• einer aktiv weiterentwickelten Plattform
• einem modernen Servicing-Modell
• langfristiger Planungssicherheit

Fazit

Die Security Updates vom 14. Juli 2026 schließen mehrere sicherheitskritische Schwachstellen und sollten schnellstmöglich installiert werden.

Mindestens genauso wichtig ist jedoch der Blick auf die gesamte Sicherheitsstrategie.

Ein sicherer Exchange-Server besteht nicht nur aus aktuellen Patches. Er benötigt zusätzlich:

• konsequentes Patchmanagement
• Extended Protection
• Multi-Faktor-Authentifizierung
• minimierte Angriffsfläche
• Reverse Proxy oder kompatible WAF
• kontinuierliches Monitoring
• regelmäßige Health Checks
• Schwachstellen-Scans
• und eine langfristige Migrationsstrategie hin zu Exchange Server Subscription Edition.

Denn die beste Verteidigung gegen neue Sicherheitslücken besteht nicht darin, auf den nächsten Patch zu warten – sondern eine Exchange-Infrastruktur zu betreiben, die nach dem Prinzip Defense in Depth aufgebaut ist.

Passkeys gelten zu Recht als ein wichtiger Schritt weg von Passwörtern und klassischen MFA-Codes. Sie sind phishing-resistenter, komfortabler und reduzieren viele bekannte Angriffspfade. Genau deshalb ist eine aktuelle Angriffskampagne gegen Microsoft-365-Nutzer so lehrreich: Die Angreifer attackieren nicht die Kryptografie von Passkeys selbst, sondern den Registrierungsprozess – und das Vertrauen der Mitarbeitenden in vermeintliche IT-Sicherheitsanweisungen.

BleepingComputer berichtete am 8. Juli 2026 über eine Pishing-Kampagne, bei der Angreifer Microsoft-365-Nutzer telefonisch dazu bringen wollen, angeblich einen neuen Microsoft-Entra-Passkey zu registrieren. Die Kampagne wird mit einem Bedrohungsakteur in Verbindung gebracht, den Okta als O-UNC-066 verfolgt und der laut Bericht mit der Erpressungsgruppe „Pink“ assoziiert wird. (BleepingComputer)

Worum geht es?

Microsoft erlaubt Administratoren, sogenannte Registration Campaigns einzurichten. Damit können Nutzer während des Anmeldevorgangs dazu aufgefordert werden, stärkere Authentifizierungsmethoden wie Passkeys oder Microsoft Authenticator einzurichten. Laut Microsoft durchlaufen Nutzer dabei zuerst den normalen Login inklusive MFA und werden danach zur Einrichtung der Zielmethode aufgefordert. (Microsoft Learn)

Genau diese legitime Sicherheitsfunktion nutzen Angreifer als Vorwand. Sie rufen Mitarbeitende an, geben sich als IT- oder Security-Support aus und behaupten, dass aus Sicherheitsgründen ein neuer Passkey eingerichtet werden müsse. Danach verweisen sie auf eine täuschend echt wirkende Phishing-Seite, die den Microsoft-Entra-Registrierungsprozess imitiert und teilweise mit dem Branding der Zielorganisation angepasst ist. (BleepingComputer)

Wichtig: Das ist keine klassische technische Schwachstelle im Sinne eines CVE. Die Schwachstelle liegt in der Kombination aus Social Engineering, ungewohnten Passkey-Prozessen und unzureichend abgesicherter Registrierung neuer Authentifizierungsmethoden.

Wie wird der Angriff ausgenutzt?

Der Angriff funktioniert grob in fünf Schritten.

Zuerst wird das Opfer telefonisch kontaktiert. Der Angreifer schafft Dringlichkeit und Autorität: „Wir führen gerade ein Sicherheitsupdate durch“, „Ihr Konto muss auf Passkey umgestellt werden“ oder „Ohne Registrierung verlieren Sie den Zugriff“. Das ist typisch für Vishing – Voice Phishing –, bei dem der persönliche Anruf Vertrauen erzeugen soll.

Im zweiten Schritt landet der Nutzer auf einer Phishing-Seite. Diese sieht aus wie ein Microsoft- oder Entra-Portal und kann Logos, Farben oder Hintergründe der betroffenen Organisation enthalten. Okta beschreibt, dass der beobachtete Phishing-Kit nicht einfach ein transparenter Adversary-in-the-Middle-Proxy ist, sondern ein operatorgesteuertes PHP-Panel, mit dem der Angreifer den Ablauf nahezu in Echtzeit an die MFA-Methode des Opfers anpassen kann. (okta.com)

Drittens gibt der Nutzer seine Zugangsdaten und MFA-Informationen ein oder bestätigt eine Push-Anfrage. Der Angreifer nutzt diese Informationen parallel, um sich am echten Microsoft-365-Konto anzumelden. Je nach MFA-Methode wird das Opfer zur Eingabe eines SMS- oder TOTP-Codes bewegt oder dazu gebracht, eine Authenticator-Push-Anfrage zu bestätigen. (okta.com)

Viertens registriert der Angreifer einen eigenen Passkey im echten Konto. Während das Opfer glaubt, selbst einen neuen Passkey einzurichten, nutzt der Angreifer den erfolgreichen Zugriff, um eine Authentifizierungsmethode unter seiner Kontrolle hinzuzufügen. Das ist der kritische Punkt: Ein neu registrierter Passkey kann dem Angreifer künftig einen starken, komfortablen Zugang ermöglichen – ohne dass er jedes Mal erneut Passwort und MFA-Code abgreifen muss.

Fünftens wird das Opfer weiter beschäftigt. Laut Okta zeigt das Phishing-Kit unter anderem Microsoft-ähnliche Seiten, die den Nutzer auffordern, eine angebliche Wiederherstellungsphrase zu speichern oder Wörter daraus zu bestätigen. Solche BIP-39-Seed-Phrasen haben laut Okta keine direkte Rolle bei der legitimen Microsoft-Entra-Passkey-Registrierung. Sie dienen vermutlich als Ablenkung, während der Angreifer im Hintergrund die echte Registrierung abschließt. (okta.com)

Warum ist das gefährlich?

Passkeys sind grundsätzlich eine starke Schutzmaßnahme. Microsoft beschreibt Passkeys als phishing-resistent, weil sie auf origin-bound Public-Key-Kryptografie basieren: Der private Schlüssel verbleibt auf dem Gerät, der öffentliche Schlüssel liegt beim Dienst, und der Passkey funktioniert nur für die Website oder App, für die er erstellt wurde. (Microsoft Learn)

Der Angriff umgeht diese Stärke nicht kryptografisch. Er verschiebt den Angriff nach vorne in den Registrierungsprozess. Wenn ein Angreifer es schafft, während einer aktiven Social-Engineering-Session Zugriff auf das Konto zu erhalten und eine eigene Authentifizierungsmethode zu registrieren, wird aus einer eigentlich sicheren Methode ein Persistenzmechanismus.

Das macht solche Angriffe für Unternehmen besonders kritisch. Nach erfolgreicher Kontoübernahme können Angreifer schnell auf Microsoft-365-Daten zugreifen. BleepingComputer berichtet, dass die Pink-Gruppe nach Account-Zugriffen Daten aus SharePoint und OneDrive exfiltriert haben soll. (BleepingComputer)

Woran Mitarbeitende den Betrug erkennen können

Ein legitimer Passkey-Rollout sollte niemals überraschend per Telefon erzwungen werden. Warnsignale sind:

• Ein angeblicher IT-Mitarbeiter ruft ungefragt an und fordert zur sofortigen Passkey-Registrierung auf.
• Der Link enthält Begriffe wie „passkey“, führt aber nicht auf eine offizielle Microsoft- oder Unternehmensdomain.
• Der Anrufer bleibt während der Anmeldung in der Leitung und gibt genaue Anweisungen.
• Der Nutzer soll MFA-Codes, Nummern aus Push-Anfragen oder Bestätigungen weitergeben.
• Die Seite zeigt ungewöhnliche Schritte wie Recovery-Phrasen, Seed-Wörter oder vermeintliche Wiederherstellungsschlüssel.
• Die Registrierung findet nicht über den bekannten Microsoft-Flow oder das bekannte Unternehmensportal statt.

Die einfache Regel für Endanwender lautet: Wenn ein Anruf zur Änderung von Anmeldemethoden auffordert, auflegen und den internen IT-Support über einen bekannten, unabhängigen Kanal kontaktieren.

Wie Unternehmen sich schützen können

1. Passkey-Registrierung organisatorisch absichern

Passkeys sollten eingeführt werden – aber kontrolliert. Unternehmen brauchen klare Kommunikationsregeln: Wer kündigt Passkey-Rollouts an? Über welche Kanäle? Welche Links sind legitim? Wie sieht der echte Prozess aus? Mitarbeitende sollten vorab wissen, dass IT-Support niemals telefonisch nach MFA-Codes fragt oder Nutzer durch geheime Registrierungsprozesse führt.

2. Registrierung von Sicherheitsinformationen mit Conditional Access schützen

Microsoft bietet die Möglichkeit, die Registrierung von Sicherheitsinformationen über Conditional Access abzusichern. Damit kann der Registrierungsprozess ähnlich wie eine Anwendung behandelt und zum Beispiel an Bedingungen wie vertrauenswürdige Netzwerke, Gerätekonformität oder MFA-Anforderungen geknüpft werden. (Microsoft Learn)

Praktisch bedeutet das: Neue Authentifizierungsmethoden sollten nicht beliebig von jedem Ort und jedem Gerät aus registriert werden können. Gerade für privilegierte Nutzer sollte die Registrierung nur von verwalteten Geräten, vertrauenswürdigen Standorten oder über definierte Onboarding-Prozesse erlaubt sein.

3. Phishing-resistente MFA gezielt erzwingen

Microsoft Entra unterstützt Authentication Strengths, darunter eine phishing-resistente MFA-Stärke. Microsoft beschreibt diese als die restriktivste integrierte Option. Für Administratoren, privilegierte Rollen und sensible Anwendungen sollte eine solche Stärke konsequent geprüft und eingesetzt werden. (Microsoft Learn)

Wichtig ist aber: Phishing-resistente MFA schützt nur dann vollständig, wenn auch der Lifecycle der Authentifizierungsmethoden abgesichert ist. Wer neue Faktoren zu leicht registrieren kann, öffnet eine Seitentür.

4. Helpdesk-Verifikation standardisieren

Okta empfiehlt ausdrücklich, Verfahren zu etablieren, mit denen Nutzer die Identität von Helpdesk-Mitarbeitenden prüfen können. (okta.com)

Das kann zum Beispiel bedeuten:

• Rückruf nur über veröffentlichte interne Helpdesk-Nummern.
• Ticketnummern, die im internen Portal überprüfbar sind.
• Kein Support per privater Telefonnummer.
• Keine MFA-Bestätigung während eines ungeplanten Support-Anrufs.
• Klare Eskalationswege für verdächtige Anrufe.

Diese Prozesse müssen einfach sein. Wenn die sichere Alternative kompliziert ist, wählen Mitarbeitende im Stress den schnelleren, unsicheren Weg.

5. Authenticator- und Passkey-Lifecycle überwachen

Microsoft weist darauf hin, dass Administratoren Audit Logs, Sign-in Logs und Nutzerbenachrichtigungen verwenden können, um Passkey-Erstellung und -Nutzung zu überwachen. Zudem gibt es keine automatische Passkey-Ablaufzeit; Lifecycle-Hygiene bleibt also eine administrative Aufgabe. (Microsoft Learn)

Security-Teams sollten daher gezielt auf folgende Ereignisse achten:

• Neue Passkey- oder FIDO2-Registrierungen.
• Neue Authentifizierungsmethoden kurz nach verdächtigen Logins.
• Registrierungen aus ungewohnten Ländern, ASNs oder IP-Bereichen.
• Änderungen bei privilegierten Konten.
• Mehrere MFA-Fehlversuche vor erfolgreicher Registrierung.
• Datenzugriffe in SharePoint, OneDrive oder Exchange direkt nach Methodenänderungen.

6. Standort-, Geräte- und Risiko-Signale nutzen

Okta empfiehlt, Anfragen aus Regionen zu blockieren, in denen die Organisation keine Services anbietet, und sensible Anwendungen an Bedingungen wie verwaltete Geräte und Endpoint-Schutz zu knüpfen. (okta.com)

Für Microsoft-365-Umgebungen heißt das: Conditional Access sollte nicht nur „MFA ja/nein“ prüfen, sondern Kontext berücksichtigen. Ein Login von einem unbekannten Gerät aus einem ungewöhnlichen Land sollte nicht dieselben Möglichkeiten haben wie ein Login von einem verwalteten Unternehmensgerät im normalen Arbeitskontext.

Fazit

Passkeys bleiben eine sehr gute Sicherheitsmaßnahme. Der aktuelle Angriff zeigt aber: Starke Authentifizierung allein reicht nicht, wenn der Registrierungsprozess schwach ist.

Die eigentliche Lehre lautet: Unternehmen müssen nicht nur den Login schützen, sondern den gesamten Identity Lifecycle – vom Onboarding über die Registrierung neuer Faktoren bis zur Überwachung und Entfernung alter Methoden. Wer Passkeys einführt, sollte parallel Kommunikationsprozesse, Helpdesk-Verifikation, Conditional Access, Monitoring und Incident Response nachschärfen.

Denn Angreifer gehen dorthin, wo Sicherheit noch ungewohnt ist. Und gerade neue Sicherheitsfunktionen sind für Social Engineering attraktiv, solange Mitarbeitende nicht genau wissen, wie ein legitimer Prozess aussieht.

Mit dem Patchday im Juni 2026 hat Microsoft neue Sicherheitsupdates für Exchange Server veröffentlicht. Betroffen sind Exchange Server 2016, Exchange Server 2019 sowie Exchange Server Subscription Edition (SE).

Auch wenn das Update auf den ersten Blick überschaubar erscheint, sollten Administratoren die Installation zeitnah einplanen. Neben Sicherheitskorrekturen enthält das Update eine wichtige Anpassung im Zusammenhang mit den Exchange Emergency Mitigation Services (EMS), die für den automatischen Schutz vor zukünftigen Bedrohungen relevant ist.

Die Veröffentlichung erfolgt in einer Phase erhöhter Aufmerksamkeit für Exchange-Umgebungen, nachdem in den vergangenen Wochen eine öffentlich bekannte Schwachstelle in Outlook Web Access (OWA) für Diskussionen innerhalb der IT-Sicherheitscommunity sorgte.

Was beinhaltet das Exchange Server Sicherheitsupdate Juni 2026?

Microsoft hat die Sicherheitsupdates für folgende Exchange-Versionen bereitgestellt:

• Exchange Server Subscription Edition (SE)
• Exchange Server 2019
• Exchange Server 2016

Laut Microsoft behebt das Update Sicherheitslücken innerhalb der Exchange-Plattform und enthält zusätzlich eine Anpassung zur weiteren Funktionsfähigkeit der Exchange Emergency Mitigation Services (EMS) und des Feature Flighting Service.

Administratoren sollten das Update unabhängig davon installieren, ob aktuell bekannte Angriffe auf die eigene Umgebung vorliegen.

Welche Schwachstelle steht aktuell besonders im Fokus?

Bereits im Mai 2026 hatte Microsoft die Sicherheitscommunity über die Schwachstelle CVE-2026-42897 informiert.

Die Sicherheitslücke betrifft Outlook Web Access (OWA) in lokalen Exchange-Installationen. Angreifer können speziell präparierte E-Mails verwenden, um unter bestimmten Bedingungen JavaScript-Code im Browser eines Benutzers auszuführen. Betroffen sind ausschließlich lokale Exchange-Server, nicht jedoch Exchange Online in Microsoft 365. (TECHCOMMUNITY.MICROSOFT.COM⁠)

Bereits vor Veröffentlichung der Juni-Updates wurde die Schwachstelle öffentlich diskutiert und es existierten temporäre Schutzmaßnahmen über die Exchange Emergency Mitigation Services (EEMS). Mit den aktuellen Sicherheitsupdates steht nun die empfohlene dauerhafte Absicherung zur Verfügung.

Warum die EMS-Anpassung wichtig ist

Ein zentraler Bestandteil der Juni-Updates ist eine technische Anpassung für den Exchange Emergency Mitigation Service.

Microsoft hat darauf hingewiesen, dass ältere Installationen künftig Probleme bei der Verarbeitung neuer Notfallmaßnahmen erhalten können. Ohne die aktuellen Updates könnten nach Juni 2026 veröffentlichte Mitigations unter Umständen nicht mehr automatisch angewendet werden. (Microsoft Support⁠)

Für Unternehmen bedeutet dies:

• Sicherheitsmaßnahmen könnten verzögert greifen
• Automatische Schutzmechanismen verlieren an Wirksamkeit
• Die Reaktionsfähigkeit bei Zero-Day-Schwachstellen sinkt

Gerade nach den Erfahrungen der letzten Jahre mit ProxyShell, ProxyNotShell und weiteren Exchange-Sicherheitsvorfällen sollte dieser Aspekt nicht unterschätzt werden.

Was sollten Exchange-Administratoren jetzt tun?

1. Sicherheitsupdate zeitnah installieren

Microsoft empfiehlt die Installation der Juni-2026-Sicherheitsupdates für alle unterstützten Exchange-Versionen.

Vor der Installation sollten:

• Aktuelle Backups geprüft werden
• Exchange Health Checks durchgeführt werden
• Replikations- und DAG-Status kontrolliert werden

2. Exchange-Version und Buildstand überprüfen

Viele Umgebungen verwenden noch ältere Buildstände oder nicht unterstützte Konfigurationen.

Microsoft empfiehlt, ausschließlich unterstützte Exchange-Versionen und aktuelle Cumulative Updates zu betreiben. Nur so können Sicherheitsupdates vollständig installiert werden. (Microsoft Learn⁠)

3. Exchange Emergency Mitigation Service aktivieren

Der Exchange Emergency Mitigation Service bietet einen zusätzlichen Schutzmechanismus gegen neu entdeckte Angriffe.

Organisationen sollten prüfen:

• Ist EEMS aktiviert?
• Funktioniert die Kommunikation mit Microsoft?
• Werden Mitigations erfolgreich verarbeitet?

4. Langfristige Exchange-Strategie bewerten

Für viele Unternehmen wird 2026 ein strategisch wichtiges Jahr.

Microsoft treibt die Weiterentwicklung der Exchange Server Subscription Edition (SE) voran und empfiehlt den Umstieg auf unterstützte Plattformen, um weiterhin Sicherheitsupdates und Support zu erhalten. (Microsoft Learn⁠)

Welche Entwicklungen sollten Unternehmen zusätzlich beobachten?

Neben den aktuellen Sicherheitsupdates gibt es weitere Themen, die Exchange-Verantwortliche auf dem Radar haben sollten.

Exchange Web Services (EWS) wird in Exchange Online eingestellt

Microsoft hat konkrete Termine für die Abschaltung von Exchange Web Services in Exchange Online veröffentlicht.

Ab Oktober 2026 beginnt die schrittweise Deaktivierung, die vollständige Abschaltung erfolgt im April 2027. Unternehmen mit Eigenentwicklungen oder Drittanbieter-Lösungen sollten frühzeitig prüfen, ob noch Abhängigkeiten zu EWS bestehen und gegebenenfalls auf Microsoft Graph migrieren.

Fokus auf lokale Exchange-Sicherheit steigt weiter

Sicherheitsbehörden und Microsoft empfehlen weiterhin:

• Multi-Faktor-Authentifizierung
• Minimierung privilegierter Konten
• Regelmäßige Installation von Security Updates
• Einsatz von Zero-Trust-Prinzipien
• Nutzung aktueller Exchange-Versionen

Insbesondere lokale Exchange-Server bleiben ein bevorzugtes Ziel für Angreifer und sollten entsprechend abgesichert werden.

Fazit

Die Exchange Server Sicherheitsupdates vom Juni 2026 enthalten zwar keine umfangreichen Funktionsänderungen, sind jedoch für die Sicherheit und Zukunftsfähigkeit lokaler Exchange-Umgebungen relevant.

Neben der Behebung von Sicherheitslücken sorgt das Update dafür, dass die Exchange Emergency Mitigation Services weiterhin korrekt funktionieren. Unternehmen sollten die Installation daher kurzfristig einplanen und gleichzeitig ihre langfristige Exchange-Strategie überprüfen.

Die Kombination aus aktuellen Sicherheitsupdates, aktivem Mitigation Service und einer unterstützten Exchange-Version bleibt die wichtigste Grundlage für einen sicheren Betrieb lokaler Exchange-Infrastrukturen.