Devices

Something I learned very early on as a DF/IR consultant was that you're likely never going to run into a perfect environment as an on-call responder. In fact, the best you can hope for is an environment with the default logging, for the OS and applications, and that the logs haven't been cleared. Even then, those two conditions aren't always the case. Even today, in 2026, I regularly see environments where auditing of successful logins has been disabled, so they don't appear in the Security Event Log. 

As such, it's not only important to keep up with what's available from the default installation of an endpoint, and what sources can be used to validate your findings, but also note what's available depending upon the applications installed.

However, what's most important are your analysis goals. For example, it's easy to say, "I want to see all USB devices connected to the endpoint", and not provide a timeframe. However, to what are these devices pursuant? IP theft? Violation of acceptable use policies? What about CSAM production? After all, smartphones and digital cameras can be connected to a computer via a USB cable, but use different protocols, and information about the devices being connected can be found in other locations than those that we traditionally look to as a result of training we may receive.

When it comes to devices connected to a Windows system, things have definitely changed over time. Cory and I published a peer-reviewed paper in 2005, covering USB artifacts on Windows XP systems. Since then, there's been quite a few changes to Windows, and as one would expect, how devices connected to an endpoint are tracked. Nicole mentioned some time ago  (2014) that different protocols used by different devices (in this case, smartphones) have an impact on investigations; unfortunately, as time has gone on, I've had a hard time linking back to Nicole's published research or even her presentations, but one of her presentations can be found here.

This WindowsIR blog post describes the fact that some of the Windows Event Log files we might look to in order to investigate USB devices connected to an endpoint have been seen to be disabled, and recommended some alternative data sources. Similarly, this NirSoft page for the USBDeView application similarly recommends data sources.

Speaking of the WindowsIR blog, here's a whole series of blog posts about just "USB devices".

Now, as to why I'm writing this blog post, in the first place...

I recently ran across this LinkedIn post from Garrett Moreau, which I thought was interesting. He's right, in that information about devices connected to/removed from the endpoint is stored in the Registry, and not just in the USBStor key. RegRipper, for example, includes multiple plugins within the "devices" category. What's really eye-opening is to read through the comments to the post; one comment, for example, states the following:

Quick note for defenders, default logging settings don’t provide much depth.

USB events are recorded under the Applications and Services Logs > Microsoft > Windows > DriverFrameworks-UserMode > Operational path, but this log must be activated manually.

Previous versions of Windows required activation of these events using PowerShell.

While the statement is true, this goes back to what I said earlier about traditional training, and the need to not only keep playbooks up to date, but to also pursue other alternative data sources. A data source we're familiar with, the Microsoft-Windows-DriverFrameworks-UserMode Event Log, is now disabled by default, and as stated, doesn't provide "much depth". However, if understanding the USB devices connected to an endpoint are part of your investigative goals, then keeping playbooks updated is key.

Some of the comments go one to suggest other data sources that might be used to add granularity or context to your investigations, such as shellbags (for directory transversal), etc. In the past, I've found the Application Event Log, and in particular, MsiInstaller events to be useful in illustrating attempts to install applications from a USB device. 

My recommendation is this...first and foremost, understand your analysis goals; what are you attempting to show, to prove or disprove? From there, maintain playbooks associated with these goals, and if you're in a role where you're dealing with different implementations and applications, keep documentation on any new findings that apply to specific edge cases, as you never know when you will see such things again. An excellent example of this is when Don Weber worked a case where the LANDesk Software Monitoring application was installed on an endpoint, and found that the application provided valuable information regarding program execution. 

Addendum, 2 Mar: Just yesterday, I became aware of this USB Devices article from ElComSoft, which addresses different types of USB-connected devices, and resources for investigating them.

Analysis Playbooks: USB

In 2005, Cory Altheide and I published the first peer-reviewed paper to address tracking USB devices on Windows systems. Over the years, it's been pretty amazing to see not only the artifacts expand and evolve, but to also see folks pick up the baton and carry on with describing what amounts to a "playbook" for developing this information as part of an investigation. Not only did malware such as Raspberry Robin propagate via USB devices, but with the rise of other devices that could be attached via a USB connection, but use different protocols, it became more important to operationalize this analysis in a playbook. 

After all, why not take the inefficient, error-prone, purely manual aspects out of the parsing by automating it?

Morad R. put together a series of posts that outline different data/artifact sources you can examine to identify USB devices that had been connected to the endpoint, as well as attribute the use of the devices to a particular user. This series of posts illustrates some steps that begin the process of pulling back the veil, if you will, to unraveling the use of USB devices on Windows systems. While there is definitely more to be done and shared, the important common factor across the posts is the use of timelines. 

USB Forensics, pt 1: Unmasking the connected device - Focuses on the System Registry hive, and extracting time stamps from Properties key values. The focus on a timeline is great way to get started on this, as doing so takes the analyst directly to context. 

However, by focusing on just USB and USBStor keys in the System hive, other devices (smartphones, digital cameras) are missed. However, that's not really an issue, per se, as the same playbook can be applied to the appropriate Registry keys.

USB Forensics, pt 2: Mapping device to user & drive letter - focuses on the user's NTUSER.DAT, but doesn't mention other artifacts, such as shellbags, RecentDocs, UserAssist, etc., that could be used to correlate additional user activity with the device, particularly via a timeline. 

RegRipper still makes use of "profiles", which is the term I used to describe what became known as "playbooks". Or, another way to look at it is that you can implement playbooks through these profiles.

USB Forensics, pt 3: The Event Log timeline - focus on a timeline continues, which is good. However, the logs are technically referred to as "Windows Event Logs"; "Event Logs" refer to the Windows 2000, XP, and 2003 era logs. I understand, I 'get it', that this is a distinction without a difference for most analysts, particularly those who've never had to work with Event Log records from older systems, and are only familiar with the new format implemented as of Windows Vista. 

All three of these posts, together, serve as a good foundation, and a great first step toward addressing USB-connected devices on Windows endpoints. Just as the field has grown and expanded since 2005, it will continue to do so in the future. In addition to providing the data sources, the underlying reliance on (or at least pointing in the direction of) timelines is, I believe, foundational. Start with a timeline, do not let a timeline be something you assemble manually, after everything else is done. We can always add or remove data sources, create new RegRipper or Events Ripper plugins, etc., but creating a timeline should be "first principles". 

In my current role, I don't have a need to determine things such as USB devices connected to a Windows system, but if I did, I'd definitely have Events Ripper plugins to extract that information, maybe even correlate it, into an easy-to-view manner. 

This is just some of the content from my blog that explicitly addresses USB devices:

Something old, something new...with USB - 2006-09-26

From the Lab: Mapping USB devices via LNK files - 2007-04-09

HowTo: USB Thumb Drives - 2012-02-04

HowTo: Correlate an Attached Device to a User - 2013-07-01

USB device redux, with timelines - 2022-05-26

USB Device Redux, with Timelines

If you ask DFIR analysts, "What is best in life?", the answer you should hear is, "...creating timelines!" After all, industry luminaries such as Andrew said, "Time is the most important thing in life, and timelines are one of the most useful tools for investigation and analysis.", and Chris said, "The timeline is the central concept of all investigative work."

My previous blog post addressed USB-connected devices, but only from the perspective of Windows Event Logs. In this blog post, I wanted to include data from the Registry, incorporated in a timeline so that the various data sources could be viewed through a common lens, in a single pane of glass. 

I stated by using wevtutil.exe to export current copies of the five Windows Event Logs to a central location. I then used reg.exe to do the same thing for the System hive. I then used my timeline process (outlined in several of my books) to create the events file from the six data sources; I used wevtx.bat to parse the Windows Event Logs, and three newly created RegRipper Pro plugins to parse the relevant data from the System hive. The specific keys, values and data parsed from the hive were based largely on Yogesh's blog post, and this academic paper posted at the ResearchGate site. I created the initial plugins, and then modified them to display TLN-format output, for inclusion in timelines.

For this research, there where three specific devices I was interested in...my iPod, my iPhone, and a SanDisk Cruzer USB thumb drive. After creating the overall events file, I used the "type" and "find" commands to look for events associated specifically with those devices, isolated each into their own individual "overlay" events file, and then created timelines from each of those events files. This approach makes it easy to "see" what's going on and create artifact constellations, as I don't have to filter out "noise" associated with other events, and I still have the overall events file that I refer to. 

What I'm sharing below are partial timelines of events, just enough to demonstrate events based on intentionally limited data sources, so that initial artifact constellations can be developed. From this point, the constellations can be built out; for example, accessing files the SanDisk Cruzer will produce Windows shortcut files pointing to files on the "E:\" volume. Again, these timeline overlays are not complete, but are intended to demonstrate Registry artifacts associated with USB-connected devices alongside Windows Event Log artifacts.

iPod

A while back, I inserted my iPod into my computer in order to retrieve music files, via iTunes, so that I could transfer them to my iPhone. I didn't think much about it at the time, but the connection was clearly "remembered" by Windows 10, specifically via the Registry.

Here are the events around the insertion:

Sun Jan  2 19:41:21 2022 Z

  REG                        - First Inserted - Apple iPod [6&3091e96e&0&0000]

  REG                        - First Install - Apple iPod [6&3091e96e&0&0000]

  EVTX     Stewie     - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPod,4.3.5,40

  REG                        - Last Inserted - Apple iPod [6&3091e96e&0&0000]

Sun Jan  2 19:41:15 2022 Z

  EVTX     Stewie            - Microsoft-Windows-DeviceSetupManager/112;iPod,{fc916355-34ea-555c-9e24-3c59f6125097},2,42,11

And here are the events around the removal of the device from the computer, a little more than 14 minutes later:

Sun Jan  2 19:55:46 2022 Z

  REG                        - Last Removal - Apple iPod [6&3091e96e&0&0000]

The completed message string for the "Microsoft-Windows-DeviceSetupManager/112" event above is:

Device 'Apple iPod' ({fc916355-34ea-555c-9e24-3c59f6125097}) has been serviced, processed 6 tasks, wrote 34 properties, active worktime was 11748 milliseconds.

I state this specifically because following the "Last Removal" event on 2 Jan 2022, the timeline contains an additional 9 events from 6 Jan to 22 May, all for the same "Microsoft-Windows-DeviceSetupManager/112" event records for the iPod, but the last three string entries are different. In every case, only 1 task is run, and the active worktime runs from 0 to 31 milliseconds. I know that the iPod was not plugged in during these times, and as such, this seems to be an artifact the installation process.

iPhone

I have connected my iPhone to this Windows 10 system via a USB cable, to transfer pictures from it, and to transfer music files to it, via iTunes. Here was see one such connection on 7 May 2022:

Sat May  7 14:16:35 2022 Z

  REG                        - Last Removal - @oem119.inf,iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device [00008030000E6C6C11DA802E]

  REG                        - Last Removal - Apple iPhone [6&139bb8e1&1&0000]

Sat May  7 14:14:57 2022 Z

  EVTX     Stewie            - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPhone,15.4.1,40

  EVTX     Stewie            - Microsoft-Windows-DeviceSetupManager/112;Apple iPhone,{7e8068a1-2d62-53fb-8285-a12072dfa871},4,34,296

Sat May  7 14:14:56 2022 Z

  REG                        - Last Inserted - Apple iPhone [6&139bb8e1&1&0000]

  REG                        - Last Inserted - @oem119.inf,iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device [00008030000E6C6C11DA802E]

There's information later in the timeline regarding another connection to the system, this time to copy pictures off of the iPhone. The "Last Inserted" and "Last Removal" events are from a different Registry key as seen above, as noted by the serial number in brackets at the end of the "event".

Fri Apr 15 16:23:13 2022 Z

  REG                        - Last Removal - @oem119.inf,iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device [6&139bb8e1&1&0001]

...

Fri Apr 15 16:19:02 2022 Z

  EVTX     Stewie            - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPhone,15.4.1,40

Fri Apr 15 16:18:57 2022 Z

  EVTX     Stewie            - Microsoft-Windows-DeviceSetupManager/112;Apple iPhone,{7e8068a1-2d62-53fb-8285-a12072dfa871},4,34,140

  REG                        - Last Inserted - @oem119.inf,iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device [6&139bb8e1&1&0001]

Cruzer

The artifact constellation for the SanDisk Cruzer thumb drive is a bit different from that of the iPhone and the iPod. In this case, the events around the last time the device was inserted and then removed from the computer is less than a minute...

Mon May 16 22:07:08 2022 Z

  EVTX     Stewie            - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,0,0,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,...

  REG                        - Last Removal - SanDisk Cruzer USB Device

  REG                        - Last Removal - Cruzer   [E:\]

