For those readers who may not be aware, I teach a couple of training courses through my employer, at our facility in Reston, VA.  We're also available to deliver those courses at your location, if requested.  As such, I thought it might be helpful to provide some information about the courses, so in this post, I'll talk about the courses we offer, some we're looking to offer, and what you can expect to get out of the courses.

Windows Forensic Analysis
Day 1 starts with a course introduction, and then we get right into discussing some core analysis concepts, which will be addressed again and again throughout the training.  From there, we begin exploring and discussing some of the various data sources and artifacts available on Windows 7 systems.  Knowing that XP is still out there, we don't ignore that version of Windows, we simply focus primarily on Windows 7.  Artifacts specific to other systems are discussed, as they come up.

Throughout the course, we also discuss the various artifact categories, and how to create and use an analysis matrix to focus and document your analysis. We discuss what data is available, how to get it, how to correlate that data with other available data, and how to get previous versions of that data by accessing Volume Shadow Copies.  All of this is accompanied by hands-on demonstrations of tools and techniques; many of the tools used are only available to those attending the training.

Day 2 starts with a quick review of the previous day's materials and answering any questions attendees may have; if there's any material that needs to be completed from the first day, we finish up with that, and then move into the hands-on exercises.  Depending upon the attendee's familiarity with the tools and techniques used, these exercises may be guided, or they will be completed by attendees, in teams or individually.

Do you want to know what secrets lie hidden within Windows shortcut files and Jump Lists?  Want to know more about "shellbags"?  How about other artifacts?  This course will tell...no, show...you.  Not only that, we'll show you how to use this information  to a greater effect, in a more timely and efficient manner, in order to extend your analysis.

Each attendee receives a copy of Windows Forensic Analysis Toolkit 3/e. 

Timeline Analysis 
Day 1 - Much like the Windows Forensic Analysis course, we start the first day with some core analysis concepts specific to timeline analysis, and then we jump right into exploring and discussing various data sources and artifacts as they relate to creating and analyzing timelines.  We discuss the various artifact and event categories, and how this information can be used to get more out of your timeline analysis.

Day 2 starts off with completing any material from the first day, answering any questions the attendees may have, and then kicking off into a series of scenarios where questions are answered based on findings from a timeline; we not only go over how to create a timeline, but also how to go about analyzing that timeline and finding the answers to the questions.

If you can't remember all of the commands that we go over in the course, don't worry...you can write down notes on the provided copies of the slides, or you can turn to the provided cheat sheet for hints and reminders.  Many of the tools used in this course are only available to those attending the course.

Each attendee receives a copy of Windows Forensic Analysis Toolkit 3/e.

Registry Analysis
This 1-day course is based on the material in my book, Windows Registry Forensics. As such, we spend some time in this course discussing not only the structure of the Registry, but also the value of performing Registry analysis.  There is a good deal of information in the Registry that can significantly impact your analysis, and the goal of this course is to allow you to go beyond assumption to determining explicitly why you're seeing what you're seeing. 

As you would guess, we spend some time discussing various tools, and some attention is given to RegRipper.  For those interested, attendees will receive plugins that are not available through the public distribution.  We also spend some time discussing the RegRipper components and structure, how it's used, and how to get the most out of it.

One of the take-aways we provide with this course is a graphic illustrating various components of USB device analysis, showing artifacts that aren't addressed anywhere else.

Each attendee receives a copy of Windows Registry Forensics.

Why Should I Attend?
That's always a great question; it's one I ask myself, as well, whenever I have an option to attend training.

Each attendee is provided the tools for the course, which includes tools that are only available to you if you attend the course.  Tools for parsing various data structures, including RegRipper plugins that you can't get any place else.  Several publicly available tools are discussed in the courses, but due to licenses, are not provided with the course materials.  In such cases, the materials provide links to the tools.

