Hi everyone
I'm coming from a theoretical standpoint, having negligible practical experience in Digital Forensics (we all have to start somewhere!). I've seen a number of forum posts, articles and presentations which stress the importance of having "known good" copies of various files on read-only media and I can appreciate the need for that, particularly when dealing with a likely malware-related problem.
I have XP and checked the .dll files used by my cmd.exe and I was amazed by just how many there are. As far as I'm aware, it's possible for malware to attack a .dll so a question that I have is why is it OK to use the .dlls on the target system but not the executable, such as cmd.exe?
I stumbled across the concept of dll redirection (hxxp//
Finally, I came across the idea of editing the PE header to avoid using system-wide .dlls but I haven't a clue how to go about this. Is this a viable alternative?
Thanks for your time (and patience!).
You might want to look at side by side assemblies to force the exe to use specific DLL's instead of editing the PE header..
http//
As for system dll's being used..there is no good reason to trust them, so assemblies or redirects are the best option.
> As for system dll's being used..there is no good reason to trust them
Well, the alternative is to load even more data (ie, DLLs) into memory, and while memory pages that are actively in use won't be overwritten, they may be "cannabilized" (term taken from "Forensic Discovery"), meaning that pages used by active processes may be swapped out to the pagefile. Depending upon what you're looking for, you may be making evidence harder to find, or you may be loosing valuable intel…this is all in addition to increasing the overall impact you're having on the system.
An alternative approach would be to simply dump all of the contents of physical memory first, and then look at collecting any subsets of volatile data. This way, you have the data you need first, with minimal impact. From there, follow your process, forcing EXEs to load specific DLLs via manifests (if I read the MS link correctly, most of the tools currently used will have to have manifests created for them).
Another approach, instead of using manifests, may be to examine the import tables of various tools that collect various bits of data, and use tools that use disparate API functions to retrieve the same or similar information. For example, one might use tlist.exe to collect the list of active processes, and then use openports.exe to collect process-to-port mapping information. If these two tools list disparate API functions in their import tables for collecting information about processes, then if you find a disparity in the data they provide, you may have found a compromised or "hooked" DLL.
One thought comes to mind, though…some user-mode rootkits use DLL hooking techniques, and they are fairly easy to detect using user-mode tools. A kernel-mode rootkit is more insidious, but then, at that point, it's (in the words of Bill Paxton in "Aliens") "…game over, man! Game over!"
Harlan