NetBIOS / NBNS Spoofing For The Easy Win

Nowadays, modern operating systems use DNS as their preferred method for resolving names – especially within a domain environment. An overview of the methods in which Windows machines resolve names of other machines on the network is as follows

1. Windows first looks in its local hosts file at c:\windows\system32\drivers\etc\
2. It will then check its own DNS cache to see it has been recently resolved.
3. If this fails, it will send a request over to its configured DNS server(s).
4. If the DNS server cannot resolve it (and assuming the name is in the non-standard DNS format) the client will send the request to its configured WINS server (if specified).
5. If at this point the client has still not received a reply, it will send out a series of NetBIOS broadcasts.
6. Finally, if all else fails, it will look inside its LMHOSTS file at  c:\windows\system32\drivers\etc\

Looking through that list, you can see that our attack doesn’t come into play until the 5^th stage; and you may well be thinking that all the planets need to be aligned in order for this to work, but you’ll be surprised how on a busy network, just how many hashes you can capture using this method. There are plenty of situations that can be present on the network that will cause a client PC to skip those first 4 steps, for instance:

1. Clients that are running login scripts to map drives via the net use method.
2. Laptops brought into the environment from other domains will be “polling” for their printers and other resources that won’t exist on the network will also send out broadcast requests.
3. Mistyped URL’s such as googlecom will be rejected by the DNS server and as such, will need to be resolved via NetBIOS
4. Modern browsers allow you to search via the address bar, and the browser needs to decide if the text is a host or a query. If the string has spaces, it is obviously a search request. If there are no spaces the browser doesn't know if we want a server named "youtube" or we want to search for youtube.

So, as you can see, we have plenty of cards up our sleeves :0)

NetBIOS uses a series of broadcasts and luckily for us, it provides very little verification as to who is sending back the replies, so anyone can falsely reply to say they are filesever01 for instance. The client will blindly trust this response, try to negotiate a NULL session and, if anonymous connections are disallowed, use the current user’s logon session in hashed format (NETNTLMv1 or NETNTLMv2) to authenticate to the filesever01 over SMB. Soon enough you, as an attacker, will have a nice list of users/hashes that you can feed into John the Ripper or Cain for cracking.

First, we need to set up a couple of Metasploit auxiliary modules to capture these hashes - the SMB and HTTP_NTLM modules.

 Figure 1 - auxiliary/server/capture/smb

Figure 2 - auxiliary/server/capture/http_ntlm

Set the SRVHOST to your own IP address and make sure the other settings are configured like the ones above.

Once these are up and running, we need to setup one more module to send out spoofed responses to our targets.

 Figure 3 - auxiliary/spoof/nbns_response

It’s a good idea to create a Metasploit resource file to automate all this to make life easier. Just create a text file and start adding in the commands on-by-one as you would type them in the Metasploit console:

Once complete, type into the console: resource /root/nbnsspoof.txt to get it started.

Depending upon the target operating 
systems, you should see a couple of different types of hashes being captured now – NTLMv1 (XP, Server 2003, Windows 2000) and NTLMv2 (Vista, Windows7).

Ideally, we would like to be seeing NTLMv1 hashes appearing now as they can be cracked much easier with rainbow tables. Now we can sit back and wait. 

 Figure 4 - Hashes from XP clients

Figure 5 - Hashes from Windows 7 clients

Above, you can see we have managed to capture some hashes from both XP and Windows 7 clients, so now we need to start cracking them.

Cracking NTLMv1 Hashes –

 

NTLMv1 hashes are produced as follows:

1.     The server issues an 8 byte challenge to the client

2.     The client uses the challenge to encrypt it’s LM or NTLM hash

3.     The client passes this back to the server, where-by the reverse is performed to read the hash. 

  

 It’s in step 1 where a lot of this technique comes into play; you will notice in figures 44 and 45 that we can set a static challenge of 1122334455667788. Providing we always specify the same challenge, then that in effect removes the “salt”, which makes cracking these a lot easier as now, we can use pre-computed rainbow tables.

