A few simple notes on boot/rootkits on Windows.

Date : 25/12/2013
Version: 1.3
By: Albert van der Sel
Remarks: It's a ridiculous simple note on boot/rootkits. It could turn out to be a flop (or disaster), but let's try anyway :-)


Contents:

1. Introduction and Scope.
  1.1 Older interpretation, or, the original interpretation.
  1.2 Additional and newer interpretations (I): physical machines.
  1.3 Additional and newer interpretations (II): Systems on Hypervisors.
  1.4 Some Malware terminology.
  1.5 Scope of this ridicoulus simple note.
2. The "Helicopter view": Wild bootkits, PoC's, and the problem.
  2.1 The main steps in the Early boot.
  2.2 PoC's.
  2.3 Kernel-mode and User-mode kits.
  2.4 Some security improvements in modern Windows Servers and Clients.
3. Some furher notes on BIOS/MBR based bootkits (XP/Win2K3)
  3.1 The mechanics of the BIOS/MBR/VBR at boottime.
  3.2 Compromising the MBR.
  3.3 Compromising Sectors "nearby" the MBR, and the VBR.
  3.4 Some notes on how to remove such MBR/VBR bootkits.
4. Some furher notes on a EFI bootkit (Vista/Win7/Win2K8 and later).
5. Some furher notes on a "user-mode" bootkit:

Appendices:

1. Articles/References.
2. A few keywords related to System Hardening.


1. Introduction and Scope:

There seems to exist a few interpretations on code that's called a "rootkit", and code called a "bootkit".
Or possibly the subjects are not clear enough.

Now, suppose you do not like to read any lenghty text at all, then here is just a very short "reasonable" description:

A "bootkit" is code which might infect bootstructures (e.g. BIOS, MBR, VBR, EFI etc..), and / or, generally, patches or replaces
systemfiles (drivers/modules etc..), so that it is able to perform it's tasks using fundamental systemservices.
Usually, it is specifically associated with the boot of a system.

A "rootkit" is often named in one sentence with a "bootkit". However, a "bootkit" should act like described above,
while a "rootkit" might be just a replacement of systemfiles or commands, or it is code which is also able to use systemservices,
like in getting Administrative privilege, or patching/replacing systemfiles etc..
But it is usually not specifically associated with the boot of a system.

Furthermore:

=> A bootkit, or rootkit, is generally assumed to be very stealthy and thus it's difficult to detect.

=> A bootkit, or rootkit, is generally assumed to aquire Admin control (root) "at some point", which enables it to perform actions with elevated privileges.

=> The two types are sometimes used interchangeably in some discussions and some articles.

But hold on... Seems that I have put already too much emphasis on "systemfile patching..., kernelhooks..., seizing Admin control...etc..".
As we will see later this note, people speak sometimes of "kernel mode" and "user mode" boot/root kits.

The characteristics listed above, are typical for "kernel mode" boot/root kits, while "user mode" root kits might be happy to live in "userspace" only.
Ofcourse, a true "bootkit" must certainly be associated with "kernel-mode", since it will attach itself "somehow" to the "boot" of a system.
Note: The kernel/user mode concepts will discussed later in this note.

Although "user mode" kits can be "nasty" enough (and even stealthy enough), for now, I think it's more interesting to study kernel mode than user mode.
So, I'am afraid the accent will be placed "a tiny bit" more to the "kernel mode" side.

However, quite a few people say that the true nuisance is mainly from user-mode Trojans and Kits, which don't care about the kernel or bootstructures.
I'am not sure of that statement: the kernel-mode bootkit is often a crafty, well-camouflaged structure, "just there" to make sure the true "payload" gets executed,
which often is malware that collect passwords, cardnumbers, or any other sort of sensitive data. Especially those bootkits, can be very "successful".

So, this is what this short note is about. I hope you like it, but it's probably only useful for an orientation on the subject.
Indeed: please be aware, that this is a "soft" document only, without any in-depth technical details.


1.1 Older interpretation, or, the original interpretation:


For instance, somewhere in the second half of the 80s, it was noted that on some unix platforms,
certain system software could have been altered, or replaced, by other software that performed
(more or less) the same as the original, but it did additional stuff as well.
Here, you might think of system utilities for the superuser (like commands), or binaries (like a network daemon),
or loadable modules, or libraries.
However, such a list is not complete, since even something like CGI scripts, or even something mundane like a log cleaner,
(which were compromised) were discovered, and were sometimes also classified into the rootkit category.

Anyway, we now understand an "early" interpretation of rootkits. The "root" in "rootkit" means that almost always
a comprimised utility was activated by the Unix superuser privileges, or it made some use of SETUID bits.

"Kit" often referred to the fact that the rootkit was often a set of modified files.

