To disable the Customer Experience Improvement Program within Windows 7, click on the Start Menu and type “customer”.  One of the available selections should be Control Panel –> Change Customer Experience Improvement Program settings.  Once launched, select the “No” option and use the Save Changes button.

Several scheduled tasks may be present under Microsoft –> Windows –> Customer Experience Improvement Program that can be disabled.

Additional scheduled task entries can be disabled under Microsoft –> Windows –> Application Experience.

Another entry may be present under WPD.

Also verify that the Diagnostic Tracking Service is disabled.

To obtain a text file that contains a list of installed updates and hotfixes from within Windows, launch an elevated command prompt and use the following command:

wmic qfe list brief /format:texttablewsys > list.txt

In October of 2013, Microsoft released an update to the Disk Cleanup utility for Windows 7.  The KB article concerning this update can be viewed at:

http://support.microsoft.com/kb/2852386

Once installed, launch the Disk Cleanup utility as normal.  Select your default partition.

Click on the “Clean up system files” button if the user account in question does not have local administrative authority as in this example.

When the application reloads, the list of items should include a new entry named “Windows Update Cleanup.”  In this example, this entry was over 3 GB in size.

During the next reboot, the boot screen may display a notification stating that some maintenance tasks are being performed.

The Windows Filtering Platform (WFP) is a new architecture that debuted in Windows Vista and Windows Server 2008.  Microsoft added a diagnostic tool for the Windows Filtering Platform in Windows 7 and Windows Server 2008 R2.  To capture network traffic, launch an elevated command prompt and use the following command:

netsh wfp capture start 

To stop the capture, use the command:

netsh wfp capture stop

 

Within the .cab output file, two files should be present.

Within the .XML file, details of the network traffic should be present.  The example below is a ping to the IP address of 8.8.8.8.

With Windows Vista and 7, an option is available to copy output from the command line to the Clipboard by piping it into the clip command:

command | clip

Below is an example of copying the output of the tasklist command to the Clipboard.

The contents of a file can be piped into the Clipboard by reserve.

clip < filename

The example below copies the contents of the file test.txt to the Clipboard.

Windows Live Mesh is one of the available components of the Live Essentials suite that can currently be found at http://download.live.com.  Live Mesh has two main features:  to sync data between two or more computers and Skydrive, and to allow remote access.  A list of supported file types within the sync process can be found at http://explore.live.com/windows-live-mesh-sync-file-types-ui.

After the application is downloaded and installed, the initial screen will ask for a Windows Live ID.  Two checkboxes are available to remember the Windows Live ID parameter and password, and to automatically log into the service in the future.

Once logged in, the initial screen should be displayed.

If the Remote main menu option is selected, the link to allow remote connections on the computer in question should be available.

In this example, the Windows 7 computer was configured to automatically log in using a “swalker” account.  To allow remote connections, an account must have a password configured.

If another computer has Live Mesh installed and configured with the same Windows Live ID and has remote connectivity enabled, and the machine is connected to the Internet, the entry for the machine should have a green dot.

If the “Connect to this computer” link is accessed, a new dialog box should appear.

A dialog box on the remote computer should pop up asking for confirmation.

If an individual does not click on the Deny button, the current account will be logged off.  The original computer should now see a login screen for the remote machine.

To sync a folder, click on the “Sync a folder” link on the main page.  A browse dialog box should appear asking to select a folder.  In this example, the My Documents folder was selected.  A dialog box will then appear asking which devices to sync to.

Any remote computers that has Live Mesh installed and configured with the same Windows Live ID should be listed, as well as Skydrive.  The current limit with the Skydrive option is 5 GB total with each file less than 100 MB.  Between two computers, the current limits are 200 folders with each file size less than 40 GB.

The default for the sync process is to use the same folder (My Documents in this example) on the remote computer(s).  So any changes made on any client should be transferred to the others.

If you wish to check the status of the sync setup, click on the arrow to the left of the sync entry.

As stated above, the path used on the original machine is normally used on a sync partner.  To use a different destination folder or path, create a sync entry (Desktop in this example) but do not select any remote machines or Skydrive within the selection dialog box.

On the destination computer, the sync folder entry should be present for the original machine.

