Analysis - .SettingContent-ms Exploit

This past summer the .SettingContent-ms Exploit was released by Matt Nelson,and attackers quickly began leveraging this technique to deliver payloads. This file type is just a simple XML file used by the OS for shortcuts.  They have been observed being embedded into office documents such as .doc and .pdf, as well as attached to emails as standalones(.settingcontent-ms).  Here is a quick walk through on handling these little pieces of malware:

This sample is a PDF with an embedded .SettingContent-ms file.


 Run peepdf to identify which objects have interesting content.


Lots of interesting stuff here. Streams are compressed byte sequences that must be inflated to view the content. Things like shellcode, embedded files, etc are stored in these stream objects. The /OpenAction tag indicates that object [12] will be executed when the document is opened. All other tags are obvious in their meanings! 

PDFs are comprised of PDF objects which each contain a PDF Dictionary, this is where the metadata is stored. The dictionary can be seen between the <<...>>.  The /OpenAction tag references a JavaScript function, as well as object 11, which we will pivot to. 



obj 11 points to both a JavaScript and EmbeddedFile.  Let's check out obj 10 (/EmbeddedFiles).




This obj references the file (downl.SettingContent-ms) at obj 2 (2 O R).



obj 2 references obj 1, which will be the embedded file stream '/Filespec /F (filename)'



And finally, the file stream.



Just a quick note about these streams, these are compressed and need to be inflated.  Without inflation (--filter), this is what the obj looks like.



This is pretty useful for malware authors because by default, their payload will be compressed, thus bypassing signature based detection.



Notice the first attempt at matching the 'powershell' string did not work in the compressed object, versus when decompressed (--filter). Here is the beautified version of the embedded SettingContent-ms file.



The way this exploit works, is that you can write in some code to invoke an executable along with a commandline string within the <DeepLink>...</DeepLink> tags. If this file is invoked, then the code within the <DeepLink> tags will run.

I cleaned up the payload a little, formatted it and changed the names of the variables. This is a simple downloader/launcher that will download an executable from the 169.xxx address using the .Download() method from the .NET 'WebClient' class, drop it into the temp folder, and execute it via the .Create() method from the WMI 'Win32_Process' class from the 'root\cimv2' namespace.



So now we have the payload, but how is it invoked? This file will not just run on it's own, time to check out the other stream objects!

If we go back to the peepdf output, there was another stream at obj 3 which looks to be what we want.



Here is a better look at the JavaScript. It first defines a function, and within that function, an object is defined (functionDataMass). The value '2' is assigned to the 'nLaunch' property which will save, then launch the .SettingContent-ms file. The JavaScript method used to drop and run this file is the exportDataObject(), the arguments being the 'nLaunch' value, and the name of the object to be exported.


Notice that the function defined here is the function that is called in the obj containing the '/OpenAction' tag, meaning that this is the code that will execute upon document open.

So ultimately, here is the sequence of execution for this attack:
PDF -> JavaScript -> .SettingContent-ms -> PowerShell -> Downloaded Executable

If Windows Defender if up to date, it will block this exploit.



However, unpatched machines are still vulnerable!



Thanks for reading and here is the sample if you wish to take a wack at it yourself (all tools used are native to REMnux).
Sample: https://app.any.run/tasks/ceda9915-b526-4c2a-81f8-26ab0cecc328

Comments