Your virus removal techniques

[RegEdit]

I was just wondering if some of you'all just go straight to deleting registry startup items that don't belong (using ERD Commander or Bart PE). You can waste a lot of time screwing around from the desktop with TDSS Killer, Autoruns, Process Explorer, etc only to find out that a rootkit or two are screwing everything up, blocking Malwarebytes, etc. Then you need to fire up ERD Commander anyway.

 

[MobileTechie]

The thing is with rootkits - you can't always see them by looking at the registry. I don't really see an economic, purely manual way of effectively ruling out all rootkits by inspecting registry entries. It's so much easier to use tools. Some might be automatic ones like TDSS Killer whilst others might be semi-automatic like RKU or VBA32ARK or whatever.

Having wasted a lot of time manually removing the new AV 2010 which has a rootkit added, I'm now all for attempting at least some RK detection early on in the process. I found some entries in the registry and removed them and their associated files but the RK was hiding plenty more stuff. After running TDSS Killer a load of other entries and files appeared.

I think this is the way things are going. The days of the basic registry start-up entry pointing at an executable type infection are numbered. RKs are easily available and customisable and effective so why wouldn't they use them? So I believe we're going to see more and more of them and have to change our methods accordingly.

 

[Xander]

Sounds about right, MT.

I'm running TDSSKiller on every XP machine I touch, among the first things I do and let it run while I cover other basics. I've been using it as my smoke detector, basically. If I'm not otherwise suspecting a rootkit and it finds nothing, I continue on. If it does, then we're in for longer scans and such.

I really wish we could have, at least, a little quick-scan tool that said "Rootkit!" so could I point at it and tell the customer that I'll need to take it back with me. One thing I'm moving towards is a special for when they have visible malware that they bring to me. With those, I'm just going to assume there's a rootkit and start scans on that basis.

 

[georgenoise]

I run TDSSkiller on almost every machines that comes in as well just for precaution. The only issue I have is it seems like sometimes it will scan, report nothing found but then when you close the program it will lock up for a second and cause a blue screen. Has anyone else run into this? I can't find a reason for certain that this is happening.

 

[RegEdit]

Do you all ever use TCPView to look for viruses? Perhaps to see if processes found with Process Explorer (that hide in Rdl32 or svchost) are really viruses accessing the internet?

 

[iisjman07]

I use this:

I usually do all that and clean out temp. files (which isn't on the list for some reason). I usually use the tools from the 'main' section, and dabble into 'auxillary' if the machine is still funky. This is how my flash drive is laid out:

01 Main:
*Autoruns
*A script that disables the internet explorer proxy
*Some scripts to disable OS restrictions
*GMER
*MalwareBytes (and offline updates)
*Process Explorer
*ESET SysInspector (with anti-stealth technology)
*AVG, Avast, Avira antivirus installers

02 Auxillary:
*RootkitRevealer
*RootRepeal
*Spybot
*SUPERantispyware Portable
*HijackThis
*FixPolicies

03 Removal Tools:
*Avg 32/64bit removal tool
*McAfee Removal Tool
*Norton Removal Tool

 

[Vicenarian]

Do you all ever use TCPView to look for viruses? Perhaps to see if processes found with Process Explorer (that hide in Rdl32 or svchost) are really viruses accessing the internet?

I do. I include it as part of my virus removal routine.

 

[Ccomp5950]

If it's not something I can easily remove manually (Oh come on, hide a little harder than the AppData folder)...

I use PLOP linux booted over PXE with Antivir commandline added.

My server I have has a script that I run daily that checks for new installers of the major tools I use (TDSSKiller, Spybot, Malwarebytes) as well as common install programs (Adobe reader, etc.) and one of the functions is to download the Antivir ivdf file and unzip it, and copy the virus definition files into the folder Antivir works off of effectively updating it daily. Allows me to be able to quickly scan a system without burning a CD a day in an "offline" environment.

Afterwards I see how it looks, I've been in the habit of running TDSSkiller on each computer since May or June. Spybot and Malware bytes usually run over night and let the customer pick it up the next day.

 

[RegEdit]

I think it's risky to remove the virus' .exe and/or .dll file(s) without removing it's registry startup location. Otherwise the computer can become unbootable.

Remove just the startup item(s) in the registry and what's left (.exe, .dll) is just benign files that won't cause the PC to fail to get tot he desktop. This as far as I know. Someone correct me if I'm wrong about this.

 

[othersteve]

Yeah, TDSSKiller has become a go-to utility for me on all systems at this point, even 32/64-bit Vista and 7 now that TDL4 has gotten out there.

I always boot to a custom ERD build first actually and immediately take to cleaning up startup. I check the proxies remotely at that point and if I find one that is linked to a TDSS variant (or really anything else at 127.0.0.1 for that matter), I immediately know I am dealing with some sort of network-filtering malware, most typically a rootkit. It's a good lead-in to the next attack step I take, which, if the proxy is present, is checking integrity of system files offline (for which I use a pretty basic .bat utility I wrote, still in the alpha stages). Next is cleaning out temp files, then almost always Safe Mode with Networking at that point, then TDSSKiller and probably Malwarebytes'.

 

[RegEdit]

I check the proxies remotely at that point and if I find one that is linked to a TDSS variant (or really anything else at 127.0.0.1 for that matter), I immediately know I am dealing with some sort of network-filtering malware, most typically a rootkit.

How do you do that? View the host file?

It's a good lead-in to the next attack step I take, which, if the proxy is present, is checking integrity of system files offline (for which I use a pretty basic .bat utility I wrote, still in the alpha stages).

It would be nice to be able to do a SFC /scannow offline. If you can write a program to do that then more power to you.

 

[MobileTechie]

The hosts file doesn't list proxy entries just IP mappings.

One place to check for proxy settings is:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]

