Detecting Follina (CVE-2022-30190): Microsoft Office Zero-Day Exploit

Microsoft Office apps

Follina (CVE-2022-30190) is a Microsoft Office zero-day vulnerability that has recently been discovered. It’s a high-severity vulnerability that hackers can leverage for remote code execution (RCE) attacks. To help you prevent a damaging breach, LogRhythm Labs provides insight into the vulnerability and tips for defending against Follina.

In this blog, you will learn how to detect the Follina (CVE-2022-30190) zero-day exploit using indicators of compromise (IOCs) and AI Engine (AIE) trend rules to highlight anomalous activity. I’ll also guide you through performing a threat hunt using LogRhythm Case Management and Playbooks. This blog is broken out into the following four topics:

  1. A summary of Follina (CVE-2022-30190) and relevant references.
  2. How to detect a zero-day exploit such as Follina.
  3. A threat hunt example that focuses on Follina IOCs. Then we’ll explore creating an AI Engine rule for the MITRE ATT&CK “T1137: Office Application Startup” technique.
  4. Using trend rules to spot anomalous activity such as a zero-day attack.

Although this blog focuses on LogRhythm technology, the guidance should be applicable outside of LogRhythm, too.

Summary of Follina (CVE-2022-30190) vulnerability and references

On May 27, 2022, security researcher Kevin Beaumont blogged about “Nao_sec” identifying a malicious Microsoft Word document that exploited a known, but rarely used feature of Microsoft Office to perform malicious activity on a Windows-based system. The crux of the vulnerability is that the attacker leverages a rarely used component in Windows, named the Microsoft Support Diagnostic Tool (MSDT), and uses a specially crafted Word or RTF file to trigger MSDT to download and execute malicious code.

Most recently, Follina is still actively being leveraged by “XFiles info-stealing malware,” as noted by BleepingComputer.

According to Microsoft Security Response Center (MSRC), Microsoft released updates on June 14, 2022, to address the vulnerability. This update should be applied as soon as possible in your organization. More information from MSRC can be found here.

Sophos released a blog on June 15th titled, “Follina gets fixed – but it’s not listed in the Patch Tuesday patches!” Sophos notes that CVE-2022-30190 isn’t officially listed in June’s security updates from Microsoft, however KB5014697 or KB5014699 seems to have fixed the trivial exploit. You can read more about their findings from Sophos here.

Detecting the Follina zero-day vulnerability

LogRhythm has a lot of great blogs and papers on what a zero-day is, and how to detect them. As an additional resource, you can read this article, “A Guide to Detecting Microsoft Exchange Zero-Day Exploits,” for more general information.

When observing how the Follina attack works, MSDT is scarcely invoked, and detection of this rare condition is trivial when monitoring processes on a Windows system and using LogRhythm’s AI Engine. Detecting uncommon or rarely executed processes with AIE trend rules typically leads to suspicious activity that deserves further investigation.

To illustrate how LogRhythm would detect Follina as suspicious, we’ll focus on the detailed security analysis of the malicious Word document written by Paul Ducklin with Sophos here.

Suspicious parent and child process

In the Sophos example, the malicious DOC file when opened will spawn the MSDT process. What this would look like in Microsoft Security Audit, Event ID 4688 is:

ParentProcessName> C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE and NewProcessName> C:\\Windows\\System32\msdt.exe

This observation would also look similar to Microsoft Sysmon Event ID 1 and the following:

ParentImage> C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE and Image’> C:\Windows\System32\msdt.exe

Creating an AIE rule to detect this parent and child relationship is fairly straightforward. In this example, I have created an AIE Log rule with the parameters:

  • Common Event is “Process/Service Started”
  • and Parent Process Name is” (also selecting the Regular Expression checkbox)
  • and Process Name is “%msdt\.exe” (also selecting the Regular Expression checkbox)
LogRhythm log observed
Figure 1: Log observed.

Note: Following LogRhythm best practices, you should further filter this rule to applicable log sources for AIE performance considerations.

