Malware Myths

Undetectable rootkits, irremovable malware, firmware bootkits surviving multiple drive wipes, I read about all these subjects on a regular basis and I will dedicate this blog post to these so-called malware myths in the hope that it may help you getting a better idea of what is possible (and most importantly what is not possible) when it comes to malware.

First of all, undetectable malware doesn't exist. Simply put, if we can't find it it means only we don't search well enough. As no piece of malicious software can exist on air only, it will have a stored component somewhere (this can range from code in a patched file to a sophisticated encrypted file system). While this stored component can be very hard to detect (after all a harddisk is a large place to hide stuff), it is not impossible and in worst case a wipe of the drive will always remove it, no matter how sophisticated. If malware returns afterwards it is time to check out removable/backup media or the network/router a computer connects to.

Firmware malware
Firmware is typically a small piece of software coded directly into a device (for example a video card or DVD writer) necessary for the device to function correctly. This code is highly device-dependent, different manufacturers and different models all require specific firmware. For that reason a firmware infection is not only highly unlikely but also very impractical for a malware writer. Someone who wants to create a successful infection not only needs to make sure the malware stays on the system (by making it harder to detect and delete), but also that it is distributed on a large scale. Deploying a firmware rootkit on a large scale is close to impossible as you'd have to write a lot of different versions for different hardware models.

BIOS malware
This form of malware certainly exists and infects the BIOS firmware. The malicious code can be removed by flashing the BIOS or resetting the BIOS. However, I have never seen such an infection in the wild. Furthermore, while the BIOS firmware is a pretty good place to hide, the only BIOS rootkit out there (mebromi) has plenty of signs and can easily be identified on an infected computer. As already explained above the real problem consists of the various firmware versions there are. Mebromi targets Award BIOS only, which makes distribution difficult. Combine that with the fact that it is easy to spot due to other components of the infection (see article) and you have to reach the conclusion that, although it is a very advanced piece of malware and may be tricky to remove (in worst case you need to open up your computer and reset the BIOS manually by removing the CMOS battery), it will not be more difficult to diagnose this infection is on board than an average MBR rootkit.

RAM resident malware
I can be short about this one: malware surviving in RAM during a power-off is technically impossible. Yes, a malicious loaded driver could in theory still be retrieved from RAM using a so-called cold boot attack, but from there to a rootkit that launches from within RAM is a long way to go. Due to the way RAM is designed it is physically impossible to store the launch code for a rootkit there.

Finally, not every weird symptom is automatically caused by malware. If you suspect suspicious network activity or see suspicious files and processes be sure to research them. Look up the IP addresses you see as well as associated port numbers, search for information on files and don't believe everything you read on the internet. You'll find that about every file on your computer is listed somewhere as infected. It is very important to determine how trustworthy a site is that offers information on files.
An infection usually comes with clear symptoms: redirects, pop ups, fake messages, extreme slowness and so on. "Weird behavior" is not enough to conclude that your computer is infected, specially not after one or more reformats/reinstalls.


"I still don't believe you and I want to know how to reformat and reinstall my computer in such a way that all possible malware is gone."

1. Make sure your computer is not on a network and power it off. Reset your router and reformat all removable storage devices you have (including mp3 players, cameras).
2. Clear CMOS
3. Delete all partitions on your hard disk(s) and reformat using DBAN.
4. Turn your computer off after deleting the partition(s) and reformatting the disk(s) for about 5 minutes.
5. Turn your computer on and reinstall using a legal Windows CD/DVD. Alternatively use a free linux OS which will not get infected at all.

Why I don't recommend Linux rescue CDs

Most AV vendors offer one free for download these days; a <fill in the AV name here> Rescue CD.  The idea behind it? Scan your computer without booting in Windows, which can come in handy when malware is actively preventing removal (for example by blocking the tools you try to run, or by refusing to be deleted easily). It is also offered as option to clean a system that will no longer boot at all in Windows.

