Recently, I have been working on adding support for automated enumeration and discovery of NTLM authentication endpoints to Chariot, our external attack surface and continuous automated red teaming product. Our red team requested this feature as a way to identify NTLM authentication endpoints exposed over HTTP that they could potentially leverage for password spraying attacks during the external attack phase of a red team engagement.

Even from an unauthenticated perspective, the NTLM protocol exposes a plethora of useful information about the target system within the NTLM CHALLENGE_MESSAGE that the server returns. To accomplish this data collection we have developed and released an open source tool named NTLMRecon which can be leveraged to perform this enumeration. The tool functions in a similar fashion to the NTLMRecon tool written in Python developed by Sachin Kamath (aka pwnfoo).

What information do NTLM endpoints expose?

An external attacker can, from an unauthenticated perspective, gain information about the computer name, domain name, and active directory forest name associated with the system exposing the NTLM authentication endpoint.

Why build a new tool for this?

Since a tool already exists, you may be wondering why we took the time to develop our own version. Primarily, we needed something we could easily integrate into the Chariot scanning pipeline. The following are some of the other considerations that factored into our choice to pursue this approach:

• Ease of Integration (Library Usage): We wanted to be able to import and use the tool as a Golang library instead of using an external Python interpreter. Including Python utilities in a scanning container also introduces additional complexity into our build system and requires us to occasionally pull in the latest version. We wanted to avoid the ongoing task of maintaining compatibility with an external tool written in another language.
• Low Development Cost: We had already developed a library in Golang for parsing NTLM messages as part of our research into NTLM relaying attacks targeting the ADFS service . As a result, the development cost for building an equivalent capability to the NTLMRecon utility in Golang was relatively low. It simply required making web requests and invoking the previously developed NTLM parsing library to extract the appropriate information, all of which only took a few days.
• Ease of Installation: Installing Python applications can often be inconvenient , because they don’t come bundled with the corresponding dependencies or libraries. Furthermore, if you install a variety of Python dependencies you can introduce conflicts between them. Sometimes those Python dependencies can then have other dependencies requiring the installation of additional packages or libraries, etc. This is not a problem with statically compiled Go binaries.

After considering these three factors,  we decided the best course of action was to develop a new capability. We decided to leverage the same approach we used with fingerprintx –developing a library alongside a command line utility. This allows us to both leverage the capability within the Chariot pipeline as well as release the capability as an external open source tool.

Why is this useful?

You may also be wondering why identifying these endpoints is useful to attackers. Multiple potential exploits can stem from endpoint discovery, including but not limited to the following:

• Password Spraying: An attacker can leverage discovered NTLM authentication endpoints to perform password spraying targeting Active Directory user accounts.
• Environmental Keying: An attacker could leverage environmental keying by using the discovered Active Directory domain, forest name, and computer name to implement environment keying within their dropper. This would enable them to ensure that the payload only runs on systems owned by the target organization. This is something our internal red team payload generator Janus supports. Janus leverages a domain specific language with a plugin-based architecture which provides operators with control over the behavior of droppers.
• Mass Account Lockout Attacks: Since NTLM authentication hits Active Directory directly an attacker could use exposed NTLM authentication endpoints to perform a mass lockout or DOS attack against an organization.
• Performing NTLM Relaying Attacks: An attacker could, for example, send UNC phishing emails to end-users with embedded UNC paths pointing to an external SMB share. They could then relay any authentication attempts obtained from end-users to an exposed NTLM endpoint (e.g. Exchange Web Services) to gain access to sensitive information such as employee email addresses.
• GitHub Reconnaissance: Once an attacker obtains the internal Active Directory domain and forest names they can leverage this as a keyword to perform GitHub reconnaissance to identify secrets. For example, a company contoso.com may have an internal Active Directory domain which may not be readily or easily guessable (e.g. corp.cntso.local). With knowledge of the internal domain and forest names the attacker can perform searches on GitHub public repositories and gists to potentially identify leaked secrets or credentials.

Modes

The initial implementation of the NTLMRecon utility is barebones and only designed to perform some simple brute-forcing to identify endpoints supporting NTLM authentication. The tool has two output modes with the first supporting JSON output with detailed metadata surrounding the data collection from the NTLM CHALLENGE_MESSAGE. The second mode, plaintext, simply outputs the paths discovered with NTLM authentication enabled. Figure 1 shows an example usage invoking the NTLMRecon utility in both JSON and plaintext modes.

Figure 1: An example JSON object with metadata collected from performing brute-forcing of NTLM authentication endpoints.

Example Using the FCC ADFS Portal

One common instance of exposed NTLM authentication endpoints occurs when organizations externally enable or expose certain application endpoints which support NTLM authentication. For example, an organization may expose the WS-Trust windows endpoints externally which support NTLM authentication. These endpoints are leveraged as part of Hybrid Azure AD device authentication; however, Microsoft documentation states that these endpoints should never be exposed externally. Figure 2 and Figure 3 include excerpts from Microsoft documentation describing that this endpoint shouldn’t be exposed externally and that the windows transport endpoints are for Hybrid Azure AD authentication.

Figure 2: Microsoft documentation recommends avoiding exposing WS-Trust Windows endpoints to the Internet as these are designed to be Intranet facing endpoints and could lead to bypassing of account lockout protections.

Figure 3: Microsoft documentation stating that the windows transport endpoints are used for Hybrid Azure AD authentication.

To find a more concrete example of this we performed some brief enumeration against externally facing ADFS servers within several public vulnerability disclosure and bug bounty programs. As an example, we found that the FCC’s ADFS server had a WS-Trust endpoint enabled, which allowed for obtaining information on the internal Active Directory domain name, forest name, and computer name. Figure 4 shows the metadata which we collected from the system during this process.

Figure 4: Leveraging a WS-Trust endpoint exposed on the FCC ADFS server to examine an NTLM CHALLENGE_MESSAGE to extract information on the internal Active Directory domain name, computer name, and forest name. 

Conclusion

We are continuing to build out the metadata collection and intelligent content discovery capabilities within Chariot. The addition of automated identification and collection of metadata exposed through NTLM authentication endpoints allows us to improve the level of detail we can provide to both our internal red team operators as well as customers leveraging the Chariot platform. Automated detailed metadata collection allows our red team operators and managed services engineers to spend their time where a human operator can provide the most value.

While we automate as much of the data collection and other repetitive tasks as possible within Chariot, we still leverage human operators to drive the most critical elements that are difficult to automate. These tasks include determining the risk and severity of automatically identified vulnerabilities and pivoting to manual testing after discovering a potential attack vector that automated testing cannot identify accurately. Our goal is to automate as much as possible while maximizing the value-added of our human operators to achieve things that a purely automated product offering couldn’t perform.