Event Log Forensics: Detecting Wiping and Reconstructing Attack Timelines

Cybersecurity

Windows EVTX logs are the first target attackers clear. Understanding the binary structure, detecting log tampering through event IDs 1102 and 104, and recovering wiped logs from disk slack are skills every IR analyst needs.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 30, 2024 · 11 min read

Windows Event Logs in the EVTX binary format (introduced in Windows Vista) are stored under C:\Windows\System32\winevt\Logs\. The three most forensically significant logs for incident response are Security.evtx, System.evtx, and Microsoft-Windows-PowerShell%4Operational.evtx. Each EVTX file uses a chunked binary format: a file header, followed by 65536-byte chunks, each containing a chunk header and individual event records in binary XML format. Understanding this structure is necessary for both parsing and recovery.

Key Event IDs for IR

• 4624: Successful logon (includes logon type, source IP for network logons, and impersonation level)
• 4625: Failed logon (source IP and username in brute-force detection)
• 4648: Logon using explicit credentials (RunAs, PsExec, scheduled task impersonation)
• 4688: Process creation with command line (requires audit policy and command line auditing enabled)
• 4697: Service installation (covers PsExec service and malware service persistence)
• 4698/4702: Scheduled task creation and modification
• 4776: NTLM authentication attempt (source workstation name)
• 7045: New service installed (System log, covers same events as 4697 from a different source)
• 1102: Security audit log was cleared (Security log; includes the account that cleared the log)
• 104: System log was cleared (System log; analogous to 1102 for the System log)

Log Tampering Detection: Event IDs 1102 and 104

Windows generates event ID 1102 in the Security log and event ID 104 in the System log whenever the respective log is cleared via wevtutil cl, the Event Viewer GUI, or PowerShell Clear-EventLog. These events are generated by the event logging service immediately before the log content is erased, and they include the account name and SID of the principal who performed the action. If these events are present, you know exactly who cleared the log and when. If the log file is completely empty with no events at all, the clearing event itself was also wiped, indicating a more aggressive tampering technique.

EVTX Binary Structure for Recovery

Each EVTX chunk begins with a 512-byte chunk header containing the ElfChnk signature, first and last event record numbers, file offset of the last record, last event record checksum, and a header checksum. Individual event records begin with the 2a 2a 00 00 (** in ASCII) signature. When an EVTX log is cleared, the file header's first chunk number resets but the chunk data on disk is not securely wiped: the previous chunk content remains in the clusters until overwritten. Carving for the 2a 2a 00 00 record signature in disk slack recovers deleted event records.

1. Collect all EVTX files using KAPE (EventLogs target) from the live system or forensic image
2. Parse with EvtxECmd.exe: EvtxECmd.exe -d C:\evtx_collection\ --csv C:\output\ --csvf events.csv
3. Filter event ID 1102 and 104 for log clearing events; note timestamp and clearing account
4. If Security.evtx shows zero records: acquire the raw disk image and search for 2a 2a 00 00 in unallocated space
5. Use Autopsy with the EVTX carving module or bulk_extractor to recover carved records
6. Cross-reference recovered records with VSS shadow copy event logs for the same time window

Enabling the Right Audit Policies

Default Windows audit policy does not log command lines (Event ID 4688 with process command line), PowerShell script block execution, or detailed object access. Organizations without a hardened audit policy will have Event ID 4624 logons and service installs but nothing on specific commands run. The minimum recommended policy additions for IR visibility are: Process Creation with Command Line (via Group Policy or auditpol.exe), PowerShell Module Logging (HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging), and PowerShell Script Block Logging (HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging).

• auditpol /set /subcategory:"Process Creation" /success:enable to enable 4688 logging
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled = 1 for command line in 4688
• PowerShell ScriptBlockLogging: generates Event ID 4104 in Microsoft-Windows-PowerShell%4Operational.evtx
• PowerShell Transcription: writes session transcripts to disk; survives even if event logs are cleared
• Sysmon: provides process creation (Event ID 1 with command line), network connections (3), and file creation (11) regardless of native audit policy

Reconstructing Attack Timelines from EVTX

Load EvtxECmd output into Timeline Explorer alongside MFTECmd, AmcacheParser, and AppCompatCacheParser outputs. The unified timeline view shows, in chronological order: the initial network logon (4624 type 3), lateral movement via explicit credentials (4648), service installation (4697/7045), process creation events (4688 with command line if enabled), and log clearing (1102). Each artifact type fills gaps left by the others. Network logon events in Security.evtx correlate with psexec.exe appearing in Shimcache and Prefetch on the target host.

An attacker who clears the Security log forgets that VSS shadow copies preserve EVTX files from before the clearing event, that PowerShell transcription writes to disk independently, and that Sysmon logs to a separate channel they may not have cleared. Layered logging defeats single-point evasion.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.