Forensic4Cast and Links

Lee Whitfield of the Forensic4Cast podcast reached out to me this past week, and asked me to be a guest on his podcast on Wed, 10 June.

If you've never listened to Lee's podcast, give it a shot...Matt Shannon of F-Response.com was interviewed, as well as others. Lee's also got a section for technical articles, many of which look to be extremely useful.

Lee's also taking nominations now through 21 June for Forensic4Cast Awards; be sure to place your vote in any or all of the various nomination categories. Take a look at the page to see how everything works, and dates for submissions, voting and the posting of the final results. While this isn't something huge that's going to get you a free pass to RSA next year or something, I do think that it's a great opportunity to show your appreciation for the work done in the various categories. See what Matt's posted as his nominations!

Speaking of podcasts, did you know that CERT has podcasts? Another security podcast out there is ExoticLiability. Man, there's just too much to check out!

Didier's posted some links to PDF analysis tidbits...very cool! Didier's done a great deal of work in the area, and his work reminds me a lot of the ComputerBytesMan's work in the area of MSWord metadata extraction. Now, some folks are going to look at these links and ask, "...okay, but how can I use this?" Far too often, folks will post links to other blogs or blogposts without any real explanation of how the information is useful, valuable, or important. Well, when conducting analysis of a compromised system, one of the questions that comes up very often is, how was the system compromised? What was the infection vector? It's pretty trivial, really, to scan a mounted image with AV software or to locate files that an intruder may have copied onto the system...but sometimes (many times?) we need to find out how they got in. One means of doing so is to run file signature analysis tools across web browser and email attachment cache directories to locate things like PDF documents or Excel spreadsheets the may have been downloaded. Finding such documents, which have recently been identified as having vulnerabilities, may lead to identifying the initial source of compromise or infection.

Moyix recently posted some Windows 7 Registry hives for examination, based on a request from Tim Morgan. I'd taken a look at hives from a Windows 7 VM earlier this year, and found that while key locations may change between various revs and versions of the OS, the binary structure appears to remain the same. Thankfully, MS hasn't moved to an all-XML format for the Registry (right now, a lot of you out there are going, "Dude, shut up!!"). I've been running my RegRipper plugins against the hives and dude...they work great!

Speaking of Registry hives, reviews of Windows Forensic Analysis 2/e are already starting to appear! It appears that some folks really like the Registry analysis chapter...maybe this is something to take off on it's own...what do you think? Should Registry Analysis become it's own book? Personally, I think that there's more than enough information out there for this...let me know your thoughts. Or let Syngress know your thoughts.

Finally, more reviews of WFA 2/e are being posted, and I've gotta thank Larry for his review of Perl Scripting for Windows Security! I greatly appreciate the efforts of those who are posting reviews, regardless of the forum. Thanks, folks!

First Amazon Review!

The first review of WFA 2/e has been posted on Amazon! Check it out! Thanks, Dave!

Links and stuff

First off...for anyone who purchased a copy of Windows Forensic Analysis Second Edition at the TechnoSecurity conference...I'd greatly appreciate it if you'd post a review on Amazon! Thanks!

Richard Bejtlich has an interesting post regarding incident ratings. I find Richard to have well-thought out and -reasoned views, and this is yet another example of that. When writing CSIRPs, we include things such as incident severity ratings for classification and escalation purposes, so having something like this, while perhaps a little complex for many organizations, is very important.

JL's been nice enough to post on some CEIC materials...cool stuff. Thanks for posting and making these materials available!

Over on OffensiveComputing, there's a link for OfficeMalScanner, which scans Office documents for malware, embedded PE files, and OLE streams. If VB code is found, it's reportedly extracted for analysis. This sounds pretty cool and a good thing to have in your toolkit, along with other means for malware detection.

The eEvidence site has been updated again! Christine has a way of finding some really cool papers and presentations...while they may not always be brand-spanking new, they are definitely topical and well worth reading and discussing.

