OSCP Journey : LLMNR/NBT-NS ATTACK

I - Introduction

In this post, we will explore LLMNR/NetBIOS attacks, focusing on the use of a tool called RESPONDER and its ability to poison LLMNR/NetBIOS. We will then discuss effective defense strategies against this attack. Finally, we will demonstrate how to set up a honeypot to detect attempts to exploit this vulnerability within your network and configure it to run automatically at regular intervals. Let's dive in

II - What is LLMNR Attack

LLMNR sands for " LINK LOCAL MULTICAST NAME RESOLUTION " is a component in Windows which is used to identify hosts in a network when DNS fails to do so .

Crowe.com does a fantastic job at giving you a high-level overview of what NetBIOS & link-local multicast name resolution do u can find the url article below .

https://www.crowe.com/cybersecurity-watch/netbios-llmnr-giving-away-credentials

III - How the Attack works

Responder is able to work its magic when your computer attempts to resolve a DNS name and resorts to NetBIOS. This typically happens if you try to access a DNS name that doesn't exist as shown in the screenshot below :

What happened is that my computer made a DNS request, but the DNS service responded with "I don't know who this is." Subsequently, the computer queried the network using NetBIOS/LLMNR, seeking a response. However, the network indicated, "No, I don't know him."

IV - The attack in action

In another scenario, when a DNS request is responded to, my computer will attempt to connect to the responding server. This connection requires authorization, at which point Windows performs a single sign-on (SSO) and sends the hash of the active user to the responding computer.

Our first step is to set up Responder so it starts listening. We can do this with the following command:

Responder -I eth0

Our first step is to set up Responder so it starts listening. We can do this with a simple command by choosing the interface to listen on using the -I argument followed by the interface name:

Now, when we type in a fake domain as we did in the first screenshot, we should receive the hashes of the active user, which in our case is KJOY.

With KJOY's hashes in hand, we can attempt to crack them using either JohnTheRipper or Hashcat. For this example, I'll use Hashcat:

V - Defend against this attack

The best way is to completely disable LLMNR and NETBIOS following these steps

V.1 - Disabling LLMNR :

starting with LLMNR we need to create a new GPO :

1 - In your server management dashboard select tools

2- Group Policy Management

3- select your domain and create new GPO

4- Now select your GPO and edit

5- now under the path : computer Configuration/Administrative Templates/ Network / DNS Client select Turn off Multicast name resoluiitoion and enable it .

6- our last step is to force updates on our domain and the user pc using the cmd

gpupdate /force

V.2- Disabling Netbios:

Open the registry by typing Regedit in the run dialogue. Navigate to registry key at the following location.

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\

From here, we’ll be presented with multiple keys, each represents a network interface. You’ll want to adjust the NetbiosOptions value on each from the default of zero, to a value of 2.

and now when we try to connect to a fake it should directly error .

VI - Responder Honey Pot

So after disabling both LLMNR and NETBIOS we will use Resove-DnsName function to check for any responder activities in our network

the full commande is :

Resolve-DnsName -LlmnrOnly FakeDomain

The primary function of the LLMR command revolves around error notification in the absence of responder activity. When triggered, it systematically returns relevant information regarding the operational status and specifications of the computer hosting the responder service, as illustrated in the accompanying screenshot.

VI.1 - Send Notification to event Manager :

It is now imperative to craft a straightforward script aimed at promptly alerting the event manager upon the detection of Responder activity. Our initial endeavor involves the creation of an essential component: an event log tailored specifically for our script's utilization.

New event-log Application -source RespHoney

$llmnr = (Resolve-DnsName -LlmnrOnly FakeDomain 2> $null)
if ($llmnr) {
    $ip = $llmnr.Ipaddress -join ', '
    $msg = "Responder Activity Detected from ip :" $ip
    Write-Eventlog -LogName Application -source RespHoney -EventId 1338 -Message $msg -Entrytype Warning
}

Script Explanation:

1. Initialization of Variable:

   • We establish a variable, $llmnr, to capture the output of the command for resolving DNS names with LLMNR protocol (Resolve-DnsName -LlmnrOnly FakeDomain). Any potential errors generated during this process are suppressed from being displayed on the standard output (2> $null), ensuring a clean execution environment.

2. Extraction of Attacker's IP Address:

   • The $ip variable is utilized to store the IP address(es) of the detected attacker's computer. This information is extracted from the $llmnr object and formatted accordingly.

3. Message Composition for Responder Activity Detection:

   • The $msg variable is employed to construct a descriptive message indicating the detection of responder activity. It incorporates the attacker's IP address retrieved in the previous step for contextual clarity.

4. Logging of Warning Event:

   • The final line of the script orchestrates the logging of a warning event in the Windows Application Event Log. This event is associated with a custom event ID (1338), which serves as a unique identifier for the detected responder activity. Additionally, the source of this event is designated as RespHoney. This entire process aids in the systematic tracking and management of potential security threats.

VI.2 - Scheduling Task :

It is now opportune to automate the execution of the script through Task Scheduler. Follow these procedural steps:

1. Launch Task Scheduler.

2. Create a New Task.

3. Configure the Trigger:

   • Begin by selecting 'New' and replicate the specified settings:

4. 

It is now imperative to encode our script for heightened security measures. Utilizing CyberChef, we shall execute a two-step encoding process: first to UTF-16LE, followed by Base64 conversion. Referencing the demonstration provided in the screenshot below, we ensure adherence to these protocols for robust encryption.

• Under "Actions," opt for "Windows PowerShell" with the complete path specified.

  In the "Add Argument" section, input "-Nop -Enc" followed by pasting your encoded script for seamless execution.

Indeed, with these configurations, your task is now fully configured and ready for execution.

VII - Conclusion

In conclusion, understanding and defending against LLMNR attacks are critical components of maintaining robust cybersecurity protocols. By comprehending the nature of LLMNR vulnerabilities and implementing proactive defense strategies, organizations can safeguard their networks from potential exploitation.

Throughout this blog post, we have delved into the intricacies of LLMNR attacks, exploring their mechanisms and potential risks. From disabling unnecessary protocols to deploying DNS spoofing protections, a multi-layered defense approach is essential in mitigating LLMNR-related threats.

Furthermore, we have demonstrated the practical implementation of a honeypot system designed to detect and alert on responder activity—a proactive measure to bolster network security. By leveraging automated scheduling techniques, such as Task Scheduler, organizations can ensure continuous monitoring and timely response to potential security breaches.

In today's dynamic threat landscape, staying ahead of emerging vulnerabilities is paramount. Through education, vigilance, and proactive defense measures, organizations can fortify their networks and mitigate the risks posed by LLMNR attacks, thereby safeguarding sensitive data and preserving the integrity of their digital infrastructure.