Using RegRipper
Russ McRee let me know recently that the folks at Passmark recently posted a tutorial on how to use their OSForensics tool with RegRipper.

Speaking of RegRipper, I was contacted not long ago about setting up a German mirror for RegRipper...while it doesn't appear to active yet, the domain has been set aside, and I'm told that the guys organizing it are going to use it not only as a mirror, but also as a site for some of the plugins they'll be getting in that are specific to what they've been doing.

If you're into GenToo Linux, there's also this site from Stefan Reimer which contains a RegRipper ebuild for that platform.

Updated tool:  Stefan over on the Win4n6 Yahoo group tried out the Jump List parser code and found out that, once again, I'd reversed two of the time stamps embedded in the LNK file parsing code.  I updated the code and reposted the archive.  Thanks!

Meetups
With respect to the NoVA Forensics Meetups, I posted here asking what folks thought about moving them to the DFIROnline meetups, and I tweeted something similar.  Thus far, I have yet to receive a response from the blog post, and of the responses I've seen on Twitter, the vast majority (2 or 3..I've only seen like 4 responses...) indicate that moving to the online format is just fine.  I did receive one response from someone who seems to like the IRL format...although that person also admitted that they haven't actually been to a meetup yet.

So...it looks like for 2012, we'll be moving to the online format.  Looking at the lineup thus far, we already seem to be getting some good presentations coming along in the near future.

Speaking of which, offering to either give a presentation or asking for some specific content to be presented on is a great way to contribute to the community.  Just something to keep in mind...if you're going to say, "...I'd like to hear about this topic", be prepared to engage in a discussion.  This isn't to say that someone's going to come after you and try to belittle your idea...not at all.  Instead, someone willing to present on the topic may need more information about your respective, what you've tried (if anything), any research that you've already done, etc.  So...please be willing to share ideas of what you'd like to see presented, but keep in mind that, "...what do you mean by that?" is NOT a slam.

New Tools
File this one under "oh, cr*p..."...

Seems setmace.exe has been released...if you haven't seen this yet, it apparently overcomes some of the issues with timestomp.exe; in particular, it is reportedly capable of modifying the time stamps in both the $STANDARD_INFORMATION and the $FILE_NAME attributes within the MFT.  However, it does so by creating a randomly-named subdirectory within the same volume, copying the file into the new directory, and then copying it back (Note: the description on the web page uses "copy" and "move" interchangeably).

Okay, so what does this mean to a forensic analyst, if something like this is used maliciously?  I'm going to leave that one to the community...

The folks at SimpleCarver have released a new tool to extract contents from the CurrentDatabase_327.wmdb file, a database associated with the Windows 7 Windows Media Player.   If you're working an exam that involves the use of WMP (i.e., you've seen the use of the application via the Registry and/or Jump Lists...), then you may want to consider taking a look at this tool.

You might also want to check out some of their other free tools.

Melissa posted to her blog regarding a couple of interesting tools for pulling information from memory dumps; specifically, pdgmail and Skypeex.  Both tools apparently require that you run strings first, but that shouldn't be a problem...the cost-benefit analysis seems to indicate that it's well worth running another command line tool.  An alternative to running these tools against a memory dump would be using Volatility or the MoonSols Windows Memory Toolkit to convert a hibernation file to a  raw dump format, and then run these tools.

Speaking of tools, Mike posted a list of non-forensics tools that he uses on Windows systems to his WriteBlocked blog.  This is a very good list, with a lot of useful tools (as well as tools I've used) on that list.  I recently used Wireshark to validate some network traffic...another tool that you might consider using alongside Wireshark is NetworkMiner...it's described as an NFAT tool, so I can see why it's not on Mike's list.  I use VirtualBox...I have a copy of the developer's build of Windows 8 running in it.

Wiping Utilities
Claus is back, and this time has a nice list of wiping utilities.  As forensic analysts, many times we have to sanitize the media that we're using, so having access to these tools is a very good thing.  I've always enjoyed Claus's posts, as well, and hope to see him posting more and more often in 2012.

Can anyone provide a technical reason why wiping with 7 passes (or more) is "better" than wiping with just 1 pass?

File Formats
I was reading over Yogesh Khatri's posts over at SwiftForensics.com, and found this post on IE RecoveryStore files.  Most analysts who have done any work with browser forensics are aware of the value of files that allow the browser to recover previous sessions...these resources can hold a good deal of potentially valuable data.

About halfway down the post, Yogesh states:

DFIROnline
Last Thu, we had (at one point) 32 attendees to the #DFIROnline online meetup, and my impression is that overall, it went pretty well.  Mike took the time to post his impressions, as well.

I think it would be very helpful to hear from others who attended and find out what they liked or didn't like about this format.  What works, what doesn't, what would folks like to see?  I know that with the NoVA Forensics Meetups, most (albeit not all) of the comments about content that I received were from out of town folks, and included, "...set up a meetup in my town...".  Well, Mike's brought that to you...in fact, you can battend from anywhere.  Mike's survey results indicated that case studies and malware analysis are things that folks are interested in, and that's a great start.

Also, I've been thinking...what do folks think about moving the NoVA Forensics Meetups to DFIROnline?

For those interested, I posted my slides (in PDF format) to the Win4n6 Yahoo Group Files section.

A a great big, huge, Foster's thanks to Mike for setting this up. 

Cool Stuff
If you do timeline analysis, David Nides has posted a great little log2timeline cheat sheet over on the SANS Forensics blog.  David made this cheat sheet available at the recent SANS360 event as a single laminated sheet...if you weren't able to make it and didn't get one, download the PDF and print out your own.  The content of the cheat sheet goes right along with Rob's SANS360 presentation, which you can watch here (actually, it's the entire set of presentations).

A huge thanks to David for putting this together and making it available.  This is another great example of how someone can contribute to the community, without having to be able to stand up in front of people, or write code. 

Jump Lists
I recently received a question about Windows 7 Jump Lists, and dusted off some of the code I wrote last summer for parsing Jump Lists.  Yes, it's in Perl...but the way I wrote it was to use just core Perl functions (i.e., no esoteric, deprecated, or OS-specific modules) so that it is platform-independent, as well as much easier to install and run.  Also, I wrote it as Perl modules, so I have additional flexibility in output formats...in short, I can have a script spit out text in a table format, CSV, or even TLN format.

If you haven't yet, check out Mark Woan's JumpLister...it's at version 1.0.5, and does a great job of parsing not only the LNK streams, but also the DestList stream (partial structure of which was first publicly documented here).  It also maps the AppId to an application name...a list of which can be found here, and here. 

Another use I've found for this code is Windows 8 forensics.  I've had a VirtualBox VM of Windows 8 Dev Build running, but recently set up a laptop (wiped XP off of it forever) to dual boot Win7 & 8, so that I could look at some of the various artifacts available, such as wireless networks within the Registry, the use of a Windows Live account to log into Win8, and the Jump Lists...yep, Win8 uses Jump Lists and at this point, they appear to be consistent in format with the Win7 Jump Lists.

Speaking Engagements
My upcoming speaking engagements include the DoD CyberCrime Conference (the conference even has a Facebook page), where I'll be presenting on Timeline Analysis.  I've also submitted to the CfP for the SANS Forensic Summit this next summer (topic: Windows 7 Forensic Analysis), so we'll see how that goes.

Some folks are aware that I recently changed positions, and I'm now with Applied Security, Inc.  My new title is "Chief Forensics Scientist", and yes, it is as cool as it sounds.  We do DF analysis of systems and mobile devices for our customers, focus on proactive security in order to promote immediate (as opposed to "emergency") response, and provide in-depth, focused DFIR training.  As part of DF analysis, we also do research-type engagements..."how does this affect that, and what kinds of traces does it leave?"  Pretty cool stuff.

