Attackers Test New Document Attack Vector That Slips Past Office Defenses
After abusing Microsoft Office macros, Dynamic Data Exchange (DDE) and Object Linking and Embedding (OLE), attackers have found a new document feature they can leverage to execute malicious code on computers.
The new attack vector was first documented last month by Specter Ops researcher Matt Nelson and relies on embedding special settings files into Word documents. Technically this is also done through OLE, but the settings file format identified by Nelson is not on the blacklist Microsoft added to Office 2016 to prevent OLE abuse.
The abusable file format has the extension .SettingContent-ms and allows users to create shortcuts to various settings pages in Windows 20. The problem is that one of the format’s internal elements called <DeepLink> can point to and execute any binary files, including cmd.exe or PowerShell.
Since Nelson published his report in June, researchers have found various document samples in the wild that used the new technique, but they were likely tests because they lacked malicious payloads. That changed recently when a sample was found that invoked PowerShell to download and execute a remote access Trojan called REMCOS. This signals that attackers are ready to weaponize the technique and use it more widely.
“During the past few years, while there has been little development with web exploit kits, there has been a lot of activity with document exploit kits such as Microsoft Word Intruder (MWI) or Threadkit,” Malwarebytes researcher Jérôme Segura said in a blog post about the new attack vector. “These toolkits allow attackers to craft lures and embed the exploit(s) of their choice before either spear phishing their victims or sending the file via larger spam campaigns. At the same time, it looks like classic social engineering attacks aren’t going anywhere anytime soon and will keep capitalizing on the human element.”
The new attack technique is an important development because it bypasses common defenses added by Microsoft over the past few years. For one, even if a .SettingContent-ms file is downloaded directly from the web and is not embedded in a Microsoft Word document, Windows doesn’t display any of the execution warnings for it that are common for internet-downloaded files.
When embedded in Word documents as an OLE object, it bypasses the Office 2016 preset list of known bad file types. If clicked, users are asked if they want to open the package contents and then the file’s content including the <DeepLink> definition executes.
Since version 1709, Windows 10 has another defense that can be used against Office document exploitation. This consists of Attack Surface Reduction (ASR) rules that are enforced by the Windows Defender Exploit Guard. One of these rules can be used to prevent Microsoft Office applications from spawning child processes, a behavior that’s common for document exploits or malicious embedded scripts.
However, Office applications can call and open each other as part of normal operation, so to avoid breaking legitimate workflows, Microsoft exempted from this rule binaries that are located in the Microsoft Office installation path. Nelson found one exempted Office component called AppVLP.exe (Application Virtualization) that can take another application as execution parameter.
This means attackers can build an attack chain that bypasses ASR by using a .SettingContent-ms file embedded in a Word document to execute malicious shell commands through cmd.exe launched by AppVLP.exe.
Nelson said on Twitter a few days ago that Microsoft doesn’t have plans at this time to block this attack vector, which means that attacks using this technique will likely be around for some time to come.
According to Nelson, administrators can do a few things to detect and prevent such exploits. First, they can limit the execution of .SettingContent-ms files to the “C:WindowsImmersiveControlPanel” path. Second, they can use tools like Sysmon to monitor for any suspicious processes that get spawned by the Office applications. Completely killing the .SettingContent-ms file handler might also be an option, but this hasn’t been tested extensively and might have unexpected consequences.
