Thriving Beyond the Operating System: Financial Home Fireeye Blogs Research Th

Menu Threat Thriving Beyond The Operating System: Financial Home FireEye Blogs Research Th... Share December 07, 2015 | By Dimiter Andonov, Willi Ballenthin, Nalani Fraser, Will Matson, Jay Taylor | Threat Research, Advanced Malware 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[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. The rest of the components can be either saved in the virtual file system or as binary data within the HKCU\.Default\Identities registry keys. These components are responsible for the primary C2 functionality of the Nemesis ecosystem that includes: file transfer, screen capture, keystroke logging, process injection, process manipulation, and task scheduling. Table 1 details the associated registry keys. Registry Value Name File Content HKCU\.Default\Identities\{3D04DDFA-AE6F-4BC2- core.sys 9AE6-4A76A471147A} HKCU\.Default\Identities\{424D9649-5B57-4C9B-A55A- vfs.sys 00D6CD382092} HKCU\.Default\Identities\{AA1F2588-670C-450E-833B- nemesis.sys C8CAAF26DA5E} HKCU\.Default\Identities\{95E4F335-E152-4778-B3B0- injproxy.dll 3422B37B3A3D} HKCU\.Default\Identities\{C34C01DC-8E9D-40AF- loader.dll 82FF-79DB2735C333} HKCU\.Default\Identities\{4EED1600-54C9-471E-B74F- nemesis.dll 2A88BAC188B4} HKCU\.Default\Identities\{36203264-DFF1-43AC- nmscfg.dat 94AD-096592297776} Table 1: Nemesis components optionally saved as registry values Step 5: Hijacked Boot Process As previously discussed, during a normal boot process the MBR loads the VBR, which loads the operating system code. However, during the hijacked boot process, the compromised system’s MBR will attempt to load the boot partition’s VBR, which has been overwritten with the malicious BOOTRASH bootstrap code. This code loads the Nemesis bootkit components from the custom virtual file system. The bootkit then passes control to the original boot sector, which was saved to a different location on disk during the installation process. From this point the boot process continues with the loading and executing of the operating system software. Figure 2 illustrates the hijacked boot process. Figure 2. Simplified hijacked boot process 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[6] 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.[7] 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. Uninstall Option BOOTRASH has a built in option for restoring the original boot sector, in the event that the threat actors wish to remove the hijacking process. This option only restores the original boot sector – it does not remove the custom virtual file system or the backup VBR that was created by BOOTRASH. Other Bootkits Malware that persists by compromising the MBR or VBR is unusual, but not unknown. ESET documented their technical research into bootkit malware families such as ‘TDL4’ (also known as ‘Olmarik’), ‘Necurs’, and ‘Rovnix’ in 2011,[8] and cataloged various MBR and VBR infection vectors in 2012.[9] In addition, there have been reports of financially motivated malware utilizing bootkits. In 2013, RSA warned that a banking Trojan named ‘KINS’ had VBR bootkit functionality and was being advertised on a Russian- speaking online forum[10].

Load more