Pro Tips with Esben #8
The Windows event log is one of the most data-rich parts of Windows. However, scanning and using this wealth of information is often overlooked by people using Lansweeper. Today we’ll take a look at just some examples of how you can use the Event Log events to your advantage.
Event Log Security Auditing
If you’re not familiar with the concept (which I doubt) security audit in Windows is one of the most powerful tools to monitor the status of your environment and help you identify potential threats to your network. Exactly what and how much you monitor things is something each organization determines based on their risk assessment. Microsoft has a great guide to a lot of best practices for many events in the Windows event log, but I wanted to highlight just a few in particular.
Configuring Assets & Scanning
While the Windows event log does log a lot, there are settings you can use to make it log a lot more. For us to log and report on the events below, we’ll need to enable 2 things.
- Audit Policy Change Logging (specifically, MPSSVC Rule-Level Policy Change Auditing, for logging firewall changes)
- Security System Extension Logging (for logging service installations)
Both of these can be enabled in your Local Security Policy app on Windows. MPSSVC Rule-Level Policy Change falls under the Audit Policy, Audit Policy Change. Security System Extension can be found under the Advanced Audit Policy Configuration in System. Obviously, you can also use a group policy to enable the logging on all of your Windows assets.
By default, Lansweeper will only scan error events. However, we also need Failure and Success events to be scanned. In ConfigurationServer Options, near the bottom of the page, you’ll find the Eventlog Scanning options where you can enable these two types of event log scanning if they are not enabled yet.
Lastly, keep in mind that Lansweeper has event log specific scanning targets that let you scan only the event log more frequently on assets. This might be useful depending on how frequently you want to scan new events.
4625(F): An account failed to log on
The first interesting event to log and report on is the failed account log-on event. This event will let you keep an eye on where and how frequently a logon fails and also which account was trying to log on. Microsoft does have additional security recommendations depending on your environment.
4950(S): A Windows Firewall setting has changed
This event is generated whenever a local Windows Firewall settings was changed. However, keep in mind that it doesn’t log settings changed via group policy. The usability of this event speaks for itself, but there are a couple of additional events you might also be interested in reporting on. By adjusting the Event ID in the report below, you can easily adjust it to report on any of the following events:
- 4946: A change has been made to Windows Firewall exception list. A rule was added.
- 4947: A change has been made to Windows Firewall exception list. A rule was modified.
- 4948: A change has been made to Windows Firewall exception list. A rule was deleted.
- 5025: The Windows Firewall Service has been stopped.
4697(S): A service was installed in the system
This one is also pretty straightforward, keeping an eye on any service that has abnormal settings or is installed using abnormal properties is important. It is therefore recommended to audit this on high-value assets. Using Microsoft’s security monitoring recommendations, I created a report that shows all of these events that Microsoft lists as being abnormal.
1102(S): The audit log was cleared
This event is created every time the Security Audit Log is manually cleared. Since this event should in theory almost never occur, it is good to keep an eye on it. There is no reason to clear the security audit log unless someone might be trying to hide something.