Mon May 16 22:06:26 2022 Z

  EVTX     Stewie            - Microsoft-Windows-Ntfs/145;3,{1e09345e-d3d4-11e8-92fd-1c4d704c6039},2,E:,false,0,{fab772f6-83e6-5d5f-1086-740d39e45bff},8,SanDisk ,16,Cruzer ...

  EVTX     Stewie            - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,512,8036285952,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,Integrated : ...

Mon May 16 22:06:24 2022 Z

  EVTX     Stewie            - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,0,0,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,...

  EVTX     Stewie            - Microsoft-Windows-DeviceSetupManager/112;Cruzer,{81fa6fcf-bfc9-5887-bdbc-2cffb6be0b29},4,34,281

  REG                        - Last Inserted - Cruzer    [E:\]

  REG                        - Last Inserted - SanDisk Cruzer USB Device

Note that several of the events, particularly those from the Partition/Diagnostic Event Log, are shortened here for readability.

Registry 

Each of the above three devices appears in the Registry, specifically in the System hive, sometimes in multiple locations. For example, the SanDisk Cruzer thumb drive appears in both the USBStor and WPDBUSENUM subkeys.

From the USBStor key:

Disk&Ven_SanDisk&Prod_Cruzer&Rev_8.02

  2443931D6C0226E3&0

    DeviceDesc     : @disk.inf,%disk_devdesc%;Disk drive

    Mfg            : @disk.inf,%genmanufacturer%;(Standard disk drives)

    Service        : disk                          

    FriendlyName   : SanDisk Cruzer USB Device     

    First Install  : 2021-09-09 17:37:15Z     

    First Inserted : 2021-09-09 17:37:15Z     

    Last Inserted  : 2022-05-16 22:06:24Z     

    Last Removal   : 2022-05-16 22:07:08Z     

From the WPDBUSENUM key:

_??_USBSTOR#Disk&Ven_SanDisk&Prod_Cruzer&Rev_8.02#2443931D6C0226E3&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

    DeviceDesc     : Cruzer                        

    FriendlyName   : E:\                           

    First Install  : 2021-09-09 17:37:17Z     

    First Inserted : 2021-09-09 17:37:17Z     

    Last Inserted  : 2022-05-16 22:06:24Z     

    Last Removal   : 2022-05-16 22:07:08Z

The Apple devices appear beneath the USB key, based on the vendor ID:

VID_05AC&PID_129E

  b9e69c2c948d76fd3f959be89193f30a500a0d50

    DeviceDesc     : @oem119.inf,%iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device

    Mfg            : @oem119.inf,%aapl%;Apple, Inc.

    Service        : usbccgp                       

    FriendlyName   : @oem119.inf,%iPhone.AppleUSB.DeviceDesc%;Apple Mobile Device USB Composite Device

    First Install  : 2022-01-02 19:41:16Z     

    First Inserted : 2022-01-02 19:41:15Z     

    Last Inserted  : 2022-01-02 19:41:15Z     

    Last Removal   : 2022-01-02 19:55:46Z     

VID_05AC&PID_129E&MI_00

  6&3091e96e&0&0000

    DeviceDesc     : Apple iPod                    

    Mfg            : Apple Inc.                    

    Service        : WUDFWpdMtp                    

    FriendlyName   : Apple iPod                    

    First Install  : 2022-01-02 19:41:21Z     

    First Inserted : 2022-01-02 19:41:21Z     

    Last Inserted  : 2022-01-02 19:41:21Z     

    Last Removal   : 2022-01-02 19:55:46Z     

VID_05AC&PID_129E&MI_01

  6&3091e96e&0&0001

    DeviceDesc     : @oem119.inf,%iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device

    Mfg            : @oem119.inf,%aapl%;Apple, Inc.

    Service        : WINUSB                        

    FriendlyName   : @oem119.inf,%iPhone.AppleUsbMux.DeviceDesc%;Apple Mobile Device USB Device

    First Install  : 2022-01-02 19:41:16Z     

    First Inserted : 2022-01-02 19:41:16Z     

    Last Inserted  : 2022-01-02 19:41:16Z     

    Last Removal   : 2022-01-02 19:55:46Z     

VID_05AC&PID_12A8

  00008030000E6C6C11DA802E

    DeviceDesc     : @oem119.inf,%iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device

    Mfg            : @oem119.inf,%aapl%;Apple, Inc.

    Service        : usbccgp                       

    FriendlyName   : @oem119.inf,%iPhone.AppleUSB.DeviceDesc%;Apple Mobile Device USB Composite Device

    First Install  : 2022-01-02 19:56:40Z     

    First Inserted : 2022-01-02 19:56:40Z     

    Last Inserted  : 2022-05-07 14:14:56Z     

    Last Removal   : 2022-05-07 14:16:35Z     

VID_05AC&PID_12A8&MI_00

  6&139bb8e1&1&0000

    DeviceDesc     : Apple iPhone                  

    Mfg            : Apple Inc.                    

    Service        : WUDFWpdMtp                    

    FriendlyName   : Apple iPhone                  

    First Install  : 2022-01-02 19:56:46Z     

    First Inserted : 2022-01-02 19:56:46Z     

    Last Inserted  : 2022-05-07 14:14:56Z     

    Last Removal   : 2022-05-07 14:16:35Z     

Additional Resources

Note that per Yogesh's blog post, the "Microsoft-Windows-Kernel-PnP/Device Configuration" Event Log may also contain information about the connected devices.

One More Thing

While I was doing some research for this blog post, I ran across this entry for event ID 112, albeit from the Microsoft-Window-TaskScheduler/Operational" Event Log. Once again, please stop referring to event records solely by their ID, and start including the event source, as well.  

Registry Analysis

Something I've observed over the years is that analysis of the Windows Registry is still a largely misunderstood, misinterpreted, and under-appreciated aspect of analysis of Windows systems.

What is "Registry analysis"?  Registry analysis is the observation and interpretation of data or metadata from the Windows Registry, in the context of other data/metadata, also from the Registry or other sources.  The correct interpretation of this data can add an unprecedented level of granularity to the context surrounding various events observed during, for example, timeline analysis.

"Registry analysis" is not the parsing and display of individual artifacts from within the Registry; that's "parsing and display".  It's also not keyword searching of the Registry; that's "keyword searching".  Keyword searches or searches for indicators do not constitute "analysis". I do understand, however, that not all cases require Registry analysis.  There are more than a few types of cases out there where keyword searching is all that is necessary, and I get it.  Through engaging with other analysts and following up on conversations, I've seen where keyword searches have more than sufficed for a number of types of cases.  But that's not the "analysis" we're talking about here.