Part of the work we do involves mobile devices, which is not something I'd really had an opportunity to dig into...until now.  Well, I take that back...in the upcoming WFA 3/e (due out on 7 Feb 2012, I'm told...and I've been told folks are already ordering it!), I do mention examining application files, to include backups of mobile devices and smart phones.  These backups...whether via the Blackberry Desktop Manager or iTunes (for iPhones, iTouch devices, or iPads) can contain a good deal of valuable data.  Again...I do not talk about examining the devices, but instead point out that the backup files may be valuable sources of data.

To kind of dabble in mobile device forensics a bit, I recently pulled an old Blackberry 7290 out of mothballs, powered it up and began running through passwords I may have used to lock it.  As it wasn't on the any cellular network and didn't have WiFi capability, it was effectively isolated from any network.  Once I unlocked it, I downloaded the Blackberry Desktop Manager and used it to backup the device, creating a .ipd file.  I then downloaded Elcomsoft's Blackberry Backup Explorer (trial available) and ran that, to pull up old SMS texts, emails, etc. It was pretty interesting the things that I found...kind of a blast from the past.  What I saw got me to thinking about how useful this stuff could be with respect to DF analysis in general.

I should point out that Elcomsoft also has an iOS forensic product (restricted to special customers), as well as a number of password cracking products.

I also gave Reincubate.com's Blackberry Backup Extractor a shot, as well.  The unregistered version of the tool only converts the first 5 entries in any database it finds, and the output is Excel spreadsheets placed in various folders, depending upon the database that's parsed.

Reincubate also has an iPhone Backup Extractor product.

One tool I'm aware of for parsing .ipd files that I haven't tried yet is MagicBerry.

I also wanted to see how JavaLoader worked against the Blackberry device itself, so I installed all of the necessary dependencies and ran that tool...pretty cool stuff.  I dumped device information, the event log, as well as directory listings, directly from the device.  Now, keep in mind, this is not particularly what one would call "forensically sound", but it is a way to gather additional information from the device after you've followed and documented a more stringent procedure.

Some lessons learned with the Blackberry...at this point, if I don't have the password for the device, I'm not getting anywhere.  I couldn't even create a backup/.ipd file for the device if I didn't have a password.  However, I could access the .ipd file with the tools I mentioned without having the password.  This is very useful information if you find that a user has the Blackberry Desktop Manager installed, and has created one or more .ipd files.

Something else that may be of interest to an examiner is that when I start the BB Desktop Manager, with no device connected to my system, the UI has information about the device already displayed.  This has to be stored somewhere on the system...I just haven't found it yet.  I've talked to some LE who like to boot the image they're analyzing and capture screenshots for use during court proceedings...this might be a very useful technique to use.

So, if you're conducting an exam and find that the user had the BlackBerry Desktop Manager installed, and you find an .ipd file (or several files), depending upon the goals of your exam, it may be well worth your time to dig into that backup.

In some ways, this is a pretty timely post, given this FoxNews article...seems that old hard drives aren't the only source of valuable information.

Online DFIR Meetups
Tonight (Thu, 15 Dec) at 8pm EST is the first Online DFIR Meetup, hosted by Mike Wilkinson.  Stop by and check it out...Mike and I will be presenting during this first meetup.

I think that we need to come up with a good hashtag for the event, particularly something that's unique to the event.

Future of IR
If you haven't already, check out the Carbon Black white paper  on the future of IR, by moving from a purely response posture to a proactive, incident preparedness posture.

Moving to a proactive posture just makes sense for a lot of reasons.  First, it doesn't matter which annual report you read...Verizon, Mandiant, TrustWave...they all pretty much state that it doesn't matter who or where you are...if you have a computer connected to the Internet, you will be compromised at some point.  In fact, you may very likely already have been compromised; you may simply not realize it yet.  Second, if all of the studies show that you're gonna get punched in the face, why keep your hands down?  Why not put on head gear, get into a good stance, and get your hands up?  If it's gonna happen, why not be ready for it, and be able to react to minimize the effects?  Finally, there are a lot of regulatory bodies out there that are all telling the organizations that they oversee that they have to take a more proactive approach to security.  Paragraph 12.9 of the PCI DSS states that organizations subject to the PCI will have (as in, "thou shalt") an incident response capability, and the subparagraphs provide additional details.

At this point, one would think that there's enough reason to have an IR capability within your organization, and be ready.  One would think...

Now, does a tool like Cb obviate the need for that response capability?  I mean, if you're able to VPN into a system and diagnose and scope an incident within minutes, does that mean we'll no longer need to do DFIR?

No, not at all.  What Cb does bring to the table is a solution for rapidly triaging, scoping, and responding to an incident; however, it does NOT obviate the need for dedicated analysis.  Once the incident has been scoped, you can then target the systems from which you need to acquire data...dumps of physical memory, selective files, or acquire full images.

As a consultant, I can see the immediate value of Cb.  The traditional "emergency response" model dictates that someone be deployed to the location, requiring the expense of last minute travel and open-ended lodging arrangements.  There's also the "cost" of the time it takes for an analyst to arrive on-site.  Remember, costs are multiplied (travel, lodging, hourly rate, etc.) for multiple analysts. 

Let's say I have a customer who has several sensors rolled out and their own internal Cb server.  With their permission, I could VPN into the infrastructure and access the server via RDP, pull up the Cb interface and being investigating the incident while we're on the phone.  Based on what is available via Cb, I could begin answering questions in very short order, with respect to the severity and scope of the issue.  I could also obtain a copy of any particular malware that is involved in the incident and send it to a malware analyst so she can rip it apart (if such activity is within scope).   Having deployed Cb, the customer has already decided to be proactive in their security posture, so we can have local IT staff immediately begin isolating and acquiring data from systems, for analysis.

So, this is the difference between the traditional "emergency response", and the future of IR (i.e., immediate response).  And yes, this is only true if you've already got Cb installed...but, as described in the white paper, Cb is still useful if it is installed after the incident.

Now, Cb also does not obviate the need for working with customers and developing relationships, so don't think that someone's going to arrive on-site, install something on your network, poke a hole in your perimeter, and you never see them again.  Rather, deploying Cb requires that an even stronger relationship be built with the customer, for two reasons.  First, being proactive is an entirely new posture for many organizations, and can require something of a shift in culture.  This is new to a lot of organizations, and new things can be scary.  Organizations who recognize the need for and are open to change are still going to tread lightly and slowly at first.

Second, Cb itself is new.  However, Cb as a number of case studies behind it already that not only demonstrate its utility as an immediate response tool, but also as a tool to solve a variety of other problems.  So, organizations rolling out Cb are going to need some help in identifying problems that can be solved via the use of Cb, as well as how to go about doing so.

