Hello.
In this demo,
we will look at how Winlogbeat can help us detect
unauthorized clearing of Windows event logs.
We will start by ensuring our Winlogbeat
configuration has the necessary event IDs.
Then,
I will simulate clearing the Windows event logs using a well known
technique seen by ransomware like NotPetya and various APTs.
Finally,
we will conclude the demo by observing the artifacts on our
Elasticsearch cluster using the Kibana web UI.
Generally speaking,
the Windows event logs serve as a history of events that occurred on a system.
So, if a threat actor were to compromise this machine,
they know the logs may capture their activities,
so part of their TTPs, or Tactics, Techniques,
and Procedures, typically involves clearing the event logs.
This is another reason why it's essential to use a tool like
Winlogbeat to ship logs off the endpoint.
Malicious or incidental clearing of the event logs probably
will not have as much impact if you know those logs are
saved in real time to a SIEM.
So what can we do with the Winlogbeat configuration to help us with detection?
Well, when the audit logs are cleared on a Windows system,
the event ID 1102 is generated.
It looks like we have that event ID configured.
According to the MITRE ATT&CK framework, clearing the Windows
event logs is considered a defense evasion tactic.
There are two well‑known ways that logs can be cleared on a
Windows endpoint. The first is using the Windows Events Command
Line Utility with a full suite of options available, including
clearing a specified log.
The second way to clear logs on a Windows system is with
the PowerShell cmdlet Clear‑EventLog.
Let's jump over to the Kibana web UI and search for any existing 1102
event IDs. Here we are, and as expected, there are no results. If you
find any 1102 EIDs in your production dataset, I recommend
investigating and considering developing a policy around arbitrary
clearing of production security logs.
Okay, time to head back to the workstation.
Now, let's clear the screen and put on our adversary hat. I've just
conducted my operations on this endpoint, and now I want to erase the
logs that may have evidence of my activity.
Now those pesky defenders will never know what I've done.
Okay, that should have logged the 1102 EID to the local system, and
Winlogbeat shipped it to our centralized collection point.
I'm going to switch over to the Kibana web UI and look at the data. Here we are.
You might notice there's only one event when we in fact cleared four event logs.
Well, that's because the event ID 1102 is specifically for the audit
log, also known as the security log. If we take a look at the message
field, we can see the source of the event.
Ah‑hah! You know which system and user is
associated with the event at this point.
Remember, accounts do get compromised, so this isn't a single source of truth.
You will need more context to identify if this was malicious or incidental,
but at least you will now be aware of the activity thanks to Winlogbeat.
That's all for this clip.
Thanks for watching.