Ed posted some good command-line kung fu for getting user and group information from a live system. For post-mortem analysis, I use RegRipper's samparse plugin for this...it not only parses out the user information, but also the group membership information, as well. Another interesting bit of analysis you can use this for is to determine all local users on the system; dumping the contents of the ProfileList key (from the Software hive) or during a 'dir' on the Documents and Settings directory will give you the list of users with profiles on the system, but this will not distinguish between local and domain users.

According to SANS, the key ingredient to team development is...beer! Amen to that!

The Case of the "Default User"

Ever run across a case during which, while examining Internet browser history, you found that the "Default User" had browser history? Ever wondered about that?

Rob "van" Hensing was one of the first I know of to blog about this issue, almost three years ago. Given the time frame, this is a good time to bring this subject up again, don't'cha think?

I've seen this sort of thing in a couple of instances, specifically when SQL injection has been used to gain access to an infrastructure, and the bad guy gets a copy of wget.exe (static PE analysis will tell you if the program accesses the WinInet APIs) onto the system, and then uses that to pull down other files - in many cases, they'd use echo to create an FTP script, then launch the native command line FTP client using the script, or use wget.exe to pull the files down. Why? Well, most times FTP and/or HTTP are allowed out through the firewall.

Good stuff.

WFA 2/e Published!

I caught a note over on Facebook yesterday from Syngress that Windows Forensic Analysis, 2/e was published today! Awesome!

The info posted on Facebook is the same information posted on Elsevier's site. Aside from the "?" where there should be quotes, the information itself looks good...just one of those things I kinda wish the publisher would've picked up on earlier in the game, and corrected.

I'm told that the book is available, right now, at the TechnoSecurity conference in Myrtle Beach, but I haven't received any confirmation of that, nor any feedback from the Syngress marketing folks who are on-site. Speaking of which, the SANS Forensic Summit is rapidly approaching, and I'm trying to get copies of WFA and other books there. Rob Lee has been gracious enough to offer table at the Summit, and I've let the Syngress folks know that I'm not the only author who will be at the Summit.

Speaking of the TechnoSecurity conference, here's a picture of WFA 2/e on sale!

So, if you're going to be at the Summit (or someone you know is going), and you want Syngress to have books there for purchase, either post something publicly (blog) and send me a link, or comment here! Let the Syngress marketing folks know that if a computer conference has the word "forensics" in the title, then they should have books with the same word in the title available...particularly if there are going to be authors at the conference (and speaking)!

Another thing...if you are a college educator who uses WFA in computer forensics courses, or if you know of an academic institution (community college, college, academy, university, etc.) where WFA is part of required or recommended reading...please contact me at keydet89 at yahoo dot com. Thanks!

Stuff

"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!

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.

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.

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!

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

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...

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.

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.

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.

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!

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!

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.

Windows AutoRun feature

Oh, how I love this...in order to address the issue with the Windows AutoRun capability, which malware such as Conficker (no, NOT 'Conflicker'!!!) can use to spread, Microsoft is taking measures to protect users from themselves...but only if you're running Windows 7.

Niiiiiiiice.

Data and Context

I receive questions from time to time regarding various bits of information, some of which is presented in my book. I recently received some questions regarding differences in run counts for applications derived from Prefetch files and UserAssist key entries, the latter being displayed via RegRipper.

What needs to be kept in mind when looking at data as it is being presented by any extraction technique or utility is the context with respect to how the data is created or modified.

For example, application Prefetch files are created by default for XP and Vista systems and are not user specific. However, UserAssist key/subkey entries are found in the NTUSER.DAT files and are user-specific.

Also, UserAssist key entries are most often created through a user's interaction with the shell; entries can be created or modified by double-clicking a shortcut on the Desktop or in Windows Explorer, by clicking through Start, the Programs, etc. However, application Prefetch files can be created/modified by double-clicking a shortcut to a file on the Desktop, as well.

I know that this is only one example, but the key here is to understand that just because two sources apparently include information about applications being launched, the analyst needs to understand the nature of the event or events that create/modify artifacts on a Windows system. Otherwise, you're going to be facing apparent contradictions where in truth, there isn't one.

CaptainForensics

Hey, be sure to check out the the latest CaptainForensics comic...wow, very cool!!

