Abusing Windows Library Files for Persistence

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 [3]. 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 [4]  pointed us to two documents 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:

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

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”.

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

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.

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.

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.

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.

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.

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.

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.

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

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://docs.microsoft.com/en-us/windows/desktop/search/search-schema-sconn-simplelocation
[4] https://docs.microsoft.com/en-gb/windows/desktop/shell/knownfolderid