These comments made it an interesting target for analysis with a view to examining the techniques that are used by what is widely considered to be a state-sponsored and sophisticated actor in deploying offensive cyber-weaponry.
We were able to acquire samples and, with a particular interest in the component called 'SGH' which was described by Kaspersky as the most advanced part of The Mask’s toolset, we began to analyse them. SGH is elsewhere described as having 'bootkit' functionality which is particularly intriguing for its potential functionality as well as power over a target system.
A bootkit is generally understood to mean a rootkit-style agent that has ‘infected’ the boot process of a system. To have malicious code running at the very beginning of the loading of an operating system allows the code to take control and subvert the security of the operating system before it has even started; as such it has the potential to be a very potent weapon.
Despite this fact, the bootkit aspect has come under little scrutiny in the analyses by the AV vendors, so it stood out as the most interesting area to focus on in our research.
Upon examination of SGH, it became clear that the ‘bootkit’ label refers to a subroutine which patches the bootmgr executable file that underpins the Windows boot process. Since the release of Vista, modern Windows systems can boot using one of two technologies: the modern Extended Firmware Interface (EFI) and the legacy BIOS-based system that has been present in IBM PC-compatible personal computers since the days of DOS.
In the case of BIOS-based systems, which comprise a significant number of Windows systems today, the chain of execution during the boot process is as follows:
It might be surprising to note that this early code executed in the MBR, VBR and the beginning of the bootmgr executable is run in 16-bit ‘real’ mode - a legacy mode of the IA32 architecture which PC processors start in. This is true even of modern 64-bit systems that still have a BIOS.
When faced with a binary comprised of 16-bit code and the real mode of IBM-compatible PC architecture, it seems that the question the malware authors posed themselves was “why reinvent the wheel?” - virus writers in the 80s and 90s invented many ingenious 16-bit tricks and techniques. Early in virus evolution, the infection mechanism of file-appending was pioneered, and The Mask demonstrates that this simple technique can still be effective today. Old tricks are sometimes the best it seems, as the method by which SGH achieves its bootkit functionality and infects the bootmgr binary is to employ this ‘old skool’ 16-bit infection strategy straight from the history books.
Although in the specific sample we analysed, the function used to patch the bootmgr is not actually used, it is still present and we can infer how it works by reverse engineering the code. It is apparent upon analysis that the function expects two chunks of data; the first is interpreted as the size of the code to be appended to the bootmgr binary, the second is the data, taken as the raw bytes of code, to be appended to the target.
The function begins by reading the first three bytes of bootmgr. If we disassemble this binary (remembering to choose 16-bit as our architecture) we can see that the very first instruction at the entry point is a jmp instruction which takes three bytes to encode.
The first byte (0xE9) is the byte that defines the instruction as a jmp, the next two bytes are the offset, or the relative distance, to jump to. This distance is taken from the address following the jump, which is three bytes in size. In the above case (with bootmgr taken from Windows 7 x64 SP1) these bytes are 0xD5 and 0x01, which when interpreted as a little-endian value, is 0x1D5, so the resulting target is 0x1D8. Thus, upon execution, the code in bootmgr immediately jumps forward to this address where it continues execution.
This next section of code is the area the SGH bootmgr-infecting function targets for modification or ‘patching’. In order to be able to reliably locate this code across multiple potential versions of the bootmgr binary, perhaps due to different Windows versions, SGH follows this initial jump, and then goes to the target location. Here the first thing it does is to check whether the executable has already been infected. In traditional terminology it checks for an infection marker, which in this case means it checks whether the code here has been patched before:
If it finds the executable has already been patched, it terminates here as there is no point in repeating this (not to mention the complication of appending its own code later multiple times).
If it finds that the executable has not already been infected, it reads 8 bytes which it stores for later, just like a classic virus would, before overwriting them with an indirect jump to the end of the file. This jump is encoded in 8 bytes, with two push instructions followed by a retf or ‘far return’ which pops the values just pushed to the stack and interprets them as a segmented address which is the memory implementation used in the 16-bit real mode of x86-compatible CPUs.
A segmented address consists of segment and offset, and here the retf takes the two values pushed as code segment and instruction pointer, putting the values into the corresponding registers and thus effectively jumping to that address. The values that SGH places here are calculated using the current location and file size, and so SGH redirects the execution flow to the end of the file, where of course it appends its own code, as well as a copy of the 8 original bytes it overwrote from the initial patch it made.
Old school diagram of old school infection technique.
Because the sample we have seen doesn’t actually use this patching function, we of course haven’t seen what code is intended to be appended to the end of bootmgr, or what purpose it serves. But to have control over the operating system at such an early stage of course imparts great power, so we are very keen to get hold of other samples to see if any of them make use of this feature. In the meantime we are left to wonder whether this resurgence of the 16-bit file-appending infection is due to its simple effectiveness, or whether there is an element of recognition and respect for the original technique and the classic virus writing scene. Perhaps the very same talented virus writers, who back in the 80s and 90s pioneered this and other virus techniques, have now been recruited by the organisation behind The Mask and are working to develop their cyber-weaponry arsenal. In which case the rest of the world beware!