During the recent SANS360 event, Mike Cloppert (see Mike's Attacking the Kill Chain post) suggested that rather than competing with an adversary on their terms on your infrastructure, that we need to change the playing field and make the adversary react to us.  With only 6 minutes, Mike didn't have the time to suggest how to do that, but Cb gives you that capability.  Cb allows you to change the IR battlefield all together.

File Extension Analysis
I posted a HowTo on file extension analysis a bit ago, and as something of a follow up, I've been working on an article for a Microsoft portal.

I guess what I find most interesting about this post is that even though I see the question that spawned the post asked in online forums and lists, the blog post doesn't have a single comment.  You'd think that as many times as I've seen this in lists and forums, someone would have looked at the post, and maybe found it useful.  Well, I tried the "HowTo" approach to the blog posts, and that didn't seem to be too well received...

Contributing
Rob Lee recently had a very thought provoking post to the SANS Forensics blog titled How to Make a Difference in the Digital Forensics and Incident Response Community.  In that article, Rob highlights the efforts of Kristinn Gudjonsson in creating and developing log2timeline, which is a core component of the SIFT Workstation and central to developing super timelines.

I love reading stuff like this...it's the background and the context to efforts like this (the log2timeline framework) that I find very interesting, in much the same way that I use an archeological version of the NIV Bible to get social and cultural background about the passages being read.  There's considerable context in the history of something, as well as the culture surrounding it and the efforts it took to get something going, that you simply don't see when you download and run the tool.  As an example, Columbus discovering the Americas isn't nearly as interesting if you leave out all of the stuff the came before.

However, I also thought that for the vast majority of folks within the community, the sort of thing that Rob talked about in the post can be very intimidating.  While there are a good number of folks out there with SANS certifications, many (if not most) likely obtained those certifications in order to do the work, but not so much to learn how to contribute to the community.  Also, many analysts don't program.  While the ability to program in some language is highly recommended as a valuable skill within the community, it's not a requirement.

As such, it needs to be said that there are other ways to contribute, as well.  For example, use the tools and techniques that get discussed or presented, and discuss their feasibility and functionality.  Are they easy to understand and use?  Is the output of the tool understandable?  What were your specific circumstances, and did the tool or technique work for you?  What might improve the tool or technique, and make it easier to use?

Another way to contribute is to ask questions.  By that, I'm not suggesting that you run a tool and if it doesn't work or you don't understand the output, to then go and cross-post "it don't work" or "I don't get it" across multiple forums.  What I am saying is that when you encounter an issue of some kind, do some of your own research and work first...then, if you still have a question, ask it.  This does a couple of things...first, it makes others aware of what your needs are, providing the goals of your exam, what you're using to achieve those goals, etc.  Second, it lets others see what you've already done...and maybe gives them hints as to how to approach similar problems.  If nothing else, it shows that you've at least attempted to do your homework.

A reminder: When posting questions about Windows, in particular, the version of Windows that you're looking at matters a great deal.  I was talking to someone last night about an issue of last access time versus last modification time on a file on a Windows system, and I asked which version of Windows were we talking about...because it's important.  I've received questions such as, why are there no Prefetch files on a Windows systems, only to find out after several emails being exchanged that we were talking about Windows 2008.

Post a book or paper review; not a rehash of the table of contents, but instead comment on what was valuable to you, and how you were able (or unable) to use the information in the book or paper to accomplish a task.  Did what you read impact what you do?

I think that one of the biggest misconceptions within the community is that a lot of folks feel that they're "junior" or don't have anything to contribute...and nothing could be further from the truth.  None of us has seen everything that there is to see, and it is very likely that someone working an exam may run across something (a specific ADS, a particular application artifact, etc.) that few have seen before.  As such, there's no reason why you can't share what you found...just because one person may have seen it before, doesn't mean that everyone has...and God knows that many of us could simply use reminders now and again. Tangential to that is the misconception that you have to expose attributable case data to share anything.  Nothing could be further from the truth.  There are a number of folks out there in the community that share specific artifacts without exposing any attributable case data.

SANS360
Speaking of Rob Lee...

I'll be in DC on Tuesday night at the SANS360 Lightning Talk event; my little portion is on accessing VSCs.  If you can't be there, register for the simulcast, and follow along on Twitter via the #SANS360 hashtag.

Bulk_Extractor Updates
Back during the OSDFC this passed summer, I learned about Simson Garfinkel's bulk_extractor tool, and my first thought was that it was pretty cool...I mean, being about to just point an executable at an image and let it find all the things would be pretty cool.  Then I started thinking about how to employ this sort of thing...because other than the offset within the image file of where the artifact was found, there really wasn't much context to what would be returned.  When I was doing PCI work, we had to provide the location (file name) where we found the data (CCNs), and an email address can have entirely different context depending on where it's found...in an EXE, in a file, in an email (To:, From:, CC: lines, message body, etc.).

Well, I haven't tried it yet, but there's a BEViewer tool available now that reportedly lets you view the features that bulkextractor found within the image.  As the description says, you have to have bulk_extractor and BEViewer installed together.  This is going to be a pretty huge leap forward because, as I mentioned before, running bulk_extractor by itself leaves you with a bunch of features without any context, and context is where we get part of the value of data that we find.

For example, when talking about bulk_extractor at OSDFC, Simson mentioned finding email addresses and how many addresses you can expect to find in a fresh Windows installation.  Well, an email address will have very different context depending on where it's found...in an email To:, From: or CC: block, in the body of an email, within an executable file, etc.  Yes, there is link analysis, but how to you add that email address to your analysis if you have no context.  The same is true with PCI investigations; having done these in the past, I know that MS has a couple of PE files that contain what appear to be CCNs...sequences of numbers that meet the three criteria that examiners look for with respect to CCNS (i.e., length, BIN, Luhn check).  However, these numbers are usually found within a GUID embedded in the PE file.

As such, BEViewer should be a great addition to this tool.  I've had a number of exams when I've extracted just unallocated space or the pagefile, and run strings across it just to look for specific things...but something like this would be useful to run in parallel during an exam, just to see what else may be there.

FOSS Page
While we're on the topic of tools, you may have noticed that I've made some updates to my FOSS page recently, mostly in the area of mobile device forensics.  My new position provides me with more opportunities with these devices, but I have talked about examining mobile device backups on Windows systems (BlackBerrys backed up with the Desktop Manager, iPhones/iPads backed up via iTunes, etc.) before, and covered some FOSS tools for accessing these files in WFA 3/e. 

These tools (there is a commercial tool listed, but it has a trial version available) can be very important.  Say that you have a friend that backs up their phone and has lost something...you may be able to use these tools to recover what they lost from the backup.  Also, in other instances, you have find data critical to what you're looking at in the phone backup.

Simulations
Corey had a great post recently on keeping sharp through simulations; this is a great idea.  Corey links to a page that lists some sites that include sample images, and I've got a couple listed here.  In fact, I've not only used some of these myself and in training courses I've put together, but I also posted an example report to the Files section of the Win4n6 Yahoo Group ("acme_report.doc").

Another opportunity that you have available for analysis includes pretty much any computer system you have available...your kids, friends, spouse, etc.  Hey, what better source for practicing is there than someone right there...say, they get infected with something, and you're able to acquire and analyze the image and track the issue back to JavaScript embedded in a specific file?

How about your own systems?  Do you use Skype?  Acquire your own system and see how well some of the available tools work when it comes to parsing the messages database...or write your own tools (Perl has a DBI interface for accessing SQLite databases).  Or, install a P2P application, perform some "normal" user functions over time, and then analyze your own system.

Not only are these great for practice, but you can also make a great contribution to the community with your findings.  Consider trying to use a particular tool or technique...if it doesn't work, ask why in order to clarify the use, and if it still doesn't work, let someone know.  Your contribution may be pointing out a bug.

Mall-wear Updates
I ran across an interesting tweet one morning recently, which stated that one of the annoying fake AV bits of malware, AntiVirii 2011, uses the Image File Execution Options key in the Registry.  I thought this was interesting for a number of reasons.

First, we see from the write-up linked above that there are two persistence mechanisms (one of the malware characteristics that we've talked about before), the ubiquitous Run key, and this other key.  Many within the DFIR community are probably wondering, "why use the Run key, because we all know to look there?"  The answer to that is...because it works.  It works because not everyone knows to look there for malware.  Many DFIR folks aren't well versed in Registry analysis, and the same is true for IT admins.  Most AV doesn't automatically scan autostart locations and specifically target the executables listed within them (I say "most" because I haven't seen every legit AV product).

Second, the use of the Image File Execution Options key is something that I've only seen once in the wild, during an incident that started with a SQL injection attack.  What was interesting about this incident is that none of the internal systems that the bad guy(s) moved to had the same artifacts.  We'd find one system that was compromised, determine the IOCs, and search for those IOCs across other systems...and not find anything.  Then we'd determine another system that had been compromised, and find different IOCs.

Analysis
I ran across this article that talks about the analysis of an apparent breach of an Illinois water treatment facility, via Twitter.  While the title of the article calls for "analytical competence", the tweet that I read stated "DHS incompetence".  However, I don't think that the need for critical and analytical thinking (from the article) is something that should be reserved for just DHS.

The incident in question was also covered here, by Wired.  The Wired article really pointed out very quickly that the login from a Russian-owned IP address and a failing pump were two disparate events that were five months apart, and were correlated through a lack of competent analysis.

In a lot of ways, these two articles point out a need for reflection...as analysts, are we guilty of some of the same failings mentioned in these articles?  Did we submit "analysis" that was really speculation, simply because we were too lazy to do the work, or didn't know enough about what we were looking at to know that we didn't know enough?  Did we submit a report full of rampant speculation, in the hopes that no one would see or question it?

It's impossible to know everything about everything, even within a narrowly-focused community such as DFIR.  However, it is possible to think critically and examine the data in front of you, and to ask for assistance from someone with a different perspective.  We're much smarter together than we are individually, and there's no reason that we can't do professional/personal networking to build up a system of trusted advisers.  Something like the DHS report could have been avoided using these networks, not only for the analysis, but also for peer review of the report.

MaaS
For quite a while now, when I've been presenting or discussing the state of DFIR with others, I've talked about how attackers and threat actors have long since moved away from digital joyriding on the Information Superhighway (how's that for a cliche?) and how cybercrime is more targeted and focused, and has an economic stimulus.  In many cases, I've mentioned this in the "us-and-them" context, how those of us on one side of the fence are faced with strict (or more often, no) budgets, while those that we're working against have a monetary motivation to not only innovate, but to do so rapidly...to fail quickly, learn and move on.

Back in the day, I knew some folks who wrote custom rootkits, albeit for a fee (I've always wanted to use albeit in a sentence).  That's right, skilled programmers who were tired of the pointy-haired bosses that they worked for, so they hung out their own cyber shingle and began writing custom rootkits for a fee, in order to support themselves.

I ran across this HelpNet Security article that describes the pricing structure for a number of available services, including infections.

Malware (or "mallware", but you'd have to take a drink...)
This section's title is based on my mispronunciation of the word "malware" (I was saying "mall-wear") during my presentation at OSDFC this past June, which led Cory Altheide to start a drinking game.  And here I was thinking that it was my mad presentation skillz that got the back of the room excited.  ;-)

Anyway, Claus is back with a great post on some malware detection resources, stuff you can use particularly if your analysis systems are "air-gapped" from other networks, and in particular the Internet itself.  It's always good to have resources like these in your toolkit, or just your back pocket, as you never know when you're going to need them.

Thoughts on WFP
Chris Pogue (@cpbeefcake on Twitter) has a new post up on the SpiderLabs blog, entitled "Manipulating Windows File Protection and Indicators of Compromise".  As you can see in his post, it is based in part on a discussion Chris and I engaged in a while back regarding the topic of malware and disabling WFP.


Chris makes the following statement in his blog post, regarding IOCs:


"Apart from dllhost.exe being present, apart from the timeline, there were not any IOCs of modification."

I would suggest that beyond what Chris mentions, there are IOCs of this sort of activity, particularly the specific activity that Chris outlined in his post.  Chris even goes so far as to mention in his post that I include a discussion of this topic in WFA 2/e, on pp.328-330; on those pages I point out a means for detecting files that were changed using the process that Chris describes in his post...in short, identifying some IOCs of this sort of activity.  Chris even describes how the target file (that was modified) has a different hash after the modification.  While there may not be anything immediately obvious in the volatile data from a compromised system, there is definitely at least two IOCs; MFT entries Chris describes, and the "new" hash of the modified file.

One of the steps I included in my malware detection checklist is to run a "WFP check".  Essentially, what this is is a Perl script that I wrote that accesses a mounted image, goes into the system32\dllcache directory, gets all of the names and hashes of the files.  Then, it goes into the system32 directory, locates any file of the same name as one of the ones found in the dllcache dir, gets the hash and performs a comparison.  I decided to limit the second-level search to the system32 directory because there a number of false positives on systems that have updates...you'll get a number of "hash mismatch" messages for older versions of files that have since been updated.

I haven't posted the Perl script that I use because, to be honest, I haven't seen where anyone's interested in this sort of capability.  I use it as part of my malware detection process...it's quick, it's easy to use, and it gives me a quick look at something that could very easily turn up a smoking gun, if not the smoking gun.  Another reason I haven't released the script on a wide-spread basis is that I have found a lot of folks who...have had trouble...using some of my more esoteric tools.  I recently had someone ask for a copy of mbr.pl, and once they had it, they ran it against a .vmem file.  And when many folks can't get the tool to work as it should, or as advertized, they tend not to contact me about the issue.

Further, in my experience, this issue (WFP being disabled) isn't one that's easily understood by a number of analysts, and when the topic is first presented, it can lead to a good bit of confusion.  For one, WFP is not intended to be a 'security' mechanism...rather, it is intended to protect the user from inadvertent actions from...well...the user.  As Chris pointed out in his post, the capability to easily circumvent this functionality has existed for some time.  Also, understanding how the detection process makes use of available IOCs can also lead to confusion.

Virtual Systems
For anyone who's done any testing of any kind, in particular of exploits and compromises, it's always nice to have some virtual systems around that you can test against.  For folks who use VMWare and VirtualBox, there are sites where you can go and download virtual machines...but most of them are non-Windows based systems.  Well, if you're using VPC, you can go to Microsoft and download IE App Compatible VHD systems; these are intended for testing web sites, but I'm sure that even with the baked-in operation limits that Claus mentions, these are a lot more accessible than a full-on MSDN subscription (particularly because several of the systems are fully patched up to a certain date).

Linkz
Here's a good post on CD/DVD Forensics from one of the "Hacking Exposed: Computer Forensics" authors.  One thing that really stood out about this post was the statement:

At G-C (my company) we try to have an internal training topic for about 30 minutes to an hour every day (that I'm in the office).

This is an excellent way to share information, particularly about exams and anything new that some has learned...or even something that's not new.

Ken Johnson has posted some really good information regarding a Windows 8 forensic overview.   Not only is this just some great info, but it's very timely...I'm putting together a submission for the 2012 SANS Forensic Summit, for a presentation where I will be discussing forensic analysis of Windows 7 systems, with a good deal of information regarding Windows 8, as well.  Take a look at what Ken mentions about the Windows 8 File History feature...pretty interesting stuff.  With that, and accessibility of "the cloud", incident responders may have something of a scoping challenge on their hands.

What's Old is New
I caught a thread on a popular list recently regarding the topic of ADSs...NTFS alternate data streams.  It's simply amazing to me, given the amount of information available on the topic,that more folks don't know about them.  What this can lead one to think is that if folks (IT/IR staff, forensic analysts, etc.) don't know about these artifacts, then they may not be looking for them.

After all, the capability to create arbitrary ADSs has existed in NTFS since the early days of the file system.  Until Vista, there were no tools native to the platform that allowed admins to view the existence of arbitrary ADSs...and even then, it's a CLI capability (i.e., dir /r).  Tools and even scripts can be launched from within ADS, and the toolkit for the Poison Ivy Trojan includes an option to use ADSs. 

Books
I was on Amazon recently, and ran across the listing for WFA 3/e.  I'm told by the publisher that this book is due to be out on or about 7 Feb 2012, and I'm really looking forward to it.

However, there are a couple of things I wanted to address about the book.  First, this one looks almost exactly like WFA 2/e.  I've already run into instances where owners of WFA 2/e don't pick up on the differences in cover art between that book and WRF.  Now, the third edition is coming out, and it's going to be even harder to tell which one you have.

Second, the third edition is NOT (I repeat...NOT) intended to replace the second edition...instead, it's a companion book.  That is, if you have one, you'll want the other.  The third edition focuses much more on Windows 7, and includes several new topics.  After all, there was really no point in reprinting the content regarding the PE file format if it didn't change, right?

Registry Analysis
I ran across this interesting blog post recently that discusses how the TypedURLs key can be populated, depending upon the version of IE used.  This simply shows, once again, that the version of Windows (and now IE) that you're dealing with is important, particularly when you're looking for assistance.

Part 2 of this article states that it is, "...becoming increasingly common for some of the TypedURLs entries to be written by malware and not typed by the user at all."  Interesting.  So the question then becomes, when conducting analysis, how do you tell the difference?

Speaking
I recently returned from visiting with the great folks at the CT HTCIA.  They had invited me up to speak at their meeting a while back, and in order to keep costs down, I did an up-and-back trip.  I gave two presentations, each about an hour in length...the first was on using RegRipper, the second was on understanding malware (via the four characteristics I've talked about in this blog).  Overall, it was was a great opportunity for me to get out and meet some new folks and see some faces I hadn't seen in a while. 

As to other speaking engagements, I'll be taking part in the SANS360 DFIR Lightning Talks (my job title is incorrect on the page...) event on 13 Dec.  This should be very interesting.  I've enjoyed some of the changes to the conference format that I first began seeing in 2008 through the SANS Forensic Summit, particularly the panel format.  This is another new addition...10 speakers, each with 360 seconds to present on a topic. 

Finally (for now, anyway), I'll be presenting on timeline analysis at DC3 in January, and I recently saw that SANS now has the CfP for the SANS Forensics Summit posted.  This is a different approach from last year, but I'm going to submit, hope that I get accepted, and hope to see you in Austin, TX, next summer!

RegRipper
Speaking of RegRipper...to get your very own copy of RegRipper, go here and get the file "RR.zip".  To get the latest and greatest user-submitted plugins, go here.  I know Rob has updated the SANS SIFT Workstation to include the latest and greatest plugins in that distribution.

Oops, he did it (again)...
I caught this very interesting article by Mike Tanji (Kyrus CSO) recently...if you haven't read it, it's an excellent article, largely because he's so on point.  I particularly agree with his statement about critical thinking, particularly in light of this OverHack blog post that describes a phenomenal leap in "analysis" (sort of brings Mike's whole "hyperbole" statement into perspective), and it's inevitable results.

Another part of Mike's article that I agree with wholeheartedly is specificity of language.  Like Mike and others, I see a lot of this (or lack thereof) within our community.  I recently received an email asking for assistance with Registry analysis, and the question revolved around the "system key".  Not to be a "word n@zi", but it's a hive, not a key.  Registry keys are very specific objects and structures, and are different from Registry values.  To Mike's point, other professions have that specificity of language...all doctors know what "stat" means, all lawyers know what "tort" means.  Like other professions and organizations, DFIR folks are often embattled with marketing forces (what does the over-used term "APT" really mean?), but we still simply do not have enough attention paid within our community to agreed-upon terminology.

Linkz
Here are some links I've pulled together since my last post...

Claus is back with some updates to MS Tools and some other software stuff...

Andreas updated his EvtxParser Perl library, to fix an issue with memory.

Dave posted on extending RegRipper...again.  I read the blog post twice, and it seems like the "they see me rollin', they hatin'" blog post of the month.  ;-)

Corey's got another great post up...one of the things I like about it is that he is the first person (that I'm aware of) who's downloaded the malware detection checklist I posted who's actually provided feedback on it.  This is just another example of Corey's continuing contributions to the community.

Windows Security Descriptor Parser (Perl) - found here.

PDF Analysis - PDF Analysis using PDFStreamDumper

Check out Chris Taylor's blog...in his first post, he mentions selling out, but to be honest, he's got some really good stuff there.  I think like many (myself included), he's found the benefit of sharing findings, thoughts and ideas, not just as a way of keeping your own notes, but also getting input from others.

Meetup
Finally, don't forget about next week's NoVA Forensics Meetup.  Time and location haven't changed...Sam Brothers will be presenting on mobile forensics.

Online Meetups
Usually when I ask online for input into the NoVA Forensics Meetups, I most often get back responses from folks who have not attended the meetups, but want to, and most of those responses are from people who live too far away to attend the meetups...so they ask me when I'm going to start a meetup in their area.  I had a chance to speak with Mike Wilkinson (teaches at Champlain College) while we were both out at PFIC 2011, and not long ago, Mike posted a survey to see if folks would be interested in attending or presenting at online meetups.  Mike posted the results of the survey recently, and posted a schedule of presentations, as well.

Based on the results, Mike will be running the online meetups on the third Thursday of each month, at 8pm EST, starting on 15 Dec 2011.

NoVA Meetup
While we're on the topic of the meetups, I thought I'd throw out a reminder to everyone about the next NoVA Forensics Meetup on Wed, 7 Dec.  I'm looking forward to this one, as Sam Brothers will be presenting on mobile forensics.

Case Notes
Corey posted a narrative version of case notes for an exam he recently worked.  Corey does a great job of walking the reader through the process of discovery during the exam, and if you look at what he's doing, you'll see his process pretty clearly, starting with his goal of determining the IIV for the malware infection.  He even went so far as to post his investigative plan. 

Another aspect of Corey's post that I really liked was this:

Some activities were conducted in parallel to save time.

I can't tell you the number of times I have seen examiners with several systems (a Mac Pro Server and two MacBook Pro systems) do nothing but start a CCN search against the one image they have, using EnCase, and state that they can't do anything else because the image is in use.  When you've got multiple systems, you can easily extract designated data from within the image before subjecting it to a long-running process (AV or CCN scans, etc.)...or simply create a second working copy of the image.  Or, instead of starting the long-running processes at the beginning of your day, start them when you know you're going to have some down-time, or even before you leave the lab.

As part of his analysis process, Corey did two other really impressive things; he made use of the tools he had available, and he created a timeline.  One of the things Corey mentioned in his post was that he created a batch file to run specific RegRipper/rip.exe plugins and extract specific data; this is a great use of available tools - not just RegRipper, but also batch file scripting - to get the job done.  Also, Corey walks through portions of the timeline he created, opening it in Excel and highlighting (in yellow or red) specific entries. 

I'll leave the rest of the post to the reader...great job, Corey!

Tools
Scalpel was updated a bit ago...if you do any file carving, check it out.

After I posted my macl.pl tool, I received an email regarding wwtool v0.1, a CLI tool for listing available wireless networks, from WiFiMafia.  While not specifically a tool for DFIR work, I can easily see how this would be useful for assessment work.

Geolocation Information
Chad had an excellent post recently regarding geolocation data; besides mobile devices, Windows systems can potentially contain two sources of geolocation information.  One is the WiFi MAC addresses that you can retrieve from the Registry...once you do, you can use tools like macl.pl to plot the location of the WAP on a map.  Second, some users back up their smartphones to their desktop, using iTunes or the BlackBerry Desktop Manager...you may be able to pull geolocation information from these backups, as well.  Check out the FOSS page for some tools that may help you extract that information.

Interviews
Like most analysts, I like to see or hear what other analysts are seeing, and how they're addressing what they're seeing.

Ryan Washington's CyberJungle interview (episode 238) - Ryan was interviewed about his PFIC 2011 presentation about how forensicators can discover artifacts of anti-forensic attempts.  As with his presentation, Ryan discusses not just hiding from the user, but also how even seasoned pen testers leave tracks on systems, often when they try very hard to be stealthy.

I remember a discussion I had with members of the IBM ISS X-Force a while ago regarding an Excel exploit that allowed them access to a system.  I asked about artifacts, and was told that there were none.  I asked explicitly that if the exploit included sending a malicious Excel file and having the user open it, wouldn't the Excel spreadsheet be an "artifact"?  After all, many a forensicator has nailed down a phishing attack by locating the malicious PDF file in the email attachment archive.

Interestingly, Ryan also mentions digital "pocket litter", which isn't something that many folks who try to hide their activities are really aware of...

Chris Pogue's Pauldotcom interview - episode 267, starts about 56:33 into the video; Chris talks about Sniper Forensics; what it means, where we are now, where we need to go, all with respect to DFIR.  Chris also references some of the same topics that Ryan discussed, and in some cases goes into much more technical detail (re: discussion of MFT attributes).  Chris talks about some of the things that he and his team have seen, including MBR infectors, and memory analysis.

Another cool thing about the interview is that you get to see Chris's office, and hear his cell phone ring tone!

More APT Confusion
I ran across an interesting article on TechTarget recently, which states that due to confusion over the APT threat, which "...leads companies to often misappropriate resources, making unnecessary or uninformed investments."

Really?  I remember going on-site to perform IR back in 2006 when I was with the ISS ERS Team, and understanding how the customer knew to contact us.  They had three copies of ISS RealSecure.  All still in their shrink-wrap.  One was used to prop a door open.  So what I'm saying is that, with respect to the TechTarget article, it isn't necessarily confusion over what "APT" means that leads to "uninformed investments", although I do think that what most organizations find themselves inundated with, with respect to marketing, does lead to significant confusion.  I think it's not understanding threats in general, as well as the panic that follows an incident, particularly one that, when investigated, is found to have been going on for some time (weeks, months) prior to detection.

Context...no, WFP.  Wait...what?
When presenting on timeline analysis, or most recently at PFIC 2011, Windows forensic analysis, one of the concepts I cover is context within your examination.  Recently, Chris posted on the same topic, and gives a great example.

Something about the post, and in particular the following words, caught my eye:

"...manually went through the list of running services using the same methodology...right name, wrong directory, or slightly misspelled name, right directory (for the answer to why I do this, check this out... http://support.microsoft.com/kb/222193)."

Looking at this, I was a little confused...what does Windows File Protection (WFP) have to do with looking for the conditions that Chris mentioned in the above quote?  I mean, if a malware author were to drop "svch0st.exe" into the system32 directory, or "svchost.exe" into the Windows directory, then WFP wouldn't come into play, would it?

What's not mentioned in the post is that, while both of the conditions are useful techniques for hiding malware (because they work), WFP is also easily "subverted".  The reason I put "subverted" in quotes is that it's not so much a hack as it is using an undocumented MS API call.  That's right!  To break stuff, you don't have to break other stuff first...you just use the exit ramp that the vendor didn't post signs for.  ;-)

Okay, to start, open WFA 2/e and turn to pg. 328.  Just below the middle of the page, there's a link to a BitSum page (the page doesn't seem to be available any longer...you'll need to look here) that discusses various methods for disabling WFP...one that I've seen used is method #3; that is, disable WFP for one minute for a particular file.  This is something that is likely used by Windows Updates.  This CodeProject page has some additional useful information regarding the use of the undocumented SfcFileException API call.

To show you what I mean by "undocumented", take a look at the image to the right...this is the Export Address Table from sfc_os.dll from a Windows XP system, via PEView.  If you look at the Export Ordinal Table, you'll see only the last 4 functions listed, by name.  However, in the Export Address Table, you don't see names associated with several of the functions.

Note that at the top of the BitSum page (archived version), several tools are listed to demonstrate some of the mentioned techniques.  As the page appears to be no longer available, I'm sure that the tools are not available either...not from this site, anyway.

Mandiant has a good example of how WFP "subversion" has been used for malware persistence; see slide 25 from this Mandiant The Malies presentation.  W32/Crimea is another example of how disabling WFP may be required (I've seen the target DLL as a "protected" file on some XP systems, but not on others...).  This article describes the WFP subversion technique and points to this McAfee blog post.

Yes, Virginia...it is UTC
I recently posted a link to some of my timeline analysis materials that I've used in previous presentations.  I've mentioned before that I write all of my tools to normalize the time stamps to 32-bit Unix time format, based on the system's interpretation of UTC (which, for the most part, is analogous to GMT).  In fact, if you open the timeline presentation from this archive, slide 18 includes a bullet that states "Time (normalized to Unix epoch time, UTC)".

I hope this makes things a bit clearer to folks.  Thanks!


Intel Sharing
Not long ago, I posted about OpenIOC.org, and recently ran across this DarkReading article that discusses intel sharing. Sharing within the community, of any kind, is something that's been discussed time and time again...very recently, I chatted with some great folks at PFIC (actually, at the PFIC AfterDark event held at The Spur in Park City) about this subject.

In the DarkReading article, Dave Merkel, Mandiant CTO, is quoted as saying, "There's no single, standardized way for how people to share attack intelligence."  I do agree with this...with all of the various disparate technologies available, it's very difficult to express an indicator of compromise (IoC) in a manner that someone else can immediately employ it within their infrastructure.  I mean, how does someone running Snort communicate attack intel to someone else who monitors logs?

I'd suggest that it goes a bit further beyond that, however...there's simply no requirement (nor apparently any desire) for organizations to collect attack intelligence, or even simply share artifacts.  Most "victim" organizations are concerned with resuming business operations, and consulting firms are likely more interested in competitive advantage.  At WACCI 2010, Ovie talked about the lack of sharing amongst analysts during his keynote presentation, and like others, I've experienced that myself on the teams I've worked with...I wouldn't have any contact with another analyst on my team for, say, 3 months, and after all that time, they had nothing to share from their engagements.  We took steps to overcome that...Chris Pogue and I wrote a white paper on SQL injection, we developed some malware characteristics, and I even wrote plugins for RegRipper.  I've seen the same sharing issue when I've talked to groups, not just about intel sharing, but also about the forensic scanner. 

I think that something like OpenIOC does provide a means for describing IoCs in a manner that can be used by others...but only others with the same toolset.  Also, it is dependent upon what folks find, and from that, what they choose to share.  As an example, take a look at the example Zeus IOC provided at the OpenIOC.org site.  It contains some great information...file names/paths, process handles, etc...but no persistence mechanism for the malware itself, and no Registry indicators.  So, this IoC may be great if I have a copy of IOCFinder and a live system to run it against.  But what happens if I have a memory dump and an acquired image, or just a Windows machine that's been shut off?  Other IoCs, like this one, are more comprehensive...maybe with a bit more descriptive information and an open parser, an analyst could download the XML content and parse out just the information they need/can use.

Now, just to be clear...I'm not saying that no one shares DFIR info or intel.  I know that some folks do...some folks have written RegRipper plugins, but I've also been in a room full of people who do forensic analysis, and while everyone admits to having a full schedule, not one person has a single artifact to share.  I do think that the IoC definition is a good start, and I hope others pick it up and start using it; it may not be perfect, but the best way to improve things is to use them.

DoD CyberCrime Conference
Thanks to Jamie Levy for posting the DC3 track agenda for Wed, 25 Jan 2012.  It looks like there're a number of interesting presentations, many of which all go on at the same time.  Wow.  What's a girl to do?

NoVA Forensics Meetup
Just a quick reminder about the next NoVA Forensics Meetup, scheduled for Wed, 7 Dec 2011, at the ReverseSpace location.  Sam Brothers will be presenting on mobile forensics.

Registry Parsing
Andrew Case, developer of Registry Decoder, recently posted regarding using reglookup for Registry analysis.  There are a number of links in Andrew's post to some of Tim Morgan's papers regarding such topics as looking for deleted Registry keys, so be sure to take a look.

PFIC 2011
I had an opportunity to meet a lot of great folks in Park City, many of whom I had only known about via their online presence.  One of those is fellow DFIR'er and fellow former Marine Corey Harrell. Corey's one of those impressive folks that you want to reach to and find in the community; rather than just sitting quietly, or just clicking "+1" or "Like", Corey goes out and does stuff, a good deal of which he's posted to his blog.

Corey posted his PFIC 2011 Review to his blog recently (Girl, Unallocated posted her thoughts and experiences, as well)...this is great stuff, for a couple of reasons.  First, some conferences, like PFIC, have a number of good topics and speakers, often during the same time slot.  As such, you may not be able to get to all of the presentations that you'd like to, and having someone post their "take-aways" from the presentation you missed is a good way to get a bit of insight beyond simply downloading the slide pack.  Taking that a step further, not everyone can attend conferences, so this gives folks who couldn't attend an opportunity to peek behind the curtain and see what's going on.  Finally, this gets the word out about next year's conference, as well, and may get someone over the hump of whether to attend or not.

DoD CyberCrime
Speaking of presentations, I got word recently that my DoD CyberCrime Conference presentation on timeline analysis on 25 Jan 2012, from 8:30-10:20am.  The last (and first) time I attended DC3 was in 2007, and unfortunately, within less than an hour of finishing my presentation, I was on an incident call, and off the next day to another major city.  Ah...such was the life of an emergency responder.

My timeline analysis presentation (an example of a previous presentation can be found here) is a bit different from most of those that I find available online, in part because I don't focus on using the SANS SIFT Workstation.  That's not to say that SIFT isn't a great resource...because it is.  Rob's done a great job of assembling a range of open source tools, and getting them all set up and ready to use.  However, the approach I tend to take is to start by attempting to engage the audience and discussing with them the reasons why we'd want to do timeline analysis in the first place, discussing concepts such as context and increased relative confidence in the data.  Understanding these concepts can often be what gets folks to see the value of creating a timeline, when "...because this guy said so..." just isn't enough.  From there, we walk through using the tools, and demonstrate how timelines can be used as part of your analysis process...keeping in mind that like any other tool, this is just a tool and needs to be used accordingly.  Creating a timeline when it doesn't make sense to do simply...well...doesn't make sense.

Anyway, I'm really looking forward to this opportunity, and hopefully seeing a bunch of really good presentations, as well.  Looking at the conference agenda as it is so far, it looks like there's a couple of good social events, as well, which will lead to some great networking.

MMPC Updates
The Microsoft Malware Protection Center (MMPC) recently posted regarding some new MSRT definitions, including Win32/Cridex, another bit of malware that steals online banking credentials.  Cridex uses the user's Run key for persistence, and apparently stores data in the Default value of the HKCU\Software\Microsoft\Windows Media Center\ key.  Figure 3 of the MMPC post includes a screen capture of what this data looks like.

Duqu
Although I haven't had an opportunity to analyze a system infected with Duqu, as always, I remain interested in what's out there, particularly from a host-based perspective.  I ran across a set of open source tools for detecting Duqu files (readme here).  There's also the Symantec write-up on Duqu, which is very interesting, as it defines the Duqu "load point", which is a driver loaded as a Windows service, specifically HKLM\SYSTEM\CurrentControlSet\Services\JmiNET3.  Apparently, configuration information is maintained in the FILTER subkey beneath this key.

Interestingly, the load point is described as "JmiNET7.sys", but the Symantec paper goes on to say that the service name is "JmiNET3".

The Symantec paper goes on to describe the loading techniques for the payload loader, and method 3 involves a section within a DLL called ".zdata".

Finally, the Diagnostics section of the paper includes another Registry key that is supposed to indicate an infected system; specifically, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\4\”CFID”.

Anyone interested in learning more about Duqu should take a look at the Symantec paper, as well as anything else that's out there.  There seem to be some interesting (and possibly unique) indicators that you can use to scan your infrastructure for infected systems; per the Symantec paper, part of the Duqu threat involves infostealers.

Tool Updates
There've been some updates to the SysInternals tools recently, in particular to AutoRuns (new v 11.1), including some new autostart locations.  Check them out.

Andreas has updated his Evtx Parser tool (written in Perl), as well.

ImDisk was recently updated to version 1.5.2.

I updated my maclookup.pl WiFi geolocation script to macl.pl.   The previous version of the script used Skyhook to perform lookups, in an attempt to translate a WiFi WAP MAC address (found in the Windows Registry) to a lat/long pair.  I found out recently that this stopped working, so I sought out...and found...a way to update the script.

Reading
The e-Evidence.info what's new site was updated recently, and as always, there's lots of great reading material.  This presentation on using open source tools for digital forensic analysis spends a good couple of slides demonstrating how to use RegRipper.  David Hull has a timeline presentation available that discusses the use of SIFT v2.0 to create super timelines.

NoVA Forensics Meetup Reminder
Don't forget about the meetup tonight...and thanks to David for pointing out my typo on the Meetup Page.

I haven't received any responses regarding a pre-meetup warm-up at a local pub, so I'll look forward to seeing everyone who's attending tonight at 7pm at our location.

I posted the slides for tonight's presentation to the NoVA Forensics Meetup Yahoo group.

SSDs
I was recently asked to write an article for an online forum regarding SSDs.  Up until now, I haven't had any experience with these, but I thought I'd start looking around and see what's already out there so I can begin learning about solid state drives, as they're likely to replace more traditional hard drives in the near future.

In Windows 7, if the drive is an SSD, ReadyBoot and SuperFetch are disabled.

Resources
SSDTrim.com
Andre Ross' post on on the DigFor blog.

OpenIOC
With this M-unition blog post, Mandiant announced the OpenIOC framework web site.  I strongly suggest that before going to the OpenIOC.org site that you read through the blog post thoroughly, so that you understand what's being presented and offered up, and to set your expectations when you go to the site.

What I mean by this is that the framework itself has been around and discussed for some time, particularly through the Mandiant site.  Here is a presentation from some Mandiant folks that includes some discussion/slides regarding the OpenIOC.  There's also been an IOC editor available, which allows you to create IOCs, and now, with the OpenIOC.org site being released, the command line IOC finder tool has been released.  This tool (per the description in the blog post) allows a responder to check one host at a time for the established IOCs.

Fortunately, several example IOCs are also provided, such as this shelldc.dll example.  I tend to believe that this is where the real power of this (or any other) framework will come from; regardless of the type of framework or schema (or standard) used to describe indicators of compromise, the real power is going to come from the ability of #DFIR folks to understand and share these IoCs.  Having a standard for this sort of thing raises the bar for DFIR...not for admission, but it tells everyone where they have to be with respect to their understanding of DFIR activities, because not only will they have to understand what's out there, but they'll have to really understand it in order to be part of the community and share their own findings.

So, in a lot of ways, this is a step in the right direction.  I hope it takes off...as has been seen with GSI's EnScripting and the production of RegRipper plugins, sometimes no matter how useful something is to a small subset of analysts, it's not really picked up by the larger community.

Breach Reporting
There's been some interesting discussion in various forums (G+, Twitter, etc.) lately regarding breach reporting.  Okay, not so much discussion as folks posting links...I do think that there needs to be more discussion of this topic.

For example, much of the breach reporting is centered around actually reporting that a breach occurred. Now, if you read any of the published annual reports (Verizon, TrustWave, Mandiant), you'll see historically that a large percentage of breach victims are notified by external third parties.  These numbers appear to be across the board, as each of the organizations publishing these reports target slightly different customer bases and respond predominantly to different types of breaches (PCI/PII, APT, etc.).

Maybe a legislative requirement for reporting a breach, regardless of how it was discovered, is just the first step.  I mean, I've seen during PCI breaches where a non-attorney executive has stated emphatically that their company would not report a breach, but I tend to think that was done out of panic and a lack of understanding/information regarding the breach itself.  However, if breaches start getting reported, there will be greater visibility into the overall issue, and from there, intelligent metrics can be developed, followed by better detection mechanisms and processes.

With respect to PII, it appears that there are 46 states with some sort of breach notification requirements, and there's even a bill put forth by Sen. Leahy (D-VT) and others regarding a national standard requiring reporting of discovered breaches.

Resources
Leahy Personal Data Privacy and Security Act

Speaking
I've got a couple of speaking engagements coming up that I thought I'd share...

7-9 Nov - PFIC 2011 - I'll be giving two presentations, one on the benefits of using a forensic scanner, and the other, an Introduction to Windows Forensics.  I attended the conference last year, and had a great time, and I'm looking forward to meeting up with folks again.

30 Nov - CT HTCIA - I'm not 100% sure what I'm going to be presenting on at this point...  ;-)  I'm thinking about a quick (both presentations are less than an hour) presentation on using RegRipper, as well as one on malware characteristics and malware detection within acquired images.  I think that both are topical, and both are covered in my books.

Jan 2012 - DoD Cybercrime Conference (DC3) - I'll be presenting on timeline analysis.  I gave a presentation on Registry analysis (go figure, right??) here a long time ago, and really enjoyed the portions of the conference that I was able to attend.  I know that Rob Lee recently gave an excellent webinar on Super Timeline Analysis, but rest assured, this isn't the same material.  While I have provided code to assist with log2timeline, I tend to take a slightly different approach when presenting on timeline analysis.  Overall, I'm looking forward to having a great time with this conference and presentation.  Also, timeline analysis has it's own chapter in the upcoming Windows Forensic Analysis 3/e.

Reading
I've had an opportunity to travel recently, and when I do, I like to read.  Being "old skul" (re: I don't own a tablet...yet), I tend to go with hard copy reading materials, such as magazines and small books.  I happened to pick up a copy of Entrepreneur recently, for a couple of reasons.  First, it's easy to maneuver the reading material in to my seat and stow my carry-on bag.  Second, I think it's a great idea to see how other folks in other business areas solve problems and address issues that they encounter, and to spur ideas for how to recognize and address issues in my own area of interest.  For example, the October issue of the magazine has an article on how to start or expand a business during a recession, addressing customer needs.  In the technical community, this is extremely important.

In that same issue, Jonathan Blum's article titled Hack Job (not the same title in the linked article, but the same content) was interesting...while talking about application security, the author made the recommendation to "choose an application security consultant".  I completely agree with this, because it falls right in line with my thoughts on DFIR work...rather than calling an IR consultant or firm in an emergency, find a "trusted adviser" ahead of time who can help you address your DFIR needs.  What are those needs?  Well, in any organization, regardless of size, just look around.  Do you have issues or concerns with violation of acceptable use policies, or any other HR issues?  Theft of intellectual property? 

If you call a consulting firm when you have an emergency, it's going to cost you.  The incident has already happened, and then you have to work through contracting issues, getting a consultant (or a busload of consultants) on-site, and having to help the responders understand your infrastructure, and then start collecting data.  You maybe paying for more consultants than you need initially, because after all, it is an emergency, and your infrastructure is unknown.  Or, you may be paying for more consultants later, as more information about the incident is discovered.  Also, keep in mind emergency/weekend/holiday rates, the cost of last minute travel, lodging, etc.  And we haven't even started talking about anything the consultants would need to purchase (drives for imaging), or fines you may encounter from regulatory bodies.

Your other option is to work with an trusted adviser ahead of time, someone who's seen a number of incidents, and can help you get ready.  You'll even want to do this before increasing your visibility into your infrastructure...because if you don't have a response capability set up prior to getting a deep view into what's really happening on your infrastructure, you can very easily be overwhelmed once you start shining a light into dark corners.  Work with this trusted adviser to understand the threats you're facing, what issues need to be addressed within your infrastructure and business culture, and establish an organic response capability.  Doing this ahead of time is less expensive, and with the right model, can be set up as a budgeted, predictable business expense, rather than a massive, unbudgeted expenditure.  Learning how an incident responder would address your issue and doing it yourself (to some extent) is much faster (quicker response time because you're right there) and less expensive (if you need analysis done, FedEx is much less expensive than last minute plane flights, lodging, rental cars, parking, etc., for multiple consultants).  Working with a trusted adviser ahead of time will help you understand how to do all of this in a sound manner, with confidence (and documentation!).

MBR Infectors
I've posted on MBR infectors before, and even wrote a Perl script to help me detect one of the characteristics of this type of malware (i.e., modifying the MBR, and then copying the original MBR to another sector, etc.).

Chad Tilbury recently posted an MBR malware infographic that is extremely informative!  The infographic does a great job of illustrating the threat posed by this type of malware, not just in what it does and how it works, but being a graphic, you can see the sheer number of variants that are out there, as well as how they seem to be increasing. 

This stuff can be particularly insidious, particularly if you've never heard of it.  I've given a number of presentations where I've discussed NTFS alternate data streams (ADSs), and the subject matter freaks Windows admins out...because they'd never heard of ADSs!  So, imagine something getting on a system in such a way as to bypass security protections on the system during the boot sequence.  More importantly, as a DFIR analyst, do you have checks for MBR infectors as part of your malware detection process?

Blogs
Melissa's posted a couple of great blog posts on a number of topics, including (but not limited to) using Volatility and John the Ripper to crack passwords (includes a video), and examining partition tables.  She's becoming more prolific, which is great because she's been posting some very interesting stuff and I hope to see more of it in the future.

Tools
I've seen some tweets over the past week or so that have mentioned updates to the Registry Decoder tool...sounds like development is really ripping along (no pun intended...).  If you do any analysis of Windows systems and you haven't looked at this tool as a resource...what's wrong with you?  Really?  ;-)

Evidence Collection
A long time ago, while I was on the IBM ISS ERS team, we moved away from using the term "evidence" to describe what we collected.  We did so, because the term "evidence" has the connotation of having do with courts, and there was an air of risk avoidance in much of the IR work that we did...I'm not entirely sure where that came from, but that's how it was.  And if a customer (or someone higher up the food chain) says, "don't call it 'evidence' because it sounds like we're taking it to court...", then, well...to me, it doesn't matter what you call it.  Now, this doesn't mean that we changed what we did or how we did it...it simply means that we didn't call the digital data that we collected "evidence". 

This recent SANS ISC post caught my eye.  The reason it caught my eye was that it started out talking about having a standard for evidence handling, listed that requirements, and then...stopped.  Most often when talking with on-site IT staff during an incident, there's an agreement with respect to the need for collecting data, but when you start talking about what type of evidence is admissible in court, that's when most folks stop dead in their tracks and paralysis sets in, as often the "how" is never addressed...at least, not in a way that the on-site IT staff remembers or has implemented.

Here are a couple of thoughts...first, make data collection part of your incident response process.  The IR process should specify the need to collect data, and there should be procedures for doing so.  Each of these procedures can be short enough to easily understand and implement.

One of the things that I learned while preparing for the CISSP exam way back in 1999 was that business records...those records and that data collected as part of normal business processes...could be used as evidence.  I am not a lawyer, but I would think that this has, in part, to do with whether or not the person collecting the data is acting as an agent for law enforcement.  But if collecting that data is already part of your IR process and procedures, then it's documented as being part of your normal business processes.

And right there is the key to collecting "evidence"...documentation.  In some ways, I have always got the impression that this is the big roadblock to data collection...not that we don't know how to do it (there is a LOT of available information regarding how to collect all sorts of data from computer systems), but that we (technical folks) just seem to naturally balk at documenting anything.  And to be honest, I really don't know why that is...I mean, if a procedure states to follow these steps, and you do so, what's the problem?  Is it the fear of having done something wrong?  Why?  If you followed the steps in the procedure, what's the issue?

This really goes back to what I said earlier in this post about finding and working with a trusted adviser, someone with experience in IR who is there to help you help them to help you (that was completely intentional, by the way...).  For example, let's say you have a discussion and do some hands-on work with your trusted adviser regarding how to collect and preserve "evidence" from the most-often encountered systems in your infrastructure...laptops, desktops, and servers in the server room.  Then, let's say you have an incident and have to collect evidence from a virtual system, or a boot-from-SAN device?  Who better to assist you with this than someone who's probably already encountered these systems?  Or better yet, someone who's already worked with you to identify the one-off systems in your infrastructure and how to address them?

So, working with an adviser would help you address the questions in the SANS ISC blog post, and ensure that if your goal (or one of your goals) is to preserve evidence for use by law enforcement, then you've got the proper process, procedures, and tools in place to do so.