LLMNR poisoning attack detection

Welcome to part three of a special series on detecting Active Directory attacks & misconfigurations. Each blog post dives deep into identifying, detecting, and mitigating a dangerous AD vulnerability. 

And the best part? 

You’ll get a free AD-focused Sherlock to practice the defensive techniques you learn!

The attack methods and misconfigurations we cover will include:

• Kerberoasting (part one)

• AS-REP Roasting (part two)

• LLMNR poisoning (part three)

• NTLM relay (part four)

• NTDS dumping (part five) 

Let’s get started! 

LLMNR poisoning explained

In earlier versions of Windows networks, the Network Basic Input/Output System (NetBIOS) protocol was used to perform operations across the network. A crucial component of this protocol was NetBIOS Name Service (NBT-NS), which was responsible for name registration and resolution.

Link-Local Multicast Name Resolution (LLMNR) is the successor of NBT-NS. It performs the same task as its predecessor, name resolution for hosts on the same local network.

LLMNR allows for the resolution of both IPv4 and IPv6 addresses into hostnames without the need for a DNS server on the local network. If a request to a DNS server fails (e.g., if a DNS server is not available), an LLMNR query is made across the local network to attempt to resolve that request.

So, how can this be a bad thing?

LLMNR does not require authentication to perform those name resolutions. That means that any computer on a local network can perform a LLMNR query.

If an attacker is listening on the local network, they can respond to those queries. This can lead to potential harmful behavior and attacks, such as LLMNR poisoning.

During an LLMNR poisoning attack, the attacker is listening for LLMNR requests. When a request is made across the local network, their device responds with its own IP address redirecting network traffic.

Responder is a popular tool to perform LLMNR poisoning attacks.

If an LLMNR event occurs on the network and the attacker is listening, Responder can obtain sensitive information regarding the victim such as the IP address, username, and password hash.

With the hash in their possession, attackers can attempt to crack it and obtain the password in clear text. Or they can try to relay that hash to authenticate as the victim in a particular service.

Note💡:LLMNR/NBT-NS Poisoning and SMB Relay is mapped to the sub-technique T1557.001 on The MITRE ATT&CK framework. 

Detecting LLMNR poisoning

Let’s dive into how we can find evidence of an LLMNR poisoning attack on network traffic.

Since network traffic contains so much extra noise (all regular web traffic for example), performing network forensics to pinpoint anomalies becomes difficult due to the sheer amount of traffic in corporate environments. 

So we need to know exactly where we should focus our efforts to find any evidence of malicious activity.

Just like in previous blogs, we’ll include a few conditions/traces that need to be present for us to conclude that indeed the attack mentioned above did occur. 

Analyze LLMNR traffic to find the rogue device

Let's start by opening the packet capture in Wireshark.

LLMNR runs on UDP port 5355 by default so we’ll filter for that. Now we can only see LLMNR traffic. 

Looking at source and destination IPs, we see that the IP address 172.17.79.136 performed a DNS query “DCC01” and another IP 172.17.79.135 that responds to that query. 

We notice that the query in question is “DCC01” which seems like a typo for a hostname (the actual hostname is DC01 but the user wrote a typo and instead the queried hostname was DCC01). 

From this, we can paint a picture that the user wanted to navigate to a file share on DC01 but instead wrote a typo “DCC01” which caused the DNS Server to fail and use LLMNR protocol for hostname resolution—from where the attacker’s rogue server acted as DC and grabbed the credentials. 

In legitimate cases, the IP address responding to the queries should belong to the Domain Controller. In our case, the DC IP is 172.17.79.4 and the machine responding to the queries is different, thus prompting us to look further into it. 

We will confirm this theory once we analyze SMB traffic. 

For now, we need to confirm that the “.135” IP address is a rogue device as we currently suspect that machine to be controlled by attackers. Remove the Wireshark filter and add a filter for DHCP.

We see the DHCP request between the suspected IP and the DHCP server. We can see the hostname for the machine that leased the “.135” IP address.

The hostname is Kali, an offensive Linux distribution used by hackers and pentesters. This confirms that this machine is not any domain-joined machine and needs further investigation.

Evidence of credential stealing in SMB traffic

Now we’ll analyze SMB traffic to find credentials being stolen and sent over to the attacker’s Kali Linux machine. 

Let's start over by adding an smb2 filter in Wireshark.

We can see multiple NTLM Authentication Negotiations. To only see negotiation packets and not other SMB packets, add a filter for “ntlmssp”. We will apply this filter first and then go back to viewing full SMB traffic.

• We can see that authentication is taking place for the domain-joined user called “john.deacon.”

• One other pattern we can spot is that multiple occurrences of NTLM authentications can be seen occurring within seconds of each other. 

By default we cannot see the IPs, so to view that go to View > Name resolution and enable Resolve Network Addresses. This will now display hostnames.