In theory that all sounds nice enough, in practice however there are a few serious problems. A Rescue CD is based on the (open source) Linux operating system kernel. That leads also the first problem; a Linux OS can mount an NTFS partition (which is the file system Windows uses) just fine. However it can't load the Windows Registry as easily. There are some Linux-based tools that can be used to access and modify the registry manually, but the registry cannot be loaded remotely as would be necessary for a scan. This means that the Antivirus or Antispyware scanner included on the rescue CD will scan the file system, but not the registry. Many types of malware use the registry in order to launch. For example a Run value that points to baddie.exe will load baddie.exe as soon as Windows has started and the user logged on. Both the file and the Run value that loads it are bad and needs to go. However, the rescue CD will only detect and delete the file. So, on next reboot Windows will still attempt to load baddie.exe but will no longer be able to find it. This will usually not cause a problem when it concerns a Run value (in worst case the user of the computer will get an annoying error pop-up on each boot), but may have much more grave consequences when it considers other registry locations.

A classic example is the Userinit value. Some (older) infections use(d) to add a file to that value resulting in the so-called logon-logoff loop if the file is removed without adjusting the value correctly. While it is not impossible to recover such a computer, it isn't exactly simple.

Another, more actual, example is the 64 bit version of the ZeroAccess rootkit which hijacks the Windows value in the HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems key so that it will attempt to load the rootkit component consrv.dll instead of the legit winsrv.dll file. If a scanner deletes consrv.dll without adequately adjusting the Windows value data, the computer will no longer boot and instead display a 0xc0000135 BSOD. Luckily most 64 bit Windows versions nowadays have the Recovery Environment pre-installed, which makes recovering from this error a lot simpler, but still, this involves a relatively complex registry edit.

Another issue you need to be aware of when scanning with a Rescue CD is the fact that any file can be deleted, even those that are critical Windows system files. Normally Windows Resource Protection will (attempt to) prevent the deletion of such files. In case a system file has become infected, it will need to be identified and replaced. Deletion will in many cases lead to unbootable or unusable systems.

There are many examples here, just a random one: if the 32 bit ZeroAccess rootkit infects i8042prt.sys (which is the keyboard/mouse ps2 port controller) and this file is deleted using a rescue CD the user of the computer will no longer be able to use their ps2 mouse/keyboard. Both will be completely unresponsive once Windows is loaded.

Does that mean a rescue CD is totally useless? I don't think so, you can still use it to diagnose/detect the malware you are dealing with. To stick with the i8042prt.sys example, if a scanner detects it as infected you can then replace it manually using the rescue CD (browse to a clean copy and use that to replace the infected file). 

My advice: if you want, use it, but use it wise and don't let it delete files but rather investigate what it detected and prepare a manual fix based on that. If you are not sure how to do that, then I recommend to look for help as doing it yourself may very well worsen the state of your computer.

             

"The Google Redirect Virus"

I have encountered this term in more different ways, shapes and forms than I care to remember and it continues to amaze me, because there is no such thing as a Google Redirect Virus.
Of course that is easy for me to say, but I suspect that if you have encountered or have become the victim of google redirects (because, contrary to the Google Redirect Virus, google redirects most definitely exist) you'll understand the term a lot better all of a sudden.

When googling "Google Redirect Virus" I get 18.300.000 results, but examining the first page does not give me a lot of clarity of what we're dealing with in fact.

First of all, what is a redirect? A redirect itself is not necessarily malicious. If I type in a site address and I make a typo, I can get redirected to the correct address. Nothing wrong with that. When talking about redirects in this post, I will only refer to malicious redirects
There are different forms of malicious redirects, but generally speaking, a redirect means that, when you use a search term in a search engine, either you get results that are in no way related, or when you click on seemingly related search results, you will be directed to an entirely different page than the one you think you are going to. Usually the page you are ending up at is either commercial in nature, or has malicious content that will attempt to infect your computer.

Next, what is a virus? A virus is a piece of malicious code that inserts itself in a legit file and can reproduce itself, thus having the ability to spread from one computer to another. More information in this Wikipedia article.

Why does it not make sense to talk about a "Google Redirect Virus"? Simply because there are so many different pieces of malware than can cause redirects. A redirect is a result, or symptom of a malware infection, it is not a cause (although it can become a secondary cause of infection by directing you to a malicious site). In most cases a redirect is not caused by a traditional computer virus but rather by other categories of malware.

A few examples of infections that can cause google (or other search engine) redirects:

• Router infections: when a router is infected, it usually means that the WAN DNS server addresses have been hijacked. The chance of this happening is a lot higher if you have not changed your default router password. A router reset should resolve this problem (afterwards any non-default settings like ISP usernames and passwords will need to be entered manually). The computer itself may or may not be infected.
• DNS hijacking: the same thing as router hijacking, except that in this case the DNS settings on the computer are affected. This usually only happens on computers that do not use a router to connect to the internet.
• Malicious Firefox extensions: the so called GooRed (Google Redirect) infection uses a malicious extension typically XUL Cache or XULrunner. Disabling/uninstalling the extension will fix the problem. A typical sign is that redirects only occur in Firefox and not in Internet Explorer.
• Hosts file hijacking: this file (typically located at c:\windows\system32\drivers\etc\hosts) contains a list hostnames and the IP addresses they should refer to. More information can be found in this Wikipedia article. Malwae can add lines to this file so that, when you type in a known/safe site's address, you will be redirected to a malicious IP. The fix is simple: remove the mlicious lines.
• TDSS rootkit variants: all TDSS rootkit variants starting with TDL3 cause persistent google redirects. For more information about this infection, see my blog post here (infected objects can be: patched system file, MBR or partition table).
• Winsock/LSP hijacking: many types of malware have used or use the Layered Service Provider in order to facilitate redirecting search results. An example that is seen much these days is the ZeroAccess/Sirefef rootkit (note that the LSP hijack caused by this infection is not its main component). In order to fix this hijack, the winsock catalog will need to be adjusted accordingly. Doing this incorrectly may lead to loss of internet connection.
• Patched system files: there are different infections that patch system files in order to facilitate redirecting. Examples are TDL3 rootkit (see above), ZeroAccess/Sirefef (see above) or Bamital, which infects c:\windows\explorer.exe and c:\windows\system32\winlogon.exe (XP) or c:\windows\system32\wininit.exe (Vista/7). In all cases deletion of the files is not an option and may cause even more problems. Infected system files need to be replaced with a clean copy.

A combination of techniques can be observed in many infections and removal depends completely on the cause. Just like a medic won't say to a patient who complains about a tummy-ache: "well, lets start removing your appendix and see if that has any result", we shouldn't apply solutions in hopes of having the desired effect without first researching what we are dealing with.

Two ways to adjust the Partition Table (an exercise in futility...)

After I made a mention last week about the latest TDL4 version which alters the partition table, I decided to try a few things to see how to manually do this. Note that this is NOT a fix for the latest TDL4 variant (for more information about this rootkit, see TDL4 rebooted | ESET Threat blog).

Repeating the steps below is at your own risk; if you are not sure what your are doing, this may result in serious damage. My recommendation for everyone who wants to try this, is to use a Virtual Machine (I use Virtual Box).

For this experiment I have used a VM (VirtualBox) with one partition, containing XP. I have used TestDisk to alter the partition table so that the boot flag for this partition no longer was Active. I also have written the TestDisk MBR to the drive to illustrate that the partition is still there and can be booted from. I then dumped the MBR using linux's DD utility (using xPUD live CD), after which I opened this dump with HxD hex editor. I used this to manually change the bootflag for the partition back to Active. Finally I restored this fixed MBR using DD, et voila...


1. Use TestDisk to change the bootflag

TestDisk can be used both under Windows and Linux (in this case I used the xPUD live CD). The hard disk showed up as follows in Testdisk (you can see here this is a virtual harddisk, created using Virtual Box).
After selecting the device, you get presented with some options. To see and alter partition information you need to select Analyse. After a Quick Search the following was displayed (see image below).

Next I used the arrow keys to change the bootflag from Primary and bootable (*, see left image) to Primary partition (P, see right image).







2. Use TestDisk to rewrite the MBR

To make sure I could test the altered partition table afterwards, I next
have rewriten the Master Boot Record with TestDisks MBR (this option is available after choosing the Device, see right picture). The only advantage is that this, when it doesn't see an Active partition or when it is not able to boot from the Active partition, will display manual boot yptions, as you can see in the left image below. The right image displays what happened when I pressed 1 at that point.
By doing that I forced the computer to look on primary partition 1 (as present in the partition table) for a boot loader. As this was present (on XP this is the NTLDR file), the boot process continued normally and Windows was loaded.


