Any time you want to see whether a DLL file is currently being used by any application on your system, you can pop up the search pane by going to the Find menu, hitting CTRL + F, or just clicking the binoculars icon on the toolbar. Now type in part of the name of the DLL, or even the full name if you’d like.
We chose to search for just the beginning, “SPVC”, since that was the common tie between them all, and sure enough, it looks like those DLLs are being loaded directly into each of the browser processes running on our computer.
Clicking on one of the items in the list and switching over to the Threads page confirmed what we were worried about. Both Chrome and Internet Explorer were running threads using the SPVC32.dll or SPVC64.dll files from the Search Protect malware, and this is how they were hijacking our new tab page — not by changing settings, but by hijacking the browser from within.
Note: In Windows, a thread is what the operating system allocates processor time to run. A process in Windows is what we’re used to thinking of as geeks and system admin types, but technically threads are actually the only thing that runs in Windows, not processes. Certain processes may have only one thread of execution, but others may have many threads that are all running separately from one another, usually communicating with some sort of in-process communication mechanism.
You can also double-click on any of the threads to see the full execution stack, which can be useful to see what functions are being called and attempt to figure out what the problem is.
You might be wondering how the Search Protect application managed to get Google Chrome to load that DLL, and the answer is that Windows provides a feature called DLL Injection. A process can inject a DLL into another process, and then hijack certain API functions. This is how certain applications override Windows features or features in other applications. It’s a very complicated subject that we definitely can’t get into in this lesson, but if you really want to read more, you can check out this guide.
It’s also worth noting that you can see the CPU usage per thread by digging into this level of details, which can be very useful when troubleshooting an application that has plugins. You could use this to figure out that a particular DLL file is taking up too much of the processor time, and then do some research on what that component belongs to.
Dealing with Locked Files or Folders
Since it’s unlikely that you’ll be investigating malware all the time, it’s also helpful to use Process Explorer for other tasks, like dealing with those “In Use” dialogs that you can any time you try to delete or move or modify a file or folder that is being used by another process, especially when you aren’t sure what process is locking it up.
When you get an error like that one, just head over to Process Explorer, open up the search with CTRL + F or the icon, and then type in the name of the folder listed above (or more descriptive full path if the name is very vague).
You’ll very quickly see a process in the list that has your file or folder open, and you can double-click on it to identify the process in the list.
Your immediate reaction might be to just close that process, but you don’t necessarily have to do that. You can also right-click on the file or folder in the list of handles (Use the CTRL + H option to bring up the Handles list) and choose the Close Handle option. That resource is now unlocked!
Note: If you’re deleting something, this is a perfectly fine option, but if you are just trying to edit or move that item, you should probably open the offending application and deal with it there so you don’t lose any data.
Researching Processes that Look Safe but Aren’t
During our malware research we’ve noticed another problem that is becoming more prevalent, so it is wise to keep an eye on it in the future. What is that problem? Malware is hiding behind legitimate Windows processes, and it’s doing a good job.
The problem is the Windows rundll32.exe utility, which can be used to arbitrarily run functions from DLL files. Since this utility is signed by Microsoft it shows up as a completely legit process in the list, but in reality what they are doing is just moving all of their malware / adware code into a .DLL file instead of a .EXE file, and then loading up the malware with rundll32.exe instead. In fact, if you see rundll32.exe running as an “own process” in the light blue color shown below, it’s nearly always something that shouldn’t be running.
In the example below, you can see that even though we used the Verified Signer feature to validate that item, when we hover over it and look at the full path, it is actually loading up a DLL that turns out to be part of an adware product.
Note: before you start screaming about running an anti-virus scan, we’ll note that we did, and it didn’t come back with anything. Much of this crapware, adware, and spyware is ignored by anti-virus utilities.
Double-clicking to open up the details shows more of the problem, and we can also see the directory that the badware is running out of, which we’ll use to investigate further.
Inside that directory we found a number of files that were being updated constantly in the background.
The rest of the investigation led into some other tools that weren’t SysInternals, and that we’ll probably cover at a later date, but suffice it to say that this is just a piece of malware that was running in conjunction with another crapware application.
The important point here is that malware is able to hide itself behind legitimate Windows executables, so be sure to keep your eyes peeled for anything similar.
Coming Up Next
Stay tuned tomorrow for even more SysInternals knowledge, as we show you how to use the Process Monitor utility to track what applications are actually doing behind the scenes. It’ll be eye-opening.