Introduction of CVSS v4.0
NTLM poses a security risk and should be disabled
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.
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:
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.
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.
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:
|Network security: Restrict NTLM: Audit Incoming NTLM Traffic||Enable auditing for all accounts|
|Network security: Restrict NTLM: Audit NTLM authentication in this domain||Enable all|
|Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers||Audit all|
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.
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
[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
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
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.
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:
|Network security: Restrict NTLM: Incoming NTLM traffic||Deny all accounts|
|Network security: Restrict NTLM: NTLM authentication in this domain||Deny all|
|Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers||Deny all|
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:
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.
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
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
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:
|dc01||Incoming NTLM traffic||Deny all accounts|
|dc01||NTLM authentication in this domain||Deny all|
|dc01||Outgoing NTLM traffic to remote servers||Deny all|
|dc01||Add server exceptions in this domain||web01|
|web01||Incoming NTLM traffic||Allow All|
|web01||Outgoing NTLM traffic to remote servers||Deny all|
|client01||Incoming NTLM traffic||Deny all accounts|
|client01||Outgoing NTLM traffic to remote servers||Deny all|
|client01||Add remote server exceptions for NTLM authentication||192.168.1.112|
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here