That is not to say that keyword or indicator searches cannot be used as pivot points into more fully-fledged analysis.  Very often, these searches can be an excellent entry point into analysis, allowing the investigator to winnow through vast amounts of data to determine what is initially important. 

Analysis techniques where I have been able to incorporate data and metadata from the Windows Registry into an overall analysis process, have allowed me to get a better understanding of inherent activity derived or extracted from a system.  This has occurred to the point, in some cases, of changing the direction of my investigation.  Further, I'll be the first to admit that I haven't seen everything there is to see; in fact, within just the past weeks, I've observed activity that I had never seen before, and was able to develop an understanding of what activity led to the observed artifacts.  This is not something for which keyword searching would have sufficed, and was only achieved by bringing together multiple data sources in a manner that allowed me to discern context.

Why is this important?  Well, for one, Windows keeps changing.  Yes, yes, I know, we've heard this before...Windows Vista was a big leap forward (with respect to DFIR artifacts) over XP/2003, and Windows 7 a similar "leap".  There were some pretty interesting changes in the short-lived Windows 8/8.1 world, but we've arguably seen a (dare I say, "significant"?) spike in changes just between versions of Windows 10 since that version has been out.  The point is that you can't often go for a week or two before something new with respect to the Windows operating system (and specifically the Registry) is discovered or observed.  An analysis process accounts for these changes occurring.  For example, one of the approaches I use to winnow down data is to create mini-timelines and overlays; in short, using very specific data sources to create a mini-timeline in order to get a view of the data without all the inherent "noise" of the operating system.  I'll create a timeline from a user's Registry hives, incorporating not just time-based data extracted from the hives (i.e., shellbags, UserAssist data, etc.), but also the overall metadata from those hives.  This way, I can 'see' a user's activities over time, without having to wade through massive amounts of "noise", such as Windows Updates.  And, I'll not only be able to develop context, but I'll also see new things, as well.

Speaking of which, let's take a look at the great work Jason Hale has done, as an example. Some of the things we've (I use the universal "we") seen over the years have been Registry key LastWrite times associated with USB devices being universally 'stomped' by updates, as well as Registry hive "backups" no longer being written (by default) to the RegBack folder.

Jason recently pointed out that key LastWrite times associated with MRUs within the shellbags artifacts have been 'stomped' by an update, similar to what was observed with USBStor keys.  What impact would this have had on your analysis had this happened 6 months, or 2 years ago?  How would this have impacted your findings in a case?

Why is understanding the use and function of the Registry important when it comes to analyzing Windows systems?

Two important aspects of the Windows Registry that I've discussed during many of my speaking engagements have been:

The Windows Registry contains a great deal of configuration information about the system that, if correctly understood and correctly interpreted, can have a significant impact on your analysis.

The Registry contains a lot of configuration settings for the operating system, many set by default, right "out of the box".  There are others that can be changed along the way that have an impact on what users of the systems can see and do, as well as what attackers can do.  For example, there's a setting that tells the Windows operating system to store credentials in memory, in plain text.  Attackers can set this value to "1", wait a week, and come back and dump the credentials from memory, and not have to spend time cracking the passwords.  There are settings that tell the Windows shell to not show all user accounts on the Welcome screen, as well as settings that control the functionality of Terminal Services, etc.  There are even settings within the Registry that control what users can and cannot access, and how their account functions (i.e., deleted files bypass the Recycle Bin, etc.).  Understanding these settings, as well as knowing how to determine when (or if) they changed, can have a significant impact on an investigation.

There are also a number of "autostart" locations within the Registry, keys or values that tell the operating system to start applications with no other interaction from the user beyond booting the system, or logging in. Consider this Threat Research blog post regarding newly-discovered malware, for example.  Not only does it include what is reportedly a new persistence mechanism, but it also includes a figure illustrating how code used by the malware is encoded and placed in the Registry for later use.  Knowing this, encountering an infected system and incorporating this into our analysis will allow us to discover new information about how the malware operated or was used.

As a side-note, does anyone have an NTUSER.DAT file from a user profile infected with the malware identified in the Juniper Threat Research blog post?  I'm curious if the binaryImage32_* values are detected by the RegRipper sizes.pl plugin.  Thanks in advance to anyone who can check, or share such a hive file.

The Windows Registry records and maintains a great deal of user activity that, if correctly understood and interpreted, can illustrate "humanness"; that is, provide strong indications of specific, purposeful human activity, as opposed to the automatic effects of the operating system, or of malware.  

There are a number of user actions...opening or saving files, launching applications, etc...that are recorded within the Windows Registry, as part of tracking user activity in order to improve the "user experience".  The idea is to make Windows more "user friendly", in part by making the more frequently used functionality more easily accessible to the user.  The key here is that actions specifically taken by the user can be interpreted as "humanness", as the data recorded is the direct result of a person interacting with the Windows shell, applications, etc.  This can provide information to inform an investigation, particularly when knowing when someone was sitting at the keyboard is important, or when discerning whether a user or some automated function accessed data is a critical aspect of an investigation.

Thankz/Shout-Outz
Thankz and shout-outz are due to a number of folks within the #DFIR community who've contributed to the topic through research, creating tools, etc.  In no specific order:

Mari DeGrazia
Maxim Suhanov
Jason Hale
Eric Zimmerman
farmerK

I apologize profusely for any names I may have missed, as it was not intentional.

Stuff

Plugin Updates

Eric Zimmerman reached to me a little while ago and let me know that he'd taken a look at the AppCompatCache data from a Windows 10 system, and found that...wait for it...the format of the data was different from previous versions of Windows.  O.  M.  G.

Thanks to the heads up from Eric, I've updated the RegRipper plugins for parsing this data.  However, my testing was extremely limited; I had only one System hive file (from a Windows 10 TP VM that I'd set up) on which to test the parsing code.  A dearth of testing data has been an issue since I started writing tools, and it seems that even TaoSecurity has recognized the need for test data.

Interestingly enough, I happened across a System hive file from a Windows 2012 system, and the updates to the parser seemed to work just fine.  Again, I said "a" hive...so testing has been extremely limited.

AppCompatCache/ShimCache
When working with the AppCompatCache or "ShimCache" data, analysts need to remember the context of the information, and in particular, the time stamps in the data. In most cases, the time stamp is the last modification time for the file in question, from the file system metadata, specifically, the $STANDARD_INFORMATION attribute. It is NOT the date and time that the application was executed.

