I've wanted to update lfle.pl for sometime, and with the rain this weekend, Saturday morning was the perfect time do so. For those who may not be aware, lfle.pl is a script I have for extracting WinXP/2003 style Event Log records from unstructured data. This means that it can be run against Event Log files, page files, unallocated space, and even memory dumps in order to extract these records. When it finds a valid EVT record, it dumps the contents in TLN format, so that a timeline can be easily generated.
Okay, so the obvious elephant in the room...why bother updating this tool? Well, in the summer of 2017, the world saw the NotPetya incident. During this incident, one of the analysts on the team I was working with got several Windows XP and 2003 systems in for analysis.
I downloaded the CFReDS hacking case image, and use FTK Imager to create a single, raw/dd-style image. I then exported the unallocated space from the image file, using the following commands:
mmls -i raw -t dos g:\cfreds\image.001
blkls -i raw -f ntfs -A -o 63 g:\cfreds\image.001 > g:\cfreds\image_unalloc
Next, I ran lfle.pl against the resulting file:
lfle.pl -f g:\cfreds\image_unalloc
This command yielded no results. Okay, next I exported the Event Log files from the image and ran lfle.pl against each one. Forty records were found in the AppEvent.evt file, and 141 in the SysEvent.evt file.
Troubleshooting
Interestingly, I go no results running lfle.pl against the Security Event Log file, using the following command:
lfle.pl -f g:\cfreds\image\secevent.evt
The prompt simply returned. Okay, so let's do some troubleshooting. Using the "-s" switch to display statistics, I get the following results:
lfle.pl -f g:\cfreds\image\secevent.evt -s
Small records skipped : 1
Large records skipped :
Malformed records skipped:
Records retrieved :
Okay, that's interesting. Only one "small" (i.e., less than 0x30 bytes) record was located. Going with the "-d" switch to enable debugging output, I get the following:
lfle.pl -f g:\cfreds\image\secevent.evt -d
Magic number located at offset 0x4 with length of 48 bytes
0x00000000 30 00 00 00 4C 66 4C 65 01 00 00 00 01 00 00 00 0...LfLe........
0x00000001 30 00 00 00 30 00 00 00 01 00 00 00 00 00 00 00 0...0...........
0x00000002 00 00 01 00 00 00 00 00 80 3A 09 00 30 00 00 00 .........:..0...
My final step was to open the secevent.evt file in hex editor, and low and behold, I found that there was just one record visible in the file, the one illustrated above. Following the record, there is the "cursor", which is 0x28 bytes, and does not contain the "LfLe" magic number. After that, what remained of the file was all zeros. So, that explains the results; it's not that the tool is "broken" or "doesn't work", but instead that there's nothing to display in the file.
Hibernation File
The image also contains a hibernation file, which I exported from the image. Using Volatility 2.6, I checked which profile would work for the image:
vol -f g:\cfreds\image\hiberfil.sys imageinfo
*Suggested Profile(s) : WinXPSP2x86, WinXPSP3x86 (Instantiated with WinXPSP2x86)
I then converted the hibernation file to raw format:
vol -f g:\cfreds\image\hiberfil.sys --profile=WinXPSP2x86 imagecopy -O g:\cfreds\image\mem.raw
Finally, I ran lfle.pl against it, with all switches enabled:
lfle.pl -f g:\cfreds\image\mem.raw -d -s > g:\cfreds\image\mem_lfle_out.txt
With everything turned on and being collected in the output file, it's kind of messy, with valid records mixed in with debugging info, etc. However, the statistics displayed at the end of the file tell us the story:
Small records skipped : 22
Large records skipped : 2
Malformed records skipped: 4
Records retrieved : 95
So, 22 "small" records were skipped, 2 "large" (i.e., 0x1000 bytes or larger) were skipped, 4 malformed (size values that bracket the record were not identical) records were skipped, and a total of 95 valid records were retrieved. Very nice.
Both the Perl script and the portable .exe version of the tool can be found on the GitHub repository.
No comments:
Post a Comment