VHL004 - LLMNR Poisoning

    In an active directory environment, attackers can use the mistakes of the users to their advantage to gain information that they should otherwise not have access to. One such attack is exploiting LLMNR and using it to gather user credentials.

The LLMNR, Link-Local Multicast Name Resolution, protocol is used to locate host in a local network without the need of DNS. It will do so by contacting every machine in its network asking for a specific hostname in hopes to find it. As an attacker, this can be very beneficial. If we are on that network, that query will be sent to us as well, which we can respond to. Attackers can use the program Responder to answer this query and request the machine to give their username and hash to authenticate. It will in turn hand over their credentials to the attacker who can use that credential to further their attacks. [1]

Simulation

To simulate this attack on the network that we have set up, we will need the domain controller, one of the workstations, and a Kali Linux machine turned on. The Kali Linux machine will by default have Responder installed so there is no need for outside installs. This program will need to be run with root.

To start, we need to get Responder running on the interface that the victim machines are on. On the victim workstation, we are going to access the shares from the domain controller. This is done through the File Explorer and the users will type in "\\HWDC16". This will then show the share folders that the user has access to.


So now go to your Kali attacker machine and start the Responder program as root and specify the interface. Depending on your system and interface, this may be different for you but here, I just have to add the switch “-I” and specify the interface and it will begin listening.



Now with Responder listening, go back to the workstation.

We are going to simulate a user accidentally mistyping the name of the workstation that they want to access. Here, the user is attempting to access the domain controller but instead is going to attempt to access “HWDC17”. A simple mistype.



When they press enter, this message will pop up. But this isn’t required for them to fall for this attack, it's already too late.


When they pressed enter to search for the “HWDC17” hostname, they sent a query to the entire network attempting to locate this host. One of those machines was our's running Responder. Responder intercepted that query and asked for the machines credentials, the workstation sent them, the attacker received them and sent that access denied.


Using Hashcat, we can crack this hash if it is weak enough to use this user's credentials in further attacks.

We were able to crack this user’s very weak password of “Password1!”.

 

Prevention

    To prevent this attack, the domain administrators will need to disable LLMNR in the network only using DNS. They can do so by going into their GPO Manager and add a policy that turns LLMNR off. They will also need to disable NBT-NS. They can also use the GPO Manager to turn this off as well. [2]

    If for whatever reason these can not be disabled, then it is important to enable NAC, Network Access Control, and enforce much stronger passwords. The attacker can not use these hashes in the hashed state and will need to crack them and get the password to further their attacks.

 

 


References 

[1] https://www.blackhillsinfosec.com/how-to-disable-llmnr-why-you-want-to/

[2] https://www.surecloud.com/resources/blog/local-network-vulnerabilities-llmnr-nbt-ns-poisoning

Popular posts from this blog

Active Directory Through an Attacker's Lens

VHL002 - Setting up the Domain Controller and Workstations

VHL005 - Own the Workstations, Local Admin Password Re-use

VHL003 - Kali Linux Setup

VHL001 - In the Beginning