Despite the release of Kerberos more than 20 years ago, many enterprises today have not transitioned away from using NTLM authentication in their enterprise IT environments. As attackers continuously refine their tools and tactics, finding new and sophisticated ways to exploit NTLM's inherent vulnerabilities, the risks associated with maintaining NTLM are becoming increasingly prominent. This article aims to demonstrate some of the most popular and contemporary attacks exploiting NTLM, provide insight as to why Microsoft is working on disabling NTLM by default during the Windows 11 lifecycle, and underline the urgency for transitioning away from this outdated protocol. Keeping NTLM authentication enabled can lead to rapid (less than one minute) compromises of entire Active Directory domains.

Microsoft Authentication Mechanism History: NTLM and Kerberos

Introduced in the early days of Windows, NT LAN Manager (NTLM) was developed as a protocol for authenticating and authorizing users in network environments. It was designed to provide user authentication to remote systems through a challenge-response mechanism, allowing users to prove their identity without transmitting their password. This protocol has evolved over time, leading to different versions of NTLM authentication and corresponding hash types.

Initially, NTLM authentication used simpler hash mechanisms, but as security threats evolved, so did the protocol. Modern Windows environments predominantly use an enhanced version of the protocol known as NTLMv2. This version generates what are called NetNTLMv2 hashes, which are more secure and complex compared to the original NTLM hashes. These will be the focus of our demonstrations. We’ll leave a discussion of the differences between the various hashes to this Medium article, and recommend this blog post from Praetorian for those who want to learn more about the security concerns around NTLMv1.

If you don’t know anything about the different NTLM versions and are not inclined to delve deeper, then the bottom line for this article is that NTLMv2, which is the most “modern” NTLM version and the default for most organizations, is affected by a host of problems that we’ll outline in this article. NTLMv1 is affected by all the same problems and more.

A following diagram describing how NTLM works at a high-level:

The persistence of NTLM in various Windows environments can be attributed to a few of its unique features:

• NTLM could authenticate users without requiring a connection to a Domain Controller, making it suitable for environments with limited network infrastructure.
• NTLM was the sole protocol supporting user authentication for local accounts, which was essential in systems not part of a domain.
• NTLM could authenticate when the identity of the target server was unknown, offering versatility in diverse network configurations.

These characteristics led to the integration of NTLM into several applications and services, some of which were even hardcoded to use NTLM over more modern authentication methods.

The Introduction of Kerberos

Kerberos, a more secure and robust authentication protocol, became the default for Windows in 2000. Developed at MIT, Kerberos was designed to address the inherent security weaknesses in NTLM, offering stronger security guarantees and better scalability in network environments. The protocol works based on tickets, allowing users to prove their identity securely across network services without repeatedly transmitting credentials. A simple (even though it may not look that way) diagram describing how Kerberos works has been included below.

For the sake of brevity, a full description of how Kerberos authentication works can be found in the related Microsoft documentation or in this simplified Newtrix article.

Despite Kerberos being more advanced, its implementation came with limitations:

• Kerberos authentication necessitated continuous access to a Domain Controller, limiting its use in certain network environments.
• The protocol required explicit specification of the target server, which wasn’t always feasible in dynamic network settings.
  

As a result of these challenges both NTLM and Kerberos were left enabled, with systems configured by default to negotiate between the two protocols. This negotiation process allowed systems to fall back to using NTLM if Kerberos was not feasible due to environmental constraints or configuration issues. The fallback mechanism, while intended to ensure seamless functionality during the transition, left NTLM as an available option for authentication. Consequently, in specific scenarios, Windows systems could still revert to using NTLM by default, potentially creating security gaps that could be exploited through various attack vectors (which we’ll talk about shortly).

The Transition Phase

The shift away from NTLM towards Kerberos has been an ongoing effort for several years, with Microsoft introducing various controls to facilitate the gradual disablement of NTLM. These efforts highlight a clear thematic direction: NTLM is becoming obsolete in favor of more secure alternatives like Kerberos.

In October 2023, Microsoft announced that it had renewed and intensified this effort. This move signifies a decisive step away from applying temporary fixes to NTLM's inherent security flaws. Instead, the focus is now on enhancing Kerberos, positioning it as the primary, more secure authentication protocol for Windows environments.

The introduction of enhanced features in Kerberos, like IAKerb (which allows clients to authenticate with Kerberos in more diverse network topologies) and a local KDC (which adds Kerberos support for local accounts), coupled with refined management and auditing tools for NTLM in Windows 11, indicates a clear trajectory. Microsoft is no longer just encouraging, but now actively steering enterprises towards Kerberos-only setups. This transition is critical for addressing the security vulnerabilities intrinsic to NTLM, marking a significant milestone in Microsoft's journey towards a more secure and resilient authentication framework.

This begs the question, if Microsoft is going to take care of it in the near future, why should enterprises start working to disable NTLM today? Is it even that bad?

Inherent Issues and Design Challenges with NTLM

At a high-level, there are several inherent issues with NTLM:

1. NTLM lacks mutual authentication. NTLM's one-way authentication process means the client verifies its identity to the server, but the reverse is not true. This absence of mutual authentication creates vulnerabilities to man-in-the-middle attacks, where an attacker could impersonate a server and intercept or alter communications between the client and the server. The inability of the client to verify the server's identity is a significant shortfall, especially in modern network environments where secure, bidirectional trust is essential.
2. NTLM uses outdated hashing and encryption algorithms that are more susceptible to cryptographic attacks compared to current standards. The use of weaker algorithms, such as MD4 and DES, makes NTLM hashes vulnerable to brute-force attacks, where attackers can quickly try numerous combinations to discover the original password. Modern encryption standards offer stronger, more complex algorithms that are resilient against such attacks.
3. NTLM relies on a challenge-response mechanism using hashed versions of user passwords. If these hashed passwords are intercepted or extracted (for example, through memory dumps), they can be used in pass-the-hash attacks, enabling attackers to impersonate users without knowing the actual passwords. This reliance on hashed passwords, without additional safeguards, poses a substantial security risk, as compromised hashes can grant attackers access to various network resources.
4. NTLM's automatic authentication mechanism, designed for convenience within Active Directory environments, allows users to access network resources such as shared folders or printers without repeated credential prompts; a convenience that comes with security trade-offs. When a user logs into a Windows system, their credentials (username and hashed password) are stored in memory. During their session, these stored credentials are used for authentication requests to network resources using NTLM. This automatic authentication occurs without the system verifying the legitimacy of the network resource (as outlined in #1) because the network is treated as inherently trustworthy, which could lead to inadvertent leakage of NTLM credentials, making them vulnerable to theft or misuse.

Attackers can chain these issues together to completely compromise internal Active Directory environments.

Automatic Authentication in Network Browsing 

Let’s take a look at how automatic authentication works in a lab environment. To demonstrate this, we’ll use a Windows machine within an Active Directory domain and a Linux machine outside the domain but on the same network, allowing free communication between the two. The Linux machine will play the role of the "attacker" in this demonstration. It is configured to run the open-source tool Responder, which we’ll use to mimic a file server.

In the video below, we’ve used RDP to access the Windows machine as the “cgt\tony” user and will browse to the Linux machine's file share (\\172.18.0.20\fake\share) that is being run by Responder. Windows will automatically attempt to authenticate to this “fake” share, and we’ll see a NetNTLMv2 hash, which is a hashed version of the user's credentials, get captured by our Responder tool as part of the NTLM challenge-response protocol.

Responder, running on the Linux machine, is set to listen for such authentication attempts. It captures the NetNTLMv2 hash sent by the Windows machine, despite the Linux machine not being a part of the Active Directory domain. This capture demonstrates how Windows, under the presumption of connecting to a trusted resource on the local network, automatically sends the credentials.

Capturing Credentials with Crafted LNK Files

While capturing hashes through direct user input of a network path demonstrates the protocol's vulnerability, it's not a likely scenario in a real-world attack. Most users would not manually enter the path to an unknown, potentially malicious network location. To make the attack more feasible and covert, we can use crafted LNK files.

