ENISA Threat Landscape
Much has been said about the already famous vulnerability called Follina, reported as Zero Day earlier this year and also called with its more technical name as CVE-2022-30190, particularly associated with the Microsoft Support Diagnostic Tool (MSDT) URL protocol, considered by most DFIR teams as "a big headache" due to its unusual behavior. In most cases where attacks are received using Microsoft Office tools, teams usually assume that they occur through the most known methods, such as the use of the famous Macros, having already tested protections for these common mechanisms used in client-side attacks.
What happens when new ways of doing the same thing are born?
Are incident response teams mature enough to adapt to the new ways of attackers?
The reality is that more and more frequently these incident response teams must update their processes and mechanisms, especially when it comes to the use of valid services coupled with the normal operation of our operating system.
Although it is estimated that it has been running since April, at the end of May a strange document with the nomenclature 05-2022-0438.doc was detected for the first time and uploaded to virustotal. The researcher named this sample Follina, because the number 0438 is the zip code of the Italian town of Follina, Treviso. The report indicated the possibility of executing code through Office by taking advantage of the internal Windows MSDT (AKA Troubleshooter) service, which collects diagnostic information to send to Microsoft in case of any type of error.
Surely while reading this post you are wondering how an attacker can take advantage of this flaw if it must be executed on the client side. To understand this, let's see a brief explanation.
How a Client-Side attack works
If the victim's PC were our home, he would usually have the doors locked and the house key to be able to open them and let people in. Therefore, the attacker's objective would be to get someone from inside to open the door and let people in without any inconvenience. Now, how does an attacker get the door of a house opened? The main strategy used is the use of social engineering to convince the victim to open the door. To do this, the attacker looks for a common channel that the victim trusts and then, using different strategies, convinces the victim to execute a file or click on a link provided through this common channel (generating the action of opening the door from the inside).
Although the graphic example is absurd (although it often works successfully) when we talk about computer systems, let's replace the pizza with a latent need that involves, for example, downloading a Microsoft Word document to complete a form or read some information of interest to the victim and, on the client side, we are opening the door that the attacker needs.
Follina Client-Side Operation
Considering the above example, an Office document (in this case Word) is sent to the victim. This Office document will be created in such a way as to generate an error in order to invoke the Windows troubleshooting service discussed above, called MSDT.exe. One of the first versions of this malware behaved as follows:
That is, the word file (our pizza), executed by the victim, called an HTML file and downloaded malicious code running through PowerShell.
But why does this happen? The files have the possibility of attaching additional information in certain variables of the file, in order to provide cosmetic variables that are directly related to the document. Ex; If we use the 7z command to decompress the Word file, we could visualize the additional content that they have.
In this particular case the document uses the Word remote template function (Word/_rels) to retrieve an HTML file hosted on the attacker's server, this extract uses the "ms msdt" instruction scheme to load code and execute commands via PowerShell.
If we think about it, they are all tools provided by the operating system, except for the construction of our exploit. To provide more clarity, we will now use a proof of concept (PoC) to demonstrate how the vulnerability works. Our scenario consists of a Kali Linux, where we will build our payload. And a Windows 10, with the corresponding Microsoft Office pack installed.
The following graph shows what the correct scenario would look like:
1. The attacker sends the malicious file
2. The victim executes the file
3. The victim fetches the HTML with the corresponding instructions.
- First we will clone this github repository with the command gitclone of the repository: https://github.com/JohnHammond/msdt-follina
- Then we check that it has been cloned correctly:
- We will now proceed to create our first payload, with the command python3 follina.py -- port [Port of choice] , in the previous screenshot we can see that the script used leaves an HTML payload, in the port that we have previously selected:
- If we want to see how the requests made by the victim would look in real time, we could run a wget http://localhost:5555/ and visualize in the log of our script all the requests made.
-Then we copy the generated document follina.doc from the folder where it was hosted in our case /root/msdt-follina (To simulate sending it) Then we move it to our virtual machine with Windows 10:
- We proceed to execute the corresponding file, after having executed it we can observe how the MSDT.exe service opens and additionally the instruction to open the calculator is executed:
How to defend yourself
Although in the origins of these problems, the only thing we could do was to disable the msdt.exe service, it is very important nowadays to keep our operating systems updated. If we do not have a correct follow-up of the usual security patches, this could be our main point of weakness.
Within the patches are the following Knowledge Base (KB), to be taken into account;
KB5014678: Windows Server 2022
KB5014697: Windows 11
KB5014699: Windows 10 Version 20H2 – 21H2, Windows Server 20H2
KB5014692: Windows 10 Version 1809 (IoT), Windows Server 2019
KB5014702: Windows 10 1607 (LTSC), Windows Server 2016
KB5014710: Windows 10 1507 (RTM, LTSC)
KB5014738: Monthly Rollup Windows Server 2012 R2, Windows RT 8.1, Windows 8.1
KB5014746: Security only Windows Server 2012 R2, Windows RT 8.1, Windows 8.1
KB5014747: Monthly Rollup Windows Server 2012
KB5014741: Security only Windows Server 2012
KB5014748: Monthly Rollup Windows Server 2008 R2, Windows 7 SP1
KB5014742: Security only Windows Server 2008 R2, Windows 7 SP1
In the event that they are in the situation of not being able to apply patches due to the impossibility of updating the systems or, failing that, due to errors in the management of updates. You could treat the failure in the following way: apply an ASR (Attack Surface Reduction) rule with Windows Defender, where Microsoft Office applications are blocked so that they do not create secondary processes.
- AttackSurfaceReductionRules_Ids - 4f940ab-401b-4efc-aadc-ad5f3c50688a - AttackSurfaceReductionRules_Actions Warn | Enable Disable the MSDT url protocol by modifying the following registry key:
- Create backup copy; “reg export HKEY_CLASSES_ROOT\ms-msdt filename”
- Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”
As we have already seen in this article, all the attacks we know evolve over time. It is also possible that this news may have been received at the beginning of the year and may or may not have already updated its infrastructure. The most important thing is that, despite this, we never lose track of this type of issue, as there may be variants of this type of attack that can cause extensive damage to personal or organizational infrastructure.
Beyond that, one must never lose sight of the importance of training the organization's security teams so that they are adequately trained on a day-to-day basis to execute countermeasures and solutions. The best defense against Zero-Day will always be a team of people who are as resilient as possible to any unfortunate event.
"Even the best sword if left submerged in salt water will eventually rust." (The Art of War, Sun Tzu)