Malicious Code Execution Traced to Weaponized Office Documents Dating From April.
Attention to anyone who manages a Microsoft Windows environment: Security researchers are tracking a zero-day vulnerability in Microsoft Office that’s being actively exploited by attackers to run malicious code on a vulnerable system.
Evidence of the vulnerability first came to light publicly on Friday, when the Japan-based “nao_sec” cybersecurity research team flagged a malicious document, submitted to the malware-scanning service VirusTotal from an IP address in Belarus. The vulnerability “uses Word’s external link to load the HTML and then uses the ‘ms-msdt’ scheme to execute PowerShell code,” nao_sec reports.
The Microsoft Support Diagnostics Tool, or MSDT, is a utility built into Windows that’s designed to collect information to send to Microsoft for analysis by support personnel, so they can help resolve problems.
After analyzing the attack, security researcher Kevin Beaumont says the exploit chain allows an attacker to use MSDT to execute arbitrary PowerShell code on a system, which they can use to download and execute malicious code.
The exploit can be triggered in multiple ways, including via “a hover-preview of a downloaded file that does not require any clicks,” via the preview pane in Windows Explorer, writes John Hammond, a senior security researcher at Huntress, in a blog post.
“I’ve validated it’s working on my test systems and is trivial to exploit,” tweets Jake Williams, director of threat intelligence at Scythe. “Sorry to barge in on your Memorial Day weekend.”
All of this “should not be possible,” not least because Office includes Protected View: a read-only mode where most editing functions are disabled, which is designed specifically to block weaponized Office documents from triggering, Gossi says in a blog post.
He’s dubbed the flaw “Follina” in reference to the numerical string “0438,” which is part of the name of the malicious file uploaded to VirusTotal, and which also happens to be the telephone area code for the Italian municipality of Follina, northwest of Venice.
Microsoft Confirms Vulnerability
Microsoft on Monday confirmed the flaw and designated it CVE-2022-30190.
“A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word,” the company says in a security alert. “An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights.”
How the Attack Proceeds
How does the attack work? “There’s a lot going on here, but the first problem is Microsoft Word is executing the code via MSDT – a support tool – even if macros are disabled,” Gossi writes in his blog post. “Protected View does kick in, although if you change the document to RTF form, it runs without even opening the document – via the preview tab in Explorer – let alone Protected View.”
“This is a novel initial access technique that readily offers threat actors code execution with just a single click – or less,” Hammond of Huntress writes in his blog post. “This is an enticing attack for adversaries as it is tucked inside of a Microsoft Word document without macros to trigger familiar warning signs to users – but with the ability to run remotely hosted code.”
Components contained in the malicious file include a file named document.xml.rels which contains a reference to an external site that hosts attack code, Huntress reports, noting that the external site appeared to go offline Monday.
Researchers have found evidence that the vulnerability has been exploited since at least April. Gossi says documents abusing the flaw pretended to offer recipients a radio interview with Russian state-owned news agency Sputnik.
The flaw appears to be present and exploitable in at least Office 2013, Office 2016, Office 2019 and Office 2021. But Gossi says it might not work in newer, beta versions of Office, which suggests Microsoft could be aware of the problem and moving to design and distribute patches.
Microsoft did not immediately respond to a request for comment, but since it subsequently issued a security alert, no doubt patches are being prepared.
In the interim, Beaumont urges proceeding with caution on the mitigation front. “I’ve seen people proposing wacky ways to mitigate this,” he writes. “My take: don’t panic, see what Microsoft says. It’s not currently under mass exploitation.”
In its security alert, Microsoft details a workaround that involves adjusting the registry key on a Windows system to disable the MSDT URL protocol, which will prevent the vulnerable functionality from being invoked. The workaround can later be disabled via a further registry key tweak.
Microsoft also details how for users of Microsoft Defender’s Attack Surface Reduction, or ASR, “activating the rule ‘Block all Office applications from creating child processes’ in ‘block’ mode will prevent this from being exploited,” Huntress’ Hammond says. “However, if you’re not yet using ASR you may wish to run the rule in ‘audit’ mode first and monitor the outcome to ensure there’s no adverse impact on end users.”
For network defenders, Gossi’s blog post includes a query designed to spot attempts to exploit the vulnerability, which anyone using Defender for Endpoint can add as a “custom detection rule.”
For customers of endpoint security vendor Trelix, its lead threat research scientist, Christiaan Beek, has published to GitHub a custom detection that can be used to block these types of malicious Office documents.
Scythe’s Williams says organizations would do well to understand the threat this risk might pose and if they might be able to reconstruct how an attack occurred, if they do get hit using this vulnerability.
“You should probably be doing some detection engineering in your environment to understand how and where msdt.exe is used (e.g. what are the parent processes),” Williams tweets. “Also, the maldoc uses mpsigstub.exe, a legitimate Defender exe that is often excluded from logging.”
To read the original article: