Introduction

The subject of exploiting user-mode vulnerabilities and the payloads required to take advantage of them is something that has been discussed at length over the course of the past few years. With this realization finally starting to set in, security vendors have begun implementing security products that are designed to prevent the exploitation of user-mode vulnerabilities through a number of different techniques. There is a shift afoot, however, and it has to do with attacker focus being shifted from user-mode vulnerabilities toward the realm of kernel-mode vulnerabilities. The reasons for this shift are due in part to the inherent value of a kernel-mode vulnerability and to the relatively unexplored nature of kernel-mode vulnerabilities, which is something that most researchers find hard to resist.

To help aide in the shift from user-mode to kernel-mode, this paper will explore and extend the topic of kernel-mode payloads on Windows. The reason that kernel-mode payloads are important is because they are the method of actually doing something meaningful with a kernel-mode vulnerability. Without a payload, the ability to control code execution means nothing more than having the ability to cause a denial of service. Barnaby Jack and Derek Soeder from eEye have done a great job in kicking off the public research into this area[2].

Just like user-mode payloads on Windows, kernel-mode payloads can be broken down into general techniques and algorithms that are applicable to most payloads. These techniques and algorithms will be discussed in chapter . Furthermore, both user-mode and kernel-mode payloads can be broken down into a set of payload components that can be combined together to form a single logical payload. A payload component is simply defined as an autonomous unit of a payload that has a specific purpose. For instance, both user-mode and kernel-mode payloads have an optional component called a stager that can be used to execute a second logical payload component known as a stage. One major distinction between kernel-mode and user-mode payloads, however, is that kernel-mode payloads are burdened with some extra considerations that are not found in user-mode payloads, and for that reason are broken down into a few more distinct payload components. These extra components will be discussed at length in chapter .

The purpose of this document is to provide the reader with a point of reference for the major aspects common to most all kernel-mode payloads. To simplify terminology, kernel-mode payloads will be referred to throughout the document as R0 payloads, short for ring 0, which symbolizes the processor ring that kernel-mode operates at on x86. For the same reason, user-mode payloads will be referred to throughout the document as R3 payloads, short for ring 3. To fully understand this paper, the reader should have a basic understanding of Windows kernel-mode programming.

In order to limit the scope of this document, the methods that can be used to achieve code execution through different vulnerability scenarios will not be discussed at length. The main reason for this is that general approaches to payload implementation are typically independent of the vulnerability in which they are used for. However, references to some of the research in this area can be found in the bibliography for readers who might be curious[4]. Furthermore, this document will not expand upon some of the interesting things that can be done in the context of a kernel-mode payload, such as keyboard sniffing. Instead, the topic of advanced kernel-mode payloads will be left for future research. The authors hope that by describing the various elements that will compose most all kernel-mode payloads, the process involved in implementing some of the more interesting parts will be made easier.

With all of the formalities out of the way, the first leap to take is one regarding an understanding of some of the general techniques that can be applied to kernel-mode payloads, and it's there that the journey begins.