Windows Incident Response

Revisiting "Forensic Value"

2012-01-27T08:10:00.000-05:00

I posted some thoughts a while back on defining "forensic value"...in that post, I pondered the question of who defines the "forensic value" of an artifact or finding. The post had received 15 comments relatively quickly, and it seems that there's something of a consensus that the forensic value of data is in the eyes of analyst. One would suppose that this means, then, that the forensic value of a particular artifact can be determined by viewing that artifact through the lens of the analyst's knowledge and experience. In my previous post, I used terms like relative and subjective value, and I think that these descriptive terms come not only from the goals of the examination, but also depend heavily on the knowledge and experience of the analyst.

I recently had the opportunity to review a paper written by someone who had done some pretty comprehensive testing and documented some interesting artifacts. In that paper, the author mentioned certain artifacts that were available, but that these artifacts were not pertinent to the analysis being performed...the artifacts were provided for informational purposes, and might be of value to other analyses. For the paper and the analysis being performed, I thought that this was a valid distinction to make, as it addressed the issue of why those artifacts were not discussed (how the got there, their format, etc.) further in the paper. In short, the author had made a clear distinction as to the relative value of certain artifacts.

The relative value of an artifact often has a lot to do with the context of that artifact. Consider an email address found within an image, perhaps using something like bulk_extractor or a keyword search. The email address may already have an intrinsic value to you, possibly as a piece of intelligence. From that point, any additional value of that artifact can rely heavily on the context in which that artifact resides. Was that artifact found in a file? In a PST file? If the email address was found in a PST file, in an email, what is the context? The value of the email address vary greatly depending upon not only the goals of your examination, but also whether the address was found in the To:, From:, or CC: block of the email, or if it is located in the body of the email. Depending upon the goals of your examination, the fact that the email address was found in the body of an email may be more important and have more relative value than if it were found in the To: block.

The absence of an artifact can also be of significant value, but again, that will depend heavily upon (a) the goals of the examination, and (b) the skills of the examiner. For example, I was performing some Registry analysis a while back to determine which files a user account had been used to access on that system (goals). I noticed immediately that RegRipper reported that the "RecentDocs key was not found." This was a very significant finding, and not something I had expected...and my experience told me that it was something worth exploring, particularly given the goals of my exam. I quickly determined that a "scrubbing" tool had been applied to the system, and determined when that tool had been installed and run, and by which user. I was also able to recover a significant bit of deleted data from within the hive file itself.

Now for the big question...so what? How does this apply to...well...anything? Well, consider my recent post on Timeline Analysis...for those analysts who want to "see everything", how much of that "everything" is actually relevant and of forensic value?

In order to address that, I think that we need to look at a couple of things...and I'd start with, what are the goals of your exam?

I've heard some folks say that during analysis, it's important to understand an attacker's methods, as well as their intentions. I'm not so sure that's something I'd hang my hat on...mostly because the attacker isn't sitting next to me so that I can ask them questions and understand their intentions. When performing analysis, all we see is the results of their actions...maybe only some of those results...and we often look at those results and artifacts through the lens of our own experiences in order to attempt to determine the intentions of others. Further, when it comes to understanding the methods an attacker uses, that's an understanding that's most often developed by observing various artifacts from within the system...but if we're not familiar with the system that we're analyzing, and we're using some automated tool to pull out all of the "relevant" artifacts for us, are we observing all of the artifacts, or at least the right ones to give us a view into what the attacker is trying to do?

Consider this...given an image acquired from a system...let's say, for the sake of discussion, a Windows 7 system...how do we know that when we run a particular tool (or set of tools) against that image that we're extracting all of the relevant data that we require in order to make informed opinions regarding our findings? When an analyst says, "I want a timeline, and I want it with everything!", how does that analyst then know that they've got everything in that timeline?

The forensic value of any particular artifact is determined by the goals of the exam, and the relevance of that artifact, taken in context with other artifacts. The terms "relevance" and "context" will often be subjective, based on the knowledge and skill level of the examiner.

Does this mean that every analyst needs to be an expert in Windows? No, that's not entirely practical. What it does mean is there ~~needs to be~~ should be multiple levels of access to knowledge, including training, mentors and trusted advisers available to your analysts, and that these should all be part of or accessible to your analysis team.

Stuff

2012-01-20T14:30:00.000-05:00

DFIROnline Meetup
If you're interested purely in numbers, last night's DFIROnline meetup had, at one point, 97 attendees. It might've helped that my presentation was addressing malware, and we ended up continuing Cory Altheide's drinking game from last year's OSDFC...every time I mispronounced the word as "mall wear", everyone had to take a drink. I have to go back and review the tape, but my presentation may have ended up being more like a Ron White concert. ;-)

My previous blog post includes a link to the slides I used, as well as the malware detection checklist that I mentioned in my presentation.

There's an excellent write-up at the Digital Forensic Source blog regarding last night's meetup, if you're interested, and you can also search for the "#DFIROnline" hash tag on Twitter to see what comments folks made during the meetup. I have to say, however, that most of the comments were made online, in chat window 3...

Again, a huge thanks to Mike for setting these up and making the resources available, and thanks to everyone who takes the time out of their evening (or day, depending on where you are) to attend and engage.

Malware IOCs - Ramnit
Here's an excellent walk-through of creating an IOC for the Ramnit malware. If you're interested in the OpenIOCs at all, or just want to see how someone would go about creating an IOC, take a look at the post...and be sure to read the first two parts, as well.

If you were on last night's DFIROnline presentation on malware detection within an acquired image, what would the malware characteristics be for Ramnit, based on the IOC?

Timelines
If you like case studies and discussions of practical analysis techniques, take a look at Rob's post on Digital Forensic SIFTing. Rob provides some very good walk-thrus regarding how to use log2timeline effectively on several incident types, and this is well worth a look.

Tools
A bit ago I ran across something Yogesh had written on parsing IE RecoveryStore files. As these files are based on the OLE format, and I've recently had some experience writing parsers for files that use this format (Jump Lists, StickyNotes), I thought I'd take a crack at this file, as well. This is still something I'd like to do...I'm hoping Yogesh will release the specifics of parsing the various streams soon.

Along those lines, John Moan recently commented on a blog post and mentioned that he's written two tools, ParseRS and RipRS. I haven't had a case yet that involves recovering information about a user's browser activity, but the approach he's taken is very interesting, and I'm sure that John would greatly appreciate it if folks would try the tools out and provide him with some valuable feedback. I've added the tools to my FOSS Tools page, keeping them persistent in one place.

Case Studies
Speaking of case studies, this is one of the items of interest within the community. I've known about it for a while...in fact, I've tried to write my books to include case studies, and I also tend to look for similar approaches in other books. Writing about a tool or technique is dry enough as it is, and the way to engage the reader (using the vehicle of the written word) is to include a case study that describes how the tool or technique was used.

On a number of forums, I see requests for case studies. Not long ago, a thread was started in a forum that included a request that analysts post case studies; this is nothing new, I've seen it before. What I haven't seen is those folks then posting case studies themselves. Now, there are a number of what could be considered case studies online. In fact, if you go to the FOSS Tools page off of my blog, and scroll down to the "Sample Images" section, you'll see links to several sample images that you can download...several of them have actual scenarios associated with them, as well as solutions. These can serve as some pretty good case studies.

DFIROnline: Detecting Malware in an Acquired Image

2012-01-18T10:24:00.000-05:00

The next DFIROnline meetup is on Thu, 19 Jan 2012, at 8pm EST. Eric Huber and I will each be presenting, with my presentation being Malware Detection within an Acquired Image (the PDF for the presentation is linked below). I thought that this would be a good presentation to give, as it seems to be fairly topical. We'll be focusing on understanding malware and addressing malware detection within an image acquired from a Windows system.

For those attending the presentation tonight, I'm sure that Eric and Mike would appreciate questions, feedback, thoughts and comments. During the presentation, please feel free to use the available chat windows for any interaction, and also feel free to contact folks via email during or after the presentations.

In particular, please feel free to either volunteer to give presentations, or to offer up ideas and/or requests for material to be covered in these presentations. Who knows...there might be someone out there with some great material who simply doesn't think that anyone could possibly be interested in what they have to say...and all it takes is one or two people to send in, "...I'd really appreciate hearing more about this topic...".

Finally, a HUGE thanks to Mike for setting this up and providing the resources to make this event possible on a regular basis.

Resources
Presentation PDF for 19 Jan DFIROnline Meetup

Malware page to this blog
Malware Detection Checklist

Timeline Analysis

2012-01-13T19:00:00.000-05:00

The DoD Cybercrime Conference is approaching, and I've been doing some thinking about my topic, Timeline Analysis. I'll be presenting on Wed morning, starting at 8:30am...I remember Cory Altheide saying at one point that all tech conferences should start no sooner than 1pm and run no later than 3:30pm, or something like that. Cool idea.

So, anyway...I've been thinking about some of the things that I put into pretty much all of my timeline analysis presentations. When it comes to creating timelines, IMHO there are essentially two "camps", or approaches. One is what I call the "kitchen sink" approach, which is basically, "Give me everything and let me do the analysis." The other is what I call the "layered" or "overlay" approach, in which the analyst is familiar with the system being analyzed and adds successive "layers" to the timeline. When I had a chance to chat with Chad Tilbury at PFIC 2011, he recommended a hybrid of the two approaches...get everything, and then view the data a layer at a time, using something he referred to as a "zoom" capability. This is something I think is completely within reach...but I digress.

One of the things I've heard folks say about using the "everything" or "kitchen sink" approach is that they'd rather have everything so that they can look at it all when they're conducting analysis, because that's how we find new things. I completely agree with that (the "finding new things" part), and I think it's a great idea. After all, one of the core, foundational ideas behind creating timelines is that they can provide a great deal of context to the events we're seeing, and generally speaking, the more data we have, the more context there is likely to be available. After all, a file modification can be pretty meaningless, in and of itself...but if you are able to see other events going on "nearby", you'll begin to see what events led up to and occurred immediately following the file modification. For example, you may see that the user launched IE, began browsing the web, requested a specific page, Java was launched, a file was created, and the file in question was modified...all of which provides a great deal of context.

That leads me to this question...if you're running a tool that someone else designed and put together, and you're just pushing a button or launching a command, how do you know that the tool got everything? How do you know that what you're looking at in the output of the tool is, in fact, everything?

The reason I prefer the layered approach is that it's predicated on (a) fully understanding the goals of your examination, and (b) understanding the system that you're analyzing. Because you understand your goals, you know what it is you're trying to achieve. And because you understand that system you're analyzing...Windows XP, Windows 7, etc...you also understand how various aspects of the operating system interact and are interconnected. As such, you're able to identify where there may be additional data, and either request or create your own tools for extracting the data that you need. Yes, this approach is more manually-intensive than a more automated approach, but it does have it's positive points. For one, you'll know exactly what should be in the timeline, because you added it.

Alternatively, most often when talking to analysts about collecting data, the sense I get is that the general feeling is to "GET ALL THE THINGS!!" and then begin digging through the volumes of data to perform "analysis". I had a case a while back that involved SQL injection, and I created a timeline using only the file system metadata and the SQL injection statements from the web server logs; adding everything else available (including user profile data) would have simply made the timeline too cumbersome and too confusing to effectively analyze. I understood the goals of my exam (i.e., determine what the bad guy did and/or was able to access), and I understood the system (in this case, how SQL injection works, particularly when the database and web server are on the same system).

Now, some folks are going to say, "hey, but what if you missed something?" To that I say...well, how would you know? Or, what if you had the data available because you grabbed everything, and because you had no real knowledge of how the system acted, you had no idea that the event(s) you were looking at were important?

Something else to consider is this...what does it tell us when artifacts that we expect to see are not present? Or...

The absence of an artifact where you would expect to find one is itself an artifact.

Sound familiar? An example of this would be creating a timeline from an image acquired from a Windows system, and not seeing any indication of Prefetch file metadata in the timeline. A closer look might reveal that there are no files ending in .pf in the timeline. So...what does that tell you? I'll leave that one to the reader...

My point is that while there are (as I see it) two approaches to creating timelines, I'm not saying that one is better than the other...I'm not advocating one approach over another. I know from experience that there a lot of analysts who are not comfortable operating in the command line (the "dark place"), and as such, might not create a timeline to begin with, and in particular not one that is pretty command-line-intensive. I also know that there are a good number of folks who use log2timeline pretty regularly, but don't necessarily understand the complete set of data that it collects, or how it goes about doing so.

