7 min read
I often encounter a dangerous misconception about the Windows Security Log: the idea that you only need to monitor domain controller logs. Domain controller security logs are absolutely critical to security but they are only a portion of your overall audit trail. Member server and workstation logs are really just as important and I’m going to focus this article on the top 4 questions you can only answer with workstation logon/logoff events.
For your workstations to generate these events you need to enable at least the following audit policy. Remember that XP is configured with the legacy 9 audit categories while Windows 7 and 8 should be configured with audit subcategories under Advanced Audit Policy in group policy objects:
| Windows XP | Windows 7 and 8 |
| Logon/Logoff for Success & Failure | Logon for Success & Failure, Logoff for Success |
When Did the User Logoff?
The workstation security log is the only place can answer this question. Contrary to intuition, Domain Controllers have no idea when you logoff. When you enter your credentials at your workstation, even though it looks like you are logging into the domain, you are really just logging on to your workstation. The domain controller authenticates you but the only logon session established is at the workstation. Windows labels that logon session with a logon ID which is included in both the logon event (528 or 4624) and then in the logoff event (551 or 4647), and that’s how you correlate the 2 events to come up with the duration of the overall logon session. Remember though that users often remain logged on for days at a time. So to make the concept of a logon session more meaningful you need to take into account when the workstation console is locked and/or screen saver is in effect. Thankfully Microsoft has added event IDs to Windows 7 to cover these events. See events 4800-4803 which are logged if you enable the “Other Logon/Logoff Events” audit sub category.
What Is the Exact Reason for Logon Failure?
Would you believe that Kerberos authentication failure events on domain controllers don’t tell you the exactreason why the request failed? It’s true though and the reason is because Kerberos authentication ticket request events log use the reason codes specified in RFC 1510. This Kerberos specification doesn’t contemplate all the different reasons why a logon can fail in Windows, so some Kerberos failure codes logged on the domain controller can mean one of several Windows logon failure reasons. For instance Kerberos failure code 0×12 (Client credentials have been revoked) can mean that the Windows account is disabled, expired or currently locked out. To get the specific reason the logon failed you need to find the related logon failure event on the workstation where the user attempted logon from. XP logs a different event ID for each reason (529-537) while Windows 7 logs just one event ID (4625) with the reason stated within the details.
Who Accessed this Laptop While It Was Disconnected from the Network?
Knowing the answer to this question can be important in forensics situations. When a Windows laptop is disconnected from the network, any domain user out of the last 10 successful interactive logons can logon to the workstation with cached credentials.
Normally, when you logon to your workstation with domain credentials, the workstation checks your credentials with the domain controller and this creates an audit trail on the DC. But when you logon to a workstation with cached credentials nothing is logged on the DC – after all the whole reason Windows is using cached credentials is because you aren’t connected to the network.
Again, the Logon/Logoff category on XP and the Logon subcategory on Windows 7 save the day. Just look for logon event 528 or 540 where the Logon Type is 11. 11 stands for an interactive logon with cached credentials.
Is Anyone Trying to Break Into This Computer?
If someone is trying to break into a workstation from over the network by guessing the password of a domainaccount, the authentication failure will show up in the domain controller. But they are pounding on a local account on that workstation or simply trying random user names the only indication you’ll have are the failed logon events in that workstation’s security log.
As stated earlier, the logon failure events for XP are 529-537 while Windows 7 logs just one event ID (4625) with the reason stated within the details. How can you tell if the logon attempt involved domain account or not? Just check the Account Domain under “Account For Which Logon Failed”. If it matches one of your domains, the logon attempt is likely related to an account on your domain. If the Account Domain matches the name of the workstation itself, someone is specifically trying to logon to that system using a local account there-in. If the Account Domain is blank or has some other non-existent domain or user name, someone may be trying to break into that system.
As you can see, workstation logon events are extremely valuable – especially in this era of increased end-point security risks. Advanced Persistent Threat actors love to start with a compromised workstation and follow a lateral kill chain to the server of their focus. So, catching intruders at the workstation is a good way to break that kill chain early in the process.