Dumping Passwords
Speaking of the Registry, I ran across this little gem that describes how to dump passwords in plain text from Windows 8.1/2012 systems.  I'm a big proponent for finding out what things look like on systems, and it's pretty clear reading through the blog post what an analyst would look for in an acquired image, to determine if something similar to what was described in the post had occurred on the system.

However, I'll put this out there...rather than hoping to find these indicators on a system, why not make IR scoping easier on yourself through the use of process creation monitoring at the endpoints?

Malware Persistence
Here's a good blog post on malware persistence.  There's some focus on MS's AutoRuns tool, so it's likely to be familiar to a lot of folks.  What I thought was interesting is the number of times we see the Run key being the point of persistence for malware; while many will suggest that this location is 'well known', there are also those of us who see it used time and time again, even when the incident is 'detected' through external, third-party notification.  Some may think that the Run key is passe, but hey, it still works, and works well...so why not use it, right?

EVT vs EVTX
Every now and then, I still get an opportunity to analyze Windows XP and 2003 systems...most often, I tend to find myself working with Windows 7 and Windows 2008 R2 systems.  Working with older versions of Windows can sometimes necessitate the use of different tools in order to conduct analysis; specifically, when working with the Event Logs, they're in a different location, as well as in a different binary format.

When working with Windows XP and 2003 (and yes, Windows 2000) Event Logs (*.evt files), I'll use evtrpt and evtparse.  These tools were written specifically for the binary format of the *.evt files found on Windows 2000, XP, and 2003 systems, and are not intended for use against the *.evtx files found on Vista+ systems.

Evtrpt
This is a tool I wrote a while back to provide me with information about the contents of an EVT file; how many records exist, how many source/ID pairs exist, and what date range do the events cover.  What's cool about this tool is that it doesn't use the MS API...which means that it can be run on Linux, and it doesn't rely on the header information of the EVT file to tell it how many records exist.

Evrtp is a command line tool, and takes just one argument...the path to the file you're interested in parsing.  If you just type the name of the tool at the command prompt, you'll get a message that says "You must enter a filename".  That seems to be pretty straightforward, and adding the full path to the .evt file of interest is all I need to do.

So, I run the tool against an Event Log file that I've extracted from an image, and one of the things I see in the output is the date range for the event records in that file:

Fri Sep 27 17:32:26 2013 to Tue Apr 28 17:37:58 2015

Cool, it covers the time that I'm interested in.  Above the date range in the output, I get a list of event sources and IDs, as well as a count of each.  For login attempts, the tool also breaks down the login/logoff type.  For example, I see the following entry:

Security                                      538,3    18938

What this tells me is that for the source "Security", there are 18938 events with ID 538 and type 3.

I ran the tool against the other Event Log files from the system, as well.  For the Application Event Log, the date range was:

Thu Jan 10 01:52:02 2013 to Tue Apr 28 15:36:04 2015

What I found most interesting from the output of the tool was this entry:

Symantec AntiVirus                               51        2

Remember the tool I use for Windows Event Logs, wevtx.bat?  The one that uses the eventmap.txt file?  Well, in that file, Symantec AntiVirus/51 event records indicate that the product detected malware.  Understanding the context of these event source/ID pairs can be extremely valuable, and the evtrpt tool can give you an idea of what pairs are available.  For McAfee, I'd look for McLogEvent/257 pairs.

Something of interest from the output of the System Event Log was:

Application Popup                                26       11
Application Popup                                44        1

So, hopefully by now you can see how useful this tool can be for a quick look at the Event Log files.

Evtparse
This tool operates similar to the evtrpt tool, but the output allows you to see more about the Event Log records.  Typing just the name of the tool at the prompt will show you the syntax information, along with example command lines you can use to run the tool.  I use this tool to parse through the *.evt file (or files) and add the entries to a timeline of system activity.  The command line to launch this tool does not take many arguments, because most of the data that you may want to include in each timeline entry (system name, user name, etc.) is included within each event record.

Why Do I Need The Event Source and the event ID?
Something I see a great deal of within the DFIR community is that Windows Event Log records are referred to only by their ID number.  Ok, you're probably wondering...so what?  Who cares?  Well, it can be important...if someone says that they have mulitple event ID 4100 records, I would have to ask, which source?  There are a number of event IDs that have multiple different event sources, each of which can provide completely different context to the situation.

So What?
Why does any of this matter? Context is extremely important when conducting analysis, and in particular when communicating findings to other analysts, as well as to clients.  One example was mentioned earlier in this post...the time stamps in the AppCompatCache/ShimCache data is the last modification time of the file, from the file system metadata (the Mandiant white paper is only 5 pages long and is an easy read...).

Another example comes from the output of another RegRipper plugin...the LastWrite time for one of the subkeys from the USBStor key is just that...the key LastWrite time, which is analogous to a file's last modification time.  It is NOT the last time that USB device was written to.

So, when communicating findings from the Event Log (or, Windows Event Log on Vista+ systems), providing the event source AND ID can be extremely important for context.  If someone just says, "...event ID 4100...", then the very next question should be, "...which event source?"  When documenting findings in your case notes, include both the source and ID, as well as a reference, for (possible) inclusion in the eventmap.txt file.

HowTo: Correlate an Attached Device to a User

Not long after my previous post on correlating LNK files to an external device, I received a question regarding correlating a device to a particular user.  Some may look at this and think, well, that's easy...the LNK files in question are located in the user profile, so correlating the user to the device is actually pretty easy.

Okay, but what happens if there are no LNK files that point to the device?  After all, for a LNK file to be available, the user must either create it manually, or perform some action where the operating system will create it automatically, right?  Usually, this means that the user has opened a folder on the external device and double-clicked a non-executable file of some kind, such as a .txt file or a Word or PowerPoint document.  The resulting action is that the appropriate application is launched based on the file extension, and the file is opened in that application, and an LNK file is created.

So, if you're examining a system and you suspect (or can show) that a USB device had been connected to the system, then how would you go about associating the device with a particular user, in the absence of LNK files?

MountPoints2 Key
As part of your USB device discovery process, one of the places that you're going to look is in the MountedDevices key within the System hive, in order to map the devices you've found in the USBStor subkeys to the volume globablly-unique identifier (GUID).  Beneath the MountedDevices key, some of the value names will be the volume GUIDs, and their binary data will contain the device information, in Unicode format.  Parsing the data and mapping back to the value name will provide you with the volume GUID.  You can then use this information to search the subkeys beneath the MountPoints2 key in the NTUSER.DAT hive files for the volume GUID

