In this section
Windows Authentication Forensics: Logon Events 4624, 4625, LogonId Correlation
Authentication events record every logon attempt on the system: who authenticated, when, how, from where, and whether it succeeded. The logon type tells you the method. The LogonId ties every subsequent action to that session.
Scenario
The SAM analysis from Section 3.1 identified the svc_backup account as attacker-created. The Security log shows 14 logon events for that account across 3 days. Four are Type 10 (RDP). Six are Type 3 (network). Four are Type 2 (interactive). The attacker used this single account through multiple access methods. You need to map every session, determine where the connections came from, and correlate what happened during each session.
Event 4624 (successful logon) and 4625 (failed logon) are the highest-volume events in the Security log and the most forensically valuable for user activity analysis. This section teaches you to read them efficiently, filter to what matters, and use LogonId to track everything that happened within a session.
Estimated time: 45 minutes.
Key logon events
Six Security event IDs form the authentication analysis toolkit:
EVENT ID WHAT IT RECORDS VOLUME
4624 Successful logon. User, logon type, source IP, LogonId. High
4625 Failed logon. User, logon type, failure reason, source. High
4634 Logoff. LogonId (ties back to the 4624 session start). High
4647 User-initiated logoff (interactive sessions only). Low
4648 Explicit credentials (RunAs, "Run as different user"). Low
4672 Special privileges assigned to new logon (admin logon). MediumEvent 4672 is the admin logon indicator. Whenever an account with administrative privileges logs on, Event 4672 is generated immediately after 4624, listing the special privileges assigned (SeDebugPrivilege, SeBackupPrivilege, etc.). If you see a 4672 for an account that should not have admin access, the account has been elevated.
Logon types
The LogonType field in Event 4624 tells you how the user authenticated. Each type indicates different access methods and different attacker techniques.
TYPE NAME MEANING ATTACKER RELEVANCE
2 Interactive Physical console logon or RunAs Direct keyboard access
3 Network SMB, WMI, PowerShell Remoting Lateral movement (PsExec, WMI)
4 Batch Scheduled task execution Persistence via Task Scheduler
5 Service Service startup under service acct Persistence via service install
7 Unlock Workstation unlocked from locked Re-entry after AFK
8 NetworkClear Network logon with cleartext creds IIS Basic Auth, legacy apps
9 NewCredentials RunAs /netonly Pass-the-Hash indicator
10 RemoteInteract RDP logon Remote desktop access
11 CachedInteract Logon with cached domain creds Offline domain logonType 3 (Network) is the lateral movement indicator. PsExec, WMI remote execution, SMB file share access, and PowerShell Remoting all generate Type 3 logons on the destination system. A burst of Type 3 logons from the same source IP across multiple systems indicates active lateral movement. A single Type 3 logon from an unexpected IP may be the first step in a pivot.
Type 10 (RemoteInteractive) is RDP. The source IP in the 4624 event identifies where the RDP session originated. Cross-reference with RDP-specific event logs in Microsoft-Windows-TerminalServices-LocalSessionManager/Operational for session connect, disconnect, and reconnect details. Event 21 (Session logon succeeded) and Event 25 (Session reconnect succeeded) in that log provide additional timestamps and source IPs specific to RDP.
# Parse RDP-specific events for additional session detail
EvtxECmd.exe -f "E:\Collection\C\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx" --csv "C:\Forensics\Processed\case-001" --csvf "rdp-sessions.csv"Type 9 (NewCredentials) is a Pass-the-Hash indicator. When an attacker uses sekurlsa::pth in Mimikatz, or when someone uses runas /netonly, the resulting logon is Type 9. This logon type creates a new token with different credentials for network access while keeping the local session under the original identity. If you see a Type 9 logon for an account that should not be using explicit credentials, investigate the source process.
Type 4 (Batch) and Type 5 (Service) indicate persistence. Scheduled tasks generate Type 4 logons. Malicious services generate Type 5 logons. Both are common persistence mechanisms. Check which account is used and whether the scheduled task or service was created during the attack window (Event 4698 for task creation, Event 7045 for service installation).
Identifying admin sessions with Event 4672
Event 4672 is generated immediately after a successful 4624 when the authenticating account has administrative privileges. The event lists the specific special privileges assigned to the session:
KEY PRIVILEGES IN EVENT 4672
SeDebugPrivilege Debug programs (enables LSASS access for cred theft)
SeBackupPrivilege Back up files and directories (bypass file ACLs)
SeRestorePrivilege Restore files and directories (bypass file ACLs)
SeTakeOwnershipPrivilege Take ownership of files or other objects
SeLoadDriverPrivilege Load and unload device drivers
SeImpersonatePrivilege Impersonate a client after authenticationIf you see a 4672 event for an account that should not have admin access (a regular user account, a service account configured with least privilege), the account has been elevated. Filter for 4672 events to quickly identify every admin-level session during the investigation period:
# List all admin sessions during the investigation window
Import-Csv "C:\Forensics\Processed\case-001\security.csv" |
Where-Object { $_.EventId -eq 4672 -and
[datetime]$_.TimeCreated -gt "2026-03-12" -and
[datetime]$_.TimeCreated -lt "2026-03-16" } |
Select-Object TimeCreated, SubjectUserName, SubjectLogonId |
Sort-Object TimeCreatedEvery LogonId returned by this query represents a session with admin privileges. Follow each one through process creation events (4688) to determine what was done with those privileges.
Parsing and filtering logon events
The Security event log on a domain-joined workstation generates thousands of 4624 events per day from system processes, service accounts, and machine account authentication. Filtering is essential.
# Filter to human-relevant logon events for a specific account
Import-Csv "C:\Forensics\Processed\case-001\security.csv" |
Where-Object { $_.EventId -eq 4624 -and $_.TargetUserName -eq "svc_backup" } |
Select-Object TimeCreated, LogonType, TargetUserName, IpAddress, WorkstationName, TargetLogonId |
Sort-Object TimeCreatedThe session map tells a story. The attacker first used svc_backup via RDP from the domain controller (10.20.1.45) on March 12, the same day the account was created. Over the next three days, they used network logons from the same DC and RDP from a second system (10.20.3.22). On the final day (March 15), they used both network and interactive logons. The IP addresses identify the pivot points: the attacker controlled at least two internal systems (the DC and WKS-FIN04).
LogonId session correlation
Every process created, file accessed, and registry key modified during a logon session carries the same LogonId. The 4624 event assigns it. The 4634 event closes it. Everything in between belongs to that session.
# Find all process creation events in a specific logon session
Import-Csv "C:\Forensics\Processed\case-001\security.csv" |
Where-Object { $_.EventId -eq 4688 -and $_.SubjectLogonId -eq "0x5D7A04" } |
Select-Object TimeCreated, NewProcessName, CommandLine |
Sort-Object TimeCreatedThis is the complete attack sequence within a single logon session. The attacker ran reconnaissance (whoami, ipconfig), launched the C2 implant (update.exe), dumped LSASS memory (procdump64.exe), archived the dump and other collected data (7za.exe), and exfiltrated the archive (rclone.exe). The LogonId ties all six actions to the same network logon session from 10.20.1.45 under the svc_backup account.
Without LogonId correlation, you know these six processes ran during the attack window. With LogonId correlation, you know they were all executed by the same entity in the same session from the same source. This is the difference between a list of suspicious processes and a narrative of the attack.
Session lifecycle analysis
Track a session from start to finish by following the LogonId:
# Complete session lifecycle for a specific LogonId
Import-Csv "C:\Forensics\Processed\case-001\security.csv" |
Where-Object { ($_.TargetLogonId -eq "0x5D7A04" -or $_.SubjectLogonId -eq "0x5D7A04") -and
$_.EventId -in @(4624, 4634, 4647, 4672, 4688, 4663, 5140) } |
Select-Object TimeCreated, EventId, @{N='Detail';E={
if ($_.EventId -eq 4624) { "LOGON Type $($_.LogonType) from $($_.IpAddress)" }
elseif ($_.EventId -eq 4634) { "LOGOFF" }
elseif ($_.EventId -eq 4688) { "PROCESS: $($_.CommandLine)" }
elseif ($_.EventId -eq 4672) { "ADMIN PRIVILEGES ASSIGNED" }
elseif ($_.EventId -eq 5140) { "SHARE ACCESS: $($_.ShareName)" }
else { $_.EventId }
}} | Sort-Object TimeCreatedThis query reconstructs the complete session: logon, privilege assignment, every process created, every share accessed, and logoff. The output is the session narrative that goes into the investigation report.
Failed logon analysis
Event 4625 records failed authentication attempts. Patterns in failed logons reveal the attacker's credential discovery phase.
# Failed logons grouped by account and failure reason
Import-Csv "C:\Forensics\Processed\case-001\security.csv" |
Where-Object { $_.EventId -eq 4625 } |
Group-Object TargetUserName, Status |
Select-Object @{N='Account_Reason';E={$_.Name}}, Count |
Sort-Object Count -DescendingFAILURE STATUS CODES
0xC000006D Bad username or authentication info (generic wrong password)
0xC000006A Correct username, wrong password (targeted)
0xC0000234 Account locked out (too many failed attempts)
0xC0000072 Account disabled (attempted logon to disabled account)
0xC000006F Outside authorized logon hours
0xC0000070 Workstation restriction
0xC0000071 Password expired
0xC0000064 User does not exist (username enumeration)Targeted brute-force pattern. A cluster of 0xC000006A (correct username, wrong password) for a single account, from a single source IP, followed by a successful 4624. The attacker knew the username and guessed passwords until one worked. The time between the last failure and the success may be seconds (automated) or hours (the attacker tried a new password list).
Password spray pattern. The same failure code (0xC000006A or 0xC000006D) across many different accounts from the same source IP, with one attempt per account. The attacker tried one or two common passwords across all accounts to avoid lockout thresholds. Success appears as a 4624 for one of the sprayed accounts amid the 4625 failures.
# Detect password spray pattern: same source, many accounts, same time window
Import-Csv "C:\Forensics\Processed\case-001\security.csv" |
Where-Object { $_.EventId -eq 4625 } |
Group-Object IpAddress |
Where-Object { $_.Count -gt 10 } |
Select-Object Name, Count, @{N='Accounts';E={
($_.Group | Select-Object -ExpandProperty TargetUserName -Unique | Measure-Object).Count
}}If a single source IP has 50 failed logons across 40 unique accounts within a 10-minute window, that is a spray attack. If it has 50 failed logons against a single account, that is a brute-force attack. The distinction matters for the investigation narrative and for determining how many accounts may have been compromised.
Anti-Pattern
Analysing 4624 events without correlating the LogonId to subsequent activity. A logon event alone tells you someone authenticated. The LogonId tells you what they did during that session. Every 4688 (process creation), 4663 (object access), and 5140 (network share access) event during the session carries the same LogonId. Without this correlation, you know the attacker logged in but not what they did. Always follow the LogonId.
Forensic Investigation Principle
The LogonId is the thread that connects authentication to action. Without it, you have a list of logons and a list of processes with no relationship between them. With it, you have session narratives: who logged in, from where, what they did, and when they left. Session correlation is what transforms raw event data into an investigation timeline.
Before moving on, verify your understanding: filter your Security log CSV to Event 4624. List all unique accounts and logon types. For the attacker-created account from Section 3.1, map every logon session with source IPs and logon types. Pick one LogonId and follow it through process creation events (4688) to reconstruct what happened during that session. Search for failed logon events (4625) and identify any brute-force or spray patterns.
Next: Section 3.3 covers folder and file access artifacts. ShellBags record which folders the user navigated to. LNK files record which files they opened.