Share via

Security Monitoring: Using SCOM to detect NTLMv1 and LanManager Authentication Types

  • Article

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

One of the big changes in the next release of the Security Monitoring management pack will be reports designed to let administrators if they are using older protocols in their environments. It goes without saying that many older protocols are often full of vulnerabilities. As well, they tend to be on by default due to concerns about what might break should they be shut off.

Recently, a colleague of mine wrote a nice article in regards to these protocols. This post will concentrate a bit more on the auditing aspect of the article. What we have done in the security monitoring MP is to create two collection rules targeting authentication on Windows Servers. When I tested this in my lab, I did not get many events on DCs. I did, however, see NTLM v1 events in the security log of each server. These will look for the following conditions:

NTLMv1

  • Event ID = 4624
  • Parameter 11 (Authentication Package) = NTLM
  • Parameter 15 = NTLM V1 (note that the friendly view name differs from the name in the event description. The friendly view name is LMPackageName.)

LanMan

  • Event ID = 4624
  • Parameter 11 (Authentication Package) = NTLM
  • Parameter 15 = LM (note that the friendly view name differs from the name in the event description. The friendly view name is LMPackageName.)

The reports will tell us where this access is taking place. This should give administrators a better picture to the types of activities going on in their environments.

Here is a screenshot of the NTLM V1 report:

image

The Computer name listed is the computer receiving the authentication using legacy protocols. This should provide an admin a very easy way to identify which systems are accepting a legacy protocol. This will not tell you the source, though that information is easy to find in the logs themselves. Filter the security log on the offending machine by event 4624. From there, a simple find for “NTLM V1” or “LM” should start yielding results. The workstation name will show who is initiating the connection. In this case, my DC was the culprit.

image

Feel free to add comments or reach out to me on LinkedIn.

Comments

  • Anonymous
    April 24, 2018
    Thank you for this contribution, I was able to download your MP from this url https://gallery.technet.microsoft.com/Security-Management-Pack-fee2c134 but I think it's outdated because when I installed it I could not find the report you are referencing in your screenshot (Security.Monitoring.NTLMv1ConnectionReport)Can you please share the latest version? I'm really interested in this report.
    • Anonymous
      April 27, 2018
      That report is in the new release that I'll be releasing next week. If you want me to get you an advanced copy, hit me up on my linked in profile and send me an email address via private message. I'll give you access to the share that it's currently hosted.