Click on the Sync this folder link on the remote computer.  When the browse dialog box appears, select a different folder.

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

Andrew also recently released his Registry Decoder, "an open source tool that automates the acquisition, analysis, and reporting of Microsoft Windows registry contents. The tool was initially funded by the National Institute of Justice (NIJ) and is now ready for public release." I had an opportunity to take a look at a beta version of this tool, and I can definitely see the value of having all of the listed functionality available in one application.

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

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

- To perform high granularity detection, down to the function

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

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

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

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

Another cool feature for Windows 7 systems is the built-in Sticky Notes application, which allows the user to create little reminders for themselves on the desktop, just like with regular Sticky Notes IRL.  Having written a Jump List parser and knowing (thanks to Troy Larson) that Sticky Notes also follow the MS compound document binary format, I decided to take a look at writing a parser for Sticky Notes.  One of the interesting aspects of the OLE format is the amount of metadata (particularly time stamps) that are simply a "feature" of the format.

When a user creates sticky notes, they appear on the desktop like...well...sticky notes.  Users can change fonts and colors for their notes, but for the most part, the available functionality is pretty limited.  Now, all of the sticky notes end up in a single file, found within the user's profile (path is "%UserProfile%\AppData\Roaming\Microsoft\Sticky Notes"), named StickyNotes.snt.

So what is the potential forensic value of sticky notes?  Well, it kind of depends on your case, what you're looking for, what you're trying to show, etc.  For example, it's possible that a user may have sticky notes that contain information regarding people they know (contacts), appointments or meetings that they may have, etc.  As far as visible content, we may not really get an idea of what's there until we start to see them used by the user.  Based on the format used, there is additional information available.  Remember that all sticky notes appear in one file, so the file system MACB times apply to the file as a whole.  However, each individual sticky note is held in an OLE storage stream, which has creation and modification dates associated with it.  Opening the Sticky Notes file in MiTeC's Structured Storage Viewer, you can see that the file has several streams; Version, Metafile, as well as the storage streams (i.e., folders with 17 character names) that each "contain" streams named 0, 1, and 3.  In each case, the "0" stream contains the complete RTF "document" for the sticky note (which can be extracted and opened in WordPad), and the "3" stream contains the text of the sticky note, in Unicode format.

Now, because the storage streams for each sticky note have creation and modification dates, we can use this information in timeline analysis to demonstrate user activity during specific time frames.  Extracting the "B" (creation) and "M" (modification) times, we can add this information to a timeline in order to demonstrate shell-based access to the system by a specific user.

Again, the usefulness of this information is predicated on the actual use of Sticky Notes, but automating the collection of this information allows us to quickly add context to a timeline with minimal effort.  That's where programming (Perl) comes into play.  I don't see Sticky Notes and Jump Lists being picked up as part of Windows 7 analysis processes any time soon, as analysts really don't seem to be seeing either of these as valuable forensic resources...yet. However, having an automated, cross-platform parsing capability now allows me to do further research and analysis, as well as incorporate it into a more comprehensive analysis framework.

For example, I wondered, "what happens if the user has no Sticky Notes on their desktop?"  Well, that doesn't mean that an analyst shouldn't look for the stickynotes.snt file.  Here's what I did...I created a bunch of sticky notes with various messages on my desktop and copied the *.snt file off of my system.  Then I deleted all of the Sticky Notes, and again, copied the *.snt file.  This second file only contained the Metafile and Version streams, but the Metafile stream still contained the names of all of the previously created sticky notes (see the above graphic); however, as of yet, this stream doesn't appear to contain any recognizable time stamps .  The good news is that the modification time of the Root Entry reflected when the last sticky note was deleted. Like I mentioned earlier in this post, understanding the underlying format of a storage container allows an analyst to exploit available information wherever they may find it.

I recently posted regarding Jump List Analysis, and also updated the ForensicsWiki page that Jesse K created.  Mark McKinnon has added a great list of AppIDs to the ForensicsWiki, as well.  So why am I talking about Jump Lists again?  Over two and a half years ago, I said the following in this blog:

...from a forensic perspective, this "Jump List" thing is just going to be a gold mine for an analyst...

