Malware targeting banks, payment card processors, and other financial services has found an effective way to remain largely undetected as it plucks sensitive card data out of computer memory. It hijacks the computer’s boot-up routine in a way that allows highly intrusive code to run even before the Windows operating system loads.
The so-called bootkit has been in operation since early this year and is part of “Nemesis,” a suite of malware that includes programs for transferring files, capturing screens logging keystrokes, injecting processes, and carrying out other malicious actions on an infected computer. Its ability to modify the legitimate volume boot record makes it possible for the Nemesis components to load before Windows starts. That makes the malware hard to detect and remove using traditional security approaches. Because the infection lives in such a low-level portion of a hard drive, it can also survive when the operating system is completely reinstalled.
“The use of malware that persists outside of the operating system requires a different approach to detection and eradication,” researchers from security firm FireEye’s Mandiant Consulting wrote in a blog post published Monday. “Malware with bootkit functionality can be installed and executed almost completely independent of the Windows operating system. As a result, incident responders will need tools that can access and search raw disks at scale for evidence of bootkits.”
Nemesis is by no means the first malware to hijack a computer’s normal boot process to gain persistence and stealth. TDL, a Windows rootkit that also goes by the name Alureon, has been doing the same thing for more than five years. Early this year, a security researcher created a proof-of-concept attack for Macs that covertly replaced the firmware that boots up most modern OS X machines. (Apple has since patched the weakness.) Still, the adoption of the technique by Nemesis is an indication it is becoming more viable in real-world computer attacks, particularly those targeting financial institutions.
The volume boot record is a small piece of code specific to an operating system that’s located in the first sector in an individual partition. It contains instructions for the OS code to begin the boot process. The process typically looks like this:
Nemesis hijacks the normal sequence using an installer dubbed “BOOTRASH.” It invokes a multi-step process that involves the creation of a virtual file system that stores malicious components in unallocated space between partitions. In Monday’s post the researchers wrote:
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.
The researchers went on to write:
The bootkit intercepts several system interrupts to assist with the injection of the primary Nemesis components during the boot process. The bootkit hijacks the BIOS interrupt responsible for miscellaneous system services and patches the associated Interrupt Vector Table entry so it can intercept memory queries once the operating system loader gains control. The bootkit then passes control to the original VBR to allow the boot process to continue. While the operating system is being loaded, the bootkit also intercepts the interrupt and scans the operating system loader memory for a specific instruction that transfers the CPU from real mode to protected mode. This allows the bootkit to patch the Interrupt Descriptor Table each time the CPU changes from real mode to protected mode. This patch involves a modified interrupt handler that redirects control to the bootkit every time a specific address is executed. This is what allows the bootkit to detect and intercept specific points of the operating system loader execution and inject Nemesis components as part of the normal kernel loading.
The malware code is stored either in the virtual file system or in the Windows registry, making it largely invisible to normal antivirus programs. That leaves live memory as one of the only places where the malware can be detected. What’s more, unless the bootkit and virtual file components are removed, the malware will execute and load every time the system starts even if the operating system partition has been wiped and the OS is reinstalled. To eradicate the malware, system administrators must perform a physical wipe and then reload the operating system. Significantly, Nemisis won’t install itself on computers that use GUID partitions which were introduced as part of the Extensible Firmware Interface initiative and are an alternative to the older master boot record. At least for now, use of this newer technology is a key way financial services firms can protect themselves from this threat.
Post updated in the last paragraph to add details about GUID partitioning.