What I am saying is that, from my perspective, each has it's own strengths and weaknesses, and it's up to the analyst how they want to approach creating timelines. You may not want to use a manually-intensive approach (which you can easily automate using batch files, a la Corey Harrell's approach), but if you end up using a substantive framework, how do you know you're getting everything?

Uncertainty

2012-01-10T10:46:00.000-05:00

Not too long ago, I blogged with a view of how you can contribute to the DFIR community, and this post seems to have sparked some discussion, leading to posts from other bloggers. I saw via Twitter this morning that Christa Miller had posted her review of the Jonathan Fields book, Uncertainty. Unfortunately, Twitter is poor medium for commenting (although many seem to prefer it) as 140 characters simply is not enough space to offer comments, input or feedback on something. Far too often, I think, for many forensicators it comes down to tweeting or nothing. When that happens, I honestly believe the something is lost, and the community is less for it. As such, I opted to post the thoughts that Christa's review percolated here on my own blog.

I won't rehash Christa's review here...there's really no point in doing that. Christa is an excellent writer, and the only way to do her review and writing justice is to recommend that you go read what she's written, and draw your own opinions.

Two sentences in particular within Christa's review really caught my attention:

A forensicator’s fear of looking stupid or failing is not, on its face, all that irrational. Who wouldn’t worry about how one’s employer or a courtroom will react to the disclosure that you don’t have all the answers?

What I thought was interesting about this was not so much whether this fear is irrational or not; rather, what caught my attention was the "one's employer or a courtroom". I'm sure that a lot of analysts are faced with this very situation or feeling, and as such, I wouldn't discount as being irrational at all. Now, I'm not saying that Christa's review did this...rather, I'm simply saying that as a community, this is a place where a number of analysts find themselves.

When I was in graduate school, I was surrounded by other students, a few of whom were PhD candidates. There were a great number of PhD academic professors, of course, and perhaps one of the most powerful things I learned in my 2 1/2 years at NPS was something one of my instructors shared with me. He had been an enlisted Marine, switched over to "the dark side" to become an officer, and was a Major by the time he left the Marine Corps to pursue his PhD. In short, he told me that if I was struggling with a 6th order differential equation, after no more than 15 minutes of not making any headway, ask for help.

That's right. Admit that you need help, assistance, a gentle nudge...hey, we all find at times that we've worked ourselves into a tight corner by going down a rabbit hole, particularly the wrong one. Why keep doing it, if all you really need is a little help?

So, I found myself thinking about that statement years later when I would be going over another analyst's case notes and report, and I'd see "Registry Analysis - 16 hrs" and nothing else. No "this is what I was looking for" and no "this is what I found." Why was that? Why would a consultant consume 8 or 16 hrs doing something that they had no idea of and had no discernible results, and then charge a customer for that time? Particularly when someone who could provide assistance was a phone call or a cubicle away?

Whenever I've encountered a situation where I'm not familiar with something, I tend to reach out for some assistance. While I was on the ISS ERS team, I was tasked with a Saturday morning response to address a FreeBSD firewall in a server room in another state. Now, I have some familiarity with Linux, but hey, this is a firewall...so I asked the engagement manager to see about lining someone up with whom I could speak once I got on-site, got situated and got an idea of what was going on. After all, I'm not an expert on much of anything, in particular FreeBSD firewalls.

Having worked with teams of analysts over the years, I've seen this "fear of failure" issue several times. Each time, I see two sides to the issue...on one hand, you have the analyst who's afraid to even ask a question, because (as I've been told) they're afraid of "looking stupid" to their peers and boss. So what happens is that instead of asking for help, they turn in a report that's incomplete, full of glaring holes in the analysis and conclusions, and essentially blank case notes. That gig to analyze one image that was spec'd out at 48 hrs now takes 72 or even 96 (or more) hours to complete between multiple analysts, and while the customer ultimately gets a half-way decent deliverable, your team has lost money on the engagement. On top of that, there's now some ill-will on the team...because one analyst didn't want to ask for help, now another analyst has to drop everything (including their family time after 5pm) to work late, in emergency mode.

On the other hand, there's the analyst who does ask questions, does ask for assistance, and in the process learns something that they can then carry forward on future engagements. The customer receives a comprehensive report in a timely manner, and the analyst is able to meet their revenue numbers, allowing them the time to take a vacation or "mental health day", and receive a bonus.

My point is this...there's not one of us that knows everything, and regardless of what your individual perception may be, no one expects you to know everything. If you have a passion for what you do, you learn when you ask questions and engage with others, you incorporate that new information into what you do, and you grow from it. If you're worried about people thinking you'll "look stupid", an option would be to pursue a trusted adviser relationship with someone with whom you feel comfortable asking questions.

If you're concerned with someone seeing you ask a question publicly (potential employer, defense counsel), then find someone you can ask questions of "off the grid".

Ultimately, as I see it, the question becomes, do you continue into the future not knowing something, or do you ask someone and at the least get a leg up on fully discovering the answer? Would you rather look like you don't know something for a moment (as you ask the question) and then have an answer (or at least a pathway to it), or would your preference be to not know something at all, and have it discovered later, after the issue has grown?

My recommendation with respect to the two sentences from Christa's review is this...if you find yourself in a situation where you are telling yourself, "I don't want people to think I'm dumb", consider what happens if you don't ask that question. Are you going to run over hours on your analysis, and ultimately provide a poor product to your customer? Are you missing data that would lead to the conviction or exoneration of someone who's been accused of a crime? Or, can you take a moment to frame your question, provide some meaningful background data ("I'm looking at a Windows XP system"), maybe do some online searches, and ask it...even if that means you're reaching out to someone you know rather than posting to a public forum?

Stuff

2012-01-02T07:52:00.002-05:00

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:

All files are in the Microsoft OLE structured storage container format.

That's awesome...he's identified the format, which means that we can now parse these files. Yogesh mentions free tools, and one of the ones I like to use to view the contents of OLE files is MiTeC's SSV, as it not only allows me to view the file format and streams, but I can also extract streams for further analysis.

Another reason I think that this is cool is that I recently released the code I wrote to parse Windows 7 Jump Lists (I previously released code to parse Win7 Sticky Notes), and the RecoveryStore files follow a similar basic format. Also, Yogesh mentions that there are GUIDs within the file that include 60-bit UUID v1 time stamps...cool. The Jump List parser code package includes LNK.pm, which includes some Perl code that I put together to parse these artifacts!

I don't have, nor do I have access to at this time, any RecoveryStore files to work with (with respect to writing a parser)...however, over time, I'm sure that the value of these artifacts will reach a point such that someone writes, or someone contributes to writing, a parser for these files.

Contributing to the Community

2012-01-01T07:57:00.002-05:00

So, here we go with my first post of 2012...

Not long ago, I posted some thoughts on how analysts can contribute to the DFIR community. What I wanted to do was offer suggestions to those within the community who had read Rob's post and had maybe thought that writing a batch script or a full-on program was a pretty daunting endeavor, let alone standing up an entire project such as log2timeline. Recently, there have been some interesting exchanges on Twitter, and I think that this is a good time for folks to consider how they might make a contribution to the DFIR community in 2012.

I think that one of the biggest misconceptions within the DFIR community is how one person can make a contribution. I think that a lot of analysts get themselves into a nice, comfortable little place called "complacency" through paralysis. What I mean by that is that too many analysts will convince themselves that they can't contribute to the community because they don't know how to program. Some analysts seem to look around, see how some others contribute, and say to themselves, "I can't contribute to the community because I don't know how to program." I think that this applies to other ways of contributing besides just programming, and I think this is just an excuse, and a pretty bad one at that.

At the first Open Source Digital Forensics Conference (put on by Basis Tech and Brian Carrier...thanks, Brian!) in 2010, toward the end of the conference a member of the audience asked, "Why can't I dump and parse memory from Windows 7 systems??" To that, a prominent member of the community asked, "What have you contributed?"...the idea being that one can't...and shouldn't...simply sit back and expect everything to come to them for free without putting forth something. But the response didn't center around someone's ability to code in Python...rather, it was about other aspects of how someone could go about making contributions. Had the person asking the question offered up extra hardware to support development efforts, offered to write up documentation, or just said, "Thank you"?

Not everyone (me, in particular) expects all DFIR analysts to be able to write code. There are a lot of really good analysts out there who don't go beyond simple scripts and regexes, and others who don't code at all. Corey Harrell has made some pretty fantastic contributions, simply by having written a number of batch scripts, in essence tying together other tools.

There are a number of ways that anyone can make a contribution to the community, and most do not require the ability to write code. Some of the ways you can do that in 2012 include, but are not limited to, the following:

Case Studies - One of the things that is definitely true about the DFIR community is that folks really love hearing how others have done things. Many of us encounter the same or similar cases, or have those "one-offs" that don't get seen very often, and we all enjoy hearing about novel approaches to solving problems. Admit it...just to be in this community, you have to have a little nerd in you, and there's a part of you that likes to hear how someone else may have overcome an obstacle that they encountered. Keeping that in mind...that you like to hear those "war stories"...consider sharing yours with others.

If you can't program, but you are able to download and use a tool (commercial, open source), then a great way to make a contribution is to comment on how you used the tool. Was it useful/sufficient/accurate? Was it easy to use?

Ask a question - Very often, this is a huge contribution! Asking a question very often has the effect of sharing your perspective on things with others, and seeing different perspectives can very often be extremely beneficial. For example, I like to dig into the Registry, but many times I don't really know what it is that other analysts find useful, or what would be most valuable to their case work. If someone asks a question about the Registry (specific keys/values, how to locate something, etc.), that gives others a perspective of how they look at things, how they approach problems, and how they go about solving them...and many times, just this perspective can help someone else with an issue that they're working on.

If you download a free, open source tool and you're having trouble using it, start by asking the author for pointers or assistance. Maybe there's something wrong with how you're using it...maybe you're missing a switch. Or maybe you're running an MBR parsing tool against a .vmem file (hey, I can't make this stuff up). Asking the author your question gives them insight into who's using the tool, how it's being used, and maybe how to improve it...and it's far better (and much more appreciated) than going to a public forum and stating, "...this tool don't work."

Here's a great example of how you can ask a question...the example is specific to the DFIROnline meetups, but it demonstrates how a number of folks can come together to provide different perspectives when addressing issues and answering questions.

Review a blog post, book or paper - Don't code, and can't share case studies? Don't feel as if you can maintain a blog? No problem. How about this...have you read Corey's blog? Did you find something interesting in one of his posts? Did you think what he posted was cool? Did you tell him about it? Did you comment on it, and share your thoughts? If you can't do so directly to the comment section of his blog, have you considered sending him an email?

If you decide to review a book, consider doing something just a little bit more than repeating the table of contents. While authors appreciate knowing that someone picked up their book, they appreciate it even more knowing (a) if the material was useful, and (b) how it was useful. Again, sharing your perspective can be very valuable.

What Not To Do
In 2012, consider what you can do, and consider not spending time worrying about (or stating) what you can't do. "I can't program" isn't a contribution to the community.

If you feel strongly enough to download a tool that someone wrote, take the time to thank them. Okay, you may not have time to do any in-depth testing of the tool, and you may have downloaded it just to have it for future use, but you had the interest and took the time to download the tool. Now, this doesn't mean that you have to reach out and thank someone every time you actually run the tool, but just having the courtesy to thank someone for their efforts can go a long way toward the development of that tool, or others.

I think that most times, folks look at what others do to contribute within the community and think to themselves, "I can't program, I don't have the time to write books, and I don't like public speaking, so I can't contribute."...and to be honest, nothing could be further from the truth. No one is expected to make contributions all the time...hey, we're people and have lives. But there's really no reason why, if you're capable of doing the work that we do in this field, that at some point in the space of a year, you can't make some contribution of some kind, no matter how small.

Clicking "Like", "+1", or re-tweeting a post isn't a contribution, as it doesn't add anything to whatever it is you're commenting on. If you like something enough to click a button, take a moment to say what you like about it, or how it was useful or valuable to you. The same holds true for book reviews...if you're going to review a book, reiterating the table of contents isn't a review; however, describing what you found valuable (or not) and how it was valuable to you is what most of us look for in a review, right? "The car has cup holders" isn't so much a review of a vehicle as "the car has three cup holders, none of which the driver can easily reach."

What if you're one of those folks who is bound by a corporate policy or something else that prevents you from contributing? What does this policy prevent you from doing? You can't talk about casework? That's fine...in a lot of cases, many of us are thankful that you're the one dealing with the details of the specific case and not us.

Final Thoughts
No one of us is as smart as all of us, and the best way to get smarter within this community is to engage with each other, share perspectives and thoughts, and then build from there.

Sometimes, the biggest contribution you can make is to simply thank someone for their contribution and efforts. Seriously. This means a lot. Think about it...if you did something, no matter how small, wouldn't you appreciate it if someone said, "thanks"?

As an example of mandating that members contribute, check out the NoVA Hackers blog...they follow the AHA model of participation...which, in short, says that if you want to remain a member, you have to participate. The AHA page lists what you must do in order to remain a member of their group, and remember, membership is voluntary, so one must accept these conditions upon becoming part of the group.

Here's looking forward to a great 2012, everyone...

Addendum:
Erika posted on this topic, as did Ken...both are excellent posts that take the conversation regarding contributing to the community several steps further. More than anything, I think that it's valuable to hear from others in this regard, in particular those within the community who might say, "...I want to contribute, but I don't think I have anything of value to share." I've said it before and I'll say it again...sometimes, the best question to ask is "why?". When I was on the IBM ERS team, we brought Don Weber on board, and besides just being a great guy, he'd ask me "why?" during engagements, and that got me to re-think (and in many cases, justify) my base assumptions with respect to next steps on the engagement. That isn't to say that it changed what I was going to do as the engagement lead, but it did open up discussion so that Don could understand what I was thinking. It also afforded me the opportunity to get Don's input, which was invaluable. Sometimes, the most information can come from questions such as, "why did you do it this way?" or "how did you go about accomplishing this?"

An additional thought or two that might help...choose your circles and choose your medium. If you don't feel comfortable posting to an open list, find some other medium. One way to ask the questions you may have would be to send them directly to someone you trust, and either ask them to post them as a proxy, or just see if they know the answer.

What happens sometimes is that someone will ask a question, and the response will be terse or concise, or include a link to LMGTFY, or just be, "...which OS?" These happen very often when little initial thought, effort or research is put into the question, and are often viewed by the recipient as a "slam". I think that what folks really don't realize is that you can't convey tone in 140 characters or less, so many times it's assumed because it can't be implied. If a medium like Twitter (limit of 140 char) leaves you thinking to yourself, "...hey, I asked a question, but that guy's response being mean to me...", then maybe that isn't the right medium for what you're trying to accomplish.

Not every medium is suitable for everyone in this industry. For example, the Win4n6 Yahoo group currently has 830 members listed in the forum, and only about a dozen or so "regular" contributors. As I approve every membership application (solely as an effort to keep bots out), I see all of those who post during the application process that their reason for joining is to "contribute" and "take part" in discussions...and we never hear from them again. So maybe this medium isn't something that works for them.

Final thought...this time around, anyway...if you don't have the time to put into a question, maybe it's not a good time to ask it. I'm not saying that you shouldn't ask your question, I'm just suggesting that if you don't have the time to do some research on your own, or don't have the time to let folks know that you're looking at a Windows 7 system and not Windows XP (if you don't know why that matters, please feel free to ask...), maybe now is not a good time to ask the question. Maybe it's better to hold off until you have more time to do a thorough job, rather than just throwing it out to "the collective". Just something to think about...Ken referred to this when he mentioned "...ask stronger questions about forensic topics." Excellent point, Ken.

Jump List Parser Code Posted

2011-12-30T12:11:00.000-05:00

As a follow-up to my recent Jump List Analysis blog post, I've posted the Jump List parser code that I've been talking about.

Again, this isn't a Windows GUI program. The code consists of two Perl modules that I wrote (and I'm not an expert in either Perl OO programming or writing Perl modules...), and the available archive contains a couple of of example scripts that demonstrate simple uses of the modules.

I wrote these modules in order to provide maximum flexibility to the analyst. For example, I use a five-field timeline (TLN) format for a good bit of my analysis, and that's not something I can get from available tools...not without manually exporting the contents of those tools and writing a separate parser. Also, I know some folks who really love to use SQLite databases (MarkMcKinnon), so providing the code in this manner allows those analysts to write scripts using the Perl DBI to access those databases.

Also, I know that analysts like Corey Harrell will be itching to rip previous versions of Jump List files from VSCs. As such, scripts can be written to parse just the DestList streams out of previous versions of the *.automaticDestinations-ms Jump List files and correlate that data.

The archive also contains a user guide that I wrote that explains not only the modules but how to use them and what data they can provide to you.

As a side note, I ran the lnk.pl script provided in the archive through Perl2Exe to create a simple, standalone Windows EXE file, and then ran it against the same target file (a shortcut in my own Recent folder) that I had tested the Perl script on, and it worked like a champ.

Once again, I am not an expert. These modules should be fairly stable, and I wouldn't expect them to crash your box. However, they are provided as-is, with no warranties or guarantees as to their function. Also, the code uses only core Perl functions and parses the target structures on a binary level, so it's entirely possible that I may have missed a structure or parsed something improperly. If you find something amiss, I'd greatly appreciate you letting me know, and providing some sample data so that I can replicate and address the issue.

That being said, I hope that folks find this code to be useful.

Jump List Analysis

2011-12-28T11:00:00.000-05:00

I've recently spoke with a couple of analysts I know, and during the course of these conversations, I was somewhat taken aback by how little seems to be known or available with respect to Jump Lists. Jump Lists are artifacts that are new to Windows 7 (...not new as of Vista...), and are also available in Windows 8. This apparent lack of attention to Jump Lists is most likely due to the fact that many analysts simply haven't encountered Windows 7 systems, or that Jump Lists haven't played a significant role in their examinations. I would suggest, however, that any examination that includes analysis of user activity on a system will likely see some significant benefit from understanding and analyzing Jump Lists.

I thought what I'd try do is consolidate some information on Jump Lists and analysis techniques in one location, rather than having it spread out all over. I should also note that I have a section on Jump Lists in the upcoming book, Windows Forensic Analysis 3/e, but keep in mind that one of the things about writing books is that once you're done, you have more time to conduct research...which means that the information in the book may not be nearly as comprehensive as what has been developed since I wrote that section.

In order to develop a better understanding of these artifacts, I wrote some code to parse these files. This code consists of two Perl modules, one for parsing the basic structure of the *.automaticDestinations-ms Jump List files, and the other to parse LNK streams. These modules not only provide a great deal of flexibility with respect to what data is parsed and how it can be displayed (TLN format, CSV, table, dumped into a SQLite database, etc.), but also the depth to which the data parsing can be performed.

Jump List Analysis

Jump Lists are located within the user profile, and come in two flavors; automatic and custom Jump Lists. The automatic Jump Lists (*.automaticDestinations-ms files located in %UserProfile%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations) are created automatically by the shell as the user engages with the system (launching applications, accessing files, etc.). These files follow the MS-CFB compound file binary format, and each of the numbered streams within the file follows the MS-SHLLINK (i.e., LNK) binary format.

The custom Jump Lists (*.customDestinations-ms files located in %UserProfile%\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations) are created when a user "pins" an item (see this video for an example of how to pin an item). The *.customDestinations-ms files are apparently just a series of LNK format streams appended to each other.

Each of the Jump List file names starts with a long string of characters that is the application ID, or "AppID", that identifies the specific application (and in some cases, version) used to access specific files or resources. There is a list of AppIDs on the ForensicsWiki, as well as one on the ForensicArtifacts site.

From an analysis perspective, the existence of automatic Jump Lists is an indication of user activity on the system, and in particular interaction via the shell (Windows Explorer being the default shell). This interaction can be via the keyboard/console, or via RDP. Jump Lists have been found to persist after an application has been deleted, and can therefore provide an indication of the use of a particular application (and version of that application), well after the user has removed it from the system. Jump Lists can also provide indications of access to specific files and resources (removable devices, network shares).

Further, the binary structure of the automatic Jump Lists provides access to additional time stamp information. For example, the structures for the compound binary file directory entries contain fields for creation and modification times for the storage object; while writing and testing code for parsing Jump Lists, I have only seen the creation dates populated.

Digging Deeper: LNK Analysis
Within the automatic Jump List files, all but one of the streams (i.e., the DestList stream) are comprised of LNK streams. That's right...the various numbered streams are comprised of binary streams following the MS-SHLLINK binary format. As such, you can either use something like MiTeC's SSV to view and extract the individual streams, and then use an LNK viewer to view the contents of each stream, or you can use Mark Woan's JumpLister to view and extract the contents of each stream (including the DestList stream). The numbered streams do not have specific MAC times associated with them (beyond time stamps embedded in MS-CFB format structures), but they do contain MAC time stamps associated with the target file.

Most any analyst who has done LNK file analysis is aware of the wealth of information contained in these files/streams. My own testing has shown that various applications populate these streams with different contents. One thing that's of interest...particularly since it was pointed out in Harry Parsonage's The Meaning of LIFE paper...is that some LNK streams (I say "some" because I haven't seen all possible variations of Jump Lists yet, only a few...) contain ExtraData (defined in the binary specfication), including a TrackerDataBlock. This structure contains a machineID (name of the system), as well as two "Droids", each of which consists a VolumeID GUID and a version 1 UUID (ObjectID). These structures are used by the Link Tracking Service; the first applies to the new volume (where the target file resides now), and the second applies to the birth volume (where the target file was when the LNK stream was created). As demonstrated in Harry's paper, this information can be used to determine if a file was moved or copied; however, this analysis is dependent upon the LNK stream being created prior to the action taking place. The code that I wrote extracts and parses these values into their components, so that checks can be written to automatically determine if the target file was moved or copied.

There's something specific that I wanted to point out here that has to do with LNK and Jump List analysis. The format specification for the ObjectID found in the TrackerDataBlock is based on UUID version 1, defined in RFC 4122. Parsing the second half of the "droid" should provide a node identifier in the last 6 bytes of stream. Most analysts simply seem to think that this is the MAC address (or a MAC address) for the system on which the target file was found. However, there is nothing that I've found thus far that states emphatically that it MUST be the MAC address; rather, all of the resources I've found indicate that this value can be a MAC address. Given that a system's MAC address is not stored in the Registry by default, analysis of an acquired image makes this value difficult to verify. As such, I think that it's very important to point out that while this value can be a MAC address, there is nothing to specifically and emphatically state that it must be a MAC address.

DestList Stream
The DestList stream is found only in the automatic Jump Lists, and does not follow the MS-SHLLINK binary format (go here to see the publicly documented structure of this stream). Thanks to testing performed by Jimmy Weg, it appears that not only is the DestList stream a most-recently-used/most-frequently-used (MRU/MFU) list, but some applications (such as Windows Media Player) appear to be moving their MRU lists to Jump Lists, rather than continuing to use the Registry. As such, the DestList streams can be a very valuable component of timeline analysis.

What this means is that the DestList stream can be parsed to see when a file was most recently accessed. Unlike Prefetch files, Jump Lists do not appear (at this point) to contain a counter of how many times a particular file (MSWord document, AVI movie file, etc.) was accessed or viewed, but you may be able to determine previous times that a file was accessed by parsing the appropriate Jump List file found in Volume Shadow Copies.

Summary
Organizations are moving away from Windows XP and performing enterprise-wide rollouts of Windows 7. More and more, analysts will encounter Windows 7 (and before too long, Windows 8) systems, and need to be aware of the new artifacts available for analysis. Jump Lists can hold a wealth of information, and understanding these artifacts can provide the analyst with a great deal of clarity and context.

Resources
ForensicsWiki: Jump Lists
Jump List Analysis pt. I, II, III
DestList stream structure documented
Harry Parsonage's The Meaning of LIFE paper - a MUST READ for anyone conducting LNK analysis
RFC 4122 - UUID description; sec 4.1.2 describes the structure format found in Harry's paper; section 4.1.6 describes how the Node field is populated
Perl UUID::Tiny module - Excellent source of information for parsing version 1 UUIDs

Even More Stuff

2011-12-19T08:15:00.000-05:00

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.

New Stuff

2011-12-16T18:22:00.000-05:00

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.

More Stuff

2011-12-15T10:48:00.001-05:00

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

Stuff

2011-12-13T08:16:00.000-05:00

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.

Meetup

2011-12-08T08:50:00.001-05:00

Last night's meetup was a great success! Sam not only gave a great presentation, he also peppered the audience with some amazing card tricks! Sam really knows how to deliver on not only the technical information, but also with the magic, and did a great job of keeping everyone entertained on both fronts. Yes, Sam is an accomplished magician.

Copies of the slides for Sam's presentation are posted to the NoVA4n6Meetup and Win4n6 Yahoo groups.

I ended up taking notes on my iPhone (using the Notepad app), but here are a couple of take-aways that I had from the presentation:

- I really liked the way Sam broke down and categorized the whole process through visualization. The third slide of the presentation has a "tool analysis pyramid" (it also appeared later in the presentation)...maybe a better title would be "tool-analysis pyramid". Based on the work that I've done on the Windows side of things, I really like how Sam broke things down into easy-to-understand categories, which has the effect of making it much easier to communicate your findings, thoughts or needs to others that also understand the framework.

- "Supported means supported." Depending on the equipment or software you have, and the device, "supported" can mean different things.

- Sam programs in Perl. Uh...that's the most awesome thing. EVER. If you find yourself doing something over and over again, automation is a wonderful thing. It's also a force multiplier...someone like Sam can write something useful, and someone else who understands the issue and Perl can leverage what Sam did, reducing the time it takes to reach that same level of understanding and effectiveness.

- Sam runs races. I've run some similar distances as what Sam runs, but that was 20 years ago. I'd be honored if Sam were to come out and run the Tough Mudder with me...we'll have to see what the future holds. Maybe I'll have to go out ahead of him and leave either some old cell phones or some antique decks of playing cards along the route... ;-)

Overall, 32 attendees was a great showing...I thank everyone who braved the weather to come out and see Sam, and I hope that everyone had a great time. And I wanted to thank Sam for taking the time to put together a wonderful presentation, as well as to come out and give that presentation to all of us. Many of us have families and other commitments, and I for one greatly appreciate the time and effort that Sam, as well as our other presenters, have taken to put materials together and get up in front of their peers.

Online DFIR Meetups
Back when I attended (and presented at) PFIC 2011, I had a chance to talk to Mike Wilkinson, an instructor in digital forensics at Champlain College. Mike decided to start online DFIR meetups via his Adobe Connect Meeting Room. The first meetup is on Thu, 15 Dec 2011 at 8pm EST. Be sure to have Adobe Flash installed on your system, and come join us. I did see a request that Mike record the meetups...I hope that this ends up being the case.

Stuff

2011-12-06T13:48:00.001-05:00

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?

New Stuff

2011-12-02T08:46:00.000-05:00

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.

Stuff

2011-11-23T07:07:00.000-05:00

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.

Good Stuff

2011-11-18T15:10:00.000-05:00

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!

Stuff, Reloaded

2011-11-16T15:25:00.000-05:00

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.

Stuff

2011-11-15T07:26:00.000-05:00

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.

Tool Update - WiFi Geolocation

2011-11-14T09:10:00.002-05:00

I wanted to let everyone know that I've updated the maclookup.pl Perl script which can be used for WiFi geolocation; that is, taking the MAC address for a WAP and performing a lookup in an online database to determine if there are lat/longs available for that address. If there are, then you can convert the lat/long coordinates into a Google map for visualization purposes.

A while back I'd posted the location of WiFi WAP MAC addresses within the Vista and Windows 7 Registry to ForensicArtifacts.com. This information can be used for intelligence purposes, particularly WiFi geolocation, that is, if the WAP MAC address has been mapped and the lat/longs added to an online database, they can then be looked up and plotted on a map (such as Google Maps). I've blogged about this, and covered it in my upcoming Windows Forensic Analysis 3/e. I also wrote maclookup.pl, which used a URL to query the Skyhook Wireless database to attempt to retrieve lat/longs for a particular WAP MAC address. As it turns out, that script no longer works, and I've been looking into alternatives.

One alternative appears to be WiGLE.net; there seems to be a free search functionality that requires registration to use. Registration is free, and you must agree to non-commercial use during the registration process. Fortunately, there's a Net::Wigle Perl module available, which means that you can write your own code to query WiGLE, get lat/longs, and produce a Google Map...but you have to have Wigle.net credentials to use it. I use ActiveState Perl, so installation of the module was simply a matter of extracting the Wigle.pm file to the C:\Perl\site\lib\Net directory.

So, I updated the maclookup.pl script, using the Net::Wigle module (thanks to the author of the module, as well as Adrian Crenshaw, for some assistance in using the module). I wrote a CLI Perl script, macl.pl, which performs the database lookups, and requires you to enter your Wigle.net username/password in clear text at the command line...this shouldn't be a problem, as you'll be running the script from your analysis workstation. The script takes a WAP MAC address, or a file containing MAC addresses (or both), at the prompt, and allows you to format your output (lat/longs) in a number of ways:

- tabular format
- CSV format
- Each set of lat/longs in a URL to paste into Google Maps
- A KML file that you can load into Google Earth

All output is sent to STDOUT, so all you need to do is add a redirection operator and the appropriate file name, and you're in business.

The code can be downloaded here (macl.zip). The archive contains a thoroughly-documented script, a readme file, and a sample file containing WAP MAC addresses. I updated my copy of Perl2Exe in order to try and create/"compile" a Windows EXE from the script, but there's some more work that needs to be done with respect to modules that "can't be found".

Getting WAP MAC Addresses
So, the big question is, where do you get the WAP MAC addresses? Well, if you're using RegRipper, the networklist.pl plugin will retrieve the information for you. For Windows XP systems, you'll want to use the ssid.pl plugin.

Addendum: On Windows 7 systems, information about wireless LANs to which the system has been connected may be found in the Microsoft-Windows-WLAN-AutoConfig/Operational Event Log (event IDs vary based on the particular Task Category).

Important Notes
Once again, there are a couple of important things to remember when running the macl.pl script. First, you must have Perl and the Net::Wigle Perl module installed. Neither is difficult to obtain or install. Second, you MUST have a Wigle.net account. Again, this is not difficult to obtain. The readme file in the provided archive provides simple instructions, as well.

Resources
Adrian wrote a tool called IGiGLE.exe (using AutoIT) that allows you to search the Wigle.net database (you have to have a username and password) based on ZIP code, lat/longs, etc.

Here is the GeoMena.org lookup page.

Here is a review of some location service APIs. I had no idea there were that many.

PFIC 2011

2011-11-10T08:16:00.000-05:00

I just returned from PFIC 2011, and I thought I'd share my experiences. First, let me echo the comments of a couple of the attendees that this is one of the best conferences to attend if you're in the DFIR field.

What I Liked
Meeting people. I know what you're thinking..."you're an ISTJ...you don't like people." That isn't the case at all. I really enjoyed meeting and engaging with a lot of folks at the conference...I won't name them all here, as many don't have an open online presence, and I want to respect their privacy. Either way, it's always great to put a face to a name or online presence, and to meet new people, especially fellow practitioners.

The content. I didn't get to attend many presentations (unfortunately), but those that I did get to attend were real eye-openers, in a number of ways. I didn't get to sit in on anything the first day (travel, etc.), but on Tuesday, I attended Ryan's presentation on how hiding indications of activity leaves artifacts, and Amber's mobile devices presentation. Ryan's presentation was interesting due to the content, but also due to the reactions of many of the attendees...I got the sense from looking around the room (even from my vantage point) that for some, Ryan's presentation was immediately useful...which is a plus in my book.

Amber's presentation was interesting to me, as I really haven't had an opportunity to this point to work with mobile devices. Who knew that an old microwave oven (with the cord cut) was an acceptable storage facility for mobile devices? As an electrical engineer, I know that a microwave oven is a Faraday cage, but like I said...I haven't had a chance to work with mobile devices. Amber also brought up some very interesting points about clones, and even demonstrated how a device might look like an iPhone, but not actually be one, requiring careful observation and critical thinking.

Another great thing about the content of presentations is that there were enough presentations along a similar vein that you could refer back to someone else's presentation in order to add relevance to what you were talking about. I referred to Ryan Washington's presentation several times, as well as to an earlier presentation regarding the NTFS file system. In a lot of ways, this really worked well to tie several presentations together.

After-hours event. I attended the PFIC After Dark even this year...The Spur bar had been shut down just for the event, and we had shuttle transportation between the hotel and bar. It was a great time to meet up with folks you hadn't had a chance to talk to, or to just talk about things that you might not have had a chance to talk about before. I greatly appreciated the opportunity to talk to a number of folks...even those who took the opportunity to buy me a Corona, which I greatly appreciated!

My room. I got in to the venue, and found that I had a complimentary upgrade to another room. Wow! The original room was awesome (or would have been), but then I got a room right by the slopes where they were creating snow for the upcoming ski season. I really like how ski resorts get business in the off-season through conferences and other events...it's a great use of facilities and brings a good deal of business to the local area.

What I'd Do Differently
This section is really a combination of what I'd do differently, as well as what I think, based on my experience, would make the event a better experience overall...

Adjust my travel. I flew in on the Monday of the conference, got in, got cleaned up from my time in airports, grabbed a bite to eat, and then gave my first presentation. Next year, I think I'd like to see about getting to the conference site a bit earlier, and maybe being able to participate in some more things. For example, I was invited to speak on the panel that took place on Wed morning, but my flight out left about an hour before the panel started.

Encourage more tweeting. Social media is a great way to get the word out about upcoming events, but I've also found that live tweeting during the event is also a great way to generate buzz and encourage participation. I did a search this morning for "#PFIC" and turned up only 20 tweets, some in Spanish. I know that Mike Murr wasn't at this

Contests. In addition to the tweeting, Amber mentioned an idea for next year...a forensic challenge of some kind, complete with each team delivering their findings and being judged/graded. I think that would encourage some great participation. I think that these sorts of things attract attention to the blog.

Presentations. One thing I saw and heard others talk about was the fact that there were several good presentations going on at the same time. For example, I had wanted to attend Chad's presentation, but couldn't because I was presenting. On Tues morning, there were two presentations on what appeared to be similar topics that I wanted to attend, and I chose to attend Ryan's.

On the topic of presentations, as the "I" in the conference name stands for "innovation", I think next year would be a fantastic time to hear from the Carbon Black guys.

My Presentations
I gave two presentations this year...thanks again to Amber and Stephanie for allowing me to do so. As the presentation materials don't really convey what was said in the presentation itself, I wanted to share some of my thinking in developing the presentations, as well as the gist of what was said...

Scanning for Low-hanging Fruit: This presentation centered on the forensic scanner I've been working on, both the concept (as in, why would you want to do this...) and the actual implementation (still very proof-of-concept at this point). The presentation even included a demo, which actually worked pretty well.

The idea of the presentation, which may not be apparent from the title, was that once we've found something that we've never seen before (either a new variant of something, or an entirely new thing...), that becomes low-hanging fruit that we can check for each time via automation. The idea would then be to free the analyst to do analysis, rather than having the analyst spend time performing a lot of manual checks, and possibly forgetting some of them in the process. As I mentioned, the demo went over very well, but there's still work to be done with respect to the overall project. Up until now, I haven't had a great deal of opportunity to really develop this project, and I hope to change that in the future.

Introduction to Windows Forensics: When developing this presentation, I really had to think about what constitutes an introduction to Windows forensics. What I decided on...and this seemed to work really well, based on the reactions of the attendees...was to assume that most everyone in the presentation already understood the basics of forensic analysis, and we'd progress on to the forensic analysis of Windows systems. The distinction at that point was that the introduction included some discussion of analysis concepts, and then went into discussing analysis of a Windows system, based on the premise that we'd be analyzing a complex system. So we started out with some concepts, and went into discussing not just the forensic potential of various artifacts and sources (the Registry, Event Log, Prefetch files, etc.), but also the value of considering multiple sources together in order to develop context and a greater relative confidence in the data itself.

Overall, I think that this presentation went well, even though I went really fast (without any RedBull, I should mention...) and finished almost exactly on time. I spoke to Stephanie after the presentation, and hope to come back next year and give a longer, hands-on version of this presentation. I think a bootcamp or lab would be great, as I really want to convey the information in this presentation in a much more "use this right away" format. Also, Windows Forensic Analysis 3/e is scheduled to be published early in 2012, and will provide a great foundation for the lab.

Slide Decks
I put the PDF versions of my presentations (in a zipped archive) up on Google Docs...you can find them here. I've also share the malware detection checklist I mentioned at the conference; keeping in mind that this is a living document, and I'd greatly appreciate feedback.

Links to Attendee's blogs:
Girl, Unallocated - It was great to put a face to a name, and hear how some folks name their blogs...
Journey into IR - It was great to finally meet Corey in person...
ForensicMethods - I'm looking forward to seeing Chad in Atlanta at DC3.

DF Analysis Lifecycle

2011-11-04T10:20:00.000-05:00

In an effort to spur some interest within the DFIR community (and specifically with the NoVA Forensics Meetup group) in engaging and sharing information, I thought it would be a good idea to point out "forensic challenges" or exercises that are available online, as well as to perhaps setup and conduct some exercises of our (the meetup group) own.

As I was thinking about how to do this, one thing occurred to me...whenever I've done something like this as part of a training exercise or engagement, many times the first things folks say is that they don't know how to get started. When I've conducted training exercises, they've usually been for mixed audiences..."mixed" in the sense that the attendees often aren't all just DF analysts/investigators; some do DF work part-time, some do variations of DF work (such as "online forensics") and others are SOC monitors and may not really do DF analysis.

As such, what I wanted to do was lay out the way I approach analysis engagements, and make that process available for others to read and comment on; I thought that would be a good way to get started on some of the analysis exercises that we can engage in going forward. I've included some additional resources (by no means is this a complete list) at the end of this blog post.

Getting Started
The most common scenario I've faced is receiving either a hard drive or an image for analysis. In many cases, it's been more than one, but if you know how to conduct the analysis of one image, then scaling it to multiple images isn't all that difficult. Also, acquiring an image is either one of those things that you can gloss over in a short blog post, or you have to write an entire blog post (or series of posts) on how to do it...so let's just start our examination based on the fact that we received an image.

Documentation
Documentation is the key to any analysis. It's also the hardest thing to get technical folks to do. For whatever reason, getting technical folks to document what they're doing is like herding cats down a beach. If you don't believe me...try it. Why it's so hard is up for discussion...but the fact of the matter is that proper documentation is an incredibly useful tool, and when you do it, you'll find that it will actually allow you to do more of the cool, sexy analysis stuff that folks like to do.

Document all the things!

Most often when we talk about documentation during analysis, we're referring to case notes, and as such, we need to document pretty much everything (please excuse the gratuitous meme) about the case that we're working on. This includes when we start, what we start with, the tools and processes/procedures we use, our findings, etc.

One of the documentation pitfalls that a lot of folks run into is that they start their case notes on a "piece of paper", and by the end of the engagement, those notes never quite make it into an electronic document. It's best to get used to (and start out) documenting your analysis in electronic format, particularly so your notes can be stored and shared. One means of doing so is to use Forensic CaseNotes from QCC. You can modify the available tabs to meet your needs. However, you can just as easily document what you're doing in MS Word; you can add bold and italics to the document to indicate headers, and you can even add images and tables (or embed Visio diagrams) to the document, if you need to.

The reasons why we document what we do are (1) you may get "hit by a bus" and another analyst may need to pick up your work, and (2) you may need to revisit your analysis (you may be asked questions about it) 6 months or a year later. I know, I know...these examples are used all the time and I know folks are tired of hearing them...but guess what? We use these examples because they actually happen. No, I don't know of an analyst who was actually "hit by a bus", but I do know of several instances where an analyst was on vacation, in surgery, or had left the organization, and the analysis had to be turned over to someone else. I also know of several instances where a year or more after the report was delivered to the customer, questions were posed...this can happen when you're engaged by LE and the defense has a question, or when you're engaged by an organization, and their compliance and regulatory bodies have additional questions. We often don't think much about these scenarios, but when they do occur, we very often finding ourselves wishing we'd kept better notes.

So, one of the questions I hear is, "...to what standard should I keep case notes?" Well, consider the two above scenarios, and keep your case notes such that (1) they can be turned over to someone else or (2) you can come back a year later and clearly see what you did. I mean, honestly...it really isn't that hard. For example, I start my case notes with basic case information...customer point of contact (PoC), exhibits/items I received, and most importantly, the goals of my exam. I put the goals right there in front of me, and have them listed clearly and concisely in their own section so that I can always see them, and refer back to them. When I document my analysis, I do so by including the tool or process that I used, and I include the version of the tool I used. I've found this to be critical, as tools tend to get updated. Look at EnCase, ProDiscover, or Mark Woan's JumpLister. If you used a specific version of a tool, and a year later that tool had been updated (perhaps even several times), then you'd at least have an explanation as to why you saw the data that you did.

Case notes should be clear and concise, and not include the complete output from every tool that you use or run. You can, however, include pertinent excerpts from tool output, particularly if that output leads your examination in a particular direction. By contrast, dumping the entire output of a tool into your case notes and including a note that "only the 3 of the last 4 lines in the output are important" is far from clear or concise. I would consider including information about why something is important or significant to your examination, and I've even gone so far as to include references, such as links to Microsoft KnowledgeBase articles, particularly if those references support my reasoning and conclusions.

If you keep your case notes in a clear and concise manner, then the report almost writes itself.

Now, I will say that I have heard arguments against keeping case notes; in particular, that they're discoverable. Some folks have said that because case notes are discoverable, the defense could get ahold of them and make the examiner's life difficult, at best. And yet, for all of these comments, no one has ever elaborated on this beyond the "maybe" and the "possibly". To this day, I do not understand why an analyst, as a matter of course, would NOT keep case notes, outside of being explicitly instructed to do so (i.e., to not keep case notes) by whomever you're working for.

Checklists
Often, we use tools and scripts in our analysis process in order to add some level of automation, particularly when the tasks are repetitive. A way to expand that is to use checklists, particularly for involved sets of tasks. I use a malware detection checklist that I put together based on a good deal of work that I'd done, and I pull out a copy of that checklist whenever I have an exam that involves attempting to locate malware within an acquired image. The checklist serves as documentation...in my case notes, I refer to the checklist, and I keep a completed copy of the checklist in the case directory along with my case notes. The checklist allows me to keep track of the steps, as well as the tools (and versions) I used, any significant findings, as well as any notes or justification I may have for not completing a step. For example, I won't run a scan for NTFS ADSs if the file system of the image is FAT.

The great thing about using a checklist is that it's a living document...as I learn and find new things, I can add them to the checklist. It also allows me to complete the analysis steps more thoroughly and completely, and in a timely manner. This, in turn, leaves me more time for things like conducting deep(er) analysis. Checklists and procedures can also be codified into a forensic scanner, allowing the "low hanging fruit" and artifacts that you've previously found to searched for quickly, thereby allowing you to focus on further analysis. If the scanner is designed to keep a log of it's activity, then you've got a good deal of documentation right there.

Remember that when using a checklist or just conducting your analysis, no findings can be just as important as an interesting finding. Let's say that you have a checklist that includes 10 steps, and of those, only 1 step finds anything interesting. Let's say you follow all 10 (again, purely arbitrary number, used only as an example) steps of your malware detection checklist, and only the ADS detection step finds anything of interest, but it turns out to be nothing. If you choose to not document the steps that had no significant findings, what does that tell another analyst who picks up your case, or what does it tell the customer who reads your report? Not much. In fact, it sounds like all you did was run a scan for ADSs...and the customer is paying how much for that report? Doing this makes whomever reads your report think that you weren't very thorough, when you were, in fact, extremely thorough.

One final note about checklists and procedures...they're a good place to start, but they're by no means the be-all-end-all. They're tools...use them as such. Procedures and checklists often mean the difference between conducting "Registry analysis" and getting it knocked out, and billing a customer for 16 hrs of "Registry analysis", with no discernible findings or results. If you run through your checklist and find something odd or interesting (for example, no findings), use that as a launching point from which to continue your exam.

Start From The End
This is advice that I've given to a number of folks, and I often get a look like I just sprouted a third eye in the middle of my forehead. What do you mean, "start at the end"? Well, this goes back to the military "backwards planning" concept...determine where you need to be at the end of the engagement (clear, concise report delivered to a happy customer), and plan backwards based on where you are now (sitting at your desk with a drive image to analyze). In other words, rather than sitting down with a blank page, start with a report template (you know you're going to have to deliver a report...) and work from there.