The path to the MountPoints2 key is:
\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Volume GUID key LastWrite time
It's commonly accepted that the LastWrite time for the volume GUID subkey beneath the MountPoints2 key indicates when that device was last connected to the system.

Shellbags Artifacts
Another artifact that allows us to correlate an attached device to a user is the shellbags artifacts, which on Windows 7 systems are found in the USRCLASS.DAT hive file within the user profile.  This is how we can tie a device to a particular user.

The shellbags artifacts are simply paths to resources composed of shell items, the same types of data structures that can be found in LNK file shell item ID lists, Jump Lists, as well as other locations within the Registry.  On Vista and Windows 7 systems, the first time that the user opens an Explorer window to a folder on an attached USB device (external hard drive or thumb drive), one of the shell items in the path will represent the drive letter to which the device was mapped, followed by the folder paths.  The drive letter can be correlated to a particular USB device by mapping to the contents of the MountedDevices key values (or, for a device previously connected to the system, you may want to dig a bit into the MountedDevices key contents available in VSCs), or to the "Windows Portable Devices\Devices" subkeys in the Software hive (again, be sure to check VSCs, as well).

Historical Registry Information
If you're looking for historical information from within the Registry, be sure to check the contents of the C:\Windows\system32\config\RegBack folder for backed-up copies of the System and Software hives.

However...and this is very important...the shellbags artifacts may contain information about attached devices that are not immediately obvious via other means of analysis.  For example, USB external drives and thumb drives are usually represented on the system as a volume (i.e., F:\, G:\) or drive letter, whereas smartphones, digital cameras, and MP3 players, while storage devices, usually appear beneath in the shellbags artifacts as a different type (type == 0x2e) of shell item.  Not all of the tools available for parsing shellbags will parse these types of shell items; in fact, those that don't seem to simply skip parsing the entire path, so shellbags with type 0x2e shell items at their root are not displayed.

Further, depending upon the version of Windows and the type of device, the shell items the comprise the path the resource might be type 0x00, or a variable type.  As the name implies, the routine for parsing these types of shell items varies, and in many instances, a great deal of information can be retrieved via knowledgeable manual analysis.

Devices connected via Bluetooth
Devices can be connected to a Windows system in other ways, including via Bluetooth. What's interesting about this type of connection is that smartphones are pretty ubiquitous at this point, and once the initial connection has been made, reconnecting to the device is trivial, and the device doesn't even have to be in view. The device can be reconnected as long as it is in range, and can be on a belt, or in a backpack or purse.

In my research, I found that a lot of users will connect to their smartphone via Bluetooth and use that connection to play music via their computer.  I also found out that MS provides a file called fsquirt.exe, which is loaded on a system during installation if the system is found to have a Bluetooth radio.

Use the bthport.pl RegRipper plugin to get some information about devices connected to a Windows system via Bluetooth.

HowTo: Tie LNK Files to a Device

Based on commentary I've seen in a couple of online forums, I thought I'd resurrect the "HowTo" label from some previous blog posts, and share (for commentary, feedback and improvement) some of the analysis processes that I've used while examining images of Windows systems.  There is a good deal of information available regarding various Windows artifacts, and one of perhaps the most difficult aspects of analysis is to tie various disparate bits of information together, correlating the artifacts, and building a complete picture so that your analysis can be used to answer questions and provide solutions.

