Wednesday, July 6, 2011

MBR Analysis

A few weeks ago, Harlan touched on the concept of analyzing the Master Boot Record (MBR or $BOOT) for signs of malware infestation. That got me to thinking, "what would that really look like"? So, I tested it and thought I would share my results.

To recap Harlan's post, basically the MBR contains the partition tables for a Windows system. On a typical NTFS host , the offset for the primary partition table that contains the operating system is 0x63. This may vary based on the type of system or the configuration, but generally speaking, this is pretty consistent. An easy way to check an image for the offset values is the The Sleuth Kit's tool, "mmls". By running mmls against an image, you will see the offset values for the partition tables.

Now, how malware comes into play here, is very interesting, and very clever. Let's take a "typical" Winodws NTFS system and assume that the OS partition is located where we would expect to see it, at offset 0x63. But what if there was a partition table set at offset 0x62? Would you even recognize it, or if you did, would you even care? It's not offset 0x63 right, and when you mount offset 0x63 you see the NTFS file system...plain as no harm no foul, right? Wrong, and here's why.

The malware creates a partition table at offset 0x62 and copies the MBR, with a jump statement. The OS boots and see the MBR in offset 0x62 FIRST. It reads the data and if malware is present executes it. It then follows the jump command to offset 0x63, the NFTS file system is recognized, and normal the normal boot process resumes. When the malware runs on the infected system, the traces are NOT in the primary file system, because they are stored in another partition table! Pretty slick!

After some digging around, I found a pretty nice perl script called, MBRparser by Gary Kessler. It's easy to use and shows you exactly what you would need to see when looking for MBR infections. In the screenshot below, I used Gary's tool to parse the MBR from my local Windows 7 Dell laptop.

As you can see, since I have a typical NFTS file system, my first partition table is set to 0x63, exactly what I would expect to see. What I would NOT expect to see, is a entry prior to offset 0x63. If I exported the MBR (again, $BOOT) from a target system and parsed it with MBRparser, and I saw a partition table prior to 0x63, I would immediately become suspicious.

Now, don't think that every time you have a partition table before the NTFS file system that you have MBR malware. There are systems that intentionally put partitions with vendor tools, or other data there intentionally. So, "Don't Panic" least not yet. If you see something there before the NTFS file system you can either mount it with a tool like ImDisk, or FTK Imager, or you can extract the data using The Sleuth Kit's, "blkls". Then you can see the data and decide for yourself if it's just benign vendor stuff, or if it's, malware.

The real takeaway here is to actually start looking. By adding this step to your malware detection methodology, you will increase your chances to catch an infection of this nature. And, since you were likely not doing this in the first place, you have made yourself an exponentially better investigator.



  1. I am probably misunderstanding here, so I will say sorry up front if I am.

    The starting sector for Windows systems partitions from Vista on is sector 2048. You should only find Vista or later systems starting a partition on sector 63 where there has been a reinstall without repartitioning over an XP/2003 or earlier version.

    The reason the starting sector was moved was, at least in part, to accomadate SSD and 4 KB sector hard drive alignment. For example, starting a partition at sector 63 on an Advanced Format hard drive (i.e., 4 KB physical sectors with emulated 512 logical sectors) could cause disk reads or writes to span two physical sectors, where the need should have been one physical sector, with a corresponding loss in drive performance.


  2. make a good point, the OS partition can be anywhere, and it really doesn't matter. What's important is that folks actually LOOK to see if there is a partition with "stuff" in it, before the OS partition. If there IS, then it might be something to check out.

  3. Hi Chris, your partition tables look a bit strange to me. As far as I understand it the boot flag should either be 80h for bootable or 00h for not bootable, and the partition types dont seem to look right either. I would expect to see 07h for NTFS. I just checked my own Win7 MBR with MBR parser v1.4 and get the results I was expecting. Also your 3rd partition table entry has an LBA size of 0 sectors when the rest of the values are populated, and the cylinders used by partition 2 and partition 3 overlap. Any chance you can post an image of the MBR hex from within Winhex, FTK imager or any other hex ditor? Thanks

  4. Doing a sanity check of the MBR is a great incident response technique. Its amazing how MBR rootkits are appearing again 10 years after their heyday. This technique will work against some of the more advanced bootkits in the wild like Alureon/TDL3 which modifies the MBR to point to its own encrypted filesystem at the end of the disk (and then once installed uses a copy of the original MBR to boot the system).