3. Dump the MBR with DD
While it would be easy to change the boot flag back to Active (bootable) partition with TestDisk (just reverse the steps under point 1), lets fix this another way than I broke it. For the next steps I used the xPUD live CD and an USB jump drive. In xPUD I navigated to my USB drive (usually present in the File menu as /mnt/sdb1) and opened a terminal. I executed the DD command visible in the image, which dumped the first 512 bytes of the drive (otherwise known as the MBR) to my USB drive as mbr.bin.

4. Edit the MBR dump to manually change the boot flag

Now that we have the MBR dump, we can open it with any (hex) editor. I used HxD hex editor for this. This is how mbr.bin looks in a hex editor (see image):

I have highlighted the partition table and color coded it for clarity. The first partition entry is yellow, the second green, the third blue and the fourth pink. Because this harddisk has only one partition, only one partition is present in the Partition Table.



In order to readjust the Partition Table so it will once again have an Active partition set, we can simply edit this dump. The bootflag for each partition is set in the first number of the respective partition entry (for the partition we need to adjust, this is 000001BE). The bootflag for the Active partition is 80, so we can simply edit the number in 000001BE and change it from 00 to 80. When done I saved the change I made in mbr.bin (to be sure I also saved the original as mbr.bin.bak) and transfered the USB jump drive with mbr.bin back to xPUD.

5. Restore the adjusted MBR

The only thing that remains to be done now is to restore the adjusted MBR and overwrite the existing MBR with it. We can do that in xPUD using DD as shown in the image.

The computer booted normally afterwards.

I hope that this example has helped you to gain an insight in how the Partition Table "works" and how you can adjust it.

TDSS in layman's terms

Since 2008 it has been a constant factor in malware-land: the TDSS rootkit (also known as Alureon rootkit).  

There is a lot of good in-depth information and analysis posted all over the internet, a few examples are TDSS - Securelist and TDSS aka TDL: A Botnet Framework. However, I often get questions from people who are looking for a simple description: how are the different variants being identified and what is the difference between them? For that reason I have posted this (very) general overview.

• TDL1: Classic TDSS; created a hidden driver service named TDSSserv, which loaded c:\windows\system32\drivers\tdssserv.sys

• TDL2: Same as TDL1, but the names differ and contain a random string. There are many different versions, each of them containing new tricks to avoid detection and deletion. Examples are UACxxxxx, SKYNETxxxxx, GEYEKxxxxx, GASFKxxxxx, H8SRTxxxxx, PRAGMAxxxxx (where xxxxx represents a random string).

• TDL3: The aim is to patch the hard disk controller driver (atapi.sys/iastor.sys) in order to get control over the system. Classic TDL3 directly patches atapi.sys on disk, later versions patch a random .sys file in the c:\windows\system32\drivers folder, which in turn patches atapi.sys in memory only, thus making detection/removal more difficult.

• TDL4: The aim of this variant is the same as that of TDL3, however instead of patching a file, the Master Boot Record is patched, which makes infection of 64 bit systems possible and detection/removal harder. 

• The latest version (at this moment still called TDL4) no longer patches the MBR. It alters the partition table so that its own hidden HPFS partition is set to Active. That way, when the computer is started, it will boot from the TDLFS partition, and load the infection from there, thus gaining control over the machine (it can then alter the MBR in memory and from there acts similar to TDL4 as described above). Fixing the MBR is no longer an option; the only way to fix this is to alter the partition table.

Next-best

Every once in a while I encounter users I am helping online to remove malware who tell me: "I think I will have this resolved by an Expert..." Usually this happens when things do not go as fast as anticipated. Said Expert usually is a form of paid support (whether that is online/remote support or a local repair shop).

This always makes me wonder: can you only be considered an expert if you are paid for what you do? That would be a discouraging conclusion, meaning that no matter how hard or how well I work in malware removal, as long as I do that on a voluntary basis, I'm still considered "next-best". Now I know quite a few people more knowledgeable and experienced when it comes to malware removal than I am, but they also are working as volunteers.

So, why does "getting paid" inspire more confidence than being a volunteer? I have no idea. I have my own "policy", which means that I do my best to help everyone as best as I can. I think I can safely say that I have managed so far to bring that in practice. If that is still not enough, then by all means, find an Expert...