Hogfly emailed me last night to let me know that he'd posted a video on how to use F-Response and RegRipper together in live response. There's no audio to the video, but it's cool nonetheless...Hogfly does a great job of putting in cues, and focusing in so that the viewer can see what's going on up-close.
One thing that I wanted to address, though, is something that Hogfly stated in his blogpost:
Harlan has said this tool is not designed for live response...
For the record, I never said that. What I did say is:
RegRipper is NOT intended to be run on live Registry hive files.
There's a difference. RegRipper was NOT intended to be run against C:\Documents and Settings\hcarvey\NTUSER.DAT while I'm logged into my system...the hive file is live and locked by the system (populating the HKEY_CURRENT_USER hive in RegEdit). However, what Hogfly did was completely different...he used the excellent tool F-Response to access the remote drives as read-only physical disks, and then used FTK Imager to extract the hive files. You can do this on your own system as well...fire up FTK Imager, add your physical disk as an evidence item, and extract your hive files into another location in the file system. At that point, when you fire up RegRipper, you're not longer really doing "live response".
Thanks, Hogfly...great video! And a mighty THANKS goes out to Matt Shannon for coming up with F-Response...for recognizing and filling a very important need. With what's coming down the road with F-Response, as well as with other tools, the face of incident response and computer forensic analysis is now changing, in a very positive direction!
Thursday, April 24, 2008
Sunday, April 20, 2008
Updated RegRipper
I posted an updated version of RegRipper (2.01A, Basic Edition) up on SF.net...I had a couple of small updates to the GUI, mostly in the area of input validation (thanks to sippy for the input on that), but nothing to warrant a new version number, really. A quick run-down of updates includes:- GUI input validation stuff (thanks to sippy)
- Added '-c' switch to rip.exe, so that when you list the plugins (ie, 'rip -l') you can now get the output in CSV format
- Added some new plugins (SAMParse, WinNT_CV, ProfileList, BitBucket, etc.), as well as made some minor updates to a couple of others, based on my own testing and use, as well as a suggestion from a user
This download includes all of the plugins from the previous download, plus the ones mentioned above. Installing this package is as simple a extracting the files from the zip archive into the same directory you used with the previous version.
A couple of notes and reminders on the use of these tools...
- RegRipper is NOT intended to be run on live Registry hive files - feel free to do so, but please...if it doesn't work, I already know that! =)
- If you find that RegRipper did not apparently work properly, or you think it didn't, then please feel free to contact me...but please also include the log file generated by RegRipper (ie, rr-
- Keep in mind that while the edition of RegRipper you're using is fully functional, there is additional functionality that has been incorporated into the Advanced edition of the tool, such as support for selecting and using arbitrary plugins files, etc. I've included this in the documentation...so if you have feature requests, please consult the FAQ and file named "regripper.pdf" first.
- Please be sure to read the documentation (FAQ, regripper.pdf) if you have any questions. I have received requests to provide plugins for USB removable storage devices...after I put in the effort to write and test the plugin, and included it in the distribution.
For those of you who have tried/used RegRipper, I hope you've found it as useful as I continue to find it just about every day. For those of you who have commented or provided feedback, I thank you very much for that.
Other stuff...
On a side note, I added an experimental '-g' switch to the version of rip.exe that I keep with the Advanced edition of RegRipper...this switch does some guessing as to what kind of hive file the analyst is pointing to. One of the things I've been toying with on the side, something requested by a friend, is the ability to parse not only a specific hive file, but to then access the Restore Points on XP, and run that same plugin against the appropriate hive file within each RP. I've got most of the code working, at this point it's simply a matter of tying it together and having the output in a readable format.
Free Analysis
What??!? "Free" (as in 'beer') analysis? A bit ago, I blogged about Forensic Analysis on the Cheap, and I wanted to revisit that topic, particularly to mention a couple of tools I've run across since then...
Event Logs
In an earlier post, I mentioned some tools you could use to perform Event Log analysis. I still like the functionality in EvtUI (although I may be seen as biased because I wrote it), but if tools like this scare you, there are other options available. For example, Event Log Explorer is a nice little little app, and you can obtain a free license for its use. In direct mode, it works just like EvtUI, accessing the event records directly within a .evt file extracted from an acquired image.
Registry Analysis
I have to say that I'm really partial to RegRipper and its associated CLI utility, rip.exe. A couple of minor tweaks, as well as some new plugins, both of which were recently added, make this an immensely useful (not to mention unique) tool.
When looking for things I may want/need to add as plugins to RegRipper, my favorite Registry Viewer to use is MiTeC's RFV. I can go through the hive file and look at things, and fire rip.exe off against it without having to unload the hive or anything like that. RFV is a great Registry Viewer that facilitates the development of plugins.
File Carving
I've mentioned scalpel before as a tool for file carving...XaberSoft provides a GUI interface for setting up the scalpel config file
Another useful tool for file carving is PhotoRec. Even though its intended for extracting image files, I'm sure that there are a number of folks out there interested in doing just that...
Other Tools
Shadow Explorer - I haven't had an opportunity to try this tool yet, but I'm told that it's great for recovering files using Vista's Volume Shadow Copy Service. If you can boot an acquired image using LiveView, and log into the running image, you may be able to get some useful information or recover some files using this tool.
Event Logs
In an earlier post, I mentioned some tools you could use to perform Event Log analysis. I still like the functionality in EvtUI (although I may be seen as biased because I wrote it), but if tools like this scare you, there are other options available. For example, Event Log Explorer is a nice little little app, and you can obtain a free license for its use. In direct mode, it works just like EvtUI, accessing the event records directly within a .evt file extracted from an acquired image.
Registry Analysis
I have to say that I'm really partial to RegRipper and its associated CLI utility, rip.exe. A couple of minor tweaks, as well as some new plugins, both of which were recently added, make this an immensely useful (not to mention unique) tool.
When looking for things I may want/need to add as plugins to RegRipper, my favorite Registry Viewer to use is MiTeC's RFV. I can go through the hive file and look at things, and fire rip.exe off against it without having to unload the hive or anything like that. RFV is a great Registry Viewer that facilitates the development of plugins.
File Carving
I've mentioned scalpel before as a tool for file carving...XaberSoft provides a GUI interface for setting up the scalpel config file
Another useful tool for file carving is PhotoRec. Even though its intended for extracting image files, I'm sure that there are a number of folks out there interested in doing just that...
Other Tools
Shadow Explorer - I haven't had an opportunity to try this tool yet, but I'm told that it's great for recovering files using Vista's Volume Shadow Copy Service. If you can boot an acquired image using LiveView, and log into the running image, you may be able to get some useful information or recover some files using this tool.
Friday, April 18, 2008
Cutaway does Windows IR
The Security Ripcord site has a great new article on Windows IR, and using system resources to get the data you need.
I know that some folks are going to have an issue with using system resources (ie, DLLs, etc) when performing any kind of IR, but to be honest, I honestly believe (based on experience) that if more folks had stopped using that as a roadblock for doing any kind of response at all, there would likely be fewer instances of reported breaches, and breaches may have been less severe.
All incident response starts with the same basic elements and questions as any other system troubleshooting. The problem seems to start when admins and responders simply have no idea what it is they need to be looking at, or for. Don's article does a great job of bringing that to light, as well as providing a means of acquiring the necessary data. Not only does Don explain what is accessed and why, he also provides caveats about the artifacts left on the system as a result of the admin or responder's interactions with the system. This is very important, as anytime you access a live system, you're going to leave artifacts of one kind or another...being able to distinguish between your actions and the user's actions may be very important. Scripts such as what Don provided are self-documenting, in that all you have to do is ensure that you keep track of when (as in "what time") you ran the script, and then include a copy of the script along with your case notes.
A great big thanks and Semper Fi to Don for providing this article and script! It's information like this that's going to break down the barriers of inaction and provide for better response to all sorts of issues, large and small.
I know that some folks are going to have an issue with using system resources (ie, DLLs, etc) when performing any kind of IR, but to be honest, I honestly believe (based on experience) that if more folks had stopped using that as a roadblock for doing any kind of response at all, there would likely be fewer instances of reported breaches, and breaches may have been less severe.
All incident response starts with the same basic elements and questions as any other system troubleshooting. The problem seems to start when admins and responders simply have no idea what it is they need to be looking at, or for. Don's article does a great job of bringing that to light, as well as providing a means of acquiring the necessary data. Not only does Don explain what is accessed and why, he also provides caveats about the artifacts left on the system as a result of the admin or responder's interactions with the system. This is very important, as anytime you access a live system, you're going to leave artifacts of one kind or another...being able to distinguish between your actions and the user's actions may be very important. Scripts such as what Don provided are self-documenting, in that all you have to do is ensure that you keep track of when (as in "what time") you ran the script, and then include a copy of the script along with your case notes.
A great big thanks and Semper Fi to Don for providing this article and script! It's information like this that's going to break down the barriers of inaction and provide for better response to all sorts of issues, large and small.
Tuesday, April 08, 2008
RegRipper on SF.net
Sunday, April 06, 2008
Bejtlich on IR, Forensics
Richard Bejtlich, of TaoSecurity fame, recently blogged about an article he'd written for CSO Magazine, entitled Computer Incident Detection, Response, and Forensics: the Basics. It's a very interesting article, and supports a great deal of what I've seen from various sources over the past year, as well as some of my own practical experience as an incident responder.
The biggest thing I picked up on is that here is Richard talking about how "pulling the plug" is not necessarily the immediate-action-of-choice these days...this is very true. For example, a system gets compromised and network logs indicate that there is a significant amount of traffic leaving that system (albeit the fact that the network logs do not contain content...). The first thing that most IT admins tend to do is take the system off-line (off the network), and in some cases even shut down or simply reboot the system. Then the big, $64,000 question that needs to be answered...for the CIO or for an external regulatory body...is, what was going out? Was it some sort of homing beacon, or was it actual data (ie, sensitive data, as defined by CA's SB1386 or AB1298)?
In pulling the plug, other questions are also difficult to answer...was this system as stepping stone to other systems, or was itself attacked from another system? If so, what/where are those systems? Ooops...no more network connection information...now I have query every system in the infrastructure, and because I shut this system down, I don't have a recognizable footprint to look for. =(
Had the first responders had the right tools and training available, they could have captured necessary data prior to taking those immediate actions.
One aspect of the article I don't agree with is the statement that prevention eventually fails. Ever since I was in the military, I had a problem with folks saying that something was failure when it was never proper implemented in the first place. While it's true that defenders have to protect all avenues of ingress and an attacker only needs to find one way in, incident analysts have seen enough intrusion incidents over the past couple of years to know that a great many infrastructures (small and large) have enough poorly configured systems (not rogue or unknown...all of these systems are known, and quite simply not properly configured) as to not have much in the way of defenses. I do agree that detection needs to be properly implemented alongside prevention, but I'd like to see prevention properly implemented before we simply rule it a failure.
Overall, the article is a very good read...and like many articles that make predictions that this is the Year of Whatever, we'll have to wait and see.
The biggest thing I picked up on is that here is Richard talking about how "pulling the plug" is not necessarily the immediate-action-of-choice these days...this is very true. For example, a system gets compromised and network logs indicate that there is a significant amount of traffic leaving that system (albeit the fact that the network logs do not contain content...). The first thing that most IT admins tend to do is take the system off-line (off the network), and in some cases even shut down or simply reboot the system. Then the big, $64,000 question that needs to be answered...for the CIO or for an external regulatory body...is, what was going out? Was it some sort of homing beacon, or was it actual data (ie, sensitive data, as defined by CA's SB1386 or AB1298)?
In pulling the plug, other questions are also difficult to answer...was this system as stepping stone to other systems, or was itself attacked from another system? If so, what/where are those systems? Ooops...no more network connection information...now I have query every system in the infrastructure, and because I shut this system down, I don't have a recognizable footprint to look for. =(
Had the first responders had the right tools and training available, they could have captured necessary data prior to taking those immediate actions.
One aspect of the article I don't agree with is the statement that prevention eventually fails. Ever since I was in the military, I had a problem with folks saying that something was failure when it was never proper implemented in the first place. While it's true that defenders have to protect all avenues of ingress and an attacker only needs to find one way in, incident analysts have seen enough intrusion incidents over the past couple of years to know that a great many infrastructures (small and large) have enough poorly configured systems (not rogue or unknown...all of these systems are known, and quite simply not properly configured) as to not have much in the way of defenses. I do agree that detection needs to be properly implemented alongside prevention, but I'd like to see prevention properly implemented before we simply rule it a failure.
Overall, the article is a very good read...and like many articles that make predictions that this is the Year of Whatever, we'll have to wait and see.
Saturday, April 05, 2008
Ripping the Registry w/ rip.exe
While I was developing the RegRipper, I found that I could use some means of testing plugins without having to fire up the RegRipper GUI each time, particularly if I just wanted to modify how the output was displayed...for example, once I got all the information I needed, say that I wanted to parse it and have it displayed based on the Registry key LastWrite times (so that it's easier to correlate to an incident timeline...). Do I want to fire things up all over again, or simply re-run the last command line?
So I wrote rip.exe, a small CLI utility that uses the same plugin structure as RegRipper, and lets me either run a single plugin against a hive file, or run an entire plugins file against a hive file. Here's what the syntax for rip.exe looks like:
Rip [-r Reg hive file] [-f plugin file] [-p plugin module] [-l] [-h]
Parse Windows Registry files, using either a single module, or a plugins file.
All plugins must be located in the "plugins" directory; default plugins file
used if no other filename given is "plugins\plugins".
-r Reg hive file...Registry hive file to parse
-f [plugin file]...use the plugin file (default: plugins\plugins)
-p plugin module...use only this module
-l ................list all plugins
-h.......................Help (print this information)
Ex: C:\>rr -r c:\case\system -f system
C:\>rr -r c:\case\ntuser.dat -p userassist.pl
C:\>rr -l
All output goes to STDOUT; use redirection (ie, > or >>) to output to a file.
copyright 2008 H. Carvey
Pretty cool. I even threw in a switch to just list all of the plugins in the plugins directory; the output includes the name of the plugin, the version, which hive file each plugin is for (ie, NTUSER.DAT, System, Software, etc.), and brief description of what the plugin does. Here are a couple of examples:
7. auditpol v.20080327 [Security]
- Get audit policy from the Security hive file
8. bho v.20080325 [Software]
- Gets Browser Helper Objects from Software hive
9. cmd_shell v.20080328 [Software]
- Gets shell open cmds for various file types
10. comdlg32 v.20080324 [NTUSER.DAT]
- Gets contents of user's ComDlg32 key
11. compdesc v.20080324 [NTUSER.DAT]
- Gets contents of user's ComputerDescriptions key
12. compname v.20080324 [System]
- Gets ComputerName value from System hive
13. devclass v.20080331 [System]
- Get USB device info from the DeviceClasses keys in the System hive
14. fw_config v.20080328 [System]
- Gets the Windows Firewall config from the System hive
So let's say that I have an image of a Windows system, and I've either extracted the Registry hive files from the image and placed them in a directory, or I've mounted the image file as a read-only file system using Mount Image Pro or VDKWin. If I want to take a cursory look at some things to sort of get an idea of what I'm looking at, I can run rip.exe to collect info for me:
C:\tools>rip rip -r d:\cases\ntuser.dat -p userassist
Let's say that I want to run an entire plugins file against a hive file...
C:\tools>rip rip -r f:\windows\system32\config\software -f software
Pretty straight-forward, simple, and quick. Very efficient, and keeps mistakes down. Rip.exe can also be incorporated into a batch file, to further enhance processing and reduce an analyst's interaction with the data even further.
So I wrote rip.exe, a small CLI utility that uses the same plugin structure as RegRipper, and lets me either run a single plugin against a hive file, or run an entire plugins file against a hive file. Here's what the syntax for rip.exe looks like:
Rip [-r Reg hive file] [-f plugin file] [-p plugin module] [-l] [-h]
Parse Windows Registry files, using either a single module, or a plugins file.
All plugins must be located in the "plugins" directory; default plugins file
used if no other filename given is "plugins\plugins".
-r Reg hive file...Registry hive file to parse
-f [plugin file]...use the plugin file (default: plugins\plugins)
-p plugin module...use only this module
-l ................list all plugins
-h.......................Help (print this information)
Ex: C:\>rr -r c:\case\system -f system
C:\>rr -r c:\case\ntuser.dat -p userassist.pl
C:\>rr -l
All output goes to STDOUT; use redirection (ie, > or >>) to output to a file.
copyright 2008 H. Carvey
Pretty cool. I even threw in a switch to just list all of the plugins in the plugins directory; the output includes the name of the plugin, the version, which hive file each plugin is for (ie, NTUSER.DAT, System, Software, etc.), and brief description of what the plugin does. Here are a couple of examples:
7. auditpol v.20080327 [Security]
- Get audit policy from the Security hive file
8. bho v.20080325 [Software]
- Gets Browser Helper Objects from Software hive
9. cmd_shell v.20080328 [Software]
- Gets shell open cmds for various file types
10. comdlg32 v.20080324 [NTUSER.DAT]
- Gets contents of user's ComDlg32 key
11. compdesc v.20080324 [NTUSER.DAT]
- Gets contents of user's ComputerDescriptions key
12. compname v.20080324 [System]
- Gets ComputerName value from System hive
13. devclass v.20080331 [System]
- Get USB device info from the DeviceClasses keys in the System hive
14. fw_config v.20080328 [System]
- Gets the Windows Firewall config from the System hive
So let's say that I have an image of a Windows system, and I've either extracted the Registry hive files from the image and placed them in a directory, or I've mounted the image file as a read-only file system using Mount Image Pro or VDKWin. If I want to take a cursory look at some things to sort of get an idea of what I'm looking at, I can run rip.exe to collect info for me:
C:\tools>rip rip -r d:\cases\ntuser.dat -p userassist
Let's say that I want to run an entire plugins file against a hive file...
C:\tools>rip rip -r f:\windows\system32\config\software -f software
Pretty straight-forward, simple, and quick. Very efficient, and keeps mistakes down. Rip.exe can also be incorporated into a batch file, to further enhance processing and reduce an analyst's interaction with the data even further.
Registry Analysis Myths
No, sorry...I don't have a lisp...
Based on a recent comment, it occurred to me that there are several myths regarding Registry analysis that are apparently accepted as fact...and I'd like to address those myths...
Myth #1
Registry analysis is time intensive.
Anything we don't understand is inherently "time intensive" due to the learning curve. However, think about when you were a teen-ager (for folks like me, that era is lost in the mists of time...) and you had a passionate desire to learn to drive. Learning to drive was time intensive, wasn't it? After all, in most cases, we didn't know how and had to learn...which took time (more so if you were learning to drive a stick). Leap forward to adulthood, and think about how "time intensive" it was to learn to do computer forensic analysis, either on your own or through vendor-specific training. Until you understand something, everything is time intensive. Maybe Blade said it best: When you understand the nature of a thing, you know what it's capable of.
Tools like the RegRipper remove the need for opening hive files by hand to search for specific keys, value names and data, and then, if necessary, translating them by hand. How cumbersome would it be to navigate to the UserAssist keys via RegEdit, and have to translate every value name (un-ROT-13) and then translate every FILETIME object? Eesh...I don't wanna think about it...b/c I can do it quickly by firing up the RegRipper, or just use rip.exe. Fast, efficient, and I get my output sorted based on the timestamps. Suh-weet!
Myth #2a
Registry analysis solves everything.
Not true...like any other form of forensic analysis, Registry analysis has its own inherent limitations. For one, if the data isn't there, it can't be analyzed...kind of simplistic, I know, but thanks to shows like CSI, some folks think that computer forensics can show files copied to and from a hard drive, without the other piece of media. There are limits to everything.
Myth #2b
Registry analysis has absolutely no benefit.
Again, not true. Registry analysis can show things not evident through traditional forensic analysis, such as associating specific activities with a specific user account, or showing that certain files (by name) were viewed long after the files themselves have been deleted from the system and overwritten. The same is true with applications on the system...information about EXEs that had once been on the system can be found in the UserAssist, MUICache, App Paths, and possibly even in the Uninstall key values.
Registry analysis can also show that certain files had been accessed...not only that they had been, but possibly even when and how/in what manner, by a specific user. Sometimes, this information can't be found through normal ASCII text searches, because the data itself if stored as a binary data type, and must be parsed into something that is human readable.
Based on a recent comment, it occurred to me that there are several myths regarding Registry analysis that are apparently accepted as fact...and I'd like to address those myths...
Myth #1
Registry analysis is time intensive.
Anything we don't understand is inherently "time intensive" due to the learning curve. However, think about when you were a teen-ager (for folks like me, that era is lost in the mists of time...) and you had a passionate desire to learn to drive. Learning to drive was time intensive, wasn't it? After all, in most cases, we didn't know how and had to learn...which took time (more so if you were learning to drive a stick). Leap forward to adulthood, and think about how "time intensive" it was to learn to do computer forensic analysis, either on your own or through vendor-specific training. Until you understand something, everything is time intensive. Maybe Blade said it best: When you understand the nature of a thing, you know what it's capable of.
Tools like the RegRipper remove the need for opening hive files by hand to search for specific keys, value names and data, and then, if necessary, translating them by hand. How cumbersome would it be to navigate to the UserAssist keys via RegEdit, and have to translate every value name (un-ROT-13) and then translate every FILETIME object? Eesh...I don't wanna think about it...b/c I can do it quickly by firing up the RegRipper, or just use rip.exe. Fast, efficient, and I get my output sorted based on the timestamps. Suh-weet!
Myth #2a
Registry analysis solves everything.
Not true...like any other form of forensic analysis, Registry analysis has its own inherent limitations. For one, if the data isn't there, it can't be analyzed...kind of simplistic, I know, but thanks to shows like CSI, some folks think that computer forensics can show files copied to and from a hard drive, without the other piece of media. There are limits to everything.
Myth #2b
Registry analysis has absolutely no benefit.
Again, not true. Registry analysis can show things not evident through traditional forensic analysis, such as associating specific activities with a specific user account, or showing that certain files (by name) were viewed long after the files themselves have been deleted from the system and overwritten. The same is true with applications on the system...information about EXEs that had once been on the system can be found in the UserAssist, MUICache, App Paths, and possibly even in the Uninstall key values.
Registry analysis can also show that certain files had been accessed...not only that they had been, but possibly even when and how/in what manner, by a specific user. Sometimes, this information can't be found through normal ASCII text searches, because the data itself if stored as a binary data type, and must be parsed into something that is human readable.
More about the Registry...
While my recent posts have been about Registry analysis, I didn't want to ignore the work that has been done with regards to extracting Registry information (key, values, etc.) from other sources, such as RAM and process dumps, unallocated space, the pagefile, etc.
Moyix over at the Push The Red Button blog has posted some really good information lately on Registry cell index translation, even going back to his enumerating Registry hives post from Feb. He's got a great deal of excellent information in these posts that can be used to merge Registry and physical memory analysis.
Segue: While we're on the subject of memory analysis, check out this "Practical of "15 Minute Virus Analysis"" post from the ForensicZone...seems someone found a good use for lspm.exe. ;-)
Registry Slack
Also, there's a question of Registry slack...cells within a hive file that contain key or value data, but are not recognized by the MS API. This is different from unused keys and values that still exist after an application has been removed from the system...largely due to the fact that these keys and values may still be viewable via RegEdit or any other tool. What I'm referring to is this...Registry key cells contain pointers to other key cells, as well as values...so basically, everything you see in most Registry viewers is a result of following links from root key, in much the same way as every file within an active file system will have a path back to the root directory. However, the question of Registry slack...cells within the hive file that may be valid key or value cells but are not linked into the visible Registry structure...still remains unanswered. Hopefully, though, not for long...there's a thesis student in Europe who has taken on the exercise of exploring this area.
Moyix over at the Push The Red Button blog has posted some really good information lately on Registry cell index translation, even going back to his enumerating Registry hives post from Feb. He's got a great deal of excellent information in these posts that can be used to merge Registry and physical memory analysis.
Segue: While we're on the subject of memory analysis, check out this "Practical of "15 Minute Virus Analysis"" post from the ForensicZone...seems someone found a good use for lspm.exe. ;-)
Registry Slack
Also, there's a question of Registry slack...cells within a hive file that contain key or value data, but are not recognized by the MS API. This is different from unused keys and values that still exist after an application has been removed from the system...largely due to the fact that these keys and values may still be viewable via RegEdit or any other tool. What I'm referring to is this...Registry key cells contain pointers to other key cells, as well as values...so basically, everything you see in most Registry viewers is a result of following links from root key, in much the same way as every file within an active file system will have a path back to the root directory. However, the question of Registry slack...cells within the hive file that may be valid key or value cells but are not linked into the visible Registry structure...still remains unanswered. Hopefully, though, not for long...there's a thesis student in Europe who has taken on the exercise of exploring this area.
Windows Oddities
Here are a couple of odd things about forensic analysis of Windows systems that I thought I'd share...
Windows Accounts
A user on one of the lists recently sent in an email with a question that I thought others might be interested in...well, interested in the question, and the answer...
The user said that they'd found profiles on an XP system with the following format for the directory names:
UserName
UserName.DomainName
UserName.DomainName.000
Evidently, according to this information on EvilBytes, this can occur when the user looses "Full Control" to their profile directory.
Fortunately, MS has something to say about this, as well...
Ch. 7 - Intro to Config and Mgmt
If another user with an account name jeffsmith logs on to the same Windows 2000 Professional–based computer from an identically named source (either a domain or local computer) and the SIDs of the two accounts are not the same, a new folder is created with an extension indicating how many times the user account name was used. This occurs when the user accounts are re-created and the user logs on to the same computer...
Also see:
How to restore a user profile in Windows 2000
How to restore a user profile in Windows 2003
Mrt.log
I was looking up something related to running a checked build of netlogon.dll today and I ended up in the %SystemRoot%\Debug directory. I saw a couple of log files, one of them named "mrt.log". Evidently, this is an MS Malicious Software Removal Tool log file...follow the previous link to get a list of software that is detected and removed by MSRT. This can be useful information for a forensic examiner, particularly when coupled with any AV software that is installed on the system...you get a version number, the date/time that it was last run, as well as the results. Say you're examining a system that has Symantec's product installed, as well as MSRT...it would then make sense to review the data available in these logs, and then use a disparate product when scanning for malware.
Passwd.log
While looking at the mrt.log file, I noticed that in the same directory is a passwd.log file and thought that was curious. Not surprisingly I found NO information at MS about this file whatsoever...however, I did find one post that indicated that the file is used by lsass.exe to record information about the TSInternetUser account's password attempts, changes, etc. Granted, the post is six years old...but still, this may remain a valid use for the file. Additional posts found on Google (by searching the Web and Groups...) indicate that it may be associated with more than just the TSInternetUser account, but it definitely appears to be associated with the SamChangePasswordUser2 API.
If your passwd.log file has entries approximately every 24 hrs, associated with the TSInternetUser account, you may want to look to MS KB Q244057 for some useful info.
Resources
A Guide to Basic Computer Forensics
Windows Accounts
A user on one of the lists recently sent in an email with a question that I thought others might be interested in...well, interested in the question, and the answer...
The user said that they'd found profiles on an XP system with the following format for the directory names:
UserName
UserName.DomainName
UserName.DomainName.000
Evidently, according to this information on EvilBytes, this can occur when the user looses "Full Control" to their profile directory.
Fortunately, MS has something to say about this, as well...
Ch. 7 - Intro to Config and Mgmt
If another user with an account name jeffsmith logs on to the same Windows 2000 Professional–based computer from an identically named source (either a domain or local computer) and the SIDs of the two accounts are not the same, a new folder is created with an extension indicating how many times the user account name was used. This occurs when the user accounts are re-created and the user logs on to the same computer...
Also see:
How to restore a user profile in Windows 2000
How to restore a user profile in Windows 2003
Mrt.log
I was looking up something related to running a checked build of netlogon.dll today and I ended up in the %SystemRoot%\Debug directory. I saw a couple of log files, one of them named "mrt.log". Evidently, this is an MS Malicious Software Removal Tool log file...follow the previous link to get a list of software that is detected and removed by MSRT. This can be useful information for a forensic examiner, particularly when coupled with any AV software that is installed on the system...you get a version number, the date/time that it was last run, as well as the results. Say you're examining a system that has Symantec's product installed, as well as MSRT...it would then make sense to review the data available in these logs, and then use a disparate product when scanning for malware.
Passwd.log
While looking at the mrt.log file, I noticed that in the same directory is a passwd.log file and thought that was curious. Not surprisingly I found NO information at MS about this file whatsoever...however, I did find one post that indicated that the file is used by lsass.exe to record information about the TSInternetUser account's password attempts, changes, etc. Granted, the post is six years old...but still, this may remain a valid use for the file. Additional posts found on Google (by searching the Web and Groups...) indicate that it may be associated with more than just the TSInternetUser account, but it definitely appears to be associated with the SamChangePasswordUser2 API.
If your passwd.log file has entries approximately every 24 hrs, associated with the TSInternetUser account, you may want to look to MS KB Q244057 for some useful info.
Resources
A Guide to Basic Computer Forensics
Tuesday, April 01, 2008
More Registry Analysis...
I think that in discussing Registry analysis, one of the shortcomings we're facing is the translation to the analyst of why something like this is (or can be) important, and how it can be used to benefit the analyst, as well as support an examination. After all, I think that most folks understand, perhaps somewhat intuitively, the usefulness of files within the active file system (as well as file metadata, such as MAC times), log file entries, etc. Where Registry analysis is falling short (from an adoption perspective) is (a) a solid understanding by the analyst of how this can benefit an exam, and (b) easy, intuitive tools for conducting Registry analysis.
Well, I think we've covered (b) pretty well...or, at the very least, started addressing it.
A short, Reader's Digest version of (a) is that the Registry holds a great deal of configuration information about the system, as well as information specific to the user's activities on the system. Much of this information is timestamped, as well (Note: recent experience shows that Win98/ME Registry keys do not enjoy the privilege of a LastWrite time...), making the Registry extremely useful and akin to a log file.
Now, Registry analysis will not benefit every exam, of course...each exam has it's own unique twists, and if you're a consultant, requirements. However, a great deal of Registry analysis is straightforward, simple, and easily accomplished...and in some cases can greatly benefit your exam. For example, consider this blog post by SynJunkie...a while back, I'd figured out that some AV vendors we're maybe passing some spurious info in their malware write-ups, and decided to look into the MUICache key. In the absence of any credible documentation from the vendor, some folks have found something very useful about this key.
Traditional file system-based computer forensic analysis may show the analyst that an image or movie is or was on a system...Registry analysis will show you who viewed it, and possibly even when. In the past, I've used Registry analysis to show that one employee was connecting to another employee's system and grabbing copies of her Trillian logs, and reading all of her conversations...I was even able to demonstrate that he'd viewed some of her log files and then deleted them, as well as the most recent time that he'd read one of those log files.
Well, I think we've covered (b) pretty well...or, at the very least, started addressing it.
A short, Reader's Digest version of (a) is that the Registry holds a great deal of configuration information about the system, as well as information specific to the user's activities on the system. Much of this information is timestamped, as well (Note: recent experience shows that Win98/ME Registry keys do not enjoy the privilege of a LastWrite time...), making the Registry extremely useful and akin to a log file.
Now, Registry analysis will not benefit every exam, of course...each exam has it's own unique twists, and if you're a consultant, requirements. However, a great deal of Registry analysis is straightforward, simple, and easily accomplished...and in some cases can greatly benefit your exam. For example, consider this blog post by SynJunkie...a while back, I'd figured out that some AV vendors we're maybe passing some spurious info in their malware write-ups, and decided to look into the MUICache key. In the absence of any credible documentation from the vendor, some folks have found something very useful about this key.
Traditional file system-based computer forensic analysis may show the analyst that an image or movie is or was on a system...Registry analysis will show you who viewed it, and possibly even when. In the past, I've used Registry analysis to show that one employee was connecting to another employee's system and grabbing copies of her Trillian logs, and reading all of her conversations...I was even able to demonstrate that he'd viewed some of her log files and then deleted them, as well as the most recent time that he'd read one of those log files.
Monday, March 31, 2008
WFA slashdotted!
Yes, WFA was slashdotted! Thanks to Don for the review!In the past (Aug 2004), Richard Bejtlich showned a correlation between a book review appearing on Slashdot.org, and higher traffic to his blog, as well as "better" numbers at book vendors sites. Hopefully I can expect to see a similar effect...
Addendum, 1 April
Okay, this isn't a joke...here's a portion of the WFA page on Amazon from today (1 April 2008), prior to 3pm EST:
Comparatively speaking, "Windows Forensics and Incident Recovery" is listed as follows:
All in all, pretty cool. ;-)
Friday, March 28, 2008
Registry Analysis - What Is It??
That's right...what is this thing we call "Registry analysis"? When someone performs "Registry analysis", what are they doing?
Okay...raise your hand if, for you, Registry analysis consists of looking for strings (using strings, or BinText, or your favorite tool), or maybe using grep() to do regex searches for IP addresses, email addresses, or something else.
Great, thanks. You can put your hands down.
Now, raise your hand if when performing Registry analysis, you open the hive files you're interested in with one of the popular Registry viewers (EnCase, FTK, ProDiscover, or even good ol' RegEdit), and "look around for anything interesting". Keep it up there if you use some sort of checklist or spreadsheet of Registry keys that may be of interest for your case or exam.
Okay...great. Go ahead and put your hands down.
So, what's wrong with either of these methodologies? Cumbersome? Inefficient? In some cases, ineffective? Ever wonder what you're missing? How about...A LOT?
The fact of the matter is, I really believe that Registry analysis isn't being performed today nearly as much as it should because it isn't "easy". I mean, sure, you've got this file that contains all this data, all this potential "evidence" (depending upon the audience, of course), but you don't know (a) how to get it, and maybe even (b) how to interpret it. After all, Registry viewers don't give you what you need, do they? They just present the data as is...it's up to you, the investigator or analyst to make heads or tails of it.
What if you just want to get the most recent document accessed...not just by the user, but via various applications, such as RealPlayer, maybe an image viewer, Excel, Adobe Reader, or even just by one of the common dialogs? If you're just looking for documents accessed, there are a LOT of places to look in the Registry...and using a checklist can take a long time. Also, due to encoding used by various vendors, regular ASCII/Unicode string searches won't work. So what if your "checklist" could be run against the Registry hive file itself?
What about those times when you have to correlate between multiple Registry keys, such as when you're trying to find out about those installed BHOs, or trying to determine when a USB thumb drive was last plugged into the system? How cumbersome is that?
How would you
like to rip through your Registry analysis, getting just what you need, presented in the way you need it, or at least a way that's usable? Forget spreadsheets and checklists...how about plugins (stuff like Nessus and Metasploit use plugins, right?) that reach out and get what you want? How about...in order to update this tool, plugins just need to be dropped into a directory, and they're ready to use? How about it this all came with a GUI and a nice "FindAllEvidence" button?
What if you could also get timestamped data (ie, most recently accessed documents, UserAssist entries, etc.) so that you could import it into a format such as Excel, or even XML (for use with Simile TimeLine)?
Know what's really cool about the timestamped data? In order for it to be placed in the user's Registry hive file (NTUSER.DAT), the user account needs to be logged into the system. Sounds pretty simple, doesn't it? Hit most public lists, though, and you'll see questions such as, "how do I tell when a user was logged on if auditing of logon events isn't recorded in the Security Event Log?" (I'm paraphrasing, of course). Well, in most cases, when someone logs on, they do something...right? Look at all of the user activity that is recorded (I say 'recorded" because in many ways, the Registry is a log file, of sorts) in the user's hive file...and then correlate that to other activity (Internet browser history, etc.) that may be available.
Sound pretty cool? How about flippin' sweet?!?
The fact is, there's "lookin' at" the Registry, and then there's doing real Registry analysis and getting the data you need.
Addendum
Some might be wondering, "What is it about Registry analysis that's so hot? After all, I get all of the information/evidence I need from the file system." Well, I can only speak to those things that I've determined through Registry analysis...logon history, files accessed, files NOT accessed, applications that had been installed, run, and then uninstalled, etc. There is a great deal of information...much of it historical, much of it associated in some way with a time stamp...right there in the Registry.
Addendum, 1 Apr
Okay, this isn't a joke...but I added three plugins to the RegRipper last night. One for the Uninstall key in the Software hive (all entries sorted based on the key LastWrite times), as well as one for the USBStor key, and another for the DeviceClasses keys...both in the System hive.
Adding a plugin for the Protected Storage System Provider is going to be problematic until I get some info how to decrypt the data in the "Item Data" values.
Okay...raise your hand if, for you, Registry analysis consists of looking for strings (using strings, or BinText, or your favorite tool), or maybe using grep() to do regex searches for IP addresses, email addresses, or something else.
Great, thanks. You can put your hands down.
Now, raise your hand if when performing Registry analysis, you open the hive files you're interested in with one of the popular Registry viewers (EnCase, FTK, ProDiscover, or even good ol' RegEdit), and "look around for anything interesting". Keep it up there if you use some sort of checklist or spreadsheet of Registry keys that may be of interest for your case or exam.
Okay...great. Go ahead and put your hands down.
So, what's wrong with either of these methodologies? Cumbersome? Inefficient? In some cases, ineffective? Ever wonder what you're missing? How about...A LOT?
The fact of the matter is, I really believe that Registry analysis isn't being performed today nearly as much as it should because it isn't "easy". I mean, sure, you've got this file that contains all this data, all this potential "evidence" (depending upon the audience, of course), but you don't know (a) how to get it, and maybe even (b) how to interpret it. After all, Registry viewers don't give you what you need, do they? They just present the data as is...it's up to you, the investigator or analyst to make heads or tails of it.
What if you just want to get the most recent document accessed...not just by the user, but via various applications, such as RealPlayer, maybe an image viewer, Excel, Adobe Reader, or even just by one of the common dialogs? If you're just looking for documents accessed, there are a LOT of places to look in the Registry...and using a checklist can take a long time. Also, due to encoding used by various vendors, regular ASCII/Unicode string searches won't work. So what if your "checklist" could be run against the Registry hive file itself?
What about those times when you have to correlate between multiple Registry keys, such as when you're trying to find out about those installed BHOs, or trying to determine when a USB thumb drive was last plugged into the system? How cumbersome is that?
How would you
like to rip through your Registry analysis, getting just what you need, presented in the way you need it, or at least a way that's usable? Forget spreadsheets and checklists...how about plugins (stuff like Nessus and Metasploit use plugins, right?) that reach out and get what you want? How about...in order to update this tool, plugins just need to be dropped into a directory, and they're ready to use? How about it this all came with a GUI and a nice "FindAllEvidence" button?What if you could also get timestamped data (ie, most recently accessed documents, UserAssist entries, etc.) so that you could import it into a format such as Excel, or even XML (for use with Simile TimeLine)?
Know what's really cool about the timestamped data? In order for it to be placed in the user's Registry hive file (NTUSER.DAT), the user account needs to be logged into the system. Sounds pretty simple, doesn't it? Hit most public lists, though, and you'll see questions such as, "how do I tell when a user was logged on if auditing of logon events isn't recorded in the Security Event Log?" (I'm paraphrasing, of course). Well, in most cases, when someone logs on, they do something...right? Look at all of the user activity that is recorded (I say 'recorded" because in many ways, the Registry is a log file, of sorts) in the user's hive file...and then correlate that to other activity (Internet browser history, etc.) that may be available.
Sound pretty cool? How about flippin' sweet?!?
The fact is, there's "lookin' at" the Registry, and then there's doing real Registry analysis and getting the data you need.
Addendum
Some might be wondering, "What is it about Registry analysis that's so hot? After all, I get all of the information/evidence I need from the file system." Well, I can only speak to those things that I've determined through Registry analysis...logon history, files accessed, files NOT accessed, applications that had been installed, run, and then uninstalled, etc. There is a great deal of information...much of it historical, much of it associated in some way with a time stamp...right there in the Registry.
Addendum, 1 Apr
Okay, this isn't a joke...but I added three plugins to the RegRipper last night. One for the Uninstall key in the Software hive (all entries sorted based on the key LastWrite times), as well as one for the USBStor key, and another for the DeviceClasses keys...both in the System hive.
Adding a plugin for the Protected Storage System Provider is going to be problematic until I get some info how to decrypt the data in the "Item Data" values.
Thursday, March 13, 2008
New WFA Review Posted
Rob Lee posted a review of Windows Forensic Analysis today...check it out!
I have to tell you, it's a good one! Rob really hits home with some very important points about the book, particularly regarding flow. That's something I'll have to work on for 2/e. That's right...a second edition. I plan to make it more than an update, more than just adding new stuff. One of the problems I see with the current edition is like Rob said...flow. How does one sit down and find something more than just information about a tool or file? Sure, books have indexes (hint, hint) and that's a great place to start, but talking about how Prefetch files or a particular Registry key is useful will only get you so far. What I need to do is figure out a way to tie this all together into something that describes how to use this stuff in an actual...you know...examination. After all, that's the point, isn't it?
I do have some thoughts and ideas on where to go, but to be honest, I'd really like to hear from folks regarding what might work.
I have to tell you, it's a good one! Rob really hits home with some very important points about the book, particularly regarding flow. That's something I'll have to work on for 2/e. That's right...a second edition. I plan to make it more than an update, more than just adding new stuff. One of the problems I see with the current edition is like Rob said...flow. How does one sit down and find something more than just information about a tool or file? Sure, books have indexes (hint, hint) and that's a great place to start, but talking about how Prefetch files or a particular Registry key is useful will only get you so far. What I need to do is figure out a way to tie this all together into something that describes how to use this stuff in an actual...you know...examination. After all, that's the point, isn't it?
I do have some thoughts and ideas on where to go, but to be honest, I'd really like to hear from folks regarding what might work.
Wednesday, March 05, 2008
Event Log Analysis
In keeping with the Getting Started posts, I wanted to include something that may be of interest with regards to finding corroborating artifacts when performing computer forensic analysis.
Many times, when performing CF analysis, we end up trying to find out when a particular user may have logged into a system, or into a Windows domain. There may be other artifacts, as well, that may lead us to the Windows Event Log (right now, I'm just talking about the Windows 2000, XP, and 2003 Event Logs). There are a number of different ways to go about this, using the commercial tools such as EnCase and ProDiscover, but sometimes the analyst may want to extract the .evt files from the acquired image and parse them. In such instances, the Windows API (used by the Event Viewer and a number of other tools) may report that the .evt file is "corrupted".
This has happened enough to others that I don't even bother any longer, and instead resort to tools such as EvtUI, a GUI-enabled Perl script based on the Evt2Xls Perl script that I wrote to parse .evt files on a binary basis, by-passing the MS API and producing something a bit more usable. EvtUI runs aga
inst an .evt file and parses out all of the event records into an Excel binary-compatible spreadsheet. The Time_Generated field of the event record structure is formated so that it can be used to sort on in the spreadsheet. EvtUI also produces a report file, which gives the analyst an overview of the .evt records based on the frequency of the various sources and event IDs. I found this particular functionality useful enough that I pulled it out into its own tool (I call it "evtrpt") and added a frequency count for event types (Info, Warning, Error, Success, and Failure). The report file also gives you the date ranges of all of the event records.
Another thing that EvtUI lets the analyst do is enter exceptions. I've seen instances with really large .evt files (when combined with an extremely verbose audit configuration) where .evt file will have more than 65,535 records...and this is the limit of entries for Excel. So, the analyst can run EvtUI once, and then check the report...if there are more than 65,535 records, she can choose event IDs to enter as exceptions and then re-run EvtUI.
Now, once you've gotten this far, the question then becomes, how do you analyze the data you've got? Well, what you look for depends not only on your case, but what's being audited (which you can see very easily by parsing the PolAdtEv value from the Security Registry hive file. This is only a start, though...I suggest that anyone who does or wants to do Event Log analysis check out the following sites:
EventID.net (indispensable and well worth the $24/yr subscription)
Eric Fitzgeralds' blog
Rob "Van" Hensing's Blog
Windows 2000 Security Event Descriptions (pt 1, 2)
Tips
There was an intrusion investigation where the intruder was suspected of having created an account (done in many cases in order to maintain persistence) within the domain. Auditing for logon events was not enabled, but auditing for account management events was...and I was able to quickly find an event ID 624 record showing the creation of the suspicious
Other Resources
EventLogRecord structure
Windows Event Log Reference (Vista, 2008)
GrokEVT (Python-based)
ScreenClean
Many times, when performing CF analysis, we end up trying to find out when a particular user may have logged into a system, or into a Windows domain. There may be other artifacts, as well, that may lead us to the Windows Event Log (right now, I'm just talking about the Windows 2000, XP, and 2003 Event Logs). There are a number of different ways to go about this, using the commercial tools such as EnCase and ProDiscover, but sometimes the analyst may want to extract the .evt files from the acquired image and parse them. In such instances, the Windows API (used by the Event Viewer and a number of other tools) may report that the .evt file is "corrupted".
This has happened enough to others that I don't even bother any longer, and instead resort to tools such as EvtUI, a GUI-enabled Perl script based on the Evt2Xls Perl script that I wrote to parse .evt files on a binary basis, by-passing the MS API and producing something a bit more usable. EvtUI runs aga
inst an .evt file and parses out all of the event records into an Excel binary-compatible spreadsheet. The Time_Generated field of the event record structure is formated so that it can be used to sort on in the spreadsheet. EvtUI also produces a report file, which gives the analyst an overview of the .evt records based on the frequency of the various sources and event IDs. I found this particular functionality useful enough that I pulled it out into its own tool (I call it "evtrpt") and added a frequency count for event types (Info, Warning, Error, Success, and Failure). The report file also gives you the date ranges of all of the event records.Another thing that EvtUI lets the analyst do is enter exceptions. I've seen instances with really large .evt files (when combined with an extremely verbose audit configuration) where .evt file will have more than 65,535 records...and this is the limit of entries for Excel. So, the analyst can run EvtUI once, and then check the report...if there are more than 65,535 records, she can choose event IDs to enter as exceptions and then re-run EvtUI.
Now, once you've gotten this far, the question then becomes, how do you analyze the data you've got? Well, what you look for depends not only on your case, but what's being audited (which you can see very easily by parsing the PolAdtEv value from the Security Registry hive file. This is only a start, though...I suggest that anyone who does or wants to do Event Log analysis check out the following sites:
EventID.net (indispensable and well worth the $24/yr subscription)
Eric Fitzgeralds' blog
Rob "Van" Hensing's Blog
Windows 2000 Security Event Descriptions (pt 1, 2)
Tips
There was an intrusion investigation where the intruder was suspected of having created an account (done in many cases in order to maintain persistence) within the domain. Auditing for logon events was not enabled, but auditing for account management events was...and I was able to quickly find an event ID 624 record showing the creation of the suspicious
Other Resources
EventLogRecord structure
Windows Event Log Reference (Vista, 2008)
GrokEVT (Python-based)
ScreenClean
Monday, February 25, 2008
Getting Started, pt II
Okay, in the face of recent (and completely bullsh*t) claims by Sen. Clinton that Sen. Obama plagiarized speeches (so the guy used some phrases...so what?), I thought that it would be best that I was up-front and came clean...I did not have se...oh, geez...wait a sec...
I was on the e-Evidence site this morning and saw a paper listed from Kennesaw State University, entitled, "Digital Forensics on the Cheap: Teaching Forensics Using Open Source Tools", from Richard Austin. This paper goes right along with what I was referring to in my earlier post, but also takes it a step further with regards to using specific tools, in this case, Helix and Autopsy. This is a great read and definitely very useful.
So, you're probably wondering...what's the point? Well, lists of free and open-source tools, as well as to documents that describe their use can be used to provide a solid foundation in the fundamentals (and even in more advanced information and techniques) of computer forensic analysis. Some college (community college as well as university) courses may not have the budget for some of the more expensive tools, but can provide the time and impetus necessary for folks wanting to learn and develop skillz to do so.
The availability and access to images and tools for creating and obtaining images, as well as the access to tools for analysis also provide a foundation for training programs, as well, in order to develop more advanced skill sets. Not only that, but new areas of computer forensic analysis can be explored...for example, it's not entirely difficult to locate malware on a system, but one of the areas that isn't explored is how it got there in the first place. Training sessions, brown-bag or white-board discussions all lend themselves very well to advancing the knowledge base of any group of forensic analysts, and the availability of the tools and images put the basis for these training sessions within reach of anyone with a Windows system and some storage space.
One final thought to close out this post (but not this subject)...has anyone thought about using these resources as part of an interview process? I can easily see three immediate ways of doing so...
I was on the e-Evidence site this morning and saw a paper listed from Kennesaw State University, entitled, "Digital Forensics on the Cheap: Teaching Forensics Using Open Source Tools", from Richard Austin. This paper goes right along with what I was referring to in my earlier post, but also takes it a step further with regards to using specific tools, in this case, Helix and Autopsy. This is a great read and definitely very useful.
So, you're probably wondering...what's the point? Well, lists of free and open-source tools, as well as to documents that describe their use can be used to provide a solid foundation in the fundamentals (and even in more advanced information and techniques) of computer forensic analysis. Some college (community college as well as university) courses may not have the budget for some of the more expensive tools, but can provide the time and impetus necessary for folks wanting to learn and develop skillz to do so.
The availability and access to images and tools for creating and obtaining images, as well as the access to tools for analysis also provide a foundation for training programs, as well, in order to develop more advanced skill sets. Not only that, but new areas of computer forensic analysis can be explored...for example, it's not entirely difficult to locate malware on a system, but one of the areas that isn't explored is how it got there in the first place. Training sessions, brown-bag or white-board discussions all lend themselves very well to advancing the knowledge base of any group of forensic analysts, and the availability of the tools and images put the basis for these training sessions within reach of anyone with a Windows system and some storage space.
One final thought to close out this post (but not this subject)...has anyone thought about using these resources as part of an interview process? I can easily see three immediate ways of doing so...
- 1. Query the interviewee with regards to familiarity with the tools and/or techniques themselves; if familiarity is mentioned or discovered during the interview process, ask probing questions about the use of the tools (Note: this requires the interviewer to be prepared).
- 2. Prior to the actual interview, have a candidate perform an exercise...point them to a specific image, and give them instructions on what tools to use (or not to use). Part of the interview can then be a review of their process/methodology.
- 3. If an interview is conducted on-site, with the candidate coming into the facility (rather than a remote interview), have the candidate sit down at a workstation and solve some problem.
When First Responders Attack!!
It still happens...an "event" or "incident" occurs within an organization, and the initial response from the folks on-site (most often, the organization's IT staff) obliterates some or all of the "evidence" of the event. Consultants are called to determine "how they got in", "how far they got" into the infrastructure, and "what data was taken", and as such, are unable to completely answer those questions (if at all) due to what happened in the first hours (or in some cases, days) after the incident was discovered.
Check out Ignorance wrecking evidence, from AdelaideNow in Australia. It's an excellent read from the perspective of law enforcement, but a good deal of what's said applies across the board.
One of the things that consultants see very often is a disparity between what first responders say they did during an initial interview, and what the analyst sees during an examination. Very often, the consultant is told that the first responders took the system offline, but didn't do anything else. However, analysis of the image shows that installing and running anti-virus and -spyware tools, deleting files, and even restoring files from backup all happened. A great deal of this can be seen once the approximate timeline of the incident is determined...and very often, you'll see an administrator login, install or delete/remove stuff, etc., and then say that they didn't do anything.
Why would this matter? Let's take a look...
Many analysts still rely on traditional examination techniques, focusing on file MAC times, etc. So an admin logs into a system and runs an AV or anti-spyware scan (or both...or just 'pokes around'...something that happens a LOT more than I care to think about...), so now all of the file access times on the system have been modified, and perhaps some files have been deleted. Anyone remember this article on anti-forensics that appeared in CIO Magazine? Why worry about that stuff, when there is more activity of this nature occurring due to either the operating system itself, or due to regular, day-to-day IT network ops?
So what's the solution? Education and training, starting with senior management. They have to make it important. After all, they're the ones that tell IT that systems have to stay up, right? If senior management were really aware of how many times (and how easily) their organization got punked or p0wned by some 15 yr old kid, then maybe they'd put some serious thought and effort into protecting their organization, their IT assets, and more importantly, the (re: YOUR) data that they store and process.
Check out Ignorance wrecking evidence, from AdelaideNow in Australia. It's an excellent read from the perspective of law enforcement, but a good deal of what's said applies across the board.
One of the things that consultants see very often is a disparity between what first responders say they did during an initial interview, and what the analyst sees during an examination. Very often, the consultant is told that the first responders took the system offline, but didn't do anything else. However, analysis of the image shows that installing and running anti-virus and -spyware tools, deleting files, and even restoring files from backup all happened. A great deal of this can be seen once the approximate timeline of the incident is determined...and very often, you'll see an administrator login, install or delete/remove stuff, etc., and then say that they didn't do anything.
Why would this matter? Let's take a look...
Many analysts still rely on traditional examination techniques, focusing on file MAC times, etc. So an admin logs into a system and runs an AV or anti-spyware scan (or both...or just 'pokes around'...something that happens a LOT more than I care to think about...), so now all of the file access times on the system have been modified, and perhaps some files have been deleted. Anyone remember this article on anti-forensics that appeared in CIO Magazine? Why worry about that stuff, when there is more activity of this nature occurring due to either the operating system itself, or due to regular, day-to-day IT network ops?
So what's the solution? Education and training, starting with senior management. They have to make it important. After all, they're the ones that tell IT that systems have to stay up, right? If senior management were really aware of how many times (and how easily) their organization got punked or p0wned by some 15 yr old kid, then maybe they'd put some serious thought and effort into protecting their organization, their IT assets, and more importantly, the (re: YOUR) data that they store and process.
Thursday, February 21, 2008
Important Memory Update
I ran across this info today, and thought that I'd post it...it seems quite important, in that it pertains to the use of physical memory (RAM) to deal with whole disk encryption (WDE), referred to as "cold boot attacks on disk encryption".
This looks like very cool stuff. Give it a read, and let me know what you think.
Don't forget that TechPathways provides a tool called ZeroView, which can reportedly be used to detect WDE.
This looks like very cool stuff. Give it a read, and let me know what you think.
Don't forget that TechPathways provides a tool called ZeroView, which can reportedly be used to detect WDE.
Wednesday, February 20, 2008
Getting started, or forensic analysis on the cheap
Quite often, I'll see posts or receive emails from folks asking about how to get started in the computer forensic analysis field. What most folks don't realize is that "getting into" this field really isn't so much about the classes you took at a college or the fact that you have a copy of EnCase. What it's about is how well you know your stuff, what you're capable of doing, and if you're capable of learning new stuff.
For example, who would you want to hire or work with...someone who only knows how to use one tool (for example, EnCase), or someone who can explain how EnCase does what it does (such as file signature analysis) and can come up with solutions for the problems and challenges that we all run into?
What I've decided to do is compile a list of free (as in "beer") resources that can be used by schools and individuals to develop labs, training exercises, etc., for the purposes of providing an educational background in the field of computer forensic analysis. With nothing more than a laptop and an Internet connection, anyone interested in computer forensics analysis can learn quite a lot without ever spending any $.
Imaging
FTK Imager 2.5.3 (and Lite 2.5.1)
George M. Garner, Jr's FAU
dcfldd - Wiki
dc3dd
Image/File Integrity Verification
MD5Deep
Images/Analysis Challenges
Lance's Forensic Practicals (#1 and #2) (no EnCase? Use FTK Imager to convert the .E0x files to dd format)
NIST Hacking Case
DFTT Tool Testing Images
HoneyNet Project Challenges
VMWare Appliances (FTK Imager will allow you to add these - most of which are *nix-based - as evidence items and create dd-format images)
Analysis Applications
TSK 2.51 (as of 10 Feb 2008...includes Windows versions of the tools, but not the Autopsy Forensic Browser - see the Wiki for how to use the tools)
NOTE: DFLabs is developing PTK, an alternative Sleuthkit interface, and they are reportedly working on a full Windows version, as well!
ProDiscover 4.9 Basic Edition
PyFlag
Mounting/Booting Images
VDK & VDKWin
LiveView (ProDiscover Basic will allow you to create the necessary .vmdk file for a dd-format image)
VMPlayer
Analysis Tools
Perl ('nuff said!!) - my answer for everything, it seems ;-)
File Analysis
MiTec Registry File Viewer - import Registry hive files
TextPad
Rifiuti - INFO2 file parser
BinText - like strings, but better
Windows File Analyzer
File Carving
Scalpel
Browser History
WebHistorian
Archive Utilities
Universal Extractor
jZip
PeaZip
AV and Related Tools
McAfee Stinger - standalone tool to scan for specific malware
ThreatFire (requires live system, best when used w/ AV)
GMER Rootkit Detection (requires live system)
Packet Capture and Analysis
PacketMon
WireShark
Other Tools
According to Claus at the GSD blog , Mozilla uses SQLite databases to store information, so if you're doing browser analysis, you may want to take a look at SQLite DB Browser, or SQLiteSpy. If you want to create your own databases in SQLite, check out SQLite Administrator. So, you can use these tools not only for analysis of the Mozilla files, but also with creating your own databases for use with other tools (ie, Perl).
Please keep in mind that this is just a list...and not an exhaustive one...of technical resources that are available. There are many, many other tools available.
Also, all of the technical tools and techniques are for naught if you (a) cannot follow a process, and (b) cannot document what you do.
For example, who would you want to hire or work with...someone who only knows how to use one tool (for example, EnCase), or someone who can explain how EnCase does what it does (such as file signature analysis) and can come up with solutions for the problems and challenges that we all run into?
What I've decided to do is compile a list of free (as in "beer") resources that can be used by schools and individuals to develop labs, training exercises, etc., for the purposes of providing an educational background in the field of computer forensic analysis. With nothing more than a laptop and an Internet connection, anyone interested in computer forensics analysis can learn quite a lot without ever spending any $.
Imaging
FTK Imager 2.5.3 (and Lite 2.5.1)
George M. Garner, Jr's FAU
dcfldd - Wiki
dc3dd
Image/File Integrity Verification
MD5Deep
Images/Analysis Challenges
Lance's Forensic Practicals (#1 and #2) (no EnCase? Use FTK Imager to convert the .E0x files to dd format)
NIST Hacking Case
DFTT Tool Testing Images
HoneyNet Project Challenges
VMWare Appliances (FTK Imager will allow you to add these - most of which are *nix-based - as evidence items and create dd-format images)
Analysis Applications
TSK 2.51 (as of 10 Feb 2008...includes Windows versions of the tools, but not the Autopsy Forensic Browser - see the Wiki for how to use the tools)
NOTE: DFLabs is developing PTK, an alternative Sleuthkit interface, and they are reportedly working on a full Windows version, as well!
ProDiscover 4.9 Basic Edition
PyFlag
Mounting/Booting Images
VDK & VDKWin
LiveView (ProDiscover Basic will allow you to create the necessary .vmdk file for a dd-format image)
VMPlayer
Analysis Tools
Perl ('nuff said!!) - my answer for everything, it seems ;-)
File Analysis
MiTec Registry File Viewer - import Registry hive files
TextPad
Rifiuti - INFO2 file parser
BinText - like strings, but better
Windows File Analyzer
File Carving
Scalpel
Browser History
WebHistorian
Archive Utilities
Universal Extractor
jZip
PeaZip
AV and Related Tools
Miss Identify - identify Win32 PE files (different from an AV scan)
GriSoft AVG Free Edition anti-virus
Avira AntiVir PersonalEdition anti-virusGriSoft AVG Free Edition anti-virus
McAfee Stinger - standalone tool to scan for specific malware
ThreatFire (requires live system, best when used w/ AV)
GMER Rootkit Detection (requires live system)
Packet Capture and Analysis
PacketMon
WireShark
Other Tools
According to Claus at the GSD blog , Mozilla uses SQLite databases to store information, so if you're doing browser analysis, you may want to take a look at SQLite DB Browser, or SQLiteSpy. If you want to create your own databases in SQLite, check out SQLite Administrator. So, you can use these tools not only for analysis of the Mozilla files, but also with creating your own databases for use with other tools (ie, Perl).
Please keep in mind that this is just a list...and not an exhaustive one...of technical resources that are available. There are many, many other tools available.
Also, all of the technical tools and techniques are for naught if you (a) cannot follow a process, and (b) cannot document what you do.
Jesse rides again!
Jesse Kornblum has done it again! Jesse's one of those guys who releases some really amazing tools for use in the IR and forensic analysis space, and he's done it again with "Miss Identify".
Miss Identify is a tool to look for Win32 applications through the use of file signature analysis. By default, it looks for Win32 apps (per the PE header) that do not have executable file extensions. As with Jesse's other tools, Miss Identify is rich with features, all of which are configurable from the command line.
So, you're probably thinking...okay, so what? You can already do this sort of thing with other tools, right? What makes this tool so Super Bad, McLovin?? Well, right now, there are a number of ways that a forensic analyst can identify malware in an acquired image, including checking the logs of any AV app that is already installed, or mounting the image and running an AV scanner or hash set comparison tool. However, two issues arise with these approaches...one is that there are legitimate tools that can and are used for malicious purposes. The other is that signatures (AV signatures, hashes, etc.) don't always work. However, there is one thing that all malware must be, and that is executable!
Miss Identify can also print strings that are found in the files, as well. This is great because you may find an executable file in the system32 directory that has a Microsoft-sounding name, but does not contain the MS copyright info embedded in the resource strings. This would be a "clue".
The use of Miss Identify doesn't replace other analysis and data reduction techniques, but instead augments them. This is without a doubt a useful tool, and one that should be considered for use by all sysadmins, first responders, as well as forensic analysts.
A round of applause for Jesse, everyone!
Also, I love the "Hollywood teaser" Jesse used to let everyone know what was coming! Speaking of teasers, isn't IronMan coming out soon....? Can you think of a better way to get Marvel Comics and Black Sabbath to come together??? ;-)
Addendum: I reached out to Jesse and mentioned to him that it might be useful to parse out the file version information from an executable, rather than all of the strings. Also, reading through the comments to Jesse's blog, there are some very useful tips pointed out...for example, finding an executable file in a user's browser cache might be considered by some examiners to be a "clue"... ;-)
Miss Identify is a tool to look for Win32 applications through the use of file signature analysis. By default, it looks for Win32 apps (per the PE header) that do not have executable file extensions. As with Jesse's other tools, Miss Identify is rich with features, all of which are configurable from the command line.
So, you're probably thinking...okay, so what? You can already do this sort of thing with other tools, right? What makes this tool so Super Bad, McLovin?? Well, right now, there are a number of ways that a forensic analyst can identify malware in an acquired image, including checking the logs of any AV app that is already installed, or mounting the image and running an AV scanner or hash set comparison tool. However, two issues arise with these approaches...one is that there are legitimate tools that can and are used for malicious purposes. The other is that signatures (AV signatures, hashes, etc.) don't always work. However, there is one thing that all malware must be, and that is executable!
Miss Identify can also print strings that are found in the files, as well. This is great because you may find an executable file in the system32 directory that has a Microsoft-sounding name, but does not contain the MS copyright info embedded in the resource strings. This would be a "clue".
The use of Miss Identify doesn't replace other analysis and data reduction techniques, but instead augments them. This is without a doubt a useful tool, and one that should be considered for use by all sysadmins, first responders, as well as forensic analysts.
A round of applause for Jesse, everyone!
Also, I love the "Hollywood teaser" Jesse used to let everyone know what was coming! Speaking of teasers, isn't IronMan coming out soon....? Can you think of a better way to get Marvel Comics and Black Sabbath to come together??? ;-)
Addendum: I reached out to Jesse and mentioned to him that it might be useful to parse out the file version information from an executable, rather than all of the strings. Also, reading through the comments to Jesse's blog, there are some very useful tips pointed out...for example, finding an executable file in a user's browser cache might be considered by some examiners to be a "clue"... ;-)
Subscribe to:
Posts (Atom)