Very often when I have managed engagements, I would start filling in the report template while the analyst (or analysts) was getting organized, or even while they were still on-site. I'll get the executive summary knocked out, putting the background and goals (the exact same goals that the analyst has in their case notes) into the report, and replicating that information into the body of the report. That leaves the analyst to add the exhibits (what was analyzed) and findings information into the report, without having to worry about all of the other "stuff", and allows them to focus on the cool part of the engagement...the analysis. Using a report template (and using the same one every time), they know what needs to be included where, and how to go about writing their findings (i.e., clear and concise). As mentioned previously, the analysis steps and findings are often taken directly from the case notes.

What's the plan, Stan?
Having an analysis plan to start with can often be key to your analysis. Have you ever seen someone start their analysis by loading the image into an analysis application and start indexing the entire image? This activity can take a great deal of time, and we've all seen even commercial applications crash during this process. If you're going to index an entire image, why are you doing so? In order to conduct keyword searches? Okay...what's your list of keywords?

My point is to think critically about what you're doing, and how you're going to go about doing it. Are you indexing an entire image because doing so is pertinent to your analysis, or "because that's what we've always done"? If it's pertinent, that's great...but consider either extracting data from the image or making an additional working copy of the image before kicking off the indexing process. That way, you can be doing other analysis during the indexing process. Also, don't waste time doing stuff that you don't need to be doing.

Report Writing
No one likes to write reports. However, if we don't write reports, how do we get paid? How do we communicate our findings to others, such as the customer, or the prosecutor, or to anyone else? Writing reports should not be viewed as a necessary evil, but instead as a required skill set.

When writing your report, as with your case notes, be clear and concise. There's no need to be flowery and verbose in your language. Remember, you're writing a report that takes a bunch of technical information and very often needs to translate that into something a non-technical person needs to understand in order to make a business or legal decision. It's not only harder to make up new verbiage for different sections of your report, it also makes the finished product harder to read and understand.

When walking through the analysis or findings portion of the report (leading up to my conclusions), I've found that it's best to use the same cadence and structure in my writing. It not only makes it easier to write, but it also makes it easier to read. For example, if I'm analyzing an image in order to locate suspected malware, in each section, I'll list what I did ("ran AV scan"), which tools I used ("AV scanner blah, version X"), and what I found ("no significant/pertinent findings", or "Troj/Win32.Blah found"). I've found that when trying to convey technical information to a non-technical audience, using the same cadence and structure over and over often leaves the reader remembering the aspects of the report that you want them to remember. In particular, you want to convey that you did a thorough job in your analysis. In contrast, having each section worded in a significantly different manner not only makes it harder for me to write (I have to make new stuff up for each section), but the customer just ends up confused, and remembering only those things that were different.

Be professional in your reporting. You don't have to be verbose and use $5 words; in fact, doing so can often lead to confusion because you've used a big word incorrectly. Have someone review your report, and for goodness sake, run spell check before you send it in for review! If you run spell check and see a bunch of words underlined with red squiggly lines, or phrases underlined with green squiggly lines, address them. Get the report in for review early enough for someone to take a good look at it, and don't leave it to the last minute. Finally, if there's something that needs to be addressed in the report, don't tell your reviewer, "fine, if you don't like it, fix it yourself." Constructive criticism is useful and helps us all get better at what we do, but the petulant "whatever...fix it yourself" attitude doesn't go over well.

The report structure is simple...start with an executive summary (ExSumm). This is exactly as described...it's a summary for executives. It's not a place for you to show off how many really cool big words you know. Make it simple and clear...provide some background info on the incident, the goals of the analysis (as decided upon with the customer) and your conclusions. Remember your audience...someone non-technical needs a clear and concise one-pager (no more than 2) with the information that they can use to make critical business decisions. Were they compromised? Yes or no? There's no need to pontificate on how easily they had been compromised...just be clear about it. "A successful SQL injection attack led to the exposure of 10K records."

The body of the report should include background on the incident (with a bit more detail than the ExSumm), followed by the exhibits (what was analyzed), and the goals of the analysis. From there, provide information on the analysis you conducted, your findings, and your conclusions. The goals and conclusions from the body of the report should be identical...literally, copy-and-paste...from the ExSumm.

Finally, many reports include some modicum of recommendations...sometimes this is appropriate, other times it isn't. For example, if you're looking at 1 or 10 images, does that really give you an overall view into the infrastructure as a whole? Just because MRT isn't up-to-date on 5 systems, does that mean that the organization needs to develop and implement a patch management infrastructure? How do you know that they haven't already? This is the part of the report that is usually up for discussion, as to whether or not it's included.

Summary
So, my intention with this post has been to illustrate an engagement lifecycle, and to give an overview of what an engagement can look like, cradle-to-grave. This has by no means been intended to be THE way of doing things...rather, this is a way of conducting an engagement that has been useful to me, and I've found to be successful.

Resources
Chris Pogue's "Sniper Forensics: One Shot, One Kill" presentation from DefCon18
Chris Pogue's "Sniper Forensics v.3" from the most recent SecTor (scroll down)
TrustWave SpiderLabs "Sniper Forensics" blog posts (five posts in the series)
Girl, Unallocated On Writing
UnChained Forensics Lessons Learned
Brad Garnett's tips on Report Writing (SANS)
Computer Forensics Processing Checklist

Useful Analysis Tidbits
Corey's blog posts on exploit artifacts

Stuffy Updates

2011-11-03T10:38:00.000-05:00

Meetup
We had about 15 or so folks show up for last night's NoVA Forensics Meetup. I gave a presentation on malware characteristics, and the slides are posted to the NoVA4n6Meetup Yahoo group, if you want to take a look. Sorry about posting them the day of the meetup...I'm trying to get slides posted beforehand so that folks can get them and have them available.

One of the things I'd like to develop is interest in the meetup, and get more folks interested in showing up on a regular basis, because this really helps us develop a sense of community. Now, one of the things I've heard from folks is that the location isn't good for them, and I understand that...not everyone can make it. However, I do think that we likely have enough folks from the local area to come by on a regular basis, as well as folks who are willing to attend when they can. The alternative to the location issue is that instead of saying that the drive is too far, start a meetup in your local area. Seriously. The idea it develop a sense of community, which we don't get with "...I can't make it to the meetup because it's too far..."; starting a local meetup increases the community, rather than divide it.

I've also received some comments regarding what folks are looking for with respect to content. I like some of the ideas that have been brought up, such as having something a bit more interactive. However, I'd also like to see more of a community approach to this sort of thing...one person can't be expected to do everything; that's not "community". I really think that there as some good ideas out there, and if we have more folks interested in attending the meetups and actually showing up, then we can get the folks who want to know more about something in the same room as others who know more about that subject and may be willing to give a presentation.

Next month (7 Dec), we're going to be blessed with a presentation on mobile forensics from Sam Brothers. In order to bring more folks in, Cory Altheide suggested that we have a Google Plus (G+) hangout, so I'm going to look at bringing a laptop for that purpose, and also see about live tweeting during the presentation (and getting others to do so).

Finally, we confirmed that adult beverages are permitted at the ReverseSpace site, as long as everyone polices their containers. There didn't seem to be any interest this month in meeting for a pre-meetup warm-up at a nearby pub, so maybe for next month's meetup, some folks would consider bringing something to share. I know from experience what Sam likes, so maybe we can make the event just a bit more entertaining for everyone.

A couple of things to think about regarding the future of the meetups and the NoVA forensics community. First, I've talked to the ReverseSpace folks about the possibility of holding a mini forensics-con at their facility.

Second, what would be the interest in forensic challenges? We could use online facilities and resources to post not only the challenges, but also the results, and folks could then get together to discuss tools and techniques used. The great thing about having these available online is that folks who may not be able to make it to the meetups can also participate.

Finally, the last thing I wanted to bring up regarding the meetups is this...what are some thoughts folks have regarding available online resources for the meetups? I set up the Yahoo group, and I post meetup reminders to that group, as well as the Win4n6 group, to my blog, LinkedIn acct, and Twitter. After the Oct meetup, two LinkedIn groups were set up for the meetup. Even so, I just saw a tweet today where someone said that they just found out about the meetups via my blog. I'd like to hear some thoughts on how to get the word out, as well as get things posted (slide decks, challenges, reminders, announcements) and available in a way that folks will actually get the information. What I don't want to do is have so many facilities that no one knows what to use or where to go.

Memory Analysis
Melissa's got another post up on the SketchyMoose blog regarding Using Volatility: Suspicious Process. She's posted a couple of videos that she put together that are well worth watching. You may need to turn up the volume a bit (I did)...if you want to view the videos in a larger window, check out the SketchyMoose channel on YouTube.

Something I like about Melissa's post is that she's included reference material at the end of the post, linking to further information on some of what she discussed in the videos.

While we're on the topic of memory analysis, Greg Hoglund posted to the Fast Horizon blog; his topic was Detecting APT Attackers in Memory with Digital DNA. Yes, the post is vendor-specific, but it does provide some insight into what you can expect to see from these types of attackers.

Attack Vectors/Intel Gathering
When investigating an incident or issue, analysts are often asked to determine how the bad guy got in or how the infection occurred. Greg's post (mentioned above) refers to a threat that often starts with a spear phishing attack, which is based on open source intelligence gathering. The folks over at Open Source Research have posted on real-world pen-testing attack vectors, and believe me, it really is that easy. Back in '98-'99 when I was doing this kind of work myself, we'd use open source intel collection (which is a fancy way of saying we used Lycos and DogPile...the pre-Google stuff...searches) to start collecting information.