In this comic, the MergeStreams utility is mentioned...ah, and oldie but a goodie! I can't say that I've ever actually seen this tool used in the wild, but it is pretty neat.

Just out of curiosity, who do you think the picture in the back of the book in the second panel looks more like?

A. me
B. Ovie Carroll
C. Richard Bejtlich
D. Robert Englund
E. Rob Lee

Just kidding, guys! Check out the comic, though...it's pretty entertaining!

Tools

I like to be open to different tools that can be used to assist in analysis, and for those of you who know me, sometimes I write my own. However, I wanted to take a moment to point out some tools that I've found recently that appear to be and have been very useful...

From Claus, I learned about a little tool called DiskDigger from Dymitry Bryant which reportedly allows you to recover deleted files from drives. I thought, wow, this is pretty cool...something to try out with respect to recovering deleted files. So I downloaded a copy and fired it up, and with the first version, saw that it only identified the two physical disks on my system. I had mounted an image file as a read-only drive letter via SmartMount and wondered why this "drive" hadn't been detected. I reached out to Dmitry, expecting to maybe hear back within a couple of days...instead, within relatively short order, Dmitry returned my email with a link to an updated version of DiskDigger, as well as to another tool I'd looked at, NTFSWalker. Now, both tools will recognize drives and volumes, and there is a separate tab for pointing the tool to an image file. Very cool! I thanked Dmitry for his quick response, and he pointed out that he's a one-man shop (wow, THAT sounds familiar...) and that if you find something amiss with a tool or if you have a question, his turn-around time is pretty quick...which is something I can personally attest to.

From JADSoftware comes Internet Evidence Finder, a nice little tool that searches for Facebook chat messages and page fragments, Yahoo chat, and MSN chat messages on drives and within memory dumps. I found my initial reference to this tool on the Forensics from the Sausage Factory blog, where the DC1743 says that he ran the tool against a mounted drive image.

If you're interested in extracting MSOffice OLE document metadata, take a look at OLEDeconstruct from Sanderson Forensics. The sample used to demonstrate the tool is the ever popular Blair document from the ComputerBytesMan. The wmd.pl and oledmp.pl Perl scripts I wrote are still freely available and provided on the DVD accompanying Windows Forensic Analysis, both the first and second editions.

Timeline Analysis - XP Restore Points

So, MS says that XP's going to be supported at least through 2014...nice. So this means great things for examiners and analysts...great things because there's no reason to give up the tools and research you've done on XP!

One of the unique things about XP is its use of System Restore Points. For users, these take up drive space and allow you to recover from issues, but for an analyst, Restore Points are a veritable treasure trove of historical data!

So, one of the challenges (albeit minor) presented to analysts is how to extract information about (and from) Restore Points from an acquired image. Well, this is actually pretty easy. A while back, I wrote a ProScript for ProDiscover that would run through an image and extract data about Restore Points to include when and why they had been created. This ProScript is called SysRestore.pl and is located on the DVD that accompanies the Windows Forensic Analysis book (both the currently available edition, as well as the second edition, due out in early June 2009).

As an alternative, I came up with another method for extracting the same data, one that does not require a commercial forensic analysis application. So, the first thing you do is mount the acquired image via SmartMount or ImDisk, as a read-only drive letter (in this case, G:\).

Next, get a copy of PSExec and put it on your analysis system. Go to the directory where you saved it and type:

D:\tools>psexec -s cmd

This will open the command prompt to your C:\Windows\system32 directory with the prompt now running with System privileges. Now, cd to the G:\ drive, and type the following commands:

G:\>cd syst*

G:\System Volume Information>cd _resto*

G:\System Volume Information\_restore{GUID}>

At this point, you should be "in" the directory that contains the restore point directories (ie, RP0, RP1, etc.). Select the directory path in the command prompt, right-click to save it to the clipboard, and then cd to the directory where you have your tools.

Note: By default, ACLs on the system only allow access to the System Volume Information directory to System, which is why we use PSExec.

The acquired image I'm using (see the above SmartMount graphic) is one of Lance Mueller's practicals. So at this point, I type in the following command:

C:\tools>rp.pl -d "G:\System Volume Information\_restore{}"

The path to the RP directory has to be in quotes due to the spaces; the output appears as follows:

RP1 Thu Jan 31 04:33:11 2008 Z System Checkpoint
RP2 Thu Jan 31 04:43:38 2008 Z Installed VMware Tools
RP3 Wed Jan 30 14:09:49 2008 Z Installed WinZip 11.1

Pretty neat! Now, we know when the RP was created, and why. If I want to have output that i can add to an event file for my timeline analysis, I add the '-t' switch and I get:

1201753991|RP|||Restore Point created - System Checkpoint
1201754618|RP|||Restore Point created - Installed VMware Tools
1201702189|RP|||Restore Point created - Installed WinZip 11.1

Once again, for timeline analysis, we see our familiar five field format. Note that the system/host and user name fields are blank. Rp.pl does have '-s' and '-u' switches for adding that information (respectively), although only the system name really applies, as Restore Points aren't specific to a user. Use of the '-s' switch will automatically populate the third field with whatever system name you enter.

This code was pretty easy for me to work up last night because I simply extracted it from ripXP, the tool I demo'd at the first SANS Forensic Summit. I'll be demonstrating that same tool again at the next Summit, in July of this year.

Linkfest

Taking a page from Claus's book...

I was reading the latest print edition of Hackin9, and in the In Brief section, there is a small inset that talks about some research conducted by Stephan Chenette of WebSense, in which Javascript can be used to download segments of malware code to be downloaded via different streams, allowing it to bypass gateways and AV scans. Back in the day, I'd performed some network exploitation research and written some code that would (a) download an EXE from a web site, which had been renamed to .gif, (b) break it into segments and store it in the Registry, and (c) at a specified date and time, reassemble the segments into a complete executable within the System Volume Information directory, and (d) launch it...Stephan's technique is definitely a twist on things and very interesting, in that Javascript can be used to download the EXE segments from multiple locations, as if they were .gifs on different web pages, and then reassemble them on the system. This is one of those techniques that will be difficult to address, as it doesn't really take advantage of a vulnerability that can be patched, per se. However, it may force the AV industry to evolve.

The SANS Internet Storm Center posted a link to information about the Verizon Business RISK Team's 2009 Data Breach Investigation Report, and pulled out some of the interesting statistics developed and provided in the Verizon report. You can find some additional information about the report at the Verizon Business Security Blog. Overall, like many, I think that the information provided in these reports is very useful and insightful, as the numbers are based on actual case work, NOT on questionnaires. As such, you have responders building tables of numbers and developing the percentages, rather than the victims...more accurate numbers will only help us with these issues in the long run.

Timeline Sources - Let's not forget that using Pasco, you can parse the resulting output and incorporate the contents of a user's index.dat (ForensicWiki IE history fil format page) into your timeline analysis. You can also incorporate Keith Jones' whitepaper that is the foundation of Pasco into your own timeline development process, either to parse the index.dat files directly to your timeline format, or to provide additional detail to the events that you do find. This is not to say that histories from other browsers aren't important, as well.

ForensicWiki - Firefox 3 history file format
BelkaSoft Browser Analyzer
Mandiant's WebHistorian

Also, there may be sources of timeline data that are not easily defined or automatically parseable; for example, I have often looked to Dr Watson log files for indications that malware or other processes were (or were not) running at a specific point in time, as each entry in the log includes a list of the active processes at the time of the application crash. All I really have at that point is point in time and a non-specific statement. Sounds like I need to write up that GUI for entering such events...oh, wait... ;-) So this is a nice little app that lets me enter the date (numbers for the month instead of the letters...'8' instead of 'Aug'), the time (already converted to GMT) and other info, and then tell it which event file to add the information to...the five field format is used that the information is added right to the event file. At that point, all you do is re-run the event file parsing script and your new event appears in the proper location within your timeline.

Event Log Analysis

I caught a very interesting blog post on the ISC the other day that had to do with Windows Event Logs. In short, the post illustrates a failed logon attempt by "a worm that spread via MS08-067 (not conficker)". The event ID is 529 (failed logon attempt) and a type 3 logon attempt, indicating that the attempt is from the network.

