Hacking Exposed Computer Forensics Blog

Showing posts with label rhel. Show all posts

Daily Blog #262: Extending mlocator RHEL Forensics Part 6

Hello Reader,
I'm working on changing up Hal's mlocator and mlocate-time scripts to work to recover and parse unallocated mlocate entries. I'm having a bit of success as you can see with the following scrren shot that I am successfully recovering dates associated with file entries from hits found by mlocator.

Right now I'm running two scripts to do this, Hal's mlocator modified to convert the hex back to ascii and then writing it out to a file and then Hal's mlcoate-time modified to not look for the beginning of a mlocate database. I'm having some success but it's hanging 1/9 of the way through the 9mbs of mlocate data recovered just from group 33. This is good because my current mlocate database is only 3mb!

I'll keep on working on this and provide another update tomorrow with the ultimate goal of combining the two scripts into one that can be used to carve all mlocate database entries from a disk and print the parsed output.

Daily Blog #261: RHEL Forensics Part 5 Testing Hal's Mlocator

Hello Reader,
So I decided to test Hal Pomeranz's mlocator perl script today. Here's what I did, what I saw and what I'm thinking now.

What I did:
1. I downloaded the script, this wasn't easy with hotel wifi
2. I looked up the inode blocks that belong to the group that the mlocate directory is in again, which is still blocks 1081344 - 1114111 for group 33.
3. I ran mlocator with the following options:
mlocator.pl /dev/mapper/VolGroup00-LogVol00 1081344 1114111

where /dev/mapper/VolGroup00-LogVol00 is my partition
1081344 is the beginning block of group 33 where mlocate.db exists
1114111 is the last block of group 33 where mlocate.db exists

What I saw:
I got this cool output

What I'm thinking now:
I need to extend Hal's script so that it will extract those hits to a file so I made a modification that would write out all the hits stored in the $bytes variable back to ascii to a file. Here is what that file looks like viewed in xxd:

So we have good data, now I need to modify mlocate-time to be able to parse these file names and timestamps outside of the standard allocated database structure. I'll be giving that a try tomorrow and I'll post my results here.

This is what I believe long term, every filename with a timestamp we can recover (whether contiguous blocks from a known database/time or not) is valuable to provide intelligence on what existed at any point in time in the past.

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