CVE-2026-69676 Kerberos Remotecodeausfuehrung: Updates prüfen

Was ist CVE-2026-69676 Kerberos Remotecodeausfuehrung?

CVE-2026-69676 Kerberos Remotecodeausfuehrung betrifft Windows Kerberos und erfordert eine zeitnahe Überprüfung der installierten Sicherheitsupdates. Microsoft stuft die Schwachstelle als kritisch ein: Ein authentifizierter Angreifer mit niedrigen Berechtigungen auf einem betroffenen Server kann eine präparierte Anfrage übermitteln, die ohne Benutzerinteraktion Code auf diesem Server ausführt. Administratorzugriff wird im Sicherheitshinweis nicht als Voraussetzung genannt.

Der MSRC-CVRF für September 2026, am 3. Oktober 2026 als JSON abgerufen, enthält für diese CVE genau folgende Werte:

Die Revision des einzelnen Sicherheitshinweises ist 1.0 und datiert vom 8. September 2026. Es handelt sich um ein Sicherheitsupdate aus September, das im Oktober überprüft wird. Die CVE war am 3. Oktober 2026 nicht im CISA-Katalog bekannter ausgenutzter Schwachstellen enthalten, in der abgerufenen Katalogversion 2026.10.02. Diese Beobachtung und Microsofts Einschätzung der Ausnutzung sind getrennte Belege; keiner davon schließt aus, dass andernorts eine Ausnutzung stattgefunden haben könnte.

Funktionsweise: Capture-Replay und niedrige Berechtigungen

Microsoft benennt eine Umgehung der Authentifizierung durch Capture-Replay. Die Beschreibung verortet die daraus resultierende Codeausführung im Netzwerk, während die FAQ einen authentifizierten Angreifer mit niedrigen Berechtigungen auf dem betroffenen Server voraussetzt. Für den Betrieb bedeutet das: Das Einspielen des Updates darf nicht allein deshalb aufgeschoben werden, weil normale Konten keine Administratorrechte besitzen.

Der öffentliche CVRF erklärt weder, welche Nachricht abgefangen wird, noch wie sie erneut abgespielt wird oder welcher Verarbeitungspfad genau verwundbar ist. Er nennt auch nicht die Identität, unter der der resultierende Code ausgeführt wird. Eine detaillierte Paketfolge, ein Exploit-Befehl oder die Behauptung einer automatischen Kompromittierung der Domäne würde über diese Belege hinausgehen.

Die durch den Sicherheitshinweis bestätigte Angriffskette

1. Der Angreifer verfügt über authentifizierten Zugriff mit niedrigen Berechtigungen auf einen betroffenen Server.
2. Der Angreifer sendet eine präparierte Anfrage über das Netzwerk.
3. Code wird auf diesem Server ausgeführt, ohne dass ein Benutzer interagieren muss.

Dies sind die dokumentierten Grenzen des Szenarios, kein Proof of Concept. Die Voraussetzung niedriger Berechtigungen macht kompromittierte normale Identitäten für die Priorisierung relevant. Der Sicherheitshinweis besagt jedoch nicht, dass jedes Domänenkonto jeden Server ausnutzen kann.

Erkennung: Kerberos-Kontext erfassen und anschließend untersuchen

Microsofts Ereignisdokumentation liefert nützliche Einblicke in Kerberos auf Domänencontrollern. Diese Ereignisse können eine Untersuchung unterstützen, doch keines wird hier als zuverlässige Signatur für die Ausnutzung von CVE-2026-69676 dokumentiert.

Aktivieren Sie die Überwachungsunterkategorien Kerberos Authentication Service und Kerberos Service Ticket Operations und sammeln Sie die Ereignisse zentral. Prüfen Sie die Erfassung von Erfolgen und Fehlern, soweit zutreffend. Der veröffentlichte Leitfaden zur Sicherheitsüberwachung von Active Directory erklärt, warum Überwachungsrichtlinien, Weiterleitung, Erhalt der Felder und Vergleichswerte zusammenspielen müssen, bevor eine SIEM-Abfrage eine nützliche Abdeckung bietet.

KQL-Ausgangspunkt für die Triage

Diese von einem Analysten verfasste Abfrage verwendet die dokumentierte SecurityEvent-Tabelle und ihre typisierten Spalten. In dieser Tabelle ist EventData eine Zeichenfolge; die Abfrage greift daher nicht wie auf ein dynamisches Objekt darauf zu. Sie gruppiert Aktivitäten zur Prüfung. Der Rückblick über 24 Stunden und die 15-Minuten-Intervalle sind Entscheidungen für die Untersuchung, keine Exploit-Schwellenwerte.

SecurityEvent
| where TimeGenerated > ago(24h)
| where Channel == "Security"
| where EventSourceName == "Microsoft-Windows-Security-Auditing"
| where EventID in (4768, 4769, 4771)
| extend Account = TargetUserName,
         ClientIP = IpAddress,
         Service = ServiceName
| summarize Events = count(), Services = make_set(Service, 20)
    by bin(TimeGenerated, 15m), Computer, EventID, Account, ClientIP, Status
| order by Events desc