I'd had an opportunity recently to do some timeline analysis, and I was seeing event ID 540, type 3 records immediately prior to the suspicious activity in question. These events are network-based logons, but the Logon Process and Authentication Package identified within the event record were both "Kerberos". I did some additional research in conjunction with the timeline analysis, as well as some testing, and found that successful network logons (event ID 540, type 3) with the Logon Process and Authentication Package of "Kerberos" indicate that the account successfully authenticated to the domain or Active Directory in order to access resources on the system...in my case, the logon events were immediately followed by the use of PSExec, and were then accessing the Service Control Manager, etc.

On the other hand, however, testing illustrated that logon events with a Logon Process of NtLmSsp and an Authentication Package of NTLM were seen when accessing shares, such as C$. I didn't see any of these in my timeline.

Resources
Tracking Logon and Logoff Activity
MS KB 326985 (contains explanation of event record strings fields)
Fitz - Tracking User Logon Activity Using Logon Events
MS - Vista/2008 Security Events
MS - Events and Errors Message Center (Event Lookup)
MS - 2003 Security Events

Timeline - Sources

I saw an interesting Twitter from Rob Lee other day which led me to the MS site, where they said:

We plan to provide support for Windows XP until 2014.

Excellent.

I like this because a lot of the code that I've written specifically for Windows XP will continue to remain useful. Now, I'm sure that the code will still be useful beyond 2014...even now, responders still deal with NT 4.0 and Windows 2000 systems.

What I'm referring to is the ProDiscover ProScript code that I wrote and included on the DVD with the first edition of Windows Forensic Analysis. ProScript is Perl, which was implemented as the scripting language for ProDiscover...kind of neat idea, eh? Some of the ProScripts that I've written and still use allow you to parse through Restore Points, collecting data about each one. It's pretty easy to go back and update those scripts, based on the latest version of ProDiscover (we're up to 5.5 now), and add the necessary code to extract some of this data in the five field timeline format, and then incorporate the resulting data in your timeline.

Don't have ProDiscover? No problem. Take the same basic code, mount your image file using SmartMount, and use Perl to extract the same data from your mounted file system. Don't have SmartMount? You can use ImDisk, or you can use Linux, either on your own or through something like SIFT.

Why Perl? Don't really know about using Perl? Well, don't listen to me...take a look at what Mike Worman has to say about it.

Obtaining file system timeline data

One of the things I've run across regarding generating timeline data from the file system is that there has to be more than one way to do this.

For example, what happens if you have an image that you can open in FTK Imager, but for some reason, you cannot get any meaningful data from the TSK tools mmls and fls? Or, what happens if you don't have an image, but are instead accessing a live system? While you can use tools like FTK Imager to extract Registry hive files, and use the copy command to get copies of the EVT (and other) files, you may have to find an alternative method by which to obtain file system data.

Well, that's no problem at all, really. First off, if you have an image and you can open that image in FTK Imager, you can export the directory listing. Simply right-click on the image and choose Export Directory Listing. You can also do this from the command line, via the /CreateDirListing=filename switch, as described in the user manual. The resulting output is tab-delimited and goes to a .csv file which you can easily open in Excel...although that isn't entirely useful, really. Instead, you'll want to parse it in Perl (of course). The format of the directory listing output by FTK Imager includes the filename, full path, size, created, modified and accessed dates (no "entry modified" date), and if the file "is deleted". As it's tab-delimited it can be easily parsed and placed in the necessary format for use in our timeline.

Another thing we'll need to do, though, is translate the time format output by FTK Imager into a Unix epoch time...which is pretty simple with the proper application of the split() function and the use of the DateTime module. Through repeated tests, I've found this module to be more accurate than Time::Local, which has actually had several of my converted timestamps off by a month. Installing the DateTime module is as easy as ppm install datetime, if you're running ActiveState Perl.

Okay, that's one way, how about some others?

You can probably just extract the MFT from an image and use Mark Menz's MFTRipper (discussed in the 22 March CyberSpeak podcast) to extract the data you need.

