Computer Virus Chronicles

Virus Chronicles: The Stealthy Mebroot Master Boot Record (MBR) Rootkit

Explore Mebroot, the elusive Master Boot Record (MBR) rootkit: stealthy, persistent - A Cybersecurity Tale. Mebroot is a MBR infecting rootkit, which hides his presence and downloads silently additional banking trojan components to the infected system through a backdoor.

5 min read
A mysterious cloaked figure surrounded by many laptops and a root net - the dark and mysterious realm of malware
A mysterious cloaked figure surrounded by many laptops and a root net - the dark and mysterious realm of malware

Welcome to the dark and mysterious realm of malware, where digital adversaries continually evolve their tactics to infiltrate our systems. In this installment of "Virus Chronicles," we delve into the enigmatic world of Mebroot, a Master Boot Record (MBR) infecting rootkit that has left cybersecurity experts awestruck with its stealth and sophistication. Mebroot's journey takes us through its inception, infection methods, and the relentless cat-and-mouse game it plays with the defenders of the digital domain.


Mebroot is a Master Boot Record (MBR) infecting rootkit which hides his presence and downloads silently additional banking trojan components to the infected system through a backdoor.

“The MBR rootkit — known as "Mebroot" — is very advanced and probably the stealthiest malware we have seen so far.” - Monday, March 3rd, 2008, Posted by Kimmo Kasslin, F-Secure Security Labs

Overview

Category: Malware
Type: Rootkit
Platform: Boot
Aliases: Troj/Mbroot-A [Sophos], StealthMBR [McAfee], TROJ_SINOWAL.AD [Trend], StealthMBR!rootkit [McAfee], Tojan:boot/mebroot, Trojan:boot/mebroot.b

Details

Mebroot appeared in the wild in December 2007 and was traced back to November 2007.
The First sample got discovered by Matt Richard from iDefense together with GMER team.
Since the first version of Mebroot got detected, the developers continuously improved the rootkit code so that over time Mebroot used a variety of methods to infect a system.


Drive-by download attack

Drive-by download defines a technique of unintentional download of malicious software (malware) onto the system. This can be achieved with or without permissions of the victim. For example by accepting a download or installing a program. In this case the victim would need to “accept” the download or start the installation process. The second type of this technique doesn’t need the victims permission in order to get downloaded and installed. The victim just needs to visit a compromised website and the malicious code can silently download in the background.
The attack uses flaws or vulnerabilities in the browser, app or operating system. One or more attack scripts runs on a web server (Exploit Server) and by connecting to this server, the attack script will check which known vulnerability can be used in this case and usually download the initial code, which in most cases is very small and therefor hard to notice. After downloading the initial code which is most likely obfuscated and will only de-obfuscate itself at runtime or execution to exploit the browser.
This will cause the browser to link to an malware server which is usually different from the exploit server. This malware server will serve the actual malware back to the client. The attack vector is either using social engineering mechanics such as: Messenger, Mail from a “trusted or reliable person” which is not identified as SPAM. Or/And an innocent high traffic trusted website which itself got compromised or there is a ARP spoofing server which will act as “man in the middle” route traffic to the trusted webserver but will inject the malicious code in the response of the server. While this involves an attack against a “Landing Site” which serves a lot of users and has to be compromised. There is yet another vector which will compromise the route between the trusted website and the clients. These technique has been introduced 2009 when a Cisco Router was exploited and is referred to as “middle of the route” attack on tw.msn.com, Taiwan.cnet.com and others.

Mebroot distribution

1st generation: Simple iFrame injection
2nd generation: Obfuscated javascript injection
3rd generation: Infection of other legitimate scripts

Other infection methods used by Mebroot

Mebroot employs various infection methods, including:

Mebroot MBR infection

The first versions of Mebroot used a documented way to read/write to the MBR over Windows API calls. It replaced the MBR which contains the first code to be loaded and executed during the boot process.
This vulnerability was a known issue. J. Rutkowska was the first person reporting this. She called it a “pagefile attack”. This attack was caused by the fact that a raw disk access from usermode was possible (but required Administrator privileges).
Later versions of Mebroot used a driver component that allowed Mebroot to perform raw disk operations. (system I/O driver later kernel driver)
This modifications of Mebroot may got forced by the fact that HIPS ( Host-based intrusion prevention) and other protection systems started to block suspicious operation on physical hard drive.

But why infect the MBR?

This is the earliest point to get executed and gives the first executed program an advantage because it can modify the system before something else is running. For example before an security program or anti-malware Program is running to avoid its track of changes and the danger to get detected by modifying the system.

Strengths of Mebroot

Mebroot prevents the kernel from altering the MBR and conceals its presence by returning the original MBR contents.

t was a well-designed malware that didn't cause many blue screens, but even if an error occurred, a correction mechanism was provided by sending dump files to the C&C (Command and Control) server, allowing the authors of this malware to improve Mebroot.

The software was able to communicate via a backdoor with the C&C (Command and Control) server and bypass security software. Through this communication channel, Mebroot could update to the latest version or send any information to the C&C server.

After the initial versions of Mebroot were detected by anti-rootkit and antivirus tools, the subsequent version of Mebroot implemented aggressive countermeasures against all these tools that attempted to remove or restore the IRP* pointers.

Mebroot was hard to detect because it doesn’t store executable files on the file system neither used registry keys or driver modules in the module list. It hides his presence through the advantage of an early execution time and has a minimal memory footprint. It implemented a watchdog for anti-removal protection and used stealth read/write disk operation.
It has been observed that the downloaded components have been keyloggers and additional banking trojan components to steal sensitive information from the infected system and report them back to the C&C server.

*„The IRP structure is a partially opaque structure that represents an I/O request packet. Drivers can use the following members of the IRP structure.” Source: MSDN


As we conclude our journey through the labyrinthine world of Mebroot, we're reminded of the ever-evolving nature of cyber threats. Mebroot, with its ability to hide in plain sight and adapt to countermeasures, stands as a testament to the ingenuity of cybercriminals. However, the battle against such threats continues, driven by the relentless dedication of cybersecurity experts worldwide. As we navigate this digital landscape, we remain vigilant, learning from each encounter with malware like Mebroot, and fortifying our defenses to protect the digital realms we call home. Stay tuned for more intriguing stories from the frontlines of cyber warfare in future editions of "Virus Chronicles."

References


Other useful information

Share This Post