Microsoft MDT: moving from BIOS to UEFI

If you have a Windows box and are trying to convert MBR/BIOS installs to GPT/UEFI installs on ‘class 2’ systems, you might want to read this:





“MBR2GPT.EXE converts a disk from Master Boot Record (MBR) to GUID Partition Table (GPT) partition style without modifying or deleting data on the disk. The tool is designed to be run from a Windows Preinstallation Environment (Windows PE) command prompt, but can also be run from the full Windows 10 operating system (OS).[…]”






MBRFilter: MBR security for Windows

Lucian Constantin has an article about a new MBR-based Windows-centric tool created by Cisco’s Talos. From his article on CSO Online:

[…]Cisco’s Talos team has developed an open-source tool that can protect the master boot record of Windows computers from modification by ransomware and other malicious attacks. threat intelligence The tool, called MBRFilter, functions as a signed system driver and puts the disk’s sector 0 into a read-only state. It is available for both 32-bit and 64-bit Windows versions and its source code has been published on GitHub. The master boot record (MBR) consists of executable code that’s stored in the first sector (sector 0) of a hard disk drive and launches the operating system’s boot loader. The MBR also contains information about the disk’s partitions and their file systems. Since the MBR code is executed before the OS itself, it can be abused by malware programs to increase their persistence and gain a head start before antivirus programs. Malware programs that infect the MBR to hide from antivirus programs have historically been known as bootkits — boot-level rootkits. […]

From the project’s readme:

[…]This is a simple disk filter based on Microsoft’s diskperf and classpnp example drivers. The goal of this filter is to prevent writing to Sector 0 on disks. This is useful to prevent malware that overwrites the MBR like Petya. This driver will prevent writes to sector 0 on all drives. This can cause an issue when initializing a new disk in the Disk Management application. Hit  ‘Cancel’ when asks you to write to the MBR/GPT and it should work as expected. Alternatively, if OK was clicked, then quitting and restarting the application will allow partitoning/formatting. […]




Showalter analysis of HDRoot MBR bootkit

William Showalter has a blog post on the HDRoot MBR bootkit. Abstract below. See the below web site for an additional PDF, and a Github repo of the samples.

A Universal Windows Bootkit: An analysis of the MBR bootkit referred to as “HDRoot”

In October, 2015 Kaspersky released an analysis of a family of malware they dubbed “HDRoot” on their Securelist blog. It was an installment in their ongoing series on the WINNTI group, known for targeting gaming companies in their APT campaigns. The Securelist blog was dismissive of the HDRoot bootkit and called out a number of mistakes they claimed the authors made, which brought it to be the focus of their ridicule. The bootkit in question uses two stolen signing certificates and is capable of running without problem on any Windows system that was released in the last 16 years, from Windows 2000 to Windows 10. The one limitation is that it will only run as an MBR bootkit and will not work on systems using UEFI. It contains the ability to install any backdoor payload to be launched in the context of a system service when Windows starts up on both 32 and 64-bit systems. It also does a fairly good job of concealing the actual bootkit code, only failing to remove the backdoor after running it at boot. […]

Full post:


Brian on Secure Boot -vs- Nemesis

Brian Richardson of Intel wrote a new blog on the recent Nemesis malware:

(Nemesis targets BIOS-centric MBR not UEFI-centric GPT partititions.)



Determining Windows partition information

Patrik Suzzi has an article on GPT partitions, and how to determine if you have MBR or GPT:

The article is written for Windows users, and has lots of screenshots, looks to be informative!




verifyBoot: check MBR for changes since last boot

A few years ago, Naja Melan wrote a verifyBoot. Excerpt of readme:

verifyBoot helps you to automate the process of checking if your MBR and a partition have not changed. verifyBoot makes sha256 hashes, first of the entire partition, then of your MBR and every file individually on the partition to help to find out what has changed. Nowadays it has become reasonably trivial to have linux installed on an encrypted partition using dmcrypt or other encryption software. The usual procedure for system start-up implies for the bios to load the MBR of the boot device or the boot sector of a partition which then loads grub. Grub will load the kernel which will then take care of further booting and decryption of the encrypted system partition. The problem with this approach is that everything in the “/boot” partition is not encrypted, facilitating a rootkit attack. An attacker could make the user run a process with the required privileges before or during a moment when the boot-medium gets plugged into the running operating system. This would allow them to place a rootkit, but also to access to the unencrypted data which would probably be what’s at stake here in the first place, so this is not a very interesting scenario when considering the threat of a rootkit. The second option an attacker has when they can’t convince the user to run a rogue process is is to get physical access to the boot-medium. Since “/boot” is not encrypted, they can easily install a rootkit compromising everything on the system as soon as the user provides their pass-phrase. It is possible to considerably raise the bar of such an attack by installing one’s boot partition on a usb-stick that one carries at all time. This makes it hard for an attacker to obtain the unencrypted boot partition to compromise it. What do you do however when you go swimming, or when you get arrested or if you forget your usb stick somewhere. You could no longer be a 100% sure it wasn’t compromised. After you have been separated from your boot medium you should verify that it hasn’t changed. This is where verifyBoot comes in. It helps you to automate that process of verification. Note that you will need a safe system to run the verification test from. This could be a verified live system that you obtain from a trusted source for example. If the boot system has changed you will need to create a new one from a trusted system or use an encrypted backup copy to restore your boot partition before booting from it.

It is tied to MBR, and doesn’t work with GPT. It isn’t perfect, but it helps BIOS/MBR users with some vulnerability detection. It also seems like a feature the kernel should have…