If you're accessing a live system, you can use Perl (or Python...that's what the illustrious Don Weber prefers) and the stat() funtion to get data from each file on the system, without having to actually access the file itself. However, this will just get the live file system...you won't get things like entry modified times and deleted files, and you will be prevented from accessing some directories by default. You can use this same code to do the exact same thing with an image mounted via Andy Rosen's SmartMount, but you may want to first open a command prompt via psexec -s cmd, so that you can run the Perl script from that command prompt, with System-level privileges. This will be particularly important if you want to get not only file system data from Windows XP System Restore Points, but also if you want to parse the rp.log file in each Restore Point for when and why the RP was created, or run tools such as ripXP.

Finally, if you're read my book, you'll know that I've written a number ProScripts for use with ProDiscover. Writing one to create a timeline bodyfile shouldn't be too difficult, although at this point, I'm not sure why you'd need to with the other methods listed.

A couple of things to remember when creating these timelines...

First, the output of fls.exe is pipe-delimited, and includes the fields:

MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime

In most instances, the "MD5" entry is 0, although if you're writing your own code, you can definitely populate it. Populating this field can let you do all sorts of analysis besides just looking at the timeline, such as determining if Windows File Protection was subverted to modify "protected" files.

The timestamps are in Unix epoch time, and consist of the last access time, the last modified time, the "entry modified" (ie, ctime), and the creation date (ie, crtime) of the file. This order is important, not only when parsing the bodyfile, but also when creating a tool to assemble your own bodyfile; putting these various times in the wrong locations can throw off your timeline analysis.

Finally, an interesting side effect of conducting this analysis is that timeline assembly and analysis can be run in parallel to other activities, particularly those that consume a great deal of time, such as scanning for PCI data. Also, as the output is largely text based and in most instances the filenames and other necessary files (INFO2, EVT, AV logs, etc.) do not themselves contain sensitive data, this information can be extracted from an image, compressed and protected as necessary, and sent to another analyst to conduct the assembly and analysis. What this leads to is a faster response time, answers delivered to the customer faster, and much quicker resolution of an incident.

F-Response 3G is out!

Check out this post over on the F-Response site...Matt's released the lastest and greatest 3rd generation F-Response! I've got it and I have to tell you...it's pretty awesome! Check out the new features listed on the page.

The very first, most coolest thing I found about 3.09 was the installation...it was smooth and fast. Put iSCSI on your system, and then run the installer. It's that easy! Getting up and running is fast, too. Once you're ready, launching the F-Response Enterprise Management Console (FEMC) allows you to quickly and easily connect to systems and access physical memory (32-bit Windows), as well as physical disks and logical volumes. And, F-Response isn't just for Windows (including 32- and 64-bit for disks)...you can use it with multiple Linux distros, as well as MacOSX.

If you have any questions at all about how useful F-Response will be in your organization, check out the training videos. Honestly...this is quick look into how simply yet powerful F-Response is, and you can run through these during lunch, or while you're having a beer after a long day at work.

Folks, F-Response has quite literally changed the face of incident response! Where once was the day that systems would sit compromised until someone could get to them and acquire data, that data can now be acquired and analyzed quickly and efficiently, even from remote locations. This means that not only can consultants carry around an enterprise capability in their pockets, but on-site IT staff can begin staging collected data, even while management is on the phone getting the help they need. Hit with malware that AV doesn't recognize? What's your response time in getting someone on-site now...24 hours? 72? How about if when the issue occurs, you reach out with F-Response EE and grab the contents of RAM from a couple of systems, and when management gets some responders on the line, you already have a RAM dump available for analysis. If you already have a transfer mechanism set up, you could literally have answers WHILE YOU'RE ON THE PHONE, not 72 hrs later!

Timeline Analysis - RegRipper

