11.4 Windows Event Log Forensics: Security Audit IDs (4624, 4625, 4688, 4720, 7045) & EVTX Parsing

11.4 Windows Event Log Forensics: Security Audit IDs (4624, 4625, 4688, 4720, 7045) & EVTX Parsing

Quick Answer: Windows Event Logs (%SystemRoot%\System32\Winevt\Logs\) are stored in binary XML (.evtx) format, arranged in 64 KB chunks (ElfChnk) with independent string and template tables that facilitate forensic carving from unallocated space. Key security audit events include Event ID 4624 (Successful Logon), where Logon Types differentiate console access (Type 2), SMB/PsExec network pivots (Type 3), and RDP sessions (Type 10). Event ID 4625 tracks failed logons, utilizing Substatus codes like 0xC0000064 (unknown username) and 0xC000006A (valid user, incorrect password) to pinpoint password spraying. Event ID 4688 records process creation with complete command-line strings and parent process IDs. Finally, Event ID 7045 in System.evtx flags newly installed services (critical for catching persistence and lateral movement like PsExec's PSEXESVC.exe), while Event ID 1102 alerts on audit log clearing.

---

Windows Event Log Architecture (.evtx)

Introduced in Windows Vista and Windows Server 2008, the Windows Event Log subsystem replaced the legacy binary .evt architecture with the structured binary XML .evtx format. Understanding the underlying file layout is critical when carving deleted logs or handling file corruption.

EVTX Binary File Structure

Event logs are stored in %SystemRoot%\System32\Winevt\Logs\ (e.g., C:\Windows\System32\Winevt\Logs\Security.evtx). The binary structure consists of a single File Header followed by a continuous series of self-contained 64 KB Chunks:

+-------------------------------------------------------------------------+
|                        EVTX BINARY FILE ARCHITECTURE                    |
+-------------------------------------------------------------------------+
| File Header (4,096 bytes)                                               |
|   • Magic Signature: "ElfFile\x00" (0x45 0x6C 0x66 0x46 0x69 0x6C...)    |
|   • First Chunk Number / Last Chunk Number                              |
|   • Next Record Identifier                                              |
|   • Header Checksum & File Status Flags                                 |
+-------------------------------------------------------------------------+
| Chunk 0 (65,536 bytes - 64 KB)                                          |
|   • Chunk Header: Magic "ElfChnk\x00"                                   |
|   • First Event Record Number / Last Event Record Number                |
|   • String Tables (Offset pointers to commonly repeated string tokens)  |
|   • Template Tables (Tokenized binary XML schema definitions)           |
|   • Event Records Array (Variable length binary XML event records)      |
|   • Chunk Checksum                                                      |
+-------------------------------------------------------------------------+
| Chunk 1 (65,536 bytes - 64 KB)                                          |
|   • [Self-contained ElfChnk structure...]                               |
+-------------------------------------------------------------------------+

Forensic Carving Advantage of the 64 KB Chunk Model

In legacy .evt files, records relied heavily on global headers. In modern .evtx files, each 64 KB chunk (ElfChnk) is completely self-contained:

• It houses its own string table, template definitions, and record indexing.
• Forensic Implication: If an adversary clears an event log or runs anti-forensic tools to truncate .evtx files, examiners can scan raw unallocated disk clusters or Volume Shadow Copies for the magic signature ElfChnk\x00. Even if the primary file header is destroyed, carved individual chunks can be fully parsed and reconstructed into coherent event records.

Legacy .evt Structures: ELF_LOGFILE_HEADER, EVENTLOGRECORD and ELF_EOF_RECORD

Pre-Vista hosts — and the archived .evt exports that organizations still retain for retention compliance — use a completely different layout, and the blueprint names its three structures explicitly. A legacy event log is a fixed-size circular file built from a header, a run of event records, and an end-of-file record.

1. ELF_LOGFILE_HEADER — always 0x30 (48) bytes.

The Flags field carries four status bits that matter in an investigation:

• ELF_LOGFILE_HEADER_DIRTY (0x0001) — records were written but the log was never cleanly closed. The service sets this bit before the first write and clears it only at an orderly shutdown, so a dirty flag is the artifact of a crash, a hard power pull, or a log pulled from a running machine. Critically, the service resynchronizes a live log that is dirty but treats a backup log with the dirty bit as corrupt and refuses to open it — a routine cause of "the tool will not load my .evt" during examination.
• ELF_LOGFILE_HEADER_WRAP (0x0002) — the records have wrapped, so the file no longer begins at record 1.
• ELF_LOGFILE_LOGFULL_WRITTEN (0x0004) — the last write failed for want of space; a burst of events was lost, which matters when an examiner argues about a gap in the timeline.
• ELF_LOGFILE_ARCHIVE_SET (0x0008) — the file's archive attribute is set.

2. EVENTLOGRECORD — fixed portion 0x38 (56) bytes, then variable data.

The fixed portion is Length, Reserved, RecordNumber, TimeGenerated, TimeWritten, EventID, EventType, NumStrings, EventCategory, ReservedFlags, ClosingRecordNumber, StringOffset, UserSidLength, UserSidOffset, DataLength, and DataOffset. It is followed by SourceName, Computername, UserSid, the replacement Strings, the event-specific Data, DWORD alignment padding, and a second copy of Length. Three details are examinable:

• Reserved holds the same 0x654C664C (eLfL) signature as the file header, so every record is independently carvable from unallocated space.
• Length is stored at both ends of the record, which is what lets a parser walk the log forward or backward and lets a carver validate a candidate record by checking that the leading and trailing sizes agree.
• TimeGenerated and TimeWritten are 32-bit counts of seconds since 1 January 1970 UTC — Unix epoch seconds, not the 64-bit 100-nanosecond FILETIME used by modern .evtx. Feeding a legacy value into a FILETIME converter throws the timestamp into the 17th century; it is the most common conversion error on mixed-era evidence.

EventType is a bit value: 0x0001 Error, 0x0002 Warning, 0x0004 Information, 0x0008 Success Audit, 0x0010 Failure Audit. The last two carry the authentication story in a legacy log.

3. ELF_EOF_RECORD — always 0x28 (40) bytes.

It sits immediately after the newest record and exists so the service can rebuild a damaged header. RecordSizeBeginning and RecordSizeEnd are both 0x28, and four fixed identifiers — 0x11111111, 0x22222222, 0x33333333, 0x44444444 — make the structure trivially greppable in a hex editor. It also repeats BeginRecord (offset of the oldest record), EndRecord (offset of the structure itself), CurrentRecordNumber, and OldestRecordNumber, which is how an examiner recovers the true record range when the header is zeroed.

Organization of Event Records: Wrapping vs. Non-Wrapping

A fresh or freshly cleared .evt is non-wrapping: header, record 1, record 2, …, EOF record. Once the log reaches MaxSize, retention settings may turn it into a circular buffer, and the layout becomes discontinuous — the oldest surviving record may be number 102 because the space holding records 1–101 was reclaimed. Two consequences show up in casework:

• The system frees an integral number of whole records to make room, so a slice of wasted space sits between the EOF record and the oldest record. That gap is unallocated log space and frequently still holds parsable fragments of purged records.
• A record that reaches the physical end of the file is split in two, with the remainder written immediately after the header. If fewer than 0x38 bytes remain — less than the fixed EVENTLOGRECORD portion — the whole record is written at the beginning instead, and the leftover tail bytes are padded with the repeating pattern 0x00000027. Seeing that filler pattern is positive confirmation that the log wrapped rather than being truncated by a wiper.

---

Security Audit Forensics: Logon & Authentication

Authentication events within Security.evtx establish the timeline, origin, identity, and method of actor access.

Event ID 4624: Successful Logon

Logged whenever an account successfully authenticates to the host. Crucial fields include:

• TargetUserName / TargetUserSid: The identity of the authenticated user.
• TargetDomainName: Domain or local computer name.
• LogonProcessName: Subsystem handling the logon (e.g., User32, Advapi, Kerberos, NtLmSsp).
• AuthenticationPackageName: Protocol used (Negotiate, Kerberos, NTLM).
• WorkstationName: NetBIOS name of the initiating endpoint.
• IpAddress & IpPort: Source IP address and ephemeral source port.
• TargetLogonId: Unique 64-bit Locally Unique Identifier (LUID) assigned to the logon session. Used to correlate with subsequent logoff events.

The Critical Logon Types

The LogonType numerical field reveals the exact vector through which the session was established:

+-------------------------------------------------------------------------+
|                     WINDOWS LOGON TYPES MATRIX (EVENT 4624)             |
+-------------------------------------------------------------------------+
| Type | Name                | Description & Forensic Context             |
|------|---------------------|--------------------------------------------|
| **2**| Interactive         | Physical console logon (user typed credentials|
|      |                     | at physical keyboard or local virtualized  |
|      |                     | console).                                  |
| **3**| Network             | Remote network connection (e.g., SMB file  |
|      |                     | share access, RPC, PsExec remote execution, |
|      |                     | WMI execution). Normal for file servers.   |
| **4**| Batch               | Scheduled task execution or batch process   |
|      |                     | running under assigned service credentials.|
| **5**| Service             | Service Control Manager (SCM) launching a  |
|      |                     | registered background Windows service.     |
| **7**| Unlock              | Workstation unlocked (user entered password|
|      |                     | to dismiss a locked screen saver).         |
| **8**| NetworkCleartext    | Network logon with plaintext credentials   |
|      |                     | (e.g., IIS Basic Authentication).          |
| **9**| NewCredentials      | RunAs /netonly or Cobalt Strike make_token |
|      |                     | (local token clones caller, outbound uses  |
|      |                     | alternate credentials).                    |
|**10**| RemoteInteractive   | Remote Desktop Protocol (RDP), Terminal    |
|      |                     | Services, or Remote Assistance sessions.   |
|**11**| CachedInteractive   | Interactive console logon using cached     |
|      |                     | domain credentials while disconnected from |
|      |                     | the Active Directory Domain Controller.    |
+-------------------------------------------------------------------------+

Event ID 4625: Failed Logon & Substatus Attack Profiling

Logged whenever an authentication attempt fails. The FailureReason, Status, and Substatus NTSTATUS hexadecimal codes reveal the exact cause of failure:

+-------------------------------------------------------------------------+
|                  FAILED LOGON SUBSTATUS CODES (EVENT 4625)              |
+-------------------------------------------------------------------------+
| Substatus Code | NTSTATUS Name               | Forensic Interpretation  |
|----------------|-----------------------------|--------------------------|
| **0xC0000064** | STATUS_NO_SUCH_USER         | The specified username   |
|                |                             | does not exist. Indicates|
|                |                             | account enumeration.     |
| **0xC000006A** | STATUS_WRONG_PASSWORD       | The username is valid,   |
|                |                             | but password was wrong.  |
| **0xC000006D** | STATUS_LOGON_FAILURE        | General bad credentials  |
|                |                             | or unknown auth package. |
| **0xC000006E** | STATUS_ACCOUNT_RESTRICTION  | Account restriction      |
|                |                             | (e.g., unauthorized hours|
|                |                             | or workstation rules).   |
| **0xC0000072** | STATUS_ACCOUNT_DISABLED     | Attempt to authenticate  |
|                |                             | to a disabled account.   |
| **0xC0000193** | STATUS_ACCOUNT_EXPIRED      | Account has expired.     |
| **0xC0000234** | STATUS_ACCOUNT_LOCKED_OUT   | Account was locked out   |
|                |                             | due to failed attempts.  |
+-------------------------------------------------------------------------+

Differentiating Brute Force vs. Password Spraying

• Targeted Brute Force: A single TargetUserName associated with thousands of Event 4625 records occurring within minutes, all exhibiting Substatus 0xC000006A (valid user, wrong password), culminating in 0xC0000234 (Account Locked Out).
• Password Spraying: Hundreds of different TargetUserName entries each registering only 1 or 2 failed Event 4625 attempts every few hours from the same IpAddress, deliberately staying beneath account lockout thresholds.

Session Duration Tracking: Event IDs 4634 & 4647

• Event 4634: An account was logged off.
• Event 4647: User-initiated logoff (user clicked Start -> Sign Out).
• Timeline Reconstruction: Correlating the TargetLogonId (e.g., 0x00000000:0x4E2B1) from Event 4624 to the identical TargetLogonId in Event 4634 establishes the exact start, duration, and termination of the interactive session.

---

Process Creation Auditing: Event ID 4688

Event ID 4688 is logged in Security.evtx whenever a new process is spawned. However, the standard default configuration records only the executable path. High-maturity forensic environments enable Command-Line Auditing via Group Policy: Computer Configuration -> Administrative Templates -> System -> Audit Process Creation -> Include command line in process creation events.

Crucial Fields in Event 4688

• NewProcessName: Full path of the newly spawned process (e.g., C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe).
• CommandLine: The exact command-line string, arguments, flags, and obfuscated payloads passed to the process: powershell.exe -ExecutionPolicy Bypass -NoProfile -EncodedCommand JABjAGwAaQBl...
• CreatorProcessName / ParentProcessName: Path of the process that spawned the new process.
• ProcessId & ProcessId (New): Process Identifier (PID) in hexadecimal format.
• SubjectUserName / SubjectUserSid: Identity of the user whose token was used.
• TokenElevationType:
  • Type 1 (Default): Full token without elevation splitting (standard user or UAC disabled).
  • Type 2 (Full): Elevated administrator process running with administrative rights.
  • Type 3 (Limited): Process running with filtered, restricted token under UAC.

Detecting Process Anomalies & LOTL Attacks

Command-line auditing enables detection of malicious process tree hierarchies:

• winword.exe or excel.exe spawning cmd.exe or powershell.exe (classic macro/document exploit).
• w3wp.exe (IIS Web Server) spawning cmd.exe or whoami.exe (web shell execution).
• Native system utilities (certutil.exe, bitsadmin.exe, mshta.exe) making outbound network requests.

---

Account Management Auditing (4720, 4726, 4728, 4732)

Adversaries create rogue accounts and modify group memberships to establish persistent, elevated access.

+-------------------------------------------------------------------------+
|                    CORE ACCOUNT MANAGEMENT EVENT IDs                    |
+-------------------------------------------------------------------------+
| Event ID | Event Description                                            |
|----------|--------------------------------------------------------------|
| **4720** | A user account was created (Records TargetUserName, Creator) |
| **4722** | A user account was enabled                                    |
| **4724** | An attempt was made to reset an account's password            |
| **4726** | A user account was deleted                                    |
| **4728** | A member was added to a security-enabled global group         |
| **4732** | A member was added to a security-enabled local group (e.g.,    |
|          | adding an account to Administrators, SID S-1-5-32-544)        |
| **4738** | A user account was modified                                  |
+-------------------------------------------------------------------------+

When investigating Event ID 4720, always cross-reference SubjectUserName (who created the rogue account) with TargetUserName (the newly created account) to establish initial compromise attribution.

---

System & Service Events: Event ID 7045 & Anti-Forensics

While user authentication and process creation reside in Security.evtx, service installations and log manipulations reside in System.evtx.

Event ID 7045: A New Service Was Installed

Logged in System.evtx by the Service Control Manager whenever a new Windows service is registered.

• Threat Relevance: Primary indicator of persistence, privilege escalation, and lateral movement.
  • PsExec: When Sysinternals PsExec pivots across a network, it remotely writes a binary to ADMIN$ and registers a temporary service named PSEXESVC.
  • Malware Persistence: Ransomware and backdoors frequently establish persistent services.
• Crucial Fields in 7045:
  • ServiceName: Name of the registered service (e.g., PSEXESVC or MaliciousBackdoor).
  • ServiceFileName: Image path, including binary location and command-line execution parameters.
  • ServiceType: user mode service or kernel driver (identifies rootkit installation).
  • StartType: Auto Start, Demand Start, or Disabled.
  • ServiceAccount: The account context assigned to run the service (typically LocalSystem).

Anti-Forensics: Event Log Clearance Detection

When an adversary attempts to conceal their actions by purging event logs, Windows records immutable clearing events in the newly initialized log:

• Event ID 1102 (Security.evtx): "The audit log was cleared."
  • Captures SubjectUserName, SubjectUserSid, SubjectDomainName, and SubjectLogonId of the actor who cleared the Security log.
• Event ID 104 (System.evtx): "The log file was cleared."
  • Logged when the System log, Application log, or custom operational channels are wiped.

[!CAUTION] The presence of Event ID 1102 or 104 without an approved change control ticket is a high-confidence indicator of active adversary containment evasion or anti-forensic activity.

---

Modern Event Log Analysis Tools & Automation

Parsing gigabytes of EVTX records manually is impossible during active incidents. Forensic analysts leverage purpose-built automation suites:

# 1. Parsing EVTX with Eric Zimmerman's EvtxECmd
EvtxECmd.exe -d "C:\Windows\System32\Winevt\Logs" --csv "C:\Cases\EVTX_Parsed" --inc 4624,4625,4688,7045,1102

# 2. Querying Live EVTX via PowerShell Get-WinEvent (High Performance FilterHashtable)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
    StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, Message | Export-Csv -Path C:\Cases\FailedLogons.csv

# 3. High-Speed Threat Hunting with Hayabusa (Sigma Rule EVTX Engine)
hayabusa.exe search-timeline -d "C:\Windows\System32\Winevt\Logs" -o C:\Cases\hayabusa_timeline.csv