I think that if folks really started to look around, they'd be pretty surprised at what's out there. Starting at the company executive management site will give you some names to start with, and from there you can use that information and the company name itself to search for things like speaker bios, social networking profiles, etc. As suggested in one of the comments to the post, you can also check for metadata in documents available via the corporate site (also consider checking P2P networking infrastructures...you might be surprised at what you find...).

Documents aren't the only sources of information...keep in mind that images also contain metadata.

Intel Collection During Analysis
Funny how writing this post is progressing this morning...one section of the post leads to another. As I mentioned, during analysis we're often asked to determine how a system became compromised in the first place..."how did it happen?", where "it" is often a malware infection or someone having obtained unauthorized access to the system. However, there are often times when it is important to gather intelligence during analysis, such as determining the user's movements and activities. One way of doing this to see which WAPs the system (if it's a laptop) had connected to...another way to determine a user's movements is through smart phone backups. I recently posted some tools to the FOSS page for this blog that might help with that.

In addition, you can use Registry analysis to determine if a smart phone had been connected to the system, even if a management (iPhone and iTunes, BB and the BB Desktop Manager) application hadn't been used. From there you may find pictures or videos that are named based on the convention used by that device, and still contain metadata that points to such a device. In cases such as this, the "intelligence" may be that the individual had access to a device that had not been confiscated or collected during the execution of a search warrant.

OpenIOC
I recently commented on Mandiant's OpenIOC site, and what's available there. One of the things that they're sharing via this site is example IOCs, such as this one. There are a couple of things that I like about this sharing...one is that the author of the IOC added some excellent comments that give insight into what they found. I know a lot of folks out there in the DFIR community like that sort of thing...they like to see what other analysts saw, how they found it, tools and techniques used, etc. So this is a great resource for that sort of thing.

The IOCs are also clear enough that I can write a plugin for my forensic scanner that looks for the same thing. The scanner is intended for acquired images and systems accessed via F-Response, and doesn't require visibility into memory. However, the IOCs listed at the OpenIOC site have enough disk-based information in them (file system, Registry, etc.) that it's fairly easy to create a plugin to look for those same items.

Stuff

2011-11-02T08:55:00.001-05:00

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

Stuff

2011-10-30T07:26:00.000-05:00

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.

NoVA Forensics Meetup

2011-10-29T07:28:00.000-05:00

Reminder - our next NoVA Forensics Meetup is Wed, 2 Nov 2011...same Bat-time, same Bat-place.

Drop me an email or comment here if you're interested in meeting for a warm up at or just before 6pm.

Tools and Links

2011-10-27T07:12:00.000-05:00

Not long ago, I started a FOSS page for my blog, so I didn't have to keep going back and searching for various tools...if I find something valuable, I'll simply post it to this page and I won't have to keep looking for it. You'll notice that I really don't have much in the way of descriptions posted yet, but that will come, and hopefully others will find it useful. That doesn't mean the page is stagnant...not at all. I'll be updating the page as time goes on.

Volatility
Melissa Augustine recently posted that she'd set up Volatility 2.0 on Windows, using this installation guide, and using the EXE for Distorm3 instead of the ZIP file. Take a look, and as Melissa says, be sure to thoroughly read and follow the instructions for installing various plugins. Thanks to Jamie Levy for providing such clear guidance/instructions, as I really think that doing so lowers the "cost of entry" for such a valuable tool. Remember..."there're more things in heaven and earth than are dreamt of in your philosophy." That is, performing memory analysis is a valuable skill to have, particularly when you have access to a memory dump, or to a live system from which you can dump memory. Volatility also works with hibernation files, from whence considerable information can be drawn, as well.

WDE
Now and again, you may run across whole disk encryption, or encrypted volumes on a system. I've seen these types of systems before...in some cases, the customer has simply asked for an image (knowing that the disk is encrypted) and in others, the only recourse we have to acquire a usable image for analysis is to log into the system as an Admin and perform a live acquisition.

TCHunt
ZeroView from Technology Pathways, to detect WDE (scroll down on the linked page)

You can also determine if the system had been used to access TrueCrypt or PGP volumes by checking the MountedDevices key in the Registry (this is something that I've covered in my books). You can use the RegRipper mountdev.pl plugin to collect/display this information, either from a System hive extracted from a system, or from a live system that you've accessed via F-Response.

Timelines
David Hull gave a presentation on "Atemporal timeline analysis" at the recent SecTorCA conference (can find the presentation .wmv files here), and posted an abridged version of the presentation to the SANS Forensic blog (blog post here).

When I saw the title, the first thing I thought was...what? How do you talk about something independent of time in a presentation on timeline analysis? Well, even David mentions at the beginning of the recorded presentation that it's akin to "asexual sexual reproduction"...so, the title is meant to be an oxymoron. In short, what the title seems to refer to is performing timeline analysis during an incident when you don't have any sort of time reference from which to start your analysis. This is sometimes the case...I've performed a number of exams having very little information from which to start my analysis, but finding something associated with the incident often leads me to the timeline, providing a significant level of context to the overall incident.

In this case, David said that the goal was to "find the attacker's code". Overall, the recorded presentation is a very good example of how to perform analysis using fls and timelines based solely on file system metadata, and using tools such as grep() to manipulate (as David mentions, "pivot on") the data. In short, the SANS blog post doesn't really address the use of "atemporal" within the context of the timeline...you really need to watch the recorded presentation to see how that term applies.

Sniper Forensics
Also, be sure to check out Chris Pogue's "Sniper Forensics v3.0: Hunt" presentation, which is also available for download via the same page. There are a number of other presentations that would be very good to watch, as well...some talk about memory analysis. The latest iteration of Chris's "Sniper Forensics" presentations (Chris is getting a lot of mileage from these things...) makes a very important point regarding analysis...in a lot of a cases, an artifact appears to be relevant to a case based on the analyst's experience. A lot of analysts find "interesting" artifacts, but many of these artifacts don't relate directly to the goals of their analysis. Chris gives some good examples of an "expert eye"; in one slide, he shows an animal track. Most folks might not even really care about that track, but to a hunter, or someone like me (ride horses in a national park), the track tells me a great deal about what I can expect to see.

This applies directly to "Sniper Forensics"; all snipers are trained in observation. Military snipers are trained to quickly identify military objects, and to look for things that are "different". For example, snipers will be sent to observe a route of travel, and will recognize freshly turned earth or a pile of trash on that route when the sun comes up the next day...this might indicate an attempt to hide an explosive device.

How does this apply to digital forensic analysis? Well, if you think about it, it is very applicable. For example, let's say that you happen to notice that a DLL was modified on a system. This may stand out as odd, in part because it's not something that you've seen a great deal of...so you create a timeline for analysis, and see that there wasn't a system or application update at that time.

Much like a sniper, a digital forensic analyst must be focused. A sniper observes an area in order to gain intelligence...enemy troop movements, civilian traffic through the area, etc. Is the sniper concerned with the relative airspeed of an unladen swallow? While that artifact may be "interesting", it's not pertinent to the sniper's goals. The same holds true with the digital forensic analyst...you may find something "interesting" but how does that apply to your goals, or should you get your scope back on the target?

Data Breach 'Best Practices'
I ran across this article recently on the GovernmentHealthIT site, and while it talks about breach response best practices, I'd strongly suggest that all four of these steps need to be performed before a breach occurs. After all, while the article specifies PII/PHI, regulatory and compliance organizations for those and other types of data (PCI) specifically state the need for an incident response plan (PCI DSS para 12.9 is just one example).

Item 1 is taking an inventory...I tell folks all the time that when I've done IR work, one of the first things I ask is, where is your critical data. Most folks don't know. A few that have have also claimed (incorrectly) that it was encrypted at rest. I've only been to one site where the location of sensitive data was known and documented prior to a breach, and that information not only helped our response analysis immensely, it also reduced the overall cost of the response (in fines, notification costs, etc.) for the customer.

While I agree with the sentiment of item 4 in the article (look at the breach as an opportunity), I do not agree with the rest of that item; i.e., "the opportunity to find all the vulnerabilities in an organization—and find the resources for fixing them."

Media Stuff
Brian Krebs has long followed and written on the topic of cybercrime, and one of his recent posts is no exception. I had a number of take-aways from this post that may not be intuitively obvious:

1. "Password-stealing banking Trojans" is ambiguous, and could be any of a number of variants. The "Zeus" (aka, Zbot) Trojan is mentioned later in the post, but there's no information presented to indicate that this was, in fact, a result of that specific malware. Anyone who's done this kind of work for a while is aware that there are a number of malware variants that can be used to collect online banking credentials.

2. Look at the victims mentioned in Brian's post...none of them is a big corporate entity. Apparently, the bad guys are aware that smaller targets are less likely to have detection and response capabilities (*cough*CarbonBlack*cough*). This, in turn, leads directly to #3...

3. Nothing in the post indicates that a digital forensics investigation was done of systems at the victim location. With no data preserved, no actual analysis was performed to identify the specific malware, and there's nothing on which law enforcement can build a case.

Finally, while the post doesn't specifically mention the use of Zeus at the beginning, it does end with a graphic showing detection rates of new variants of the Zeus Trojan over the previous 60 days; the average detection rate is below 40%. While the graphic is informative,

More Media Stuff
I read this article recently from InformationWeek that relates to the recent breach of NASDAQ systems; I specifically say "relates" to the breach, as the article specifies, "...two experts with knowledge of Nasdaq OMX Group's internal investigation said that while attackers hadn't directly attacked trading servers...". The title of the article includes the words "3 Expected Findings", and the article is pretty much just speculation about what happened, from the get-go. In fact, the article goes on to say, "...based on recent news reports, as well as likely attack scenarios, we'll likely see these three findings:". That's a lot of "likely" in one sentence, and this much speculation is never a good thing.

My concern with this is that the overall take-away from this is going to be "NASDAQ trading systems were hit with SQL injection", and folks are going to be looking for this sort of thing...and some will find it. But others will miss what's really happening while they're looking in the wrong direction.

Other Items
F-Response TACTICAL Examiner for Linux now has a GUI
Lance Mueller has closed his blog; old posts will remain, but no new content will be posted

Stuff in the Media

2011-10-20T07:36:00.000-05:00

Now and again, I run across some interesting articles available through various media sources. Back in the days when I was doing vulnerability assessments ('98-ish), we used to listen to what our contact said when we went onsite, and try to guess which magazines and journals he had open in his office...usually, we'd hear our contact using keywords from recent articles.

Terry Cutler, CTO of the Canadian firm Digital Locksmiths, had an interesting article published in SecurityWeek recently. The article is titled, "You've been hacked. Now what?", and provides a fictional...albeit realistic...description of what happens when an incident has been identified. A lot of what is described in the article appears to have been pulled from either experience (IR is not listed as an available service on the company web site) or from "best practices". For example, in the article, the assumption appears to be made that if a compromise occurs, corporate cell phones must be assumed to have been compromised (with respect to calls...email wasn't mentioned).

The article talks about not disconnecting systems, which in many cases is counter to what most victims of a compromise want to do right away. However, I completely agree with this...unfortunately, the article doesn't expand beyond that statement to say what you should do.

Now, what I do NOT agree with is the statement in the article that you should "get help from an ethical hacker". First off, given the modern usage of the term "hacker", the phrase "ethical hacker" is an oxymoron...like "jumbo shrimp". While I do agree that some of the folks performing "ethical hacking" are good at getting into your network (as stated in the article, "Ethical hackers are experts at breaking into your system the same way a hacker will."), I don't agree that this necessarily makes them experts at protecting networks, or more importantly, scoping the incident and determining where the attack came from.

In the years that I have been an incident responder, the one thing that consistently makes me a cringe is when I hear someone say, "...if I were the hacker, this is what I would have done." Folks, where that thinking takes you can be irrelevant, or worse, can send your responders chasing way down rabbit holes. Think CSI, and go where the evidence takes you. I've seen instances where the intruder had no idea what organization he'd compromised and simply meandered about, leaving copious and prolific artifacts of his activity on all systems he touched. I've also seen SQL injection attacks where, once in, the intruder was very focused in what they were looking for. Sometimes, it's not so much about the corporate assets as it is loading keystroke loggers on user systems in order to harvest online banking credentials.

What you should be doing is collecting data and following the evidence, using the information you've collected to make educated, reasoned determinations as to where the intruder is going and what they are doing. Do not make the assumption that you can intuit the attackers intentions...you may never know what these are, and you may chase down rabbit holes that lead to nowhere. Instead, focus on what the data is telling you. Is the intruder going after the database server? Were they successful?

The best way to go about establishing an organic capability for this sort of work (at least, for tier 1 and/or 2 response) is to establish a relationship with a trusted adviser, someone who has experience in incident response and digital forensics, and can guide you through the steps to building that organic capability for immediate response.

At this point, you're probably wondering what I mean by "organic", and why "immediate response" is something that seems so necessary. Well, consider what happens during a "normal" incident response; the "victim" organization gets notified of the incident (usually by an external third party), someone is contacted about providing response services, contract negotiations occur, and then at some time in the future, responders arrive and start to learn about your infrastructure so that they can begin collecting data.

The way this should be occurring is that data collection begins immediately, with incident identification as the trigger...if this doesn't happen, critical data is lost and unrecoverable. The only way to do this is to have someone onsite trained in how to perform the data collection.

A lot of local IT staff look at consultants as the "experts" in data collection, and very often don't realize that before collecting data, those "experts" ask a LOT of questions. Most often, the consultants called onsite to provide IR capabilities are, while knowledgeable, not experts at networking, and they are definitely not experts in YOUR infrastructure and environment.

I'm not even talking about getting to prosecution at this point...all I'm talking about is that data that is necessary to determine what happened, what data may have been compromised is quickly decaying, and if steps are not taken to immediately collect and preserve this data, there very likely will be a significant detrimental impact on the organization. Now, the only reason that this isn't being done now is because onsite IT staff don't have the training. So, work with that trusted adviser and develop a process and a means for collecting the necessary data, and documenting it all.

Going back to the SecurityWeek article, I completely agree...don't disconnect the system as your first act. Instead, have the necessary tools in place and your folks trained in what to do...for example, collect the contents of physical memory first, and then do what you need to do. This may be to disconnect the system from the network (leaving it powered on), or making an emergency modification to a switch or firewall rule in order to isolate the system in another manner. If the system is boot-from-SAN, you may also want to (for example) have a means in place for acquiring an image of the system before shutting it down. Regardless of what needs to be done, be sure that you have a documented process for doing it, one that allows for pertinent data, as well as business processes, to be preserved.

Ever wondered, during an incident, what kind of person (or people) you're working against? This eWeek article indicates that the impression that hackers are isolated, socially-inept "lone wolf" types is incorrect; in fact, according to the article, "hackers" are very social, sharing exploits, techniques and even providing tutorials. Given this, is it any wonder why folks on the other side of the fence are constantly promoting sharing? The bad guys do it because it makes sense, and makes them better...so why aren't we doing more of it?

Links, Updates, and WhatNot

2011-10-19T07:16:00.001-05:00

Malware
Evild3ad has an excellent writeup of the Federal (aka, R2D2) Trojan via memory analysis using Volatility. The blog post gives a detailed walk-through of the analysis conducted, as well as the findings. Overall, my three big take-aways:

1. An excellent example of how to use Volatility to conduct memory analysis.
2. An excellent example of case notes.
3. Detailed information that can be used to create a plugin for either RegRipper, or a forensic scanner.

There is also a link to a Rar archive containing the memory image at the site, so you can download it and try running the commands listed in the blog post against the same data.

M-Trends
The Mandiant M-Trends 2011 report is available...I received a copy yesterday and started looking through it. Very interesting information in the report...as a host-based analysis guy, I found some of the information on persistence mechanisms (starting on pg 11 of the report) to be very interesting. Some may look at the use of Windows Services and the ubiquitous Run key as passe, but the fact is that these persistence mechanisms work. After all, when the threat actors compromise an infrastructure, they are not trying to remain hidden from knowledgeable and experienced incident responders.

Interestingly, the report includes a side note that the authors expect to see more DLL Search Order Hijacking used as a persistence mechanism in the future. I tend to agree with the statement in the report, given that (again, as stated in the report) that this is an effective technique that is difficult to detect.

Another interesting persistence mechanism described in the report was services.exe being modified (without changing the size of the binary) to point to an additional (and malicious) DLL. This technique has been seen being used with other binaries, including other DLLs.

A major section (section III) of the report discusses visibility across the enterprise; I think that this is an extremely important issue. As I've performed incident response over the years, a common factor across most (if not all) of the incidents I've responded to has been a lack of any infrastructure visibility whatsoever. This has been true not only for initial visibility into what goes on on the network and hosts, but it has also affected response capabilities. Network- and host-based visibility of some kind needs to be achieved by all organizations, regardless of size, etc. I mean, think about it...any organization that produces something has some sort of visibility into processes that are critical to the business, right? A company that manufactures widgets has controls in place to ensure that the widgets are produced correctly, and that they're shipped...right? I mean, wouldn't someone notice if trucks weren't leaving the loading docks? So why not have some sort of visibility into the medium where your critical information assets are stored and processed?

Looking at the information provided in the M-Trends report (as well as other reports available from other organizations), I can see the beginning an argument for incident preparation being built up; that is to say that while the report may not specifically highlight this (the M-Trends report mentions the need for "...developing effective threat detection and response capabilities..."), it's clear that the need for incident preparation has existed for some time, and will continue to be an issue.

Addendum: Pg 13 of the M-Trends report mentions some "interesting" persistence mechanisms being used, one of which is "use of COM objects"; however, the rest of the report doesn't provide much of a description of this mechanism. Well, I ran across this post on the ACROS Security Blog that provides some very good insight into using COM objects for persistence. Both attacks described are something of a combination of the use of COM objects and the DLL Search Order hijacking, and very interesting. As such, there needs to be tools, processes, and education of analysts in these techniques so that they can be recognized or at least discovered through analysis. I would suggest that these techniques have been used for some time...it's simply that most of us may not have known to (or "how to") look for them.

Resources
Verizon DBIR
TrustWave GSR

Incident Preparation
I recently gave a talk on incident preparation at ETCSS, and overall, I think it was well received. I used a couple of examples to get my point across...boxing, fires in homes...and as the gears have continued to turn, I've thought of another, although it may not be as immediately applicable or understandable for a great many folks out there.

Having been a Marine, and knowing a number of manager- and director-types that come from prior military experience, I thought that the USS Cole would be a great example of incident preparation. The USS Cole was subject to a bombing attack on 12 October 2000, and there were 56 casualties, 17 of which were fatalities. The ship was stuck by a bomb amidships, and a massive hole was torn in her side, part of which was below the waterline. However, the ship did not sink.

By contrast, consider the RMS Titanic. On 15 April 1912, the Titanic struck an iceberg and shortly thereafter, sank. According to some sources, a total of six compartments were opened to the sea; however, the design of the Titanic was for the ship to remain afloat with only the first four compartments opened to the sea. As the weight of the water pulled the ship down, more water was allowed to flood the ship, which quickly led to her sinking.

So, what does this have to do with incident preparation and response? Both ships were designed with incidents in mind; i.e., it was clear that the designers were aware that incidents, of some kind, would occur. The USS Cole had some advantages; better design due to a better understanding of threats and risk, a better damage control team, etc. We can apply this thinking to our current approach to infrastructure design and assessments.

How would the USS Cole have fared had, at the time of the bombing, they not had damage control teams and sailors trained in medical response and ship protection? What would have happened, do you think, if they'd instead done nothing, and gone searching for someone to call for help?

My point in all this goes right back to my presentation; who is better prepared to respond to an incident - the current IT staff on-site, who live and work in that environment every day, or a consultant who has no idea what your infrastructure looks like?

Determining Quality
Not long ago, I discussed competitive advantage and how it could be achieved, and that got me to thinking...when a deliverable is sent to a customer of DFIR services, how do they (the customer) judge or determine the quality of the work performed?

Over the years, I've had those engagements where a customer says, "this system is infected", but when asked for specifics regarding why they think it was infected, or what led them to think it was infected, most often don't have anything concrete to point to. I'll go through, perform the work based on a malware detection checklist and very often come up with nothing. I submit a report detailing my work activity and findings, which leads to my conclusions of "no malware found", and I simply don't hear back.

Consulting is a bit different from the work done in LE circles...many times, the work you do is going to be reviewed by someone. The prosecution may review it, looking for information that can be used to support their argument, and the defense may review it, possibly to shoot holes in your work. This doesn't mean that there's any reason to do the work or reporting any differently...it's simply a difference in the environments.

So, how does a customer (of consulting work) determine the quality of the work, particularly when they've just spent considerable money, only to get an answer that contradicts their original supposition? When they receive a report, how do they know that their money has been well-spent, or that the results are valid? For example, I use a checklist with a number of steps, but when I provide a report that states that I found no indication of malware on the system, what's the difference between that and another analyst who simply mounted the image as a volume and scanned it with an AV product?

Attacks
If you haven't yet, you should really consider checking out Corey's Linkz about Attacks post, as it provides some very good information regarding how some attacks are conducted. Corey also provides summaries of some of the information, specifically pointing out artifacts of attacks. Most of them are Java-based, similar to Corey's exploit artifact posts.

This post dovetails off of a comment that Corey left on one of my posts...

I've seen and hear comments from others about how it's difficult (if not impossible) and time consuming to determine how malware ended up on the system.

Very often, this seems to be the case. The attack or initial infection vector is not determined, as it is deemed too difficult or time consuming to do so. There are times when determining the initial infection vector may be extremely difficult, such as when the incident is months old and steps have been taken (either by the attacker or local IT admins) to clean up the indicators of compromise (IoCs). However, I think that the work Corey has been doing (and providing the results of publicly) will go a long way toward helping analysts narrow down the initial infection vector, particular those who create detailed timelines of system activity.

Consulting
Hal Pomeranz has an excellent series of posts regarding consulting and issues that you're likely to run into and have to address if you go out on your own. Take a look at part 1, 2, 3, and 4. Hal's provided a lot of great insight, all of which comes from experience...which is the best teacher! He also gives you an opportunity to learn from his mistakes, rather than your own...so if you're thinking about going this route, take a look at his posts.

Links

2011-10-14T07:03:00.001-05:00

Carbon Black

I recently gave a presentation at ETCSS, during which we discussed the need for incident preparedness in order to improve the effect of incident response efforts. In that presentation, I mentioned and described Carbon Black (Cb), as well as how it can be used in other ways besides IR.

While I was traveling to the venue, Cb Enterprise was released. Folks, if you don't know what Carbon Black is, you really should take a look at it. If you use computers in any capacity beyond simply sitting at a keyboard at your house...if you're a dentist's office, hospital, law firm, or a national/global business...you need to take a good hard look at Cb. Cb is a small, light-weight sensor that monitors execution on a system...remember Jesse Kornblum's Rootkit Paradox paper? The paradox of rootkits is that they want to hide, but they must run...the same is true with any malware. Cb monitors program execution on Windows systems. The guys at Cb have some great examples of how they've tracked down a three-stage browser drive-by infection in minutes, where it may have taken an examiner doing just disk forensics days to locate the issue.

If you have and use computers, or you have customers who do, you should really take a hard look at Cb and consider deploying it. Seriously...check out the site, give the Kyrus Tech guys a call, and take a good hard look at what Cb can do for you. I honestly believe that Cb is a game changer, and the Kyrus Tech guys have demonstrated that it is, indeed, a game changer, but not just for IR work.

Timeliner
Jamie Levy has posted documentation and plugins for her OMFW talk (from last July) regarding extracting timeline data from a memory dump using the Volatility framework. This is a great set of plugins for a great memory analysis framework, folks. What's really cool is that with a little bit of programming effort, you can modify the output format of the plugins to meet your needs, as well. A greatbighuge THANKS to Jamie for providing these plugins, and for the entire Volatility team/community for a great memory analysis framework.

Exploit Artifacts
Speaking of timelines...Corey has posted yet another analysis of exploit artifacts, this one regarding a signed Java applet. This is a great project that Corey works on, and a fantastic service that he's providing. Using available tools (i.e., MetaSploit), he compromises a system, and then uses available tools and techniques (i.e., timeline analysis) to demonstrate what the artifacts of the exploit "look like" from the perspective if disk analysis. Corey's write-up is clear and concise, and to be honest, this is what your case notes and reports should look like...not exactly, of course, but there are lot of folks that use the "...I don't know what standard to write to..." as an excuse to not do anything. Look at what Corey's done here...don't you think that there's enough information to replicate what he did? Does that work as a standard?

Also, take a look at the technique Corey used for investigating this issue...rather than posting a question online, he took steps to investigate the issue himself. Rather than starting with an acquired image and a question (as is often the case during an exam), he started with just a question, and set out to determine an answer. Information like this can be extremely valuable, particular when it comes to determining things such as the initial infection vector of malware or a bad guy, and a good deal of what he's provided can be added to an exam checklist or a plugin for a forensic scanner. I know that I'm going to continue to look for these artifacts...a greatbighuge THANKS to Corey, not just for doing this sort of work, but posting his results, as well.

DFF
DFF 1.2 is available for download. Take a look at this for a list of the updates; check out batch mode. Sorry, I don't have more to write...I just haven't had a chance to dig into it yet.

Community
One of the things I see a great deal of, whether it's browsing the lists or reading questions that appear in my inbox, is that when asking questions regarding forensic analysis, many of us still aren't providing any indication of the operating system that we're analyzing. Whether its an application question (P2P, FrostWire, a question about MFT entries, etc.), many of us are still asking the questions without identifying the OS, and if it's Windows, the version.

Is this important at all? I would suggest that yes, it is. The other presentation I gave at ETCSS (see the Carbon Black entry above) was titled What's new in Windows 7: An analyst's perspective. During this presentation, we discussed a number of differences, specifically between Windows XP and Win7, but also between Vista and Win7. Believe it or not, the version of Windows does matter...for example, Windows 2003 and 2008 do not, by default, perform application prefetching (although they can be configured to do so). With Windows XP, the searches a user executed from the desktop were recorded in the ACMru key; with Vista, the searches were NOT recorded in a Registry key (they were/are maintained in a file); with Windows 7, the search terms are maintained in the WordWheelQuery key.

Still not convinced? Try analyzing a Windows 7 memory dump with Volatility, but don't use the Windows 7 profile.

So, it you're asking a question that has to do with file access times, then the version of Windows is very important...because as of Vista, by default, updating of last access times on files is disabled. This functionality can be controlled by a Registry value, which means that this functionality can also be disabled on Windows XP systems.

I also see a number of questions referring to various applications, many of which are specific to P2P applications. Different applications behave differently...so saying, "I'm doing a P2P investigation" doesn't really provide much information if you're looking for assistance. I mean, who's going to write an encyclopedic if/then loop with all of the possibilities? Not only is the particular application important, but so is the version...for the same reasons that the OS version is important. I've dealt with older versions of applications, and what those applications do, or are capable of doing, can be very important to an investigation...that is, unless you're planning to fill in the gaps in your investigation with speculation.

In short, if you've got a question about something, be sure to provide relevant background information regarding what you're looking at...it can go a long way toward helping someone answer that question and provide you with assistance.

Tools
I've started a new page for my blog, listing the FOSS forensic tools that I find, come across, get pointed to, and use. It's a start...I have a good deal of catching up to do. I've started listing the tools, and provided some descriptions...I'll be updating the tools and descriptions as time goes on. This is mostly a place for me to post tools and frameworks so that I don't have to keep going back and searching through my blog for something, but feel free to stop by and take a look, or email me a tool that you like to use, or site with several tools.

Endorsements
One final thing...and this is for Mr. Anonymous, who likes to leave comments to some of my blog posts...I get no benefit, monetarily or otherwise, for my comments or endorsement of Volatility, nor for DFF...or any other tool (FOSS or otherwise) for that matter. I know that in the past, you've stated that you "...want to make sure that it is done with the right intentions". Although you've never explicitly stated what those intentions are, I just wanted to be up front and clear...I have used these tools, and I see others discovering great benefit from them, as well...as such, I think that it's a great idea to endorse them as widely as possible, so that others don't just see the web site, but also see how they can benefit from using these tools. I hope that helps.

NoVA Forensic Meetup

2011-10-06T07:27:00.000-05:00

Last night's meetup went very well! I'd like to thank Brian Rydstrom for providing a very good presentation on Mobile Forensics...I don't do any forensics of mobile devices, so I found the information very valuable.

I'd also like to thank everyone who showed up last night. Attendance was very good...we had about 28 people show up, and a lot of interaction and questions. Per usual, we had a couple of core regulars, as well some new folks who took time out to stop by.

So, Mitch Harris has graciously offered to provide part 2 of his botnets presentation ("Botnets 201") next month (Nov), and Sam Brothers is still on-board to provide December's presentation on "Mobile Forensics". We also had a request for a presentation on SSD forensics, as well as someone who offered to give such a presentation early next year (TBD). I did find this blog post that discusses SSDs.

We had a couple of additional requests last night, as well. One was for something a bit more hands-on...I'm sure that we could do something like that. Brian offered to set up a LinkedIn group for the meetup, so that folks could see a bit more about the professional backgrounds of the other attendees. We're also looking for something more stable for providing announcements and copies of presentations...seems that Yahoo groups aren't for everyone.

The other request was for something along the lines of "gorilla forensics", or perhaps more appropriately "Sniper Forensics". I don't think I want to steal Chris's thunder (not that I could if I tried...), but maybe we can come up with something along the lines of "the essentials of DF investigations". I think that this would end up being an interesting discussion, particularly when it comes to the topic of maintaining case notes.

Again, thanks to everyone who was able to make it last night, and thanks to the ReverseSpace guys for hosting us.

Forensic Scanner

2011-10-05T08:35:00.000-05:00

With the manuscript for WFA 3/e submitted, I have time now to focus on other projects (while I wait for the proofs to review), including the next step for or next generation of RegRipper, which is something I call the "forensic scanner"...for now, anyway, until I come up with a really cool name for it. All new projects need a cool name, right?

As I work on developing this project, I wanted to share some of the thoughts behind it, in part to see if they make sense, but also to show the direction of the project.

Why?
Why have a "forensic scanner" at all? That's a great question. Other areas of information security have scanners...when I started my infosec career after leaving the military, I used ISS's Internet Scanner. Consider Nessus, which was the inspiration behind the design for RegRipper. And there are others...the idea being that once you've discovered some artifact or "check", you can automate that check for future use, without having to memorize the specifics. After all, by creating a "plugin" for the check, you're documenting it. Another strength of something like this is that one analyst can create a check, documenting the plugin, and provide it to others, sharing that information so that those other analysts don't have to have the same experiences. This way, a team can focus on analysis and benefit from the analysis performed by others.

Look at it this way...do you want to do the same checks that you always do for malware, manually? Let's say that a customer believes that a system is infected with Zeus/ZBot...do you want to manually check for sdra64.exe every time? What about the persistence mechanism? What if the persistence mechanism is the same, but the file name has changed? What if you could automate your entire malware detection checklist? Most forensic analysts are familiar with the detection rates of AV products, and sometimes it's a matter of looking not for the malware itself, but rather the effects that the malware had on it's ecosystem...what if you could automate that?

Purpose
The purpose of the forensic scanner is not to replace anything that's already out there, but instead to augment what's currently available. For instance, the Digital Forensics Framework (DFF) was recently updated to version 1.2 and includes some great features, none of which the forensic scanner includes (i.e., search, etc.). The forensic scanner is a targeted tool with a specific purpose, and not a general analysis framework. Instead, much like other scanners (Nessus, ISS's Internet Scanner, etc.), the forensic scanner is intended to fill a gap; using frameworks and applications (ProDiscover, etc.), analysts will find artifacts and indicators of compromise, and then document them as plugins as a means of automation. Then whenever the scanner is run against an acquired image, checks for those artifacts, as well as processing and even inclusion of references, are run automatically. This is intended to quickly allow the analyst to analyze, by running checks that have already been discovered. Learn it once, document it, run it every time.

Scanner Attributes
Here are some of the forensic scanner attributes that I've come up with:

Flexibility - From the beginning, I wanted the scanner to be flexible, so I designed it to be run against a mounted volume. You're probably wondering, "how is this flexible?" Well, how can you mount a volume, particularly in read-only mode? You can convert a raw/dd image to a .vhd file (using vhdtool.exe, or the VirtualBox convertfromraw command), and mount that .vhd file read-only via the Disk Management tool. You can use FTK Imager, ImDisk, or another image mounting tool. You can also connect to a remote system via F-Response and run the scanner. You can mount an image by converting it to a .vmdk file, and mount is as an independent, non-persistent hard drive. Using either the .vhd or .vmdk methods, you can also mount VSCs as volumes and scan those; as with RegRipper, a CLI engine for the scanner can be included in a batch file to automate the scans.

Even though I'm writing the plugins that I'm using for Windows, there's nothing that really restricts me to that platform. The scanner is written in Perl, and can be run from Linux or MacOS X (the GUI would require the appropriate modules, of course...) and run against pretty much any mounted volume.

Force Multiplier - One of the things I really like about RegRipper is the ability to write my own plugins. So, let's say I find something of interest...I write a plugin for it. I can (and do) include appropriate references (i.e., to malware write-ups, MS KB articles, etc.) in the comments of the plugin, or even have those spit out in the output. I can even add an explanation to the plugin itself, in the comments, describing the reasoning behind the plugin, why it was written, and how to use or interpret the output. That plugin then persists, along with the documentation. This plugin can then be shared amongst analysts, increasing their capability while reducing their need to experience the same analysis I did to zero. So, let's say I find something that I'd never seen before and it took me 10 hrs of dedicated analysis to find it. If there are 5 other analysts on my team (and we're all of approximately equal skill levels), and I share that plugin with all of them, then I've just added to their capability and saved the team 50 hrs of dedicated work.

This section could also be referred to as Preservation of Corporate Knowledge or Competitive Advantage, depending on who you are. For example, both LE and private industry consultants benefit from retaining corporate knowledge; also, LE would greatly benefit from any plugins shared by private industry.

Knowledge Retention
Within the private sector, the information security industry can be fluid. Analysts have changes in their lives, or develop new skills (or want to do so) and move on. Having a means of documenting and retaining their experiences within the environment can be valuable; have a means of incorporating that knowledge directly into the field can be critical. It's one thing for an analyst to talk about something they found, or write a white paper...it's something else entirely to have a forensic analyst write a dozen or so plugins throughout their tenure and have those available for use, by all of the other analysts, well after he or she has left.

LE experiences something similiar; many times, an analyst receives training, works on some cases, and is then off to do other LE things. And often, their wealth of knowledge leaves with them. With a framework such as the forensic scanner, not only is an individual analyst's knowledge retained, but it can be provided other analysts, even ones that haven't been hired or completely trained.

Competitive Advantage is usually associated with private industry consulting firms, but I'm sure that you can see how this would apply. Any analyst who finds something and documents it through a plugin can then share that plugin with others...100% capability for 0 experience; the time-to-market for the capability is pretty much as long as it takes to open an email and extract the plugins from an attached archive. Ideally, you'd want to have an "armorer", like a lab tech or analyst who either gets information from other analysts and writes and tests the plugins, or receives the plugins and tests them before rolling them out. The approved plugins can be placed in an archive and emailed to analysts, or you can use some form of distribution mechanism that each analyst initiates.

Self-Documenting - The forensic scanner has an interesting feature that I'm carrying over from RegRipper - when running, it produces an activity log, collecting information about the scanned volume and tracking the plugins that were run. So, not only will your output make it clear what the results of the scan were, but the activity log can tell you exactly which versions of the plugins had been run; if there's a plugin that wasn't run, or an updated version of a plugin comes out, you can simply re-run the scan.

This information can also be used from a debugging standpoint. If something didn't work as planned, why was that? How can the process be improved?

Common Format - One of the things that we're all familiar with how there are a number of tools out there that parse information for us, but these tools all have different output formats, and it can be a very manual process to work through Prefetch files, Jump Lists, etc., and have to manually convert all of that information into a common output format. Even if we get several tools from the same site and author, and we can format the output in .csv or .xml, we still have to run the tools, and manage the output. Using the scanner, the plugins will handle the output format. I can write one plugin, and have .csv output...then modify the output in another version of the plugin to .tln output, and include each plugin in the appropriate scanner profile.

Plugins
When scanning a mounted volume, the engine exports a number of variables that you can use to tailor your plugins; however, as the target is a mounted volume, there is no proprietary API that you need to learn. Want to get a list of files in a directory? Use the standard opendir(), readdir(), and closedir() function that ship with Perl. What this means is that learning to write plugins is as easy as learning to program in Perl, and if you don't know (or want to learn) how to program in Perl, that's okay...find someone who does and buy them a beer.

The plugins can also be flexible, ranging from the broad to the narrowly-focused. An example of a broad plugin might be one that scans the Windows\Temp (or the user's Temp) folder for PE files. I know how tedious something like that can be...particularly with a reprovisioned system that has a dozen or more user accounts on it...but how would you like to have a report of all of the .tmp files in all of the user's Temp folders that are actually PE files?

A plugin that's a bit more tactical might be one that looks for a specific file, such as ntshrui.dll in the C:\Windows directory. The "strategic" variant of that plugin might be one to list all of the DLLs in the Windows directory.

However, plugins don't have to be just Perl; using Perl functions, you can also create plugins to run external commands. For example, you can use strings and find to parse through the pagefile, and retain the output. Or you can run sigcheck. Using Perl functions that allow you to launch external commands, you can automate running (and processing/parsing the output of) external commands against the mounted volume.

Deploying the Scanner
I alluded to some of the deployment scenarios for the scanner earlier in this post, but I'll reiterate some of them here because I think they're important.

When I was on the IBM response team (and the ISS team before that), each responder had two MacBooks that we had in our jump kits, as well as Mac Server in our office; lots of horsepower, with a reduced form factor and weight (over the comparable Dell Latitudes). I opted to primarily run Windows, as I wanted to be as familiar with the most predominant platform that we encountered. Our team was also geographically dispersed. So how would something like the scanner be deployed in such an environment?

Now, if we had a central intake point, such as a lab were images were received and processed (image file system verified, documented, and a working copy made to a storage facility) by a lab tech, the scanner could be deployed to and maintained by the lab tech. Once an image was processed, the working copy could be scanned, and the analyst could VPN into the lab, fire up the appropriate analysis VM, and review the output report from the scanner.

What's coming?
Recently on Twitter, Ken Johnson (@Patories) point out an artifact that he'd found on the Windows 8 dev build, and likely associated with IE 10...a key named "TypedURLsTime". The data for each of the listed values is a FILETIME object...when the time comes that Win8 is seen on the desktop, this will likely be a very useful artifact to be included in a plugin.

So, let me ask you this...who's going to remember that when Windows 8 actually hits the streets? I'm running the dev build of Windows 8 in a VirtualBox VM, as a .vhd file; anyone doing so can easily mount the .vhd (read-only) on their Windows 7 system, write a plugin for the artifact, and there it is...documented.

Documentation

2011-10-01T08:09:00.000-05:00

If you didn't document it, it didn't happen.

When I first heard that, it had nothing to do with DFIR work, but it holds true nonetheless.

How often does this happen? We're working on a school or self-imposed project, and you run across an issue, so you go online to ask a question of the communal brain trust (Twitter, Forensic Focus, CFID mailing list, etc.). Within short order, you start getting queries...which version OS/version of Windows, which application, where did you get the file (path), etc. By the time you return to the online world, you can't remember any of this, and now have to start over. However, had you kept case notes or documentation of some kind, this wouldn't be an issue.

So the questions I usually see/hear at this point are how do I keep case notes and to what standard do I keep case notes? The how is easy...what works? When I was on the IBM team, we used the QCC Forensic CaseNotes tool. This is a very good tool to use, and includes a lot of functionality. However, it's sometimes simply easy to use MS Word, and create the necessary sections. I usually create a section for Exhibits (what items I had received, often in a table if there were more than 2 or 3 items), as well as one for Hours (again, sometimes in a table). When I got to the actual notes, these were most often a narrative of what I actually did, broken down by day.

You can create other sections, as well. Bill over at Unchained Forensics recently posted about having a case outline or preparation plan. I usually have an analysis plan in mind, and if it's for work that I don't already have a checklist, I write one. I think that Chris has even talked about having an analysis plan documented.

So, to what standard do you keep case notes? Most often, I'll say, "...so that you can come back a year later and know what you did." Too often, however, this provides a lazy analyst with an easy out, because from their perspective, what are the chances that in a year, someone's going to come back and ask them a question? Well, you don't know until it happens...and it does happen. The best standard to use when writing your case notes is to assume that at any point, you could "get hit by a bus" and another analyst will have to take your notes and finish the exam. As such, are your case notes written to a level where another analyst could run the same commands, using the same versions of the tools you used, and replicate your results? So, in your case notes, do you say, "Checked for ADSs", or do you say "Mounted image with FTK Imager v3.0 as G:\ volume, scanned for ADSs using LADS v4.0"? This is important...remember MHL's post on stealth ADSs? There are more things on heaven and earth than are dreamt of in your philosophy, Horatio...so the tool you use will make a difference, and you might want to consider using the tool that MHL provided.

On that note, consider this...what do your case notes say? If you do PCI work, do your notes say, "Ran CCN search"? Is that adequate? How was that search run, and over what data? Did you load the image into EnCase? If so, which version? And yes, the version of EnCase you're using DOES matter. Was your search run using a specific EnScript, and was that a publicly available EnScript or one crafted specifically by/for your team? Or did you extract the unallocated space from the image using blkls from the TSK tools, and run a series of regexes over the data?

All of this is important because the number of CCNs that may have been exposed are extremely important to the merchant as well as the banks; as such, accuracy is critical, and one way to ensure accuracy is to be able to replicate your findings.

Start with a Process
An efficient way for maintaining case notes is to have documented processes already in place. For example, if you're tasked with detecting malware within an acquired image (no memory dump available), do you have a documented process for doing this? If so, you can say "followed documented malware detection process" and provide the version number or date, as well as the completed checklist itself. That documented process can be a separate document in your case notes directory, and all you would need to include is any additional actions you took, or anything you decided to leave out, including your justification (ex: "Did not run search for ADSs, as the file system was FAT.").

The Value of Case Notes
So why are case notes so important? Well, those of us that teach the need for this kind of documentation use the you may have to testify a year later and what if you get hit by a bus hooks, but in the big scheme of things, these events rarely happen. When they do, they're real eye openers, but by then it's too late and everyone's left saying, "...yeah, I should have kept case notes...".

Something that a lot of folks don't think about when it comes to case notes is competitive advantage. How do organizations that provide DFIR services define "competitive advantage"? Most often, the outward expression of this perception is generated through marketing (presentations at conferences, blog posts, use of social media, webinars, etc.) efforts; however, behind the scenes, that organization is going to have to deliver at some point, and it becomes a matter of the quality of the service provided (usually in relation to margins). As such, detailed and clear case notes serve as a fantastic learning tool for other members of the DFIR team. Let's say there's a team of 11 analysts/responders, all of whom are geographically dispersed. One analyst spends 16 hrs of analysis and finds something new, that no one else has ever seen. Now, assuming a common skill set level across all analysts, we have to assume that for everyone else to replicate this finding, assuming they get a relatively similar case, would take a total of 160 hrs (10 analysts x 16 hrs/analyst). This isn't terribly efficient, is it, particularly given the assumptions? However, if the first analyst's case notes are clear, they can be used to provide information to the other analysts regarding what to look for, etc. If the team uses a remote presentation capability (WebEx, brown bag "lunch and learn", etc.), the 160 hrs can be reduced to 30 minutes, and all analysts would then have the same knowledge and capabilities, without having to have had the same experience. This can provide a great deal of competitive advantage to that organization.

Another use of the case notes is to use them to create the appropriate indicators of compromise (IoC), or a plugin for a forensic scanner, to be shared amongst all analysts. This provides an immediate capability (the time it takes to share the plugin) with zero experience, in that the other analysts don't have to actually have had the experience in order to achieve the capability. This means that corporate knowledge is always available and retained well after analysts leave the organization, and knowledge retention becomes competitive advantage.

Consider this...when performing a specific exam (i.e., malware detection), how do you go about it? Do you have a series of artifacts that you look for or tasks that you perform? Now...and be honest here...do you have a documented checklist? If you do, how much of that can you put into an automated process such as a scanner? If you do this, you have now reduced your initial analysis time from days or hours to minutes, and by using automation, you've also reduced your chances of forgetting something, particularly those repetitive tasks. Now, imagine collaborating with other analysts and increasing the number of plugins run...you now have a communal knowledge bank focused on quickly checking for the low-hanging fruit, and providing you with the output report (and a log of all the plugins run). Ultimately, you're left to do the actual analysis.

So in the case of the scanner, the documentation comes in two forms...first, the documentation of previous analysis that results in a plugin. Second, the output report from the scanner, as well as the activity log, serve as case documentation, as well.

WFA 3/e update

2011-10-01T07:37:00.000-05:00

I posted a bit ago on WFA 3/e, and as I get closer to completing rewrites of reviewed chapters and getting the manuscript submitted, I wanted to provide an update of how things have progressed thus far...

I also wanted to talk a little bit more about what this edition is all about. Specifically, this edition is NOT a follow-on to the second edition; instead, it's a companion book. That is to say, if you have the second edition on your bookshelf, you will also want to have this edition, as well. In fact, ideally, you'll have both WFA editions along with Windows Registry Forensics, as well, in order to make a complete set.

There have also been a couple of changes, perhaps the biggest one being that I completely rewrote chapter 2; rather than being "Live Response", I retitled it to "Immediate Response" (the need for which was covered in this article by Garry Byers), as the previous topic had been covered to some extent in WFA 2/e, and one of the points of the third edition is to not rehash what's already been covered. Instead, I wanted to write about the need for organizations that have identified (or been notified) that an incident has occurred within their infrastructure to immediately collect and preserve data, and do so from the perspective of a third-party consultant/responder. I think we've seen enough in the media in the last 9 or 10 months to clearly demonstrate that no organization is immune from being compromised; add to that the ethereal nature of "evidence" and you can see why organizations must be ready to begin collecting data as soon as know that something has happened. The perspective I wanted to take was that of a responder who gets a call, and after the contract has been negotiated, travels to the site and begins working with the local IT staff to develop an understanding of the infrastructure and the nature of the incident...all while digital evidence continues to expire and fade away.

During the rewrites, I'll be adding some specific information that has developed since specific chapters were originally written. For example, in chapter 4, I fleshed out information regarding Jump Lists, and I added some additional information to the chapter on Registry Analysis.

Now, there are some things I don't cover in the book. For example, memory analysis and browser analysis are two of the most notable topics; these are not covered in the book because there are covered elsewhere, and in a much better manner that I could have done.

Finally, with WRF, I started posting the code for the books on my Google Code site, and I will do the same with WFA 3/e. Throughout the book I mention tools and checklists, and I'll have those posted to the Google code site before the book is actually published.

NoVA Forensics Meetup Reminder

2011-09-28T05:57:00.002-05:00

Just a quick reminder that the next NoVA Forensics Meetup will be Wed, 5 Oct 2011. Time and location remains the same. We're planning to have a presentation on mobile forensics.

Friday Stuff

2011-09-23T07:12:00.001-05:00

ADSs
I've been fascinated by NTFS alternate data streams for almost 14 years now, and I caught MHL's recent blog post on detecting stealth ADSs with TSK tools. The idea behind a "stealth ADS" came from this Exploit Monday post, and both posts were very interesting reads.

ADSs are one of those NTFS artifacts that many folks (DF analysts, admins, etc.) don't really know a whole lot about, and I'm not sure why. I guess it's a chicken-or-the-egg issue; how do you know that there aren't any ADSs on your systems if you're not looking for them? If you don't look for them, why do you then need to know about them...right? I remember about 11 years ago, Benny and Ratter of the group 29A wrote Win32/Stream, mostly as a proof of concept.

F-Response
If you haven't heard of Matthew Shannon's F-Response, I'd really have to question where've you been. F-Response is one of those tools that have really pushed incident response work ahead by leaps and bounds. Using F-Response, you can reach out systems on another floor, in another building, or even in another city, and make a read-only connection to the physical disk, and from there, run tools to search for specific items, collect specific files, or even conduct a physical or logical acquisition. With Windows systems, you can even collect the contents of physical memory.

Matt's added the FlexScript scripting capability to F-Response, and through Powershell, recently demonstrated how to use F-Response to automate large collections. As always, Matt includes a video so you can see what he did, in addition to providing the scripts along with the F-Response Mission Guides.

This adds a whole new dimension to an already-valuable tool; being able to automate large-scale collections is a powerful capability. If an incident occurs, an organization can use this capability to automate quickly connecting to systems and either collecting data, or

Live Forensics
Speaking of Matt Shannon, thanks to his Twitter account, I was recently directed to this paper, which is intended to dispel some of the myths of live digital forensics. The paper is just 5 pages long, so I printed it out so I could read it...and found it very interesting. The paper essentially addresses (and shoots down) three common myths that are encountered within the digital forensics community regarding live forensics, and does so only with respect to the admissibility of "live" digital evidence in a US court of law. I can see how this distinction is important for the paper, particularly in driving its point home. Additional discussion in dispelling the myths would extend the length of the paper unnecessarily, and potentially make the argument a bit murky. In short, each of the myths is addressed with "...the Court makes no requirement...".

This is similar to conversations I've had with Chris Pogue, during which we've discussed "court certified" tools; this is something we've both heard, and the long and short of the discussion is that there is no such thing, regardless of what folks (including marketing staff) my choose to believe or say.

Volatility
Here's a post on the malwarereversing blog that discusses (and provides) the vscan.py plugin for Volatility 2.0, which allows you to submit malicious stuff you've found in a Windows memory dump to an online AV scanning site (the post uses Jotti).

The blog post also mentions MHL's avsubmit.py plugin, which allows for the submission of stuff you've found to VirusTotal.

Tools
I ran across the CERT Linux Forensics Tools Repository recently; very cool. Not only are some of my tools posted there (i.e., RegRipper, tln_tools) but many of the ones listed also run on Winderz!

Mark Woan recently updated JumpLister to include parsing of DestList streams, as well as looking up AppIDs. It appears from the JumpLister web page that the DestList parsing capability was added based on the information available in the ForensicsWiki, which really shows how useful and powerful a resource the ForensicsWiki can be. Mark's application downloads as part of an installer package, and it only runs on Windows. The installer adds 11 files to your system, and when you run it, you can load one autodest JumpList at a time. The tool did a great job of parsing the DestList stream on the few files I loaded. Mark mentioned in the Win4n6 Yahoo group that he changed the functionality of the tool, so that instead of loading the entire compound file, it first parses the DestList stream, and then looks for the numbered streams identified in the DestList stream. Jimmy Weg reports that XWays now supports parsing autodest JumpLists, including the DestList streams.

I hope that with the information in the ForensicsWiki, and a number of available tools (free and otherwise) supporting parsing of these artifacts, that maybe this will push folks to start looking at these files as a valuable forensics resource. Since I started posting about Jump List analysis, I've created my own code for parsing these files, including not only the compound files that the autodest Jump Lists are stored in, but also the LNK streams and the DestList stream. This code allows me a great deal of flexibility, not only to troubleshoot issues with "misbehaving" Jump List files, but also to modify the output into any format I desire (CSV, TLN), either to analyze separately or include in a timeline. I've seen the value of Jump Lists in forensic analysis, and I hope others begin to parse these files and include them in their analysis.

AutoRuns Update
AutoRuns has been updated to version 11, to include a "jump to folder" capability, as well as several new autostart locations. I haven't gone through all of them yet, but this looks very promising.

Speaking of autostart mechanisms, Martin Pillion recently posted to the HBGary blog regarding malware's use of Local Group Policy to maintain persistence on a system. I found the blog post fascinating (it's always interested to see stuff you've seen talked about before), albeit a bit hard to follow in some places; for example, just below figure 4, the second sentence states:

We do this by adding the following line in the section:

What section? I see the "following line", but for the casual reader (or perhaps someone not quite as knowledgeable in this area), this can be confusing. Overall, however, this doesn't really take much away from this persistence mechanism. I mention it here (rather than in its own section), as according the blog post, the new version of AutoRuns does NOT detect this persistence mechanism.

Several other MS/SysInternals tools have been updated, as well, to including ProcDump and Process Explorer.

DFF
DFF RC 1.2 is available.

Links and Updates

2011-09-19T06:05:00.000-05:00

iTunes Forensic Analysis
I ran across a very interesting read regarding the forensic analysis of an iTunes installation via DFINews. One of the things I see consistently within the community is that folks really want to see how someone else has done something, how they've gone about conducting an exam or investigation, and this is a good example of that.

Volatility Updates
Keep your eye on the Volatility site for updates that include support for Windows 8, thanks to the efforts of @iMHLv2, @gleeda, @moyix, and @attrc.

Speaking of Volatility, the folks at p4r4ni0d take a look at Morto. Great work, using a great tool set. If you want to see how others using Volatility, take a look at the blog post.

NetworkMiner
A new version of NetworkMiner has been released. If your work involves pcap capture and analysis, this is one tool that I'd definitely recommend that you have in your kit.

Registry
Andrew Case (@attrc) put together a very good paper (blog post here) on how he went about recovering and analyzing deleted Registry hives. Now, this is not recovering deleted keys from within hive files...Andrew recovered entire hive files from unallocated space after (per his paper) the system had been formatted and the operating system reinstalled. Take a look at the process he went through to this...this may be something that you'd want to incorporate into your tool kit.

If you're read Windows Registry Forensics, you'll understand Andrew's approach; Registry hive files (including those from Windows 8) start with 'regf' at the first 4 bytes of the file. The hive files are broken into 4k (4096 bytes) pages, with the first one beginning with 'regf'; the subsequent pages start with 'hbin'.

I've done something similar with respect to Windows XP Event Logs, carving specifically for individual records rather than entire Event Log (.evt) files. In much the same way, Andrew looked that goals of his examination, and then used the tools he had available to accomplish those goals. Notice that in the paper, he didn't discuss re-assembling every possible hive file, but instead only those that might contain the data/information of interest to his examination. Nor did he attempt to carve every possible file type using scalpel; he only went after the types of files that he thought were necessary.

When I wrote my event record carving tool, I had the benefit of knowing that each record contains the record size as part of its metadata; Andrew opted to grab 25MB of contiguous data from the identified offset, and from his paper, he appears to have been successful.

Also, page 4 includes a statement that is extremely important; "This is necessary as USBSTOR keys timestamps are not always reliable." As you're reading through the paper, you'll notice that Andrew focused on the USBStor keys in order to identify the devices he was looking for, but as you'll note from other sources (WRF, as well as Rob Lee's documentation), the time stamps on the USBStor keys are NOT a reliable indicator of when a USB device was last connected to (or inserted into) a system. This is extremely important, and I believe very often confused.

More importantly, I think that Andrew deserves a great big "thanks" for posting his process so clearly and concisely. This isn't something that we see in the DFIR community very often...I can only think of a few folks who do this work who've stepped up to share this sort of information. Clearly, this is a huge benefit to the community, as I would think that there will be folks reading his paper who will think to themselves, "wow, I could've used that on that examination!", just as others will likely be using it before 2011 closes out. Notice that there's nothing in the write-up that specifically identifies a customer or really gives away any case-specific data.

Andrew's paper is an excellent contribution to the community, and provides an excellent look at a thorough process for approaching and solving a problem using what you, as an examiner, have available to you. Something else to consider would be to look for remnants of the (for Windows XP) setupapi.log file, which would provide an indication of devices that had been connected (plugged in, attached, inserted into) to the system. I've done something similar with both the pagefile and unallocated space...knowing what I was looking for, I used Perl to locate indications of the specific artifacts, and then grab X number of bytes on either side of that artifact. As an example, you could use the following entry from a setupapi.log file:

#I121 Device install of

Now, search for all instances of the above string, and then grab 200 or more bytes on either side of that offset and write it to a file. This could provide some very useful information, as well.

Timelines
Corey has an excellent post up regarding the thought processes behind putting a timeline together. I'd posted recently on how to go about creating mini-timelines from a subset of data; in his post, Corey discusses the thought process that he goes through when creating timelines, in general...he also provides an example. If you look at the "Things to consider" section of his post, you'll notice some similarity to stuff I've written, as well as to Chris Pogue's Sniper Forensics presentations; in particular, the focus on the goals of the examination.

In his post, Corey mentions two approaches to timelines; the "kitchen sink" (including everything you can, and then performing analysis) and the "minimalist" approach. From my perspective, the minimalist approach is very similar to what Corey describes in his post; you can add data sources to a timeline via a "layering" approach, in that you can start with specific data sets (file system metadata, Event Logs, Prefetch file metadata, Registry metadata, Jump Lists, etc.), and then as you begin to develop a more solid picture, add successive layers, or even just specific items, to your timeline. The modular approach to the tools I use and have made available makes this approach (as well as creating mini-timelines) extremely easy. For example, during an examination involving a SQL injection attack, I put together a timeline using just file system metadata and pertinent web server log entries. For an incident involving user activity on a system, I would create a timeline using file system metadata, Registry key LastWrite times (as well as specific entries, such as UserAssist data), Event Log entries, Prefetch file metadata, and if the involved system were Windows 7, Jump List metadata (including parsing the DestList stream and sorting the entries in MFU/MRU order). In a malware detection case, I may not initially be interested in the contents of any user's web surfing activity, with the exception of the LocalService or "Default User" user accounts.

This is not to say that one way is better or more correct than another; rather, the approach used really depends upon the needs of the examination, skill set of the analyst, etc. I've simply found, through my own experience, that adding everything available to a timeline and then sorting things out doesn't provide me with the level of data reduction I'm looking for, whereas a more targeted approach allows me to keep focused on the goals of the examination.

Links...and whatnot

2011-09-16T06:17:00.002-05:00

How'd you do that??
One thing I've found to be very true about the community is that folks love to see how other analysts have done things. This is very helpful to know when it comes to writing articles or giving presentations.

Frank Boldewin recently posted CSI:Internet Episode 3: A trip into RAM, which provides an excellent walk-through on how he collected the contents of physical memory from a live Windows system, and then used Volatility (including the malfind, volshell, apihooks plugins) to locate malware. Frank's article is well worth a look, as it is an excellent read.

Advice
Need advice or input on getting started in DFIR work? Corey recently posted links to various articles and posts (including my own), and provided some considerable (and excellent) advice of his own. Even if you're already in the field, this is an excellent source of advice.

HowTos
I posted a quick-and-dirty blog post recently on how to create mini-timelines, and received a comment asking for more of these types of posts. I've considered writing "HowTo" posts in the past, but quickly found myself running short on topics. I'm considering posting more of these, but like I said...I'm kind of running short of topics.

Windows 8
I recently installed the available developer build of Windows 8 into VirtualBox (running on 64-bit Windows 7) using these instructions. So far, so good. During the setup, I opted to use the .vhd disk format (rather than the VirtualBox .vdi, or .vmdk) so that I could later add the .vhd file to a Windows system to see what things look like. I installed the OS, poked around a bit, and then shut the VM down and opened the .vhd file in FTK Imager. The Registry hives that I looked at (NTUSER.DAT) appear to follow the same format as previous versions; as Windows 8 is running in a VM, I won't be able to see things like wireless connectivity, etc. It also appears that Windows 8 uses Jump Lists (good thing I wrote that code to parse those bad boys, eh?); I'll definitely have to take a closer look at them, that's for sure. Looking at the Jump List files in the FTK Imager hex view, I see the file signature for the OLE/compound document binary format file, as well as the "Root Entry" and "DestList" stream names.

From the TwitterVerse, it seems that I'm not the only one moving along these lines...moyix has taken the first steps toward adding Win8 support to Volatility (see it working here).

APT
I know, I know...no one wants to hear about the "Advanced Persistent Treat" anymore. However, it appears that there was an APT Summit in DC this past summer, and RSA recently published an overview document of the findings from the summit. The PDF doc is 3 pages long, and pretty interesting read.

Windows Post-Exploitation
Thanks to Chad Tilbury, I was directed to this page (at pentestmonkey.net) which discusses various means of getting from Local Admin to Domain Admin once a system has been compromised. Looking for artifacts of these approaches can provide indications of what the intruder may have been up to.

NoVA Forensics Meetup Group

2011-09-15T11:14:00.000-05:00

Based on some advice from a friend, I set up a NoVA 4n6 Yahoo Group. I've updated the blog page with the information, but will be posting information about location, meeting times, etc., to this group. This will also provide us with a place for folks to upload files (i.e., presentations, etc.), ask questions, continue discussions, etc.

Also, I've received comments from folks who've indicated that it's far too difficult to find information regarding the meetups, so I wanted to put everything in one place...or one more place...because what we want to do is grow the meetup group, not make it a right of passage just trying to find the place.

Thanks.

HowTo: Mount and Access VSCs

2011-09-15T08:52:00.001-05:00

I've posted before regarding how to mount and access Volume Shadow Copies (VSCs), but I thought it might be useful to revisit this topic, as there's a great deal that you can do once you've mounted a VSC.

If you received/have an image acquired from a Vista or Win7 system, you'll likely want to mount the image and access data within the available VSCs at some point. Commercial tools such as ProDiscover provide access to the VSCs within an image (PDF here), but how can you access this source of data in a more economical fashion?

Well, there are a couple of ways to go about this, both of which require that you're using a version of Windows that supports VSCs, such as Windows 2008 or Windows 7.

VMDK Method
Starting with your image, download a copy of either raw2vmdk or LiveView and create a VMWare virtual disk (.vmdk) file for the image (I say "for" because the .vmdk file will most likely contain a reference to the image file). Once you've done this, you can add this .vmdk file as an additional hard drive to a VMWare virtual machine (VM), and then boot that VM. You can add a .vmdk file as an additional hard drive via VMPlayer, but if you have VMWare Workstation, you can add the .vmdk file as an independent, non-persistent disk, which means that no changes are made to the .vmdk file.

Note: You should always work on a copy of an image, not the original image file itself.

As a test, I opened VMPlayer running on a Windows 7 64-bit host system and selected a 32-bit Windows 2008 guest VM. I added a .vmdk file from a 32-bit Windows 7 guest VM to the Win2008 VM as an additional hard drive, and booted the Win2008 VM. Once I logged in, I was able to list the available VSCs from the Windows 7 .vmdk file (mounted as the E:\ volume) using the command vssadmin list shadows /for=e:. From that point, it was simply a matter of using the mklink command to mount a VSC.

VHD Method
To use this method, download a copy of vhdtool, and use it to convert the image to a VHD file (i.e., vhdtool /convert). The tool adds a VHD footer to the image file, so the extension of the image file won't change automatically, although that's not needed in order to mount the VHD file (you can change the extension manually, if you like). You can then use the Disk Management tool to add the VHD file to a Windows 2008 or Windows 7 system as a read-only disk.

What now?
Once you've mounted the image file, you can list the available VSCs using the vssadmin command, and even create a batch file that will mount each VSC using the mklink command, run various tools on the mounted VSC (i.e., rip.pl/.exe, LogParser, etc.), and then unmount each VSC using the rmdir or rd command.

I've used this method to cycle through the VSCs within an image from a Vista system to extract information from a user's UserAssist key using the userassist_tln.pl RegRipper plugin (via rip.pl), in order to determine not only the last time that the user launched an application, but previous times, as well.

Resources
This section provides links to blog posts from other analysts to demonstrate what they've done while having access to VSCs...

- Stacey Edwards' SANS Forensic Blog post on using LogParser against VSCs
- Corey's "A Little Help with VSCs" post
- SANS Forensics Blog post (using TSK tools)

HowTo: File Extension Analysis

2011-09-14T11:59:00.000-05:00

Subtitle: Determining which application a file "belongs" to

Many times when I am browsing through online lists and forums, I see questions geared along this avenue; an analyst finds a file with a specific extension, and wants to know which application uses it or may have been used to modify that file. Most times, this is just a small part of a much larger question, and initial attempts to answer the question via Google searches may have led to additional confusion (specified application does not appear to be installed on the system, etc.). However, there are things that an analyst can do to answer that question using the data currently available, within the collected image.

File Extension Analysis
So you have a file that you're interested in, along with a path, name, and extension, and you want to know which application may have been used to create or modify that document. One way we can go about this is to use Registry analysis. Within the acquired image, locate the Software hive (usually in the path "\Windows\system32\config"), and within that hive, look to the Classes key. Many of the first subkeys that you'll see beneath this key are file extensions, such as ".3g2". The "(Default)" value of this key is "QuickTime.3g2", which indicates that this system will attempt to open a file with this extension using the QuickTime application. Additionally, the "OpenWithList" subkey includes a subkey named "QuickTimePlayer.exe". Locating the key "Classes\QuickTime.3g2", I saw that that key had a "shell\open\command" subkey with a "(Default)" value that pointed to QuickTimePlayer.exe (along with the complete path to that file).

As another example, beneath the "Classes\.aa" key, the "OpenWithList" subkey contains a subkey named "iTunes.exe", which indicates that the iTunes application will be used to open a file that ends in the ".aa" extension. Some extensions may have multiple subkeys beneath the "OpenWithList" key, which serves as an indicator to the type of file with which the extension is associated.

Other keys beneath the "Classes" key may have different information that may indicate how the file had been accessed or used on the system. On a system I was looking at, I found the ".rnk" extension, and the key only had a "(Default)" value with "rnkfile". I then located the "Classes\rnkfile" key, which had a "shell" subkey, with additional subkeys that referred to different commands. When I went to the command line on that system and typed "assoc rnkfile", the response was "rnkfile=Dial-Up Shortcut".

As this technique is based on Registry analysis, analysts need to keep in mind that it may often be unique to the system being analyzed, and findings on one system may not necessarily map directly to or represent those on another system. Also, these artifacts are based on file associations, which many times will be set when an application is installed, during the installation process. As such, when the application is uninstalled, those associations may be removed.

As this technique involves Registry analysis, there are other areas you can check, as well. For example, each user hive (XP) has a "Software\Classes" key within the NTUSER.DAT hive that may contain file associations specific to the user. On Vista and above systems, this information will be located in the root of the USRCLASS.DAT hive. You can also look to the RecentDocs key within the NTUSER.DAT hive to see which files the user has accessed, by extension. Also, if you suspect that someone may have purposely deleted any of the keys or values of interest, be sure to use regslack to check the unallocated space within the hive files for those artifacts.

If you have a file name (as opposed to just an extension) you might open up the user's hives in something like MiTeC's Windows Registry Recovery tool or the Registry Decoder from DFS, and search for the file name...you may find a reference in the application MRU listing.

Jump Lists
Jump Lists are artifacts that are new to Windows 7, and appear to contain most frequently used or most recently used (MFU/MRU) information with respect to applications and files. The *.automaticDestinations-ms Jump List files are created by the operating system, with only interact from the user being to open the file. However, testing indicates so far that Jump Lists created as a result of an application being used will persist after the application itself has been removed or uninstalled from a system. Therefore, an analyst with a specific file extension of interest should be sure to check the available Jump Lists (assuming that the image is from a Windows 7 system, of course) for indications of the extension or the complete file name. From there, the analyst can then map the AppID (first part of the Jump List name, before the '.') to the application, using the list on the ForensicsWiki, or on ForensicArtifacts.com.

Timeline Analysis
When presenting on timeline analysis, one of the benefits of this analysis technique that I try to get across is that it can provide context to what we're looking at; for example, creating a timeline from multiple data sources (including data from the user profile) may provide clear indications as to how a file with a specific extension was created or modified. Timelines very often include (if available) file system metadata, Prefetch file metadata, as well as time stamped data from a user's NTUSER.DAT, including (but not limited to) UserAssist data, RecentDocs data, etc. Through a timeline, you may find that a user opened an application, and shortly thereafter a Prefetch file was created or modified for that application, and then the file in question was created or modified. At this point, you'd not only know when the file was created, but using with application, and by which user.

VSCs
Volume Shadow Copies (VSCs) may provide some considerable information that may not be available via other sources. If an artifact does not persist when an application has been uninstalled from a system (such as may be the case with file extension associations), there may be historic remnants available in the VSCs (Vista, Windows 7).

Resources
Jump List Analysis (part 1, part 2, part 3)

HowTo: Creating Mini-Timelines

2011-09-12T19:43:00.001-05:00

There are times when you don't want (or need) a super timeline, but instead just want to focus on one piece of available data, such as Event Log entries or Registry key LastWrite times. I've had occasion to focus on just specific entries in the Security Event Logs; specifically, event ID 528, type 10, indicating RDP logins to a system. I used one of the timeline tools I wrote, evtparse.pl, to parse the appropriate records from the Security Event Log and then create a timeline from just those records.

So, let's say that you have something specific that you want to look for, such as all Registry keys that were created or modified between two specific dates. You'd want to start by either extracting the appropriate hives from the acquired image via FTK Imager, or using FTK Imager to mount the acquired image as a volume on your analysis system.

For the next steps, go here and download the tln_tools.zip archive...do NOT download regtime.zip for this exercise. From the tln_tools.zip archive, we will be working specifically with the regtime.pl and parse.pl tools (note that regtime also ships with a standalone EXE...you must have the p2x588.dll file in the same directory along with the EXE).

The first thing you'll need to do is create your events file of the Registry key LastWrite times. One thing you'll need is the name of the system you're analyzing. This can be something that's already in your case documentation; however, if you don't have that information, you can either enter a designator, or leave it blank...for what we're doing, it isn't critical. If you have RegRipper installed, this is very easy to get, using the following command:

C:\rr>rip -r H:\Windows\system32\config\system -p compname

We can then use the returned information in your mini-timeline instead of the "SERVER" value in the below commands.

Next, we'll parse the Software and System hives (assume that the image is mounted as H:\):

C:\tools>regtime -r H:\Windows\system32\config\system -m HKLM/System -s SERVER > D:\case\key_events.txt

C:\tools>regtime -r H:\Windows\system32\config\software -m HKLM/Software -s SERVER >> D:\case\key_events.txt

Now that we have the events file, we can use parse.pl to generate our timeline. If you type just "parse.pl" at the command prompt (or "parse.pl -h"), you'll see that the script has a couple of options, one of which is to specify a date range. Let's say that you want all events from your events file, between 3 March and 4 April 2011, inclusive. You would use the following command:

C:\tools>parse.pl -f D:\case\key_events.txt -r 03/03/2011-04/04/2011 > D:\case\key_tln.txt

This command provides an ASCII output format that I've always found very easy to view and understand. If you would like .csv output, which Excel is much happier with, type the following command (note the "-c" switch):

C:\tools>parse.pl -f D:\case\key_events.txt -r 03/03/2011-04/04/2011 -c > D:\case\key_tln.csv

There you go...that's it. You can also add other hives to your events file, even NTUSER.DAT hives (adding the username after the "-u" switch can help you tell different user's apart).

This blog post has been brought to you by the open source tool, "regtime.pl", and the redirection operator ">".

Growing the NoVA Forensics Meetup

2011-09-09T14:58:00.002-05:00

I received an email today from Tim/@bug_bear asking about the format that we use for the NoVA Forensic Meetups, as he may be looking at starting something in his area. In responding, I started thinking about what we currently do, and whether or not we're "serving" our members. What I'm looking at is what we can do to get folks interested in attending and interacting, more so than we have now.

One of the things I've noticed about the meetings is that we have a very small core of regulars...folks who can make it out on a regular basis. We do have folks who happen to be in the area for another event and stop by, which is very cool...this last meetup, we had some folks from a defense contractor, one of whom is a former Marine.

So I thought I'd share some thoughts I had on expanding the meetups, and see if we can't get some feedback or additional thoughts and comments from others on what we can do to expand, so that we're not just doing the same thing every time.

I'd like to see something more than just presentations; our presentations have been very good, and I greatly appreciate everyone who has (and will be) stepped up to give a presentation. But I'd also like to see about maybe getting a little more interactive and offer some additional value to our members. To that end, I'd like to get some input from the members

Some other ideas I've had, in part from my exchange with Tim, include:

Collaborative projects - Tim mentioned this, and I think that the idea has some very good possibilities. One of the aspects of ReverseSpace that our hosts remind us of is that they have something of a network infrastructure themselves. However, this doesn't have to be the sole avenue for collaborative projects; all it takes is the desire. Thoughts? Ideas?

Wiki - this is also something that Tim brought up that I thought might be interesting. Taking nothing at all away from the ForensicsWiki, there are resources such as WikiSpaces available, as well.

Mentoring - our membership includes a number of folks who are interested in forensics, but perhaps don't "do" it, or do it on a regular basis. We also have members who have other backgrounds...network and system admins, IDS analysts, etc. We've had folks attend who do online investigations, as well as various levels (local, state, federal) LE. There are folks who specialize in or just work with Mac, Linux or Windows systems, as well as mobile devices. What I like about all this is that we have folks from a range of backgrounds who are willing to answer questions. "Mentoring" doesn't have to be anything more than someone is willing to provide.

Lightning talks - I've thought about this before; instead of having one 45-50 minute presentation, have two (or more) shorter ones, just covering very specific, limited topics. Speaking of which, the ReverseSpace (our hosts) folks have hosted DojoCon at their location; what would be the interest in a ForensiCon? I've noticed online that there are a number of conferences that have moved to a combination of talks, lightning talks, and even panels, and have been very successful. We may be able do something like this on a Saturday during the messy winter weather, but it would really depend on what sort of attendance we could get.

Logo - Would it be cool if we had a logo? I'd put up either a signed copy of DFwOST (signed by both authors) or of WRF to whomever comes up with the winning logo design, if we have folks who want to design a logo that our membership could vote on.

I'd like to get input from our membership, as well as from anyone else who has some thoughts along these lines.

Something else I will be doing going forward is sending out reminders via other media besides just this blog; I'll be pushing more reminders out via the Win4n6 group, Twitter, LinkedIn, Facebook, etc. Also, I'll be sure to bring these topics up during the admin/intro portion of our next meetup.

Updates and Links

2011-09-09T07:52:00.000-05:00

NoVA Forensic Meetup
The most recent NoVA Forensics Meetup was a great time! Mitch Harris gave a great "Botnets 101" presentation and opened the door for 201. Mitch described botnets and their command-and-control (C2) structures, and is leaving mitigation techniques for his follow-on presentation. A huge thanks to Mitch for presenting, and everyone for showing up, especially those who came by because they were in the area. We're looking forward to having Mitch come back for that follow-on presentation in the future.

BIOS Malware
Speaking of Mitch's presentation, he also mentioned malware that infects systems by writing to the BIOS. Oddly enough, I ran across Mebromi this morning, which Norman describes as a "BIOS-flashing Trojan".

An excellent point brought up in the writeup is also something that we discussed during the meetup; that is that the reason why we're not all infected with malware that writes to the BIOS (or to the GPU on our graphics card, etc.) is that this sort of malware is "hard to do", because it's very hardware-specific. In fact, the writeup also indicates that the Trojan attempts to modify Award BIOS's only. Mebromi also apparently infects the MBR, as well.

Here is Symantec's writeup on Mebromi.

VirusTotal
Okay, this is the last thing I'm going to say about malware in this post...seriously. I ran across this ComputerWorld article this morning, which mentioned that the same spearphish attack code used against RSA had also been used against other organizations; in fact, the first sample of that code had actually been submitted on 4 March, whereas (according to the article) it wasn't until 19 March that a sample was submitted from someone at EMC (the company that owns RSA).

Folks, what this tells us is that those tools that we use to quickly gather intelligence about stuff we find on our systems can then be used against us. In spearphishing attacks, you can be sure that the attackers know exactly to whom the emails were sent...that's sort of the nature and definition of a spearphishing attack, and is also why we don't simply call it "random-spray-and-pray". Remember, "public" websites are usually exactly that...public. And available to everyone. This is why you might want to develop an organic, in-house malware analysis capability.

Also, there was apparently some metadata analysis of the actual spreadsheets that had been submitted, as well...take a look at the article and see if you agree with what was said about that...

Jump Lists
The new 4n6k blog has a post up that extends Jump List Analysis by adding a whole bunch of AppIDs. I posted recently regarding using timeline analysis to fill in the gaps in analysis when you're either attempting to determine the app associated with an unknown AppID, or if the user had deleted the application itself prior to the acquisition of the system.

Community
One of the comments to the blog post that I mentioned above was along the lines of, hey, locating indications of apps being run has been discussed before...my thought along those lines is, okay, but do we do it enough? Seriously. How often do we really share analysis techniques, or findings? Something may have been discussed before...but where, and with whom?

What would have happened within the community if no one took USB device analysis any further after the first research was published? What if Rob Lee had never decided to take what was published a step or two further? What if the first iterations of the Volatility Framework had never been developed?

It's important that we discuss these things, and keep discussing them. The problem that we face as a community is that nothing about what we do is static; everything's changing all the time. Discussing analysis techniques and findings allows us to not only engage other analysts who may not have seen what we've seen (or didn't know that they did), but it also allows us to metaphorically go beyond the next ridge and see if the world really is flat.

ProDiscover
ProDiscover recently turned 7...that's right, version 7 was released, adding MacOSX support (HFS+ file system, DMG images), EVTX Event Log format support, and there's a Fedora Linux live boot disk, as well. Chris Brown has graciously provided me with a license for ProDiscover IR since version 3, so I've seen this application go through a lot of growth, as Perl ProScripting support was added, as well as support for parsing PST/OST files. Just prior to version 7, Chris added support for parsing Windows 7 Jump Lists, making PD the first commercial forensic analysis application (that I'm aware of) to support parsing this artifact. ProDiscover was also the first commercial app to include native parsing of VSCs...right clicking on the partition within the app gives you a list of VSCs to choose from, and the ones you selected would appear as volumes/drive letters right there in the app UI.

Timelines
Corey's got a great post up called "What's a Timeline", which is a very good post that helps explain what a timeline is, or should be. It doesn't matter whether you're new to timelines or not, it's worth a look.

ESEDB Format
BugBear posted recently regarding using Joachim Metz's libesedb project tools to parse data from the Windows Desktop Search database, based on the Extensible Storage Engine (or 'ESE'). Joachim also wrote a paper that documents the format of the database. While Joachim's tools are Linux-based, Mark Woan provides his EseDbViewer for Windows systems.

From reading the materials available, it would appear that the ESE DB format, particularly for the Windows Desktop Search, may provide some very interesting forensic artifacts. It would be good to hear if any analysts out there are already using information from within the ESE database in their examinations.

If you're interested in developing your own code, iiobo has an ESE library and toolkit (C++/C#) available.

Jump List Analysis, Pt III

2011-09-08T19:24:00.000-05:00

Dan recently posted on Jump Lists on his blog, and provided a list of AppIDs, which can be used to augment what Mark posted on the ForensicsWiki.

So what happens if you run across an AppID that's not on one of the lists? Recently Jamie (Twitter: @gleeda) suggested determining the algorithm used to generate AppIDs, but what if the algorithm is a one-way hash, similar to what is used to compute the hashes in Prefetch file names? If that's the case, then having the AppID alone doesn't provide a means for determining the application name (i.e., if the hash is one-way). So, what else can be done?

Well, this would be a great time for timeline analysis. After all, it's unlikely that the only thing you'll want to determine is the name of the application that corresponds to the AppID; it's much more likely that that will be the first (or one) question of several.

When developing your timeline of system activity from a Windows 7 system, you'll likely have Prefetch files, Windows Event Log (EVTX) files, file system metadata, Registry key LastWrite times, time stamped information from Registry values, etc. Also, when you parse the DestList stream from the *.automaticDestinations Jump List files (particularly the one you're interested in), you'll have an MRU/MFU listing that you can add to the timeline. So what you'd normally look for (as with a Windows XP system) is that an entry was added to or modified within the Jump List file around the time that an application .exe was accessed...but wait...by default, Windows 7 (and Vista) doesn't update last access times on files! Holy MFT, Batman! What now?