In my last post on timeline analysis, I described using file system data (via TSK's fls.exe), Event Log data (via a custom Perl script) and Recycle Bin/INFO2 file data (also via a custom Perl script) to generate a timeline of activity on the system. One of the sources that is missing is, well, Registry hive file data...but that's changing.

The Registry contains a great deal of timestamped data that can be extremely useful when added to a comprehensive timeline.

First, here's the output of the acmru plugin as is currently seen by RegRipper (or more appropriately, rip.pl/.exe):
C:\Perl\forensics\rr>rip.pl -r d:\cases\ntuser.dat -p acmru
ACMru - Search Assistant
Software\Microsoft\Search Assistant\ACMru LastWrite Time Mon Sep 26 23:02:08 2005 (UTC) 5603 [Mon Sep 26 23:32:56 2005 (UTC)]
000 -> port*
001 -> sol.exe
002 -> hacker*
003 -> hack*
004 -> lad*

5604 [Mon Sep 26 23:33:30 2005 (UTC)]
000 -> disk
001 -> ha*

What the above output tells us is that this particular user ran searches (via Start->Search->For Files and Folders...) on 26 Sept 2005, looking for "port*" and "disk", at 23:32 and 23:33 UTC, respectively. I've bolded the most recent searches, as those are on the searches that correlate to the LastWrite times of the keys (seen directly above the bolded text). The other searches were run at some other time, and like most MRUs, do not have a specific time associated with them; therefore, for the purposes of generating a timeline, they will most likely be of little use...although there's no doubt that overall, they'd be useful.

Now, here's what the timeline information looks like:

C:\Perl\forensics\rr>rip.pl -r d:\cases\ntuser.dat -p acmru -t 1127775728|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru 1127777576|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru\5603 (000 = port*) 1127777610|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru\5604 (000 = disk)

You can see here that I've output the information in the familiar five field (time, type, server, user, description) format. Redirecting this information (and all other timeline information) to the overall event file will allow you to parse this data right along with the file system and Event Log timeline data, as well as data from any other source (such as the Recycle Bin INFO2 files, etc.). This can be extremely important, as a user launching an application will be visible near the file system activity associated with the results of that application. In the case of the example above, a recent search can account for a number of files all having last accessed times relatively close together.

Part of what these updates to RegRipper/rip allow the code to do is 'guess' which hive file is being accessed. If the hive file is a user's hive, the code will attempt to extract the username and SID for later use (as with the timeline information above...the 'jdoe' username was automatically populated). Similarly, if the hive is a System hive file, the code will extract the ComputerName value from the hive file for use in the timeline information. However, the server and username values will not be able to be populated for every hive file; for example, the Software, Security and SAM hives do not contain an easily-referenced value for the system or server they're on, and do not apply to a specific user. The way around this is to allow the user to enter this information via the '-s' and '-u' switches to rip.pl.

Adding this capability to ripXP will allow a plugin to be run across all of the hive files within the System Restore Points, extracting historical data for inclusion in the timeline. Very, very sweet.

SANS Summit Updates

Rob Lee has updated the SANS Forensic/IR Summit information, as well as the agenda. Chris Pogue of TrustWave will be joining us in the IR panel, the first panel of the summit. Chris is a co-author of Unix and Linux Forensic Analysis, so be sure to bring your copy to get it signed!

If you've got only one chance to go to a conference, the Summit is THE one to attend in 2009!

New Volatility Plugins

Andreas has posted a couple of new Volatility plugins recently that look really interesting, in that he provided the capability to link file objects to processes, as well as scanning a memory dump for driver objects.

Someone uses RegRipper

I was pleasantly surprised the other day to receive a forwarded post from a list that I don't have access to where someone had successfully used RegRipper. I don't get a lot of these, so when I do, I like to see if the author would be willing to post their comments publicly, or grant me permission to do so. In this case, the author has said that I can post this, so here it is, in its entirety (and completely unsolicited)...

I thought the group might benefit from some interesting observations I have had with a Vista Home Basic edition machine.

#1 regarding user account Windows logon passwords: Three apps were used to evaluate logon passwords: 1) latest version of Ophcrack with Vista rainbow tables, 2) AccessData Registry Viewer, and 3) Harlan Carvey's Regripper. Ophcrack found 3 SIDs, each with NT passwords. 2 of the 3 shared the same password (the family last name followed by the digit "3"). The 3rd user's PW was "not found" in the rainbow table.

PRTK was used to attempt to recover the 3rd PW, but I stopped it after 5 days when nothing was recovered using a custom dictionary and profile constructed from the exported word list from FTK. Registry Viewer displays the date on which all user PW were changed, and lists the NT PW as "True" for all 3 users. Viewer also displays the "hint" for each user's PW, and
for all 3 it is "name + number." Hmmm......the plot thickens. :)