The more I look into Jump Lists, the more convinced I am of that statement.  However, there's still a great deal that needs to be addressed regarding Jump Lists; for example, none of the tools available at this point parse the DestList streams in the automaticDestinations files (I wrote a Perl script that does this).  Also, the available tools that do parse Jump Lists, including ProDiscover, do so in a format decided upon by the developer, not by analysts.  I've heard from several folks who have stated that the process that they have to go through to find relevant information in the Jump List files is very manual and very cumbersome, and we all know how repetitive processes like this can be prone to errors.  Even though I've developed code that quickly parses either a single Jump List file (or a whole directory full of them), I haven't yet settled on an output format (beyond TLN and CSV) and how to display or present relevant information derived from the Jump List files.  That brings to this to mind...there's the issue of what is relevant to the analyst...what I want to see as part of my analysis isn't necessarily the same thing someone else would want to see.

AppIDs
Another issue is the application identifiers for the Jump List files.  Thanks to Mark McKinnon, a nice list of AppIDs is publicly available, but I'm sure that anyone looking at it will recognize that it's far from complete.  This is going to be a community effort to keep building the list.

This page at the WindowsTeamBlog site discusses how AppIDs are created, and strongly suggests that they're very similar to the manner in which Prefetch file hashes are created.  For example, the hash that is part of a Prefetch file name is created using the path and command line for the application; it appears from this page that a similar approach is used for AppIDs, indicating that the AppIDs can vary based on the file location and the command line used.

This page at MS talks about AppUserModelIDs; this page doesn't explicitly discuss Jump Lists, but does reference exclusion lists for Taskbar pinning and recent/frequent lists.  The page also discusses Registry keys to use for exclusion lists, as well as provides a list of applications (including rundll32.exe and mmc.exe) that are excluded from the MFU list.  What this indicates is that the automaticDestination Jump Lists are, in fact, MRU/MFU lists.

With respect to the exclusion lists discussed at the MS site, the page mentions a "Registry entry" as one means of preventing inclusion in the Start Menu MFU list, but not what kind of entry; i.e., key or value.  Reading on, there is mention that the type of the entry can be "Reg_None" and that the data is ignored, indicating that the "entry" is a value.

These pages do provide some insight as to how Jump List analysis needs to incorporate more than just looking at the files themselves; we have to include the Registry, as well.  For example, let's say that there are indications of an application on a Windows 7 system, but no Jump List files; do we just assume that the application was never used by the user in question if there are no Jump List files in their profile?  I would suggest that, based on the pages linked to above, conclusions regarding usage and attribution could not be drawn without including Registry analysis.


Now, I'm a bit skeptical about all of this, as when parsing Jump Lists created by the Remote Desktop Client, the numbered streams include a command line entry within the LNK stream (i.e., /v:"192.168.1.2").  However, all of the streams are contained in the same file rather than separate files.

What this means is that there's more we need to know about Jump Lists...

Analysis
So, how would you use Jump Lists and the information they contain during an examination?  Well, whenever there is some question of the user's activities on the system, would be my number one thought.  I would think that attempting to determine if a user had used an application (or had not...remember, forensic analysis can be used to exonerate someone, as well) would be the primary use of Jump List analysis.  There are secondary uses, for example, such as determining when the user was active on the system, or when the system itself was active (i.e., booted and running).

I would also include parsing Jump Lists and sorting the LNK streams based on the DestList stream time stamps in a timeline; again, this might be of particular value when there was some question regarding the user's activities.

Also, limited testing has demonstrated Jump Lists persist on a system even after the application with which they are associated have been deleted and removed from the system.  I found this to be the case with iTunes 10, and others have observed similar behavior.  This behavior can prove to be invaluable during investigations, providing a significant amount of valuable information that persists long after a user has made attempts to hide their activity.

Something else to consider is this...what if the user connects a USB drive to the system, or inserts a DVD into the system, and the attached media includes files with a unique viewer application?  That viewer would not have to be installed on the system, but the user's use of the application to view the files (images, movies, etc.) would likely create a Jump List file that would persist long after the user removed the media.  This is definitely something that needs to be looked into and tested, and it also demonstrates how valuable Jump Lists could possibly be during an examination.

