|
Update: We now have an official blog post from Microsoft: The workaround to disable the MSDT URL Protocol is now confirmed, and we do have a CVE number for the issue.
It was a long weekend for many European countries, and it's an off-day in the US, but we were aware of a new attack vector for Microsoft Office documents. It started with a tweet from @nao_sec[1], who reported an interesting Word document. Office documents have been a common way to drop malware into victims’ computers for a while. We have to fight against VBA macros, XLS 4 macros, embedded payload, etc. But the one described here is interesting. The file is detected by only 17 antivirus engines on VT (sha256:4a24048f81afbe9fb62e7a6a49adbd1faf41f266b5f9feecdceb567aec096784)[2] When you open the file, nothing is displayed (it seems like a blank document), but, looking at the document specs, you see something interesting: The document contains an external reference pointing to a malicious URL:
This host, www[.]xmlformats[.]com, will be visited when you open the document (and activate the content). The following payload will be fetched:
Microsoft Office will automatically process the MSDT URL and execute the Powershell payload. The Base64 contains this:
Even if macros are disabled, the protected view feature does its job. However, Kevin Beaumont tested a document converted into an RTF form. It works even when you preview the document in Windows explorer[4]. This vulnerability does not work with all Office versions (at least in Office 2013 and 2016). While we had a look at the malicious file during the weekend, Didier generated a new payload that will fire a classic calculator as a demonstration of the code execution. He recorded a video of the behavior [5]. This behavior is really bad. How to detect this? Note that the suspicious scheme ("ms-msdt:/") is not present in the document. It's present in the first stage payload that will be downloaded by Office. Here are some ideas: 1. Check the parent-child relationship: A good idea is to track msdt.exe processes launched from parent processes like word.exe or excel.exe. 2. Delete the 'ms-msdt' scheme from the registry. Didier performed some tests, and it works[6]. 3. Prevent Office from spawning child processes by creating an ASL rule:
4. Of course, train your users not to open suspicious documents. We will continue to keep an eye on this new attack vector and update this diary. Feel free to share your findings with us. [1] https://twitter.com/nao_sec/status/1530196847679401984?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1530196847679401984%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fnao_sec%2Fstatus%2F1530196847679401984image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07 Xavier Mertens (@xme) |
Xme 697 Posts ISC Handler Jun 1st 2022 |
| Reply Subscribe |
Jun 1st 2022 4 weeks ago |
The interesting part is the windows.location.href. The protocol schema is “ms-msdt:/“ (note the single slash!). What’s this MSDT or “Microsoft Support Diagnostic Tool”? msdt.exe is a tool provided by Microsoft that will collect information to send to Microsoft Support[
Sign Up for Free or Log In to start participating in the conversation!
https://www.sans.edu
