@dtmsecurity

Exploring search connectors and library files in Windows

DTM -

Introduction

This short post explores the file formats .searchConnector-ms and .library-ms. Both of these file formats have default file associations on most Windows versions. They integrate with Windows to show content from a arbitrary location which can also be a remote location by specifying a WebDAV share. As seen in the header image to this post these files can be creatively applied to blend in as legitimate folders.

Try these examples at https://github.com/dtmsecurity/examples:

Playing with these files

I started out by digging out documentation [1] for the search connector file format. When I specified a HTTP URL I noticed Windows making PROPFIND requests. So I then set out to set up a WebDAV server for testing. I found the TrustedSec blog [2] useful. However, I made a few tweaks which I think are down to me using a more recent version of wsgidav than when the article was written.

I settled for a YAML config of the following - allowing a read-only mount point:

provider_mapping:
"/":
root: "/tmp/webdav/share"
readonly: true
ssl_certificate: "/etc/letsencrypt/live/webdav.example.org/cert.pem"
ssl_certificate_chain: "/etc/letsencrypt/live/webdav.example.org/fullchain.pem"
ssl_private_key: "/etc/letsencrypt/live/webdav.example.org/privkey.pem"

I then ran wsgidav as follows (after sorting the certificate out with certbot):

wsgidav --host=0.0.0.0 --port=443 --config test.yaml --auth=anonymous

.searchConnector-ms

I then successfully made my *.searchConnector-ms file work - hurray! Clicking on my file (where the file extension is hidden even if the file extension is set to show in Windows it seems) gave my remote folder.

<?xml version="1.0" encoding="UTF-8"?>
<searchConnectorDescription xmlns="http://schemas.microsoft.com/windows/2009/searchConnector">
<description>Microsoft Outlook</description>
<isSearchOnlyItem>false</isSearchOnlyItem>
<includeInStartMenuScope>true</includeInStartMenuScope>
<templateInfo>
<folderType>{91475FE5-586B-4EBA-8D75-D17434B8CDF6}</folderType>
</templateInfo>
<simpleLocation>
<url>https://webdav.example.org/</url>
</simpleLocation>
</searchConnectorDescription>

The above output shows the XML format I put together for this copy and pasting largely from the Microsoft article. Another related file format is referenced *.osdx - However, when I tried to create one of these in Windows 10, I kept on getting an error 'Unsupported in this Windows version'. But the article eludes that (maybe for older versions of Windows) you can cause search connector files to be loaded via this other format.

.library-ms

When exploring the search connector format, it was clear that there is similarities with the *.library-ms. The default libraries in Windows are stored in:

C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Libraries

Check out the default libraries, as these denote your 'Documents','Pictures' etc. These can also be modified to point at remote locations and clicking on a *.library-ms file can give the similar results to above as shown below. Note: the warning about being an 'unsupported library location'.

<?xml version="1.0" encoding="UTF-8"?>
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
<name>@windows.storage.dll,-34582</name>
<version>6</version>
<isLibraryPinned>true</isLibraryPinned>
<iconReference>imageres.dll,-1003</iconReference>
<templateInfo>
<folderType>{7d49d726-3c21-4f05-99aa-fdc2c9474656}</folderType>
</templateInfo>
<searchConnectorDescriptionList>
<searchConnectorDescription>
<isDefaultSaveLocation>true</isDefaultSaveLocation>
<isSupported>false</isSupported>
<simpleLocation>
<url>\\webdav.example.org@SSL\DavWWWRoot</url>
</simpleLocation>
</searchConnectorDescription>
</searchConnectorDescriptionList>
</libraryDescription>

The above output shows an example XML file for a *.libary-ms file.

Why is this interesting?

As far as email phishing goes URLs and file attachments are subject to more stringent checks. You could include a WebDAV link directly in an email, or attach an *.lnk file or similar but these are much more widely known and obvious attack vectors.

I find these lesser known files interesting from a payload delivery perspective as you can see from the header picture they can be trivially made to look like local or internal file locations.  If you can get someone to click on one you at the very least have some record of the interaction (assuming WebDAV / Web Client is enabled). You can potentially tempt someone to click a payload held within the shared folder which then may now only checked by an inline proxy. This potentially side steps some of the whole end-to-end delivery suite of security products you typically face if they do not perceive these file formats as a threat.

On the flip side there is a potential option to modify existing *.libary-ms files post compromise in order to:

  • Show different content to a user i.e. persistence via a document lying around.
  • Trick users into saving data to a familiar location which is actually remote.

Mitigations

  • Disable the Web Client to prevent WebDAV being used to access remote locations.
  • Block or monitor WebDAV connections via enterprise proxy.
  • Apply a whitelist of allowed file types for email attachments and downloads.
  • Monitor the integrity of *.library-ms files.

[1] https://docs.microsoft.com/en-us/windows/win32/search/search-sconn-desc-schema-entry

[2]  https://www.trustedsec.com/blog/how-to-set-up-a-quick-simple-webdav-server-for-remote-file-sharing/