Security researchers have found many vulnerabilities in Microsoft products in recent months which, in the worst case, allow to escalate privileges from non-authenticated access to the domain administrator. These include ProxyLogon (CVE-2021-26855, CVE-2021-27065) and ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) by Orange Tsai, PetitPotam (VDB-179650) by topotam, and various vulnerabilities in insecurely configured Active Directory Certificate Services (ADCS) by Will Schroeder and Lee Christensen. A common denominator is the use or misuse of the New Technology LAN Manager (NTLM) authentication protocol.

Attackers try to force NLTM authentication of a user or machine in order to abuse it for their own purposes. This technique is called Coerced Authentication or Forced Authentication. This can be achieved via direct requests or indirectly via machine-in-the-middle attacks (MITM) as well as ARP or multicast poisoning. The tool Responder by Laurent Gaffie is a popular and reliable tool for the latter attack technique. Attackers can use the forced NTLM authentication to crack credentials from the challenge response hashes or relay them to another system. An overview of NTLM relay attacks is shown in Charlie Bromberg’s mind map and the attack techniques are documented on the NTLM relay attacks page.

NTLM poses a security risk and should be disabled.

Introduction

The NTLM protocol is a challenge response authentication and uses different protocols for this. The term NTLM should not be mistaken for the hash function of Windows. Windows stores the hash of passwords locally in the SAM database and on domain controllers in the file ntds.dit and uses the hash function NTHash, which uses the algorithm MD4(UTF-16-LE(password)). NTHash is often incorrectly referred as NTLM.

NTLM uses the following protocols:

• LAN Manager Version 1 (LM)
• LAN Manager Version 2 (LMv2)
• NT LAN Manager Version 1 (NTLMv1 or Net-NTLMv1)
• NT LAN Manager Version 2 (NTLMv2 or Net-NTLMv2)
• NT LAN Manager 2 – Session Security

The functionality of the protocols is explained in detail in the article The NTLM Authentication Protocol and Security Support Provider. NTLMv2 is supported since Windows NT 4.0 SP4. The Kerberos protocol has been the primary and preferred authentication method in an Active Directory infrastructure since Windows 2000. However, NTLM is still active by default in Windows 10 and Windows Server 2019 for compatibility reasons. NTLM is used for authentication if no AD infrastructure is available, authentication with systems outside the domain takes place, systems are addressed via the IP address instead of hostnames or DNS, or no domain controller can be reached using Kerberos.

Disable NTLM

Backward compatibility and the use as fallback protocol makes it difficult to disable NTLM. Therefore, outages could occur if NTLM is disabled on all systems without any prior investigation. The “Microsoft veteran” and principal program manager in the area of Windows Server Engineering Ned Pyle already wrote back in 2009 in the TechNet article NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7 that blocking NTLM is not easy and requires an analysis and longer preparation.

Audit of NTLM

There are three group policies under the path Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, and the recommended setting to perform an analysis is:

The Audit NTLM authentication in this domain policy should only be applied to domain controllers, the other two can be applied to all systems. The NTLM audit events are logged to the event log Applications And Services Logs\Microsoft\Windows\NTLM\Operational.

Analysis

All events are ideally collected and analysed in a central logging/monitoring infrastructure. For example with Splunk, the following entry can be added to the SplunkForwarder configuration in inputs.conf:

[WinEvent Log://Microsoft-Windows-NTLM/Operational]
checkpointInterval = 5
current_only = 0
disabled = 0
start_from = oldest

The objective is to identify which systems use NTLM for authentication. NTLM is used in various protocols such as HTTP or SMB. The following Splunk query can be used to generate a list of IP addresses of target servers:

source="winEvent Log*" "LogName=Microsoft-Windows-NTLM/Operational"
| rex field=_raw "(?i)target\sserver:\s(?<IP>.*)" 
| dedup IP
| table IP

This list is a starting point for analysing which systems and applications use NTLM. For this purpose, the log data of clients and servers are correlated. In events with the event id 8003, the incoming authentication request is logged on the server. The user, domain and workstation can be extracted from this message. At the same time, the outgoing connection is logged on the client under the event id 8001. In the case of applications that do not communicate over SMB, the target server, and the process (Name of client process) can be identified.

In the following example, the user jdoe accesses a web application with activated Windows Authentication via IP address:

Message=NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
Target server: HTTP/192.168.1.112
Supplied user: jdoe
Supplied domain: TEST
PID of client process: 5780
Name of client process: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
LUID of client process: 0xBE4B5
User identity of client process: jdoe
Domain name of user identity of client process: TEST

The client client01 establishes a connection to the web server web01 via the URL https://192.168.1.112. Authentication is necessary for access and since the IP address is used, the web server and browser agree on the NTLM protocol. The user enters his domain credentials, the web server accepts it and validates the credentials with the help of a domain controller. Based on the analysis of the logs, it is evident that an outgoing NTLM connection to 192.168.1.112 is established on the client (event id 8001), the NTLM connection is received on the web server (event id 8002) and the web server forwards the credentials for validation to a DC (event id 8004).

The audit phase should be continued over several months. Within this phase, log data can already be analysed and possible misconfigurations corrected. An example of a misconfiguration is that an IP address has been configured for access instead of the NetBIOS server name or the fully qualified domain name (FQDN).

If the service or application does only support NTLM, it must be registered as exception. However, the objective is to have as few exceptions as possible.

At the end of the audit phase, an exception list should be available containing all systems that receive incoming NTLM connections and from which systems access must be possible. The completeness of the list is essential for the functionality of the infrastructure. As soon as NTLM is blocked and a system is not on the list, this application will no longer work.

Blocking NTLM

When NTLM is blocked, it is not completely disabled on a system because the local login process still uses NTLM. Even if NTLM is blocked, logging in with a local account is still possible.

There are three group policies for blocking NTLM under the path Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, and the settings to block NTLM completely are:

The settings Incoming NTLM traffic and Outgoing NTLM traffic to remote servers can be configured on all systems. The setting NTLM authentication in this domain is relevant for domain controllers.

If exceptions for blocking are necessary, the settings are available under the path Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options:

• Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication
• Network security: Restrict NTLM: Add server exceptions in this domain

The setting Add remote server exceptions for NTLM authentication defines which systems a client can still authenticate to via NTLM. The NetBIOS name, FQDN and IP address are accepted as valid values. The list of systems that continue to accept NTLM requests and are within the domain must be included in the Add server exceptions in this domain setting. This setting is maintained on domain controllers.

Example

NTLM is to be blocked in this environment. Incoming and outgoing NTLM connections can be blocked on all systems of a domain. On the domain controllers, the use of NTLM within the domain is additionally deactivated. An exception list is also maintained on the domain controllers. In addition, outgoing NTLM connections must be declared as exceptions on the involved systems. This list should be divided among the requirements and not distributed as a complete list.

A web application that uses an IIS web server with Windows Authentication was specified as an exception. The following systems are involved for this exception. The DC dc01 is an example for all domain controllers in the domain.

The restriction Outgoing NTLM traffic to remote servers only affects client01 in this example, as the outgoing NTLM connection to web01 is blocked there (Event ID 4001). Therefore, the IP address of web01 is included in the list of the setting Add remote server exceptions for NTLM authentication. Ideally, the exception list is only assigned to clients that need access to the web application.

Due to the setting Incoming NTLM traffic being set to the value Deny all accounts, the NTLM connection from client01 to web01 is blocked on the web server (Event ID 4002). According to the documentation of Microsoft, the exception list Add server exceptions in this domain can be used for Incoming NTLM traffic. However, this exception did not work in the test environment, so the setting Incoming NTLM traffic had to be configured to the value Allow all on web01.

To disable NTLM within the domain, the setting NTLM authentication in this domain is set to the value Deny all. The NTLM authentication request of the web server will be blocked on the DC (Event ID 4004). Therefore, web01 is added to the list of the Add server exceptions in this domain setting. In the test environment, the NetBIOS server name had to be configured; if the FQDN was used, the exception did not work.

The configuration for the systems including exceptions is as follows:

Conclusion

The authentication protocol NTLM is outdated and insecure and was replaced by Kerberos. Since then, NTLM has continued to be supported for compatibility reasons and is still active in the current Windows version. NTLM is misused for many attacks and makes it easier for attackers to compromise an Active Directory infrastructure.

The task of blocking NTLM must be implemented in several steps. First, it must be determined which systems and services still use NTLM. The audit settings should be enabled, and the logs analysed over months with the goal of finding incorrect configurations and reducing NTLM use. For systems that continue to depend on NTLM, exception lists can be documented and configured. Afterwards, NTLM can be disabled within the domain.

The hurdle to block NTLM is high, it is not an easy task to achieve and there is a risk of failures. But given the many attacks and vulnerabilities in NTLM, the security benefit is so substantial that it is worth tackling the project. It is time to say goodbye to NTLM. Farewell.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• http://davenport.sourceforge.net/ntlm.html
• https://attack.mitre.org/techniques/T1187/
• https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html
• https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic
• https://g-laurent.blogspot.com/
• https://github.com/lgandx/Responder
• https://github.com/topotam/PetitPotam
• https://specterops.io/assets/resources/Certified_Pre-Owned.pdf
• https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/ntlm-blocking-and-you-application-analysis-and-auditing/ba-p/397191
• https://twitter.com/NerdPyle
• https://twitter.com/_nwodtuhs
• https://twitter.com/harmj0y
• https://twitter.com/orange_8361
• https://twitter.com/tifkin_
• https://twitter.com/topotam77
• https://vuldb.com/?id.170592
• https://vuldb.com/?id.170595
• https://vuldb.com/?id.174834
• https://vuldb.com/?id.178577
• https://vuldb.com/?id.178612
• https://vuldb.com/?id.179650
• https://www.thehacker.recipes/ad-ds/movement/ntlm/relay