Controlling and restricting NTLM usage. Part II. Audit and Detection

This is the second part of this blog post:

From the audit and detection perspective, it’s possible to use multiple approaches, better – in a combination.

1. Initial audit and detection

Starting from Windows Server 2008 it’s possible to audit NTLM logon events on domain controllers. There’s an event 4624(S) that provides an ability to detect the version of NTLM being used. This gives us an easy way to list clients that are actively using non-secure NTLMv1 and LM protocols, and make sure that they will be switched to NTLMv2.

Package Name (NTLM only) gives us all necessary information about NTLM version being used.

You can filter out all events related to a specific NTLM version:

You could extract collect and process all this events by using your favorite scripting techniques.

2. Advanced NTLM detection

If there’s such a perfect event 4624, providing us all necessary details, why do we need something else?
The short explanation here will be that (unfortunately!) this event is NOT being logged for all NTLM authentication events that actually happen on a specific DC. You can easily check this statement, just create a lab environment:
– A single DC on Windows Server 2016 (or older version – doesn’t matter)
– A domain-joined IIS server with an application set up for using Windows Authentication (NTLM)
– a standalone Windows 10 computer (non-domain joined computer)

When you have this environment ready, try to access the IIS site from your non-domain joined test workstation, and authenticate using domain credentials:

After that try to search for 4624(s) on your test domain controller. Surprise! Your DC has authenticated a user using NTLM, but your security log on DC has nothing about it.

To catch these kind of authentication events you need something else, and there’s an approach that might be used to do this:

  • Enable ETW logging for NTLM (MSV1_0) on domain controllers.
  • Perform data capturing for several hours.
  • Process the collected log and extract information about LM Package Name for authentication.


I’ve published a simple toolkit available for automating these tasks. The toolkit consists of two scripts:

  • This is a script that enables ETW logging for NTLM authentication, waits for a specified period of time, collects the resulting logs and disable ETW logging
  • This script processes the collected ETW logs and extract all events of LM/NTLM/NTLMv2 protocols usage in a csv file.


In the resulting report you are able to get some information about:

  • Username of the user that authenticates using LM/NTLMv1.
  • Workstation where the authentication happened.
  • Additional information about NTLM protocol being used (protocol version).


Feel free to evaluate this toolkit within your environment (test first, of course).
You can download it from GitHub:

3. PDCE trick for LM/NTLMv1 detection

If (for some reason) you’re not happy with the previous two audit and detection techniques, you might want to consider one more approach for catching LM and NTLMv1.

To do this trick you’ll need to configure all DC’s in a domain to LanManagerAuthenticationLevel = 4 (accept just NTLMv1 and NTLMv2), and PDCE – to LanManagerAuthenticationLevel = 3 (accept LM, NTLMv1 and NTLMv2).

If a client uses LM, there will be 4776 failure event on a DC, and 4776 success event on the PDCE. We utilize fallback to PDCE in “password change” verification scenario (immediate RPC call from DC to PDCE). Of course, in this case you will need to correlate 4776 events from DCs and PDCE, some automated tools like ACS might be used here.

The key point here is to isolate PDCE from the clients to minimize amount of 4776 events in PDCE security event log. To do this you might want to put it in a dedicated AD site.

4. “Network Security: Restrict NTLM: Audit NTLM…” policies

It worth to say that these policies are simply useless in case you want to get rid of LM and NTLMv1 only and keep NTLMv2 alive. The events being generated have no information about LM Package (i.e. NTLM version), so you simply can’t distinguish between “bad” LM/NTLMv1 and “not-so-bad” NTLMv2. All you can see is that clients are using some “generic” NTLM.


Step-by-step recommendations for eradicating LM/NTLMv1.

To prevent the usage of not secure protocols it’s recommended to eventually switch Network security: LAN Manager authentication level on domain controllers to “Send NTLMv2 response only. Refuse LM & NTLM”. This setting is within Microsoft’s security baselines for all operating systems and roles, all other standards and regulators support this recommendation.

As impact of just enabling this setting is highly probable, it’s better to have a gradual approach:
1. Employ necessary measures for switching clients and applications to NTLMv2. For Windows clients, this could be done by applying appropriate group policies settings. For applications (including 3rd-party applications) that are known to be authenticating users using old protocols (LM and NTLM), necessary changes should be made to switch them to NTLMv2 or Kerberos. Start with small groups of clients, then extend coverage and get rid of “basic” LM and NTLMv1 being send by clients.
2. After making sure that all obvious steps for switching to NTLMv2 have been undertaken on clients, you might want to further investigate the remaining usage of LM and NTLM within domain infrastructure. This could be done by consequently employing Initial and Advanced detection techniques described in this post. Start with Initial detection, then, if necessary, employ more advanced techniques.
3. At this point some additional hosts/application/users that are still performing authentication by using old protocols will be identified. Make sure that you undertake necessary steps to bring the authentication for these hosts/applications to NTLMv2 or Kerberos.
4. Repeat the step 2 again to make sure that there’s no evidence of LM and NTLMv1 usage anymore.
5. Enable hardened setting for the policy Network security: LAN Manager authentication level by setting it to “Send NTLMv2 response only. Refuse LM & NTLM”. Remediate authentication issues if there are any. The number of such issues shouldn’t be too high.

Share in comments, how this process is going within your environment.
And happy old protocols eradication!

Comments 2

  • Hi Nikolay

    I have a scenario where we need to detect all NTLM and thus I wanted to try your powershell script. However I dont get any results when I run the parser scripts. Output is 0 bytes. My output looks like this , so I think , I have a problem with the tmf files ?

    Unknown( 12): GUID=cb96f7e3-c126-ec9a-4022-a1f82ee482e3 (No Format Information found).
    Unknown( 12): GUID=cb96f7e3-c126-ec9a-4022-a1f82ee482e3 (No Format Information found).
    Unknown( 12): GUID=cb96f7e3-c126-ec9a-4022-a1f82ee482e3 (No Format Information found).
    Unknown( 20): GUID=35b64fe5-8a72-e3ed-9b57-4c1cf039e40f (No Format Information found).
    Unknown( 85): GUID=0f89ea57-141a-3e49-8d0f-587c9d8ed5ea (No Format Information found).
    Unknown( 87): GUID=0f89ea57-141a-3e49-8d0f-587c9d8ed5ea (No Format Information found).
    Unknown( 12): GUID=cb96f7e3-c126-ec9a-4022-a1f82ee482e3 (No Format Information found).
    Unknown( 107): GUID=8488de7e-0c19-e862-8ea6-1e71da76c484 (No Format Information found).

    I ran the trace on a Windows 2008 R2 DC.

    any ideas ?


Leave a Reply

Your email address will not be published. Required fields are marked *