This particular topic was previously discussed in this blog (and here's another, much older post), but sometimes processes like this need to be revisited.  Before we start, however, it's important to point out that this process will work only on Windows Vista systems and above, due to the information that is required for the process to work properly.

LNK Files
A Windows shortcut/LNK file can contain volume serial number, or VSNs.  This is intended to be a unique 4-byte (DWORD) value that identifies the volume, and is changed when the volume is reformatted.  Many tools that parse LNK files will display the VSN in their output, if one exists.

Note: Prefetch files include a volume information block which also contains a VSN.  If this information is different from the local system...that is, if a user launched an application from an external storage device...you can also use this process to correlate the VSN to the particular device.  You can view the VSN for a volume on a live system by navigating to the volume via the command prompt and typing the 'vol' command.

Registry
The EMDMgmt key (within the Software hive) contains information about USB external devices connected to the system.  This information is generated and used by the ReadyBoost service, at least in part to determine the suitability of the device for use as external RAM.

The path to the key in question is:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt

This key will contain subkeys that pertain to and describe external storage media.  The subkeys that we're interested in are those that begin with "_??_USBSTOR#".  These subkey names are very similar to artifacts found in the System hive, particularly in the USBStor subkeys.  These subkey names include device serial number, as well a volume name (if one exists) and a VSN in decimal format.

An example of such a subkey name, with the VSN in bold, appears as follows:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt\_??_USBSTOR#Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15#0C90195032E36889&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}TEST_1677970716

For those subkeys that pertain to USB thumb drives, the emdmgmt.pl RegRipper plugin will parse the subkey name, and display the VSN formatted in a usable, understandable manner.  That is to say that the plugin will translate the decimal value for the VSN into a hexidecimal format, and display it in the same manner as the VSN seen in LNK and Prefetch files, as well as what is displayed by the vol command on live systems.

Again, it is important to note the EMDMgmt key exists on Vista systems and above, but not on XP systems. As such, this technique will not work for XP/2003 systems.

Now that we have these two pieces of information, we can correlate LNK files (or Prefetch files, if necessary) to a particular device, based on the VSNs.  I've used this technique a number of times, most recently in an attempt to determine a user's access to a particular device (remember, LNK files are most often associated with a user, as they are often located within the user's profile).  If you know what it is that you're attempting to determine or demonstrate...that is, the goals of your analysis...then the tools and artifacts tend to fall right into place.  When I've had to perform this type of correlation of artifacts, because of the tools I have available, this analysis is complete in just a few minutes.

As a final note, do not forget the value of historical information on the system, particularly for the Registry.  The RegBack folder should contain a backed-up copy of the Software hive, and there is additional information available in VSCs.  Corey Harrell has a number of excellent posts on his blog that demonstrate how to use simple tools and processes...batch files...to exploit the information available in VSCs.

Resources
MS-SHLLINK file format specification
Description of EMDMgmt RegRipper plugin

There are FOUR lights!

Okay, you're probably wondering what Picard and one particular episode of Star Trek TNG has to do with forensicating.  Well, to put it quite simply...everything!

I recently posted the question in a forum regarding Shellbag analysis, and asked who was actually performing it as part of their exams.  One answer I got was, "...I need to start."  When I asked this same question at the PFIC 2012 conference of a roomful of forensicators, two raised their hands...and one admitted that they hadn't done so since SANS training.

I've seen during exams where the shellbags contain artifacts of user activity that are not found anywhere else on the system.  For example, I've seen the use Windows Explorer to perform FTP transfers (my publisher used to have me do this to transfer files), where artifacts of that activity were not found anywhere else on the system.  When this information was added to a timeline, a significant portion of the exam sort of snapped into place, and became crystal clear.

Something I've seen with respect to USB devices that were connected to Windows systems is that our traditional methodologies for parsing this information out of a system are perhaps...incomplete.  I have seen systems where some devices are not so much identified as USB storage devices by Windows systems (rather, they're identified as portable devices...iPods, digital cameras, etc.), and as such, starting by examining the USBStor subkeys means that we may miss some of these devices that could be used in intellectual property theft, as well as the creation and trafficking of illicit images.  Yet, I have seen clear indications of a user's access to these devices within the shellbags artifacts, in part because of my familiarity with the actual data structures themselves.

The creation and use of these artifacts by the Windows operating system goes well beyond just the shellbags, as these artifacts are comprised of data structures known as "shell items", which can themselves be chained together into "shell item ID lists".  Rather than providing a path that consists of several ASCII strings that identify resources such as files and directories, a shell item ID list builds a path to a resource using these data structures, which some in the community have worked very hard to decipher.  What this work has demonstrated is that there is a great deal more information available than most analysts are aware.

So why is understanding shell items and shell item ID lists important? Most of the available tools for parsing shellbags, for example, simply show the analyst the path to the resource, but never identify the data structure in question...they simply provide the ASCII representation to the analyst.  These structures are used in the ComDlg32 subkey values in the NTUSER.DAT hive on Windows Vista and above systems, as well as in the IE Start Menu and Favorites artifacts within the Registry.  An interesting quote from the post:

Of importance to the forensic investigator is the fact that, in many cases, these subkeys and their respective Order values retain references to Start Menu and Favorites items after the related applications or favorites have been uninstalled or deleted.

I added the emphasis to the second half of the quote, because it's important.  Much like other artifacts that are available, references to files, folders, network resources and even applications are retained long after they've been uninstalled or deleted.  So understanding shell items are foundational to understanding larger artifacts.

But doesn't stop with the Registry...shell item ID lists are part of Windows shortcut (LNK) files, which means that they're also part of the Jump Lists found on Windows 7 and 8.

Okay, but so what, right?  Well, the SpiderLabs folks posted a very interesting use of LNK files to gather credentials during a pen test; have any forensic analysts out there seen the use of this technique before?  Perhaps more importantly, have you looked for it?  Would you know how to look for this during an exam?

Here's a really good post that goes into some detail regarding how LNK files can be manipulated with malicious intent, demonstrating how important it is to parse the shell item ID lists.

So, the point of the graphic, as well as of the post overall, is this...if you're NOT parsing shellbags as part of your exam, and if you're NOT parsing through shortcut files as part of your root cause analysis (RCA), then you're only seeing three lights.

There are, in fact, four lights.

Resources
DOSDate Time Stamps in Shell Items
ShellBag Analysis, Revisited...Some Testing

Value of Targeted Timeline Analysis in Research

I recently conducted some research into a specific event/activity on a system, and found that timeline analysis proved to be an extremely valuable technique to use in this case.  I see a good number of questions online in the various forums asking about what could lead to a particular event, and in most cases, I ask the poster if they'd considered generating a timeline.  After all, any time you're interested in an event that occurred, particularly one that occurred at a specific time, generating and analyzing a timeline is a great way to answer that question.  It's also a great way to conduct analysis as part of research.

As indicated in my previous post, I had read online that the volume GUIDs found in the value names within the MountedDevices key, as well as within a user's MountPoints2 subkey names follow the UUID v1 format discussed in RFC 4122.  As such, this GUID contains a node identifier, which is most often a MAC address from the system.  Okay, that's easy enough.  There is also a 60-bit time stamp embedded in the GUID, which tracks 100 nano-second intervals since 15 Oct 1582...and I got interested in determining to what event that time stamp referred or was associated, specifically on my Windows 7 Ultimate test system.

I purchased a SanDisk Blade thumb drive (it was on sale), as I knew that such a device had never been connected to my system.  I then recorded the time and date that I booted system, as well as when I first connected the device to the system.  After connecting the device and noting the drive letter to which it was mapped, I disconnected it, waited a couple of hours and reconnected the device.  After disconnecting it, I shut the system down.  Again, I recorded the significant times in my notes.

Several days later, I copied the setupapi.dev.log file, extracted the System, Software, and NTUSER.DAT hives via FTK Imager, and dumped the System Event Log via LogParser, using the following command:

logparser -i:evt -o:csv "Select RecordNumber,TO_UTCTIME(TimeGenerated),EventID,SourceName,Strings from System" > d:\cases\local\system.csv

Using the appropriate tools, I generated my events file in preparation for creating a timeline.  I wrote a specific script to parse the System Event Log entries into the necessary five-field format, and crafted a specific variant of the RegRipper mp2.pl plugin to parse the volume GUIDs based on the UUID v1 time stamps.  I used regtime.pl (part of my timeline tools) to parse the Registry hives into the necessary format.

Now, what I didn't do was create a supertimeline from all data sources, as it wasn't necessary to do so.  No new Prefetch files had been created during the testing process, and I hadn't created or edited files on the thumb drive, so there really was no need to collect file system metadata.  I focused solely on the System Event Log as I understand that a number of event records are created in that log file with respect to drivers and USB devices, as well as a number of system-specific records.

What I was able to determine is that the time stamp within the volume GUID refers to the boot time of the boot session during which the device was connected to the system.  For example, I booted my test system at approximately 4:29pm EDT on 4 April 2012 (as indicated by a Microsoft-Windows-Kernel-General record with event ID 12); however, I didn't plug the device into the system until 4:55pm EDT (remember, I disconnected it and then plugged it again later at 9:02pm EDT).  When I parsed the volume GUID for the time stamp and normalized it to 32-bit time format, the time was within a second of the boot time of the system.  Throughout the rest of the timeline, I saw the creation of keys beneath the Enum\USB and Enum\USBStor keys within the System hive, as well as several other keys that need to be researched further and possibly included in the USB device analysis process.  I was also able to see that there were a number of event records that pertain to the use of USB devices.

Another example where this sort of analysis can be applied is in determining artifacts corresponding to a CD or DVD being burned on a Windows 7 system.  The System Event Log will have an event record with a source name of "cdrom" and an event ID of 133, indicating that the CDROM was locked for exclusive use.  If the user burned an ISO image, you'll see an indication of the access to the ISO image beneath the user's RecentDocs key, just prior to the ID 133 event.  If the user chose to send a selection of files to the CD/DVD drive and to "burn a disk", you'll likely see an isoburn.exe Prefetch file.

Again, it's very clear that timelines are an extremely valuable technique, not only for analysis of acquired images, but also when conducting research with respect to developing context and an increased relative confidence in the data and events in which you may be interested.

Links and Updates

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.

Updates and Links

ECSAP
I had a great time speaking on timeline analysis at an event last week...it was a great opportunity to get out in front of some folks and talk about this very important and valuable analysis technique.  My impression was that most of the folks in the room hadn't really done this sort of analysis beyond perhaps entering some interpreted times and data into a spreadsheet.

One take-away for me from the conference speaking is that people like to get free stuff.  In this case, I had one DiskLabs Find Evidence keyboard key left, and as I tend to do with conferences where I speak, I also gave away copies of my books...I gave away one copy of DFwOST and one of WRF (both of which were signed).  I hope that the continuing promises of free stuff kept folks coming back into the room from breaks... 

Along those lines, something I would offer back up to conference attendees is that speakers are people just like you, and they like to get free stuff, too...in particular, feedback.  Did what they say make sense?  Was the presentation material something that you feel you can use?  A simple "yes" doesn't really constitute feedback.  Some of us (not just me) have also written books or tools, which we may refer to...and getting feedback on those is always a bonus.  But again..."cool" isn't really "feedback".

I can't speak for every presenter, but I value honest, considered feedback, even if it's negative, over a positive albeit empty statement.  If what I talked about simply isn't useful, please...let me know.  If it's too easy or too hard to understand...let me know.  I think that most folks who present would welcome some honest feedback on what they covered.

Investigation Plans
Chris posted recently on the need to develop an investigation plan prior to doing any analysis.  Chris even outlines an exercise to clarify that, and to keep it firmly planted in your mind while you conduct your analysis.  I tend to do something very similar...I copy what I'm supposed to do (the goals) from the statement of work or contract to the top of the MSWord document I use for case notes, usually right below my description of the exhibits I've received.  From there, I also write a description of my initial approach to the analysis...keyword searches I may want to run, as well as anything of note that I may have available, such as a time frame to work with (i.e., "online banking fraud was found to have begun on 20 March, so begin timeline analysis of the system prior to that date...").

Analysis plans are not set in stone...they are not rigid scripts that you need to follow lock-step, beginning to end.  We all know that no plan survives first contact...the idea of an analysis plan is to get us started and keep us focused on the end goal, what we hope to achieve and what question(s) we need to answer for our customer.  Too many times, we won't have a plan and we'll find something "interesting" and begin running ourselves down that rabbit hole, and by the time we take a breath to look around, the original goals of the exam are nowhere in sight, but we've consumed considerable time getting there.

Timelines
Having presented recently on the topic of timelines, and working on some code to more fully exploit Windows 7 Jump Lists as forensic resources, the creation and use of timelines have been on my mind a lot recently.  I prepared and delivered a 2-day, hands-on course in timelines in June, and recently (ECSAP) presented a 2-hr compressed version of the class...which really doesn't do the subject justice (next time I'll push for at least a 4 hr slot).  One of the things I've been thinking about is how useful timelines can be from both an investigative and an analytic perspective, and how a timeline can be used to answer a wide range of questions.