Or, what happens if the user installs an application, does some stuff, and then deletes the application? Even if the Windows 7 system had been tweaked to update last access times on files, if the application is deleted and the executable file isn't available (MFT entry is overwritten...)...well, you can see where I'm going with this...

There is a solution to determining which application used in both of the above scenarios. One of the forensically interesting aspects of Jump Lists is that they persist on the system even after the application has been removed. We can use other, similar artifacts, such as Prefetch file metadata and UserAssist key entries (which also persist on a system after the application that was launched has been removed) to correlate the necessary information. For example, if a user installed an application (via an MSI package), you'd see that activity in the UserAssist key (as well as the MSI key listing). If they then launched the installed app, you'd also likely (depending upon how it was launched) see that in the UserAssist key, and then you'd see a Prefetch file being created in close proximity to the launch. You should also see the Jump List file being created within close proximity to the UserAssist key and Prefetch file data.

Once the application is removed from the system, you shouldn't see any further modifications to the Prefetch file or Jump List file data. If you found that the application appeared to have been run multiple times, then you should be sure to look to VSCs for additional available time stamped data.

What I hope this demonstrates is how analysis techniques such as timelines not only provide context to the data that you're looking at, but by incorporating multiple data sources, you increase your relative level of confidence in the data itself. Understanding the nature and value of those data sources also means that not only do you understand what should be there, but you can also fill the gaps when something (i.e., an application) is intentionally removed or deleted.