LNK files, commonly known as Windows shortcuts, can be manipulated in such a way that their icon paths point to a network location. For our demonstration, we configure the icon path of the LNK file to point to the Linux machine running Responder (\\172.18.0.20\fake\share). It's important to note that the actual shortcut path isn’t important here; it's the icon retrieval mechanism that we're exploiting.

In our lab setup, we use PowerShell to create a LNK file on the Windows machine with its icon path set to the Linux machine. This approach is necessary because the share doesn't actually need to exist at the time of creation. Ideally, for an effective attack, the LNK file would be placed in a directory that users frequently access, such as a corporate file share. This strategic placement increases the likelihood of triggering the authentication process. Responder, configured on the Linux machine, is ready to listen for incoming NTLM authentication requests. As a user on the Windows machine navigates to the directory containing the crafted LNK file, Windows, in an attempt to retrieve the file icon from the specified network path, initiates an automatic NTLM authentication process. During this process, the NTLM credentials, in the form of a NetNTLMv2 hash, are transmitted to the Linux machine. Responder then captures these credentials, exploiting Windows' automatic mechanism for authenticating to network paths specified in LNK file icons.

“Why does Windows automatically trigger authentication for LNK files, even before I click on them?”

Windows automatically tries to retrieve resources associated with a file for functionality like displaying icons or previewing content. This feature is part of the operating system's user-friendly design, aimed at providing immediate and relevant file information. When encountering an LNK file with a network path, Windows interprets this as a legitimate request for network resource access and initiates an automatic NTLM authentication process to authenticate with the network location.

Targeting Servers in Coercion Attacks

Attackers can target not just client machines but also servers in NTLM coercion attacks. These attacks exploit the automatic authentication behavior of NTLM, forcing servers to authenticate to a controlled machine. One well-known NTLM coercion attack is PetitPotam, which demonstrated how an unauthenticated attacker could coerce a Domain Controller (DC) to authenticate to a controlled machine. PetitPotam takes advantage of the Encrypting File System Remote (EFSRPC) protocol, which, when invoked, triggers an NTLM authentication process from the DC. The attacker can then capture this authentication attempt, gaining access to the password hash for the DC machine account. Machine accounts in Active Directory are similar to user accounts but represent computers rather than individual users. Like user accounts, machine accounts have associated credentials and can perform NTLM authentication. However, machine accounts typically have different privilege levels and usage patterns compared to regular user accounts.

In recent years, several vulnerabilities similar to PetitPotam have emerged, exploiting NTLM coercion in various ways. These include DFSCoerce, ShadowCoerce, and CheeseOunce. Microsoft has patched some of these vulnerabilities, especially those allowing unauthenticated coercion. However, vulnerabilities requiring authenticated access are often not triaged with the same urgency or have been marked as “Won’t Fix” by Microsoft, like PrinterBug. These coercion attacks are exceptionally dangerous because they can target tier-0 assets like domain controllers, backup systems, DNS servers, and certificate authorities. Compromising such critical infrastructure can lead to widespread network compromise and privilege escalation.

Coercer, as described on its GitHub page, is a Python script capable of coercing Windows servers to authenticate to an arbitrary machine using 12 different methods. In the lab setup, we’ll use Coercer to target a fully patched Domain Controller. By doing so, we’ll demonstrate how Coercer (on the left) coerces one of the lab’s Domain Controllers into performing NTLM authentication via the Print System Remote Protocol (MS-RPRN) and a low-privileged domain account, with the authentication attempt captured by Responder (right).

“Wait, so you just captured the machine account hash from a fully patched domain controller using a low-privileged domain account? How is that even a thing and why isn’t it patched?”

Windows systems use various protocols for inter-process communication (IPC) and remote procedure calls (RPC). These protocols allow different processes on the same or different machines to communicate and perform actions on each other's behalf. Common protocols include MS-EFSRPC (used for Encrypting File System), MS-RPRN (used for printer functions), and others associated with system services. In a typical scenario, these functionalities are used for legitimate administrative or operational purposes. For example, a service might need to authenticate with a domain controller to request certain actions or access specific resources.

