🔨LLMNR
Last updated
Last updated
Link-Local Multicast Name Resolution (LLMNR) is a protocol that is able to perform name resolution in the absence of a DNS server. When a request is made for a share such as \\Fileshares and the user accidently instead types \\Filesharez getting the share name incorrect DNS would first attempt to resolve the target share and when failing to do so (As it does not exist) It will fallback to LLMNR.
Once DNS has failed to resolve the request and LLMNR kicks in the requesting machine will send out a broadcast on the subnet asking if anyone of the other devices can connect them to the share \\Filesharez The attacking machine on the network will respond to the request stating that it can get them connected to the share. At this point the requesting (victim) machine will send the username and NTLMv2 hash of the account requesting the resource over to the malicious machine.
To perform the attack we need to first start up Responder on Kali.
As of the time of writing December 2nd 2020 the version of Responder built into Kali v3.0.2.0 did not work correctly for me when attempting to capture hashes so instead I downloaded version 3.0.0.0 from Igandx's Github.
Once ready we can start Responder with the following command:
Once started you should see the following:
For now, on the attacking machine this is all we need to do. We now need to wait for an event to happen in which LLMNR is triggered by the victim machine so Responder can reply back to the victim machine to poison then capture the NTLMv2 hash.
On the victim machine if we was a user and tried accessing a file share where the name is incorrect or does not exist in the DNS server you would be prompted with the following message as per below.
In the example above the user has attempted to access the share \\filesharez which does not exsist. Firstly the machine will refer to the DNS server and attempt to resolve this name to IP. On failure to resolve the machine will send out a broadcast on the subnet using LLMNR asking if anyone is able to get the machine connected to the share.
At this point Responder which is actively listening will respond to this request asking for the requesting machine users NTLMv2 hash so it can masquerade as passing it on to the correct resolver.
Once this happens Responder should pick up the hash as shown below:
Once the hash is captured we can take it offline and attempt to crack it using a tool such as Hashcat.
We can use the following command to crack the hash:
The switch -m indicates which mode of attack to use on the hash. 5600 is defined in the Hashcat examples page as being for a NTLMv2 hash. https://hashcat.net/wiki/doku.php?id=example_hashes
After reading the output we can see hashcat has cracked the password as 'iloveyou' We now have the complete credentials of 'Bart.Simpson:iloveyou'
Monitor HKLM\Software\Policies\Microsoft\Windows NT\DNSClient for changes to the "EnableMulticast" DWORD value. A value of "0" indicates LLMNR is disabled. [16]
Monitor for traffic on ports UDP 5355 and UDP 137 if LLMNR/NetBIOS is disabled by security policy.
Deploy an LLMNR/NBT-NS spoofing detection tool.[17] Monitoring of Windows event logs for event IDs 4697 and 7045 may help in detecting successful relay techniques.[4]
Source: https://attack.mitre.org/techniques/T1557/001/
| Mitigation | Description |
|---|---|
Disable LLMNR and NetBIOS in local computer security settings or by group policy if they are not needed within an environment. [14]
Network intrusion detection and prevention systems that can identify traffic patterns indicative of MiTM activity can be used to mitigate activity at the network level.
Network segmentation can be used to isolate infrastructure components that do not require broad network access. This may mitigate, or at least alleviate, the scope of MiTM activity.
