I know, I haven't posted in a while...but then, I haven't really had a lot to post about, as I've been busy completing one project (book) and getting kicked off on another one...
Speaking
I've got a couple of upcoming speaking engagements in the next couple of months...
WACCI - I think I'm giving keynote 2 on Tues; I'm strongly considering using a discussion-style approach (as in "no PPT"), and broaching the subject of engaging and sharing between LE and the private sector in some manner. This is a bit of a sticky wicket, as one cannot simply pontificate on the need for LE to reach to the private sector to engage and share; without being LE, I'm afraid that I'd have little credibility in the matter.
PFIC2010 - I'll be heading to Utah in Nov for a couple of days, to present on "Windows System Forensics". Yeah, I know...lots of room there for me to mess this one up! ;-)
Windows Registry Forensics
I recently finished work on the Windows Registry Forensics book, including sending in the DVD master.
Here's a short description of the chapters:
Ch 1 - This chapter addresses some of what I consider to be the basic concepts of "analysis"; this book is about Registry analysis and as such, I thought it was important to lay out what I see to constitute Registry analysis. This chapter also goes into the purpose and structure of the Registry, in order to build a foundation for the analyst, for the rest of the book.
Ch 2 - This chapter addresses the tools that can be used to perform analysis of the Registry, in both live and post-mortem situations. This is kind of important, I think, because there are issues such as malware infections that really overwhelm both IT admins and responders; identifying Registry artifacts of an infection can allow you to comb the infrastructure using native or custom tools for other infected systems.
Note: This chapter does not address any commercial forensic analysis applications, for the simple reason that I did not have access to any of them, beyond Technology Pathways' ProDiscover.
Ch 3 - This chapter addresses Registry analysis from a system-wide perspective; that is, it addresses the files that compromise the system hives, and what information that is of value to an analyst that can be extracted from the hives. For example, I discuss what information is available from the SAM hive, and also include some tools that you can use to determine if a user has a password, and how you can crack it.
Ch 4 - This chapter addresses analyzing the user's hives.
With chapters 3 and 4, I took a bit of a different approach than I have in the past. Rather than listing key and value after key and value, I provided examples of how the information (key name, key LastWrite time, values, data, etc.) could be and have been used during incident response or during an examination.
The DVD includes a copy of the RegRipper tools (including the Plugin Browser), as well as all of the latest plugins that I've written, as of mid-Sept, 2010.
Open Source
Having finished the Registry book, I'm working diligently on my chapters of Digital Forensics with Open Source Tools, which I'm co-authoring with Cory Altheide (it was Cory's idea, and he's handling the lion's share of the writing).
Projects
I've run across a couple of interesting issues during analysis recently that I wanted to document, and the best way I found to do was to create what I'm referring to as a forensic system scanner, based on tools such as RegRipper and Nessus. The idea is that rather than memorizing the various things I've looked for or found, I can now mount an acquired image as a drive letter, and then run a number of plugins across the image. Much like RegRipper, the plugins can parse the Registry, but what I've done now is included checks for the file system, as well.
I'm designing/writing this scanner to be run against a mounted (via ImDisk, etc.) image, or against a system accessed via F-Response. Given this, it will also work with other mounting methods, such as Windows 7's ability to mount .vhd files. If you have a method for mounting .vmdk files, you could also use that. At this point, I've got a couple/half dozen or so working plugins and things seem to be moving smoothly in that regard. One plugin looks for .tmp files with 'MZ' signatures in the user profiles "Local Settings\Temp" directories...it gets the information about the profile paths from the ProfileList key. That plugin also checks for .exe files with 'MZ' signatures, as well. In both cases, if it finds any such files, it also computes an MD5 hash for each file.
Another plugin checks for a Zeus/Zbot infection. This plugin checks the UserInit value in the Software hive for the addition of "sdra64.exe", as well as checks the system32 directory within the image for the existence of the file. This plugin can be expanded to include any of the other file names that have been used, as well.
Chris Pogue has mentioned seeing the Perfect Key Logger in a number of exams; it is pretty simple and straightforward to write a plugin that checks for this, as well.
As with RegRipper, I can run either individual plugins, or lists of plugins, which I've taken to calling "profiles".
My overall thinking is that there can be a lot of things to look for out there, and if I can codify a check, I don't have to keep trying to remember all of them. God knows I'll get through an exam, deliver the final report, and think, "wow, I forgot to check for this...".
This scanner is NOT meant to completely comprehensive, nor is it meant to replace deep analysis. My goal here is to produce something that can be used as part of an in-processing procedure; get an image, verify it, copy it, then run the scanner against the working copy of the image. The report can then be provided along with either the image, or with selected files extracted from the image, to an analyst. This is intended to be more of a sweeper, but also a force multiplier...think of it; someone writes a check or plugin, and provides it to their team. Now, everyone on the team has the ability to run the same check, even though they don't all see the same thing on every engagement. With a central repository of well-documented plugins, we now have retention of corporate knowledge from each analyst.
Addendum: I was reading this MMPC post regarding Camec.A (they should have entitled the post "Getting a Brazilian"), and it occurred to me that this would be a great example of using the scanner I mentioned above. Specifically, you could easily write a plugin to check for this issue; one way to write it would be to simply check for the DLL files mentioned in the post, and if you find them, get and compare their hashes. Another way to write the plugin would be to add a Registry query for BHOs (RegRipper already has such a plugin), and then check for the files.
Again, once the plugin is written and added to the tool's plugins directory, every system that this is run against would be checked; the analyst running the scan would not need to know (or have memorized) the specifics indicators of the malware.
11 comments:
Harlan, the scanner is quite a promising project. Question: When you mount an image of a Vista/7 volume on a Vista/7 box, can you deal with the symlinks that would direct (I presume) your scanner to the local system target? As you know, this is an issue that arises in the routine mounting and virus-scanning of images. Thanks.
The scanner seems like a great tool which will speed up the analysis and will also reduce the errors that crop up when things are done manually.
Harlan are you maintaining a database of tests for different kinds of malware? If yes it would be great if you could share that somewhere (e.g. Win4n6 yahoo group).
Also looking forward to your book.
When you mount an image of a Vista/7 volume on a Vista/7 box, can you deal with the symlinks that would direct (I presume) your scanner to the local system target?
No idea...I don't have either one to test on. I do have a laptop running Windows 7, but I don't have an image of a Vista or Win7 system (yet) to work with.
Kaylan,
The scanner seems like a great tool which will speed up the analysis and will also reduce the errors that crop up when things are done manually.
That's part of what I'm trying to accomplish. Rather than forgetting some of those checks I tend to want to run (ie, contents of the hosts file, etc.), I can now view a report that includes the output of the checks.
Harlan are you maintaining a database of tests for different kinds of malware? If yes it would be great if you could share that somewhere (e.g. Win4n6 yahoo group).
I'm not sure what you're looking for. Most of the stuff I get (ie, Visal.B today) is from sites such as MMPC, etc. Some of it is expanded slightly beyond what is posted, largely due to the fact that write-ups on AV sites are often incomplete.
When you mention this database, what are you thinking of?
Jimmy,
Don't know about symlinks, but I have an image of a Vista system that I mounted, and updated one of my plugins that checks the "Local Settings\Temp" folders on XP/2003 systems so that the same plugin will run the same checks on the AppData\Local\Temp dir in user profiles on Vista and above systems.
I'm not sure what you're looking for. Most of the stuff I get (ie, Visal.B today) is from sites such as MMPC, etc. Some of it is expanded slightly beyond what is posted, largely due to the fact that write-ups on AV sites are often incomplete.
When you mention this database, what are you thinking of?
What I meant was a database which lists the name of malware, IIV, propagation mechanism etc. and where folks can add their observations, comments
But I guess you are right. MMPC itself is a good enough database.
Kalyan,
RegRipper has a number of tests for malware, as does the scanner.
There is no such database such as what you describe, that I'm aware of...perhaps you could start one.
Thanks.
[Harlan said]: I have an image of a Vista system that I mounted, and updated one of my plugins that checks the "Local Settings\Temp" folders on XP/2003 systems so that the same plugin will run the same checks on the AppData\Local\Temp dir in user profiles on Vista and above systems
Thanks, Harlan. I think that running a scan against that Vista path for a named user should work. The issue will arise if you try to run a scan in a mounted Vista/7 image in a Vista/7 host and, for example, scan \Users\All Users. In that instance, you may be scanning your own Program Data folder.
Jimmy,
That's something I've not really done before...and don't know why I (or someone else) would...but thanks for the heads up.
Actually, I did see that yesterday when working with a mounted XP image; when I opened the Tasks directory in the mounted image via Explorer, I saw my own folder contents (on my system) but accessing it via the command line ("dir /ah") let me see what I needed to see.
Harlan, as I think about this, you may encounter the same problem if you mount an image and try to scan the System Volume Information tree. That, however, is not a symlink issue, but one that concerns permissions.
This is something that I've talked about before in regard to running AV scanners on mounted images (where symlinks also may be an issue). The problem usually can be overcome by taking ownership; at least I've done that with MIP mounted images.
...you may encounter the same problem if you mount an image and try to scan the System Volume Information...
You're absolutely right...but this is not that kind of "scanner", per se. It's not meant to scan mounted images from beginning to end.
I'm not saying to skip the SIV directory. Someone can write a plugin, and as part of the in-processing procedures, take ownership of the directory and then run the scanner.
Again, it's a tool...like any other tool, it will have strengths and weaknesses. There will be times when it's a valuable tool to use, and there will be times when you wouldn't use it.
Also, the symlink doesn't appear to be an issue. I "found" a Vista image, and mounted it via ImDisk. When I went to the Tasks directory via Explorer, as expected, I saw the contents of my own Tasks directory. However, when I ran "dir" against that directory, I found what was in the image.
Post a Comment