Simple (better) local check; Monitor windows event logs\ID's

We created a local powershell check which (better) monitors the windows event ID’s better then the default options in check mk.

We have about ~1400 hosts in our check mk enviorment and the check_mk.user.yml doesn’t meet out expectations and neither does the default windows event rules.

This is the powershell script and you need to place it inside the folder; C:\ProgramData\checkmk\agent\local

You can customize the lines 26 and below or add more (after line 25; #add services below)
In this specific configuration we check for event in the log that appear for the CVE-2022-38023 - Security Update Guide - Microsoft - Netlogon RPC Elevation of Privilege Vulnerability and for CVE-2022-37967 - Security Update Guide - Microsoft - Windows Kerberos Elevation of Privilege Vulnerability

Good luck :wink:

Function GetEvents {
	param(
		[Parameter(Mandatory)]
		[string]$logname,
		[Parameter(Mandatory)]
		[int]$eventid,
		[Parameter(Mandatory)]
		[int]$lookuphours,
		[Parameter(Mandatory)]
		[string]$servicename,		
		[Parameter(Mandatory)]
		[int]$threshold_warning,		
		[Parameter(Mandatory)]
		[int]$threshold_critical,
        [Parameter()]
		[string]$description
	)
	$time = [datetime]::Now.AddHours(-$lookuphours)
	$events = Get-WinEvent -FilterHashtable @{ LogName=$logname; ID=$eventid; StartTime=$time;} -ErrorAction SilentlyContinue
	$eventmeasure = $events | measure
	$eventcount = $eventmeasure.Count
	return "P $servicename count=$eventcount;$threshold_warning;$threshold_critical $description"
}
"<<<local>>>"
#add services below
GetEvents -logname "System" -eventid 5838 -lookuphours 24 -servicename "CVE-2022-38023_5838" -threshold_warning 1 -threshold_critical 2 -description "The Netlogon service encountered a client using RPC signing instead of RPC sealing"
GetEvents -logname "System" -eventid 5839 -lookuphours 24 -servicename "CVE-2022-38023_5839" -threshold_warning 1 -threshold_critical 2 -description "The Netlogon service encountered a trust using RPC signing instead of RPC sealing"
GetEvents -logname "System" -eventid 5840 -lookuphours 24 -servicename "CVE-2022-38023_5840" -threshold_warning 1 -threshold_critical 2 -description "The Netlogon service created a secure channel with a client with RC4"
GetEvents -logname "System" -eventid 5841 -lookuphours 24 -servicename "CVE-2022-38023_5841" -threshold_warning 1 -threshold_critical 2 -description "The Netlogon service denied a client using RC4 due to the RejectMd5Clients setting"

GetEvents -logname "System" -eventid 43 -lookuphours 24 -servicename "CVE-2022-37967-43" -threshold_warning 1 -threshold_critical 2 -description "The Key Distribution Center (KDC) encountered a ticket that it could not validate the full PAC Signature"
GetEvents -logname "System" -eventid 44 -lookuphours 24 -servicename "CVE-2022-37967-44" -threshold_warning 1 -threshold_critical 2 -description "The Key Distribution Center (KDC) encountered a ticket that did not contained the full PAC Signature"

Screenshot how it looks in check mk.

2 Likes

Interesting, reminds me a little of how check_logfiles did it in the past, but I think there are certainly use cases where this is a much easier solution than going through the Checkmk Event console - thanks for sharing!

1 Like

I would argue that once log forwarding to the event console is properly set up it is much easier to define new rules there (and more flexible) than to modify a local check that has to be distributed to 1400 hosts.

3 Likes

Maybe that is true, but for us its way to much information that is being sent to check mk.
Which we want to minimalize because of performance.

So this is the best option in the situaties we have.