Active Directory Domain Services (AD DS) offers many ways to integrate applications and services.
Before Windows 2000 Server and Active Directory, in the Windows NT era when servers were beige and server racks from wood, authentication on networks was NTLM-based. Windows 2000 Server introduced Microsoft’s Kerberos implementation, but even today NTLM continues to be used.
Kerberos is on one side of the spectrum, where NTLM v1 is completely on the other side. NTLM v1 authentication should be avoided.
Why NTLMv1 is bad
Typically, on networks you want to avoid NTLMv1, because:
- It uses weak encryption algorithms (MD4/DES). Because of these algorithms, the plain text password for the device and/or user can be cracked.
- It doesn’t offer mutual authentication. If NTLMv1 data is intercepted, it can be relayed, through a Meddler-in-the-Middle (MITM) attack.
- It works based on a password hash that is stored in the LSA service. This hash can be extracted and reused using readily available tools, like Mimikatz. This type of attack is typically referred to as a Pass-the-Hash attack.
When comparing NTLMv2 to NTLMv1, NTLMv2 uses much stronger encryption algorithms (but not AES or SHA-256) and protection against the relay and brute force attacks that are possible with NTLMv1.
How to detect NTLMv1 authentications
Perform these steps to detect NTLMv1 authentications:
Before you begin
Sign in with an account that has sufficient permissions to manage Group Policy for the scope of the hosts you want to detect NTLMv1 authentications on, with an account that has local administrator privileges (on domain-joined hosts) or with an account that has a membership to the Domain Admins, Enterprise Admins, Administrators or Server Operators group (on Domain Controllers with default settings).
Make sure that the Security logs on any hosts you want to detect NTLMv1 authentications on, allows for a sufficient log size to view NTLMv1 authentication-based log items for the desired time frame you want to detect authentications for. By default, log items in the Security log are overwritten when the log reaches the maximum allowed size for the log. The default size that is allowed on recent Windows Server versions is 20480 KB.
When investigating (and eventually limiting the use of) NTLMv1 authentication, aim to work from the outside in: First identify any Windows-based devices used by end-user that have incoming NTLMv1 authentication and remediate them. Then, turn to domain-joined Windows Server-based hosts and finally turn to the Domain Controllers. Work together with admins for trusted Active Directory-environments to identify any NTLM authentications people with user accounts in your Active Directory domain/forest perform in their Active Directory domain/forest.
Enable NTLM auditing
To be able to detect NTLMv1 authentications, we need to enable NTLM auditing. NTLM auditing is not enabled by default. It needs to be turned on.
Afterwards, it can be turned off again. As NTLM auditing has a performance impact on systems, avoid auditing and logging for investigations you don’t or no longer intend to perform.
Through the registry
On individual hosts, NTLM auditing can be enabled through the registry. Run the following line of Windows PowerShell in an elevated PowerShell window to do so:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\" -Name AuditReceivingNTLMTraffic -Value 1 -Type DWORD
Through Group Policy
NTLM auditing can also be enabled through two specific Group policy settings. Perform the following steps to do so using a new Group Policy object (GPO):
- Sign in interactively to a domain-joined Windows-based host that has the Group Policy Management feature installed.
- Open Group Policy Magement (gpmc.msc).
- In the left navigation pane, expand the Forest node.
- Expand the Domains node, and then navigate to the domain where you want to audit NTLM authentications.
- Expand the domain name.
- Right-click the Group Policy Objects node and select New from the menu.
The New GPO pop-up window appears.
- In the New GPO pop-up window, fill in the name: field for the GPO.
Make sure that you don't select Source starter GPO.
- Click OK to create the GPO.
- In the left navigation pane, right-click the newly created GPO and select Edit… from the menu. The Group Policy Management Editor window appears.
- In the left navigation pane of the Group Policy Management Editor window, expand Computer Configuration, then Windows Settings, Security Settings, Local Policies and finally Security Options.
- In the main pane, double-click the Network Security: Restrict NTLM: Audit Incoming NTLM Traffic policy setting. The Network Security: Restrict NTLM: Audit Incoming NTLM Traffic window appears.
- From the drop-down list, select Enable auditing for domain accounts.
- Click OK to save the setting.
- When auditing NTLM authentications on Domain Controllers, double-click the Network Security: Restrict NTLM: Audit NTLM
authentication in this domain policy setting, too The Network
Security: Restrict NTLM: Audit NTLM authentication in this domain
- From the drop-down list, select Enable
- Click OK to save the setting.
- Close the Group Policy Management Editor window.
- In the Group Policy Management window, right-click the organizational unit (OU) where devices exist on which you want to audit NTLM authentications
- Right-click the OU and select Link an Existing GPO… from the menu.
The Select GPO window appears.
- In the Select GPO window, select the previously created GPO from the Group Policy objects: list.
- Click OK to link the GPO.
Retrieve NTLMv1 authentications
With NTLM auditing enabled, Events with Event ID 4624 are logged in the System log. Use the following lines of Windows PowerShell in an elevated PowerShell window on a Windows-based host to retrieve them:
$Events = Get-WinEvent -Logname security -FilterXPath "Event[System[(EventID=4624)]]and Event[EventData[Data[@Name='LmPackageName']='NTLM V1']]" | Select-Object `
$Events | Out-GridView
Why NTLM is still used
There are many scenarios in which NTLM is still used as the authentication protocol instead of Kerberos:
- When a Windows-based host is addressed using its IP address or a CNAME instead of its short name or fully-qualified domain name (FQDN).
- When a workgroup-joined Windows-based host is addressed.
- When a domain-joined Windows-based host is addressed and you sign in with an account that is local to the host, instead of a domain account.
- When a domain-joined Windows-based host in a different Active Directory forest is addressed and the forest trust type is a legacy NTLM trust.
- When a domain-joined Windows-based host is addressed over a filtered networking connection that allows NTLM but not Kerberos traffic.
- By default, when a domain-joined Windows-based fail-over cluster node is addressed and the host runs Windows Server 2016, or an earlier Windows Server version.
- When an application or service is addressed from the local host.
- When a SQL Server database on a domain-joined Windows-based host is addressed through named pipes.
- When a service on a domain-joined Windows-based host is configured with one or more incorrect or missing Service Principal Names (SPNs) for the domain account that runs the service.
- When an application or service on a domain-joined Windows-based host is addressed and the application (or service) is configured to use NTLM security package instead of the negotiate security package. Negotiate defaults to Kerberos, but offers fallback to NTLM in case any of the above scenarios applies.
These situations can all reasonably be migrated away from or avoided with proper administration processes.
When a system offers NTLM, an attacker can downgrade any authentications to this protocol through the Negotiate security package. It should be removed.
Getting rid of legacy and inactive protocols and objects should be a large proponent of the work an Active Directory admin does. Removing NTLMv1 authentications from the network should be one of the first things to be performed.