In the above example, I’m leveraging LogRhythm’s Common Event where the log message is considered a “Process/Service Started” which includes Microsoft Security Audit 4688 and Microsoft Sysmon event ID 1, among a great number of other similar log sources. With AIE, you can specify RegEx patterns to help capture the criteria of the rule regardless of where Microsoft Office is installed and whether parsing includes the full path, making this rule very versatile and still maintaining high-efficacy detection logic.

This AIE rule is helpful going forward, but what if you need to assess if you have ever observed this behavior prior to creating the AIE rule? Next, I will demonstrate how to perform a threat hunt using LogRhythm’s Case Management and WebUI.

Threat Hunting with LogRhythm Case Management and WebUI

In a previous article, I covered how to perform a threat hunt using Case Management, so I won’t dive into the details of each component in this blog. For an in-depth overview of the threat hunting process using LogRhythm, read though that post for more tips.

Creating a zero-day Follina threat hunting Case and adding the Playbook

To get started with your zero-day Follina threat hunt, you can watch my YouTube tutorial, or continue reading the written instructions below.

Step-by-step instructions

In the LogRhythm WebUI, and under the “Cases” tab is where you can start creating a case to start the threat hunt.

Creating a case in LogRhythm WebUI.
Figure 2: Creating a case in LogRhythm WebUI.

In the Cases dashboard, click on the new case icon to create the threat hunting case.

Click icon to create a new case.
Figure 3: Click icon to create a new case.

Next, name the case with something descriptive as to what the case is about. In this example, I am prefixing the name “Blog” and the title of this blog as the case name for easy reference.

Naming the case
Figure 4: Naming the case.

Next, add a summary to the case before clicking the “Save” button.

Adding a descriptive summary to the case.
Figure 5: Add a descriptive summary to the case before saving.

After creating the case, add an appropriate Playbook to follow for the next steps. In selecting the type of Playbook, I’ll leverage one that we have made to help us identify possible MITRE ATT&CK rules we can create. I will select our “Threat Hunt with MITRE ATT&CK hypothesis” Playbook.

Add appropriate playbook to the case.
Figure 6: Add appropriate playbook to the case.

Playbook Procedures: Leading to MITRE ATT&CK T1137: Office Application Startup

The first procedure in the playbook has me form a hypothesis. In doing so, this led me to select MITRE ATT&CK T1137: Office Application Startup. In the “Detection” table and “Process Creation” data component, MITRE ATT&CK says to:

“Monitor newly executed processes that may leverage Microsoft Office-based applications for persistence between startups. Collect process execution information including process IDs (PID) and parent process IDs (PPID) and look for abnormal chains of activity resulting from Office processes. Non-standard process execution trees may also indicate suspicious or malicious behavior. If winword.exe is the parent process for suspicious processes and activity relating to other adversarial techniques, then it could indicate that the application was used maliciously.”

First playbook procedure: Form hypothesis.
Figure 7: First playbook procedure: Form hypothesis.

The rest of the procedures goes through the process of collecting logs and staging the creation of AIE detection rules. Next, I’ll cover the new detection rule based on known parent and child process relationship and will also cover how trend rules can spot anomalous parent and child process relationships so that you are able to catch zero-days quickly.

AI Engine Detections

AIE: LRLABS_CVE-2022-30190:Follina

I created this AIE rule based on IOCs where the Parent Process “winword.exe” is observed starting the Process “msdt.exe”.

AIE rule logic for AIE rule named "LRLABS_CVE-2022-30190.
Figure 8: AIE rule logic for AIE rule named “LRLABS_CVE-2022-30190.

The AIE rule is leveraging LogRhythm’s Common Event named “Process/Service Started.” This will include Microsoft Security event ID 4688 and Microsoft Sysmon event ID 1 among others. When the parent and child process is observed, the rule will event and alerts the analyst to a potential compromise risk.

AIE Event: LRLABS_CVE-2022-30190:Follina

