Added new zero-day search for Windows to Microsoft protocol nightmare

A new zero-day vulnerability in Windows Search can be used to automatically open a search window containing remotely hosted malware executables simply by launching a Word document.

The security vulnerability can be exploited because Windows supports a URI protocol handler called “search-ms” that allows applications and HTML links to launch customized searches on a device.

While most Windows searches search the local device index, it is also possible to force Windows search to query file shares on remote hosts and use a custom title for the search window.

For example, the popular Sysinternals toolset allows you to remotely mount live.sysinternals.com as a network share to launch their utilities. To search this remote share and only list files that match a specific name, you can use the following “search-ms” URI:

search-ms:query=proc&crumb=location:%5C%5Clive.sysinternals.com&displayname=Searching%20Sysinternals

As you can see from the command above, the search-ms variable “crumb” specifies the location to search and the variable “displayname” specifies the search title.

A custom search window will appear when this command is executed from a Run dialog box or web browser address bar on Windows 7, Windows 10 and Windows 11 as shown below.

Notice how the window title is set to the friendly name “Searching Sysinternals” that we specified in the search-ms URI.

Threat actors could use the same approach for malicious attacks, sending phishing emails pretending to be security updates or patches that need to be installed.

They can then set up a remote Windows share that can be used to host malware disguised as security updates, and then include the search-ms URI in their phishing attachments or emails.

However, it would not be easy to get a user to click on a URL like this, especially when a warning is shown as shown below.

However, Hacker House co-founder and security researcher Matthew Hickey found a way, combining a newly discovered Microsoft Office OLEObject bug with the search-ms protocol handler to launch a remote search window simply by opening a Word document.

Microsoft Office takes it to the next level

In this week, researchers discovered that threat actors were exploiting a new Windows zero-day vulnerability in the Microsoft Windows Support Diagnostic Tool (MSDT). To exploit it, threat actors created malicious Word documents that launched the URI protocol handler “ms-msdt” to run PowerShell commands simply by opening the document.

The flaw identified as CVE-2022-30190 allows modifying Microsoft Office documents to bypass Protected View and launch URI protocol handlers without user interaction, which will only lead to further protocol handler abuse.

This was seen yesterday when Hickey converted existing Microsoft Word MSDT exploits to use the previously described search-ms protocol handler.

When a user opens a Word document with this new PoC, a “search-ms” command is automatically launched to open a Windows search window listing executable files on a remote SMB share. This share can be named whatever the attacker wants, e.g. B. “Critical Updates” which prompts users to install the listed malware.

Microsoft Office search-ms: URI handler exploit, requires user interaction. unpatched. pic.twitter.com/iYbZNtMpnx

— hackerfantastic.crypto (@hackerfantastic) June 1, 2022

Like the MSDT exploits, Hickey also showed that you can create RTF versions that automatically open a Windows search window when the document is rendered in the Explorer preview window.

Here is the same search-ms attack exploited by an RTF document when the Windows preview window is enabled… 😉 pic.twitter.com/AmOeGWltjm

— hackerfantastic.crypto (@hackerfantastic) June 1, 2022

By using this type of malicious Word document, attackers can create sophisticated phishing campaigns that automatically launch Windows search windows on recipients’ devices to trick them into launching malware.

While this exploit is not as severe as the MS-MSDT remote code execution vulnerability, it could lead to abuse by hardworking threat actors looking to create sophisticated phishing campaigns.

While we’ve already found ways for threat actors to exploit this new bug in the wild, we won’t be sharing this information for obvious reasons.

To mitigate this vulnerability, Hickey says you can use the same mitigation for ms-msdt exploits – delete the search-ms protocol handler from the Windows registry.

1. To run command prompt how Administrator.
2. To backup the registry key, run the command “reg export HKEY_CLASSES_ROOT\search-ms search-ms.reg“
3. Run the command “reg delete HKEY_CLASSES_ROOT\search-ms /f“

A Windows log Nightmare

Both the MSDT and search-ms abuse examples are not new and were originally disclosed by Benjamin Altpeter in 2020 in his thesis on the security of Elektron applications.

However, only recently have they been exploited in Word documents for phishing attacks without user interaction, making them zero-day vulnerabilities.

Based on Microsoft’s guidance for CVE-2022-30190, the company appears to be addressing the flaws in the protocol handlers and underlying Windows functions, rather than the fact that attackers can abuse Microsoft Office to launch these URIs without user interaction.

As CERT/CC vulnerability analyst Will Dormann points out, these exploits actually use two different flaws. Without fixing the Microsoft Office URI issue, more protocol handlers will be abused.

Hickey also told BleepingComputer that he believes this isn’t necessarily a bug in the protocol handlers, but rather a combination leading to a “Microsoft Office OLEObject-Search-ms Location Path Spoofing Vulnerability”.

“The next best thing is to fix the search feature title and location setting messages to prevent such spoofing attacks, or disable them as a URI handler,” Hickey explained in a conversation about the bugs.

In June, researchers inadvertently disclosed the technical details and a proof-of-concept (PoC) exploit for a Windows spooler RCE vulnerability called PrintNightmare.

While the RCE component was quickly fixed, a variety of local elevation of privilege vulnerabilities were discovered, which remained exposed under the PrintNightmare classification.

It wasn’t until Microsoft made some drastic changes to Windows printing that they finally got control of this class of vulnerabilities, although it caused numerous printing problems for some time.

By only addressing the issue on the protocol handler/windows features side, Microsoft faces an entirely new “ProtocolNightmare” classification, where researchers will continue to find new URI handlers to abuse for attacks.

Until Microsoft makes it impossible to launch URI handlers in Microsoft Office without user interaction, be prepared for a slew of similar news articles as new exploits are released.