# LLMNR (Link Local Multicast Name Resolution) LLMNR (Link-Local Multicast Name Resolution) is a protocol used for local name resolution in various networks, enabling devices to communicate with each other without requiring a DNS server. It allows clients to resolve hostnames to IP addresses even when the DNS service is unavailable. In a typical scenario, the client wants to access a shared resource, such as a folder, printer, or service, using a name like //DC/SecTeam, and requests the IP address from the DNS server. The DNS server responds, saying, "Yes, I have the IP address for this name, but you must authenticate yourself using the NTLMv2 authentication protocol first. If your authentication is legitimate, I will allow you to access that IP." In NTLMv2 authentication the server sends a challenge to the client. The clinet must encrypt the challenge and send back the encrypted challenge with its username and hashed password to the server. If the authentication is successful, the client gains access to //DC/SecTeam. However, if the client mistakenly types //DC/Sec instead of //DC/SecTeam, the DNS server will not have a record for this request. In this case, if LLMNR is enabled, the client can broadcast a message asking, "Who knows the IP for //DC/Sec?" This is where an LLMNR attack can occur. An attacker can set up a rogue DNS service and respond to the client's request by claiming to be //DC/Sec. In other words, the attacker responds to LLMNR requests with spoofed replies, misleading clients into sending sensitive information. The attacker instructs the client to send the encrypted challenge and its username along with the NTLMv2 password. The client, unaware of the attack, sends this information. If the user's password is weak, the attacker can easily crack it using tools like Hashcat, gaining access to the client's username and password. This type of attack is known as an LLMNR attack and is also referred to as a man-in-the-middle attack. Additionally, LLMNR was previously known as NBT-NS, which stands for NetBIOS over TCP/IP Name Service. The images below explain NTLMV2 Authentication and LLMNR Poisoning visually . {"ntlmv2"}/

${"LLMNR_Poisoning"}/$ # WPAD (Web Proxy Auto-Discovery Protocol) Normally, the client sends an IP request to the DHCP server. In response, the DHCP server provides the client with an IP address, subnet mask, gateway IP, and potentially the IP address of the proxy server. However, if an attacker intercepts this process by responding to the client’s IP request instead of the legitimate DHCP server, the attacker can provide a false IP address for the proxy server (for example, the attacker's own IP address instead of the legitimate proxy server's address). As a result, the client will send its requests to the attacker's proxy, allowing the attacker to manipulate or monitor the client's traffic and potentially execute more serious attacks. This technique is known as WPAD poisoning. To effectively impersonate the DHCP server, the attacker must also present a valid wpad.dat file. If the client trusts this file, it will accept the attacker's configuration, further facilitating the attack. The images below explain WPAD Poisoning visually . {"WPAD"}/

${"WPAD_Poisoning"}/$ # Difference Between LLMNR and WPAD Poisoning ## LLMNR Poisoning Scenario 1 : "Yes, I am //DC/SecTeam. Send me your hash!" In this scenario, the attacker impersonates the requested server (e.g., //DC/Sec). When the client attempts to connect to this server, the attacker captures the client's NTLMv2 hash during the authentication process. This hash can later be cracked to reveal the user's password, allowing the attacker unauthorized access. ## WPAD Poisoning Scenario 2 : "I’m not //DC/Sec, but I can be your trusted proxy server!" In this case, the attacker does not directly impersonate //DC/Sec. Instead, they set up a rogue WPAD server to deceive clients looking for a web proxy configuration. When the client searches for a WPAD server, the attacker responds with a malicious wpad.dat file, which the client trusts and uses to configure its web proxy settings. This allows the attacker to intercept and manipulate the client's web traffic. # Practical LLMNR and WPAD Poisoning First, a client attempts to access a non-existent shared folder called //DC/Sec. Since this folder was never shared, the DNS server (in this case, our Domain Controller) does not have the required records for it. As a result, with LLMNR enabled, the client broadcasts a request to all other devices on the network. This is the perfect opportunity for us to execute our attack command. You can use the following command to initiate the attack: ```bash:responder sudo responder -I wlan0 -Wvd ``` -W: performs a WPAD attack. -d: performs an LLMNR attack. Alternatively, you can use this command: ```bash:responder sudo responder -I wlan0 -Pvd ``` -d: performs an LLMNR attack. -P: enables poisoning for any protocol it can, making the Responder tool more powerful. The -P flag initiates a broader range of poisoning attacks, while the WPAD (-W) option is one specific type of attack within this broader set. However, when -P is activated, Responder focuses on poisoning all possible protocols without dedicating resources specifically to the rogue WPAD server. {"responder"}/

This command will capture the broadcasted traffic and respond by saying, "Here I am at //DC/Sec. Send me your password." After the user types in their username and password, the Responder tool will capture the NTLMv2 hash and username of the client. To crack the captured hash, you can use the following command: ```bash:hashcat hashcat -m 5600 pass.txt /usr/share/wordlists/rockyou.txt ``` {"hash"}/

LLMNR And WPAD Poisoning

Most Popular Posts