Internal Enterprise Network Attacks: LLMNR & NBT-NS Poisoning

No comments

As a penetration tester, one of the first attacks I attempt during an internal assessment is that of LLMNR & NBT-NS poisoning.  LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) are used to identify hosts when DNS fails to do so.  A key flaw of LLMNR and NBT-NS is that both services utilize a user’s username and NTLMv2 hash (Windows password hash) when appropriately responded to, allowing for a potential man-in-the-middle attacks.  Let’s take a high-level look at what this attack looks like:

output_xi0VvD

In the above example, we have a server, a victim, and a hacker sitting in the middle.  The victim is trying to get to the network share of \\hackme, but has accidentally typed the share name wrong and wrote “\\hackm”.  Since this share does not exist, the server does not know how to resolve the address.  With LLMNR and NBT-NS enabled, the victim machine will next ask all hosts on the network, via a broadcast message, if they know where “\\hackm” is.  Our attacker, being the malicious fellow he is, lies about knowing the location of the non-existent share.  Why?  Because the victim machine will send over its Windows login credentials in an attempt to connect to that share.  This is LLMNR and NBT-NS in a nutshell.

Let’s now take a look at a real-world example:

First, the attacker runs his or her LLMNR/NBT-NS poisoning tool, which will actively attempt to poison LLMNR/NBT-NS and capture user hashes.  The tool being used is Responder (https://github.com/SpiderLabs/Responder).

z

Next, the victim will incorrectly type in a file share.  For simplicity and proof of concept, the incorrect file share typed in is \\192.168.134.166, which happens to be the IP of the hacker machine.

za

With this mistake, Responder should catch the victim hash and it did.  It looks like user fcastle in the HACKER domain sent over a NTLMv2 hash.

zb

The captured hash can be run through a cracking tool, such as John the Ripper.  Here, the password is easily cracked and is “Hacker123”.

zc

It is that simple.  The password gathered can now be used to attempt to log in to other critical network assets.

Defenses:

The best defense is disabling LLMNR and NBT-NS.

  1. To disable LLMNR, select “Turn OFF Multicast Name Resolution” under Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client in the Group Policy Editor.
  2. To disable NBT-NS, navigate to Network Connections > Network Adapter Properties > TCP/IPv4 Properties > Advanced tab > WINS tab and select “Disable NetBIOS over TCP/IP”.

If a company must use or cannot disable LLMNR/NBT-NS, the best course of action is to:

  1. Require Network Access Control.  If an attacker cannot get onto the network, the attack cannot be performed plain and simple.
  2. Require strong user passwords (e.g. > 12 characters in length and limit common word usage).  The more complex the password, the harder it is for an attacker to crack the hash.

References: