Abusing Windows Library Files for Persistence

Posted on 8 October 2018 by Jayden Zheng

Imagine that – unbeknownst to you – an attacker has dropped a malicious file on your computer that executes whenever you access your favourite folder on the Desktop – for example, the Documents folder. This exact scenario is possible by exploiting a little known persistence technique - Windows Library Files.


Windows introduced Library files to allow users to view the contents of multiple directories in a single view. A library can contain files and folders stored on the local computer or in a remote storage location [1].


The malicious usage of these files for persistence was first made public through the WikiLeaks Vault 7 release [2] and shares many similarities with Junction Folder abuse [3]. As both techniques are difficult to detect they make excellent choices for attackers and provide a challenge for even the best detection teams.


This blog post will provide a short analysis on how to use library files to maintain persistence and what to look for when hunting.

 

Introducing Library Files

By default, Windows library files are located in the ‘%APPDATA%\Microsoft\Windows\Libraries’ directory with the file extension of library-ms. These files are XML based and follow a publicly available schema.


As an example we’ll look at the Documents library file (‘Documents.library-ms’) which is used for the Documents folder. Examining this file, the most interesting part is the URL of the SimpleLocation element [4]. This element specifies the location for “search connectors” that are file-system based or protocol-handler based.


Our example shows the library pointing to two different known folders in the URL elements using global unique identifiers (GUIDs). Searching for the GUIDs [5]  pointed us to two documents directories:

 

{FDD39AD0-238F-46AF-ADB4-6C85480369C7} %USERPROFILE%\Documents
{ED4824AF-DCE4-45A8-81E2-FC7965083634} %PUBLIC%\Documents

 

 Library Files Screenshot of documents library pointing to two directories

As two locations were used, opening this library would allow the user to view the contents of two different directories in a single view. The screenshot below shows the contents of each separate folder: 

Library Files Screenshot of document folder directory

However, when viewing the library all items are shown within the same folder:

Library Files Screenshot of documents library2


Creating a malicious library file

So how can we abuse this feature for persistence?

 

The simplest technique is to add another URL element to load a malicious COM object, so when the folder is accessed or rendered, it will cause our COM object to execute.

 

In the following example we created a COM object that referenced a payload “beacon.dll”.

Library Files COM object that referenced payload beacon dll

An additional searchConnector was then added to the library, with a URL element referencing the CLSID we created.

Library Files search connector added to library

Finally, the library was saved to the Desktop so it looked like a benign folder “Documents”. If a user opened the folder, it would show the expected contents of the Documents folder. However, in the background the COM object would also be executed, starting our beacon payload from rundll32.exe with PID 5392.

Library Files library saved to desktop

Library Files library saved to desktop 2

Library Files rundll32 exe properties

Interestingly, rundll32 shows no parent process; this is because the parent process dllhost.exe (COM Surrogate process) exited after running the COM object. In Sysmon you will see an event similar to the example below, with a parent of dllhost.exe and a child process of rundll32.exe.

Library Files sysmon event properties window

Looking at Process Monitor, you will see dllhost.exe querying the CLSID we created, which then loads our beacon.dll, followed by rundll32.exe execution.

Library Files process monitor 1

Library Files process monitor 2

Library Files process monitor 3

Although these data points can be used for detection, you will likely see false positives from legitimate activity. Correlating data points though can give higher fidelity results. 


Implementing Persistence

Obviously for persistence we’d need our library-ms file to execute on start-up, so you might be wondering how can we achieve this?


Aside from the usual persistence techniques, a stealthier approach is to use Windows Explorer which will automatically execute the file when the directory containing the file is viewed. So users wouldn’t need to actually click the file, simply viewing a directory is sufficient. For example, we could place the library file on the Desktop and on boot up, Explorer will render it causing our COM object to execute.


From a detection perspective, the difference between on boot execution and user click execution is that when booted the parent process will be explorer.exe since it is explorer that caused the library file to be rendered.

Library Files IP screenshot

Library Files explorer exe

Library Files rundll exe properties 2

 
Hunting for library-ms files

We can use PowerShell to hunt for malicious library files by checking for any file with the extension of library-ms, then filter for the URL tag to get the CLSID and retrieve the related registry key for analysis.

Library hunting for library ms files using PowerShell

This scenario is only based on the abuse of the URL element; you might want to hunt for additional elements in order to spot further anomalies.

 

We have provided a script that performs the above conditions checks for any library-ms files that were created in the %USERPROFILE% folder, which you can use to check for any anomalies in any registry keys associated with this technique.

Library Files hunting for library ms files 3

You can get it here:
https://gist.github.com/countercept/6890be67e09ba3daed38fa7aa6298fdf

 

It can also be useful to look out for library-ms file creation, this can be a high fidelity indicator since these extensions are rarely created. Tools such as Sysmon allow you to easily monitor for these events, simply add the following to the Sysmon config file within the FileCreate tag.

Library Files file create tag in sysmon

 

When a library-ms file is created, you will see a file creation event like below:

Library Files file creation event


Conclusion

Windows has many “traditional” persistence techniques such as the Registry, Services, Scheduled Tasks etc. which many defensive teams focus on. As shown in this post though library-ms files present a unique challenge as they can hide in plain sight and execute code through COM references making detection and analysis a lot more challenging.


Blue teams should focus on the creation and modification of “.library-ms” files as well as COM entries. In addition to these suspicious process executions from explorer.exe or dllhost.exe can provide further evidence of malicious activity.


References

[1] https://docs.microsoft.com/en-us/windows/client-management/windows-libraries
[2] https://wikileaks.org/ciav7p1/cms/page_13763381.html
[3] https://www.countercept.com/our-thinking/hunting-for-junction-folder-persistence/
[4] https://docs.microsoft.com/en-us/windows/desktop/search/search-schema-sconn-simplelocation
[5] https://docs.microsoft.com/en-gb/windows/desktop/shell/knownfolderid