I can't really tell, if you are in charge of an IT department or are doing this as a customer-based thing (that is, people bring their PC to you, you fix it, etc) If you are in charge of an IT department, you're simply doing it wrong- you should be simply restoring backup images. That's mostly why I think it's the latter (customer-based), but I'm not 100% sure on that.
I am curious as to some of the local scanners that the 'malware removal experts' here recommend? I work for an IT company and generally do about a dozen or so virus removals a week.
and how do they remove the infection locally while having an infected MBR?
the MBR is writable while the system is powered on. Rootkits generally have nothing to do with the MBR, it's just common that a rootkit comes with a MBR infection as well.
I've had to take out the hard drive and hook it up to one of our service machines and have had the highest success rate with that.
Obviously you are running something on the "service machine" to fix it. (
Edit: MSE. Wow, that's totally an enterprise solution you have there, kudos) Don't know what that is. Clearly you cannot just plug a drive into a "service machine" and suddenly have success.
Turns out that it creates its own virtual file system within the HDD outside of the file system; on the very last sectors of the HDD.
This is not particularly unique, either within rootkits or the MBR code itself; additionally, it's not necessarily it's own "file system" as much as it is the malicious loader (which is pretty much the only thing the boot sector can do, is say where the loader is)
Normally, being a season professional, I'm sure you already know this; but the boot sector pretty much just loads the rest of the boot code from disk. NT's bootloader will load NTLDR, and continue booting using that; DOS' will read io.sys and msdos.sys; Linux will generally load the selected boot loader (these days, this is typically GRUB). A MBR and boot sector infection can easily infect the drive with a boot sector that references otherwise "unused" portions of the disk, rather then creating a physical file like operating systems do for the "legit" final stage loader. Thing is, that loader(in the unused portion of the disk) will need to pass off control to an OS loader; and before that OS loader starts there really isn't a whole lot for this malicious loader to do. It could, I suppose, manually edit the disk to create new infections or something, but that's so messy to do with direct device access I doubt there is even a existing instance of the method.
Not sure if a PE environment would be as effective though since TDL3 inserts serveral API imports and exports to avoid heuristics
It would be.
Booting from a PE environment means that no MBR or boot sector code from the hard disk is loaded. Therefore it is a completely separate environment. rootkits are relatively simple; they are merely kernel drivers that are set to "hide" files/registry keys/etc from certain locations. (well, at least, that's one part of what a rootkit does). For example they almost always hook ntcreatefile() to hook access to "their" rootkit files, and essentially return that the file doesn't exist; similar changes are done for all the various file creation and enumeration functions, essentially hiding said files.
However, hooking said functions requires that said functions exist to be hooked. This means that, in the case of ntcreatefile(), NTDLL.DLL would need to be loaded. NTDLL.DLL isn't loaded until long after the loader code loses control, since loading NTDLL.DLL is part of Boot Phase 1. At this point, nothing of the bootloader is still executable (to my understanding, since the bootloader was run in real mode whereas the processor had been switched to protected mode before), and even if it was there was no way for it to gain control, anyway. (and thus hook functions).
Now, a kernel mode boot-time driver, on the other hand, can easily hook ntcreatefile(), but such boot-time drivers are all defined in the registry- a registry stored on the hard disk. A Hard disk, that isn't accessed by a PE boot environment for initialization.
I do this for a living boys and girls, this isn't just a hobby of mine.
Could have fooled me. Your previous post shows a rather clear misunderstanding of the windows boot process and exactly what infection vectors exist at early boot phases as well as the capability of said vectors.
Anyone can download malwarebytes and combofix, lol.
Could you quote where anybody has stated otherwise?
But they have not had time to respond to a discussion in where they explain the mechanics of how a local scanner is able to remove an MBR infected computer.
they're busy. there is a shortage of active malware specialists at the moment. It's nice to see yet another person who has the idea of
I am right and the entire industry is wrong of course, by industry I mean free online malware removal. It's certainly not snake-oil, since it's free and that would be pointless; and saying anything like "you get what you pay for" (which, although you haven't said it, was pretty much implied. Also, other people who have come here saying "OMG you are doin it rong!" pretty much say the same thing) is pretty ridiculous, given that people pay them nothing and often leave with much healthier machines, as well as of course forgetting the number of unscrupulous technicians - about 60% of technicians will try to charge for things like replacing the hard drive and/or reinstalling a new OS for something as simple as a moved jumper.
a "local scanner" (such as GMER, or what-have-you) can easily fix a infected MBR/boot sector a root-kit fixer fixes it by simply rewriting the MBR. *censored*, you can do this with chkdsk /FIXMBR as well as rewriting the boot sector (via recovery console and fixboot). However, this isn't the sole thing that GMER performs.
You see, as I explained previously, a rootkit consists of Kernel-Mode DLLs that hook various functions; what GMER (and rootkitrevealer as well to some extent, altough RKR is more or less a informational tool rather then a true "scanner" program) does is pretty simple; it detects hooked functions.
Now the question may arise "but golly, how does it do that detection?"
Simple! As we all know, (and you know especially, since we're just "boys and girls" and you "do this for a living") every function in a DLL has a specific export address. GMER (and other detectors) essentially go through all the loaded modules and compare their raw DLL imports with the DLL imports specified in the DLL file for any number of common functions (such as the aforementioned NTCreateFile()) the raw DLL imports, in the case of function hooking, will be pointing to something other then the explicit import address specified in the DLL import table. the detection program flags this, but it is hardly indicative of a infection, since AV software also hooks pretty much the same functions. the detector also prints out the name of the new DLL and function that is hooking that function, which is the bit that is most important.
An oversimplification would be to say that it compares the result of the GetProcAddress() function with the actual DLL import tables, however, this is naive, since GetProcAddress() could itself be being hooked by a kernel mode rootkit to not return data that might incriminate the rootkit- therefore, it's not a trustworthy function. In fact, no API function is really trustable, except for a few core unhookable functions found in ntoskrnl.
RootKitRevealer works a bit differently, and instead of looking for possibly hidden function hooks, it looks for possibly hidden data (after all, those function hooks are almost certainly in place to hide something). It does this by reading the registry using Raw file accesses and comparing the keys/data from that to the keys/values that are available to the windows API. A lot of legitimate entries may be flagged as "inaccessible to the windows API" one needs to use their better judgement- it's not usually hard to identify registry entries that are used for something malicious (after all, that's why they were hidden).
it checks files by reading the disk using raw Kernel reads/writes via direct driver calls; it's impossible to hook driver calls (except via DeviceIOCtl, but such an implementation is unlikely to succeed or work very well, given the varied nature of the drivers involved)
Removing a rogue AV security suite with combofix is not going to solve the source of the problem because you're just going to be re-infected.
you're right. It's an awfully good thing nobody said it would fix the problem, then.
Hijackthis had it's day until Trend Micro took it over. Now it's useless. I would recommend GMER at the bare minimum if you're naieve enough to attempt an advanced rootkit removal during normal startup or even safe mode.
HJT and GMER are wholly unrelated applications. the new standard (in HJT's domain) is probably DDS; Broni actually brought this up a few times that HJT should probably be dumped in favour of DDS. At least, I think it was Broni. Somebody mentioned it. Actually it might have been me, I don't remember.
Here is what you do: Remove the hard drive. Hook it up to the service machine (with autorun off). Run MSE. It's that simple. It has worked dozens of times, successfully removing all variants of TDL3 that I have encountered, and I do it dozens of times a week without any re-do's coming back.
haha... MSE is an excellent scanning program, but your solution is brute-force. It works, but at an incredible cost of your time and the time of the owner of the machine (more so the former then the latter). Truly if you are going to go to such extraordinary measure you may as well just do a format/install. Now who is oversimplifying the solution? The specialists here have the difficult task of essentially taking the malware off of a machine. What tools they use for this task really has no relevance since clearly your goals are different- clean the machine using the easiest possible route- additionally, a good number of visitors to this site seeking malware help are not going to be able to slave a drive to begin with; That being said, your exact method has been used at least a dozen times that I've witnessed, but only when most other measures fail (brute force is always a last resort in pretty much any problem domain).
My challenge is to find a local environment to remove these viruses; a 'rescue disk' to be more exact. Something outside of the OS. I was hoping you 'malware removal specialists' actually had some knowledge about these things.
They do. They just don't feel like sharing it, obviously.
After reading most of your solutions to these poor people that you are putting through all this trouble for nothing
99.9% of the people requesting malware help eventually leave with clean machines. At the moment there is a rather sharp shortage of Specialists (a good number of them have essentially gone idle) this is actually quite a different problem entirely, and solutions are being investigated; however, even so, those requestees they are able to get to in a timely fashion have, from what I can tell, generally been left with clean machines.
I actually had a stance similar to yours when I first joined the forum, I rambled on about how regedit,RegMon Process Monitor, and other tools can be used easily to remove nearly any kind of infection. Of course, now I know that that is both wrong, as well as out of context, since it's a heck of a lot harder to direct people through regedit to remove stuff, and it's far more dangerous then a tool for the purpose. At least I didn't stand by a "just slave the drive and run MSE" approach.
