Active Directory

Securing Active Directory Part 1: Legacy Name Resolution

J

15 Feb 2026 • 6 min read

Introduction:

Microsoft seems to be trying pretty hard to convince everyone to move to a cloud-native directory solution (Entra ID). While this isn't entirely a bad idea, we will be dealing with on-premises Active Directory for many more years to come.

This series on securing Active Directory will mostly cover information that is already well known to most information security practitioners. However, I felt the need to write it because I still see these same mistakes almost daily. So until these attacks stop working, I will keep talking about them. Hopefully I can reach at least one person who will use this information to better protect their organization.

This series will cover all the attacks that I see organizations fall victim to on a regular basis. So without further ado, here is Part 1.

The Problem

Legacy name resolution protocols are prevalent in most environments. Unfortunately, they often lead to the disclosure and compromise of user credentials through poisoning attacks. This gives attackers an easy way to gather and exploit credentials to move laterally and vertically within an environment.

When an attacker gains an initial foothold or beachhead in an environment, they often need to move laterally (to other devices on the same network) to achieve their goals. While motivations may vary between different threat actor groups, for the purpose of this post we will assume that the primary goal is ransomware and data exfiltration.

While it is possible that the beachhead device belongs to a Domain Admin, it is unlikely. Most often I see regular users who either unknowingly download a malicious attachment, fall for a fake Captcha/ClickFix attack, or (worst-case scenario) have their VPN compromised.

Now that the attacker has established a beachhead, they will often use poisoning attacks to gain additional credentials. The most common tool used for this purpose is Responder.

Responder listens for incoming name resolution requests and responds to the client with the attacker's IP address. When the client attempts to connect to the attacker, Responder requests network authentication—most of the time in the form of an NTLMv2 hash.

Once an attacker has these hashes, they can either attempt to crack them using tools such as Hashcat or use a tool like ntlmrelayx to relay the authentication attempt to another device on the network.

This unfortunately spells the end for a lot of organizations. It is quite common for an attacker to obtain the password hash of a Domain Admin or other privileged user utilizing this method and then crack or relay the hash. This will most often give the attacker access to the Domain Controllers, where they can perform actions on objective.

Attack Demonstration

For this demonstration I will be using Responder, but there are other tools available that can perform similar attacks.

Here I am starting Responder, and it is listening for incoming name resolution requests.

When an unsuspecting user attempting to reach "fileserver" accidentally types "fileeserver", a DNS request will be sent out for "fileeserver" (which does not exist). When this DNS request fails, the user's computer will fall back to other name resolution protocols such as LLMNR.

In the following screenshot you can see that a poisoned answer was sent back for "fileeserver". We then successfully captured the user's NTLMv2 hash.

Using Hashcat we can quickly crack the NTLMv2 hash and recover the user's plaintext password.

This is just one simple example of how Responder can abuse the LLMNR protocol. However, there are multiple different ways to perform this attack.

The Solution

The good news is that many of these legacy protocols can be disabled without any fear of disruption or downtime to the environment. But like all other things within information technology, a good change management process should be followed at all times.

In a perfect world, we would all be migrating to Kerberos-only authentication. However, until that dream becomes a reality, we are stuck trying to protect NTLM hashes.

Detecting Legacy Name Resolution Use

All of these protocols can be detected by analyzing network traffic. The easiest way would be to have centralized logging such as a SIEM solution that is ingesting and analyzing network traffic from your entire environment. However, most small environments will not have a tool of this nature and will instead need to take packet captures in every broadcast domain and analyze them using Wireshark.

LLMNR: TCP/UDP 5355
NBT-NS: TCP/UDP 137
mDNS: UDP 5353

Disabling LLMNR

Disabling LLMNR is quite simple and can be done via Group Policy.

The path to the policy is:
Local Computer Policy → Computer Configuration → Administrative Templates → Network → DNS Client

Double-click "Turn off multicast name resolution" and set it to Enabled.

Disabling mDNS

Unfortunately, mDNS cannot be disabled by Group Policy.
It must be disabled by editing the registry or with PowerShell:

PowerShell

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name EnableMDNS -Value 0 -Type DWord

Disabling NBT-NS

NBT-NS cannot be disabled by Group Policy either. While it is possible to disable it via DHCP configuration, I have found that the most thorough method is to use a PowerShell startup script:

PowerShell

$RegKey = "HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces"
Get-ChildItem $RegKey | ForEach-Object { Set-ItemProperty -Path "$RegKey\$($_.PSChildName)" -Name NetbiosOptions -Value 2 -Verbose }

It is also possible to disable it via the GUI by navigating to:
Network Connections → Network Adapter Properties → TCP/IPv4 Properties → Advanced tab → WINS tab and selecting “Disable NetBIOS over TCP/IP”.

Protected Users Group

From the Microsoft Docs:

"Protected Users is a global security group for Active Directory (AD) designed to protect against credential theft attacks. The group triggers nonconfigurable protection on devices and host computers to prevent credentials from being cached when group members sign in."

The Protected Users group safeguards sensitive accounts by forcing Kerberos authentication (among other things).

All Domain Admin and Enterprise Admin accounts should be placed in the Protected Users group. The only exception is if one of these accounts is being used as a service account (which is a really bad idea).

It should be noted that there may be non-Windows applications or services running that do not support Kerberos authentication. In that case, authentication will fail. Proper testing should be conducted before moving any user accounts into this group.

Closing Thoughts

I know this topic has been spoken/written about ad nauseam, but I still felt the need to write about it as unfortunately there are still a lot of organizations that are unaware of the dangers of having these protocols enabled on their network. In my experience, most organizations will only learn of the risk after a pen test or a successful breach.

I urge all organizations to take a proactive stance on their security posture and evaluate the usage of these legacy protocols in your environment before they get abused.