Thriving Beyond The Operating System: Financial Threat Group Targets
Volume Boot Record[html]
In September, Mandiant Consulting identified a financially motivated
threat group targeting payment card data using sophisticated malware
that executes before the operating system boots. This rarely seen
technique, referred to as a ‘bootkit’, infects lower-level system
components making it very difficult to identify and detect. The
malware’s installation location also means it will persist even after
re-installing the operating system, widely considered the most
effective way to eradicate malware.
We first identified this activity during a recent investigation at
an organization in the financial industry. We identified the presence
of a financially motivated threat group that we track as FIN1, whose
activity at the organization dated back several years. The threat
group deployed numerous malicious files and utilities, all of which
were part of a malware ecosystem referred to as ‘Nemesis’ by the
malware developer(s),[1] and used this malware
to access the victim environment and steal cardholder data. FIN1,
which may be located in Russia or a Russian-speaking country based on
language settings in many of their custom tools, is known for stealing
data that is easily monetized from financial services organizations
such as banks, credit unions, ATM operations, and financial
transaction processing and financial business services companies.
Nemesis, the malware ecosystem used by FIN1, includes comprehensive
backdoors that support a variety of network protocols and
communication channels for command and control (CnC). It provides a
robust set of capabilities, including: file transfer, screen capture,
keystroke logging, process injection, process manipulation, and task
scheduling. The threat group continually updated the Nemesis malware
during their ongoing access to the victim environment, deploying
several different variants of the same tools and adding functionality
between iterations. In early 2015, FIN1 updated their toolset to
include a utility that modifies the legitimate system Volume Boot
Record (VBR) and hijacks the system boot process to begin loading
Nemesis components before the Windows operating system code. We refer
to this utility as BOOTRASH.
A Brief Refresh
On a Windows system, the Master Boot Record (MBR) is critical to the
boot process. The MBR stores information about the disk, including the
number and layout of any partitions, and a small amount of code used
during the boot process.[2] This code searches
for the primary active partition, and passes control over to that
partition's VBR.[3]
A VBR, on partitioned devices, is located in the first sector of an
individual partition. The VBR contains machine code specific to the
operating system or program on that partition. For example, in
situations where more than one operating system is installed on a
computer, each operating system is installed on a separate partition
and each partition contains a VBR with instructions on how to start
the respective operating system.[4] The VBR
instructs the operating system code to begin the boot process, which
involves loading the necessary software into memory.
Figure 1 depicts a simplified boot process. The MBR loads the VBR,
which loads the operating system code. BOOTRASH hijacks this boot
process in order to load the Nemesis payload before the operating
system boots.
Figure 1. Simplified normal boot process
BOOTRASH Step by Step
To successfully hijack the boot process, the malware first uses a
complex multi-step process to create a custom virtual file system name="_ftnref5">[5] to store the Nemesis components in the
unallocated space between partitions. It then hijacks the original VBR
by overwriting the bootstrap code with its own malicious code. The
bootstrap code calls the Nemesis bootkit, which intercepts certain
boot process functions and injects the Nemesis components into the
Windows kernel. Following is a description of the installation and
hijacking process:
Step 1: System Checks
Prior to installation, the BOOTRASH installer gathers statistics
about the system, including the operating system version and
architecture. The installer is capable of deploying 32-bit or 64-bit
versions of the Nemesis components depending on the system’s processor
architecture. The installer will install the bootkit on any hard disk
that has a MBR boot partition, regardless of the specific type of hard
drive. However, if the partition uses the GUID Partition Table disk
architecture, as opposed to the MBR partitioning scheme, the malware
will not continue with the installation process.
The malware checks to make sure a copy of the BOOTRASH installer is
not already running on the system. It also checks to see if the
Microsoft .NET 3.5 framework is installed on the system - a
prerequisite for the malware. If the installer is already running or
the .NET framework is not installed, the malware will quit.
Step 2: Available Space Calculations & Virtual File System Creation
BOOTRASH creates its own custom virtual file system (VFS) to store
the components of the Nemesis ecosystem. The malware performs several
calculations to determine the positioning of the file system and
whether the system has enough space to fit the file structure.
To determine how much space is needed for the installation, the
malware uses Windows Management Instrumentation (WMI) to query the
system’s boot disk and partition. The malware then calculates the
total size of the 32-bit or 64-bit components to ensure there is
enough space for the custom file system in the free space between the
system’s partitions.
Step 3: Boot Sector Hijacking
The installer reads the original boot sector into memory and saves
an encoded backup copy of the VBR code at 0xE sectors from the start
of the partition. Next, the malware applies two algorithms
(CRC16-CCITT and MD5) to the original boot sector in order to check
its integrity at a later time. With the original boot sector saved,
the malware decodes the new bootstrap code from one of its embedded
resources and overwrites the existing bootstrap code, effectively
hijacking the boot process of the compromised system.
Step 4: Nemesis Component Installation
The installer always uses the virtual file system for saving the
three components responsible for creating and installing the bootkit:
vbr.bin, vbs.bin, and bootldr.sys.