One thing to note is that DCC01 is not an actual host in the network, Wireshark decoded the Attacker’s Kali hostname as DCC01 in smb traffic because the victim machine (Forela-Wkstn002.local) thinks the Kali machine is the DCC01 host (the typo the victim made).

This confirms our findings so far that the credentials got stolen by the attacker from Wkstn002. 

Let’s again filter for smb2 traffic and see the file share the victim wanted to navigate to.

In smb traffic we see that the user from wkstn2 navigated to a file share on DC01. Now the whole scenario makes more sense. Let’s go over again to what happened.

1. The victim wanted to visit \\DC01\DC-Confidential but instead made a typo (\\DCC01\DC-Confidential) which failed the hostname resolution.

2. When the DNS server was not able to resolve DCC01 (as it does not exist), Windows tried using LLMNR to resolve this.

3. Our crafty attacker was running a tool called Responder in the network which acts as an LLMNR server and it responded to the LLMNR query by the victim machine.

4. The victim's machine sent the hash to authenticate thinking it was a domain controller, but in reality, it was an attacker-controlled server.

5. On the victim’s side, nothing seems out of the ordinary. When file share does not open, victim realises they made a typo and they type in the correct path and carry on as usual. In our case victim fixed the typo and navigated to DC01 share after realizing their typo.

We can see all above activity occured in under a minute.

Recovering & cracking the user hash 

This step is important because it allows us to determine if the attacker cracked the compromised user hash. 

If the password policy is strict in your environment, there’s a high chance the attacker failed to crack the password. The real impact of this attack is therefore reduced thanks to the complex password policy. 

Go to NTLM authentication traffic (ntlmssp filter). The NTLM authentication and negotiation occur in sets of three (3) packets. Each negotiation includes an: 

1. NTLMSSP_NEGOTIATE packet.

2. NTLMSSP_CHALLENGE packet.

3. NTLMSSP_AUTH packet.

To recover the hash, we need to dissect 1 set. Let’s do this on the first set. We need different values from the negotiations and to plug in the values in this format.

Format 

User::Domain:ServerChallenge:NTProofStr:NTLMv2Response(without first 16 bytes/32 characters).

To find each value:

User: In details of NTLMSSP_NEGOTIATE packet expand SMB2 (Server Message Block Protocol Version 2) ->SMB2 Header -> Session ID->Account.

Domain: In details of NTLMSSP_NEGOTIATE packet expand SMB2 (Server Message Block Protocol Version 2) ->SMB2 Header -> Session ID->Domain.

ServerChallenge: In details of the NTLMSSP_CHALLENGE PACKET  expand SMB2 (Server Message Block Protocol Version 2) -> Session Setup Response (0x1) -> Security Blob -> GSS-API Generic  -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> NTLM Server Challenge.

NtProofStr:  In details of the NTLMSSP_AUTH Packet expand SMB2 (Server Message Block Protocol Version 2) -> Session Setup Response (0x1) -> Security Blob -> GSS-API Generic **** -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> -> NTLM Response -> NTLMv2 Response ->NTProofStr.

NTLMV2Response: In details of the NTLMSSP_AUTH Packet expand SMB2 (Server Message Block Protocol Version 2) -> Session Setup Response (0x1) -> Security Blob -> GSS-API Generic **** -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> -> NTLM Response -> NTLMv2 Response. 

💡Note: You have to remove first 32 characters from the value of this field because the first 32 characters are the same as NTProofStr, which we already have acquired and is ready to be plugged in the hash format for cracking.

Now let's plug in the values in the format. 

This is the final format we get and we save this a txt file. 

Now let's get cracking. We will use Hashcat to crack this.

Hashcat Format: Hashcat.exe -a0 -m5600 hash.txt passwords.txt. 

In this format, hash.txt contains our hash format which we plugged in and passwords.txt is our wordlist.

To summarise what we’ve discussed so far: 

1. In LLMNR traffic, look for any machine responding to queries that is not a domain controller.

2. Look for NTLM authentication packets going towards the unidentified/unknown machine discovered from point 1.

3. Look for typos in LLMNR traffic, DNS Traffic, and SMB traffic. 

4. Try cracking the hash to see how resilient the password of the compromised user is.

5. As a follow up, look for authentications for the compromised user in the environment, especially after the time of LLMNR poisoning, and search for logon types three (3) (network logon) and 10 (RDP Logon).

Remediation

If LLMNR and NBT-NS are not required in the environment, you should disable both of them entirely as a mitigation measure.

If a particular organization is unable to disable the LLMNR and NBT-NS protocols, they can consider implementing Network Access Control (NAC) and requiring long and complex passwords to reduce the chances of attackers cracking them offline.

Practice detecting LLMNR poisoning with HTB Sherlocks

Take on the Very Easy “Noxious” Sherlock focused on forensics and detection of Kerberoasting attacks.

The Sherlock has a guided mode that’s perfect for beginner cybersecurity analysts or DFIR professionals looking to develop real-world defensive skills.

Boost your defensive skills in Active Directory