Registry Stuff

2011-09-07T06:46:00.001-05:00

I ran across a tweet recently from Andrew Case (@attrc on Twitter) regarding a Registry key with some interesting entries; specifically, the key HKLM\Software\Microsoft\RADAR\HeapLeakDetection.

Andrew also recently released his Registry Decoder, "an open source tool that automates the acquisition, analysis, and reporting of Microsoft Windows registry contents. The tool was initially funded by the National Institute of Justice (NIJ) and is now ready for public release."

I had an opportunity to take a look at a beta version of this tool, and I can definitely see the value of having all of the listed functionality available in one application.

To get an idea of what this key might be all about, I did some research and found this page at the Microsoft site, with an embedded video. From watching the video, I learned that RADAR is a technology embedded in Windows 7 that monitors memory leaks so that data can be collected and used to correct issues with memory leaks in applications. The developer being interviewed in the video give four primary goals for RADAR:

- To perform as near real-time as possible memory leak detection

- To perform high granularity detection, down to the function

- To perform root cause analysis; data must be sufficient enough to diagnose the issue

- To respect user privacy (do not collect user data)

So, what does this mean to the analyst? Well, looking around online, I see hits for gaming pages, but not much else, with respect to the Registry keys. Looking at one of my own systems, I see that beneath the above key that there is a subkey named "DiagnosedApplications", and beneath that several subkeys with the names of applications, one of which is "Attack Surface Analyzer.exe". Beneath each of these keys is a value called "LastDetectionTime", and the QWORD data appears to be a FILETIME object.