In a coercion attack, an attacker manipulates these functionalities to force a server (often a domain controller) to initiate an NTLM authentication process with an attacker-controlled machine. This is achieved by sending crafted requests to these services, causing them to authenticate to the attacker’s machine under the guise of a legitimate operation.

In our exploit demonstration above, we abused the remote MS-RPRN function RpcRemoteFindFirstPrinterChangeNotificationEx. This function is designed to create a remote change notification object that monitors changes to printer objects and sends change notifications to a print client. One of the arguments we can pass to that function is pszLocalMachine, which is a pointer to a string that represents the name of the client computer. As part of execution, this function will end up attempting to connect to the client computer we specified, and when it does so, will attempt authentication, divulging the machine account hash.

As far as the machine (and Microsoft) are concerned, nothing out of the ordinary is happening here. We have a valid domain user connecting to the remote protocol for the print system asking the server to create a remote change notification object and telling it to send those change notifications to a client on the local network, which is a network that is implicitly trusted by Windows. Of course, if an attacker (or malicious insider) had compromised our “trusted network” we would be in big trouble, because with the lowest privilege domain account they could obtain a machine account hash for one of our most important assets: a domain controller.

At this point you might be thinking, “well who needs printers anyways, lets just disable that service and fix everything”. Unfortunately, its not that simple anymore. Research into coercion vulnerabilities is becoming more and more popular as attackers (and researchers) find issues that can have huge impact and that Microsoft doesn’t have easy fixes for. Coercer itself (a single tool) has a dozen methods it can use to coerce authentication. Shown below is the tool being used to scan our targeted Domain Controller, with each output line representing a unique method that could potentially be used to coerce authentication:

On domain controllers, some of these services are crucial for routine operations like processing authentication requests, managing group policies, and handling file services. Disabling or heavily restricting these services on domain controllers can lead to significant operational issues, affecting everything from user logins to printer discovery. There’s not a simple patch we can apply that will take care of all these problems without potentially breaking legitimate functionality. We’ll outline mitigation strategies at the end of this article but understand that the problem is both widespread and complex.

Abusing Legacy and Unused Network Protocols

While we’ve focused on LNK files and coercion attacks as methods for capturing NTLM hashes, it's important to recognize that these are just a few of the many techniques attackers can use. The NTLM protocol, with its inherent weaknesses and its widespread implementation in Windows environments, is susceptible to a range of other well-established attack vectors. For brevity, we won't delve deeply into each of these methods, but it's crucial to be aware of their existence and impact. These include, but are not limited to, the abuse of legacy and unused network protocols, which can be exploited to capture NTLM hashes:

Web Proxy Auto-Discovery (WPAD): WPAD allows clients to automatically detect a proxy configuration file. In some scenarios, NTLM authentication may occur with the detected proxy, leading to the inadvertent transmission of hashes to a malicious proxy server set up by an attacker.

Local Link Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS): LLMNR and NBT-NS are protocols used for name resolution in networks where DNS fails. Attackers can respond to these requests and impersonate network services, causing the client to authenticate with NTLM and send their hash.

Dynamic Host Configuration Protocol version 6 (DHCPv6): Since Vista, Windows defaults to using IPv6 over IPv4 due to its enhanced capabilities, such as a larger address space and integrated security features. This leads to Windows clients automatically soliciting IPv6 configurations via DHCPv6. In environments where IPv6 is unused or improperly configured, this behavior can allow attackers to configure rogue DHCPv6 servers to intercept NTLM hashes.

Bridging the Gap: The Significance of Obtained NTLM Hashes

Capturing NTLM hashes is more than just a demonstration of a security vulnerability; it's a gateway to potential system compromise. The question arises: once an attacker has these hashes, what can they do with them?

Relay Attacks

