Wednesday, December 21, 2011

"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.

Sunday, November 27, 2011

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.

Tuesday, November 15, 2011

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.

Monday, April 11, 2011

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...