EVTX Record Recovery: Advanced Carving Techniques for Damaged Windows Event Logs

Positive Technologies researchers detail methods for carving EVTX records directly from raw disk images, memory dumps, and virtual machine snapshots when standard file system access fails. The approach bypasses corrupted MFT structures or wiped partitions by scanning for ElfChnk and record signatures. Their Go-based library parses both intact and damaged EVTX files, recovering events even when checksums mismatch. The article explains the three-layer EVTX structure including file headers, 64 KB chunks, and BinXML records with template substitution for space efficiency. Two carving strategies are presented: chunk-level recovery that restores full field names via per-chunk caches, and record-level extraction that pulls values without templates. The work supports faster incident reconstruction in ransomware cases where attackers encrypt entire VDI or VHDX images.

HabrTranslated from Russian

Read at source

Positive Technologies researchers have published a detailed technical guide on recovering EVTX records through carving techniques when attackers destroy or encrypt Windows event logs.

Windows event logs in EVTX format remain a critical telemetry source during incident response. They frequently provide the only evidence of credential theft, lateral movement, or persistence. Attackers routinely clear logs with wevtutil cl, encrypt them, or wipe entire disks. Modern ransomware increasingly targets full virtual machine images such as VDI, VMDK, and VHDX, rendering the volume file system unmountable due to destroyed MFT or partition tables.

EVTX File Structure

An EVTX file consists of three nested layers: file header, chunks, and records. The 4096-byte file header begins with the magic ElfFile\x00 and contains fields for first and last chunk numbers, next record ID, and two CRC32 checksums. Each 65536-byte chunk starts with ElfChnk\x00 and holds its own header with separate checksums for the header and event data, plus caches for strings and templates.

Event records begin with the magic bytes 2A 2A 00 00, followed by DataSize, EventRecordID, a FILETIME timestamp, BinXML body, and a duplicate DataSize trailer. The trailer enables boundary detection during carving. BinXML uses token streams and template instances to avoid repeating tag names, storing full templates once per chunk and referencing them via TemplateInstance tokens.

Carving Methods

The team describes two carving approaches. Chunk-based carving searches for the ElfChnk\x00 signature at any offset, validates header and data checksums separately, and assigns high, medium, or low confidence levels. When checksums match, full records with named fields are reconstructed using the chunk’s string and template caches.

Record-based carving scans for the 2A 2A 00 00 magic and extracts substitution values directly from TemplateInstance records. This method recovers field values even when the owning chunk and its caches are lost, although field names cannot be restored. The EventRecordID sequence helps identify gaps caused by deleted events.

The resulting library, implemented in Go, handles both complete files and raw images while tolerating checksum mismatches. It supports automated pipelines for large-scale artifact analysis during ransomware and targeted intrusion investigations.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Other

Mail.ru Reduces Lifetime 1TB Cloud Storage Promo to Standard 8GB Quota for Select Users
Kimi K3 Open Model Surpasses Closed AI Leaders with Million-Token Context and 896 Experts
Innostage Completes Functional Testing of PT NGFW 1.10.3 Across 156 Criteria