Security, et al

How do you figure out when someone was actually logged onto their PC? By “logged onto” I mean, physically present and interacting with their computer. The data is there in the security log but it’s so much harder than you’d think.

First of all, while I said it’s in the security log, I didn’t say which one. The bad news it isn’t in the domain controller log. Domain controllers know when you logon but they don’t know when you logoff. This is because domain controllers just handle initial authentication to the domain and subsequent authentications to each computer on the network. These are reflected as Kerberos events for Ticket-Granting Tickets and Service Tickets respectively. But domain controllers are not contacted and have no knowledge when you logoff – at all. In fact, look at the evens under Account Logon audit policy subcategory; these are the key domain controller events generated when a user logs on with a domain account. As you can see there is no logoff event. That event it only logged by the Logoff subcategory which and really, the whole concept of a discreet session with a logon and logoff has disappeared. You may remain “logged on” to your PC for days if not weeks. So the real question is not “Was Bob logged in?”, it’s more about “Was Bob physically present, interacting with the PC?”. To answer this you have to look at much more than simple logon/logoff events which may be separated by long periods of time during which Bob is anywhere but at his computer.

Physical presence auditing requires looking at all the events between logon and logoff such as when the console locks, the computer sleeps and screen saver events.

Logon session auditing isn’t just a curious technical challenge. At every tradeshow and conference I go to, people come to me with various security and compliance requirements where they need this capability. In fact one of the cases where I’ve been consulted as an expert witness centered around the interpretation of logon events for session auditing.

The absolute only way to track actual logon sessions is to go to the workstation’s security log. There you need to enable 3 audit subcategories:

1. Logon
2. Logoff
3. Other Logon/Logoff

Together, these 3 categories log 9 different events relevant to our topic

• 4624 - An account was successfully logged on
• 4634 - An account was logged off
• 4647 - User initiated logoff
• 4800 - The workstation was locked
• 4801 - The workstation was unlocked
• 4802 - The screen saver was invoked
• 4803 - The screen saver was dismissed

But how do you correlate these events because that’s what it’s all about when it comes to figuring out logon sessions. It is by no means a cakewalk. Matching these events is like sequencing DNA but the information is there. The best thing to do is experiment for yourself. Enable the 3 audit policies above and then logon, wait for your screen saver to kick in, dismiss the screen saver, lock the console as though you are walking away and then unlock it. Allow the computer to sleep. Wake it back up.

As you can see there is some overlap among the above events. What you have to do is between a given logon/logoff event pair (linked by Logon ID), identity the time periods within that session where the user was not present as a result of

• Sleep (that of the computer)
• Hibernation
• Screen saver
• Console locked

And count any session as ending if you see

• Event ID 4647 for that session’s Logon ID (User initiated logoff)
• Event ID 4354 for that session’s Logon ID (Logoff)
• Event ID 4608 – System startup

As you can see, the information is there. But you have to collect it and that is a challenge for most organization because of the sheer number of workstations. SIEM solutions like EventTracker automate this for you whether by remote event collection which can be practical in some cases or with the more feasible end-point agent.

“This article by Randy Smith was originally published by EventTracker” https://www.eventtracker.com/newsletters/tracking-physical-presence-windows-security-log/