PRTK used again, this time to extract IE7 Intelliforms data. No success using PW supplied by Ophcrack. Multiple sessions with AccessData proved PRTK does extract this stuff EASILY, so I assumed I had a bad image, a bad export, the wrong index.dat files, etc. Days of retrying proved fruitless.

Ran Regripper against the SAM file, and it says the 2 accounts for which Ophcrack supplied a PW, don't require a PW. Remember, Viewer also said the PW was set to "True." For the 3rd user, Regripper said "Password does not expire." Okay, so I rerun PRTK to extract the IE7 Intelliforms data, and this time I leave the logon PW field blank (meaning no PW). Bingo! I get
it all.

So, Ophcrack says PW, Registry Viewer says PW, Regripper says PW not required, PRTK extracts Intelliforms data only when no PW is supplied. So, it look like Regripper wins! Go Harlan!! As for the 3rd user, I've tried the name + number PW and no PW, but still no success. It's not absolutely necessary for the case, so I'm not pursuing it any further.

#2 regarding groups to which SIDs are assigned: A few weeks back I posted to the listserv asking about how to tell if a user had Admin privileges. Several responses said to examine the "groups" key in the SAM file. I looked at these keys with AccessData Registry Viewer. Viewer listed the different groups available on the machine, but not which users were in each
group. I responded to the listserv with this result, but nobody came back at me with an answer. Well, Regripper lists the available groups on the machine, the number of users in each group, and the terminal segment of the SID for each user in the group. Wow! Harlan wins again!! Perhaps Viewer does provide this information, but it is not readily available or visible to
the user. So, if I am falsely accusing Viewer of not providing this information, please set me straight.

Okay, I think I've taken enough of your time. Hope all have a Happy Easter and a good Passover.

Regards,

Louis M. Schlesinger,PI,CCE,CFC,CIFI,WCSI,ACE
CyForensics, LLC
A Licensed Investigative Agency
Macon, Georgia
Voice: 478-731-0752
Fax: 478-922-9020
Email: cyforensics@cyforensics.com
Website: www.cyforensics.com

Addressing the need to evolve

Been watching the 'net recently to see what's new? I have. Saw the MMPC write-up on Conficker.E recently, and it occurred to me that the authors of this bit of malware are really going out of their way to "protect" the systems they infect. After all, look at the list of process names that it terminates if found. Now, from that list, how many of those tools do YOU use when troubleshooting a system or performing incident response? How about dynamic malware analysis?

Okay, so this is nothing new is it? By "new", I mean the need to adapt our tools and techniques to the current environment and climate. Back in the day (or in the "Old Corps", as the case may be...), malware would maintain persistence by writing to the Registry, in particular, to the Run key. Once enough folks became familiar with that technique, then there was a move to maintain persistence via other Registry keys, including the Services keys. Then, to make things even more fun, the Services were added as randomly-named DLLs, loaded as part of SvcHost. We're even seeing WFP subverted or disabled, or bypassed completely by modifying "protected" files in memory only (as with Conficker.E, apparently). Oh, yeah, and while I'm off looking in the Registry for a persistence mechanism, some malware author is using Scheduled Tasks, instead.

This is all the continuing evolution of (cyber)warfare. Students of military history have seen this throughout the ages. Build a tank, then build an armament or weapon to take it out. Add armor to the tank, someone builds a missile. Reactive armor is added to the tank, and then a probe is added to the missile...and back and forth we go. The IR/CF world is really no different, as the same sorts of tactics are used.

It's never a good time to rest on your laurels. Just when you think you've got it licked and all wrapped up, that's when you know its time to change how you're doing things again.