Photo by Deborah Austin
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.
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).
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.
SettingContent-ms file for the Windows Control Panel. Source: Matt Nelson / Specter Ops
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.
SettingContent-ms file modified to launch calc.exe. Source: Matt Nelson / Specter Ops
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.
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.
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
— Nextron Systems (@thor_scanner) June 30, 2018
VThttps://t.co/K3cWx7Lp7F
Sourcehttps://t.co/YAHRdScoGy
Sandbox Runhttps://t.co/QNbwHVz7Uw pic.twitter.com/zOHlH7DWtP
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.
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 approach some admins take with .js files).
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
— Martijn Grooten (@martijn_grooten) July 3, 2018
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
— Kyle Hanslovan (@KyleHanslovan) July 2, 2018
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).
— Kyle Hanslovan (@KyleHanslovan) July 6, 2018
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.
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.
Jonathan covers the latest threats and cybersecurity trends from a practical perspective.
Get the latest security news, tips, and trends straight to your inbox.
Get the latest security news, tips, and trends straight to your inbox.
ebookNew eBook:
5 companies, 5 attacks, and the reality of ransomware recovery.
close
Keep in Touch
© 2018 All Rights Reserved. Barkly is a registered trademark of Barkly Protects, Inc. | Privacy Policy and Terms of Service