Windows Cyber ​​Security

New Windows Search added to Microsoft’s protocol nightmare

A new Windows Search vulnerability could be used to automatically open a search window containing executable malware hosted remotely by simply running a Word document.

The security issue can be taken advantage of because Windows supports a URI protocol handler called “search-ms” which allows applications and HTML links to start custom searches on the device.

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

For example, the popular Sysinternals toolkit allows you to remotely mount live.sysinternals.com as a network share to run its utilities. To search only this remote share and the list of files matching a given name, you can use the following URI “search-ms”:

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 “displayname” variable specifies the title of the search.

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

Windows search on a remote file share
Windows search on a remote file share
Source: BleepingComputer

Notice how the window title is set to the “Searching Sysinternals” display name we specified in the ms URI’s search title.

Threat actors can use the same technique for malicious attacks, where phishing emails are sent 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 ms-ms search resource identifier in their phishing attachments or emails.

However, it wouldn’t be easy to get the user to click on a URL like this, especially when it displays a warning, as shown below.

Browser warning when running URI protocol handlers
Browser warning when running URI protocol handlers
Source: BleepingComputer

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

Microsoft Office takes it to the next level

this week, Researchers discover That threat actors were using a new Windows vulnerability in the Microsoft Windows Support Diagnostic Tool (MSDT). To exploit it, attackers created malicious Word documents that launched a URI protocol handler “ms-msdt” to execute PowerShell commands simply by opening the document.

This flaw has been identified as CVE-2022-30190, which makes it possible to modify Microsoft Office documents to bypass Protected View and run URI protocol handlers without user interaction, which will only lead to further abuse of protocol handlers.

This was seen yesterday when Hickey has transformed existing Microsoft Word MSDT exploits to use the search-ms protocol handler we described earlier.

With this new PoC, when a user opens a Word document, it will automatically run a “search-ms” command to open a Windows Search window that lists executables on the remote SMB share. This post can be called anything the threat actor wants, such as “Important Updates,” which urges users to install the listed malware.

Like MSDT exploits, Hickey also demonstrated that you can create RTF versions that automatically open the Windows Search window when viewing the document in the Explorer preview pane.

Using this type of malicious Word document, threat actors can create elaborate phishing campaigns that automatically launch Windows Search windows on recipients’ machines to trick them into launching malware.

While this exploit is not as severe as the MS-MSDT Remote Code Execution vulnerability, it can lead to abuse by diligent threat actors who wish to create complex phishing campaigns.

Although we have found ways that threat actors can exploit this new flaw in the wild, we will not share 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. Being Command Prompt as such boss.
  2. To backup the registry key, run the command “reg export HKEY_CLASSES_ROOT\search-ms search-ms.reg
  3. Execute the commandreg delete HKEY_CLASSES_ROOT\search-ms /f

Windows Protocol

Examples of MSDT abuse and search-ms are not new, and were initially revealed by Benjamin Altpeter in 2020 in his dissertation on Electron application security.

However, it wasn’t until recently that they were weaponized in Word documents for phishing attacks without user intervention, turning them into zero-day vulnerabilities.

Based on Microsoft’s guidance for CVE-2022-30190, the company appears to be addressing flaws in its protocol processors and core Windows features, rather than the fact that threat actors could abuse Microsoft Office to launch URIs without user interaction.

As Will Dorman, Vulnerability Analyst at CERT/CC, says, these vulnerabilities actually use two different flaws. Without fixing the Microsoft Office URI issue, other protocol handlers will be misused.

Tweet Will Dorman

Hickey also told BleepingComputer that he believes this is not necessarily a flaw in the protocol handlers, but rather a combination that leads to a “location path spoofing vulnerability in Microsoft Office OLEObject-ms.”

Hickey explained in a chat about the flaws: “The next best thing is to fix address search capabilities and locator messages to prevent or disable such phishing attacks as a URI handler.”

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

While the RCE component was quickly fixed, a wide range of local privilege elevation vulnerabilities were discovered and continued to be exposed under the “PrintNightmare” rating.

It wasn’t until Microsoft made some drastic changes to Windows Printing that it finally got control of this category of vulnerabilities, even though it has been causing many printing problems for some time.

By addressing the issue only on the protocol/feature handler side of Windows, Microsoft is facing a whole new “ProtocolNightmare” classification where researchers will continue to find new URI handlers for abuse in attacks.

Until Microsoft makes it impossible to run URI handles in Microsoft Office without user interaction, be prepared for a whole series of similar news articles as new exploits are released.

Leave a Comment

Your email address will not be published.