Carving
One of the things that many of us do during an examination is file carving.  For the most part, this is done through one of the commercial tools, or using a tool (foremost, scalpel) that looks for file headers and footers, or just the headers (and it grabs X bytes following the header).

I've taken a more targeted approach to carving.  For example, on Windows XP and 2003 systems, using blkls to extract the unallocated space from an image, I then searched for the event record magic number, and instead of grabbing X bytes from there, I followed the event record format specification and retrieved over 330 "deleted" albeit valid Event Log event records from unallocated space.  I was able to do this because I know that there's more to the record format than finding a header and grabbing X bytes following that.

I've started to take a similar look at carving Jump Lists from unallocated space, and getting anything that can be parsed is going to be a challenge.  Remember that the compound file format is referred to as a 'file system within a file', and that's exactly what it is.  The header of the file specifies the location of the directory table within the file, and for the most part, each of the streams is comprised of 64 byte sectors.  However, at a certain point, the file contains enough numbered stream entries that the DestList stream gets over 4Kb (4096 bytes) in size, and it's content is moved to 512 byte sectors.  Also, as numbered streams are added to the Jump List, the DestList stream becomes intermingled amongst the rest of the sectors in the file...one of the things I had to do in writing my code was build lookup arrays/lists, and as the file becomes larger, the DestList stream becomes more dispersed throughout the file.

Now, consider the numbered streams.  A numbered stream that is 203 bytes in length, per the directory table, will consume four 64 byte sectors, with 53 bytes left over.  A numbered stream that is 456 bytes long will consume eight 64 byte sectors...and in neither case is there any requirement for these sectors to be contiguous.  This means that they could be dispersed within the Jump List file.  Reassembling those streams is enough of an issue without having to deal with hoping that you retrieved the correct sectors from unallocated space within the image.

Based on this, something does come to mind that would make an interesting honors or university project...carving within the Jump List file itself.  Locating deleted keys and values (as well as pulling out unallocated space) within Registry hive files has proved to be a very useful analysis technique, so maybe something of value could also be retrieved by locating and extracting unallocated space within Jump List files.  This would simply be a matter of reading the directory table and determining all of the 64- and 512-byte sectors used, and then extracting those that are currently not being used.

Resources
Alex Barnett's paper on Jump List Forensics
Mark Woan's JumpLister
Troy Larson's Forensic Examination of Windows 7 Jump Lists presentation
Mike Ahrendt's blog post on Jump Lists (3 Apr 2011)

Every now and again, I see questions about Windows forensic analysis such as "what's new/different in Windows 7?"  There are a number of things that are different about Windows 7, some of which may significantly impact how analysts approach an examination involving Windows systems.  While there are some aspects of Windows systems that are just different (Windows Event Logs, Registry, etc.), there are some things that are new technologies.

One of those new technologies is Jump Lists. Windows 7 Jump Lists (see the "Jump Lists" section of this post) are a new and interesting artifact of system usage that may have some significant value during forensic analysis where user activities are of interest.  Jump Lists consist primarily of two file types...the *.automaticDestinations-ms (autodest) files, which are created by the operating system when the user performs certain actions, such as opening files, using the Remote Desktop Connection tool, etc.  The specific Jump Lists produced appear to be associated through file extension analysis...if one use double-clicks a text file on one system, it may open in Notepad, whereas on another system it may open in another editor (I like UltraEdit).  The contents of these Jump Lists appear in application context menus on the TaskBar, as well as the Start Menu.  According to Troy Larson, senior forensic dude for MS, these files follow the OLE/compound document format, with individual numbered streams following the LNK file format.  The autodest files also contain a DestList stream, which according to research performed by Jimmy Weg, appears to be an MRU list, of sorts.

There are tools available to view the contents of the autodest files.  For example, you can use MiTeC's SSViewer to open the files and see the various streams.  From here, you would then need to save the numbered streams and use an LNK file viewer to see the contents of the streams.  There's also Mark Woan's JumpLister, which allows you to view the contents of the numbered streams right there in the tool, automatically parsing the LNK formats.  Chris Brown also added this capability to ProDiscover, including a Jump List Viewer in the tool that parses the contents of the numbered streams.

There are also custom Jump Lists, *.customDestinations-ms (customdest) files, which are created when a user "pins" a file to an application, such as via the TaskBar.  Per Troy, these files appear to consist of stacked segments (not in an OLE container) that are LNK file formats.

