I'd like to thank everyone who's responded to my query thus far, both on the lists as well as directly to me. I also contacted some other folks off-list and I'd like to share the outcome of what I've found, and perhaps invite discussion... The reason I asked the question about flushing DLLs was some research I've been doing into conducting 'live' forensics investigations on NT/2K (and ultimately XP). The "what to look for" issue isn't as sticky as the "how to look for it" one. In my reading I came across Dominique Brezinski's presentation from Blackhat '99. http://www.blackhat.com/html/bh-usa-99/bh3-speakers.html This presentation went right along with Rob Lee's web site, http://www.incident-response.org. Seeing that so much work has been done on Linux, *BSD, and *nix, I wanted to see if I could fill the gap for the MS platforms...provide a Win32 TCT, of sorts. Thanks to folks like JD Glaser, Mark Russinovich, Dave Roth, Todd Sabin, and many, many more, tools are not a problem. So I started to look at the issue of statically-linked binaries. How does one go about this without recompiling all of the tools, many of which the source is not readily available? Well, I decided, based on Dominique's presentation, one didn't have to. Simply run the tool, and use either listdlls.exe, or depends.exe from the RK, and then copy the tools and all of the DLLs it uses to CD. Sounds good so far. However, when approaching a system that is to be investigated, the current state of the machine is in question. At this point, I would like to point out as a matter of distinction that I am referring to 'live' forensics investigations...collecting volatile data from a system. I am not referring to taking the system down and making a bit-image copy of the drive. An active NT/2K system has many DLLs loaded into memory, and these libraries provide functions that the applications can call and make use of. However, L0pht pointed out a vulnerability that would allow an attacker to load trojaned DLLs into memory. So this is something we need to be careful of...if the investigator is trying to get a process listing, for example, perhaps a DLL could be trojaned to prevent the investigator from viewing certain processes. So the idea may be to flush all of the currently loaded DLLs from memory before running any of the investigative tools. However, thanks to JD and others, I've come to the conclusion that this is NOT something the investigator wants to do. JD put it simply...removing the DLLs that the currently loaded apps are relying on will cause GPFs...for those of you too young to remember Win3.1, that's a "BAD THING"(tm). After all, doesn't the investigator want to know which DLLs are loaded and being used? Using a combination of pslist.exe, pulist.exe (from the RK), whoami.exe (also from the RK), fport.exe and listdlls.exe, the investigator can get a pretty good idea of what's going on on the box. Sure, if the question comes up (ie, "Is it possible that a DLL could have been trojaned to provide false information?"), the answer would be 'yes, it's possible.' However, the investigator should use his knowledge, experience, and most importantly, a methodology to minimize the risk associated with such things. This, of course, also builds an excellent argument for admins using tripwire-like utilities to build a listing of files in the system32 dir (plus a few others), and generate MD5 and SHA1 hashes for each of them. Throw the appropriate ACLs and auditing into the mix, and you've got a good chance of not only preventing and detecting attempts to install trojaned DLLs, but you've also provided meaningful information for the investigator to use. Again, thanks to all of you who responded. I really appreciate it. If anyone wishes to pursue this discussion, I'd be happy respond via the lists or email... Carv __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Tue Oct 23 2001 - 10:18:05 PDT