I continually update the course materials.  I sit down with the materials immediately following a course and look at my notes, any questions asked by attendees, and I pay particular attention to the course evaluation forms.  When something new pops up in the media, I like to be sure to include it in the course for discussion.  Updates come from other areas, as well...most notably, what I get from and how I perform my analysis.  New techniques and findings are continually incorporated directly into the training materials.

As the Windows operating systems have gotten more complex, it's proven to be difficult for a lot of analysts to maintain current knowledge of the various artifacts, as well as analysis tools and techniques.  These courses will not only provide you with the information, but also provide you with an opportunity to use those tools and employ those techniques, developing an understanding of each so that you can incorporate them into your analysis processes.

What Do I Need To Know Before Attending?
For the currently available courses, we ask that you arrive with a laptop with Windows 7 installed (can be a VM), a familiarity with operating at the command prompt, and a desire to learn.  Bring your questions.  While sample data is provided with the course materials, feel free to bring your own data, if you like.

The courses are developed so that you do NOT want to book all of these courses in a single 5-day training course.  The reason is that a great deal of information is provided in the Windows Forensic Analysis course, and if you've never done timeline analysis before (and in some cases, even if you have), you do not want to immediately step off into the Timeline Analysis course. It is best to take the Windows Forensic Analysis (and perhaps the Registry Analysis) course(s), return to your shop, and make develop your familiarity with the data sources before taking the Timeline Analysis course.

If you've ever seen or heard me present, you know that I am less about lecturing and more about interacting.  If you're interested in engaging and interacting with others to better understand data sources and artifacts, as well as how they can be used to further your analysis, then sign up for one of our courses.

Upcoming Course(s)
Malware Detection - By request, I'm working a course that addresses malware detection within an acquired image.  I've taught courses similar to this before, and I think that in a lot of ways, it's an eye-opener for a lot of folks, even those who deal with malware regularly.  This is NOT a malware analysis course...the purpose of this course is to help analysts understand how to locate malware within an acquired image.  This is one of those analysis skills that traverses a number of cases, from breaches to data theft, even to claims of the "Trojan Defense".

Others - TBD.

---

Our website includes information regarding the schedule of courses, as well as the cost for each course.  Check back regularly, as the schedule may change.  Also, if you're interested in having us come to you to provide the training, let us know.

I finished up leading a Timeline Analysis Course on Tuesday afternoon, ending two days of some pretty intensive training.  One of the things I find when I'm putting presentations or courses together, and then actually giving the presentation, is that I very often end up learning a good deal along the way, and this time around was no different.  As has happened in the past, what I learn leads me to revisit and possibly even modify tools or analysis techniques, and again, this time was no different.

One of my biggest takeaways from the training is that I need to reconsider how at least some of the available time stamped data is presented in a timeline.  One of those items is how Prefetch file metadata is represented and displayed; I've since updated the parsing tool to address this particular item.  Another, and the one I'm going to discuss in this blog post, is how Windows shortcut (LNK file) information might be displayed in a timeline, or more specifically, what information about LNK files might possibly need to be presented in a timeline.

Category IDs
So, as a bit of background, I've been thinking quite a lot lately about how to better take advantage of timeline data.  As I was putting the timeline course together, it occurred to me that I was going to be spending a good deal of time describing to attendees how to create a timeline, and even walking them through this process with demonstrations and hands-on exercises, but spending very little time discussing how to actually analyze the timeline data.  The simplest answer is, it depends.  It depends on your exam goals, why you're performing the exam, and why you created a timeline in the first place.  It occurred to me that I was making an assumption that most analysts would have a good solid justification for creating a timeline as part of their analysis process.  If that were the case every time, I wouldn't have folks signing up for a timeline analysis course, would I?  I'm not saying that analysts don't have a justification for creating a timeline, but sometimes that justification be, "...that's what we always do...", or "...that's what I did last time."