I tested the AIE rule using LogRhythm ECHO. As shown in figures 9 and 10, the AIE event contains information that will aid an analyst in determining if further investigation is required.

User Origin: "System."
Figure 9: User Origin: “System.”


Parent Process Name:winword.exe and Process Name:msdt.exe.
Figure 10: Parent Process Name:winword.exe and Process Name:msdt.exe.

Next, I will demonstrate how trend rules can be used to detect this activity without prior knowledge of CVE-2022-30190.

Anomalous Trend Rules: “Rare Child Process”

Currently, I have four anomalous test rules that detected the Parent Process Name “winword.exe” along with the Process Name “msdt.exe”. I will focus on one of these anomalous rules named “Rare Child Process.” In the below picture, the AIE event displays the anomalous (hasn’t been seen before by the SIEM in the past 30 days) parent/child process.

AIE anomalous
Figure 11: AIE anomalous event named “test_rare child process” observed Parent Process Name “winword.exe” creating Process Name “msdt.exe”.

Next, I will perform an AIE Drill Down to display the raw logs that triggered the AIE event.

Perform an AIE Drill Down by clicking on "AIE Drill Down".
Figure 12: Perform an AIE Drill Down by clicking on “AIE Drill Down.”

The trend rule will display all logs relevant to the AIE rule within a given time window. In this case, the trend rule performs an evaluation every eight hours, and I ran the test three different times within that period, thus a total of six logs are shown below in the dashboard.

AIE Drill Down displays a total of six logs found during the trend rule eight-hour evaluation period.
Figure 13: AIE Drill Down displays a total of six logs found during the trend rule eight-hour evaluation period.


Analyzer grid view of the logs retrieved by the AIE Drill Down.
Figure 14: Analyzer grid view of the logs retrieved by the AIE Drill Down.

AIE Rule: Anomalous “test” rule: test_rare child process

The AIE trend rule summary is in the screenshot below. The first thing worth pointing out is the “Time and Schedule” setting. Here, I am evaluating one day against the baseline of 30 days for any new Parent Process Name and Process Name.

Time and Schedule setting.
Figure 15: Time and Schedule setting.

In the Expressions screen shot below, the expression is shown where one or more live logs must be observed and is new and not currently present in the baseline. The rule logic states that both rule one and rule two must be true.

Expression and expression logic.
Figure 16: Expression and expression logic.

When creating or editing the expression, this is what it looks like. Here, the expression type is “Count: Log Count Threshold.”

Expression: Count: Log Count Threshold.
Figure 17: Expression: Count: Log Count Threshold.

In the Expression Logic section, you can see in the description that a lot of different logical operations can be set. In this example, both 1 and 2 must be true.

Expression Logic description and how this example is set where 1 and 2 must be true.
Figure 18: Expression Logic description and how this example is set where 1 and 2 must be true.

In the Time and Schedule setting, the example rule is set to a Live Time of 1 day.

Live Time is set to 1 day.
Figure 19: Live Time is set to 1 day.

The Baseline Time is set to 30 days.

Baseline Time set to 30 days.
Figure 20: Baseline Time set to 30 days.

The Evaluation Frequency is set to “Auto” in the screenshot below. What auto does it automatically set the time to evaluate 1/3 of the Live Time.

Note: In using the auto setting, the live time must be divisible by 3.

Evaluation Frequency set to "Auto.”
Figure 21: Evaluation Frequency set to “Auto.”

The Evaluation Frequency is automatically calculated at 8 hours in the screenshot below.

Evaluation Frequency automatically set to 8 hours.
Figure 22: Evaluation Frequency automatically set to 8 hours.

Creating trend rules like this are helpful to highlight something of interest that is “new” in your SIEM. This new activity in this case spotted the “Follina” attack. This rule, along with you performing a threat hunt, will help spot future zero-day attacks in your environment.

More threat hunting tips from LogRhythm Labs

Discover additional blogs and resources to guide you through threat hunting best practices from LogRhythm Labs.