"Links" seemed like an overdone title...I couldn't of anything else witty, and I wanted to get right to the content anyway...so "stuff" will have to suffice for now.
First, more good news about F-Response! Matt's done a truly awesome job with this product...absolutely amazing. F-Response is a real-world example of what happens when someone who does the work decides that there's a better way to do it...and then goes out creates that better way to do the job.
I posted a PDF document to RegRipper.net, in the Downloads section, under Documents...this is trifold "cheat sheet" for RegRipper v2.02. It's pretty simple, and has some basic usage information, as well as some space for notes. I got the idea from a trifold that Rob Lee posted for SANS, and it seemed like an awesome idea. I mean, I know that I can't remember everything, and having a trifold available with the most frequently used commands or CLI options is very helpful. I'd greatly appreciate your thoughts on this...what you like, what you don't like, and anything that might be done to improve it.
I finished up an engagement recently, and one of the interesting things I found was that the Security Event Log was full, and only covered a couple of hours on the day that the system was acquired. One of the questions I was trying to answer included whether or not a shared Admin account was being used to log into the system locally or remotely. I found a single event record with ID 528, type 2, indicating login to the console. I also found a single event ID 683, indicating that an RDP session had been successfully disconnected. Both pertained to the same user account. Now, most folks are aware that Windows did not include the ability to log source IP addresses for network logons until Windows 2003...but on XP systems, the event ID 683 includes the remote system name and IP from which the user logged in. Cool! As a follow-on, what I had hoped to find (and didn't) was the event ID 528, type 10, showing the remote interactive login for the session what was disconnected.
cmdLabs has a blog post on document metadata that mentions the wmd.pl script that ships with Windows Forensic Analysis (first and second editions). Embedded metadata is a huge issue, and something I've used quite successfully during examinations...I even have a case study illustrating this in the second edition of WFA (due out next week).
Here's an interesting blog post from Damballa. The Damballa product has to do with botnets, and I ran across it not long ago during an engagement...like many other tools, I don't think that the customer necessarily understood the use of the tool, or what it was doing. I do agree with the author (a former ISSer) to some extent...a botnet infestation should not be considered an inconvenience, but rather a breach. This is true with respect to much of the malware that's out there today...blended, compound threats, and I've also seen malware go from quarantined by most AV products to completely and utterly undetected in a matter of hours. But the fact of the matter is that most IT folks simply do not understand what's going on with malware...in some cases, it's considered an inconvenience, while in others, everyone up to the CEO goes completely nuts because someone speculated that the malware had keystroke logging capabilities...
A question popped up in the forums recently with respect to encryption and Truecrypt volumes, and some tools were mentioned (TCHunt, EDD) that may be helpful.
Lance Mueller posted a nice article about file system creation date vs OS install date...take a look.
For anyone analyzing systems where they suspect that a torrent client may have been used, Jamie Acorn wrote this PDF document on the Forensics of BitTorrent.
Finally, for those of us who've been around for a while, L0phtcrack is back! Go here to check it out!
Friday, May 29, 2009
Friday, May 22, 2009
More giggity, news, links and stuff
I guess just "Links" as a post title is getting old, and besides, I don't want to keep stealing Claus's thunder...
Peter Norris reached out to me (and others) and let me know that he's completed his MSc thesis work on the Internal Structure of the Windows Registry. I've had trouble downloading the ISO image, but I have been able to take a look at some of the tools. I hope that Peter's work, like JT's regslack Perl script, will serve to motivate examiners and analysts to start looking more and more into the Registry. I know, for example, that there's been a great deal of concern in the "differences" in the Registry between XP and Vista, and Peter's work illustrates that from a binary level, there really isn't much difference; however, the differences in the Registry's for the two Windows versions rest in things like key names, functionality locations, etc. Like Tim Morgan and JT's work, Peter's work is excellent, and something we need more of; IMHO, Registry analysis is much more than sitting down with a spreadsheet of keys, maybe some presentations from conferences, and a Registry viewer, and going through things manually. I wrote RegRipper for the purpose of optimizing extraction (as well as translation and correlation, as necessary) of Registry data, allowing for quicker and more thorough analysis.
Speaking of the structure of the Registry, Lance has a great post on locating the user's password hash in the SAM hive file.
On a side note, the second edition of Windows Forensic Analysis is due out in about two weeks (I'm told); one of the comments I received from a couple of folks who reviewed the content was that the chapter on Registry Analysis (chapter 4) was too long, and there is enough content that it should be split into multiple subchapters. I mentioned writing a completely separate book on the topic to the publisher and there seems to be some interest. I'd like to hear what others think about that.
Richard Bejtlich listened to the TalkForensics podcast, during which Larry Daniels and I spoke. Richard made mention of my reference to SQL injection obfuscation, in which hex or character set encoding allowed the attacker to achieve their goals, but hampered detection and analysis...and by that, I mean, for those using nothing more than a "traditional" approach. I mentioned the "declare" statement during the interview...encoding the keyword would turn up no hits during a search, but the statement would still be processed. Therefore, an analyst would need to seek another means of detection; for example, parsing the IIS web server logs and mapping the various cs_uri_stem fields to the length of their corresponding cs_uri_query fields, and looking for unusually long queries.
On the topic of log analysis, check out LogAnalysis.org. There are some great resources at the site on a wide range of log-type topics. Be sure to check out the app-specific log parser page for some Perly goodness!
Andrew Martin posted an excellent writeup on the Gumblar attack. I really like stuff like this as it's often more comprehensive, and (for me) far more useful than the stuff produced by AV companies. For example, given the information in the post, you can do things such as network-based detection for infected systems, as well as scanning of the infrastructure for infected systems (using reg.exe, RegRipper, etc.). Analysts can use this same information to determine if a system was infected, even if all they have is an image acquired from the system (Note: I did something similar myself recently...I found a Conficker.B infection in an acquired image...)
Speaking of Gumblar, one of the things that the malware does is steal FTP credentials; the MMPC blog has a post about cleaning password stealing malware off of infected systems.
Didier Stevens, who's done a great deal of work with respect to parsing files, has posted a link to his Hakin9 article on malicious PDF docs. Didier's code has been included on VirusTotal, and is definitely worth a look for anyone performing forensic analysis, and interested in determining infection and compromise vectors.
Peter Norris reached out to me (and others) and let me know that he's completed his MSc thesis work on the Internal Structure of the Windows Registry. I've had trouble downloading the ISO image, but I have been able to take a look at some of the tools. I hope that Peter's work, like JT's regslack Perl script, will serve to motivate examiners and analysts to start looking more and more into the Registry. I know, for example, that there's been a great deal of concern in the "differences" in the Registry between XP and Vista, and Peter's work illustrates that from a binary level, there really isn't much difference; however, the differences in the Registry's for the two Windows versions rest in things like key names, functionality locations, etc. Like Tim Morgan and JT's work, Peter's work is excellent, and something we need more of; IMHO, Registry analysis is much more than sitting down with a spreadsheet of keys, maybe some presentations from conferences, and a Registry viewer, and going through things manually. I wrote RegRipper for the purpose of optimizing extraction (as well as translation and correlation, as necessary) of Registry data, allowing for quicker and more thorough analysis.
Speaking of the structure of the Registry, Lance has a great post on locating the user's password hash in the SAM hive file.
On a side note, the second edition of Windows Forensic Analysis is due out in about two weeks (I'm told); one of the comments I received from a couple of folks who reviewed the content was that the chapter on Registry Analysis (chapter 4) was too long, and there is enough content that it should be split into multiple subchapters. I mentioned writing a completely separate book on the topic to the publisher and there seems to be some interest. I'd like to hear what others think about that.
Richard Bejtlich listened to the TalkForensics podcast, during which Larry Daniels and I spoke. Richard made mention of my reference to SQL injection obfuscation, in which hex or character set encoding allowed the attacker to achieve their goals, but hampered detection and analysis...and by that, I mean, for those using nothing more than a "traditional" approach. I mentioned the "declare" statement during the interview...encoding the keyword would turn up no hits during a search, but the statement would still be processed. Therefore, an analyst would need to seek another means of detection; for example, parsing the IIS web server logs and mapping the various cs_uri_stem fields to the length of their corresponding cs_uri_query fields, and looking for unusually long queries.
On the topic of log analysis, check out LogAnalysis.org. There are some great resources at the site on a wide range of log-type topics. Be sure to check out the app-specific log parser page for some Perly goodness!
Andrew Martin posted an excellent writeup on the Gumblar attack. I really like stuff like this as it's often more comprehensive, and (for me) far more useful than the stuff produced by AV companies. For example, given the information in the post, you can do things such as network-based detection for infected systems, as well as scanning of the infrastructure for infected systems (using reg.exe, RegRipper, etc.). Analysts can use this same information to determine if a system was infected, even if all they have is an image acquired from the system (Note: I did something similar myself recently...I found a Conficker.B infection in an acquired image...)
Speaking of Gumblar, one of the things that the malware does is steal FTP credentials; the MMPC blog has a post about cleaning password stealing malware off of infected systems.
Didier Stevens, who's done a great deal of work with respect to parsing files, has posted a link to his Hakin9 article on malicious PDF docs. Didier's code has been included on VirusTotal, and is definitely worth a look for anyone performing forensic analysis, and interested in determining infection and compromise vectors.
Wednesday, May 20, 2009
Giggity giggity
I know, interesting post title, right...just couldn't come up with anything witty...sorry.
Well, Rob Lee ran us (me, Chris Pogue, and David Hull) through the SANS Essential Incident Response WebCast yesterday, and two out of three panelists agree that Cory Altheide is THE indispensable incident response tool! The mini-panel was a lot of fun and I hope folks listening to it take it as a harbinger of things to come this summer at the Summit.
Speaking of conferences, I ran across SecureArtisan's comments (day 1, day 2, day 3) from attending the CEIC Conference. It appears that there were some interesting presentations, some of which may have been interesting in title only. Reading through his comments, I have to agree with some of them from my own experiences, as this is why I've stopped trying to attend some conferences. What have you seen?
Also, I wanted to share some comments (posted with the author's permission) I've received lately from folks regarding tools...the first is from Brian Perkins, who said:
I just wanted to drop you a quick note regarding a recent success story using your FRUC client and the FSP Server. One of the data points I collect is autorunsc.exe –a. With this collection of data I was able to identify the malicious software in a matter of minutes even before acquiring an image. I have made great use of your FRUC client and server to the point that it serves as my first tool to deploy for Incident Response, and it now sits at the core of my Forensic Investigation Protocol . Getting the volatile data first and then the static data (hdd image) second is my order of priority. Using your tools has made my time well spent when as we all know how efficient a tools performs depends upon its success. Now I going to let Reg Ripper have a go at the hives!
If you remember, the FSP is one of the tools available on the DVD that accompanies the first edition of Windows Forensic Analysis (and yes, it is on the DVD with the second edition, as well).
The second comment is from Ian Hutchison, and has to do with the rp.pl Perl script that I mentioned in a previous post; Ian asked for a copy and ran it after I sent it, and this is what he had to say:
I ran this and it chewed threw 114 restore points in less than a second. That would have taken me hours if not days to do manually, and seriously messed with my sanity.
I want to thank both Brian and Ian for their comments, and for allowing me to post them. While it's nice to see comments like this out in public view, more than anything else, these comments show that there are folks out there looking for answers in other areas of a system or an image aside from just the file system, and moving beyond the traditional, purist approach to computer forensic analysis.
Well, Rob Lee ran us (me, Chris Pogue, and David Hull) through the SANS Essential Incident Response WebCast yesterday, and two out of three panelists agree that Cory Altheide is THE indispensable incident response tool! The mini-panel was a lot of fun and I hope folks listening to it take it as a harbinger of things to come this summer at the Summit.
Speaking of conferences, I ran across SecureArtisan's comments (day 1, day 2, day 3) from attending the CEIC Conference. It appears that there were some interesting presentations, some of which may have been interesting in title only. Reading through his comments, I have to agree with some of them from my own experiences, as this is why I've stopped trying to attend some conferences. What have you seen?
Also, I wanted to share some comments (posted with the author's permission) I've received lately from folks regarding tools...the first is from Brian Perkins, who said:
I just wanted to drop you a quick note regarding a recent success story using your FRUC client and the FSP Server. One of the data points I collect is autorunsc.exe –a. With this collection of data I was able to identify the malicious software in a matter of minutes even before acquiring an image. I have made great use of your FRUC client and server to the point that it serves as my first tool to deploy for Incident Response, and it now sits at the core of my Forensic Investigation Protocol . Getting the volatile data first and then the static data (hdd image) second is my order of priority. Using your tools has made my time well spent when as we all know how efficient a tools performs depends upon its success. Now I going to let Reg Ripper have a go at the hives!
If you remember, the FSP is one of the tools available on the DVD that accompanies the first edition of Windows Forensic Analysis (and yes, it is on the DVD with the second edition, as well).
The second comment is from Ian Hutchison, and has to do with the rp.pl Perl script that I mentioned in a previous post; Ian asked for a copy and ran it after I sent it, and this is what he had to say:
I ran this and it chewed threw 114 restore points in less than a second. That would have taken me hours if not days to do manually, and seriously messed with my sanity.
I want to thank both Brian and Ian for their comments, and for allowing me to post them. While it's nice to see comments like this out in public view, more than anything else, these comments show that there are folks out there looking for answers in other areas of a system or an image aside from just the file system, and moving beyond the traditional, purist approach to computer forensic analysis.
Tuesday, May 19, 2009
SANS WebCast today at 1pm, EST
I'll be participating in a SANS mini-IR panel webcast today at 1pm, EST, along with Chris Pogue and David Hull. Our intrepid host is Rob Lee, Mr. SANS-Forensics himself! This webcast is a bit of a taste of what's to come at the SANS Forensics Summit this summer, so be sure to check it out and participate!
Be sure to check it out!
Be sure to check it out!
Sunday, May 17, 2009
Links and Stuff
After traveling last week, I thought I'd throw up some updates and interesting things I've run across...
JL's got a good blog post on sources of info, including podcasts, listservs, etc. I hadn't heard of the Exotic Liability podcast before, I'll have to check that one out...checking out the web page, it looks pretty cool, especially the post about controlling web cams. JL also provides her blogroll, etc...anyone have anything to add to any of the lists she's provided?
Matt's got some new goings-on over at F-Response with the release of the F-Response EMC version 3.09.1 (Don talks it up, as well), and has posted about F-Response working with something called the Revealer Toolkit. If anyone's seen or used this before, would you care to post a review?
Links for file system stuff:
WikiPedia Common Filesystem Features
MS TechNet NTFS Time Stamps
What else? Oh, yeah...put in a little work on merging the code from two separate Prefetch (XP and Vista) file parsing scripts into one unified script, updating the code that is currently on the DVD that ships with my book. The updates to the code are based, in part, on my desire to not have a ton of code just lying around, as well as information from this blog post. I haven't actually looked at the EnScripts that are available, as the code I'm working on is intended to work on a live system, Prefetch files extracted from an acquired image, and Prefetch files accessible via a mounted (SmartMount, ImDisk, etc.) image or via F-Response. The script parses items such as the volume information block from the .pf file, getting things such as the volume serial number. Here's an example of the output of the script run against a Prefetch file on my local system:
C:\Perl>pref.pl -f c:\Windows\prefetch\MRT.EXE-1B4A8D49.pf -i
c:\Windows\prefetch\MRT.EXE-1B4A8D49.pf Fri May 15 00:37:33 2009 (1)
Volume Path : \DEVICE\HARDDISKVOLUME1
Volume Creation Date: Mon Aug 7 16:05:41 2006 Z
Volume Serial Number: 8456-B799
Since the file is from my local system, I can verify the volume serial number:
C:\Perl>vol
Volume in drive C has no label.
Volume Serial Number is 8456-B799
Pretty sweet. Analysis of the Prefetch files can lead to some interesting information, particularly when using the entire capability of the script to output such things as the embedded file paths. Prefetch files are perhaps most often tied to the named application being run on the system, the last time that application was run, and how many times it has been run. Keep in mind, though...Prefetch files by themselves do not tie the launch of the application to a user.
Speaking of Windows Forensic Analysis 2/e, one of the marketing folks at my publisher has said that copies of the book will be drop-shipped from the printer to TechnoSecurity in Myrtle Beach, SC. Unfortunately, I just found that out, and there's no way for me to get to the conference...but I'm hoping that we'll have copies of the book available at the SANS Forensic Summit in July.
Other Resources
ForensicWiki page on Visualization Software
JL's got a good blog post on sources of info, including podcasts, listservs, etc. I hadn't heard of the Exotic Liability podcast before, I'll have to check that one out...checking out the web page, it looks pretty cool, especially the post about controlling web cams. JL also provides her blogroll, etc...anyone have anything to add to any of the lists she's provided?
Matt's got some new goings-on over at F-Response with the release of the F-Response EMC version 3.09.1 (Don talks it up, as well), and has posted about F-Response working with something called the Revealer Toolkit. If anyone's seen or used this before, would you care to post a review?
Links for file system stuff:
WikiPedia Common Filesystem Features
MS TechNet NTFS Time Stamps
What else? Oh, yeah...put in a little work on merging the code from two separate Prefetch (XP and Vista) file parsing scripts into one unified script, updating the code that is currently on the DVD that ships with my book. The updates to the code are based, in part, on my desire to not have a ton of code just lying around, as well as information from this blog post. I haven't actually looked at the EnScripts that are available, as the code I'm working on is intended to work on a live system, Prefetch files extracted from an acquired image, and Prefetch files accessible via a mounted (SmartMount, ImDisk, etc.) image or via F-Response. The script parses items such as the volume information block from the .pf file, getting things such as the volume serial number. Here's an example of the output of the script run against a Prefetch file on my local system:
C:\Perl>pref.pl -f c:\Windows\prefetch\MRT.EXE-1B4A8D49.pf -i
c:\Windows\prefetch\MRT.EXE-1B4A8D49.pf Fri May 15 00:37:33 2009 (1)
Volume Path : \DEVICE\HARDDISKVOLUME1
Volume Creation Date: Mon Aug 7 16:05:41 2006 Z
Volume Serial Number: 8456-B799
Since the file is from my local system, I can verify the volume serial number:
C:\Perl>vol
Volume in drive C has no label.
Volume Serial Number is 8456-B799
Pretty sweet. Analysis of the Prefetch files can lead to some interesting information, particularly when using the entire capability of the script to output such things as the embedded file paths. Prefetch files are perhaps most often tied to the named application being run on the system, the last time that application was run, and how many times it has been run. Keep in mind, though...Prefetch files by themselves do not tie the launch of the application to a user.
Speaking of Windows Forensic Analysis 2/e, one of the marketing folks at my publisher has said that copies of the book will be drop-shipped from the printer to TechnoSecurity in Myrtle Beach, SC. Unfortunately, I just found that out, and there's no way for me to get to the conference...but I'm hoping that we'll have copies of the book available at the SANS Forensic Summit in July.
Other Resources
ForensicWiki page on Visualization Software
Sunday, May 10, 2009
Excellent Sunday Linkage
Thought I'd share a couple of posts, links and thoughts I've come across or had recently...
First, a while ago I provided information for a "lessons learned" ISS X-Force blog post on SQL injection, and it was posted last week. Hopefully, this post provides some insight into the dangers of the SQL injection attacks that the media did not pick up on; namely, leveraging the configuration issue to burrow deep, deep, deep inside the infrastructure.
The blog post was picked up by the SANS ISC, as well...thanks, guys!
Some additional resources regarding SQL injection, if you're not familiar with the issue:
SQL Injection Attacks by example
SecuriTeam: SQL Injection Walkthrough
What MS has to say...
The Illustrious Don Weber has a couple of excellent posts over on the Security RipCord blog, the latest regarding the use of F-Response and the FEMC v3.09. Don's posted lots of pictures, too, that clearly illustrate how easy Matt's product makes incident response. The title that Don used for the post includes "quick", as in, "the quick or the dead", because honestly, that's what it comes down to, doesn't it? At the first SANS Forensic Summit in Oct, 2008, AAron Walters used the term "temporal proximity" to indicate the need for better detection and quicker response to incidents in order to collect data for analysis. F-Response moves incident response ahead a quantum leap forward, providing responders with the capability to reach out and collect data faster than ever before. Not only are you not sacrificing accuracy or completeness for speed, but this isn't so complicated that you need to be a rocket scientist to use it.
Speaking of F-Response, be the first on your block...uh, blog...to get the new F-Response decal!
For those of us who are into Windows memory analysis, Andreas Schuster has posted links to more versions of the venerable PTFinder tool. Don's also spent some time talking about memory analysis tools and large memory acquisitions, as well.
Ryan Johnson posted to the SANS Forensic Blog on the Future of Digital Forensics; his post focuses primarily on the PI issue that has cropped up in many states already, to varying degrees requiring folks who do IR and CF work to be licensed as private investigators. IMHO, this does absolutely nothing to better the field or the community, nor does it do anything to serve the customer/victim...in fact, it hurts the victim. When someone calls for assistance, they're going to either have to pay some additional amortized fee for the cost of obtaining licensing in that state, or they're going to be told, "oh...sorry, no...we can't do work in YOUR state." Cllick. It's already happening, folks. Am I saying that you won't get the best of the best? No. What I am saying is that the purpose of the licensing has nothing whatsoever to do with the quality of the work, and in some cases, it prevents victim organizations from bringing in responders with whom they already have a relationship, and may know some pretty important things about their infrastructure.
Last but not least, Richard Bejtlich has posted some highlights from the 2009 Verizon Security Data Breach Report, and as always, he's got some pretty insightful things to say. One of his statements that I would suggest is accurate is, Detection methods continue to be pathetic. Harsh? Maybe. Look at the graphic from the report; 70% of breaches were reported by an outside third party. Ouch.
Finally, don't forget to check out episode 151 of the PaulDotCom podcast, and don't miss Larry Daniels' TalkForensics show...
First, a while ago I provided information for a "lessons learned" ISS X-Force blog post on SQL injection, and it was posted last week. Hopefully, this post provides some insight into the dangers of the SQL injection attacks that the media did not pick up on; namely, leveraging the configuration issue to burrow deep, deep, deep inside the infrastructure.
The blog post was picked up by the SANS ISC, as well...thanks, guys!
Some additional resources regarding SQL injection, if you're not familiar with the issue:
SQL Injection Attacks by example
SecuriTeam: SQL Injection Walkthrough
What MS has to say...
The Illustrious Don Weber has a couple of excellent posts over on the Security RipCord blog, the latest regarding the use of F-Response and the FEMC v3.09. Don's posted lots of pictures, too, that clearly illustrate how easy Matt's product makes incident response. The title that Don used for the post includes "quick", as in, "the quick or the dead", because honestly, that's what it comes down to, doesn't it? At the first SANS Forensic Summit in Oct, 2008, AAron Walters used the term "temporal proximity" to indicate the need for better detection and quicker response to incidents in order to collect data for analysis. F-Response moves incident response ahead a quantum leap forward, providing responders with the capability to reach out and collect data faster than ever before. Not only are you not sacrificing accuracy or completeness for speed, but this isn't so complicated that you need to be a rocket scientist to use it.
Speaking of F-Response, be the first on your block...uh, blog...to get the new F-Response decal!
For those of us who are into Windows memory analysis, Andreas Schuster has posted links to more versions of the venerable PTFinder tool. Don's also spent some time talking about memory analysis tools and large memory acquisitions, as well.
Ryan Johnson posted to the SANS Forensic Blog on the Future of Digital Forensics; his post focuses primarily on the PI issue that has cropped up in many states already, to varying degrees requiring folks who do IR and CF work to be licensed as private investigators. IMHO, this does absolutely nothing to better the field or the community, nor does it do anything to serve the customer/victim...in fact, it hurts the victim. When someone calls for assistance, they're going to either have to pay some additional amortized fee for the cost of obtaining licensing in that state, or they're going to be told, "oh...sorry, no...we can't do work in YOUR state." Cllick. It's already happening, folks. Am I saying that you won't get the best of the best? No. What I am saying is that the purpose of the licensing has nothing whatsoever to do with the quality of the work, and in some cases, it prevents victim organizations from bringing in responders with whom they already have a relationship, and may know some pretty important things about their infrastructure.
Last but not least, Richard Bejtlich has posted some highlights from the 2009 Verizon Security Data Breach Report, and as always, he's got some pretty insightful things to say. One of his statements that I would suggest is accurate is, Detection methods continue to be pathetic. Harsh? Maybe. Look at the graphic from the report; 70% of breaches were reported by an outside third party. Ouch.
Finally, don't forget to check out episode 151 of the PaulDotCom podcast, and don't miss Larry Daniels' TalkForensics show...
Friday, May 08, 2009
PaulDotCom and TalkForensics Interviews
On Thursday night, I was interviewed by the guys from the PaulDotCom podcast. I have to say, while I've listened to several of their podcasts (albeit not all 150), it's a completely different experience to be on the hook with them live. Thanks, guys, for the wonderful opportunity!
Also, I'll be appearing as a guest on Larry Daniels' TalkForensics radio show on Sunday, 10 May. Be sure to listen in.
Also, I'll be appearing as a guest on Larry Daniels' TalkForensics radio show on Sunday, 10 May. Be sure to listen in.
Thursday, May 07, 2009
Definitions
I've run across a couple of questions lately that have all pointed to one of the biggest issues I see in the IR/CF community...a lack of specificity of language. In particular, many of us use different terms to describe the same thing, or just incorrect terms. In an attempt to address this, I want to provide a couple of definitions and links to further information.
Disk signature
This is a value specific on a hard drive, found within the MBR. The disk signature can be found in the first sector at offset 0x1B8, and is 4 bytes in length. When you acquire a system, you can check this value with a hex editor (as well as via the hex view of the tool you're using, be it X-Ways, ProDiscover, etc.).
This value is also stored in the MountedDevices key in the System Registry hive file, as well. If you open up RegEdit on a live system and navigate to that key, you'll see several value entries for both volumes (\??\Volume{GUID}) and drive letters (\DosDevices\) that have binary data that is 12 bytes in length. The first 4 bytes is the disk signature, and that's followed by the offset to the partition. Again, this is specific to MountedDevices key Registry values whose names begin "\??\Volume{GUID}" or "\DosDevices\", and whose binary data is 12 bytes in length.
Side Note: You may find other entries...for example, a value name that looks like "#{GUID}" may refer to a TrueCrypt volume that was mounted to the system.
You can also use this value to determine the length of the volume, as well. This is useful in determining not only the size of the installed hard drive(s), but also the size of volumes for attached USB external hard drives. This does not apply to thumb drives.
Volume serial number
The volume serial number is written to the volume by Windows each time it is formatted. This value is calculated using the current date and time, and can be easily viewed by opening a command prompt to the volume (ie, C:\, D:\, etc.) and typing the vol command.
Device serial number
This is a unique value that, if available, can be pulled from the device descriptor of a USB removable storage device. You can view this value in the Registry...if you see the value with "&" as the second character, this is a value generated by Windows when a USB removable storage device does NOT have a serial number in its device descriptor. In Windows Forensic Analysis, I mention a tool called UVCView from Microsoft, but I have not been able to locate this tool for quick download via MS. However, it does appear to be part of the driver toolkit.
Okay, this is only a couple of terms, but too often, we see them mixed and matched and used interchangeably, when all that really does is confuse the issue. I don't want to get into a debate or discussion over certifications and governing bodies here...I just want to see if we can't get on the same sheet of music.
Thanks.
Disk signature
This is a value specific on a hard drive, found within the MBR. The disk signature can be found in the first sector at offset 0x1B8, and is 4 bytes in length. When you acquire a system, you can check this value with a hex editor (as well as via the hex view of the tool you're using, be it X-Ways, ProDiscover, etc.).
This value is also stored in the MountedDevices key in the System Registry hive file, as well. If you open up RegEdit on a live system and navigate to that key, you'll see several value entries for both volumes (\??\Volume{GUID}) and drive letters (\DosDevices\) that have binary data that is 12 bytes in length. The first 4 bytes is the disk signature, and that's followed by the offset to the partition. Again, this is specific to MountedDevices key Registry values whose names begin "\??\Volume{GUID}" or "\DosDevices\", and whose binary data is 12 bytes in length.
Side Note: You may find other entries...for example, a value name that looks like "#{GUID}" may refer to a TrueCrypt volume that was mounted to the system.
You can also use this value to determine the length of the volume, as well. This is useful in determining not only the size of the installed hard drive(s), but also the size of volumes for attached USB external hard drives. This does not apply to thumb drives.
Volume serial number
The volume serial number is written to the volume by Windows each time it is formatted. This value is calculated using the current date and time, and can be easily viewed by opening a command prompt to the volume (ie, C:\, D:\, etc.) and typing the vol command.
Device serial number
This is a unique value that, if available, can be pulled from the device descriptor of a USB removable storage device. You can view this value in the Registry...if you see the value with "&" as the second character, this is a value generated by Windows when a USB removable storage device does NOT have a serial number in its device descriptor. In Windows Forensic Analysis, I mention a tool called UVCView from Microsoft, but I have not been able to locate this tool for quick download via MS. However, it does appear to be part of the driver toolkit.
Okay, this is only a couple of terms, but too often, we see them mixed and matched and used interchangeably, when all that really does is confuse the issue. I don't want to get into a debate or discussion over certifications and governing bodies here...I just want to see if we can't get on the same sheet of music.
Thanks.
Wednesday, May 06, 2009
Is this stuff really useful??
Every now and then I get emails from folks who've found my blog or one of my books useful, whether it has to do with work, school, or a hobby. For the most part, these emails are positive...I haven't really received any negative comments, per se...but I also try to see if there's a way to have these comments made publicly available in some manner. Recently, one of the folks who emailed me consented to allowing me to post the body of their email to my blog...so, here it is...
I'll try to make this short. I have your first book and on more than one occasion, I've referenced it for information. A fellow examiner asked me about it one time and even read through it to some extent. He later commented that it was a pretty good book but the author wasn't even a certified examiner. I let it go because everyone has their opinion. About a week or so ago, he was preparing to testify in a case and the subject of external drives and USB flash drives came up. I showed him your chapters concerning the registry and USB storage. Long story way too long, his newly gained knowledge of the registry and USB helped out enormously during the trial to the point that the other side didn't even have their expert take the stand. He is now a converted HC follower and has plans to purchase your upcoming WFA 2/e as I will be doing the same. Anyhow, I thought you would find this pretty amusing....I did.
Pretty amusing, definitely. Cory Altheide and I conducted the first publicly available research into USB removable storage device artifacts on Windows systems many, many moons ago, and since then, I'd have to say that it's probably the most popular and most asked-about set of artifacts...and maybe even one of the most misunderstood.
I'll try to make this short. I have your first book and on more than one occasion, I've referenced it for information. A fellow examiner asked me about it one time and even read through it to some extent. He later commented that it was a pretty good book but the author wasn't even a certified examiner. I let it go because everyone has their opinion. About a week or so ago, he was preparing to testify in a case and the subject of external drives and USB flash drives came up. I showed him your chapters concerning the registry and USB storage. Long story way too long, his newly gained knowledge of the registry and USB helped out enormously during the trial to the point that the other side didn't even have their expert take the stand. He is now a converted HC follower and has plans to purchase your upcoming WFA 2/e as I will be doing the same. Anyhow, I thought you would find this pretty amusing....I did.
Pretty amusing, definitely. Cory Altheide and I conducted the first publicly available research into USB removable storage device artifacts on Windows systems many, many moons ago, and since then, I'd have to say that it's probably the most popular and most asked-about set of artifacts...and maybe even one of the most misunderstood.
Tuesday, May 05, 2009
WFA 2/e...proposed cover art
Windows Forensic Analysis 2/e is scheduled (I'm told) to be released on 5 June 2009, and has been available for pre-order on Amazon for some time. For those of you lucky enough to have a Kindle, there's a link just below the cover art (place holder) on the Amazon page where you can tell the publisher that you'd like to read this book on your Kindle.Yes, the graphic associated with this post is, I'm told, the working cover art for the book. However, it may change...but hey, it does look pretty cool. Right?
For those who are interested in what's in the second edition, I provided an overview of the chapter updates here.
Thanks!
Saturday, May 02, 2009
e-Evidence updates
I've been reading through some of the presentations and papers that are part of the updates from the e-Evidence web site, and as always, I've found some good stuff linked there.
Matt Churchill has an excellent presentation that addresses examiners fighting back against anti-forensics techniques, in part through live response (slide 14) and learning new things (slide 20). Matt also suggests reaching out to others and having peer reviews, but honestly, I don't see this happening any time soon; however, I do believe that is immensely important, because none of us is as smart as all of us. Matt's presentation also reminds me of an analysts need to evolve.
Diane Barrett has another excellent presentation on Virtual Traces, addressing the use of virtualization and its impact on forensic analysis. I've read Ms. Barrett's presentations before and been impressed with her findings with respect to virtualized desktop environments such as Moka5 and MojoPac. While I have not personally run into the use of any of these environments, it something that I definitely keep in mind when looking at data exfiltration issues; some of the artifacts identified by Ms. Barrett are picked up by RegRipper.
Over on the ForensicFocus site, Dennis Browning compares the Apple property list to the Windows Registry...definitely an excellent read, particularly for anyone who deals with both.
From AccessData, Dustin Hulburt has an excellent paper on fuzzy hashing, and he references Jesse Kornblum's work, as well. More and more, in my own professional experience, traditional MD5 hash comparisons are becoming less and less effective, and in many cases, are significantly less effective than AV scans. In a recent examination, malware that was known (ie, by AV vendors and regulatory bodies) was modified, so that it was NOT detected by AV nor by hash comparisons, but the names of the malware files remained the same. Heck, even VirusTotal has been providing fuzzy hashes of submitted files. I ran into a similar instance over a year ago, where files of the same name and same apparent usage were found in examinations 8 months apart; although MD5 and SHA-1 hashes were different (completely obviating the use of EnCase or Gargoyle for detection), Jesse Kornblum's ssdeep indicated that the files were 97% similar.
These aren't all that's listed at the sight, just a taste. This is definitely a site you should have bookmarked, and check on a regular basis (monthly?), as well as submit links to.
I also want to thank Christine for her diligence in continuing to pull this stuff together and post it. This is one of the ways that examiners and responders can evolve, by being exposed to other approaches and ideas. Thanks!
Matt Churchill has an excellent presentation that addresses examiners fighting back against anti-forensics techniques, in part through live response (slide 14) and learning new things (slide 20). Matt also suggests reaching out to others and having peer reviews, but honestly, I don't see this happening any time soon; however, I do believe that is immensely important, because none of us is as smart as all of us. Matt's presentation also reminds me of an analysts need to evolve.
Diane Barrett has another excellent presentation on Virtual Traces, addressing the use of virtualization and its impact on forensic analysis. I've read Ms. Barrett's presentations before and been impressed with her findings with respect to virtualized desktop environments such as Moka5 and MojoPac. While I have not personally run into the use of any of these environments, it something that I definitely keep in mind when looking at data exfiltration issues; some of the artifacts identified by Ms. Barrett are picked up by RegRipper.
Over on the ForensicFocus site, Dennis Browning compares the Apple property list to the Windows Registry...definitely an excellent read, particularly for anyone who deals with both.
From AccessData, Dustin Hulburt has an excellent paper on fuzzy hashing, and he references Jesse Kornblum's work, as well. More and more, in my own professional experience, traditional MD5 hash comparisons are becoming less and less effective, and in many cases, are significantly less effective than AV scans. In a recent examination, malware that was known (ie, by AV vendors and regulatory bodies) was modified, so that it was NOT detected by AV nor by hash comparisons, but the names of the malware files remained the same. Heck, even VirusTotal has been providing fuzzy hashes of submitted files. I ran into a similar instance over a year ago, where files of the same name and same apparent usage were found in examinations 8 months apart; although MD5 and SHA-1 hashes were different (completely obviating the use of EnCase or Gargoyle for detection), Jesse Kornblum's ssdeep indicated that the files were 97% similar.
These aren't all that's listed at the sight, just a taste. This is definitely a site you should have bookmarked, and check on a regular basis (monthly?), as well as submit links to.
I also want to thank Christine for her diligence in continuing to pull this stuff together and post it. This is one of the ways that examiners and responders can evolve, by being exposed to other approaches and ideas. Thanks!
Friday, May 01, 2009
SearchSecurity: Matt Shannon
Matt Shannon, creator of Nigilant32 and F-Response, was recently interviewed for SearchSecurityChannel.com, making the case of "live" incident response. This is a point that Matt and others have been trying to make for some time now, and Matt's statements in the article repeat the rational behind this sort of approach. Responders need to evolve their approach, addressing risk and threats in the face of business needs. Matt made an excellent point that he's not taking anything away for the incident response process, but "often there's a better way to do it." He's absolutlely right about that!For those of you out there who still aren't convinced how useful and revolutionary F-Response is, check out this post from Matt, and get back to me. Please.
I will be
speaking with Larry Daniel on his TalkForensics BlogTalkRadio show on 10 May. In my pre-interview discussion with a member of Larry's staff, we talked about Registry analysis and timeline analysis as some possible topics for the talk show. Any thoughts? Also, be sure to check out the shows that are already available.
Subscribe to:
Posts (Atom)