Both types of files start with a series of hex characters that are the application identifier, or AppID.  This is an identifier that refers to the specific application that the user was using.  While I've found some short lists of references to AppIDs, I haven't yet found a comprehensive list.  Most of what I have found refers to "fixing" Jump Lists by deleting the appropriate files and starting over.

Addendum: Mark McKinnon recently updated the ForensicsWiki page for Jump List IDs.

In an effort to develop a better understanding of the autodest files, I began digging into the Jump List file structure, and wrote some Perl code that parses the *.automaticDestinations-ms (autodest) Jump List files on a binary level.  This parsing capability consists of two Perl modules; the first parses the autodest Jump List files (maintained in MS OLE/Compound File format) and the DestList stream within those files.  The second module parses the numbered streams, which are maintained in the Windows shortcut/LNK file format.  By combining these two modules, I'm able to parse the autodest Jump List files, correlate the DestList stream entries to the numbered streams, and present the available information in any format (TLN, CSV, XML, etc.) I choose.

So far, this is the only tool that I'm aware of that parses the DestList streams.  I had done some research into the format, and it appears that I was able to figure out at least part of the structure of these streams.  I've also found that various applications maintain different information within the contents of the streams...some maintain file names, other maintain string identifiers that appear to be used similar to a GUID.  One thing of interest, and perhaps significant value to an analyst, is that there's a FILETIME object embedded within each structure, and based on Jimmy Weg's research and input, this appears to be an MRU time.  Each individual structure within the DestList stream has a number that is associated with a numbered stream, so the information can easily be correlated to develop a complete picture of what the Jump List contains.

Here's an interesting example of how the information in Jump Lists can be useful; when a user uses the Remote Desktop Connection tool, the "1bc392b8e104a00e.automaticDestinations-ms" Jump List file is created.  The DestList stream of the Jump List file contains the "MRU Time" for each connection, as well as an identifier string.  However, we can correlate each DestList entry to the corresponding numbered stream within the Jump List file, which is itself maintained in the Windows shortcut/LNK file format; as such, we can extract information such as the basename and command line (if it exists) of the shortcut.  If we combine the two, this would appears as:

C:\Windows\System32\mstsc.exe /v:"10.1.1.23"

The information that is available depends upon how the connection was made; for example, rather than an IP address, the command line element of the LNK stream may contain a system name.  However, what we do have is an action associated with a specific user, that occurred at a specific time.  As this is a Windows 7 system, we may also be able to find additional, historic MRU data in Jump Lists accessed via Volume Shadow Copies.

The code is Perl-based and doesn't use any proprietary or platform-specific modules; while it does make heavy use of seek(), read(), substr(), and unpack(), all of these functions are available in all versions of Perl.  Ideally, this code should run on Windows, Linux, and Mac systems equally well (I don't have a Mac to use for testing).

I opted to create Perl modules for this capability because it is a much more flexible method that allows me to incorporate it into other tools.  For example, I can incorporate the modules into a Perl script (which I have done) that will parse through either individual autodest Jump List files or all such files found in a directory, and list the information they contain in any manner that I choose.  Or, I can write a ProDiscover ProScript.  Or, I can (will) include this in my forensic scanner.  Or, to paraphrase Beyonce, "If you like then you better put a GUI on it!"

