Since Windows Event Log files are actually mapped into the memory space (note that portions of them can sometimes be swapped out) of the services.exe process, it's relatively simple, now that appropriate analysis tools such as Memoryze/Auditviewer from Mandiant, or Volatility from Volatile Systems are available, to extract them from a memory dump for analysis. This can come in quite handy if the data from the HD is unavailable for some reason.
You can do this in either Volatility or in Auditviewer. I'll cover the Volatility method to start. (If you need to get and install Volatility from scratch, I recommend Jamie Levy's bash install script (though it's a bit old, and I'm not sure whether it includes all the current plugins). EDITOR'S NOTE: Volatility is installed fully inside of the SIFT WORKSTATION 2.0. What makes it easy to use inside the SIFT workstation is it is fully pathed and can be run from any directory location.
First, run:
python Volatilty pslist -f <path to your memory dump> | grep services.exe
to get the process number of the Event Log service. Then:
'python volatility vadinfo -p <Event Log Process ID> -f <path to your memory dump> > <output filename>
Examine the output file, and look for sections similar to the following:
VAD node @8a103d90 Start 02420000 End 02e1ffff Tag Vad Flags: Commit Charge: 0 Protection: 4 ControlArea @8a2febc8 Segment e1f5c180 Dereference list: Flink 00000000, Blink 00000000 NumberOfSectionReferences: 2 NumberOfPfnReferences: 10 NumberOfMappedViews: 1 NumberOfSubsections: 1 FlushInProgressCount: 0 NumberOfUserReferences: 2 Flags: Accessed, HadUserReference, WasPurged, File FileObject @8a2feb50 (0a2feb50), Name: \WINDOWS\system32\config\SysEvent.Evt WaitingForDeletion Event: 00000000 ModifiedWriteCount: 0 NumberOfSystemCacheViews: 0 First prototype PTE: e2025000 Last contiguous PTE: e20277fc Flags2: File offset: 00000000
VAD node @8a30de90 Start 01020000 End 01a1ffff Tag Vad Flags: Commit Charge: 0 Protection: 4 ControlArea @8a3174f0 Segment e1f3ba28 Dereference list: Flink 00000000, Blink 00000000 NumberOfSectionReferences: 2 NumberOfPfnReferences: 14 NumberOfMappedViews: 1 NumberOfSubsections: 1 FlushInProgressCount: 0 NumberOfUserReferences: 2 Flags: Accessed, HadUserReference, WasPurged, File FileObject @8a30f768 (0a30f768), Name: \WINDOWS\system32\config\AppEvent.Evt WaitingForDeletion Event: 00000000 ModifiedWriteCount: 0 NumberOfSystemCacheViews: 0 First prototype PTE: e201e000 Last contiguous PTE: e20207fc Flags2: File offset: 00000000
VAD node @89ff1ec0 Start 01a20000 End 0241ffff Tag Vad Flags: Commit Charge: 0 Protection: 4 ControlArea @8a2f82f8 Segment e1d701d0 Dereference list: Flink 00000000, Blink 00000000 NumberOfSectionReferences: 2 NumberOfPfnReferences: 59 NumberOfMappedViews: 1 NumberOfSubsections: 1 FlushInProgressCount: 0 NumberOfUserReferences: 2 Flags: Accessed, HadUserReference, WasPurged, File FileObject @8a32f6b8 (0a32f6b8), Name: \WINDOWS\system32\config\SecEvent.Evt WaitingForDeletion Event: 00000000 ModifiedWriteCount: 0 NumberOfSystemCacheViews: 0 First prototype PTE: e2022000 Last contiguous PTE: e20247fc Flags2: File offset: 00000000
These are the VAD sections that contain the memory-mapped event log files. The important part in each is near the top, where it says
VAD node @######## Start ########
The number after the word 'Start' is the virtual address of the memory section where the file data resides, and that's how you recognize it after you dump the VAD table from that process, which is the next step.
python volatility vaddump -p <Event Log Process ID> -f <path to your memory dump> -d <directory in which to place your output>
The result will be a number of files with names like 'services.exe.#######.########-########.dmp'. That number before the hyphen is the start of the dumped memory section's virtual address, and when you find the ones that correspond to the numbers from your vadinfo output, you have your event log files. You should be able to analyze them using whatever tools you normally use on Windows event logs.
Doing it with Memoryze/Auditviewer is even easier. Just use Auditviewer to run memoryze on the file, and select at a minimum the 'Process Enumeration' and 'Memory Sections' checkboxes. Then once the analysis windows comes up, select the 'Memory Sections' tab, and double-click on the services.exe process. You can then scroll down in the right hand pane to the entries for the event log files, and note the 'RegionStart' addresses.
Finally, right-click on the services.exe entry in the left pane, and select 'Acquire Process'. This will dump the process's VAD table into the next higher numbered folder name, under the directory where you elected to store your results. As a bonus, all the dumped sections that contain normal dlls will be clearly identified by name. You will see files for the event logs in this folder too, with names like '<Process ID>_%5cWINDOWS%5csystem32%5cconfig%5cAppEvent.Evt', but they will be length zero. I'm not sure why these files are created, but the actual data will be in files with names like '<Process ID>__SystemMemory%5c0x########-########.VAD', where that number before the hyphen corresponds to the 'RegionStart' addresses you identified previously.
This method should also be usable to dump out any other file that's directly mapped into the memory space of a process.
As always, please feel free to leave commentary if you liked this article or want to call me on the carpet for some inaccuracy.
John McCash, GCFA Silver #2816, is currently a Forensic Investigator employed by a fortune 500 telecommunications equipment provider.