ROOTKITS
CASE STUDY: The Invisible Rootkit That Steals Your Bank Account Data
Let’s go back to a time when a new form of rootkit was introduced that rocked the industry. In 2008, a rootkit appeared in the wild, stealing financial data by installing keyloggers on computers and monitoring when users entered their usernames and passwords for many European banks. This rootkit was the most malicious of its kind ever seen. Invisible to all anti-rootkit and anti-malware utilities, including those from leading security and antivirus vendors, this rootkit downloaded malware that logged all keystrokes typed into the computer. Between December 12, 2007, and January 7, 2008, iDefense, a security firm owned by Verisign, detected approximately 5000 machines infected with the rootkit in Europe.
The rootkit, once installed, embedded itself into the Master Boot Record (MBR) of the computer. The MBR is the first 512 bytes of the computer’s primary hard drive. The BIOS of the computer tells the CPU to execute the machine code written to the first 512 bytes. This machine code, commonly referred to as a boot manager, typically starts the operating system loaded on the computer and directs it to access the first partition available on the system. The boot manager can be replaced by other code if the operating system allows the first 512 bytes of the hard drive to be overwritten. Microsoft Windows allows the MBR to be overwritten by applications that are executed by an administrative user.
Users infected themselves when they accessed websites intended to spread the virus such as various pornographic and illegal software (warez) sites. The rootkit, named Mebroot, exploited users running a copy of Internet Explorer that was vulnerable to an exploit. Once exploited, the rootkit downloaded a 450KB (rather large) file that, when executed, stored itself in the last few sectors of the hard drive, wrote a copy of its rootkit boot manager to the MBR, and executed itself. Because the rootkit was written to the MBR, when the system rebooted, the rootkit was executed before the operating system, thereby ensuring it was loaded first and could reinfect the computer.
What made this rootkit even worse was that researchers at F-Secure and Symantec had proof that the rootkit was “beta” tested in early November 2007 to ensure it functioned properly. The datestamps and timestamps on the executables found in the wild indicated that in November 2007, a specific domain on the Internet started to spread an early version of what would become the Mebroot rootkit. After the beta release, two additional waves of Mebroot with some amazing capabilities were released to the world.
Besides being one of the first rootkits to infect the MBR, Mebroot was, at that time, the pinnacle of professional rootkit development. The methods used to execute processes, hide network traffic, and prevent detection were advanced, and to this day, they are still among the most effective techniques for evading detection. Mebroot innovated in three main areas: stealth disk access, firewall bypassing, and backdoor communication. Each of these capabilities was implemented within the Microsoft Windows kernel, a portion of the operating system usually reserved for drivers that managed your network card or graphics card. The amount of skill needed to implement these capabilities at the kernel level itself was exemplary but even more so for a rootkit in which traditional rootkit developers did nothing but copy code from other authors and websites and then change a few things.
Disk Access
Traditional rootkits prevent access to portions of the hard drive by intercepting the functions executed by applications such as CreateFile(). Mebroot was different. Instead of just intercepting the function calls by overwriting certain portions of the DISK .SYS driver in memory, which would be detectable, the Mebroot rootkit overwrote all functions within the DISK.SYS driver and installed a wrapper driver that called the DISK .SYS functions to ensure that behavioral products such as host-based intrusion prevention systems did not prevent it from infecting DISK.SYS.
As an extra measure, the rootkit also started a “watchdog” thread that checked every couple of seconds to ensure that the rootkit’s stealth capabilities were still installed on the system. If they were removed, the rootkit would reinstall them.
Firewall Bypassing
Rootkits need a way to covertly allow themselves and any malware they work with to access the network to request web pages and communicate with its command-and-control (C&C) server. Of course, if the rootkit does not hide its communication, anti-rootkit tools such as firewalls and host intrusion prevent systems (HIPS) may detect it.
Until Mebroot, most rootkits simply worked by creating and installing a driver similar to a network card driver within the NDIS, the network interface of the Windows’ kernel. Mebroot didn’t want to be detected, so the developers did not use this method. Instead, the developer wrote a set of algorithms to find hidden and undocumented functions within Microsoft’s NDIS, which allowed the rootkit to communicate with the NDIS without installing a driver. This method, although stealthy, required that the rootkit implement its own TCP/IP stack to communicate with other devices on the Internet. Writing your own TCP/IP stack is difficult, which goes to show how focused the authors were during development and the lengths that rootkit developers must go to in order to remain undetected.
Backdoor Communication
Mebroot utilized advanced firewall bypassing techniques to covertly communicate with C&C servers on the Internet and process commands from the owner of the botnet. Researchers have been able to unravel the important capabilities of Mebroot, but because of its polymorphic capabilities and spaghetti-code techniques, they believe some aspects of the malware remain hidden and yet to be discovered and analyzed.
First, the rootkit connected to a random C&C server, building a domain name using the current time and date and a variety of hard-coded domains. Once the rootkit resolved a DNS name to an IP address, it sent an encrypted packet to the IP address to “ping” the C&C server to ensure it responded to its encrypted communication. The rootkit used an encryption algorithm based on SHA-1, an industry standard but one that uses a very weak and easily decipherable key, which has allowed researchers to decrypt the packets. To add additional complexity, however, the decrypted packet actually contained data that was then encrypted using a different encryption scheme found in other malware.
Once the C&C server responded to the rootkit, the C&C server could tell the rootkit to execute one of four commands:
• Install a DLL into any process or install a new version of Mebroot.
• Uninstall a user-mode DLL or uninstall Mebroot.
• Instruct a trusted process to launch new processes by filename.
• Execute any driver in kernel mode.
The ability to uninstall the rootkit was further evidence that the rootkit was developed and tested by professionals, as an uninstall function can aid in debugging and creating a rootkit.
Once the command was received, the rootkit executed each command on the system using very detailed instructions (too detailed for this case study!) to ensure that anti-rootkit technologies did not prevent the command from executing. For example, the rootkit used a built-in system call (similar to what an operating system does!) to rewrite custom DLLs that were then executed on the system.
Intent
What could be so beneficial that the Mebroot developers would spend potentially months of time developing such an advanced rootkit? Money. The Mebroot rootkit installed and executed malware delivered by the C&C server to infect hosts. This malware recorded keystrokes, sniffed HTTP and HTTPS requests, and injected arbitrary HTML into websites, particularly banking sites. These features enabled many different types of fraud, including identity theft, click-fraud, and the theft of bank accounts.
At the time, the Mebroot rootkit was one of the most advanced rootkits the public had ever seen. Written by professionals, effective, and hard to remove, this rootkit delivered malware that was used to steal financial information such as bank account and credit card numbers. Mebroot, with all of its advanced capabilities, was just the beginning of the new evolution of rootkits that has propelled what was previously easily cleaned or ineffective malware into a new echelon of capabilities.
Now, not all was lost. Mebroot could be removed, and the easiest way to remove it was to run the fixmbr command from within the Windows recovery console, which was available by booting the Windows XP CD (included with all Windows installations). This overwrote the rootkit’s entry on MBR with a standard Windows MBR. Also some of the latest BIOS settings allowed users to make the MBR read-only. If set to read-only, any modification to the MBR caused a BIOS warning.
Presence and Significance
Mebroot was a game changer, ushering in a new era of rootkits. Even now, new variants or derivatives of Mebroot have continued to be released with tweaks that bypass removal tools that were developed to detect and remove the presence of old Mebroot variants. Attackers often use these new iterations as a complement to other malware to enhance their rootkit capability.