At first glance, this would likely be a good location to look for indications of applications being run; while I agree, I also think that we (analysts) need to have a better understanding of what applications would appear in these keys; under what conditions are artifacts beneath these keys created or modified. There definitely needs to be more research into this particular key. Perhaps one way of determining this is to create a timeline of system activity, and add the LastDetectionTime information for these keys to the timeline.

Getting Started

2011-09-07T06:40:00.000-05:00

We see it all the time...someone starts off an email or post to a forum with "I'm new to the field..." or "I want to get into DFIR work..." and they ask for advice on how to "break in" to the field.

Digital forensic analysis can be a large, daunting field. There's a lot out there (operating systems, platforms, mobile devices, tablets, GPS, applications, etc.), and in many cases, courses available through community colleges and universities sort of lay it all on the table for you, and let you see the enormity of the field, but there simply isn't enough time in the course work to allow for focusing the interest and attention of the future analyst into one particular area of specialization. Add IR work to that and the field expands even more. So, if you're in school looking ahead to graduation and getting a job, or if you're looking to change professions, or if you're just looking to break into the field and get started...how do you do that?

Eat the Elephant

DF is a daunting field. It's huge...expansive. There's a lot out there. There are a lot of different devices that can be (and have been) the subject of forensic analysis...computers, laptops, cell phones, smart phones, tablets, Internet kiosks, GPS devices, smart cars...the list goes on. So how do you get started? The same way you eat an elephant...one bite at a time. Pick something, and start there. A journey of a thousand miles starts with a single step...so get t' steppin'!

This is going to do a couple of things for you. First, it's going to give you some experience. Regardless of where you start, when you do get employment in the field, at some point, you're going to have a sense of deja vu...hey, I've seen this before. It could be during the interview process or it may be during a case. It may be some virtualization software, or a particular version of a browser...whatever. It doesn't matter where you start, the fact that you started is just going to benefit you in the long run.

Second, it's going to show an employer that you can pick stuff up on your own, and that you don't have to be sent away to a training course in order to learn something. Think about it...would you rather have an employee who can learn on their own, or pick up the basics and then go to the intermediate course, or would you rather have someone who simply can't grow beyond where they are without being spoon fed?

Don't have access to some of the materials you'd like? What about your local library? Seriously. Libraries and even used book stores are fantastic resources for some of the available books that cover topics in the field. Maybe you can borrow a book or two from a friend or professor.

However, books aren't necessarily are requirement...a lot of what you need may not be in books. Let's say that you want to become familiar with browser forensics; start with Google, and then branch out from there. Most of the browsers are freely available, so do some testing and analysis, using tools and techniques you've read about.

Have a Passion
I attended the PFIC conference in 2010, and while I was there, Amber talked about accessing the Windows Sync in her car. I thought this was pretty cool because she didn't show up at work everyday and wait for someone to contact her or give her something to do. In this industry, you can't sit back and wait for stuff to come to you...you have to go after it.

There are a LOT of resources available for you to gain experience in the DFIR field. There are images and virtual machines available online that you can download and interact with, and there are a wide range for free and open source analysis frameworks available for you to get experience in analysis, as well.

Even if you don't want to go that route, look around you. How many computer systems do you have access to in your home? How about via friends? There are image acquisition tools and even bootable Linux environments that you can download for free to get experience in acquisition...and once you have an image, you can engage in analysis.

So...pick something, and get started. Even if all you have is a thumb drive, try downloading a tool for dumping physical memory from your Windows system, dump it, and then download a tool to analyze it.

Engage with the Community
There are a number of lists and forums (forii??) out there that are free and open, and allow you to engage with other members of the community. Start reading, and start asking smart questions. By that, I mean, don't post a question because you're too lazy to research it yourself...do some research first. Have a question about carving files? Do some research on the topic, and ask a well thought out question.

This also helps when directing questions at one particular person, or working with a mentor...the better developed your questions are, the easier they are to address and answer.

Resources are not just online...there are IRL resources, as well. In my area, we have the NoVA Forensics Meetups once a month. Don't have one in your area? Start one.

An "artifact" of engaging within the community is that you will likely be recognized for your contributions, and if you're looking to change jobs (or get one), you will be "known" to some degree.

Learn to Write
Shakespeare wrote in "Hamlet", "...there are more things on heaven and earth...than are dreamt of in your philosophy", and that holds true for DFIR work, as well. One of the aspects of the field that a lot of folks don't tell you is that being the best analyst...EVER...is worthless if you can't communicate clearly. And most folks...whether you're in the public or private sectors...want a report. Writing is hard, but only because we don't like to do it. I have the benefit of a wide range of experience...college, military, graduate school, and private sector experience...and I've seen a lot of folks go through a lot of pain to provide the benefit of their abilities to customers, simply because they don't like to write. If you engage in a community as mentioned above, and you've starting asking (and maybe answering) questions, you've already started down the road of developing some writing skills.

When writing, think about your audience. If you're engaged in an online forum, it might be safe to assume that some of the folks reading your questions or posts have a technical background. But what if you decide to start writing tutorials? Let's say that you started to take a look at file carving, and after you had done a great deal of research and study, and worked with several tools, you decided to write up what you learned, either as a tutorial document or a blog post. At that point, your audience may be a little less technical, and you're providing the benefit of your experience so that others can learn.

Now, take that a step further...let's say that you're working in the private sector and just completed analysis for a customer. This report is likely going to go to a high-level (possibly C-suite) manager, who isn't highly technical, and needs information in order to make a business decision. What does he or she want to know? Were we hacked? Who hacked us, how did they do it, what did they take? What risk or compliance issues are we exposed to?