Timeline analysis is something of a data reduction technique...we go from a 500GB hard drive or image, to somewhere around a GB or so of data, and we then arrange it based on a time value in the hopes of obtaining some context and increasing our relative confidence in the data that we're looking at; that's the goal, anyway.  But by grabbing just the data directly associated with a time value, we end up performing a great deal of data reduction.  Even so, we still need a means for directing our analysis, or getting the cream to rise to the top of the container.

Something I'd discussed in a previous blog post was the concept of categories for events.  Rob Lee has done some considerable work in this area already, providing a color-coded Excel macro that implements the category ID scheme he's identified via resources such as the SANS DFIR poster.  Regardless of the method used to identify event types or categories, the idea is to develop some method to assist the examiner in her analysis of the timeline.  After all, if you have something of an idea of what you're looking for, then finding it might be a bit easier if you classify various events by type or category, and then have some means to identify the events accordingly (via color, a tag or identifier, etc.).

Shortcut/LNK Files
Speaking of categories, perhaps one of the most difficult artifacts to classify into a single category is Windows shortcut/LNK files.  Without getting into a long discussion about this, let's take a look at an example of what's available in an LNK file found in a user's Recent folder:

atime                         Tue May 15 21:11:59 2012                         
basepath                    C:\Users\                                        
birth_obj_id_node       08:00:27:dd:64:d1                                
birth_obj_id_seq         9270                                             
birth_obj_id_time        Tue May 15 21:09:27 2012                         
birth_vol_id                 2C645C57...13C2834AAD2                 
commonpathsuffix       john\Downloads\Autoruns.zip                      
ctime                           Tue May 15 21:11:59 2012                         
filesize                        535772                                           
machineID                  john-pc                                          
mtime                         Tue May 15 21:11:59 2012                         
netname                     \\JOHN-PC\Users                                  
new_obj_id_node        08:00:27:dd:64:d1                                
new_obj_id_seq          9270                                             
new_obj_id_time        Tue May 15 21:09:27 2012                         
new_vol_id                 2C645C57...13C2834AAD2                 
relativepath                ..\..\..\..\..\Downloads\Autoruns.zip            
vol_sn                        F405-DAC1                                        
vol_type                     Fixed Disk          

As you can see, we have a number of data elements available to us once we've decoded the binary contents of the LNK file, any of which (or any combination of which) may be relevant or significant to our analysis.  For example, as the LNK file was found in the user's Recent folder, we can assume that the existence of the file indicates some form of user activity; that is, the user must have done something, must have performed a specific action (such as double-clicking the file) that caused that LNK file to be created.

Next, we have the path to where the target file was located within the file system, as well as the MA.B times of the target file at the time that the shortcut was created. That might be significant to your analysis, as it demonstrates both knowledge of and access to a file, and will persist even after the target file is no longer available.

Had the LNK file been located on the user's Desktop and pointed to an EXE target file, this might illustrate specific actions taken by the user, such as installing an application.  This might also indicate program execution, rather than file access.

If the target file in the shortcut is a document or image, this might also illustrate program execution.  Launching the shortcut would cause the Windows system to reach into the Registry in order to determine which application with which files with the target file's extension are associated.  For example, let's say a shortcut "points to" a .avi video file.  On some systems, launching a shortcut that points to a video file might cause Windows Media Player to be launched automatically; on other systems, it might be another application all together.  Either way, the existence of an LNK file might also illustrate program execution or application launch.

Finally, we see that the last item visible in our example is called "vol_type", which refers to the type of volume where the target file was at the time of the activity.  In this case, the C:\ volume is a "Fixed Disk"; if it wasn't, would that be significant?  For example, if the volume type were "removable media" or a "network share", would that be significant to your exam?  In some cases, it could very well be, and we might look to that information for indications of access to or use of removable storage devices, or of network shares.

Perhaps the idea here isn't to classify LNK files into a single category, but instead filter the various data items found within LNK files based on a set of rules, and produce timeline events based on the output of each of the rules, where appropriate.  This might mean that for a single LNK file, we might end up with multiple events in our timeline.