NTLM authentication involves a challenge-response mechanism. When a client requests access to a server, the server sends a challenge. The client responds with an NTLM response, calculated using the user's password hash and the server's challenge. A critical aspect of NTLM is that it doesn't inherently verify the server's identity to the client (lack of mutual authentication). This means the client doesn't authenticate the server before sending the NTLM response. In a relay attack, the attacker positions themselves between the client (user) and the server. When the client sends the NTLM response, the attacker intercepts it. Because there's no verification of the server's identity, the intercepted response can be relayed to another server. The attacker uses the client's response to authenticate themselves to this second server, impersonating the client. A diagram depicting how this works has been included below:

Diagram courtesy of Hackndo, who has an excellent blog post detailing how NTLM relay attack works and describing what can and cannot be relayed. If you want the technical explanation of how relay attack works please check their blog post out.

NTLM relay attacks exploit the trust relationship in a network environment. The second server (the one being relayed to) trusts that the authentication response is coming directly from the client, not realizing it’s been intercepted and relayed by an attacker. The NTLM response itself is versatile and can be used in various contexts, making it a valuable target for attackers. Once intercepted, it can be used in multiple ways across multiple services depending on the attacker's objectives.

SMB Relay

In our lab, we’ll use (again) a crafted LNK file to trigger NTLM authentication. Instead of Responder, we’ll employ the NTLMrelayx tool, which is designed to intercept and relay NTLM authentication sessions. When the Windows user accesses the directory with the crafted LNK file, it will send an NTLM authentication request as part of the usual automatic authentication process. NTLMrelayx, listening on the network, captures this authentication attempt. Instead of just recording the hash, it actively relays this session to another target, such as an SMB server. By relaying the NTLM session, the attacker can gain the same level of access as the victim. This can include accessing files, executing commands, or even escalating privileges if the captured credentials belong to a user with administrative rights.

In the demonstration above we were able to relay Tony’s credentials to gain administrative access to the NEWS system since SMB signing was not enabled.

ADCS Relay

Active Directory Certificate Services (ADCS) provides functionalities for creating and managing digital certificates. It's an essential component in Windows environments for securing communications and establishing trust. ADCS Web Enrollment is a feature that allows users within a network to request and retrieve digital certificates through a web interface. It's designed for ease of use, enabling straightforward certificate management without complex administrative overhead. In normal operation, Web Enrollment streamlines the process of obtaining certificates necessary for tasks like email encryption, secure website access, or machine authentication. ADCS's web enrollment feature can be targeted in relay attacks, much like SMB.

Attackers can exploit the Web Enrollment service in ADCS by coercing a server, like a Domain Controller, to authenticate against a rogue service controlled by the attacker. This is a form of NTLM relay attack specifically targeted at ADCS. Once the attacker relays this coerced authentication to ADCS, they can request certificates on behalf of the coerced server. ADCS typically has several default certificate templates, such as user, machine, and domain controller certificates. These certificates are integral to the security infrastructure, as they can be used to authenticate various services and applications within the domain. When attackers successfully relay coerced authentication to ADCS, they can enroll for these certificates. With a certificate like a Domain Controller certificate, attackers can potentially impersonate Domain Controllers or other high-privileged roles within the network.

In our lab, we’ll demonstrate a coercion attack by using Coercer to initiate authentication from a Domain Controller (DC01). The coerced NTLM authentication will then be relayed to ADCS using Certipy, aiming to enroll for a high-value certificate like a “DomainController” certificate. Once the certificate is obtained, it can be exchanged for a plain NTLM hash, which can then be used to perform a DCSync attack using the open-source tool secretsdump. A DCSync attack is a post-exploitation technique that allows an attacker to simulate the behavior of a Domain Controller (DC) to request sensitive data from other DCs within the network. Specifically, the attacker uses the Directory Replication Service (DRS) Remote Protocol to request account password data and hashes.

In the attack above we showed how it was possible to leverage coercion to get a NetNTLMv2 hash for the Domain Controller’s machine account, relay that to AD CS to get a certificate we could use for authentication, then performed a DCSync to obtain plain NTLM password hashes for any or all domain principals. This would represent a complete compromise of the Active Directory domain in about one minute.

