13. 09. 2025 Mirko Ioris Blue Team, SEC4U

A Practical Guide to Working with Windows Authentication Logs – Part 2

Welcome back for the second and last part of our journey into the jungle of Windows logs! In the first part we set out our goal – tracking admin authentications – and learned more about Windows, how authentication events are logged, and where can we focus to isolate the most accurate events.

Today we’re going to show the queries we used and the dashboards we created.

Queries

For each paragraph we discussed in the previous post, let’s summarize the corresponding part of the query here.

Elevated Token

You can spot the Elevated Token value in event 4624. It can be either True or False, and in the logs these are mapped as %%1842 and %%1843.

At first, we filtered for winlog.event_data.ElevatedToken:"%%1842", which catches all logs that Windows classifies as administrative authentications. Just keep in mind that this also includes regular users who are local admins on their machines. When they authenticate at the Domain Controller, that event gets flagged with Elevated Token = True.

Eventually, we decided to go with NOT winlog.event_data.ElevatedToken:"%%1843", which filters out all logs flagged as Elevated Token = False. We chose this approach because the Elevated Token info only appears in 4624 events, and filtering for “True” would exclude logouts and failed login attempts.

Logon Types

Out of all the different logon types we mentioned last time, we determined that Event IDs 2, 7, 8, 9, 10, and 11 are human logons. They involve some kind of user interaction, either directly or through tools like RDP or runas.

Event types 3, 4, and 5 are usually automated and not triggered by a user. That said, type 3 does include some human activity, so we had to fine-tune it. After countless attempts, we ended up excluding type 3, except for a few specific cases. This helped us isolate human-related activity and filter out system-generated logins. Here’s the query we used:

NOT winlog.event_data.LogonType : (3 OR 4 OR 5) OR ( (event.code: "4624" AND winlog.event_data.LogonType : "3" AND process.name : ("svchost.exe" OR "lsass.exe") AND winlog.event_data.SubjectLogonId : "0x3e7" AND winlog.event_data.SubjectUserSid : "S-1-5-18") OR (event.code: "4624" AND winlog.event_data.LogonType : "3" AND winlog.event_data.LogonProcessName : "NtLmSsp" AND winlog.event_data.SubjectLogonId : "0x0" AND winlog.event_data.SubjectUserSid : "S-1-0-0") )

Service Accounts

Service accounts usually end with a dollar sign ($). Since we don’t want them showing up in our dashboard, we simply filter them out using:
NOT user.name:*$
Yep, it’s that simple! Almost too good to be true!

We did consider a few other approaches too. For example, we tried excluding logs where the Subject User ended with a dollar sign. But that turned out to be a bad idea, because some of our human admins also fell into that category. So we scrapped that method and stuck with the cleaner filter.

Administrator Enrichment

To make our filter even smarter, we came up with a way to tag all device administrators with a custom role called “administrator”. We built a PowerShell script that runs on each machine and grabs all the admin users (even recursively, in case there are nested groups).

We converted the results to JSON and pushed them into a dedicated Elastic index. Every collected log is then checked against this list, and if the user is an admin of the device or server they’re accessing, the log gets enriched with that info.

The script runs periodically and keeps track of any new users added to the Administrators group, so the data stays fresh and up to date.

Putting It All Together

Considering all our reasoning and bringing everything together into a single query, here’s what we ended up with:

The event.category:authentication part isolates all Windows authentication logs, while user.roles:administrator filters for users enriched with the administrator role, the ones identified by our PowerShell script as having admin rights on the device they’re accessing.

The Dashboard

We used the query mentioned earlier to build a clean and user-friendly dashboard in Elastic for our customers. A snippet of the dashboard is shown below.

Elastic dashboards are great because they let users, even those with little to no experience, explore the data with ease. They’re interactive and update in real time when you click on any item.

On top of that, Elastic lets us add filters, so users can choose from multiple values and update the dashboard based on what they’re looking for.

Wrapping Up

We started this journey by identifying human logons through specific event IDs, refined our filters using the Elevated Token value, excluded service accounts, and enriched our data with a custom PowerShell script that tracks local administrators.

All of this came together in a single, powerful query that feeds into a real-time Elastic dashboard, making it easy for users to explore authentication data without needing deep technical skills.

This setup not only improves visibility into admin activity across the network, but also helps reduce noise and focus on what really matters. We’re very happy with the results we’ve achieved, and we hope this approach will help you too when working with Windows Logs!

These Solutions are Engineered by Humans

Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find cybersecurity issues interesting, maybe you could start in a cybersecurity or similar position here at Würth Phoenix.