Output formats are also a matter of personal choice now.  I'm focusing on TLN and CSV formats for the time being, but there's nothing that restricts me to these formats; XML is a possibility (I simply don't have a style sheet format in mind, so I may not pursue this output format).

Issues
Jump Lists are fairly new...although Windows 7 has been out for a while now, I haven't seen a great deal of discussion or questions in public forums or lists looking for more information about these artifacts.  However, some issues have already come up.  For example, I was contacted recently by someone who indicated that one of available tools for parsing Jump Lists "didn't work".  Initial correspondence indicated that at least one Jump List may have been recovered from unallocated space, but it turned out that the three "problem" Jump Lists were from a live acquisition image, and the applications in question could have been open on the desktop during the acquisition.

This presents an interesting and valid issue...how do you deal with Jump Lists from live acquisition images, where the apps were open during the acquisition (live acquisition may be required for a number of reasons, such as whole disk encryption, etc.)?  Or, what about Jump Lists carved from unallocated space?

The answer is that you need to understand the binary format of the Jump Lists (or know someone who is), because that's really the only way to resolve these issues.  When a tool "doesn't work", you need to either have the understanding of the formats to troubleshoot the issue yourself, or go to the tool author for assistance, or go to another resource for that assistance.  If you're squeamish about sharing information about the issue, or the "problem" Jump List file, even with confidentiality agreements in place, then you're really limiting yourself, and by extension, your analysis.  However, this applies to every facet of an examination (Registry, Event Log, USB device analysis, etc.), not just Jump Lists.  So, the answer is to develop the capability internally, or develop trusted resources that you can reach to for assistance.

Summary
From an analyst's perspective, Jump Lists are a new technology and artifact that need to be better understood.  However, at this point, we have considerable information that clearly indicates that these artifacts have value and should be parsed, and the embedded information included in timelines for analysis.  In many ways, Jump Lists contain analytic attributes similar to the Registry and also to Prefetch files, and are tied to specific user actions.  Further research is required, but it appears at this point that Jump Lists also represent a persistent artifact that remains after files and applications are deleted.  In one test, I installed iTunes 10 on my system, and listened to two CyberSpeak podcasts via iTunes.  The Jump Lists persisted even after I removed the application from my system.

Resources
Code Project: Jump Lists
AppID list 1
ForensicsWiki Jump Lists page

Windows 7 includes an option to change the default printer depending on what network location is used.  To configure this feature, access the Devices and Printers dialog box.  Select one printer to display additional menu selections.  Then click on the “Manage default printers” menu option.

A new dialog box should appear with drop-down boxes for both network locations and printers.

One location entry is “no network”, which could be used for a XPS or PDF print queue when no network connectivity is available.

Internet Explorer 9 includes a new security feature named ActiveX Filtering.  This component allows global or selective blocking of ActiveX controls.

This option is off by default.  To enable it, click on the Tools icon, Safety, and then ActiveX Filtering.  No configuration text or dialog box will be displayed.  Access the same path and verify that a check mark is present to the left of the menu option.

If a site is accessed that has an ActiveX control that was blocked, the icon that resembles a blue circle with a line through it within the address bar will display the the text of “Some content is filtered on this site” when the cursor is placed on it.

Some web sites will display warnings that the control is question is not available for use.

If you click on the icon that resembles a blue circle with a line through it, a small dialog box will appear which will allow access on the site in question.

The text within the dialog box can be misleading in clicking the button does not turn off ActiveX Filtering globally, but only for the current web site.  If the site is added, the normal notification at the bottom of the screen should appear.

To view the list of sites that have been allowed, click on the Tools icon and then Manage Add-ons.  Right-click on the entry under the Toolbars and Extensions area and click on the More Information option.

The dialog box should display a list of sites that have been added as an exception.  A button is also available to enable the control in question across all sites.  For example, ActiveX Filtering could be enabled but Flash could be allowed for all sites.

CyberSpeak, 8 Nov
Be sure to check out the CyberSpeak 8 Nov podcast, with an interview of Kristinn, creator of Log2Timeline. There's some Lubie, some iPhone stuff, and lots of Ovie! Good stuff, Ovie, thanks for putting these podcasts together and entertaining us all.

Windows 7 & USB Devices
A member of the Win4n6 group recently posted that there seems to be yet another place that Windows 7 tracks USB removable storage devices. The key path is:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt

This key appears to have to do with ReadyBoost, and applies to Vista, as well as Windows 7, systems. The key names for each of the devices listed contains information similar to what's in the DeviceClasses key, including the serial number (bold in the below example) for the device, as illustrated below:

\_??_USBSTOR#Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15#0C90195032E36889&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}GEEKSQUAD_1414378827

The values beneath each key include things such as the physical size of the device, as well the date that it was last tested (presumably by ReadyBoost for use as a RAM cache). I have a Windows 7 system for testing, as well as set of hive files from a Vista system, and I see entries for devices that include thumb drives and even an iPod, but not for a digital camera that had been connected to the system.

This might be a very good resource, as I've seen where some folks have asked for the physical size information of a USB device. It would be interesting to see if external HDD enclosures appear in this key, as well, and under what conditions the key LastWrite time is updated.

Resources
CodeProject

F-Response
There's a new post over on the NewInForensics blog that talks about using F-Response, in this case when analyzing Windows Event Logs (.evtx) files. I have to say that I'm glad to see others using this tool, and running tests like this, as it tells me two things. One is that folks are deciding to pick up tools and run their own tests.

The other is that folks in the community and industry are beginning to really realize and acknowledge how useful and truly powerful a tool F-Response really is, and they're using it as such.

When it comes to Windows Event Logs (.evtx) from Vista and above systems, I like to use LogParser from MS to parse the logs into some text-based format, and then use Perl to put the entries in a TLN format for inclusion into a timeline, or for generating mini-timelines. Sometimes I get questions that are best answered by creating mini-timelines (sort of the opposite of super timelines) from just RDP login events, W32Time events, etc.

OpenSource Tools
Brian mentioned recently that there's a new site available called OpenSourceForensics. From Brian:

One of the take aways from the Sleuth Kit and Open Source Digital Forensics Conference last year was that the community needed a site where examiners could go to find tools and learn about which ones were better than others.

This is a great resource, as one of the issues I hear from folks is that tools are out there, but they're OUT there...there's no single resource or location where an examiner can go to search for or find a tool, or get input from other analysts on the usefulness of the tool. Hopefully, with input from examiners and analysts, this can become an exemplary resource...but remember, folks, it takes effort from everyone!

Add to that a big thanks and shout-out to Brian for this, as well as for the Open Source Conference last June...Brian also mentioned that there will be another one next June!

Note
I presented at the PFIC2010 conference recently, and while I was there, someone came up and told me that they had all of my books. I was going to say something witty, and ask which one they liked best or opened the most, only to have them start off by saying, "...File System Forensic Analysis..."...uh...that's Brian, not me. Brian has hair, and is much smarter than I.

SecTor.ca
Speaking of conferences, SecTor videos are available. I watched Greg Hoglund's keynote presentation, and correlated to what I heard there about the APT and focused attacks to what I saw in Dave Nardoni's presentation at PFIC2010.

During the keynote, Greg pimped Windows Forensic Analysis 2/e during his presentation...very cool, Greg, thanks!

Greg went on to say that the perimeter is disappearing through the use of mobile devices, and that host systems are becoming more important than ever. Early in his keynote, he talked about threat intelligence achieved through host-based analysis, and how many folks have a simple, flash-and-go response policy...wipe the drive of a potentially infected system, re-install, and move on. I think that one of the scariest things...well, should be one of the scariest things...is that Greg pointed out that there's an economy behind gaining access to host systems. That's right...people are paying money to gain access to your systems!

Finally, during his presentation, Greg mentioned a couple of times how MD5 hashes are just short of useless for analysis of well-thought-out intrusions. I know someone who'd be upset about that, if they bothered to watch videos like this.

Windows 7 is supposed to automatically detect a SSD hard drive and enable the TRIM function by default.  To verify this setting, launch a command prompt with local administrative authority and type:

fsutil behavior query DisableDeleteNotify

Two results are possible:

0 –> This indicates that TRIM is enabled and working.

1 –>  This means that TRIM is not enabled.

If you attempt to modify the default libraries within Windows 7 and wish to go back to the initial default values, open Windows Explorer.  Right-click on the Libraries icon and select “Restore default libraries.”  This will not affect any custom library entries that may have been created.

A shell shortcut (nicknamed the “God Mode”) was discovered to work with Windows 7.  It is simply a list of every single Control Panel feature.  To enable this view, right-click on the Desktop and select New –> Folder.  Copy and paste the following text as the name:

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

After hitting the return key, the icon of the folder should change.

If the shortcut is accessed, a list of all Control Panel features should be present.

To quickly access the Advanced System Properties dialog box within Windows 7, type systempropertiesadvanced (with no spaces) with the Search dialog box under the Start Menu.

Within Windows 7, the Add Hardware Wizard is no longer available via the Control Panel.  To launch the wizard, use the text of hdwwiz.exe within the search dialog box within the Start Menu.