25. 06. 2025 Mirko Ioris Blue Team, SEC4U

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

If you’ve ever worked with Windows authentication logs, you know they can be a chaotic mess. Even when you’re looking for something apparently simple and useful – like tracking admin logins – you quickly find yourself in a sea of redundant entries, some of them logged for no apparent reason, and poorly documented details.

I’ve been there, multiple times. Follow me, as I tell you about my ordeal.

Understanding the Goal

Italian law requires companies to collect and monitor authentications performed by administrative users. In our SOC we log all kinds of data, including authentication events. My goal was then straightforward: I wanted to isolate administrator authentication activities, such as logins, logouts, and failed login attempts, and make them visible to our customers on a dashboard. It helps during investigating suspicious activities, and we also comply with the law, so it’s a win-win.

How hard can this be? Well… as I quickly discovered, getting this data wasn’t as easy as running a basic query. We’re only interested in administrative authentications, so we have to find a way to filter out normal user activity. Additionally, Windows records multiple authentication events during the day: even while I’m writing this blog my account is probably generating login events. We want to isolate actionable data and remove duplicates, or else it would look like every single person logged in thousands of times per day, making it that much harder to understand what’s going on.

Last but not least, we also want to differentiate between human events and process activities. Scheduled tasks or periodic jobs can be configured to run under a specific user account. When this happens, the user name recorded in the event logs reflects that user account, not the name of the process that was executed.

Finding the Right Logs

Windows logs a ton of data, and finding what you actually need is another story. The admin authentication events I wanted aren’t categorized under a single label. Instead, they’re scattered across multiple event IDs, often mixed with non-relevant data. I focused on the following:

Event ID	Description
4624	A successful login, but for all users, not just admins.
4625	A failed login, but again, for everyone.
4634/4647	Logouts, but mixed in with session timeouts.
4672	A privilege escalation event, useful but not complete on its own.

Querying the event IDs directly is too broad, returning every type of login and logout from every user. I needed to narrow it down, focusing only on privileged accounts. Let’s dig deeper.

Elevated Tokens

When an administrator logs in, Windows may grant an “elevated token” to indicate that the session has administrative privileges. This happens when User Account Control (UAC) prompts the user for approval before running a process with elevated rights. In authentication logs, this can be identified through Event ID 4672, which signifies that special privileges were assigned during the login session. By tracking this event in combination with successful logins (Event ID 4624), we can reliably identify when an admin account is used with elevated privileges.

As you can see, we must correlate two different events to understand if the login was performed by an admin. Luckily, Windows tried to help us here (but don’t take this for granted :D), and in the newer versions of the OS, the elevated token is included directly in the 4624 event:

This isn’t enough to identify all the admin authentications though, because it’s a parameter added only for login events. It’s missing from logouts and failed logins, so we have to find another way to enrich those logs.

Logon Types

Not all Windows authentications are created equal. Depending on the identity, origin, and method of access, different logon types are recorded. Below is a summary of the most frequently encountered types.

Logon Type	Name	Description
2	Interactive	A user logged on to the console (keyboard/monitor). This is a typical local logon.
3	Network	A user or computer logged on over the network (e.g., accessing a shared folder). No user interface is presented.
4	Batch	Used for scheduled tasks. The system logs on the user without user interaction.
5	Service	A service started by the Service Control Manager logs on using a service account.
7	Unlock	A user unlocked the workstation (after it was locked).
8	NetworkCleartext	A user logged on over the network with credentials sent in cleartext. Used by legacy protocols.
9	NewCredentials	A user logged on with explicit credentials using `RunAs` or similar. The new credentials are used for outbound connections only.
10	RemoteInteractive	A user logged on via Remote Desktop (RDP) or Terminal Services.
11	CachedInteractive	A user logged on with cached credentials (e.g., when a domain controller is unavailable, offline domain login).

As you may notice from the gaps in the numbering, there are additional logon types. However, many of them are either deprecated, reserved, or not relevant to modern environments and were not considered in our scenario.

From this table, we can conclude that access types 4 and 5 are used solely by the system, while human activity is found in the other types. Logon type 3 is the most challenging, as it contains mostly system activities, but also some human activities. This will require more fine-tuning later.

Subject User vs. Target User

In Windows authentication logs each event has two interesting fields: a Subject User and a Target User. The subject user refers to the account that initiated the action, while the target user is the account being acted upon.

For example, if an admin account executes a task on behalf of another account, the subject user will be the admin, while the target user will be the account being accessed. This distinction helps in identifying privilege escalation attempts and unusual account activities.

Service Accounts

When analyzing Windows authentication logs, you’ll often encounter accounts that end with a dollar sign ($). These are called service accounts, and they’re privileged accounts primarily used to run applications or services.

Service accounts also exist in other operating systems and are not limited to Windows. They’re local device administrators and have system privileges, but are not associated with any human identity, nor do they represent human users.

SID and Local Users

Users, groups and other security principals in Windows are uniquely identified by a SID (Security Identifier). SIDs are unique and immutable and work as a digital fingerprint for a resource. The interesting part about this is that there are some well-known SIDs in Windows that represent standard users, groups, or system accounts across all Windows installations.

Some service accounts are identified with these SIDs, such as LocalSystem identified by S-1-5-18, LocalService identified by S-1-5-19, and NetworkService identified by S-1-5-20. Activities performed by these accounts are not generated by humans.

Putting It All Together

Combining the knowledge we’ve just discussed, it’s logical to think that one can filter logs where a service user is mentioned as a subject user (by looking at the name ending in $ and local SIDs). In these cases, even if a human is present in the target username, the login itself was not performed directly by the person, but was generated by the local service/account.

While this makes sense on paper, practical tests performed in our environment showed that there are events where the subject user is a service account, but the authentication was actually performed by a human. Don’t worry though, we can still use this knowledge to filter out some noise by removing all events where local accounts are mentioned as target users 🙂

Conclusions (for now)

So this is the end of the first part, in which we saw what lies behind authentication logs. With patience (and the right filtering), it’s possible to turn the chaotic mess inside logs into meaningful data. In part two, we’ll see how we implemented our queries and dashboards to finally achieve our goal.

Thanks for reading this far, it’s been a pleasure!

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.