IT Connect

Information technology tools and resources at the UW

Using Get-NtlmV1LogonEvents.ps1

A PowerShell script is available to get an abbreviated set of info about NTLMv1 logon events.

The PowerShell script is available from: https://itconnect.uw.edu/wp-content/uploads/2016/04/Get-NtlmV1LogonEvents.zip

Get-NtlmV1LogonEvents.ps1 queries the Windows Security eventlog for NTLMv1 logons in eventid 4624. The number of events returned is configurable. Whether null session logon events are included is configurable. It can be run against all domain controllers, a remote member server, or the localhost. If used against anything other than the localhost, WinRM is required to be listening on those remote hosts. If used against DCs, the ActiveDirectory PS module is required. The .Net 3.5 framework is required.

Note: If you can’t run this PS script, you can pull the XML filter from the script and use eventvwr.exe with that XML filter instead–that negates any automation you might achieve, but it’s a workaround.

 

Example usage and other information is available via the standard PowerShell comment-based help system:

      get-help .\Get-NtlmV1LogonEvents.ps1

 

———————————

Finding NTLMv1 events and Using the Powershell script

 

The NTLMv1 logon events will show up in your security event log. They are eventid=4624 with a body that include the phrase “LmPackageName=NTLM V1”. https://itconnect.uw.edu/wp-content/uploads/2016/04/Get-NtlmV1LogonEvents.zip has a powershell script that will help you easily parse through your security event log for NTLMv1 logon events. I typically do this to use it:

 

1.            Open PowerShell with Administrator elevation

2.            Run: “.\Get-NtlmV1LogonEvents.ps1 -NullSession $false -NumEvents 100000000 | out-file server-date.txt”

 

That runs the script, ignores null session events (computer identities), limits the number of results to a really large number you’ll never see, and outputs the results to a text file with the servername and date (so you don’t forget where it came from and when). You can, of course, run the script without piping it to a text file—and then the output just goes to the PS window.

The output of the script looks like this:

—————————

Querying security log for NTLM V1 events (ID 4624) on localhost

 

Time                                    UserName                                WorkstationName

—-                                    ——–                                —————

7/29/2014 9:19 AM                       barkills                                   POT-FS2

7/29/2014 9:18 AM                       barkills                                   POT-FS2

7/29/2014 9:17 AM                       barkills                                   POT-FS2

—————————–

The timestamp allows you to go back into the security event log and easily find the event in question, if for some reason, you want to look at any other details in the event. I generally don’t find any other details useful, but occasionally I’ll do this with really odd results.

 

If you aren’t really familiar with powershell, then in general, there is one problem you might run into:

 

The script execution policy on your computer may prevent the script from being executed. You can fix that using: “Set-executionpolicy RemoteSigned” in the powershell window. This will allow scripts that come from elsewhere (like ours) to be run if they are signed. This is generally a pretty safe configuration. And yes, we have signed our script. (smile)