Using Procmon to find malware
The situation was worse than I'd anticipated and what seemed like a simple Scareware infection turned out to be rather crippling to a user account. There's been a surge of scareware recently (April 2010) and XP Defender Pro is certainly doing the rounds (pictured right) given that I've now found 2 infections in a week and other scareware too.
The scareware program itself is often harmless, merely popping up a fake anti-virus scanner, but it gets dangerous to your wallet as after it's identified a number of fake problems with your system the scareware authors will ask you to pay for their rubbish to "fix your problems".
Scareware gets more dangerous still when the Scareware author teams up with other "bad guys" to implement a "multi-warhead threat" that not only tries to steal your cash but can also be used to bring down other malware threats, a bit like a bully hijacking your party!
How did Procmon help?
On the computer in question only one user was affected by the XP Defender Pro scareware, everytime a program was launched up it would pop. It seemed reasonable to just knock the problematic file on the head so after it was tracked down to c:\Documents and Settings\User\Application Data\ave.exe (thanks to Mark for tracking it down) it got nuked - ave.exe was no more.
Sadly, the problems didn't stop there and every time the previously infected user attempted to launch a program (either from a shortcut or the run prompt) they'd receive a box asking what program they'd like to use to open the file. Changing user and running a virus scan didn't find anything but there must still be something - let's see what's going on, Procmon to the rescue.
A search of the registry for ave.exe at this point would have come to the same conclusions. However, we're interested in the quick route to the problem.
- Clearly given the problem running programs from the affected account we'll need another user so let's switch user at this point.
- Logon as a different user of the system (they'll need to be an administrator so if necessary drop into safe mode and create one).
- Run Procmon (you can download this quickly from http://live.sysinternals.com if you don't have it on the system in question) which should immediately start capturing events.
- Switch user and log back into the affected account.
- Try to run a program, switch back to the account running Procmon.
|Note - Switch User|
It's important to note we're using switch user here (part of fast user switching). If we were to log off we'd close Procmon and/or open user registry hives.
- From the file menu, select Capture events so the tick disappears. This stops Procmon from monitoring for the moment.
- Use the find tool to search for the Scareware's name, in this case ave.exe and Procmon will highlight one of the offending problems. As we can see from the screenshot (right) ave.exe has been found in the registry.
Ok, it's in the registry, so what?
There are many keys in the Windows Registry and it's not possible for any one person to know all of them (and what they do, what their possible values are). However, in this case let's break down what Procmon has shown us:
The registry key is reference as being at HKU\S-1-5-21-448539723-1078081533-682003330-1004_CLASSES\secfile\shell\open\command\(Default) which is a little bit tricky to understand - a brief breakdown:
- HKU means HKEY_USERS - when a user logs on their profile (a collection of their settings) is loaded into HKEY_CURRENT_USER (HKCU) and HKEY_USERS will also have a copy.
- S-1-5-21-44.... is the user's SID or Security Identify - a string that's unique to them. It ends in _CLASSES because it describes how certain files are processed.
- Other parts give us the complete path to the key which is called (Default).
Now, given it's not possible to know every registry piece of information I had to do some research at this point to find the correct key value for the (Default) key - it should be "%1" %* so I adjusted the value back to that.
The proof of the pudding
Switching back to the affected user and trying to load a program worked as the instruction was no longer trying to be passed through the bad, ave.exe, program.