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.