Resources
ForensicsWiki LNK page

What is a way to use a system to perform various activities, but leave minimal traces? One might think that any of the available cleaner tools (anyone remember SilentRunners.vbs?) would be the answer, but such tools can be too good, making it clear that something was used to wipe artifacts off of the system, harkening back to one of the adages in my books, that the absence of an artifact is itself an artifact.

Think virtualization. Think plugging in a USB device (thumb drive, iPod, etc.) that contains its own running operating system, along with its own tools and storage area. This isn't something that I've seen a lot of, but in a time when the media is telling us that declines in the economy are leading to increased data theft by departing employees, its something to consider.

Diane Barrett has talked about how virtuatlization affects forensics. When portable virtual environments such as MojoPac or Moka5 are used, the analyst is presented with a whole new set of challenges, as the usual remnants and artifacts (i.e., browser history, Registry settings, etc.) won't be available on the confiscated system. Instead, all artifacts will be on the USB storage device that contains the virtual environment, and only indications of the use of these environments (USBStor and MUICache Registry key entries, etc.) will be found.

So, the days of a simple, straightforward examination are fading into the past. Concerns of data leakage or IP theft just took on another dimension... going from file copying and malware and Trojans to leakage via social networking sites and virtualized environments. What's needed is specialized research and training to keep up with developments.

