NetBIOS Name Service (NBNS) is a protocol that exists to resolve names on the network without the requirement for using local hosts files or DNS. It is part of the NetBIOS-over-TCP protocol suite enabling to run on top of an IP network; however, NetBIOS itself is not restricted to only IP. It was developed to essentially serve the same purpose of DNS in that it allows users to access resources using a name and it will in turn resolve that name to an IPv4 IP address. It varies from DNS in that NBNS is a flat name service whereas DNS is hierarchical, meaning that it can have a TLD (Top Level Domain), sub-domains, and hostnames while NBNS is similar to a hosts file where a single name resolves to an IP address. NBNS also varies from DNS in that requests are issued to either broadcast or multicast address, meaning that anyone who is connected to the same broadcast domain will hear this request if they are listening.
NBNS has been around since the early days of Windows to provide an easy way to resolve names on a network. More recently, other protocols have become more commonplace for this purpose, such as DNS. DNS has also been adapted to allow for a dynamic registration from a workstation into a namespace and is also compatible with IPv6. That said, NBNS and it's newer version counterpart called Local-Link Multicast Name Resolution (LLMNR), which now supports IPv6, are still commonly found during penetration tests and have been shown to be very lucrative to an attacker.
Windows uses the following order of operations when resolving names on the network:
- Local hosts file located in
%SystemRoot%System32driversetchosts - DNS
- NBNS or LLMNR
Since NBNS is only done after DNS, you may wonder how often a Windows host will actually use this for name resolution. The answer is quite frequently. Hence the reason it is still a very viable method for attackers to use today. For NBNS response spoofing, we will leverage a program called responder. Responder will listen for these broadcast requests and spoof a request back to the client. This response can prompt the client to begin the NTLM or SMB handshake and will potentially send hashes across the network to authenticate with the responding service. Responder can then capture these hashes from clients.
Most Kali distributions (ISO and VM) have this installed by default; however, if you are using an alternative platform, like Raspberry Pi, you will need to install it first. We will invoke the apt package manager to download it and install it for us.
To do this, follow the steps below:
- Run the following command:
#apt-get install responder python-opensslYou should see the following screen:
- This will proceed to install responder and the required
python-supportpackages. Now we can run responder from the command line with the help flag to see the options that are available.#responder –help
You can see from the help file that responder has more than just NBNS functionality built in; it can also respond to HTTP and HTTPS requests that require basic (Windows Enabled) authentication. For this reason, it is recommended that you stop the existing apache2 instance that is running and has been used in previous attacks, such as S.E.T. in the previous example. This can be accomplished using init.d, issuing the stop command to the apache2 service.
- This must be done as root, so if you're not already logged in with the root user, precede this with the
sudocommand.#/etc/init.d/apache2 stop
In this scenario, we are interested in using responder to capture the hashes that are sent from the victim's workstation when it attempts to access a protected resource that requires password authentication. We will only need the
–iflag to be set and then to specify the IP address of our Kali instance, in this case192.168.0.147. - Launch the NBNS listener and responder using the following command:
#responder –I [IP or interface of your Kali host]
With the service in place and running, now it's just a matter of waiting, usually not very long, before a user will attempt to access a protected resource and NBNS or LLMNR is invoked. If this is a lab environment and you want to force this process to happen, typically all you will need to do is to go to any Windows workstation on this same network and click Start | Run and start a process of mapping a Windows share by typing two backslashes,
\.That's it. NBNS will do the rest and begin the name resolution process with hosts that you've previously connected to. If your responder attack is successful, you will start to see hashes begin to populate your terminal window.
Now that we've captured an NTLMv2 hash off of the network, what are the next steps? Two scenarios are in play for this example: either we can crack the captured hash or we can use it in an SMB replay attack. Let's look at the differences between them:
- Crack the Hash – Using computation and comparison to a list of known (computed) hashes to determine what the user's password is. In the absence of rainbow tables or a relatively simple password, this option may be difficult.
- Hash Replay – Taking the captured hash and relaying to another system to attempt authentication as that user without knowing what the plain-text password is. This is very effective as an administrative user as it allows for privilege escalation on the targeted system.
Responder 2.0 has added the hash replay option as part of the core functionality.
SMBRelay.py, an add-on module, will listen for broadcast or multicast user requests and respond accordingly. The captured hashes will then be replayed to a target of the attacker's choosing and, if successful, a remote command can be run with the privileges of the authenticating user. This can be particularly handy if you manage to capture the NTLMv2 hash of a domain administrator or a user who has escalated privileges on the target machine. This can include adding a new account to the local administrator's group, exporting a shell from the target machine, or disabling problematic services such as anti-malware or anti-virus applications.As mentioned, the other option we have once collected the hash from the air, is to crack the hash using one of a variety of applications. In this example, we will use
hashcat, which is an application that is bundled with Kali. Keep in mind that cracking hashes can take lot of processing power, time, and/or disk space if you choose to use rainbow tables. If you are using an embedded system or underpowered laptop, this is not going to be viable for you. There are several cloud-based services that can be used to accelerate this process or if you have a high-powered graphics card, GPU-accelerated cracking can be done usingoclhashcat, which is available from theaptrepository. - To begin, you want to copy the hash that was captured by responder and paste it into a document that will contain your hashes.
- Now, run the following command:
#echo "John Q. Enduser::WIN- TBNVIDOOASO:1122334455667788:9DC8A21E85A42BE0E078D7DC03B18D4A:0101000000000000DB40F52F4B13D101CCA1F7F52A4ECF5F0000000002000A0073006D006200310032000100140053004500520056004500520032003000300038000400160073006D006200310032002E006C006F00630061006C0003002C0053004500520056004500520032003000300038002E0073006D006200310032002E006C006F00630061006C000500160073006D006200310032002E006C006F00630061006C0008003000300000000000000000000000002000001C37EF1DF4A11FCEDF6DA4978C0900B47140CF47731E3431C6118A45C70D12F70A001000000000000000000000000000000000000900180063006900660073002F00700069006E00620061006C006C000000000000000000" > hashes.txt - Next we want to obtain a password list that we will hash and compare to our captured hash. Kali has several built-in lists located in
/etc/share/wordlists. A common one that can be used is calledrockyou.txt. It is compressed by default and you will have to uncompress it before using it.#gunzip –d /usr/share/wordlists/rockyou.txt.gzThis process will take some time since the wordlist is very large. Once completed, a
rockyou.txtwordlist will now exist within that directory and we will use it withhashcat. The hashcat application has many options that are not all going to be used in this example. The one that we will need to use is–m, which corresponds to the hash type that hashcat will be expecting when it reads yourhashes.txtfile.If you look at the help file for hashcat using the
--helpoption, the different options for–mare spelled out under the hash types header. The hashes that we captured using responder are NTLMv2 hashes that correspond to anmvalue of5600. The other options hashcat is expecting are the hashes file that you created and the password list that you either imported or the defaultrockyou.txtfile. - Using these options, we construct the following command:
#hashcat -m 5600 hashes.txt password.list
The size of your password file, the complexity of the passwords you are decrypting, and the power of the device you run on hashcat all determine how long it will be before you see results. Discovered passwords will be displayed following the colon at the end of each corresponding hash.