Bestätigen Sie, dass Ihr Connector diese Ereignis-IDs in SecurityEvent erfasst und für jeden Ereignistyp TargetUserName, IpAddress, ServiceName und Status befüllt. Vergleichen Sie Beispielzeilen mit dem ursprünglichen Ereignis-XML. Fehlende Felder erfordern eine Überprüfung des Parsers, bevor die gruppierten Ergebnisse nützlich sind. Interpretieren Sie fehlende Werte oder ein leeres Ergebnis nicht als Beleg dafür, dass keine Ausnutzung stattgefunden hat. Diese Abfrage wurde nicht mit Kundentelemetrie ausgeführt.

Vergleichen Sie unbekannte Kombinationen aus Konto, Client und Dienst sowie Aktivitätsspitzen mit dem Normalbetrieb, Änderungsfenstern und Endpunktbelegen auf dem betroffenen Server. Ticketereignisse auf Domänencontrollern bilden nicht vollständig ab, was auf einem Mitgliedsserver ausgeführt wird. Bewahren Sie Hosttelemetrie auf, wenn verdächtige Aktivitäten mit einem ungepatchten System zusammenfallen.

Der separate Leitfaden zum Kerberos-RC4-Fallback erklärt, wie sich Belege zur Ticketverschlüsselung von der Kontokonfiguration unterscheiden lassen und wie AES-Abhängigkeiten sicher behoben werden können. RC4-Aktivität liefert Kontext; ein Wechsel zu AES ist nicht als Behebung dieser CVE belegt.

Behebung: Das richtige Update für jedes Produkt überprüfen

1. Jedes System seinem CVRF-Produkt zuordnen

Lesen Sie die Einträge zu betroffenen Produkten und Abhilfemaßnahmen für die Windows-Version und den Installationstyp des Systems. Der Eintrag umfasst Windows-Clients ebenso wie Serverprodukte. Eine AD-Prüfung sollte daher nicht annehmen, dass nur Domänencontroller relevant sind.

Für Windows Server 2025 ordnet der CVRF ProductID 12436 und Server Core ProductID 12437 KB5122871 zu, mit FixedBuild 10.0.26100.33438 und RestartRequired Yes. Die Updateseite von Microsoft Support bestätigt die Veröffentlichung am 8. September und den Betriebssystembuild 26100.33438. Verwenden Sie dies als versionsspezifisches Beispiel, nicht als KB für jede Windows-Version. Dieselbe Supportseite dokumentiert eine Regression der Remotedesktopdienste nach dem September-Update und erklärt, dass sie in Updates behoben ist, die am oder nach dem 14. September 2026 veröffentlicht wurden. Prüfen Sie vor der Bereitstellung die aktuellen bekannten Probleme und die anwendbaren ersetzenden Updates.

2. Installationsbelege sammeln

Passen Sie auf einem Windows-Server-2025-System die dokumentierte Suche nach ID aus Get-HotFix an die oben bestätigte KB an:

Get-HotFix -Id KB5122871

Für zusätzliche Versionsbelege wird dieser Befehl direkt aus der Dokumentation zu Get-ComputerInfo übernommen:

Get-ComputerInfo -Property "*version"

Diese Befehle sind Beispiele auf Grundlage der Dokumentation, keine Messungen Ihrer Server. Get-HotFix fragt Win32_QuickFixEngineering ab; bewahren Sie zusätzlich Wartungsnachweise und vollständige Belege zum Betriebssystembuild auf. Fehlt die ursprüngliche KB, prüfen Sie, ob ein installiertes kumulatives Update sie ersetzt und die Korrektur enthält. Erklären Sie ein System nicht allein aufgrund einer erfolglosen KB-Suche für verwundbar oder gepatcht.

3. Installieren, neu starten und erneut prüfen

Stellen Sie das anwendbare Sicherheitsupdate oder ein überprüftes ersetzendes Update über Ihren unterstützten Wartungsprozess bereit. Führen Sie den erforderlichen Neustart durch, dokumentieren Sie den laufenden Build und prüfen Sie Kerberos-abhängige Anwendungen. Erfassen Sie Ausnahmen mit einem Verantwortlichen und einem Behebungsdatum. Solange eine Ausnahme besteht, beschränken Sie unnötigen Zugriff auf den betroffenen Server und überwachen Sie verdächtige Aktivitäten; diese Maßnahmen ersetzen das Update nicht.

Wie EtcSec dies erkennt

Für diesen Artikel wurde keine direkte EtcSec-Prüfung für CVE-2026-69676 verifiziert. Verwenden Sie ein Ergebnis zur Sicherheitskonfiguration von etc-collector allein nicht als Beleg für den Patchstatus oder eine Ausnutzung.

Nutzen Sie die oben beschriebenen Patchbelege und den Ablauf zur Kerberos-Untersuchung, um dieses Problem zu bewerten. Halten Sie bei der Dokumentation des Ergebnisses Konfigurationsbefunde, Nachweise installierter Updates und Vorfallsbeobachtungen getrennt. Eine Konfigurationsprüfung ohne Befund allein kann nicht belegen, dass dieser Windows-Codefehler behoben wurde.