Both John the Ripper and Cain can be used to crack these hashes, NTLMv1 hashes contain the weaker LANMAN hash, so providing you have a good set of wordlists and tables, you should be able to crack these relatively easily.

To use John against these, you need to manually choose the format and make sure you are pointing it at the correct file - it should start with /tmp/john_netntlm

You can now choose to crack the NThashes – this can be quicker for derivatives of the word “password” or other weaker passwords longer than 7 characters.

Or, you can crack half of the LM hash (first 7 letters) by choosing nethalflm format. This is best for short passwords or for those that you cannot get easily with the netntlm method.

As you can see, we only have the first 7 characters of the passwords, but you will find a handy perl script within the john directory called netntlm.pl.

This script will take the first 7 letters and brute force the remainder of the password for you. The syntax is as follows –

perl netntlm.pl --seed="LONDON2" –-file=/tmp/john_netntlm

Unfortunately, this script can only run against a single seed at a time so you won’t get any bulk cracking done here, but as you can now see below, we have the uppercase version of Jane’s password.

We now need to get the case of the password, and this can be done simply by running the same command again.

Another way to do all this is to use Cain. You will need to download the HalfLM tables first - which are available here: http://www.freerainbowtables.com/en/tables/

You will then need to copy and paste the hashes from the cain output file into a text file and import them into Cain:

 Figure 6 - Importing hashes into Cain

Then choose the HALFLM + challenge method and load in your HalfLM tables to begin cracking.

 And now we are ready to start:

As you can see from above, Cain has started to crack many more of the passwords than john did. All we need to do now is to get the second half of the password.

For this, we need to use the Brute-force method within Cain – as follows:

Within seconds usually, we will now have just about all of the passwords cracked

Cracking NTLMv2 Hashes –

NTLMv2 hashes are sent by default on Vista or later operating systems, and are produced a little different from the NTLMv1 types, in that, the challenge is performed from both parties involved, and more factors are included to make up the salt – such as the username and the domain name. Basically, this means that we can no longer use rainbow tables. No matter though, as long as people choose weak passwords then we can easily get them.

John can be used against these by specifying the format=netntlmv2 argument:

And Cain can also be used here, but a little more work is involved because the Metasploit capture modules do not output these in Cain format for some reason.

You need to copy and paste the john format of the hash into Cain’s hash file located at C:\Program Files (x86)\Cain\NTLMv2.lst and re-arrange the format into the following:

Username<tab>domain<tab><tab>hash<tab>serverchallenge<tab>clientchallenge<tab><tab>

The easiest way of remembering this is to have Cain open (must be closed before saving) and use a tab where you see a column within the gui interface:

 

So, for those of you who have not yet tried this, I am willing to bet that it will become an essential part of your testing; as you may well find, it can really give you that jump-start into the network.
In fact it's so successful, it almost seems unfair, especially if you couple this along with the technique described here http://www.anotherwayin.net/2011/11/using-ettercap-to-improve-netbios.html?utm_source=BP_recent
you wont come across many networks that aren't susceptible to this.

** 2013 update**

Things have moved on a little since I posted this, and a couple of new tools now exist to make this attack even more successful . Firstly, newer OS's have IPv6 turned on by default, and this changes the order that windows uses to resolve names slightly. Whereas IPv4 only clients - such as XP etc. use DNS first then NBNS; IPv6 clients will use DNS, then Local Link Multicast Name Resolution (LLMNR), then NBNS.
Metasploit now has a module for this called llmnr_response, so I recommend you include this within your resource file to increase your success rate when running these attacks on modern networks.

In addition to this, a tool was released last year called Responder that includes all these attacks, plus  WPAD poisoning, NTLMv1 downgrading, ICMP redirection and many more. It also has better safety measures in place to minimize disruptions on the network. So get out of here, and go check it out :)