Mini-guide: pivoting on the logon ID, or how one number turns a log into a session

Ask the Security log "what did this account do" and it answers with every event the account ever touched. Ask it "what did this logon do" and it answers with a story. The difference is one field.

The thread

Every successful logon gets a logon ID, a hexadecimal value unique on that machine until the next reboot. It then appears in every event the session causes. On PELL-APP-06 at Pellwick Dairy Cooperative:

19:02:11  4624  New Logon: adm.petrenko   Logon Type: 10   Logon ID: 0xF4D39E1   Source: 10.24.30.77
19:02:11  4672  Special privileges assigned   Logon ID: 0xF4D39E1   SeDebugPrivilege, SeBackupPrivilege ...
19:03:40  4688  New Process: C:\Windows\System32\cmd.exe          Creator Subject Logon ID: 0xF4D39E1
19:03:58  4688  New Process: C:\Windows\System32\net.exe          Creator Subject Logon ID: 0xF4D39E1
                   Command Line: net group "Domain Admins" /domain
19:04:25  4688  New Process: C:\Windows\System32\nltest.exe       Creator Subject Logon ID: 0xF4D39E1
                   Command Line: nltest /domain_trusts
19:09:02  4647  User initiated logoff   Logon ID: 0xF4D39E1

Filter the log on 0xF4D39E1 and those six lines are what you get: a Remote Desktop logon from 10.24.30.77, administrative privileges, a shell, two discovery commands, and a logoff seven minutes later. Filter on the account name instead and you get those six among every scheduled task, service start and mapped drive adm.petrenko has touched this month.

How to do it

1. Find the 4624 you care about and copy the New Logon: Logon ID.
2. Search the Security log for that value in any field. In 4688 it is the Creator Subject: Logon ID. In 4672, 4634 and 4647 it is the Subject's.
3. Sort by time. What you have is the session.
4. Note the 4634 or 4647. A session with no logoff before a reboot, or before the log ends, is worth a line in your notes.

Where the thread breaks

Reboots. Logon IDs are reused after a restart. Bound every search by the boot times, which events 6005 and 6006 in the System log give you.

Split tokens. With User Account Control, an administrator's interactive logon writes two 4624 events: a full token and a filtered one, each with its own logon ID and each naming the other as its Linked Logon ID. Processes started elevated carry one and everything else carries the other. Follow both, or you will see half the session and conclude the other half did not happen.

Process creation auditing is off. 4688 is not enabled by default. Without it the thread runs from logon to logoff with nothing in between, and that silence is a configuration finding, not evidence that nothing ran. Say so in the report.

Other hosts. The ID means nothing on another machine. A network logon from here to a second server gets a new ID there. The join between hosts is the source address and the second, not the ID.

Why it is worth the habit

It converts adjacency into attribution. "adm.petrenko logged on at 19:02:00 and nltest ran at 19:04:00" is two facts and an inference. "Logon 0xF4D39E1 ran nltest" is one fact. Reports built on the second kind survive being challenged, which is the only test of a report that matters.

The full list of events that carry the field is on the Windows event log cheat sheet.

Sources

The scenario above is invented. These are what its real half rests on.

• Microsoft Learn: 4624, An account was successfully logged on
• Microsoft Learn: 4688, A new process has been created
• Microsoft Learn: 4672, Special privileges assigned to new logon
• Microsoft Learn: 4634, An account was logged off
• Microsoft Learn: 4647, User initiated logoff