The scenario is: you know you are infected, because you’ve identified a process associate with a malware, but you can’t figure out how that given process is getting launched. A variation of this is: you kill the process, remove the executable but it reappears after a given amount of time / after reboot / etc.
A great tool to help you identify the source of the problems is Process Monitor (or Procmon for short) from Microsoft (formerly Sysinternals). It records all kind of actions related to the registry, filesystem and network with detailed information about the source of the call (process, stacktrace, etc). It can also perform this logging during bootup (which is useful, since malware can launch before you get to the desktop). Here is a short tutorial on how to use it:
The scenario is:
You have malware.bat in you system32 directory with the following content:
@echo off echo Boo! pause > NUL
It is being launched by launcher.bat, which is started because of an entry in the registry and has the following contents:
@echo off call c:WINDOWSsystem32malware.bat
Pretend that you don’t know this and want to find out how the “malware” gets started. So fire up Procmon and check “Enable Boot Logging”. You can also uncheck “Resolve Network Addresses”, because we are not interested in them currently and it speeds up things a little bit.
Now restart your computer and observe that the “malware” is launched. Now start Procmon again, and it will ask you if (and where) you want to save the capture file from this reboot:
After you saved the file, you can search in it and locate references to our “malware”. When you’ve located a reference, you can see the properties of the process when it executed the particular command. In our case it is cmd.exe running the “launcher”:
However, this was the easy part. The hard part is interpreting the results :-). A process can “touch” a file for many reasons. Don’t immediately assume that just because one process is related to the malware, it too is instantly malicious. For example, all programs registered in the “Run” and similar registry key are started by explorer.exe, which isn’t malware ;-). An other reason why a clean process could launch malicious files is because they’ve loaded a DLL related to the malware. Check the stack tab. Conversely, just because the name / icon looks familiar, don’t assume that it’s innocent. Check that it is in the right path (an old trick is to put executable in the system directory with the same names as the ones in system32). If possible, check that the digital certificate is valid (malware can for example modify the code in executables to launch itself – which invalidates the certificates). When in doubt, second check. Sites like VirusTotal can give you a good indicator on the “maliciousness” of the file. Also, you can submit your files to sandboxes like ThreatExpert or CWSandbox, and see how it behaves. This can give you and indication about other files you might need to take a look at.
Good luck and stay secure!
5 responses to “Using Procmon for finding malware”
cdman83
Off topic question:
Have you seen this yet?
Kon-Boot
Kon-Boot “root a box” on the fly .. it’s a kind of magic ! – Security Database Tools Watch
http://www.security-database.com/toolswatch/Kon-Boot-root-a-box-on-the-fly-it.html
I learned about it from a tipster earlier this week and tested it on a lab-box. Worked to bypass the Windows profile without any issues.
I’m not sure what is going on and if it is a Windows vulnerability or what.
Useful as a sysadmin but disconcerting from a security standpoint.
Would welcome your perspective if you have a chance.
Cheers,
–Claus V.
I couldn’t find much detail on the site, but from the modus operandi and from the fact that it has “boot” in the name, I theorize that it is an other “bootkit”.
There are a couple of these proof-of-concepts out there (for example Vbootkit – http://blogs.msdn.com/michael_howard/archive/2008/01/08/vbootkit-vs-bitlocker-in-tpm-mode.aspx) and even some malware which uses this technique (here is a good technical description on one of them: http://www2.gmer.net/mbr/) and they all work in a similar fashion: they write themselves to the MBR to get control of the machine before the OS does and the “hook” the function which reads from the hard-disk and lie to the OS (when it tries to load its file, the bootkit includes some of its code in the loaded file, so that when the OS executes its components, the malicious code also gets executed).
Currently the best defense against them is to use a drive encryption software which can co-operate with the TPM chipset (currently the only one I know of is the Vista BitLocker). Of course, you must take into account how this affects other IT procedures (like backups, re-imaging, data recovery, etc). An other low-level threat is the one of “BIOS rootkits”, when the BIOS gets re-flashed with some malicious code. From what I know, these are only present in proof-of-concept forms and have not been actually used in malware, but it is something to consider. You can defend against them by setting the “write-protect” jumper on the motherboard. Unfortunately many of the newer systems don’t have this jumper :-(.
PS. If you want something other scary, take a look at the firewire attack: http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation
cdman83 – Thanks for the perspective and linkage.
I’ve done some quick looks and this is awesome stuff.
I’m going to be studying them for a while!
We do use PGP WDE on our systems at work so the particulars of that process (PGP’s own proprietary boot sector code) should prevent any access to the encrypted main Windows boot sector/kernel via a boot-disk hack like this one seems to use.
I’ve tossed GMER and MBR.exe on a non PGP WDE system I tested the Kon-Boot program on and it doesn’t find any mods to the MBR were done (to the degree that these latest version can detect it at least.
Thanks a million for taking the time to indulge me on this question.
Cheers!
–Claus V.
It is my pleasure to provide quality security information. The most probable reason for GMER not finding the “bootkit” is because it doesn’t try to hide. The one GMER has detection for tries to return the original MBR when you try to load it.
As for PGP (or other full disk encryption products – like Truecrypt) protecting: unless they can use TPM to validate the MBR before executing it, they are bypassed, since the bootkits usually do it the following way:
1. save the old MBR somewhere
2. write themselves in the MBR
3. now, when the system is booted, they hook the disk access and the start running the old MBR
4. if this one was a full-disk encryption product, it will prompt the user for authentication and start decrypting the files
While it is true that current bootkits only look at the bytes effectively read from the disk, and thus encryption will thwart them, they are still in control and nothing stops them from accessing the decrypted files in the memory and patch them. The only 100% sure way is to use TPM to validate the fact that the MBR hasn’t changed before executing it.