One example involves artifacts from the use of USB devices on Windows systems; I've seen a number of questions in forums and lists in which the original poster (OP) identifies an anomaly that is either interesting, or needs to be explained as part of the examination...something appears odd with respect to the observed artifacts.  Often the question is, "what could have caused this?", and the answer may be found by developing a timeline of system activity, and identifying surrounding events and context to the observed artifacts.

Malware
Here's a great write-up on the Malware FreakShow 3 presentation provided by two TrustWave SpiderLabs researchers at DefCon19.  The presentation addresses malware found on Windows-based point-of-sale ("POS"...take that any way you like...) devices.

Tools
Need to find Facebook artifacts?  Take a look over on the TrustedSignal blog...there's a post indicating that a Python script has been updated and is available.  You never know when you're going to need something like this...

Resources and Links
Ken's (re)view of GFIRST...what I really like about this post is the amount of his perspective that Ken encapsulates in his post, giving his views and insights of what he saw and experienced.  Too many times in the community when someone talks about an event they attended or a book they read, the review is very mechanical..."the speaker talked about..." or "the book contains eight chapters; chapter 1 covers...".  I think this is odd, in a way, because when I talk to folks about what they want to see in a presentation or book, very often when they're looking for is the author's insights...so, in a way, this sort of goes back to what I was saying in the ECSAP section of this post.

Here's an interesting post regarding not just a trick used by malware to confuse a potential victim, but the post also describes the use of MoonSol's DumpIt and the Volatility Framework.

The DFS guys posted their materials from GFIRST and OMFW...thanks to Andrew and Golden for doing that.  There are a couple of great slide decks available; if you want to see how they investigated a data exfil incident (speaking of analysis plans), take a look at their slide pack from GFIRST...it's like reading their case notes from an exam.  You'll have to excuse a misspelling or two (slide 19 mentions the setup.api log file; spelled correctly on slide 40), but for the most part, their examination of the USB history, et al, from an XP system is a very good view into an actual investigation, and well worth writing into a process or checklist.

A couple of thoughts from the presentation:
slide 38 - instead of writing a "wrapper script" to import the information into Excel, it might be easier to modify the usbstor.pl plugin (use of a "wrapper script" mentioned again in slide 79)
slide 40 - the LastWrite times of the USBStor subkeys are not used to determine the last time the devices were plugged into the system; this is further indicated by the USB Analysis Process illustrated in slide 43
slide 90 - path should read HKLM\System\CurrentControlSet\Services\lanmanserver\Shares

Speaking of OMFW, gleeda posted to her blog and included links to her, MHL, and Moyix's slides.

DFwOST
Richard Bejtlich posted his impressions (not a full-on review) of DFwOST.  Thanks for the vote of confidence on a second edition, Richard...also, I do agree with what he mentioned with respect to the images, but as with WRF, there's not a lot that the authors can do about what the publisher or printer does with images.