NTLMv2+

Overview:

What is NTLM?

  • Windows New Technology LAN Manager (NTLM) is a suite of security protocols offered by Microsoft to authenticate users’ identity and protect the integrity and confidentiality of their activity. At its core, NTLM is a single sign on (SSO) tool that relies on a challenge-response protocol to confirm the user without requiring them to submit a password.

    Despite known vulnerabilities, NTLM remains widely deployed even on new systems in order to maintain compatibility with legacy clients and servers. While NTLM is still supported by Microsoft, it has been replaced by Kerberos as the default authentication protocol in Windows 2000 and subsequent Active Directory (AD) domains.

  • NTLM has two versions – NTLMv1 and NTLMv2. NTLMv2  is supposed to offer better security than its previous version, and to some extent it does provides better defense against relay and brute force attacks, but does not completely block them.

  • NTLMv2 follows a similar flow to NTLMv1 with a key difference: in step 3, the client includes a timestamp and username along with the nonce, which helps mitigate offline relay attacks. However, NTLMv2 still shares some vulnerabilities with NTLMv1 and doesn’t offer a complete solution. Additionally, NTLMv2 uses a variable-length challenge instead of NTLMv1’s 16-byte random number challenge.

  • The NTLM cryptography scheme is relatively weak, making it relatively easy to crack hashes and derive plaintext passwords. It’s easy enough for standard hardware to be able to crack an 8-character password in less than a day. This is for three main reasons:

    1. The password hash is based on MD4, which is relatively weak.

    2. The hash is saved unsalted in a machine’s memory before it is salted and sent over the wire.

    3. A user must respond to a challenge from the target, which exposes the password to offline cracking. This prevents offline Relay attacks.

  • This flaw exposes the protocol to man-in-the-middle (MITM) attacks due to one-way authentication, where the client doesn’t validate the server’s identity. A malicious actor can impersonate the server and send malicious data to the client. The most severe risk associated with NTLM is the exposure of servers in Active Directory environments to NTLM relay and remote code execution attacks. Other NTLM flaws are minor in comparison. In such attacks, the attacker hijacks the client-server connection and spreads laterally through the system using the user’s credentials. Despite Microsoft’s attempts to develop mitigation techniques, all patches have been compromised. No NTLM version provides a solution, leaving all NTLM users vulnerable to devastating attacks.

  • Risks of Force NTLMv2 or Higher NOT being implemented?:

    • 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

Potential implementation impacts to watch out for:

  • This can break authentication if you implement without understanding how the machines in the domain are currently authenticating. Make sure to read the Implementation Tip section to ensure you find what authentication method(s) are in place, then resolving that before enforcing this hardening tactic.

Technical Deployment:

Creating a GPO for Force NTLMv2 or Higher:

  • 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.

Implementation Tip

  1. 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.

  2. The Group Policy setting is the Network Security: Restrict NTLM: Audit NTLM authentication in this domain setting. It is found here:

    1. Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

    2. By default, it is configured as Not defined.

  3. 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.

  4. Below are the possible settings for enabling the Audit NTLM authentication policy in the domain:

    1. Enable for domain accounts to domain servers—The domain controller will log events for NTLM authentication logon attempts for domain accounts to domain servers

    2. Enable for domain accounts—The domain controller will log events for NTLM authentication logon attempts that use domain accounts

    3. Enable for domain servers—The domain controller will log events for NTLM authentication requests to all servers in the domain

    4. Enable all—The domain controller will log events for NTLM pass-through authentication requests from its servers and for its accounts

  5. 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.

  6. In PowerShell, you can look up events using this command:

    1. Get-WinEvent -LogName “Microsoft-Windows-NTLM/Operational”

    2. Any entries in the above log will allow auditing of the applications and servers involved with log entries.

  7. Audit for NTLMv1 before enabling to find out if this will break anything in your environment. To audit which applications use NTLMv1 enable via GPO:

    • Logon Success Auditing on your domain controller under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy.

  8. Then look for the auditing Event 4624. This particular event ID contains information about NTLM.

  9. 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

  10. If you have a SIEM in place, you can collect, the aggregate these to only view the ones that have a Package Name of NTLM V1. This should give you visibility into how many devices are utilizing NTLM V1.