NTFS Alternate Data Streams (ADSs) have been around since the dawn of...well...NTFS. Windows OSs ship with plenty of tools to create (and execute) ADSs, but the cool thing is that until Vista came along, there were not tools provided with the Windows operating systems that allowed you to see arbitrary ADSs that had been added to your system.
Caveat: There are some tools that do allow you to see specific ADSs, but those are only in very specific instances. Even Windows systems themselves make use of some specific ADSs, as well.
And, yes, you heard me right...from NT up through Windows XP and 2003, someone could create arbitrary ADSs on your system, using tools on the system...but there are no tools that ship as part of the OS that allow you (as an admin) to find and/or view these ADSs. On Vista, you can use dir /R to view arbitrary ADSs.
An interesting kicker is that ADS can not only be attached to files, but directory listings, as well, using the same command line syntax, with a slight alteration...
D:\>type c:\windows\system32\calc.exe > d:\ads\:calc.exe
Running tools such as LADS (from Frank Heyne, see below) we see that the ADS is indeed attached to the directory listing. We can launch this executable using the same syntax as was used to create it:
D:\>start d:\ads:calc.exe
Pretty sweet, huh? This is how tlist.exe sees it:
2640 ads:calc.exe Calculator Command Line: "d:\ads:calc.exe"
You see pretty much the same thing in Task Manager, as well.
This topic is covered in both of my books...Windows Forensics and Incident Recovery and Windows Forensic Analysis. From these resources, you can see that ADSs can be used to "hide" files and data, but also be used as a repository for executables, as well as scripts.
Resources
My original paper, The Dark Side of NTFS
Frank Heyne's LADS
SoftCorp scSTREAMS
Rootkit that uses ADSs
WindowsIR on ADSs
Wednesday, June 11, 2008
Portable Devices on Vista
Rob Lee shared an interesting tidbit of Vista Registry goodness with me recently...basically, the Vista Registry maintains some historical data on the drive letters that had been assigned to portable devices. Sweet!
The key in question is:
HKLM\Software\Microsoft\Windows Portable Devices\Devices
The subkeys beneath this key contain the device names...and the FriendlyName value contains the drive letter.
Rob discovered this as a part of the Computer Forensics SANS course as part of the section on Application Forensics where he and the class were examining U3 device footprints on a VISTA machine. (rlee@sans.org for contact info)
Very cool, Rob, and thanks for sharing!
And yes, I've already written a plugin for RegRipper...I KNEW you were going to ask that! =)
The output looks like:
Device : DISK&VEN_APPLE&PROD_IPOD&REV_1.62
LastWrite : Fri Sep 21 01:42:42 2007 (UTC)
SN : 000A270018A0E610&0
Drive : IPOD (F:)
Device : DISK&VEN_BEST_BUY&PROD_GEEK_SQUAD_U3&REV_6.15
LastWrite : Thu Feb 7 13:26:19 2008 (UTC)
SN : 0C90195032E36889&0
Drive : GEEKSQUAD (F:)
Device : DISK&VEN_CASIO&PROD_DIGITAL_CAMERA&REV_1.00
LastWrite : Sat Dec 15 01:17:56 2007 (UTC)
SN : 6&14BB4B7C&0
Drive : Removable Disk (F:)
The key in question is:
HKLM\Software\Microsoft\Windows Portable Devices\Devices
The subkeys beneath this key contain the device names...and the FriendlyName value contains the drive letter.
Rob discovered this as a part of the Computer Forensics SANS course as part of the section on Application Forensics where he and the class were examining U3 device footprints on a VISTA machine. (rlee@sans.org for contact info)
Very cool, Rob, and thanks for sharing!
And yes, I've already written a plugin for RegRipper...I KNEW you were going to ask that! =)
The output looks like:
Device : DISK&VEN_APPLE&PROD_IPOD&REV_1.62
LastWrite : Fri Sep 21 01:42:42 2007 (UTC)
SN : 000A270018A0E610&0
Drive : IPOD (F:)
Device : DISK&VEN_BEST_BUY&PROD_GEEK_SQUAD_U3&REV_6.15
LastWrite : Thu Feb 7 13:26:19 2008 (UTC)
SN : 0C90195032E36889&0
Drive : GEEKSQUAD (F:)
Device : DISK&VEN_CASIO&PROD_DIGITAL_CAMERA&REV_1.00
LastWrite : Sat Dec 15 01:17:56 2007 (UTC)
SN : 6&14BB4B7C&0
Drive : Removable Disk (F:)
Tuesday, June 10, 2008
RegRipper Plugin Updates
Pretty much everyone is aware by now that the full version of RegRipper is available on SF.net. I made a couple of minor updates to some of the plugins the other day (so you won't find these in the currently available distribution) that I wanted to mention briefly...
First, I updated the winnt_cv plugin so that the InstallDate value is converted to a readable time stamp, such as:
InstallDate : Fri Aug 31 15:21:10 2007 (UTC)
Much better than just spewing the DWORD data to the output, don't'cha think?
Second, after using RegRipper on some actual engagements recently, I decided that I wanted a plugin that would display information about the services in a shorter format so that its easier to read. The services plugin displays the following about services and drivers:
Name = SNMPTRAP
Display = @%SystemRoot%\system32\snmptrap.exe,-3
ImagePath = %SystemRoot%\System32\snmptrap.exe
Type = Own_Process
Start = Manual
Group =
The svc plugin (get it...shorter name, shorter format for the output??) displays the following about services:
Thu Nov 2 12:53:48 2006Z
Appinfo (%SystemRoot%\system32\svchost.exe -k netsvcs) [LocalSystem]
Thu Nov 2 12:53:38 2006Z
SessionEnv (%SystemRoot%\System32\svchost.exe -k netsvcs) [localSystem]
Thu Nov 2 12:53:22 2006Z
TrkWks (%SystemRoot%\System32\svchost.exe -k LocalSystem NetworkRestricted) [LocalSystem]
Thu Nov 2 12:53:11 2006Z
Dhcp (%SystemRoot%\system32\svchost.exe -k LocalServiceNetworkRestricted) [NT Authority\LocalService]
The svc plugin grabs much of the same information as the services plugin, but presents it in a shorter format, so that it's much easier to read at a glance. In addition, svc also grabs the ObjectName value (if available), which indicates the account that the service runs under.
For analysis purposes, I generally try to look for services and drivers that have a LastWrite time around the reported date of the incident, as this has indicated the use of keystroke loggers and kernel-mode rootkits.
What's also really sweet about this is that, as always, the plugins work great with rip.exe...check out the batch files that were included in the most recent distribution of RegRipper.
Two other items that are yet to be completed (currently in progress) with regards to RegRipper are:
1. Extraction of time-based data in a common format, for correlation with other sources of time-based data, and then display of that data using Timeline or some other visualization tool.
2. Development of a separate, standalone copy of rip.exe (to start, anyway) that will not only run a plugin or plugins file against a hive, but also against the appropriate hive files in XP System Restore Points (all automatically).
Thoughts? Just more RegRipper goodness...no hive files were harmed in the making of these tools or of this post...
First, I updated the winnt_cv plugin so that the InstallDate value is converted to a readable time stamp, such as:
InstallDate : Fri Aug 31 15:21:10 2007 (UTC)
Much better than just spewing the DWORD data to the output, don't'cha think?
Second, after using RegRipper on some actual engagements recently, I decided that I wanted a plugin that would display information about the services in a shorter format so that its easier to read. The services plugin displays the following about services and drivers:
Name = SNMPTRAP
Display = @%SystemRoot%\system32\snmptrap.exe,-3
ImagePath = %SystemRoot%\System32\snmptrap.exe
Type = Own_Process
Start = Manual
Group =
The svc plugin (get it...shorter name, shorter format for the output??) displays the following about services:
Thu Nov 2 12:53:48 2006Z
Appinfo (%SystemRoot%\system32\svchost.exe -k netsvcs) [LocalSystem]
Thu Nov 2 12:53:38 2006Z
SessionEnv (%SystemRoot%\System32\svchost.exe -k netsvcs) [localSystem]
Thu Nov 2 12:53:22 2006Z
TrkWks (%SystemRoot%\System32\svchost.exe -k LocalSystem NetworkRestricted) [LocalSystem]
Thu Nov 2 12:53:11 2006Z
Dhcp (%SystemRoot%\system32\svchost.exe -k LocalServiceNetworkRestricted) [NT Authority\LocalService]
The svc plugin grabs much of the same information as the services plugin, but presents it in a shorter format, so that it's much easier to read at a glance. In addition, svc also grabs the ObjectName value (if available), which indicates the account that the service runs under.
For analysis purposes, I generally try to look for services and drivers that have a LastWrite time around the reported date of the incident, as this has indicated the use of keystroke loggers and kernel-mode rootkits.
What's also really sweet about this is that, as always, the plugins work great with rip.exe...check out the batch files that were included in the most recent distribution of RegRipper.
Two other items that are yet to be completed (currently in progress) with regards to RegRipper are:
1. Extraction of time-based data in a common format, for correlation with other sources of time-based data, and then display of that data using Timeline or some other visualization tool.
2. Development of a separate, standalone copy of rip.exe (to start, anyway) that will not only run a plugin or plugins file against a hive, but also against the appropriate hive files in XP System Restore Points (all automatically).
Thoughts? Just more RegRipper goodness...no hive files were harmed in the making of these tools or of this post...
Thursday, June 05, 2008
Some UpComing Events
There are some interesting events coming up this summer (and beyond) that I wanted to point out to folks...
DFRWS is this summer (11-13 Aug), but the Open Memory Forensics Workshop (OMFW) will be held just prior (info here, update here). OMFW looks like a great opportunity...it's a half-day event, but looking at the list of speakers and panelists...wow! If you haven't already, grab books off of your bookshelf (I *know* most of you recognize author names...) and get your copies signed! OMFW is brought to you by the letters M and S, and these guys.
If anything, this really shows how the interest in analysis of physical memory is really picking up. More than anything, I'd have to say that the interest is really been driven by the guys over at Volatile Systems, along with a host of other names. There is a great deal of extremely valuable information available in physical memory (RAM), and these guys are leading the way in showing us what's there, and providing tools for getting at it and making it available, but more importantly, useful to analysts.
As a side note, if you look around the community/industry, there is a big piece that's missing right now...collection. That's right...there are open source and commercial tools (from Mandiant and HBGary...and HBGary is apparently partnering with GSI) that provide the ability to parse, comb through and analyze a physical memory dump, but very few that provide the ability to extract the contents of RAM from Windows 2003 SP1 and above (e.g., Vista, Win2K8) systems. I even received an email from a friend at MS yesterday asking me if I knew of any such tools. One would naturally assume that we'd eventually see such a tool from MS/SysInternals. One way to go about changing this...buy more F-Response!
Note: Paraben is having an Innovations Conference in Utah in Nov, 2008. They also let you vote for a company or product that you feel is most innovative for 2008...I voted for F-Response.
Okay, back on track...what was I talking about? Oh, yeah...
Looking at the program for DFRWS 2008...yet another impressive line-up. I'm hoping to go...working for a large corporate (think "glacial") entity (think Borg cube), these requests are always in limbo. However, I'm very interested in Timothy Morgan's talk, as well as a couple of others. It also looks as if some of the speakers from OMFW are going to be on deck for DFRWS, as well. Maybe a good opportunity to ply familiar faces and famous names with some of the locally brewed beverages.
Interestingly enough, the local RCFG conference (which overlaps with DFRWS this year) has been cancelled. That's too bad...this conference is held on the GMU campus and for the most part is a nice, smaller conference. However, with the right leadership, it has the potential to really be a premier conference...not just for local LE, but in general. In fact, an interesting thought would be that since some folks are going to be in the area anyway, talking about the same topic...
Also, in Jan 2009, there is the DoD CyberCrime Conference...Jesse mentioned the CfP here. It's too early to list the speakers, but I had an opportunity to visit the conference in 2007 and it was a good one...lots of attendees, lots of events, lots of really great speakers.
DFRWS is this summer (11-13 Aug), but the Open Memory Forensics Workshop (OMFW) will be held just prior (info here, update here). OMFW looks like a great opportunity...it's a half-day event, but looking at the list of speakers and panelists...wow! If you haven't already, grab books off of your bookshelf (I *know* most of you recognize author names...) and get your copies signed! OMFW is brought to you by the letters M and S, and these guys.
If anything, this really shows how the interest in analysis of physical memory is really picking up. More than anything, I'd have to say that the interest is really been driven by the guys over at Volatile Systems, along with a host of other names. There is a great deal of extremely valuable information available in physical memory (RAM), and these guys are leading the way in showing us what's there, and providing tools for getting at it and making it available, but more importantly, useful to analysts.
As a side note, if you look around the community/industry, there is a big piece that's missing right now...collection. That's right...there are open source and commercial tools (from Mandiant and HBGary...and HBGary is apparently partnering with GSI) that provide the ability to parse, comb through and analyze a physical memory dump, but very few that provide the ability to extract the contents of RAM from Windows 2003 SP1 and above (e.g., Vista, Win2K8) systems. I even received an email from a friend at MS yesterday asking me if I knew of any such tools. One would naturally assume that we'd eventually see such a tool from MS/SysInternals. One way to go about changing this...buy more F-Response!
Note: Paraben is having an Innovations Conference in Utah in Nov, 2008. They also let you vote for a company or product that you feel is most innovative for 2008...I voted for F-Response.
Okay, back on track...what was I talking about? Oh, yeah...
Looking at the program for DFRWS 2008...yet another impressive line-up. I'm hoping to go...working for a large corporate (think "glacial") entity (think Borg cube), these requests are always in limbo. However, I'm very interested in Timothy Morgan's talk, as well as a couple of others. It also looks as if some of the speakers from OMFW are going to be on deck for DFRWS, as well. Maybe a good opportunity to ply familiar faces and famous names with some of the locally brewed beverages.
Interestingly enough, the local RCFG conference (which overlaps with DFRWS this year) has been cancelled. That's too bad...this conference is held on the GMU campus and for the most part is a nice, smaller conference. However, with the right leadership, it has the potential to really be a premier conference...not just for local LE, but in general. In fact, an interesting thought would be that since some folks are going to be in the area anyway, talking about the same topic...
Also, in Jan 2009, there is the DoD CyberCrime Conference...Jesse mentioned the CfP here. It's too early to list the speakers, but I had an opportunity to visit the conference in 2007 and it was a good one...lots of attendees, lots of events, lots of really great speakers.
Monday, June 02, 2008
Job Openings
Okay, I'm going to take a slight divergence from the normal content of this blog to reach out to all of you, my loyal readers...according to Google Analytics, both of you. =D
Anyway, as you may or may not know, by day I am an incident analyst for the IBM ISS Emergency Response Services (ERS) team...and we're looking to expand. By that I mean add qualified members to our team. And not just here in the US, but also in Australia, AsiaPac, Japan, and EMEA.
So you're probably wondering what we do...good question. In short, we respond to incidents on an emergency basis. The basic idea is that we get a call, from a current (or soon-to-be) customer and we triage the incident and deploy the necessary assets. Each team member has a jump kit of equipment, both hardware and software (plus our tools of our own choosing), and we arrive on-site to assist the customer in resolving the incident, through incident management, data collection and analysis, and pretty much whatever else we need to do. In many cases, we collect data and return to the lab to perform analysis.
We also do Visa PCI forensic audits, as well. In addition, we have subscription customers that we service, as well, with on-site visits, training, CSIRP development, mock incidents, etc.
Of course, there's all the other stuff that goes along with this kind of work...report writing, keeping track of expenses and billable hours. I guess a lot of that is to be expected, but I thought I'd mention it anyway.
So what we're looking for is someone with experience in incident response (beyond just running an AV scanner, or just wiping the drive...), volatile data collection and analysis, forensic acquisition and analysis, documentation and justification of activities, reporting, and customer interface. All of these things are important in what we do.
If you think that this is something you'd be interested in, please feel free to send me a copy of your resume here or here.
Finally, this is NOT a sub-contractor opportunity...this is a full-time employment position.
Anyway, as you may or may not know, by day I am an incident analyst for the IBM ISS Emergency Response Services (ERS) team...and we're looking to expand. By that I mean add qualified members to our team. And not just here in the US, but also in Australia, AsiaPac, Japan, and EMEA.
So you're probably wondering what we do...good question. In short, we respond to incidents on an emergency basis. The basic idea is that we get a call, from a current (or soon-to-be) customer and we triage the incident and deploy the necessary assets. Each team member has a jump kit of equipment, both hardware and software (plus our tools of our own choosing), and we arrive on-site to assist the customer in resolving the incident, through incident management, data collection and analysis, and pretty much whatever else we need to do. In many cases, we collect data and return to the lab to perform analysis.
We also do Visa PCI forensic audits, as well. In addition, we have subscription customers that we service, as well, with on-site visits, training, CSIRP development, mock incidents, etc.
Of course, there's all the other stuff that goes along with this kind of work...report writing, keeping track of expenses and billable hours. I guess a lot of that is to be expected, but I thought I'd mention it anyway.
So what we're looking for is someone with experience in incident response (beyond just running an AV scanner, or just wiping the drive...), volatile data collection and analysis, forensic acquisition and analysis, documentation and justification of activities, reporting, and customer interface. All of these things are important in what we do.
If you think that this is something you'd be interested in, please feel free to send me a copy of your resume here or here.
Finally, this is NOT a sub-contractor opportunity...this is a full-time employment position.
Saturday, May 31, 2008
Innovation
I was reading a list entry recently, looking at some of the functionality that was being added to a popular forensic analysis application, and I got to thinking...what areas of what we do (incident response and computer forensic analysis) are in need of innovation? What could we do better, through process or whatever, to do what we do better...more efficiently, more accurately, more completely?
What about adding functionality to forensic analysis applications? In the instance I was looking at, the request that had been granted was to add parsing of ASCII-based logs to the application. Is this really necessary? Is this something that needs to be added to applications that are still unstable, crash without notice or without any sort of debugging information, and currently contain far too much "functionality" so as to require a certification just to use the application (forget doing actual forensic analysis).
I'm not picking on any one application either. There's another one that I like a lot, and updates have been delayed while functionality is being added to it...functionality that is available in other tools.
What I'd like to see is a core, stable application capable of opening image files, and allowing the analyst to quickly and accurately perform keyword and grep() searches, for file content, file names, etc. From that point on, major functionality (such as parsing PST files) could be easily added as plugins, allowing the core application to remain stable.
I'm also a firm believer that too much functionality in a forensic analysis application moves that analyst further and further away from understanding the data itself. As analysts are removed from the data, their understanding of what's expected and what's unusual or suspicious lessens. One person can't be expected to know everything, but that's why we have a "community", right? Having analysts that understand how various pieces of data interact to build a more complete picture is extremely important, particularly as the sophistication of cybercrime continues to rise.
What are some areas that you feel need a little innovation? How about just shook up enough to flake off the shell of "...but that's how we've always done it"?
What about adding functionality to forensic analysis applications? In the instance I was looking at, the request that had been granted was to add parsing of ASCII-based logs to the application. Is this really necessary? Is this something that needs to be added to applications that are still unstable, crash without notice or without any sort of debugging information, and currently contain far too much "functionality" so as to require a certification just to use the application (forget doing actual forensic analysis).
I'm not picking on any one application either. There's another one that I like a lot, and updates have been delayed while functionality is being added to it...functionality that is available in other tools.
What I'd like to see is a core, stable application capable of opening image files, and allowing the analyst to quickly and accurately perform keyword and grep() searches, for file content, file names, etc. From that point on, major functionality (such as parsing PST files) could be easily added as plugins, allowing the core application to remain stable.
I'm also a firm believer that too much functionality in a forensic analysis application moves that analyst further and further away from understanding the data itself. As analysts are removed from the data, their understanding of what's expected and what's unusual or suspicious lessens. One person can't be expected to know everything, but that's why we have a "community", right? Having analysts that understand how various pieces of data interact to build a more complete picture is extremely important, particularly as the sophistication of cybercrime continues to rise.
What are some areas that you feel need a little innovation? How about just shook up enough to flake off the shell of "...but that's how we've always done it"?
Monday, May 26, 2008
RegRipper Update
I wanted to let folks know that I've posted the latest version of RegRipper to SF.net. The file you're looking for is "rr_2.02.zip".
There is no longer a break between the Basic and Advanced editions of RegRipper...I've done away with the Basic edition all together, and posted what used to be the Advanced version. The download package includes everything you need...the executables, source, RTFM docs (PDF, FAQ) and even a couple of simple batch files that show you how to use rip.exe to perform/automate some real simple tasks.
Development of RegRipper will continue. I still need to add more documentation to each plugin, along with Analysis Tips (explain why/how the data collected displayed may be important, etc.), as well as add the separate consolidation of timeline information (for use in analysis and graphing).
The power of RegRipper is in the plugins, and I can only go so far developing plugins myself. If you find that there's a plugin that you'd like to see, let me know. Please keep in mind...sample data is far more helpful than a description.
As always, if you have any thoughts, questions, comments, etc., please feel free to drop me a line.
There is no longer a break between the Basic and Advanced editions of RegRipper...I've done away with the Basic edition all together, and posted what used to be the Advanced version. The download package includes everything you need...the executables, source, RTFM docs (PDF, FAQ) and even a couple of simple batch files that show you how to use rip.exe to perform/automate some real simple tasks.Development of RegRipper will continue. I still need to add more documentation to each plugin, along with Analysis Tips (explain why/how the data collected displayed may be important, etc.), as well as add the separate consolidation of timeline information (for use in analysis and graphing).
The power of RegRipper is in the plugins, and I can only go so far developing plugins myself. If you find that there's a plugin that you'd like to see, let me know. Please keep in mind...sample data is far more helpful than a description.
As always, if you have any thoughts, questions, comments, etc., please feel free to drop me a line.
Sunday, May 25, 2008
More Free Tools
To continue adding to the list of free tools (earlier posts here and here), here are a couple of gems I found recently...
NetworkMiner - a free network forensic analysis tool that takes analysis of network traffic captures to another level. Very cool tool...I love how WireShark lets you reassemble streams, but NetworkMiner lets you do a bit more, and it's Windows-based. Don't have any packet captures available to try it with? Check out the HoneyNet Project's SotM #27.
Thanks goes to Claus for pointing these out...
Stinger and MVC...these are NOT full-bore AV applications, but rather free tools meant to target specific malware. Use these on a live system, or mount the acquired image as a live file system (as opposed to booting the image...) and scan the files.
OpenFilesView - Neat little tool to see which files are open on a system; GUI based but comes with command line options, making it a great tool for use in IR batch files. Say you've got a suspected intrusion and you need to know if sensitive data (pursuant to PCI, HIPAA, etc.) is being siphoned off of the system...well, grab process information w/ tools like tlist.exe and correlate that information to files opened on the system by process...
MUICacheView - The NirSoft site says, "Each time that you start using a new application, Windows operating system automatically extract the application name from the version resource of the exe file, and stores it for using it later, in Registry key known as the 'MuiCache'." This is one of those things I've looked into, and I'm not able to find what the OS would use this for...but hey, who am I to complain about it, right?
By the way, RegRipper has a plugin for this key, which means that you can parse the contents of this key by either extracting the hive from an image, or by firing up F-Response. ;-)
Addendum: Claus posted some of his own bloggy goodness about Evidence Collector, and from that post I learned about USBHistory, a nice little tool that extracts historical information about USB devices connected to a live system. The author even gives a shout out to ol' watashe-wa and his book! Very cool!
NetworkMiner - a free network forensic analysis tool that takes analysis of network traffic captures to another level. Very cool tool...I love how WireShark lets you reassemble streams, but NetworkMiner lets you do a bit more, and it's Windows-based. Don't have any packet captures available to try it with? Check out the HoneyNet Project's SotM #27.
Thanks goes to Claus for pointing these out...
Stinger and MVC...these are NOT full-bore AV applications, but rather free tools meant to target specific malware. Use these on a live system, or mount the acquired image as a live file system (as opposed to booting the image...) and scan the files.
OpenFilesView - Neat little tool to see which files are open on a system; GUI based but comes with command line options, making it a great tool for use in IR batch files. Say you've got a suspected intrusion and you need to know if sensitive data (pursuant to PCI, HIPAA, etc.) is being siphoned off of the system...well, grab process information w/ tools like tlist.exe and correlate that information to files opened on the system by process...
MUICacheView - The NirSoft site says, "Each time that you start using a new application, Windows operating system automatically extract the application name from the version resource of the exe file, and stores it for using it later, in Registry key known as the 'MuiCache'." This is one of those things I've looked into, and I'm not able to find what the OS would use this for...but hey, who am I to complain about it, right?
By the way, RegRipper has a plugin for this key, which means that you can parse the contents of this key by either extracting the hive from an image, or by firing up F-Response. ;-)
Addendum: Claus posted some of his own bloggy goodness about Evidence Collector, and from that post I learned about USBHistory, a nice little tool that extracts historical information about USB devices connected to a live system. The author even gives a shout out to ol' watashe-wa and his book! Very cool!
Wednesday, May 21, 2008
F-Response - Extend Your Arsenal
I recently played with F-Response Enterprise Edition, and I have to tell you, this stuff rocks! Excuse me...R0x0rz! Imagine as an incident responder if you could have read-only access to a remote disk...completely independent of your toolset? This means that once you get F-Response up and running, you have a disk on your system, which is the physical disk of the remote system...but it's read-only. Wanna grab files? Do it. Wanna image the drive? Do it.
Just so you know, you'll need to get the MS iSCSI Software Initiator as well.
So once I got ev
erything set up (Matt's documentation is pretty straight forward) and running, all I had to do was run the installed service on the remote system...in this case, a Windows XP VMWare session. Once that was done, I had a nice little indicator that the remote system was connected to. Very good. Then I looked and saw that I had an icon for an F:\ drive 
now attached to my system. I could browse it, copy files, do whatever...it was all read-only. No changes (file modifications, adding files, etc.) appeared on the remote system drive.
So then I thought I'd replicate what Hogfly had done using RegRipper...and it worked like a champ! I simply fired up RegRipper 2.02, pointed it at the NTUSER.DAT for the user account on my remote system, and ran it, saving the report and log files locally.
Awesome! RegRipper ran very well, over F-Response...as if it were running against a file that I'd extracted from an image, locally.
The cool thing is that F-Response EE can be easily pushed out as part of an incident preparedness program, or pushed out remotely using tools like psexec.exe. By design (and an excellent choice, I must say), the F-Response service does NOT start automatically...which means that as an administrator, you can have the service sitting there until you need it. As an incident responder, once you get it set up and running, all you need to do is launch the service.
Matt Shannon, the creator of F-Response, also has two other versions of F-Response...I was using the Enterprise Edition. Check out his site and see which version may be suitable for you.
Great job, Matt! Excellent tool! I really look forward to seeing not only what updates you may have available in the future, but also some of the novel and inventive ways folks come up with for using and employing such a simple and yet 0h-so-powerful tool!
Note: Updating a license for F-Response is a breeze! Download the update file, download the updater, plug in the FOB, run the updater, point it at the update file...and bang, in a couple of seconds you're stick-a-fork-in-me-I'm-DONE!
Addendum:
Rob Hensing blogs about...this post!
Lance "The Man" Mueller's blog post
Just so you know, you'll need to get the MS iSCSI Software Initiator as well.
So once I got ev
erything set up (Matt's documentation is pretty straight forward) and running, all I had to do was run the installed service on the remote system...in this case, a Windows XP VMWare session. Once that was done, I had a nice little indicator that the remote system was connected to. Very good. Then I looked and saw that I had an icon for an F:\ drive 
now attached to my system. I could browse it, copy files, do whatever...it was all read-only. No changes (file modifications, adding files, etc.) appeared on the remote system drive.So then I thought I'd replicate what Hogfly had done using RegRipper...and it worked like a champ! I simply fired up RegRipper 2.02, pointed it at the NTUSER.DAT for the user account on my remote system, and ran it, saving the report and log files locally.
Awesome! RegRipper ran very well, over F-Response...as if it were running against a file that I'd extracted from an image, locally.
The cool thing is that F-Response EE can be easily pushed out as part of an incident preparedness program, or pushed out remotely using tools like psexec.exe. By design (and an excellent choice, I must say), the F-Response service does NOT start automatically...which means that as an administrator, you can have the service sitting there until you need it. As an incident responder, once you get it set up and running, all you need to do is launch the service.
Matt Shannon, the creator of F-Response, also has two other versions of F-Response...I was using the Enterprise Edition. Check out his site and see which version may be suitable for you.
Great job, Matt! Excellent tool! I really look forward to seeing not only what updates you may have available in the future, but also some of the novel and inventive ways folks come up with for using and employing such a simple and yet 0h-so-powerful tool!
Note: Updating a license for F-Response is a breeze! Download the update file, download the updater, plug in the FOB, run the updater, point it at the update file...and bang, in a couple of seconds you're stick-a-fork-in-me-I'm-DONE!
Addendum:
Rob Hensing blogs about...this post!
Lance "The Man" Mueller's blog post
Thursday, April 24, 2008
RegRipper Video Posted
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!
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!
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.
Subscribe to:
Posts (Atom)