Splunk is committed to using inclusive and unbiased language. This blog post might contain terminology that we no longer use. For more information on our updated terminology and our stance on biased language, please visit our blog post. We appreciate your understanding as we work towards making our community more inclusive for everyone.
If you want just to see how to find detections for the Follina MS Office RCE, skip down to the “detections” sections. Otherwise, read on for a quick breakdown of what happened, how to detect it, and MITRE ATT&CK mappings.
On May 28th, 2022, the nao_sec Japanese cybersecurity research team tweeted about an unusual Microsoft Word document that appeared on VirusTotal. The researchers determined that this document was malicious and used two techniques to gain remote code execution (RCE) on the victim’s computer. The document was also able to bypass most detection methods at the time, including Microsoft Defender. The RCE was christened Follina by Kevin Beaumont due to a reference of 0438 within the sample, and 0438 being the area code of Follina in Italy. In this blog, we will provide a brief overview of this RCE exploit along with some Splunk searches to help you defend against this type of behavior in your environment.
There are multiple great write-ups on Follina that break down the technical details. We don’t want to rewrite the great work already out there, so here is a list in the order that they were released:
If you haven’t read the links above (which you really should), here is a brief overview of how Follina works.
As mentioned earlier, two techniques are used to gain remote code execution. The first technique uses an embedded HTML link within the original document. When opened (or just previewed if the document is saved in rich text format), Word retrieves the content from that link, which in this case is HTML payload containing script tags. The malicious HTML payload then uses the Microsoft Support Diagnostic Tool (MSDT) protocol schema - `ms-msdt`, which allows arbitrary execution of commands including calc.exe or PowerShell scripts that disable protection tools, download a backdoor, and then open you up to things like data exfiltration, ransomware, etc.
Fig. 1. RCE à La Follina Recipe
This may not sound novel, but so far we have not seen an example of MSDT being used as a launching pad for other processes. The closest we could find is a post by SySS GmbH titled “Abusing the MS Office protocol scheme.” This is a good read that calls out other methods of abusing similar MS protocols. While MS-MSDT is found in their blog, it isn’t specifically mentioned as an abuse vector.
This type of activity usually lives in the wonderful land of macros. But defenders are getting quite good at detecting and blocking macros, so adversaries have to find new ways to infiltrate networks. Legitimate programs called LOLBins, or living off the land binaries, are one powerful technique to bypass traditional defenses and hide malicious activity since these programs are typically needed for systems to function properly, and limiting their use can be difficult.
Should Word or other Office programs use msdt.exe? Should msdt.exe attempt to run PowerShell or other programs? I had no clue going into this, and I bet that most defenders out there are in the same boat.
First, these sorts of situations present a great learning opportunity. When a new behavior like this surfaces, it’s always a good idea to dig in a bit deeper to understand how it works. Basic searches for MSDT turn up the usual page-turners, aka Microsoft Documentation. The MSDT documentation page highlights the power of this particular tool. It has a number of capabilities that make it a perfect vector for this sort of attack.
Also, should Word, or other MS Office programs launch MSDT? Off the top of my head I can’t think of any particular reason, so maybe we should prevent it. John Hammond calls out a capability within Microsoft Defender called Attack Surface Reduction (ASR). A rule exists that will not only block MS Office programs from launching MSDT, but any other child processes. This may or may not work for your environment depending on how your business uses these applications, so tread carefully before turning this on en masse.
This leads to one of the most important learning exercises I can think of. You MUST start by understanding your own environment inside and out. This is not easy by any stretch of the imagination, but once you start putting this jigsaw puzzle together, you will be a much better defender. With this knowledge, you can start crafting detection and hunting techniques that are more behavior-driven, and less dependent on static values that can change at the drop of a hat.
Since we know the techniques used in this particular scenario, we are able to replicate the activity and then hunt for the behaviors within Splunk. Treat this hunting search as Splunkspiration, as you may need to adjust it to better reflect your environment.
If you ingest Microsoft Sysmon data (in our opinion you should be), this search can detect when MSDT is launched with the relevant command-line options used in this scenario. We have adopted and translated this Sigma rule created by the team at Huntress to create this search.
index=main source="xmlwineventlog:microsoft-windows-sysmon/operational" process_name=msdt.exe | where (like(CommandLine, "%PCWDiagnostic%") AND (like(CommandLine, "%ms-msdt:/id%") OR like(CommandLine, "%ms-msdt:-id%"))) OR (like(CommandLine, "%invoke%")) | table host CommandLine parent_process_name parent_process_id process_name process_id
Fig. 2. Search results for msdt.exe launching via the command line.
This search functions as follows:
1. It searches in the main index using Microsoft Sysmon data as a source.
2. It only looks for the msdt.exe process name.
Then, it looks for one of two CommandLine executions.
3. In the first where condition, the search looks for CommandLine execution containing the string PCWDiagnostic along with ms-msdt:/id OR ms-msdt:-id strings.
or
4. In the last OR condition, it looks for any invoke strings that msdt.exe makes.
A combination of 1 + 2 and then 3 or 4 will trigger a match.
If we wanted to explore a bit further, we could pivot on the parent process ID in that time period to determine if that process communicated with any remote sites.
index=main source="xmlwineventlog:microsoft-windows-sysmon/operational" process_id=10864 EventCode=3
| table src_ip src_port dest_ip dest_port
Fig. 3. Search results after pivoting on the parent process ID
This search functions as follows:
1. It searches in the main index using Microsoft Sysmon data as a source.
2. It uses the parent process ID from the previous search, but now as the process ID itself.
3. It searches for EventCode=3, which is the event code for Network Connections.
4. It then creates a table showing the source IP, source port, destination IP, and destination port.
The search results show us that winword.exe communicated with 143[.]244[.]214[.]139 on port 80 (HTTP).
This data would be very useful if we wanted to continue hunting in our environment to see if other hosts communicated with that destination.
For folks using ESCU, the Splunk Threat Research Team (STRT) released a new Splunk Analytic Story containing detections for this threat.
Our team of Security Professionals, who are part of our Splunk Professional Services team, can help you implement what we’ve mentioned here. We also have more targeted offerings that can help you increase your security posture as well.
This section is all about Splunk helping you prepare for and respond to a breach using our suite of products. Let our experts help you with:
After reviewing relevant blog posts from just about the whole internet, we mapped the vulnerability activity to MITRE ATT&CK. As more information becomes available, we will update this table with searches if more ATT&CK tactics, techniques, and procedures (TTPs) become known. Please note these are just searches that map to the TTP not necessarily perfect detections.
This information along with the searches and ideas above should get you started to hunt for this behavior in your environment. You should also invest time to understand your risks, exposure, capabilities, and weaknesses and then plug any gaps you find. But remember, security is like a donkey, it has many layers and there are no silver bullets.
Happy Hunting!
The Splunk platform removes the barriers between data and action, empowering observability, IT and security teams to ensure their organizations are secure, resilient and innovative.
Founded in 2003, Splunk is a global company — with over 7,500 employees, Splunkers have received over 1,020 patents to date and availability in 21 regions around the world — and offers an open, extensible data platform that supports shared data across any environment so that all teams in an organization can get end-to-end visibility, with context, for every interaction and business process. Build a strong data foundation with Splunk.