- What’s your ENow AppGov Score? Free Microsoft Entra ID app security assessment - Thu, Nov 30 2023
- Docker logs tail: Troubleshoot Docker containers with real-time logging - Wed, Sep 13 2023
- dsregcmd: Troubleshoot and manage Azure Active Directory (Microsoft Entra ID) joined devices - Thu, Aug 31 2023
Attackers commonly try to compromise critical networks with authentication-related attacks. These can include password attacks, phishing, and others. However, they can also exploit weak authentication protocols to compromise environments. The NTLMv1 and NTLMv2 authentication protocols have been used in production environments for decades. As a result, NTLM has serious security vulnerabilities that businesses need to consider.
Security considerations of NTLMv1 and NTLMv2
The problem with NTLM is that while it requires a password, it uses very dated cryptography to create the hash. In addition, NTLM is a single sign-on (SSO) protocol that relies on a challenge–response mechanism. When combined with weak passwords, NTLM becomes a vulnerable target for attack.
Despite known vulnerabilities and Microsoft replacing NTLM with Kerberos authentication as part of Active Directory Domain Services (AD DS), NTLM is still widely deployed in many environments for compatibility reasons.
One challenge for many IT admins is understanding which apps, servers, and clients may still be using NTLM authentication.
NTLM auditing using Group Policy
Microsoft has introduced a group policy that allows admins to audit NTLM authentication in the Active Directory domain. In addition, it enables visibility into NTLM-based authentication requests to domain controllers.
The Group Policy setting is the Network Security: Restrict NTLM: Audit NTLM authentication in this domain setting. It is found here:
- Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
By default, it is configured as Not defined.
Viewing the Audit NTLM authentication in this domain policy
Although the Group Policy is labeled "Restrict" when the policy setting is defined on the domain controller, only authentication traffic to that domain controller will be logged.
Below are the possible settings for enabling the Audit NTLM authentication policy in the domain:
- Enable for domain accounts to domain servers—The domain controller will log events for NTLM authentication logon attempts for domain accounts to domain servers
- Enable for domain accounts—The domain controller will log events for NTLM authentication logon attempts that use domain accounts
- Enable for domain servers—The domain controller will log events for NTLM authentication requests to all servers in the domain
- Enable all—The domain controller will log events for NTLM pass-through authentication requests from its servers and for its accounts
The Audit events related to NTLM are recorded on this computer in the NTLMBlock Log located under Applications and Services Log > Microsoft > Windows > Security-NTLM.
In PowerShell, you can look up events using this command:
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational"
Any entries in the above log will allow auditing of the applications and servers involved with log entries.
NTLMv1 auditing by enabling Logon Success Auditing
You can also audit which applications use NTLMv1 specifically by enabling Logon Success Auditing on your domain controller under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy. Then look for the auditing Event 4624. This particular event ID contains information about NTLM.
Audit logon success using Group Policy
Below is an example of information found in Event ID 4624. Note the Package Name section.
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): NTLM V1
Key Length: 128
Aggregating NTLM logs using Windows Event Forwarding
You can consider using Windows Event Forwarding to gather all relevant NTLM logs to a single location. You can pull or push logs to the event collector server. Below is an example of creating a Windows Event Forwarding subscription to query the security logs for Event 4624.
Windows Event Forwarding for aggregating NTLM logs
Restricting and blocking NTLM authentication in the domain
Once the entries are reviewed and steps are taken to ensure applications using NTLM have been migrated to more secure protocols (like Kerberos), the next step is to block the use of NTLM across the domain. To do so, we can use the related Group Policy setting Network Security: Restrict NTLM: NTLM authentication in this domain.
It mirrors the options for the policy to audit NTLM authentication requests. However, this time, they will not only be logged, but logon will be blocked.
As you can see below, the policy setting comes with a warning: "Modifying this setting may affect compatibility with clients, services, and applications." However, once we have done our homework reviewing the audit log after the NTLM audit, it should be safe to enable the below setting once all NTLM-reliant applications have been migrated or upgraded.
Restrict NTLM use in the domain policy setting
Wrapping up
Businesses need to eliminate insecure authentication protocols and bolster their passwords and other authentication security, as these are areas attackers commonly use to compromise environments.
Unfortunately, NTLM is still found across many environments with legacy applications and clients. Using NTLM auditing and restriction Group Policies helps admins know the source of NTLM authentication requests and also provides an easy way to restrict the use of this legacy protocol across the domain.
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
