How to audit access to the Windows Event logs?

[guarisma]

Hello,

I've been asked to audit the access to the Windows Event logs themselves... this might be more of a Windows Server question, but still Splunk relevant.
To access Windows Events, I have identified that a user has several options:
1. Use Event Viewer
2. User PowerShell Cmdlt Get-EventLog
3. Open the files in %SystemRoot%\System32\winevt\Logs directly with some tool (like event viewer)

So, I would think all of these use cases trigger a read from the file system and I setup a File System auditing for the whole %SystemRoot%\System32\winevt\Logs in Windows Server group policy for the Everyone group and I manage to capture events from the 3rd use case using explorer, event viewer (double clicking the file from explorer), and event from a CMD console using the type command. But for use case 1 (Event Viewer and click on any Windows Logs) and 2, I don't get any events in the Security logs.

Am I missing something? From where is Event Viewer reading the logs if it's not from the files in %SystemRoot%\System32\winevt\Logs?

Thanks,

Igor

[adayton20 · Accepted solution]

I see what you're saying now. I do not know of a way to audit what users are viewing inside Event Viewer. I'd be interested in that solution myself, but in almost every environment I've worked in, the customer imposes a variety of restrictions on users - simply opening Event Viewer is one of them.

As far as when a user accesses Event Viewer, you can either:

1. Monitor new process creations (4688) for the Event Viewer process name, which on my pc is eventvwr.exe.

2. Explore the possibility of using sysmon (part of sysinternals), which will provide you with parent and child process creations. For example, simply opening the Event Viewer generates an event with a field containing "CommandLine", which looks something like this:

   CommandLine: "C:\Windows\system32\mmc.exe" "C:\Windows\system32\eventvwr.msc"

Here we see the Management Console calling the Event Viewer Snap-in.

Using this option will also show you a user accessing Event Viewer via other means, for example:

Command Prompt:
ParentCommandLine: "C:\Windows\system32\cmd.exe"
Image: C:\Windows\System32\eventvwr.exe

Or even those using scripts to open other processes, like Event Viewer:

Batch file calling Event Viewer:
ParentCommandLine: C:\Windows\system32\cmd.exe /c ""C:\Users\Andrew\Desktop\test.bat" "
Image: C:\Windows\System32\eventvwr.exe

PowerShell calling Event Viewer:
ParentCommandLine: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
CommandLine: "C:\Windows\system32\mmc.exe" "C:\Windows\system32\eventvwr.msc"

As far as monitoring PowerShell inputs and outputs, using Group Policy, you can turn on verbose logging for PowerShell.

There is an article outlining the steps here:
https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html

After you do this, you will need to set up a monitoring stanza in your inputs.conf. There are two paths involving PowerShell in Event Viewer:

Microsoft-Windows-PowerShell/Operational
(Applications and Service logs > Microsoft > Windows > PowerShell / Operational)
The event ID's you should whitelist are 4100, 4101, 4102, 4103, and 4104.

and

Windows PowerShell
(Applications and Service logs > Windows PowerShell)
The event ID's you should whitelist are 400 and 800.

Using this solution will not only provide you with the input but also the output of what the user retrieved using the cmdlet.

Hope that helps 🙂

[guarisma]

The PowerShell part is great, I'll have to convince the Sys Admins to turn on PowerShell auditing now.
One thing is that I cannot see if the command was successful.

I will have to conform with the Event Viewer being executed by someone for now.
I wonder if there's a way to turn on auditing for the Event API, maybe is just not a good idea since I imagine infinite events caused by one trigger 🙂

[adayton20]

If I understand you correctly, you will want to modify your group policy to log successes and failures to objects. What you are trying to accomplish can be done by setting a group policy to increase what you are logging. Does this article help at all?

http://www.online-tech-tips.com/windows-xp/how-to-track-and-monitor-who-and-when-someone-accesses-a-...

If yes, once you make the change as to what you want to log, if you're logging all events in the WinEventLog:Security, these successes and failures will begin showing up in Splunk. Now, bear in mind auditing both successes and failures will be extremely noisy in Splunk, so make sure you're very specific about what you're monitoring. I'd recommend testing this policy in a test environment, or on a single machine, so you can evaluate the data and determine how it will impact your license usage and storage (depending on your environment of course) before deploying it enterprise wide.

Another route you might explore is to create a group policy to simply restrict user access to the event viewer, power shell, command prompt, and system directories all together. These are generally administrative level functions. I'm not sure what sort of environment you work in, but from a security standpoint, allowing users to access the above is a big no no. I won't go into detail, but from my experience, the average user shouldn't need to have access to those tools / paths. If there is a valid use case, create a special group in AD and push the increased logging policy to users in that group. That way it minimizes how much you actually have to ingest in Splunk and is less work for you sifting through all those logs.

Lastly, explore some of the event ID's. I personally use Ultimate Windows Security. Event ID 1102, for example, is a log generated when audit logs are cleared. Browsing some of these event ID's might enable you to craft a search which monitors for suspicious or malicious activity, and may satisfy the requirement of auditing user activity associated with the Windows OS.

Hope that helps.

[guarisma]

Thanks for your answer, although if you read carefully you'll notice I did setup the group policy and turn on auditing from the %SystemRoot%\System32\winevt\Logs folder, and this works if I interact directly with the files (double click from the Windows explorer or do something from the command line like 'type' or 'copy'.
The problem is when using Event Viewer or the PowerShell Cmdlt, it doesn't report anything in the Security logs.

It's not my role to give or restrict access, just to find a way to report what was accessed, but I agree in that's a best practice.

Clearing logs is already cover in another use case I implemented, and yes I used that Event ID, thanks anyway.

Thanks again.