Zero-day vulnerabilities pose a serious threat in the field of cybersecurity. These flaws are usually discovered and exploited by criminals before security researchers even know of their existence. Because of this, we call them 0-day. It indicates the amount of time the “good people” have had to study and solve the problem. So if this number is zero, it’s certainly bad news.
It’s a Remote Code Execution Vulnerability in Microsoft Windows’ Support Diagnostic Tool (MSDT), that allows a remote attacker to execute arbitrary shell commands on the target system. Officially recognized as CVE-2022-30190, it was renamed Follina by Kevin Beaumont, one of the first to document it.
I’m calling it Follina because the spotted sample on the file references 0438, which is the area code of Follina in Italy.Kevin Beaumont
The vulnerability relies on a call to the MSDT via the URL protocol from a calling application that can be for instance Microsoft Word. In this scenario, a Word document loads malicious code from a remote web server and passes it to the MSDT executable via the ms-msdt protocol. As soon as someone opens the document, or even just loads a preview of it, the downloaded PowerShell code is executed. The attacker can precompile this code that will then run with the privileges of the user who opened the infected file.
John Hammond reported a more detailed analysis of the vulnerability, if you’re interested in further reading. He also provided an example of its exploitation:
Fortunately, even in the worst case of a zero-day vulnerability, there are many security enthusiasts investigating the problem and doing their best to inform the community. Several people like the following have started to gradually reproduce the exploit on various machines and publish detection rules:
This list is only a small part of the community’s contributions and shows us how quickly researchers can act and work to ensure a high level of safety for all of us.
We in the SOC Team at Würth-Phoenix worked on the vulnerability to simulate a successful attack and test the efficiency of our detection rules. We used the PoC mentioned above in a controlled environment and executed the exploit.
Note: in a real scenario an attacker will not open the calculator, but rather will try to gain control of the machine.
Through our Elastic SIEM we can monitor the status of our devices and generate alerts in case of anomalies. The Follina exploit in the previous image was correctly detected with a rule created specifically for its detection.
Follina is also detected with a generic rule that monitors unusual child processes. This works because the msdt.exe instance is not normally launched from a Word document and this peculiarity is detected.
Follina was disclosed on May 27 and at the time of publishing this post, 18 days later, we are still waiting for an official patch to fix the problem. At the moment, what Microsoft has been able to provide us with are just a few mitigations. These reduce the likelihood of Follina being exploited, but do not represent an ultimate solution. While we wait, we can count on the ongoing work of security specialists. And remember to always be wary of opening documents if we are unable to assess their trustworthiness.
Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find security issues interesting, maybe you could start in a roles like this as well as other roles here at Würth Phoenix.