ADCS, with its broad functionality and integral role in network security, presents a large attack surface. Regularly examining and securing ADCS is as crucial as securing Active Directory itself, given its potential for being exploited in sophisticated attacks. If you’re hearing about ADCS attacks for the first time from this article, we strongly encourage you to read about them from SpecterOps, the organization that pioneered research into the ADCS attack surface.

SMB and ADCS are not the only relay options available to attackers, but that’s all we’ll show in this article. Fox-IT has a great relay writeup if you want to see demonstrations of other potential relay avenues like LDAP, IMAP, and MSSQL. If you want a deeper dive into the relaying in general, consider taking a look at this blog post from LuemmelSec.

Hash Cracking

In Windows environments, there are several types of NTLM hashes, including LM, NT (known as NTLM which can get confusing), NetNTLMv1, and NetNTLMv2. Each serves different purposes and operates under varying security mechanisms. We’ll leave a discussion of the differences to this medium article, which we linked at the start of this article. Some hash types, like NTLM, can be commonly used for direct authentication in techniques such as pass-the-hash. Others, like NetNTLMv2, are designed with additional security measures (like incorporating server and client challenge values) that prevent them from being used directly for authentication.

Pass-the-hash attacks allow attackers to use the captured hash directly, instead of the plaintext password, to authenticate to network resources. This technique bypasses the need to crack the hash into its password equivalent. This is what we did when we initiated the DCSync using secretsdump with the NTLM hash for the DC01$ machine account.

However, when dealing with hashes that cannot be directly used for authentication, like NetNTLMv2, we turn to hash cracking. Hash cracking is the process of recovering the plaintext password from a hash, whether that be via brute-force attacks that try every possible combination or sophisticated methods using common wordlists and mutations to guess common passwords. Although captured NetNTLMv2 hashes cannot be directly used for authentication, their cracked plaintext passwords can be.

We’ll demonstrate this by capturing a user’s (Tony’s) NetNTLMv2 hash. Using Hashcat, a powerful password recovery tool, we will attempt to crack this hash to recover Tony’s plaintext password.

Captured password hashes are vulnerable to offline cracking efforts. Attackers use powerful computing resources to apply brute-force or dictionary attacks, attempting to discover the plaintext password.

Successful cracking of these hashes is particularly dangerous because it provides the attacker with actual user credentials, which can be used for further attacks or to maintain persistent access within the network.

With a single Nvidia 4090 graphics card, Hashcat would allow us to crack NetNTLMv2 hashes at a rate of 11.7 GH/s, which is about 11 billion attempts every second. At this rate, we would be able to try all passwords between 1 to 8 characters long (including upper-case letters, lower-case letters, numbers, and special characters) in about half a day. This underscores the importance of using long (at least 12 characters), complex, and unique (those that do not appear is breaches or other common wordlists) passwords.

Recommendations for Combating NTLM Attacks

The most effective way to combat NTLM attacks is to disable NTLM authentication across your network. This step removes the vulnerabilities associated with NTLM entirely. Disabling NTLM can be challenging, particularly in environments with legacy systems that rely on it. These systems might face operational issues or lose access to certain network resources. Despite these difficulties, the security benefits of disabling NTLM typically outweigh the risks associated with maintaining it, especially in modern networks where more secure alternatives are available. If you’re not sure what the impact on your environment may be we recommend starting with enabling Audit NTLM Authentication in This Domain via group policy so that you have an operational log to review and understand what pieces of your infrastructure still relies on NTLM authentication.

If disabling NTLM is not immediately feasible, then the only option is to reduce opportunities for attackers to collect and leverage hashes.

Mitigate Impact of Hash Acquisition

Enable and Enforce SMB Signing: SMB signing is used to secure Server Message Block (SMB) communication by providing a digital signature that verifies the authenticity and integrity of the communication. Enabling SMB signing can slightly impact network performance due to the additional processing required for signing and verifying each message. However, this impact is often minimal with modern hardware and is outweighed by the significant security benefits in preventing SMB relay attacks.