Resources
PortableUbuntu
Qemu Manager - Manager for Qemu VMs
Running the OLPC Image in Qemu
ReactOS (use Qemu or VMWare)
Run Haiku under Qemu (Haiku is based on BeOS...I added this one for pure kewlness...)
Portable Virtual Privacy Machine
Windows + Qemu + Plan 9 (again...pure kewlness)
OS/2 Warp 4 on Qemu (ok, that's just going for the extra nerd points...)

The Need
There is a need for effective incident response, now more than ever. However, the key to incident response is incident preparedness. Responding without being prepared to respond correctly is what turns an incident into a major data breach and a major embarrassment.

Addendum: If you don't think incidents are going to happen, or that they aren't going to happen to you, take a look at this SecurityFix post from Brian Krebs. To be clear, the very first sentence says "reported"...which perhaps indicates a subset of what was actually detected.

There are three primary characteristics of effective incident response, and knowing and understanding these lead to being better prepared to respond to incidents:

1. Completeness of Data
When I am called to respond to an incident, there are four sources of data I will generally look for, to some degree, regardless of the type of incident:

- Network traffic captures
- Logs from network devices (firewalls, routers, etc.)
- Host-based volatile data
- Host-based non-volatile data

Now, you may not need data from every source for every incident, and the value of the data from these sources may vary depending upon the incident. In all the time I've been doing IR, in various capacities, I can't recall a single time when I've had all four sources of data available...in fact, in most cases, I'm lucky to get one, and it's a miracle to have two.

2. Accuracy of Data
How accurate the data is in many cases can depend upon what it is you're actually trying to do. For example, capturing portions of volatile memory using a batch file and third party tools (ie, tlist.exe, tcpvcon.exe, etc.) to get the list of active processes, network connections, etc., may be accurate enough for your needs. However, in other instances, collecting the full contents of physical memory may be the only means of achieving accuracy (and completeness) of data.

3. Temporal proximity
This is a term I borrowed from Aaron Walters (of Volatility fame), not because it's cool and Star Trek-y sounding, but because it makes perfect sense. The sooner you begin responding to an incident, the more complete and accurate data you're going to get, and your overall response is going to be more effective and lead to better remediation, etc.

Since this field is wrought with analogies, let's try this one...as a homeowner, do you have smoke detectors in your home? How about fire extinguishers? I do. How about insurance? When you called for your insurance, did the insurance company ask how far you are from the nearest hydrant? How about from the nearest fire department? Did you get a home inspection prior to purchasing your home? Is it up to code with respect to exits, etc? Do you know what to do in case of a grease fire in your kitchen?

So, your home is full of valuables, in particular, your family. If your home were to catch fire, what would you do? First off, how would you know? Then, once you knew, what would you do? Would you just wait until the house burned down to call the fire department?

Now, map your home to your network infrastructure, and a fire to a data breach. Where are your valuables? Do you have a detection mechanism? Are you able to respond immediately and correctly to a grease fire?

This example shows, in part, that temporal proximity plays an important role in incident response, but it also highlights the need for approaching it the right way, which may include training. So what does this mean for the coming year? Well, it should mean that training will be more important than ever. Think about it. If a small fire starts in your house, would you (a) wait for an hour, then call the fire department, (b) wait for the house to burn down completely, or (c) begin putting the fire out yourself immediately? With respect to computer security incidents, who is in a better position to respond immediately...the sysadmin who is currently logged into the console, or an responder such as myself who is 24-48 hrs away from being on-site? Not only is the sysadmin there, but she more than likely knows the systems and the architecture very well; an external responder such as myself is going to have to get up to speed on your architecture, and even then won't have all of the little nuances.

This is all fine and good, but as Lon Solomon is fond of saying, "so what?" The fact is that many organizations simply don't put any effort or resources into their response plan because they feel that there's no requirement to do so.

External Forces
I'm not going to make a prediction for the future, but the primary drivers for incident response in 2009 (and beyond) will continue to be external forces; specifically, legislative and regulatory compliance requirements. Why is that? Because they have to be. After all, most of us think that if someone is making a business out of storing and/or processing our sensitive (PII, PHI, PCI) data, then of course they'll do everything they can to protect and secure that data. I mean, why wouldn't they, right? After all, if a buddy wants you to hold $50 for him, or the ring he's going to present his bride at their wedding, then you're going to do everything you can to protect that data, right? For many of us, this is just what we think of as common sense, but that's sadly not the case with your sensitive data. Look here, or here. And things only start to change when some external forces come into play, and those forces are strong enough to act as the stimulus to cause that change...those external forces being legal (think CA SB-1386, etc.) or regulatory compliance (think HIPAA, Visa PCI, etc.) requirements.

During first responder activities, be they simple troubleshooting or incident response related, one of the important pieces of information that can really provide some insight into the behavior and status of a system is process-to-port mapping.

Why is this information important? Well, it really depends on what you're looking for, but if your initial indicator or notification of a potential security incident is "unusual traffic" originating from a system, then you'd want to know what process was generating that traffic...right? After all, there are a couple of truths you need to keep in mind when troubleshooting or performing IR activities. One is that network traffic never spontaneously emanates from a system without a cause...there's always some process involved. Another is that nothing happens on a system without some code executing as part of a thread/process.

Okay, moving on...

With NT, getting process-to-port mapping information wasn't easy. You had to use a tool like fport to get the information. The same was true for Windows 2000, and it was really cool that as of XP, netstat.exe had the '-o' switch added so that you could get the network connections with the associated PID all on one line (this is great for scripting! =) )

Many folks may not be aware that there was an update to Windows 2000 that added the '-o' capability to netstat.exe on that platform. If you've got Windows 2000 systems, this is a great update to add, so that (as an admin) you have the capability to get the information you need.

Another tool you can use to get this information during IR activities is tcpvcon. I prefer this tool because it can be included in a batch file (reducing overhead), and the output can be sent to .csv format, which is great for parsing with Perl scripts.

Analysis Tip: One of the things you might run across during an engagement is working with admins who are network-centric...or being one of those network-centric admins. For example, you may get some indication of an issue from traffic captures, or IDS/IPS/firewall notifications or logs. In such cases, you very often have a couple of pieces of information available to you, one of them being the source IP of the traffic, which you would likely use to locate the system from which the traffic originated (assuming that it wasn't spoofed). But guess what? You will very likely also have the source port for the traffic...and this will information (if you don't ignore it) may assist you in identifying the process from which the network traffic had been generated. Something as simple as "netstat -ano | find " may be all you need to do to find the process that generated the traffic.

How is this important? Well, one more than one occasion, incident responders such as myself have encountered those who've said, "...we saw some unusual traffic, found the system, and scanned it with [insert AV product name], and found a virus." In such cases, there may be no correlation whatsoever between the traffic and whatever the AV product found (could've been a DLL or a Registry key...) - this is "incident response by assumption/speculation", which is about as bad as "security through obscurity".