with the most important keys being:
"MigrateProxy"=dword:00000001
"ProxyEnable"=dword:00000001
"ProxyHttp1.1"=dword:00000000
"ProxyServer"="http://ProxyServername:80"
"ProxyOverride"="<local>"

This key reflects the IE proxy settings which obviously you can just check in IE's options.

If you get the ERD / D.A.R.T. disks they allow offline sfc scanning.

 

[Ccomp5950]

I think it's risky to remove the virus' .exe and/or .dll file(s) without removing it's registry startup location. Otherwise the computer can become unbootable.

Remove just the startup item(s) in the registry and what's left (.exe, .dll) is just benign files that won't cause the PC to fail to get tot he desktop. This as far as I know. Someone correct me if I'm wrong about this.

You could do it either way

If it's a startup item (HKLM\...\Windows\Run\ or in the startup folder) you could have errors "Cannot load xitygggh.dll" popup when you first reboot the computer, or entries in the event logs.

One instance where I've seen what you describe is rootkits that have been halfway cleaned up by customers already. If you reboot and it doesn't even show the windows screen but instead blacks out, and when starting in safemode it stops at isapnp.sys then you have a driver that is being used as a launchpoint for a rootkit, then you go into C:\Windows\System32\Drivers\ and hunt down 0 size files and rename them. But those are cases where you aren't going to find it with your scans and you are more dealing with the customers antivirus having halfway fixed it.

 

[othersteve]

Only problem is that many rootkits manage to feed the "proper" file information to the shell when it requests information about the patched files... so nowadays, it's less likely renaming in Safe Mode will even work, unless the rootkit is just sort of poorly written.

 

[RegEdit]

Only problem is that many rootkits manage to feed the "proper" file information to the shell when it requests information about the patched files... so nowadays, it's less likely renaming in Safe Mode will even work, unless the rootkit is just sort of poorly written.

Do rootkits launch from the usual registry startup locations?
HKLM/Software/Microsoft/Windows NT/Current Version/Winlogon/
HKLM/Software/Microsoft/Windows/Current Version/Run/
HKLM/Software/Microsoft/Windows/Current Version/Run/RunOnce

 

[Ccomp5950]

Do rootkits launch from the usual registry startup locations?
HKLM/Software/Microsoft/Windows NT/Current Version/Winlogon/
HKLM/Software/Microsoft/Windows/Current Version/Run/
HKLM/Software/Microsoft/Windows/Current Version/Run/RunOnce

No, it's usually a "patched" universal driver. Imapi.sys seems to be a common target. The driver is loaded before you even see the windows loading screen and does what it needs to do while redirecting any file checks afterwards to a file that is clean so it's effectively hidden itself.

 

[RegEdit]

If software can't remove it from the desktop then how do you remove it when it's a patched universal driver? Perhaps by slaving the drive to another (working) computer?

 

[MobileTechie]

That is the question isn't it? How do you find and remove rootkits. Your average AV software has some difficulty dealing with them and old-fashioned removal techniques as outlined in the famous Russinovitch vid are no longer enough. You sure as hell won't see many rootkits in Process Explorer.

A patched driver isn't the same as the non patched driver and the rootkit must intercept (hook) kernel processes to do its work. These differences can be detected and hooks can be unhooked.

That's way people are looking to tools like: Rootkit Unhooker, Kernel Detective and other manual tools that list hidden files, hooked processes and so on. Trouble is they are not simple to use in practice. They are easy to use on a fresh install but most older installations with apps running have all sorts of system changes that you have eliminate from your enquiries. E.g. apps from AVs to DVD burners will hook into the kernel. You need to know a fair bit about Windows internals to fully understand what you are doing with these tools. I use them but I'm not happy about my level of understanding with them.

 

[Ccomp5950]

If software can't remove it from the desktop then how do you remove it when it's a patched universal driver? Perhaps by slaving the drive to another (working) computer?

I PXE boot into a linux environment which mounts the drives, scans or manual inspection occurs there.

Other options are UBCD4Windows. I noticed that with the imapi.sys problems you could open up the view menu and select what columns to show and show version information, then sort by version information once it's done looking it all up (it does take a moment). Find the blank ones, those are your suspicious files, you will have about 5 or 6 max.

Back to imapi.sys problem... the version tab didn't show up under the file properties, that's how you could tell it was bad. But you had to look at it in a non-natively booted environment (UBCD4Windows) otherwise the rootkit showed the old files information by redirecting your query.

 

[othersteve]

Hey RegEdit, first off, sorry I missed your question!

One of the easiest ways to spot patched system files is to boot to a remote offline OS (or slave the drive), then:

1. To have a whitelist of known good system files, and
2. To check for Company information in the file.

If neither condition is met I begin an investigation of the driver. I actually have a script I am working on (I know, I've said this many times before, I just haven't completed it yet... life has gotten busy, having a baby, etc. etc.) which automates this process for me. It checks the file against a known whitelist I have started to create, then it checks Company information, compares THAT to a whitelist, and then if neither condition checks out, it even can check for the file's status in some places online. It's pretty handy, and it's what I used to find the most recent (zero-day) rootkit I dealt with this morning.

But often it's not much harder to just do it manually. If you can get a list of all unsigned drivers or files with no Company name in the system32 directory, you can work off of that. However it is very important to do this offline, as the smarter rootkits will simply feed you valid hash information and a good Company name (and digital signature) to keep you from finding them.

Alternatively, you can also try something like OTL, which scans at a very low level. But it requires quite a lot of practice to be used safely!