A new Windows Search zero-day vulnerability could be used to automatically open a search window containing a remotely hosted malware executable by launching a Word document.
Security concerns can be exploited because Windows supports a URI protocol handler called “search-ms”, which allows applications and HTML links to initiate custom searches on the device.
While most Windows Searches will find an index of the local device, it is also possible to force Windows Search to query the file share on the remote host 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 its utilities. To search this remote share and list only files matching a specific name, you can use the following “search-ms” URI:
As you can see from the command above, the search-ms ‘crumb’ variable specifies where to search, and the ‘displayname’ variable specifies the search title.
When executing this command on Windows 7, Windows 10, and Windows 11 from the Run dialog or from the web browser address bar, a custom search window appears as shown below.
Note how the window title is set to the “search system internal” display name we specified in the search-ms URI.
Threat actors can use the same method for malicious attacks, where they send phishing emails masquerading as security updates or patches that need to be installed.
They could then set up a remote Windows share that could be used to host malware masquerading as a security update and then include a search-ms URI in its phishing attachment or email.
However, getting users to click on such a URL is not easy, especially when it displays a warning like the one below.
But Hacker House co-founder and security researcher Matthew Hickey has found a way to combine a newly discovered Microsoft Office OLEObject vulnerability with the 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 found Threat actors are exploiting a new Windows zero-day vulnerability in the Microsoft Windows Support Diagnostic Tool (MSDT). To exploit it, attackers created malicious Word documents that launch the “ms-msdt” URI protocol handler, which executes PowerShell commands simply by opening the document.
The vulnerability, identified as CVE-2022-30190, modifies Microsoft Office documents to bypass Protected View and launch the URI protocol handler without user interaction, which only leads to further abuse of the protocol handler.
I saw this yesterday Hickey converts existing Microsoft Word MSDT exploit Use the search-ms protocol handler we described earlier.
With this new PoC, when a user opens a Word document, it automatically launches a “search-ms” command to open a Windows search window listing executable files on a remote SMB share. This share can be named anything the threat actor wants, such as “Critical Update,” prompting the user to install the listed malware.
Microsoft Office search-ms: URI handler exploit, requires user interaction. Not patched. pic.twitter.com/iYbZNtMpnx
—hackerfantastic.crypto (@hackerfantastic) June 1, 2022
As with the MSDT exploit, Hickey also showed that you can create an RTF version that automatically opens the Windows Search window when the document is rendered in the Explorer preview pane.
This is the same search-ms attack exploited via RTF documents when the Windows Preview Pane is enabled… 😉 pic.twitter.com/AmOeGWltjm
—hackerfantastic.crypto (@hackerfantastic) June 1, 2022
Using this type of malicious Word document, threat actors can create a crafted phishing campaign that automatically launches a Windows Search window on the recipient’s device to trick them into launching malware.
Although this exploit is not as severe as the MS-MSDT remote code execution vulnerability, it could lead to abuse by diligent threat actors who want to create sophisticated phishing campaigns.
While we’ve found ways threat actors could exploit this new vulnerability in the wild, we won’t share this information for obvious reasons.
To mitigate this vulnerability, Hickey said you can use the same mitigation for the ms-msdt vulnerability — removing the search-ms protocol handler from the Windows registry.
- run command prompt as administration staff.
- To backup registry keys, execute the command “reg export HKEY_CLASSES_ROOTsearch-ms search-ms.reg“
- Excuting an order”reg delete HKEY_CLASSES_ROOTsearch-ms /f“
The nightmare of Windows protocols
MSDT and search-ms abuse examples are not new, originally disclosed by Benjamin Altpeter in his 2020 paper on Electron application security.
However, only recently have they started being weaponized in Word documents for phishing attacks without user interaction, turning them into zero-day exploits.
According to Microsoft’s guidance on CVE-2022-30190, the company appears to be addressing flaws in the protocol handler and its underlying Windows functionality, rather than the fact that threat actors can abuse Microsoft Office to launch these URIs without user interaction .
As noted by CERT/CC vulnerability analyst Will Dormann, these exploits actually exploit two different vulnerabilities. If the Microsoft Office URI problem is not fixed, further protocol handlers are abused.
Hickey also told BleepingComputer that he doesn’t think it’s necessarily a flaw in the protocol handler, but a combination that results in “Microsoft Office OLEObject search-ms Location Path Spoofing Vulnerability.”
“The next best thing is to fix the search function header and location setting message to prevent such spoofing attacks or disable it as a URI handler,” Hickey explained in a conversation about the flaws.
In June, researchers accidentally disclosed technical details and a proof-of-concept (PoC) exploit for a Windows Spooler RCE vulnerability dubbed PrintNightmare.
While the RCE component was quickly fixed, extensive local elevation of privilege vulnerabilities were discovered that continue to be disclosed under the “PrintNightmare” category.
It wasn’t until Microsoft made some drastic changes to Windows printing that they finally got hold of this vulnerability class, even though it caused countless printing problems for a while.
By addressing the issue only in terms of protocol handlers/Windows capabilities, Microsoft is facing a whole new category of “ProtocolNightmare” where researchers will continue to find new URI handlers to abuse in attacks.
Before Microsoft can’t start URI handlers in Microsoft Office without user interaction, prepare for a new vulnerability announcement for a series of similar news articles.