What the rootkit often tried to do, was to provide for "remote access", or creating "backdoors". However, any thinkable activity was
ofcourse possible.

Since here the compromised software does the expected behaviour as well, it's often seen as a characteristic for a rootkit module,
that it's pretty good in "hiding itself", and possibly even it's so clever to remove evidence of it's malware practice.

While rootkits still exists on Unix, it's fair to say that since the late 90s, procedures and awareness have progressively increased in strenght,
resulting in the fact that the likelyhood for getting a rootkit in a business environment (like using AIX, UX etc..)
is not so dramatically high anymore. But it's certainly not "0".
Since Linux is used by so many private persons, connected to the Internet, you might say that the threat of rootkits on Linux systems
is somewhat higher compared to the traditional Unixes. It's just simply more abundant compared to, for example, AIX.

1.2 Additional and newer interpretations (I): physical machines.


On Windows platforms, many rootkits are seen to be that sort of software that's able to "hook" into some
systemprocess, which either activates (parts of) the code itself, or makes it possible to access system services.

Here, if we consider the interpretation itself, there seems to be a large sort of "overlap" with viruses, and trojans.
For example, complex malware that executes early in the bootphase of XP, might be seen as a boot/rootkit by some experts.
Others may just speak of a bootsector virus, like code that activates when the MBR or bootsecor is read or executed.

However, there is no explicit "need" for the early bootphase to activate such malware. For example, some compromised usermode software
that's able to use an unpatched "Vulnerability in Windows which could allow for Elevation of Privilege"

Again, a typical characteristic seems to be, that this sort of malware is "pretty good" in hiding itself.
However, there seems not to exist one striking sentence that really would quicly define a rootkit on Windows.

So, some folks view a "rootkit" on the Windows platform, as having at least "some" of the following characteristics:

Listing 1:
  • Very "stealthy" code, that is, very difficult to observe using OS tools, or code that even escapes heuristic scanning.
  • Might use many sections that calls ordinary Winapi function, largely done for looking like "innocent" code.
  • Complex code, often using multiple modules, so, in some way, it looks like a "kit" again.
  • Might install itself (partly) in nonobvious locations (possibly even unallocated space).
  • Professional/elaborate code which suggest that "economic crime" is the main objective of the kit (however, it's not mandatory).
  • Possibly uses the MBR or other bootstructures, and may even "hide" clean copies of bootstructures.
  • May use a suitable systemprocess, or vulnerability, to get activated.
  • Uses system privileges when executing (parts of) it's code.
Still I think it's quite safe to say that "something" acts like a Windows rootkit, if it shows
a couple of the characteristics as shown in Listing 1 above, especially the first and last ones.

1.3 Additional and newer interpretations (II): Systems on Hypervisors

On some hypervisors, it is in such a way implemented, that a VM of the x86/x64 class, inherits it's virtual bios or mbr
from a binary resource of the hypervisor itself.

Although I have some difficulties in establishing the sanity, or reliability, of some articles dealing on that subject, it is clear
that this could represent a grim scenario.
You can make your own LAB or Test environment, and see for yourself that there are one or two things to worry about.

Evidently, if it turns out that this shared binary resource gets compromised, it might effect all VM's on the Host, or even
all VM's in the cluster of Hosts.

Maybe I have something usefull to say on this as well. If so, it will get into this note.

1.4 Some Malware terminology:


In some articles you may find that rootkits are described in such a way, that it seems that they are pretty close to for example "viruses" and/or "trojans".
There indeed exists many different terms or names. And, while time progressed, the distinction somewhat blurred.

The following link will give a short overview on some of the most common malware types:

Most common malware types and descriptions.

1.5 Scope of this ridicoulus simple note:


In this very small and simple note, I will only concentrate on malware that gets active in the early bootphase of Windows systems.
This thus might also include systems that run on a hypervisor, which somehow inherits it's virtual bios or mbr from the compromised hypervisor.

So, in these cases we may view the subject as "rootkits" that acts like "bootkits", or malware that infects, or alters, bootcode or startsequences of the OS.

Why focus on bootkits? In my personal opinion, the potential of "future" crafty bootkits, even on strong firmware, or hypervisors,
might never be underestimated. It might well be that they turn out to be hard to combat.
If you would ask me: they will get a "high risk potential". So, it's interesting stuff to study, and in the process, you prepare yourself with knowledge.

However, this short note is probably only usefull for orientation on the subject.



2. The "Helicopter view": Wild bootkits, PoC's, and the problem:

Depending on which resource (like websites, articles) you study, you will find that larger and shorter "lists" exists of rootkit variants.
When it comes to bootkits, the listings seems to shorten quicly. That's not to say that it is a short listing.

Also, from chapter 1, we know that exact definitions are quite hard to make, and sometimes distinctions between malware types is a bit blurred.

We need some highlevel info before we try to understand how bootkits might work.

2.1 The main elements in the Early boot:


Code with the "wrong attitude" that activates during the earliest bootphase, is of special concern ofcourse. For one thing, public available Anti Virus (AV) software
will only get alive after the first bootphases.

So, AV software in general, is not of much help in the early boot.

Ofcourse, after the bootphase is passed, up-to-date good AV software probably is able to detect an installed bootkit.
However, you might feel that "you are too late now".

But the "threats" can be exeggerated as well. You certainly do NOT need to reformat everyting and reinstall the OS and everyting else.
However, regrettably, that cannot be garanteed ofcourse.

There exists a number of types of booting a system, like from a LAN, or from disk etc... We are primarily interested in disk based boottypes.

Main Disk based Boottypes
:
1. BIOS/MBR Based boot of a physical machine:

For PC "like" systems (like PC's /laptops, and Servers) using Windows, the "MBR based boot" exists for decades now!
So, everyting up to XP and Windows Server 2003, was MBR based. Later versions (like Win2K8 Server) can use MBR as well, but they can also boot from EFI firmware.
It's just a fact that the MBR, and the sectors following the MBR, in the default configuration, can be easily "altered" to transfer control,
to say, another legitimate bootloader, or malware.
If you ever installed Linux next to Windows (in multiboot, not VM), you know that it can install the "grub" pointer in the MBR,
which points to the grub bootloader.
Ofcourse, in this case the machine is fully at the disposal for the Linux setup (Windows is down), but it's just an example how pointers
can be rerouted to another bootsequence.

2. EFI Based boot of a physical machine:

EFI use a different methodology compared to (1), and more about that later.

3. MBR or EFI Based boot of a Virtual Machine:

It is actually mostly the same as (1) or (2). However, the source of the early bootcode could have been provided by some resource
of the hypervisor itself.


So, "worries" exists that bootstructures "somewhere" might have been altered.

By the way, not only at the early bootphases, a kit might seize Administrative control. It might also happen when the system
is fully up-and-running. However, typically, up to now, kits often places hooks and patches at the early boot.
A few solutions exists to battle lowlevel bootkits that would want to change bootcode and bootsectors:

Listing 3:
  1. Use EFI with NVRAM to boot from, instead of the older MBR implementation.
  2. Use special NVRAM, or a harware chip, that store the signatures and other info, of everything involved in the low level bootprocess.
  3. Implementing a "Secure Boot", or "Trusted Boot" which involves verification for EFI objects, all the way up to the boot manager.
  4. Full encryption of full volumes. However, bootstructures like MBR does not allow easily for encryption.
  5. A distributed system that garantees that Servers in a defined group are, and stay, in a "precise defined state".
  6. Launch of a anti-malware driver at the earliest possible stage, which can validate critical code at a later stage in the boot.
These are all serious options.
In this "ridicoulus simple note", we will discuss the MBR, and EFI boot, in more detail later on.

For now, we can say that the EFI based boot (item 1) is unfortunately already shown, not to be "unbreakable".
Note that I'am not saying that the "Trusted Boot" has been compromised.
Although some claims go around, it's seems very unlikely that it actually happened in a real-world situation.

Since in this note we must have a reasonable understanding of the various sorts of Windows boots,
take a look at figure 1. It shows a very schematic representation of an BIOS/MBR boot (like XP),
or an EFI type boot of a modern OS like Win2K8. Please note, that with even a modern OS, you can still opt
to implement the traditional BIOS/MBR bootphase. In that case, you "fall back" to the weaknesses of this type of boot.

Fig. 1. Very schematic representation of the early boot of a Windows system.



The picture above is so much simplified, that it's almost faulty: the real bootsequences are really quite more complex.
However, we must start somewhere. And the figure above certainly shows the main elements in the early boot.

We will describe the various stages of this early bootphase in more detail in chapters 3 and 4.

Later on, we will sometimes refer to the full bootsequence, so the figure below represents a very schematic representation
of the full boot of a Windows system. Note that we again, have distinguished between a BIOS/MBR boot, and an EFI boot.

Fig. 2. Very schematic representation of boot of a Windows system.




As an additional remark, please think about this as well:

  • During boot, you might say that not all security measures are in place yet. Or better: other security measures are the
    primary defense, compared to a fully booted system. For example, we fully rely on what's implemented in EFI, up to "bootmgr/winload".

  • When a system is fully up and running, every measure that's supposed to be there, is now functional (including your AV). So, generally speaking it's harder
    for malware to get elevated priviliges, or to patch systemfiles (unless an account is logged on as a superuser and is quite careless about his/her actions).


2.2 PoC's:


Researchers in the security fields, do an awfull lot of work ofcourse, but two things are important here:

=> Researchers Work: "Prove of Concept" malware and bootkits::

Some technical researchers, active in the security field, produce code themselves that can be viewed as "Prove of Concept" malware.
They do this, to test Operating System releases, test claims of Manufacturers on security, and explore develoment tools etc..,
all done to find out "how far they can go" and ofcourse to study all effects.

When it comes to bootkits, the emphasis lies ofcourse to explore all possible ways to manipulate the bootsequence,
and how to become as "stealty as possible".

=> Researchers Work: finding the bugs, or weaknesses, in the OS that lead to "Elevation of rights":

One important question always is: using "what" mechanism, either "as designed" or "as a bug", may lead to "Elevation of Privileges".
For example, a user is logged on to his workstation, as an ordinary user and not as an Admin. Then the user clicks a control on a webpage.
Is it then possible that the code somehow tries to get Admin rights, and succeeds, and perform illegal actions?

As you know, Microsoft regularly publishes security updates which fixes found bugs, to remedy unwanted "Elevation of Privileges".
MS does that, because sometimes they discovered the issue themselves, but more often it is due to discoveries done in the Security industry,
or from the Academic world, or from open communities, or by just a clever person who has just run into the issue.

As we will see, especially UAC, split tokens, and manifests, have features that might amaze you.


2.3 Kernel mode and User mode kits:

Sometimes, a distinction is made between "kernel mode kits" and "user mode kits".

Kernel mode kit:
"Kernel mode" code is understood to be code running in "ring 0", and may utilize privileged instructions.
The Windows kernel runs in "ring 0", and for example drivers run in "kernel mode" as well, or ring 1 or ring 2.
So, if a kit has placed a "hook" (or has "patched") such a module, it may utilize privileged instructions as well.
It's quite natural to think that the kernel mode kits are the most dangerous ones.

The concept of "rings" is an abstraction on the level of access to critical instructions (or level of access), and relates directly
to the cpu/machine architecture. Ring 0 has the highest level, while ring 3 the lowest level. User applications run in ring 3,
and must use services offered by lower levels.
In most OS'ses, people say that applications use system call interfaces, to communicate with lower services (like the kernel).

User mode kit:
Applications use a system call interface, like the WinApi on Windows. A rootkit might just use higher level services to perform it's "task",
or just start in user mode (e.g. to download something), and later on try to elevate to kernel mode.
However, when a kit uses userspace only, most people would speak of a user mode kit.


2.4 Some security improvements in modern Windows Servers and Clients:

If you still have them: you should probably "do away" all your XP and Win2K3 Servers as soon as possible.
Since MS support for XP is over, as of april 2014, there will be no more updates/patches published.

It's really fair to say that those versions expose a too large attack surface.

However, the "freedom" for e.g. developers on XP pro, was rather "gentle" compared to, say Win7.
For example "driver signing" on Win7 x64, is sort of "mandatory" feature, so for smaller developers (lower on $$), or home users,
it's sometimes seen as a real pain.
That's simply so, since the official way to get drivers verified and signed, costs them money.

However, if you would take a viewpoint from "stability" and "security", the following limited list of features certainly enhances security on modern Windows OS'ses.
If you are unfamiliar with those concepts: they are only very briefly touched here, and you are encouraged to do a Web search for more information.
I only briefly decribe them here, since it's possible that I mention them in later parts of this note.

1. DEP:

Supporting "Data Execution Prevention" (DEP)" was introduced in XP SP2 / Win2K3 SP1.
Essentially it is a technique which prevents code injected or sprayed in datapages or heaps in memory, that it gets executed.
This is so, because those pages are flagged as "non-executable". Hardware-based DEP is tied to the cpu architecture, but all modern
cpu's support it (NX flag).
There are several DEP options (from less strict to more strict) possible, which we don't discuss here.

2. ASLR:

As of Vista/Win2K8, you can make use of ASLR, if the code supports it.
ASLR or "Address Space Layout Randomization" is a technique to randomize the offsets of the position of headers, the executable, libraries,
heaps, and the stack, in the process's address space.
This makes it harder for attackers to change pointers or insert shell code. However, if the program cannot handle this, it will crash.

3. EFI (UEFI) boot:

As of Vista/Win2K8, an EFI based boot is supported. This means that the former (traditional) MBR/VBR boot (see chapter 3) is not neccessary anymore.
As you will see in chapter 3, the MBR/VBR area's, are a very attractive sort of "red light district" for bootkits.

4. Driver signing:

On modern x64 OS'ses: drivers (and other critical modules), must be "signed" and carry a supported certificate in order for the OS to execute them.
There are plus- and minus points to consider here. But, it's fair to say that it's a good thing for stability and security.

However, several advanced boot/root kits have already shown that they can bypass or circumvent this feature, which might raise some questions...

5. Trusted Installer or "Windows Resource Protection":

For example, NTFS based directories and files are protected by "ACL's", what means that such ACL is a structure in a filesystem object (like a file),
listing the SID's of Groups and Accounts, and which "Access Rights" they have (like Read, Execute, Full Control etc..).

You have seen it countless of times. On a NTFS volume, if you rightclick an object (like a directory), and choose Properties,
you can see the "security" associated with that object (the list of access rights of groups and/or accounts).

Not only "filesystem objects" are secured by ACL's, but other objects as well, like Registry keys, programmatic objects, AD objects, printers etc...

One of the exceptions to deviate from the "defaults", is if you need to grant Groups access on a resource on a Server, like some directory
on a File Server, or a printer on a File/Print Server etc..

Rather trivial remark: Never "just" change ACL's that are associated with OS related objects.

As of Vista, an additional "mechanism" protects system related objects
.
It's done by the "Windows Modules Installer service" (TrustedInstaller.exe), which works in such a way that ACL's of system objects are owned
by the "trusted installer". So, in some cases, even an Admin cannot modify these objects. You should really view it as a security enhancement.

However, in some cases, just "some" (old) Program Directories (which you think may be deleted), are owned by the TrustedInstaller as well.
That can be a bit annoying. If you need to delete or modify it, then you must change ownership of the objects.

However, such actions must certainly be limited. Be carefull not to "mess" with Trusted installer owned objects.

6. UAC, Split Token, Stripped Token:

User Account Control, or UAC, is a new security component since Win2K8 and Vista (althoug actually earlier versions existed).
I'am sure you have "experienced" UAC quite often.
Many find it quite "irritating", due to the endless "security dialog boxes" that keeps popping up. However, it can be
switched on/off or put in various levels. In general, you should view UAC as a security enhancement, nomatter how annoying it may be.

UAC starts when a user logs onto a machine. Let's see what happens with an interactive logon. The Local Security Authority (LSA)
uses the credentials (account+password) and performs the initial logon. Then it will evaluate the user's token to find what are defined as elevated privileges.
If elevated privileges are found, it will filter this token, and "strip" the higher privileges "out".
The user might me member of standard group(s) (like Server Operators etc..) with higher permissions, or some system permissions were directly granted to the user.
These privileges are all stripped out, and the former fully privileged token is saved by LSA. The full one can still be obtained, so
the tokens keep being linked. This is also why some folks speak of "split tokens".

So, UAC is a measure to prevent a standard user to change "system wide settings", but also to (try to) prevent malware to take silently control, if you
are logged on as an Administrator.

When an administrator application is starting, by default a UAC dialog appears:

- If you are an Admin, the message gives a choice to allow the application to start or to prevent it from starting.
- If you are a standard user, the user can enter the user name and password of an account that is a member of the local Administrators group.

More in depth information on UAC and filtered tokens can be found in ref. 8.



3. Some furher notes on BIOS/MBR based bootkit on XP/Win2K3 with "MBR-Type" disks :

EFI or GPT as a "BOOT disk" is not available for XP/Win2K3 (booting is only supported for 64-bit Win2K3 editions on Itanium-based systems).
In this note, we have not dealt with EFI or GPT disks yet.

For use as a NON BOOT disk, for XP/Win2k3, thus for data etc.., they ofcourse can use GPT disks.
Since booting is an important subject in this chapter, it explains why we here focus on XP/Win2K3 with "MBR-Type" disks.

3.1 The mechanics of the BIOS/MBR/VBR at boottime:

PC technology have changed enoumously since the early '80s up to now. However, from the early periods up to 2010 (or so), the
BIOS/MBR bootphase of "Intel-like" PC's and Servers running Windows, was, in principle, more or less the same.
Today, manufacturers seem to offer primarily EFI machines (with an optional alternative BIOS/MBR traditional bootoption).

- As you can see in figure 1 above, the BIOS/MBR bootsequence is illustrated by the first row (the XP/Win2K3 illustration).
(Ofcourse, predecessors like NT4, Win2000, used - with minor differences - the same method).

- With newer OS'ses (like Vista/Win7/Win2K8 etc..), there are two main options: again the traditional BIOS/MBR method, or using EFI.
These are illustrated by the second and third rows in figure 1 respectively.

Now, let's take a look at figure 2. In this chaper, we specifically take a look at the upper row in this figure, that is the BIOS/MBR/VBR boot.

The upper row then could represent a XP/Win2K3 boot using MBR/VBR.
The lower row then could represent a Win7/Win2K8 boot using EFI.

This chapter deals with the bootsequence of XP/Win2K3.

It's also important to note that the machine is running in "real mode", up to the 16 bit stub (or part) of NTLDR,
after which this (by Microsoft provided) piece of code, switches the machine into "protected mode".

=> Overview of the Role of the BIOS:

In this chapter, we focus on the BIOS/MBR types of machines. So, it just all starts with the "BIOS".
When the machine is powered on a BIOS/MBR machine, the BIOS gets control almost immediately.

Although BIOS is often associated with "ROM", that is "unmoveable" hardwired code, actually it is often implemented as "flashable" PROM,
so it can be updated with a new release. In principle, this makes it "writeable".
Although measures are in place with BIOS flashes, like crc checks, it has indeed occurred that the BIOS was compromised on specific machines.

Although everybody knows the main functions of the BIOS, let's just briefly review it's main purpose:

  1. First we have the "Power On Self Test" (checking main hardware components, like memory etc..).

  2. Then we have the "export" of routines (interrupt vectors, "Int") to well defined (low) memory areas so that they can be called (by programs using BIOS).
    This "export" of routines is no more than reserving a specific areas in memory, to pass messages. So, suppose a real mode
    program wants to use BIOS interrupts, then it uses one such specific area as the interrupt number and passes along the function number
    with information added, to whatever needs to be done. This way, video can be manipulated, a disk can be read or written etc..

  3. Next is the optional loading "option ROMs" routines from BIOS'ses on special cards/controllers.

  4. And, finally, we have the locating and indentifying of a "bootloader" on a disk (here we assume it's a disk).

Notes:

- Ofcourse, about finding the (preferred) bootloader: there is more to it, since you know that you can adjust the order of
the list of searchable devices, using the interactive BIOS menu (like altering the preferred order of DVD, Harddisk etc..).
However, here we assume the "bootloader" is found on the first harddisk.

- You might remember the "DOS interrupts" from ancient times. They were used to create a consistent interface to an "Operating System", namely "MSDOS" (or "PCDOS" etc..)
But in many cases, DOS, while having more sophisticated funcions, it often used the BIOS routines.

- For more information on x86-type BIOS interrupts: see the "Ralph Brown interrupt listing" (ref 6 below). Here, for example, you can easily
find that "Int 13-02" means that a disksector needs to be read into memory.


If the bootable device is a harddisk, this bootloader is code in the MBR, the first 512 bytes on an MBR type disk.

The structure of the MBR is like this:

(1). The first 446 bytes of the MBR contains the "bootloader" and some elementary errormessages.
(2). After those first 446 bytes, you would see the "Partition Table", a 64 byte structure. Each table entry is 16 bytes long,
with the first byte of such an entry being the "Boot Indicator" field. This tells the code in (1) which partition is bootable.
If that partition is bootable, the boot indicator field carries the value "0x80".

=> MBR/VBR Boot

There actually exists a number of MBR implementations, but the "PC classical one", is discussed here.
  1. Traditionally, the BIOS indentifies the MBR by it's signature at the very end of this 512-byte sector (55 AA).

  2. Then it transfers control to the "bootloader" located in the first 446 bytes of the MBR.

  3. The bootloader reads the Partition table, and determines the bootable Partition (or VBR, Volume BootRecord)

  4. Control is passed to the VBR, which controls which OS dependent OS loader needs control (like NTLDR).

  5. NTLDR does (among other things), load the bootclass drivers, the HAL for this architecture, and the kernel (see figure 2).


3.2 Compromising the MBR:

You should preferrably have read section 3.1 first, before starting this one.
By now, we have a "reasonable" idea of the BIOS/MBR/VBR bootsequence (see section 3.1).

=> Compromising the MBR.


Let's take a look at a "sound" MBR of a "MBR-type disk":


Fig. 3. MBR of a MBR type disk.




It is just so implemented, that the BIOS loads MBR the at the fixed memory address "0000:7C00", and next jumps to it, meaning executes it.


Real Mode scenario:

Now, suppose a bootkit manages to get hold of Int13, then we know that it can access any sector, so sector 0 as well.
It might then modify the MBR, in such a way, that it puts a pointer (a Jump) in the MBR to itself, so that it gets executed "first" at any boot.
Also, it might have stored a "good" copy of the MBR at some other sector "nearby", or some other place.
Then, once the kit is loaded, a Jump is performed to the code in the good MBR, which then executes in the usual way.

So what we have then is the sequence BIOS->BOOTKIT->MBR->VBR etc..

Ofcourse when we talk of the "bootkit" here, actually often is just a small part, which might be a sort of "starter" for the major parts of the kit,
which probably is stored elsewhere.
Anyway, by creating a Jump to "itself" in the MBR, this code has managed to be the "first" live code in the system.

Maybe it sounds surprisingly simple. What we sketched here, is not much different from the bootsector viruses from the 80s and 90s.

From the perspective of the Kit, there are difficulties ofcourse. Once "up and running", your computer is not running a real mode OS like DOS,
where Int13 is easy to use.

But, the scenario above could happen if you booted when a compromised USB, DVD or other device, which was "touched" first by the BIOS,
thereby loading the malware, which then performs as described above.
However, once a NT family Windows system is "fully up", disk access goes by protected mode disk drivers.

But at the very early "real-mode" bootphase, the above scenario is actually possible.
So, it's still true that one should be alert on the fact, if possible "untrusted", and "bootable", external media is attached.

Note:
If you would take a look at ref. 2, you will see an article where somebody created an assembler program, which modifies the MBR,
to just display "Hello World", and then stops. It's actually a really nice and simple illustration of the theory above.


Protected Mode scenario in XP / Win2K3:

So, direct Int 13, or even the easy "Win9x" "VWIN32_DIOC_DOS_INT25/26" functionality, are not easily available when the protected mode OS is up and running.
For example, with the extinct OS'ses like Win95/Win98, a developer was indeed able to use ordinary functions, like those mentioned above,
for using those functions to realize reading and writing "sectors".
But, in the modern NT based OS'ses, just using high level programming environments and hoping to get direct disk access, is quite troublesome from
the perspective of the malware author.

Also, using regular assembler can be problematic too, since a huge addressing mismatch is in place. In protected mode, programs live in virtual memory, seperated from
other programs, and don't (or can't) use real memory addresses.

However, using a FLAT assembler, then it can be used to created programs on 32 bit protected mode platforms.
And generally, if we are really talking about XP/Win2K3, any agent using for example "DPMI translation service" might help too.

The malware authors are indeed criminals for sure, but they are not dumb. They study "driver stacks", they know all about the exported methods of the WinApi,
they know all there is to know about the "true" systemcall interface "ntdll.dll" (which even is not fully documented).
On the older XP/Win2K3, they also knew what there is to know about shell code, heaps and other memory structures.

And more importantly, they want to know all that there is to know about "vulnerabilities" in Windows modules.

Once a relevant "vulnerability" is found, which leads to Admin control, their code effectively runs in kernel-mode, and standard IO calls,
or non-standard IO calls, can be used, in principle, to read/write any disklocation they want.

Possible routes then are: (remember, this chapter deals with XP/Win2K3)
  • Using the general interface of the IO Manager, like using IRP (I/O request packets), which are "high level" requests to the driver stack,
    like e.g. "IRP_MJ_INTERNAL_DEVICE_CONTROL()" etc. In effect: using the regular way.
  • Overwrite/patch existing driver with "adjusted" code.
  • Add a "new" compromised driver and register it.
  • There is always contradictory information about interrupts in protected mode. Under XP, the DPMI translation service (function 300 with INT 31h)
    works "fine" with DOS interrupts, if flat thunks to 16 bits are possible. So, under a 32 bit protected mode OS, there are options for controling interrupts.
    On 64 bit, this game is quite "over".

3.3 Compromising of Sectors "nearby" the MBR, and the VBR:

=> 1. Sectors "nearby" the MBR.

Please be aware that with EFI and GPT, the situation is very different from what is described here and in sections 3.1, 3.2.
We will deal with EFI/GPT in chapter 4. So let's return to the "MBR-type" of disks that were used with XP/Win2K3.

We have seen the "traditional" MBR in section 3.2, as stored in sector 0.
The physical drive (the harddisk), however, is usually partitioned in to "partitions" (or "volumes").

Such a partition will have a starting "boundary" that will always start on a new cilinder (not the one the MBR is located on).

In the traditional situation, the sectors "left" from the MBR (so to speak) on the first cilinder, so just before the partition boundary, are a bit special.
Again, traditionally, these 62 sectors (numbered LBA 1 to LBA 62) are "officially" empty. Note that here we have 63 sectors, 0 being the MBR, and 62 unallocated.

However, on new types of drives, like the "e512" or "Advanced Format Drive", this "empty space" can be a lot "longer".
Also, due to a phenomena called "Partition Alignment", it is often chosen by Admins (or by the OS like Win2K8), to let the first partition
start at sector 2048. This then means about 1MB of empty space (which is not large ofcourse).

So:

-Traditionally, sectors 1-62 (while sector 0 is the MBR) are "officially" not in use.
-In a more modern setting (on a MBR-type disk), the first 1MB (or other "round" number of 32K), are empty, while 0 is the MBR.

However, this lost space in certainly not always "empty". Some bootmanagers might have altered the MBR, as being part of a "stage 1" boot,
while the "rest" of that bootmanager (stage 2, and possibly more stages) might be located in sectors near the MBR.

Be aware that other "special" sectors might be found too, in LBA 1 to LBA 62.

Contamination:

If the bootkit, as decribed in the above sections, got hold of control, through "booting" using the MBR, it could also be possible that
it stores parts of "it" in the empty sectors we have seen above. This may seem troublesome, but in this stage, if the kit is dead and cleaned
from the MBR, those sectors just contains "noise".

However, it's important that we know about such "tactics". So, a "live" bootkit might have stored code and data in those sectors near the MBR.

=>2. Volume Boot Record (VBR), or the Partition Bootsector:

=> "Partition Boot sector", or the "Volume Boot record".

From what we have seen before, the "Partition Boot sector", or the "Volume Boot record", might begin at the first new cilinder boundary.
So, we have the MBR in sector 0, then about 1 MB of unallocated secors (totalling 2047 sectors), then the VBR starts at sector 2048,
if indeed that Partition is the "active" (bootable) Partition.

Also that Partition is a range of sectors, but this time, viewable as a "drive" (C:, D: etc..) since it's formatted and a filesystem has
been placed on that Partition.
However, again, the first few sectors are "special" again. The first sector is the Volume Boot Record (VBR), or the Partition Bootsector.
But, depending on the type of filesystem of that Partition, the VBR might use several sectors on the Partition. But let's concentrate on the first one.

In this sector, a small amount of OS dependent "IPL code" is present, meaning on XP/Win2K3, that this code transfers control to NTLDR.
The BPB (see below) provides information for the executable portion of the VBR to be able to locate the NTLDR file.

If you would use Vista/Win7/Win2K8 with MBR-Type disks, then this code transfers control to BOOTMGR.

IPL is a general term, and means "Initial Program Load", which just is code for starting the bootloader of the Operating System (like NTLDR).

For refreshing your memory, and getting the facts straight, just take a look again at figures 1 and 2 above.

=> BPB.

As another important datastructure on the Partition, the "BIOS Parameter Block" (BPB) should be considered as well.
Many folks see the BPB as part of the VBR. Others treat it as an apart structure. Ofcourse, it's stored in sectors.

Be aware of the fact that in some articles, people talk of the "bootblock", which then must be seen as a number of sectors
at the beginning of the Partition, containing the "VBR" and "BPB". That's alright as well.

It's length is, among others, dependent of the type of filesystem (like FAT, NTFS).

It holds various "administrative" fields, like "the number of FAT's", "the number of Hidden Sectors", "MFT first cluster number", and many more.

Contamination:

The VBR/BPB, or "bootblock", is much more complex than the relatively simple MBR (of an MBR-type disk).
However, if the bootkit wants to do something "usefull" with the information, it should be able to interpret certain fields.

Using the VBR/BPB, the bootkit, for example (among other things) might be able to:
  • Locate NTLDR, and patch it. Remember, if the bootkit gets live at boottime, on XP/Win2k3, the system still runs in real-mode,
    the VBR/BPD can be read (and possibly altered), interrups can be utilized, and read/writes can be done.
  • Install data and code in empty sectors in the cilinder where the MBR sits, or install in the Partition.
A bootkit could do much more than wat is listed above. But, what you see here, are actions that can be relatively easy "implemented".


3.4 Some notes on how to repair MBR/VBR corruption/problems:


Recently, I decided to place "repair options" in a seperate note. If you have interest in how to repair MBR/VBR systems, you might
want to check Chapter 2 of the following note:

A simple note on how to repair bootstructures.



4. Some furher notes on a EFI bootkit:


Recently, I decided to place "repair options" in a seperate note. If you have interest in how to repair EFI/GPT systems, you might
want to check Chapter 3 of the following note:

A simple note on how to repair bootstructures.



5. Some furher notes on a "user-mode" bootkit:




Appendices:


1. Articles/References:

(1): Mebromi: the first BIOS bootkits in the Wild
(2): Simple example of altering the MBR to boot to only display "Hello World"
(3): UEFI Boot Tech Paper
(4): MBR/EFI NT Boot process
(5): UAC and IE protected mode.
(6): Ralph Brown Interrupt lists (1)
(7): AAM and UAC
(8):Teach Your Apps To Play Nicely With Windows Vista User Account Control
(9): Example of a site with "drive-by install"
(10): Simple, effective, analysis of "drive-by install"
(11): Bootkit threats (general paper)
(12): ESET article: The Evolution of TDL (TDL4) (1)
(13): TDSS - TDL4 (2)
(14): ESET article: Root of Evil (general paper)
(15): Kleissner's pdf on Stoned
(16): Short description Sinowal
(17): Short description Vbootkit 1.0 (PoC on Vista architecture)
(18): Short announcement on release Vbootkit 2.0 (PoC on Win7 architecture)
(19): XPAJ trojan/bootkit variants
(20): Trojan.Mayachok.2: analysis of a VBR-bootkit
(21): Analysis of a MBR rootkit
(22): Examination of the Win7 VBR
(23): Writing a Kernel driver
(24): Stealth MBR rootkit (gmer.net)
(25): Some other notes to clean the MBR


2. Just a few points (or keywords) to consider for Windows system hardening:

You might want to take a look at this short note.