It’s Not You! Windows Security Logs Don’t Make Sense
Summary: Windows logs are designed to track the execution of the application, regardless of whether this facilitates cyber investigations or not.
When I used to read code as a rookie, I used to think “I can’t understand this code. My coding skills must be sh*t.” Now that I’m a bit more senior, I read code and think “I can’t understand this code. The coding skills of the person who wrote this must be sh*t.” And that my friends is the main difference between a junior and a senior developer!
Except, despite working with Windows logs for most of my adult life, there are still things that make me scratch my head. And I’m starting to think it’s not me that is the problem.
4624(S) An account was successfully logged on
Reference: 4624(S) An account was successfully logged on
Windows events have a Subject/Target pattern to many events. This makes sense for events like 4720 (A User account was created) or 4656 (A handle to an object was requested). The subject in these cases is, like in linguistics, the person or thing taking the action. The subject in 4720 is the user account that is creating the new account. The subject in 4656 is the process that is requesting the handle.
The subject in event id 4624 however is actually the computer, not the user. That is, it is the computer that is taking the action. You can actually see it in the Event name, “An account was successfully logged on [by the computer]” instead of “An account successfully logged on [to a computer]”.
Grammar aside, we already know the subject account name from the “computer” field, the SID is assumed to always be SYSTEM, and the Logon ID will always be the SYSTEM Logon ID (0x3E7), so none of this is adding much value. What bugs me the most about this however is not the wasted space but the incorrect parsing I’ve seen over the years where a hastily written regex captures the subject logon ID instead of the target’s.
In the same category of wholly unnecessary is the process information field. The field captures the process that called the logon function. This can either be winlogon.exe for pre-Windows 10/Server 2016 or svchost.exe for newer OSes; which is a nice piece of trivia to know, but mostly useless from a monitoring perspective.
And then there are the logon types, and my personal favourite, logon type 3.
Just try explaining logon type 3! The best example is that it gets generated when someone accesses a network share … or uses Windows Remote Management … or it gets generated on domain controllers a lot for some reason … or PSExec (but also sometimes you get interactive too). Don’t worry, Microsoft has all this documented if you bother spending five hours looking for it. IIS also generates logon type 3, except when it generates a logon type 8 (Network Clear Text). Network Clear Text by the way does not mean that credentials are not transferred on the network in clear text, because what in the name would give you that impression?
Microsoft’s documentation of logon type 3 is listed below. All one sentence of it!
System ID 7045 vs Security 4697
Reference: 4697(S) A service was installed in the system.
Reference: Event ID 7045 — New Service was installed
You need to understand, Microsoft over-engineered the heck out of their logs and is now stuck with a small mountain’s worth of technical debt. In the case of the two events in question, I guess what happened was that someone decided that monitoring service creation was useful for both for system administration and for security monitoring. So they created two events, one in System and one in Security Auditing.
Security ID 4697 is well documented on Microsoft’s documentation site. By contrast, I could not find canonical documentation for System ID 7045. Point to Security ID 4697!
But! System ID 7045 records failures as well as successes. Heck, it even captures the reason the installation failed. Information that would certainly come in handy if someone is trying to escalate privileges. Point to System ID 7045.
But! But! If you’re using this for detections, shouldn’t you use whatever everyone else in the industry is using? Well, if you search Sigma, you can find 32 hits for 7045 and 22 hits for 4697.
So which event should you collect?
4738(S) A user account was changed
Reference: 4738(S) A user account was changed
An alert triggers. A local accounts on one of the hosts has been changed. You take a look at the event and realise, you have no idea what happened. You look at Microsoft’s documentation and you see this lovely nugget:
Unfortunately, for local accounts, all fields, except changed attributes, will have previous values populated. Also, the User Account Control field will have values only if it was modified. Changed attributes will have new values, but it is hard to understand which attribute was really changed.
The developer in me can empathise with the Microsoft developers. I can see the complex web of dependencies that probably caused this situation. But the SOC analyst in me thinks that creating an event for “Something changed. We hope you figure it out. May the odds be ever in your favour” is not the most useful event.
4698(S) A scheduled task was created
Reference: 4698(S) A scheduled task was created
Can you tell when the developer gave up on trying to parse the XML?
Event Viewer and Correlations
One of things I like most about Windows logs are Logon IDs. When you log into a host, event ID 4624 records a Locally Unique Identifier (LUID) called the Logon ID. As you go about your work, spawning processes, creating scheduled tasks, or creating user accounts, this Logon ID is recorded with these events. This makes the Logon ID a great way to track what the user has done in a session.
Frustratingly though, this foresight in designing events with emphasis on investigations does not extend to the tool used to view these events. Event Viewer, despite being built for Windows, is mostly event agnostic. It can display the Logon ID just fine, but it doesn’t make any effort to suggest that this field may be any different than any other field.
Of course, Event Viewer is not really the problem here. It is every SIEM solution that fails to extend the functionality of the events to what they could be. And so, many a junior SOC analyst would have their eyes glaze over the Logon ID field, completely unaware of what it can do and how it can help them.
“But Tareq”, I hear you say. “Event Viewer is meant to be a generic tool for Windows logging, not just Security Auditing.” Fair enough. The Logon ID field is specific to the Security Auditing, but what about “Correlation?” Correlation is part of the Event Schema. It is as generic as it can get in Events.
As a side note, if you view the event in XML format, the first line contains a link to the event schema. That link is a dead link.
The Correlation field is used to reference other events that are “correlated” together. For example, when you log in, Windows generates an event ID 4624 (An account was successfully logged on). In that event, you have a field called “Correlation” that links this event to related events like 4672 (Special privileges assigned to new logon) or 4627 (Group membership information). Would being able to get the group information of the user who just logged in be useful? Of course it would be. Does Event Viewer or most other SIEMs allow you to easily find this information? Of course not!
Perhaps I wanted Event Viewer to be the example of what can be done with Windows Events. I’m not mad at you, Event Viewer. I’m just disappointed.
4720(S) A user account was created
Reference: 4720(S) A user account was created
Event 4720 reports when an account was created, successfully. Which begs the question, how would you know if someone tried, but failed, to create a new user? A smart person would tell you that event ID 4720 only logs successes because failed attempts fail on the object access level (think, when trying to get a handle to the SAM database, for example), but that is exactly the problem. We have accepted that you need a PhD in Windows logs to make heads or tails of these logs. Those who can understand it are part of the “in” group, not like those Muggles who don’t know “real” cyber.
The truth is, these logs were not created with you in mind. They were created by a developer with a deadline. Despite the “Security Auditing” in their name, what they really audit is the application execution. This means that they are technically correct, but often less than helpful. Logon type 3 logs what the code is doing. The fact that you are trying to use it to figure out if someone accessed a network share or if they used WinRM is secondary. It does not matter what you need in terms of investigation. The logs will only tell you what was convenient to program at the time, regardless of whether these logs are useful or not.
Windows logs the Logon ID because that is what the application uses. A security person would have probably suggested the use of a Globally Unique Identifier (GUID) to make it easier to track activities when you have multiple hosts reporting to the same SIEM, but a security person did not design these logs, the application developer did. And the application developer knows that a failed account creation does not reach the same part of the code as a successful one. So now, every one of us needs to know that too just to do our jobs. Add this to everything else we expect security professionals to know and you can understand why we can’t find “good” security professionals, why we need to collect so much data, and why we keep getting breached.
For contrast, compare Windows logs to Sysmon logs. Sysmon is not without its flaws but just by using a Process GUID, I can tell you when the process was spawned, which domains it looked up, what connections it made, and what pipes it created or connected to. This is simply because every new Sysmon event was added for a reason. There was always a blind-spot that the new event was covering. Sysmon didn’t create a hundred events and hope that you can somehow string them together into a coherent narrative.
We need better logs. Our security depends on it.
P.S. If you’re interested in Threat Hunting or Detection Engineering, you may be interested in checking out our newsletter at the link here: https://threathuntersdigest.substack.com