Enable and Enforce LDAP Signing and Channel Binding: LDAP signing ensures the authenticity of LDAP traffic, while channel binding tokens (CBT) enhance security by binding the transport layer and the application layer. Enabling LDAP signing and channel binding may require updates to client and server configurations. Older applications or systems not compatible with these settings may face connectivity issues, necessitating updates or configuration changes.

Enable Extended Protection for Authentication (EPA): EPA is a security feature that enhances the security of NTLM authentication by binding the authentication process to the transport layer. Implementing EPA across the network, especially on ADCS servers and other critical servers, significantly reduces the risk of NTLM relay attacks. When enabling EPA, ensure compatibility with both client and server configurations to maintain operational efficiency.

Enforcing Strong Password Policies: Strong password policies are essential in securing network environments. Implement policies that require passwords to be complex, long (at least 12 characters), and unique. This reduces the risk of NTLM hash cracking and increases the overall security of user accounts. Educating users on the importance of strong passwords and providing tools for password management can aid in maintaining effective security practices.

Disabling Avenues for Hash Acquisition

Disable LLMNR: LLMNR allows devices on the same local network to resolve each other's names without requiring a DNS server. Disabling LLMNR might affect name resolution in small networks or environments where DNS is improperly configured. However, in well-configured domains, DNS alone is typically sufficient for name resolution, making LLMNR unnecessary and safe to disable.

Disable NBT-NS: NBT-NS is used for name resolution in networks that rely on NetBIOS. In modern networks, DNS largely replaces the need for NetBIOS. Disabling NBT-NS might impact older applications or systems that rely on NetBIOS for network communication. Ensuring these systems are upgraded or have alternatives in place is essential before disabling NBT-NS.

Block DHCPv6 or Prefer IPv4 to IPv6 (if not in use): If the IPv6 network is not being used and/or has not been configured for use, then Windows clients with an IPv6 network interface may still send DHCPv6 configuration requests that attackers can respond to and can leverage to establish themselves as a DNS server. To mitigate this, it is important to either a) block incoming DHCPv6 traffic on all systems b) or force preference for IPv4 over IPv6 on all systems.

Disable WPAD: WPAD automates the configuration of web proxies for clients on a network. If your organization is not using WPAD, disable it. If automatic proxy configuration is necessary for client devices, consider manually configuring the location of the proxy file instead of relying on auto-detection, or consider using alternative methods for distributing proxy settings.

Perform Patching and System Updates Regularly: Ensure all systems and applications are consistently updated to address security vulnerabilities, including those affecting NTLM authentication. Regular updates and patching are critical for protecting against security threats, particularly for preventing exploitation of NTLM weaknesses. Establish a routine schedule for applying updates and prioritize critical security patches, considering automation to maintain consistent security levels.

Disable Unnecessary Services Prone to Coercion Attacks: To mitigate the risk of NTLM coercion attacks, it's crucial to disable or restrict unnecessary services that can be exploited. These services often include certain Windows RPC services known to be vulnerable to such attacks. Carefully evaluate your network and disable services that are not essential for your operations. For example, your domain controllers probably don’t need to expose the print service.

• Block MS-ESFR: The MS-EFSRPC protocol is used for managing the Encrypting File System (EFS) on Windows. Disabling this service is generally safe in environments where EFS is not used for encrypting files.
• Block MS-RPRN: The MS-RPRN protocol is associated with printer functions, specifically managing print jobs and printer configurations on Windows. It's typically safe to disable MS-RPRN in environments where remote printing services are not required or if print management is handled by other means.

Regularly review and update the list of enabled services, considering the latest threat intelligence and security advisories to stay ahead of potential exploitation vectors.

Conclusion:

By implementing these recommendations, organizations can significantly reduce the risk posed by NTLM-related vulnerabilities, but not completely eradicate them. While the transition away from NTLM can be challenging, it is a necessary step toward ensuring a more secure and resilient network environment.

Want to find out how quickly an attacker can compromise your Active Directory domain? Contact us today!