Daily Blog #255: RHEL Forensics Part 4: More on mlocate.db

RHEL Forensics Part 4: More on mlocate.db by David Cowen

Hello Reader,
Today we have something special, a guest post from Hal Pomeranz. One of the best parts of sharing research and information is when others come back and extend their work for the benefit of us all. Today Hal Pomeranz has kindly not only shared back his work in extending the idea of recovering mlocate database's from unallocated space, he's written a tool to do so! I'll be testing Hal's tool on my test image and post those results tomorrow. In the mean time enjoy this very well written post!

If you want to contact Hal go to http://deer-run.com/~hal if you want train with Hal he is an excellent instructor with SANS http://www.sans.org/instructors/hal-pomeranz. Hal is an awesome forensicator and community resource who also is willing to 1099 to those of you like myself that run labs that are looking to extend our capabilities.

You can download the new tool has has made here: https://mega.co.nz/#!TsoTlSjR!BMz7BQqOhCeLGumWu51kaw4v_VFxd6UT3lyqu-ljUdc

With all that said, here is today's guest post from Hal.

Hal Pomeranz, Deer Run Associates

One of the nice things about our little DFIR community is how researchers build off of each other’s work. I put together a tool for parsing mlocate.db files for a case I was working on. David Cowen and I had a conversation about it on his Forensic Lunch. David had some questions about whether we could find previous copies of the mlocate.db in unallocated blocks, and wrote several blog posts on the subject here on HECF blog. David’s work prompted me to do a little work of my own, and he was kind enough to let me share my findings on his blog.

Hunting mlocate.db Files

In Part 3 of the series, David suggested using block group information to find mlocate.db data in disk blocks. My thought was, since the mlocate.db files have such a clear start of file signature, we could use the sigfind tool from the Sleuthkit to find mlocate.db files more quickly.

# sigfind -b 4096 006D6C6F /dev/mapper/RD-var

Block size: 4096 Offset: 0 Signature: 6D6C6F

Block: 100736 (-)

Block: 141568 (+40832)

Block: 183808 (+42240)

Block: 232192 (+48384)

Block: 269312 (+37120)

Here I’m running sigfind against my own /var partition. “006D6C6F” is “mlo” in hex, the first four bytes of a mlocate.db file (sigfind only allows a max of 4-byte signatures). I’m telling sigfind to look for this signature at the start of each 4K block (“-b 4096”). As you can see, sigfind actually located five different candidate blocks.

What was interesting to me was the blocks are in multiple different block groups in the file system. As David suggested in Part 3, the EXT file system normally tries to place files in the same block group as their parent directory. But when the block group fills up, the file can be placed elsewhere on disk.

I wanted to make sure that these were all legitimate hits and not false-positives. So I used a couple of other Sleuthkit tools and a little Command-Line Kung Fu:

# for b in 100736 141568 183808 232192 269312; do

echo ===== $b;

blkstat /dev/mapper/RD-var $b | grep Allocated;

blkcat -h /dev/mapper/RD-var $b | head -1;

done

===== 100736

Not Allocated