Maybe so, but if the top anti-malware companies can identify this threat, it is certainly within their grasp to remove. If it’s such a big threat as portrayed in this article then the best of the best damn well better be working around the clock for a solution.
I can't disagree with that but I've seem them fail to actually finish the job. McAfee sometimes detects the trojan, removes it and 10 minutes later does the same thing. Over and over.
What I go to when I have a serious trojan problem is majorgeeks.com. They have never failed to get rid any trojan that I've ever had. The service is free. It's run by very expert volunteers who are sticklers for procedure. Do exactly what they tell you to do and you will succeed. Don't and you won't.
Heck, I figured I might as well paste the whole thing in from the first link:
News broke out earlier this year (My Note: this was March 2008) of a new breed of rootkit using techniques never before seen in modern malware. The most notable of them is the fact that the rootkit replaces the infected system’s Master Boot Record (MBR).
The MBR is the first physical sector of the hard drive and contains the first code loaded and executed from the drive during the boot process.
In the competition between rootkits and rootkit detectors, the first to execute has the upper hand. And you can’t execute earlier than from the MBR. Of course, MBR viruses used to be very common in the DOS days, 15 years ago or so. But this is 2008.
This new Windows MBR rootkit launches itself very early during the Windows startup process without requiring any registry or file modifications. In fact, it is quite surprising that it’s possible to write to the MBR from within Windows to begin with.
The MBR rootkit — known as “Mebroot” — is very advanced and probably the stealthiest malware we have seen so far. It keeps the amount of system modifications to a minimum and is very challenging to detect from within the infected system.
Below are some details about the MBR rootkit’s stealth features:
The ntoskrnl.exe module hook that executes the kernel-mode downloader payload is set to the nt!Phase1Initialization function which resides in the INIT section. This means that after the system has initialized the section is wiped out from memory and no sign of the hook is any longer present.
The rootkit stores data that’s required to survive reboots in physical sectors instead of files. This means that the data, including the real payload, is not visible or in any way accessible to normal applications. Therefore the rootkit does not have to hook the normal set of interfaces to keep them hidden.
The MBR is the rootkit’s launch point. Therefore it doesn’t need to make any registry changes or to modify any existing startup executables in order to launch itself. This means that the only hooks it needs to make are used to hide and protect the modified MBR. Essentially this means that the rootkit hooks only two DWORDs from the disk.sys driver object which is shown in the picture below.
Another interesting feature of the MBR rootkit that has not received very much public discussion is its networking layer and firewall bypassing capabilities. One reason for this might be that this part of Mebroot’s code is heavily obfuscated and time consuming to analyze.
It is known that the rootkit’s main purpose is to act as an ultimate downloader. To be stealthy and effective it is essential that the rootkit does not trigger nor is blocked by personal firewalls. It is able to achieve this by operating in the lowest parts of the NDIS layer just above the physical hardware.
Only a single DWORD is hooked at all times from the NDIS internal structures. To send packets the rootkit uses the SendPacketsHandler function implemented by the actual hardware specific driver.
The rootkit uses its own unmodified versions of NDIS API functions it needs to operate. This has been done before by some malware, such as Rustock and Srizbi. However, what we have not seen before is the fact that the MBR rootkit uses a “code pullout” technique to only load the relevant code from the ndis.sys driver instead of loading the whole ndis.sys driver as its private module into memory.
This means that the memory fingerprint of the malware is smaller and there are no additional modules loaded into the system address space which might trigger some forensic tools.
This malware is very professionally written and produced. Which of course means it’s not written for fun. Initial samples from December 2007 and January 2008 were at beta stage. Now it appears that the malware is fully-baked and more active distribution has begun. During the weekend our Security Lab started to receive information about multiple drive-by exploit sites spreading the latest version. (However, at the moment these attacks cannot be considered as widespread.)
The actual site hosting the exploit code utilizes the following exploits:
Microsoft Data Access Components (MDAC) Function vulnerability (MS06-014)
AOL SuperBuddy ActiveX Control Code Execution vulnerability (CVE-2006-5820)
Online Media Technologies NCTsoft NCTAudioFile2 ActiveX Buffer Overflow (CVE-2007-0018)
GOM Player “GomWeb3” ActiveX Control Buffer Overflow (CVE-2007-5779)
Microsoft Internet Explorer WebViewFolderIcon setSlice (CVE-2006-3730)
Yahoo! JukeBox datagrid.dll AddButton() Buffer Overflow
DirectAnimation.PathControl KeyFrame vulnerability (CVE-2006-4777)
Microsoft DirectSpeechSynthesis Module Remote Buffer Overflow
Proof of concept code for two of the exploits was publicly disclosed just less than a month ago.
The downloaded payloads seem to clearly target online banking and other financial systems.
We detect the latest MBR rootkit variant as Backdoor.Win32.Sinowal.Y.
The exploit site is currently resolving to an IP address of 216.245.195.114 and seems to still be active.