I mentioned getting access to books earlier in this post...going to the library, or a friend, or a professor. One thing you can do besides using that book as a reference or resource is to write a review. How do you do that? Don't reiterate the table of contents...instead, talk about what you found useful (or not so much) in the book. Then post your review in a public location (book retailer's web site, your own blog, etc.)...with your name on it. Why do this? When posting anonymously, we tend to take a much different approach than when we know that what we write can be attributed directly to us, and when you're writing a report in the public or private sector, you can be that the report will be attributed back to you. Do you seriously think that a prosecutor or a CIO is going accept (and pay for) a report submitted by "anonymous"?

Sharing
Writing also gives you the ability to give back to and share with the DFIR community. Mark McKinnon added a list of Jump List AppIDs to the ForensicsWiki not too long ago...he did it by noting which AppIDs were already in the Jump List folder, running another application, and identifying the one that was added...and doing that over and over again. He then added the table to the wiki. That's one way of sharing, and there are others. Put together a white paper. Review an application or tool. Start a blog. Review some material about a particular subject and if you find something within that literature that isn't fully described or even mentioned, blog about it.

There's no requirement within the community or profession that you be able to program, and release open source tools. However, one of the best ways to expand our knowledge and understanding isn't to hoard it, but to share it.

Stuff...and whatnot

2011-09-05T06:39:00.001-05:00

Speaking Engagements
I received notification last week that my submission for the 2012 DoD CyberCrime Conference was accepted. I'll be giving a presentation on timeline analysis at this conference, and I hope to have some new material ready and available to share well before the presentation.

I will also be speaking at PFIC 2011 this year; I actually have two presentations, with a total (according to the schedule) three sessions on the podium. I'll be presenting on "Scanning for Low-Hanging Fruit in an Investigation", as well as "Intro to Windows Forensics". Once I've completed WFA 3/e and everything's been submitted, I plan to focus on some of the material for the first presentation, in particular the scanning framework. This presentation will be a follow-on to my OSDFC presentation from this past June.

The closest alligator to the boat, however, would be presentations I'll be giving at ETCSS in Oct. I'll be giving two presentations on 12 Oct..."What's new in Windows 7: An Analyst's Perspective", and "Incident Preparedness".

eEvidence
The eEvidence What's New page has been updated...I always find a lot of great reading material there. This time around, there are a number of excellent presentations linked from the page...all of which are well worth taking a look at.

NoVA Forensics Meetup
Our next meetup is this Wednesday, 7 Sept. Mitch Harris will be presenting on botnets.

Please take a look at the "NoVA Forensics Meetup" page linked on the right-hand panel of this blog, under "Pages", if you have any questions regarding location, times, fees, attendance requirements, etc. Thanks.

If you still feel the need to ask about attendance requirements and fees, you will have to pay eleventy-three dollars at the door as a cover charge, and you have to come dressed as a clown.

RegRipper Plugins
An archive of new RegRipper plugins was recently released and is available for download at this Google Code site. I didn't write these plugins, but I will say that it is really cool to see folks taking the time to take full advantage of an open source tool such as RegRipper, and create what they need to get the job done.

I did modify some code for one of the plugins. -- contact the author --

Now, I've seen a couple of comments and received an email or two recently regarding adding these new plugins to RegRipper. First, download the archive and copy the plugins into the plugins directory...however, from there, there seems to be some confusion regarding how to get RegRipper to use these new plugins.

The RegRipper plugins folder generally contains types of files; the ones that end with the ".pl" extension should be plugins (Perl scripts), and those that have no extensions should be profiles, or lists of plugins that you'd like to run against a particular hive. The profiles don't have to have a specific name...the ones that were originally shipped with RegRipper (software, system, sam, ntuser, etc.) are just examples, nothing more. You can name one of these files "steve" if you like, it doesn't matter. As long as the file does not have an extension, it will appear in the dropdown list in the RegRipper GUI.

So, when you get a new plugin and add it to the plugin folder, yes, you do sort of have to figure out what you want to do with it. I designed it this way to give analysts the flexibility to run their exams the way they want, to give them choices (hopefully based on knowledge, education, and experience). In order to facilitate determining which hive a plugin is intended for, I added some functionality to rip.pl (or rip.exe, whichever version you're using); for example, if you run rip.pl with the "-l" switch, you will see a listing of plugins with information about each one output to STDOUT. If you add the "-c" switch, the output will in .csv format, which is great for redirecting to a file, which you can then open in Excel. From there, it's pretty easy to create or modify a profile via Notepad.

I also created the Plugin Browser, which was released along with the code/programs for Windows Registry Forensics (RR.zip). This tool provides a graphical method for an analyst to browse through the plugins (hence the name) and even create a profile.

When I sat down and came up with this tool, I wanted the user/analyst to have the ability to decide which plugins to run. After all, there isn't always a need to run all of the available plugins against a hive file; this may simply be too much information to dig through. Some plugins may be redundant, parsing the same information, but just displaying it a different manner (yes, I was once contacted by someone who had run all three plugins that parse UserAssist subkey data and present it in different formats...they asked me what the difference was between them...). There may also be instances in which a plugin may be used in different profiles; for example, I would include the plugin that parses the XP firewall settings in a profile that gets general information about the system, as well as one specifically used to determine if there are any indications of malware on the system.

What this ultimately means is that the analyst is going to have to do something. I'm really sorry about that...but as an analyst using RegRipper, you're going to have make some decisions and take some actions.

Note: Something I wanted to mention again...tools such as RegRipper (and rip) are only as powerful as the analyst using them. If you sit down and expect RegRipper to extract some particular information from the Registry for you, without understanding what the tool is doing, or if there is even a plugin that gets that information, you may be disappointed.

What do I do if it don't work?
If something doesn't appear to be right about the tool you're using, it's usually most helpful if you go directly to the author, and provide information beyond, "it don't work". The response may be simply an update, particularly if it's a known issue. Or you may be using the tool incorrectly...those pesky readme files are such a PITA, aren't they? Or it could be an unanticipated condition...such as when I was working on the Jump List parser and found out what a Jump List "looks like" when it hasn't yet been closed by the operating system (the Jump List was extracted from an image file produced during a live acquisition).

What if a plugin I need isn't in RegRipper?
If there's a particular plugin that you need and can't seem to find, contacting me with a clear description of what you're looking for, as well as providing a sample hive, will usually result in a new or updated plugin in fairly short order. And no, I don't make a habit of sharing the fact that you asked, or sharing the contents of the hive, or the sharing the plugin. I tend to securely delete the hive file once I'm done, and I leave it up to you to share the plugin...unless it's really cool, but then, I'll ask you first. So if you have any trepidation about asking for help, I hope what I've said here will quell those concerns or fears.

Resources
I've posted on using RegRipper to the blog before; there's a link here, and one here. There is also a great deal of information about using RegRipper available in chapter 2 of Windows Registry Forensics.

Books (Again)
I had a section in my last post regarding the use of books I've written or co-authored being used in courses to teach computer forensics. I received an email from Joshua Bartolomie, Adjunct Lecturer at Utica College, and have provided the entirety of his statement, quoted below, with his permission:

To expand a bit on some detail – my associate and I just finished one of our 8 week classes (Computer Forensic Investigations I) in the Cyber Security Master Program at Utica College where we utilized your Windows Forensic Analysis 2ED book as the primary ‘text’ book, with supplemental/ancillary reading via online texts and reports as needed for core concepts and research. We walked through the book and leveraged your examples and case studies in a lot of our discussions and hands-on lab concepts – for the most part the hands-on labs were specifically set to look for, preliminarily evaluate, and compare/contrast available technologies within the vein of the topic at hand. The students responded well to this type of instruction and even those that have done forensic analysis before are keeping your book handy as a practical reference.

We also just started the follow-on class (Computer Forensic Investigations II) and are leveraging the Open Source Digital Forensics book you co-authored as our primary textbook – with the same caveat as above regarding supplemental/ancillary reading via online texts and reports as needed for core concepts and research. The plan that we've outlined in this class is to walk the book front to back and evaluate/compare/use the 'forensic workstations' that are being built. We are building both a Linux and Windows VM concurrently to compare/contrast the environments, their applicable usages, and pro’s and con’s. We are also utilizing these VM’s for analysis and examination hands-on labs as we progress; leveraging standard and/or available forensic test images such as those offered by NIST, Honeynet project, etc. At the end of the class - all of our students should have two fully functional, usable, and relatively cheap/free forensic environments to continue their learning and expansion in this field.

The goal of our classes and overall program is to take a different approach to the traditional theory based Graduate programs, and instead provide our students with viable, practical, and production/operations grade hands-on instruction and usage. The two courses I mentioned above are being taught between myself, with a corporate security focus/background, and one of my associates at Utica College that is also the lead computer forensic investigator for a local police department, with an obvious law enforcement focus/background. We both instruct portions of each of our classes and by tag-teaming them we are able to highlight concepts, protocol/procedures, and issues from our respective areas of expertise. By executing the classes in this manner, we are able to provide them with insight from two generally different operational approaches/angles, and integrating your book(s) provides a solid foundation for hands-on real-world applicability.

This is a great endorsement for all of the books mentioned! When I develop training materials myself, my focus (time permitting) is usually to give those I'm engaged with something that they can use immediately, right there in the course (or as soon as they leave)...that "practical...operations-grade hands on instruction". I do that, because that's what I look for in training courses, as well, regardless of whether it's a 60 minute presentation or a half day of instruction. I tend to look for something I can put my hands on and use. Oddly enough, it turns out that others look for the same thing. So, again...endorsements like this are great, and they're much better than a "review" that simply reiterates the table of contents of the book.

CyberCrime
I'm sure that by now, many of us have heard of this guy, who got 6 yrs for "hacking" user's systems and taking over their webcams and mics, and using information (pictures, video, stuff he listened in to) to extort his victims.

Something else to be aware of, folks, is how this sort of information is presented in the media...notice that the first sentence of the third paragraph mentions "undetectable malware", but later the article actually names some of the malware used (i.e., Poison Ivy).

Tools
If you're into digital forensics analysis of Windows systems, particularly those formatted NTFS, then you should consider taking a look at a couple of tools.

First off, Willi Ballenthin released a Python script for parsing INDX files; Willi's also done an excellent job of providing background information about the tool, as well as why you'd want to use it, so take a look.

Then there's the Windows NTFS journal change log parser from TZWorks, LLC. Tim Mugherini provides a great example of how "jp" was used during a case.

I haven't used either of these tools yet, but I can see where they would be very useful during an examination. I've found indications of files in directories via the INDX files (appear as "$I30" in FTK Imager) when malware or an intruder's tool kit was deleted after use.

Friday Updates

2011-09-02T05:54:00.000-05:00

Prefetch Analysis
I received an email recently that referred to an older post in this blog regarding Prefetch file analysis. The sender mentioned that while doing research into Prefetch files, he'd run across this post (in Polish) that indicated that under certain circumstances, the run count in the Prefetch file "isn't precise". So, being curious, I ran the text of the site through Google Translate, and got the following (in part):

It turns out the meter program starts in the file. Pf is not as accurate. When its value reaches 0A, it is no longer so "eager" to increase at subsequent runs of the program. It also does not update the date of the last run. You can see a correlation here. If  the field meter [0x90] updates, it also updates the date of the last  run [0x78] (actually in this statement is not only the implication that  even equivalence).

I did some  small tests and it turns out that if the difference between the current  date and the date last run stored in the. Pf is less than 2 minutes (120  seconds) it will not update the counter. Also,  if any program (even malware) runs many times in a short period of time  and we would like to know the date of the last of his starts, and the  number - is on file in the folder Perfetch we can ride well.

Another  interesting fact is that if you change the date (even using the watch  in the address bar), we can easily cheat files. Pf. Assume that X was the last time the program was launched in July this year. Someone gained physical access to our computer and wants to run our named with letter X program. Of course would not want the contents of the Prefetch betrayed that there was an unauthorized launch. The method is trivial. The attacker changes the date (eg year 2002) and fires the program. The  difference between 2002 and 2011 is less than 2 minutes (sounds weird,  but subtract the smaller number of larger - we get a negative value). File. Pf remains unchanged, and the program X is seamlessly (from the standpoint of Perfetch) run.

If someone wants a really effective analysis, it appears that the files in the folder Perfetch rather not help him.

In short, what this says is that if someone runs an application several times in quick succession (i.e., 120 seconds, or 2 min), the Prefetch metadata isn't modified accordingly. Interesting stuff, and worth a further look, as if this is information that truly pans out and can be replicated, then it would likely have a significant impact on analysis and reporting. One thing I have thought about, however, is...does this happen? I mean, if a user launches Solitaire, what would be the purpose of launching it again within 2 min? What about malware? Let's say an intruder gains access to a system, and copies over some malware...what would be the purpose of launching it several times, within a 2 min period?

Books
I've known for some time that various courses make use of my books, either as recommended reading or as required texts. For example, I understand from some recent emails that Utica College uses some of my books in their Cyber Security curriculum. As an author, this is pretty validating, and in a way, better than a review; rather than posting a review that says what's in the book, the instructors are actually recommending it or using it. Also, it's great marketing for the books.

Below is a recommendation for Windows Registry Forensics from Andy Spruill (Senior Director of Risk Management/FSO, GSI), posted here with his permission:

I don’t know anyone who is on the fence about your book. As far as I am concerned, it is a mandatory item for anyone in this field.

I have a copy sitting in the lab here at Guidance and another sitting in the lab at the Westminster Police Department, where I am a reserve officer with their high-tech crimes unit. I have another personal copy that I use as an Adjunct Instructor at California State University, Fullerton, where I teach a year-long certificate program in Computer Forensics.

As an author, I usually sit back after a book has been out for a while and wonder if the information is of use to folks out there in the community; is the content of any benefit? I see the reviews posted to sites (Amazon, blogs, etc.) but many of them simply reiterate the table of contents without going into whether the reviewer found the information useful or not. I get sporadic emails from people saying that they liked the book, but don't often get much of a response when I ask what they liked about it. So when someone like Andy, with his background, experience, and credibility, uses and recommends the book, that's much better than a review. This isn't me suggesting to folks that it's a resource...after all, I'm the author, so what else am I going to say? It's someone like Andy...a practitioner and an instructor, teaching up-and-coming practitioners...saying that it's a resource that lends that statement credibility. So, a great big "thanks" to Andy, and to all of the other instructors, teachers, mentors, and practitioners out there who recommend books like WRF and DFwOST to their charges and colleagues.

Analysis
I recently posted on Jump List and Sticky Notes analysis, and also released a Sticky Notes parsing tool. As of 11am, 31 Aug, there were just 10 downloads. One of the folks who downloaded the tool has apparently actually used it, and sent me an email...I received the following in that email from David Nides (quoted here with his permission):

Time after time I see examiners that aren't performing what I would consider comprehensive analysis because they don't go beyond push buttons forensics.

This is something I've mentioned time and again, using the term "Nintendo forensics". Chris Pogue also discusses this in his Sniper Forensics presentations. When developing the tools I wrote for parsing Jump Lists and Sticky Notes, I didn't find a great number of posts on the Interwebs from folks asking for assistance or how to parse these types of files...in fact, I really didn't find any. But I do know of folks are currently (and have been) analyzing Windows 7 systems; when doing so, do they understand the significance of Jump Lists and Sticky Notes, and are these artifacts being examined? Or is most of the analysis that's being done out there simply a matter of loading the acquired image into a commercial forensic analysis application and clicking a button?

Windows 8
What? Windows 8?!? We were just talking about Windows 7, and you've already moved on to Windows 8...and perhaps rightly so. It's coming folks...and I ran across this interesting post regarding improvements in the file operations (copy, move, etc.) experience. There are some interesting statistics described in the blog post, which were apparently derived from analysis of anonymous data provided by Windows 7 users (anyone remember Dr. W. Edwards Deming??). The post indicates that there's some significant tracking and optimization within the new version of Windows with respect to these file operations, and that users are granted a more granular level of control over these operations.

Okay, great...but in the words of Lon Solomon (who's a fantastic speaker, by the way...), "so what?" Well, if you remember when Windows XP came out, there was some trepidation amongst the DFIR community, with folks up in arms, screaming, "what is this new thing?!?"...yet over time, we've come to realize that for the sake of the "user eXPerience", there are significantly more artifacts for analysts. The same is true with Windows 7...so should we (DFIR analysts) expect anything less from Windows 8?

CDFS
If you have had any thoughts or questions regarding the CDFS, or why you should join, here's another resource that provides an excellent view into answering that question. This is a timely post, considering this post that rehashes issues with accreditation and certification in the DFIR industry. Yes, I joined this week, and I'm looking forward to the opportunity to have a say in the direction of my chosen profession.

Google Artifacts
Imagine a vendor or software developer actually providing forensic artifacts...yeah, it's just like that! It seems that Google is doing us DFIR folks a favor and providing offline access to GMail. Looking at some of the reviews for the app, it doesn't look as if there's overwhelming enthusiasm for the idea, but this is definitely something to look for and take advantage of if you find it.

Updates and Links

2011-08-29T20:14:00.001-05:00

Report Writing
One of the hardest parts of what we do is writing reports; technical people hate to write. I've seen this fact demonstrated time and again over the years.

Paul Bobby wrote up a very interesting blog post about criteria for an effective report. As I read through it, I found myself agreeing, and by the time I got to the end of the post, I noticed that there were some things that I see in a lot of reports that had not been mentioned...for example,

One section of the post that caught my eye was the Withstand a barrage of employee objections section...I think that this can be applied to a number of other examinations. For example, CP cases will sometimes result in "Trojan Defense" or remote access claims (I've seen both). Adding the appropriate checklists (and training) to your investigative process can make answering these questions before they're asked an easy-to-complete task.

At the end of the post, Paul mentions adding opinions and recommendations; I don't really so much have an issue with this, per se, as long as the opinions are based on and supported by clearly documented analysis and findings, and clearly and concisely described in the report. In many of the reports I've reviewed over the years, the more prolific the author attempts to be, the less clear the report becomes. Also, invariably, the report becomes more difficult of the author to write.

CyberSpeak Podcast
Ovie's posted another CyberSpeak podcast, this one with an interview of Chris Pogue, author of the "Sniper Forensics" presentations. Chris talks about the components of "Sniper Forensics", including Locard's Exchange and the Alexiou Principles.

Another thing that Chris talks about is Occam's Razor...specifically, Chris (who loves bread pudding, particularly a serving the size of your head...) described a situtation that we're all familiar with, in that an analyst will find one data point, and then jump to a conclusion as to the meaning of that data point, not realizing that the conclusion is supported by that one data point and a whole bunch of assumptions. When I find something that is critical to addressing the primary goal of my examination, I tend to look for other supporting artifacts to provide context, as well as a stronger relative level of confidence, to the data I'm looking at, so that I can get a better understanding of what is actually happening.

At the beginning of the podcast, Ovie addresses having someone review your analysis report before heading off to court, sort of a peer review thing. Ovie said that Keith's mention (in a previous podcast) of this review probably referenced folks in your office, but this sort of thing can also include trusted outside analysts. Ovie mentioned that you have to be careful about this, in case the analyst then goes about talking/blogging about their input to your case. I agree that this could be an issue, but I would also suggest that if the analyst were trusted, then you could trust them not to say anything.

One thing to remember from the podcast is that there is no such thing as a court-approved tool...the term is simply marketing hype.

Finally, Chris...HUGE thanks for the RegRipper (and ripXP) shout-out! And a HUGE thanks to Ovie and the CyberSpeak team for putting together such a great resource to the community.

Morto
I recently blogged regarding Jump Lists, and in that post had indicated what artifacts are available when the user uses the Remote Desktop Client to connect to other systems via RDP. Another thought as to how this might be useful came with F-Secure's announcement of a worm called Morto, which appears to use RDP to spread. How Jump Lists might come into play is if RDP connections are observed between systems (or in the logs of the system being accessed); an investigation might show no Jump Lists associated with the Remote Desktop Client for the primary user on that system. This goes back to what I was referring to earlier in this post...let's say you see repeated RDP connections between systems, and go to the system from which they originated. Do you assume that the connections were the result of malware or the user? Examining the system will provide you with the necessary supporting information, giving you that context.

Mentions of Morto can also be found at Rapid7, as well as MMPC.

NoVA Forensics Meetup Reminder
The next NoVA Forensics Meetup is set for 7 Sept. We're scheduled to have a presentation on botnets from Mitch Harris...I'm really looking forward to it!

Tools
I posted recently regarding StickyNotes analysis, and also recently completed my own StickyNotes parser. It works very well, and I've written it so that the output is available in a listing, CSV, and TLN formats. Not only does it print out information about the embedded notes within the StickyNotes.snt file but it also provides the modification date/time for the "Root Entry" of the .snt file itself. This would be useful if the user had deleted all of the sticky notes as it would provide an indication of user activity on the system (i.e., the user would have to be logged in to delete the sticky notes). In order to write this tool, I followed the MS OLE/Compound Document binary format spec, and wrote my own module to parse the Sticky Notes. As I didn't use any proprietary modules (only used the Perl seek(), read(), and unpack() functions) the tool should be cross-platform.

Anyway, the tool parses out the notes out of the .snt file, and presents information such as the creation and modification dates, and the contents of the text stream (not the RTF stream) of the note. It also displays the modification date for the Root Entry of the OLE document, as well...

C:\Perl\sticky>sn.pl -f stickynotes.snt
Root Entry
Mod Date     : Fri Aug 26 11:51:35 2011

Note: a4aed27b-cfd9-11e0-8
Creation Date: Fri Aug 26 11:51:35 2011
Mod Date     : Fri Aug 26 11:51:35 2011
Text: Yet another test note||1. Testing is important!

Note: e3a17883-cfd8-11e0-8
Creation Date: Fri Aug 26 11:46:18 2011
Mod Date     : Fri Aug 26 11:46:18 2011
Text: This is a test note

I also have CSV and TLN (shown below) output formats:

C:\Perl\sticky>sn.pl -f stickynotes2.snt -t
1314359573|StickyNote|||M... stickynotes2.snt Root Entry modified

In the above example, all of the notes had been deleted from the .snt file, so the only information that was retrieved was the modification date of Root Entry of the document.

Addendum: I've posted the Windows binary of the Sticky Notes parsing tool to my Google Code site. Note that all times are displayed in UTC format.