Do I need to say it again? The age of Nintendo Forensics is gone, long past.

Acquiring a system is no longer as simple as removing the hard drive, hooking it up to a write blocker, and imaging it. Storage capacity is increasing, devices capable of storing data are diversifying and becoming more numerous (along with the data formats)...all of which are becoming more ubiquitous and common-place. As the sophistication and complexity of devices and operating systems increases, the solution to the issue of backlogs due to examinations requiring additional resources is training and education.

Training and education lead to greater subject-matter knowledge, allowing the investigator to ask better questions, and perhaps even make better requests for assistance. Having a better understanding of what is available to you and where to go to look leads to better data collection, and more thorough and efficient examinations. It also leads to solutions that might not be readily apparent to those that follow the "point and click execution" methodology.

Take this article from Police Chief Magazine, for example. 1stSgt Cohen goes so far as to specifically mention the collection of volatile data and the contents of RAM. IMHO, this is a HUGE step in the right direction. In this instance, a law enforcement officer is publicly recognizing the importance of volatile data in an investigation.

It's also clear from the article that training and education has led to the use of a "computer forensics field triage", which simply exemplifies the need for growth in this area. It's also clear from the article that a partnership between law enforcement, the NW3C and Purdue University has benefited all parties. It would appear that at some point in the game, the LEs were able to identify what they needed, and were able to request the necessary assistance from Purdue and NW3C...something known in consulting circles as "requirements analysis". At some point, the cops understood the importance of volatile memory, and thought, "we need this...now, how do we collect it in the proper manner?"

So what does this have to do with alternative methods of analysis? An increase in knowledge allows you to seek out alternative methods for your investigation.

For example, take the Trojan Defense. The "purist" approach to computer forensics...remove the hard drive from the system, acquire an image, and look for files...appears to have been less than successful, in at least one case in 2003. The effect of this decision may have set the stage for other similar decisions. So, let's say you've examined the image, searched for files, even mounted the image as a file system and hit it with multiple AV, anti-spyware, and hash-comparison, and still haven't found anything. Then lets assume you had collected volatile data...active process list, network connections, port-to-process mapping, etc. Parsing that data, wouldn't the case have been a bit more iron-clad? You'd be able to show that at the time the system was acquired, here are the processes that were running (along with their command line options, etc.), installed modules, network connections, etc.

At that point, the argument may have been that the Trojan included a rootkit component that was memory-resident and never wrote to the disk. Okay, so let's say that instead of running individual comments to collect specific elements of memory (or, better yet, before doing that...), you'd grabbed the contents of RAM? Tools for parsing the contents of RAM do not need to employ the MS API to do so, and can even locate an exited or unlinked process, and then extract the executable image file for that process from the RAM dump.

What if the issue had occurred in an environment with traffic monitoring...firewall, IDS and IPS logs may have come into play, not to mention traffic captures gathered by an alert admin or a highly-trained IR team? Then you'd have even more data to correlate...filter the network traffic based on the IP address of the system, isolate that traffic, etc.

The more you know about something, the better. The more you know about your car, for example, the better you are able to describe the issue to a mechanic. With even more knowledge, you may even be able to diagnose the issue and be able to provide something more descriptive than "it doesn't work". The same thing applies to IR, as well as to forensic analysis...greater knowledge leads to better response and collection, which leads to more thorough and efficient analysis.

So how do we get there? Well, someone figured it out, and joined forces with Purdue and NW3C. Another way to do this is through online collaboration, forums, etc.