Microsoft changes course, blocks .SettingContent-ms files from being activated via OLE. But that doesn't completely eliminate the threat. Here's what you need to know.
What's happening? In early June, SpecterOps researcher Matt Nelson discovered .SettingContent-ms files could be abused to get around Microsoft's OLE blocking and Attack Surface Reduction (ASR) rules and execute malicious code on victim machines. Other researchers have been cranking out PoCs in the weeks following the disclosure, and the technique has also been seen in the wild.
What are .SettingContent-ms files? Simply XML files that allow users to create shortcuts to Windows 10 setting pages. Example: A user can create a shortcut to open the Control Panel.
How exactly are .SettingContent-ms files being abused? The files contain a <DeepLink> tag that takes any binary with parameters and executes it. This can lead to trouble because an attacker can create a .SettingContent-ms file with a DeepLink element that points to a binary such as cmd.exe or PowerShell.exe, which provides them with shell command execution.
How can these files be delivered? UPDATE: Up until July 9, the most likely path was by embedding them inside Microsoft Office documents via OLE and tricking users into double-clicking the icons. On July 9, however, Microsoft officially added .SettingContent-ms to its list of file extensions blocked in OLE packages. That thankfully takes that delivery option off the table, but attackers can still attempt to distribute them as email attachments or with links that download the files directly from malicious/compromised websites.
What to do now: Malicious use of this technique has been low as of yet, but that could easily change quickly. To get out in front of this threat it's a good idea to block .SettingContent-ms files at the firewall and/or email gateway level (when possible). In addition, you may also want to consider using Group Policy to force .SettingContent-ms files to open in Notepad (the same approach some admins take with .js files).
Barkly provides an important layer of protection against the abuse of .SettingContent-ms and other legitimate files.
Legitimate file type offers attackers code execution
Attackers are always on the lookout for legitimate programs or file types that can be abused to evade detection and bypass security. Luckily, researchers like Specter Ops' Matt Nelson are around to beat them to the punch. Earlier this year, he discovered a technique for using .SettingContent-ms files — simple XML documents used to create shortcuts to Windows 10 setting pages — to achieve shell command execution, meaning attackers could use the files to download malicious payloads or run malicious code.
Nelson reported the discovery to Microsoft in February, but after investigating the issue, Microsoft eventually responded that the issue was "below the bar for servicing" and closed the case on June 4. A week later, Nelson published a blog post detailing the method, which he explained he had stumbled across while attempting to find a workaround past Microsoft's Object Linking and Embedding (OLE) restrictions.
UPDATE: On July 9, Nelson announced Microsoft had changed course and added .SettingContent-ms files to its list of "dangerous" file formats it prevents from being activated via OLE (more on that below).
How it works
The key to abusing .SettingContent-ms files involves modifying the <DeepLink> element, responsible for specifying the Windows 10 settings binary that will open when a user clicks the shortcut. For example, this .SettingContent-ms file opens the Windows Control Panel.
Nelson discovered that he could simply replace "control.exe" with any other binary, including ones like cmd.exe and PowerShell.exe that provide shell command execution. That allows attackers to run malicious commands, including downloading and executing malicious payloads. All they have to do is trick a user into opening the .SettingContent-ms file.
In addition to (initially) allowing attackers to bypass Microsoft's OLE restrictions, Nelson discovered the DeepLink element of SettingContent-ms files could also enable them to circumvent one of Microsoft's key Attack Surface Reduction (ASR) rules — blocking Office applications from creating child processes. That rule was expressly designed to prevent attackers from abusing Office features like macros and OLE to launch programs like cmd.exe and PowerShell.exe. But Nelson found a way of creating a chain that could bypass the rule. By simply modifying a .SettingContent-ms file's DeepLink to start with AppVLP.exe — a Windows program allowed to start child processes — Windows could be tricked into allowing the commands to be executed.
3 2 primary delivery methods to worry about
As mentioned above, Microsoft added .SettingContent-ms files to its OLE blocked list on July 9, thankfully rendering any attacks attempting to hide those files in Office documents ineffective. That doesn't completely eliminate this threat, however. Organizations still need to be mindful of two additional delivery options attackers still have at their disposal:
Note: As of July 9, this delivery method is no longer viable thanks to Microsoft's decision to block this file type from OLE activation.
Using Microsoft Office documents as decoys has long been a popular attack strategy, and Nelson's write up primarily covers this approach. That makes sense considering that finding a workaround past Microsoft's OLE restrictions designed to prevent malicious Office document abuse was what led Nelson to come across .SettingContent-ms files in the first place.
From an attacker's perspective, embedding the .SettingContent-ms file inside a Word document, for example, has obvious advantages. It allows them to package the attack in a familiar format employees are used to, and frame it in context that takes them off their guard. Ex: Embedding the .SettingContent-ms in a Word document titled "Invoice" and disguising it with an Excel icon with instructions for opening it.
Prior to Microsoft rendering this delivery method ineffective, Barkly blocked these attempts.
Unlike other Office attacks, the only "warning" users are presented with upon clicking the embedded object is a simple prompt asking them to confirm they want to open the file.
Defending against this method: Microsoft has rendered this method ineffective.
2) Disguising .SettingContent-ms files as legitimate email attachments
Another delivery option is for attackers to attach these files directly to emails, and there is already evidence that they are taking advantage of the fact that Windows does not display file extensions in order to disguise these attachments more effectively.
Case in point: The file below was disguised with the name "Umfrage DSGVO.pdf (many spaces).settingcontent-ms" to make it appear as though it was a PDF (because the .settingcontent-ms extension is hidden, the user just sees "Umfrage DSGVO.pdf").
File named "Umfrage DSGVO.pdf (many spaces) .settingcontent-ms" (German: Questionnaire GDPR) is a downloader using #DeepLink method as described by @enigma0x3@ItsReallyNick
Defending against this method: If feasible, organizations should block .SettingContent-ms files at the email gateway. In addition, admins should consider adjusting Windows settings to show file extensions by default and educating users not to open files with the .settingcontent-ms extension.
3) Linking to .SettingContent-ms files in emails
In his blog post, Nelson also demonstrated how these files can be distributed via links to malicious/compromised websites and downloaded directly from the Internet.
As Nelson notes, despite the file coming from the Internet it executes without any notification or warning to the user.
Defending against this method:If feasible, organizations should adjust firewall settings to block .SettingContent-ms file downloads. In addition, admins can consider adjusting Windows settings to force .SettingContent-ms files to always open in NotePad (the same approachsome admins take with .js files).
Weaponization of .SettingContent-ms Files Timeline
February 16, 2018: Researcher Matt Nelson reports discovery to Microsoft
June 4, 2018: Microsoft says issue is below the bar for servicing
July 2, 2018: .SettingContent-ms file spotted using PowerShell to download and launch Remcos RAT
July 3, 2018: .SettingContent-ms file spotted embedded in Word doc saved as a MHT file, used to deploy Loki Bot.
July 9, 2018: Microsoft adds .SettingContent-ms files to list of files it prevents from being activated via OLE in Office 2016 documents.
Protecting your company from features, not just bugs
Few things better exemplify the cat-and-mouse nature of security than attackers' ongoing attempts to abuse legitimate Windows features and Microsoft's corresponding efforts to prevent that abuse. This threat represents the latest chapter in that continuing saga, and if there's a larger takeaway it might be this:
.SettingContent-ms files remind us that it is features, not bugs we should be most concerned about (blog post, by me) https://t.co/unJ24j7ZZa
Researchers and attackers alike are drawn to sussing out features they can potential abuse for a reason — unlike bugs, which can be patched, vendors often don't feel compelled to disable or restrict features until abuse reaches a widespread level with attackers actively exploiting them in the wild. This time around, organizations are relatively lucky — Microsoft's response to .SettingContent-ms files has been like lightning compared to the way they've handled similar issues in the past (see DDE abuse, which ramped up for months before Microsoft finally removed the functionality from Word).
Meanwhile, the speed at which attackers are able to incorporate new feature-abusing tactics into their campaigns continues to increase, meaning any window of time between a new tactic being publicly disclosed and a vendor mitigating the issue puts organizations at risk, particularly those small and medium-sized companies with few or no dedicated security personnel equipped to proactively handle the threat.
This concern prompted researcher and Huntress Labs CEO Kyle Hanslovan to start a fascinating, if contentious, debate about the ways in which tradecraft like the SettingContent-ms file abuse is disclosed, and what (if any) responsibility researchers have in limiting the amount of risk associated with publishing their discoveries.
Tradecraft PoCs that abuse features like Squiblydoo, SettingContent-ms, & the LOLBin de jour puts the masses at more risk than attackers privately abusing them. #UnpopularOpinion
Absolutely still feel that certain tradecraft should follow a process that I'm calling "Private Disclosure" (report the bug to private, trusted parties. only publicly disclose the tradecraft when it's found being abused in the wild).
Whether such an approach gains support, only time will tell. In the meantime, organizations should make sure they're actively monitoring and keeping up with legitimate feature abuse to the same degree they're focusing on staying up to speed on patch management.
How Barkly can help
Barkly helps small and medium-sized organizations stay ahead of these threats by providing protection that goes beyond blocking malicious executables and blocks a wider variety of malicious system activity and behavior patterns, too. That's allowed Barkly to protect its customers from a broad range of legitimate feature abuse, including blocking attempts to misuse macros, OLE, DDE, and embedded .SettingContent-ms files before Microsoft put additional restrictions in place.
Vendors don't always move quickly to resolve legitimate feature abuse. Barkly helps ensure organizations stay protected so there's no window when they're exposed. Learn more about how Barkly can keep your company safe. See a demo of its protection in action.