Ein Fehler im Azure-SSO von Windows Admin Center könnte Angreifern ermöglichen, von einem kompromittierten Rechner aus auf sämtliche Azure-VMs und Arc-verbundene Systeme im gesamten Mandanten zuzugreifen.
Die Sicherheitslücke „… ermöglicht es einem Angreifer mit lokalen Administratorrechten auf nur einem Rechner, seine Privilegien auszuweiten, Remote-Code auszuführen und sich lateral über Azure-VMs und Arc-verbundene Systeme innerhalb desselben Mandanten zu bewegen, ohne über gültige Azure-Anmeldedaten zu verfügen“, sagten Cymulate-Forscher.
Der Token-Fehler in Windows Admin Center
Die als CVE-2026-20965 geführte Sicherheitslücke betrifft Unternehmen, die Windows Admin Center zur Verwaltung von Azure-VMs und Arc-verbundenen Systemen einsetzen – insbesondere, wenn Administratoren häufig über das Azure-Portal Verbindungen herstellen.
Das Hauptrisiko besteht darin, dass ein Angreifer, der sich auf einem von WAC verwalteten System festsetzt, diesen Zugriff möglicherweise nutzen kann, um sich lateral zu bewegen und andere Rechner im gesamten Mandanten zu erreichen.
Der Azure-SSO-Ablauf von Windows Admin Center beruht darauf, dass zwei separate Token zusammenwirken.
Das erste Token, WAC.CheckAccess, wird verwendet, um zu bestätigen, dass der Benutzer über die erforderlichen rollenbasierten Berechtigungen verfügt.
Das zweite ist ein Proof-of-Possession-Token (PoP), das die Wiederverwendung von Token verhindern soll, indem es die Authentifizierung an kryptografische Schlüssel bindet, die im Browser erzeugt werden.
Unter normalen Bedingungen trägt diese Kombination dazu bei, sicherzustellen, dass ein gestohlenes Token selbst dann nicht aus einem anderen Kontext wiederverwendet werden kann.
Die Cymulate-Forscher stellten fest, dass WAC diese Token nicht so strikt validierte wie erforderlich.
In der Praxis konnten Angreifer ein gestohlenes WAC.CheckAccess-Token mit einem gefälschten PoP-Token kombinieren und sich so als privilegierte Benutzer ausgeben sowie auf anderen WAC-fähigen Systemen aus der Ferne administrative Befehle ausführen.
Die Ursache sind mehrere Lücken bei der Validierung, darunter fehlende UPN-Prüfungen zwischen den Token, die Akzeptanz mandantenübergreifender PoP-Token, die Wiederverwendung von Nonces sowie die Unterstützung von PoP für Nicht-Gateway-URLs wie den direkten IP-Zugriff über Port 6516.
Noch wichtiger ist, dass das WAC.CheckAccess-Token nicht ausreichend eingeschränkt war. Dadurch konnte sich die Autorisierung über einen einzelnen Rechner hinaus erstrecken und effektiv umfassendere Zugriffsmuster auf Mandantenebene ermöglichen.
Was zum Auslösen des Angriffs erforderlich ist
Die Ausnutzung erfolgt nicht vollständig „im Vorbeigehen“.
Der Angreifer muss bereits über lokale Administratorrechte auf einer WAC-fähigen Azure-VM oder einem Arc-verbundenen Rechner verfügen, und ein privilegierter Benutzer muss während des Zeitfensters des Angreifers über das Azure-Portal eine WAC-Sitzung starten.
Sind diese Bedingungen jedoch erfüllt, kann der Schaden erheblich sein – mit lateraler Bewegung, Privilegienausweitung und einer umfassenden Kompromittierung von Systemen, die als voneinander isoliert galten.
Microsoft hat einen Patch zur Behebung des Problems veröffentlicht. Unternehmen sollten ihn umgehend installieren und zugleich ihre Protokolle auf Anzeichen für Token-Missbrauch oder ungewöhnliche mandantenübergreifende Identitätsaktivitäten überprüfen.
So lässt sich die mandantenweite Gefährdung reduzieren
Unternehmen, die Windows Admin Center in Azure betreiben, sollten CVE-2026-20965 als Risiko mit hoher Priorität einstufen, da ein einziger kompromittierter Host dadurch den gesamten Mandanten gefährden kann.
Sicherheitsteams sollten außerdem davon ausgehen, dass sich Token-Missbrauch ohne gezielte Überwachung nur schwer erkennen lässt.
- Führen Sie ein Upgrade auf die Windows Admin Center Azure Extension v0.70.00 oder höher durch und entfernen Sie WAC dort, wo es nicht erforderlich ist, um die Angriffsfläche zu verkleinern.
- Beschränken Sie den WAC-Zugriff nach dem Prinzip der geringsten Privilegien,PIM und Conditional-Access-Kontrollen (z. B. MFA, konforme Geräte sowie standort- und risikobasierte Richtlinien).
- Schränken Sie die Netzwerkauslastung ein, indem Sie Port 6516 auf vertrauenswürdige Pfade beschränken, die ausschließlich über Gateways führen und NSG-/JIT-Regeln verschärfen, um einen umfassenden eingehenden Zugriff zu verhindern.
- Isolieren Sie WAC-fähige Systeme in dedizierten Verwaltungs-Subnetzen und beschränken Sie den ausgehenden Datenverkehr, um laterale Bewegungen und Wege für Token-Missbrauch zu reduzieren.
- Überwachen Sie Identitäts- und Token-Anomalien, darunter mandantenübergreifende UPN-Anmeldungen, unerwartete WAC_user-Konten sowie Anzeichen für PoP-/Token-Wiederholungen.
- Lösen Sie bei verdächtigen WAC-Aktivitäten wie Spitzen bei InvokeCommand, neuen Identitäten auf Zielsystemen sowie nicht autorisierten WAC-Diensten oder -Prozessen, die auf eine Manipulation hindeuten, Alarme aus.
Diese Maßnahmen zeigen praktikable Schritte auf, um die Lücke zu schließen, laterale Bewegungen zu begrenzen und verdächtige WAC-Aktivitäten frühzeitig zu erkennen.
Mandantenweites Risiko durch ein einziges schwaches Glied
Diese Sicherheitslücke erinnert daran, dass Fehler bei der Identitäts- und Token-Validierung routinemäßige Administrationsabläufe in ein mandantenweites Risiko verwandeln können – insbesondere in Cloud-Umgebungen, die auf Geschwindigkeit und Skalierbarkeit ausgelegt sind.
Unternehmen sollten Windows Admin Center umgehend patchen und anschließend Zugriffskontrollen, Netzwerkeinschränkungen und Überwachung verstärken, um den Schaden zu begrenzen, falls ein einzelnes System kompromittiert wird.
Deshalb setzen Unternehmen auf ein Zero-Trust-Sicherheitsmodell, das davon ausgeht, dass ein Sicherheitsvorfall eintritt, und dessen Auswirkungen begrenzt.