Registry Stuff

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.

Sticky Notes Analysis

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.

Jump List Analysis, pt II

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)

Jump List Analysis

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

Updates

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.

Links

Tools
David Kovar has written a tool, in Python, to parse the NTFS $MFT, called analyzeMFT. The tool can be downloaded from this site. I've been using Mark Menz's MFTRipper to parse this data, and having other tools to do this sort of thing available can only be a good thing.

MS article on NTFS $MFT
Lance's article on Detecting Timestamp Changing Utilities

Windows 7 XP Mode
One of the interesting aspects of Windows 7, from both a usability and a digital forensics point of view is the addition of XP Mode. In short, if you have a system whose processor supports hardware virtualization (be sure to check that out!!), you can install a Windows XP SP3 virtual machine into VPC on Windows 7, and run tools that may not run (or run quite as well) on Windows 7. This sort of thing could be very useful from an analyst's perspective...with just one platform, you can run tools that don't rely on the Windows API to parse some data sources, and at the same time, you can run other tools that do require the Windows API, and even a specific version.

So, while this can be very useful, there's the question of virtualization and how it affects what the analyst needs to look for when examining a system. Diane Barrett has discussed artifacts left when someone uses Moka5 or MojoPak in presentations, and we're all aware of other virtualization tools and platforms out there...but with XP Mode, it's built into the OS shell.

The key to all this, from a digital forensics perspective, is going to be in determining where the artifacts of interest exist.

XP Mode Resources
Tony Bradley's article
LifeHacker article

AV, Symantec and the Google Thang
Symantec posted something on the Trojan.Hydraq Incident, indicating that it is associated with the Google issue that popped up recently.

Something I find concerning about their write-up is the description of the artifacts. They mention that the Trojan is a DLL and installs as a Windows service with the name "RaS[4 random characters]". Well, that's easy enough to search for across the enterprise...look for any service name that starts with "RaS". The problem is, this isn't the whole story. If the executable file is a DLL, that would indicate that it installs "under" something else, like SvcHost. This would mean that there are other artifacts; specifically, if someone finds a service with the specified name, then they should look at the Parameters subkey for the ServiceDll value...what happens if the name of the file changes from what's listed in the write-up? How about checking the SvcHost key in the Software hive?

Symantec isn't the only one who doesn't provide a great deal of useful information to folks, either. The MMPC has a write-up on rootkits, and mentions Trojan:W32/AproposMedia...here's their write-up on that one. Googling, I find that EmsiSoft, makers of the a-squared AV product, have something a bit more substantial.

SafeBoot
Didier Stevens has posted about restoring SafeMode with a .reg file, adding a bit more to his info about a virus that deletes the SafeBoot key, tricks to restore SafeBoot, and protecting the SafeBoot key from being deleted. While not an end-all, be-all security approach, it is a good idea to take a look at this and consider making it part of your system setup. After all, where would you be if you didn't have access to a bit of safety net like SafeBoot?

Safe Mode Boot Options
Safe Mode Boot options for XP (here're the options for Windows 2000)

Interesting Request
I received an interesting request in my email this morning...someone wanted to use one of my Perl scripts in part of their courseware, and was asking if it was okay to do so. I appreciate when people do that, but I didn't recognize the script: sweep.pl. I followed the link provided in the email and downloaded the script...it's a port scanner/banner grabbing script I wrote in 1998! I wouldn't call my skillz 'l33t in any sense, even now...but back then, maybe imaginative. After all, I was doing stuff back then to see if I could, and to see if I really understood the mechanics of what was going on.

p0wnage

A little over a month ago, I purchased a Dell Inspiron 1545 from the Dell Refurbished shelf. Most of the systems I've purchased from Dell have been procured through this route, and I've been pretty happy with the systems.

Until now. Tonight, I was p0wned by MS.

See, I'd purchased the laptop to do Windows 7 forensic (and in particular Registry) research. You know, use it like a user would and then see what the system "looks like" from a forensic perspective. Do what a user would do, then do like a forensic nerd would do.

Well, it seems that the laptop I purchased is running an Intel T4200 processor. It has 410 Million transistors, but does not support hardware virtualization.

Okay, my thought was that I was going to get an almost-brand-spanking-new system...no way it wouldn't support hardware virtualization. Well, it doesn't. What this means is that this laptop doesn't support XP Mode. Wow, so much for that rather critical portion of research.

So, the lesson learned here is, don't assume that the latest and greatest box, even one birthed in the past year, is going to have the necessary functionality to support what you want to do. In fact, as far as XP Mode is concerned, if that system you've got your eye on has an Intel processor, assume that it doesn't until proven otherwise. Wonder where I got that? My favorite forensics tool, Cory Altheide, found this at the Parallels site...notice what it says at the bottom of the page about AMD microprocessors.

Addendum: It seems that while the laptop I just purchased does not have a processor that supports hardware virtualization, the Dell Latitude D820 that I purchased in 2006 DOES! All I need to do is enable it in the BIOS...

Windows 7 and the Future of Forensic Analysis

Okay, so I was in Redmond, WA, last week at some computer conferences (yes, plural) and was on-stage with Troy Larson while he waxed philosophic on forensicy stuff with respect to Windows Vista and beyond, including Windows 7. I've been noodling a lot of this over, and here's what I've come up with...

One of Troy's pet projects is Volume Shadow Copies (please, do not ask me about any of his other interests...), and I have to say, he's really one of the most knowledgeable folks I'm aware of on the subject of VSC and the needs of forensic analysts. Troy has some interesting things to say about how Volume Shadow Copies can be accessed, but one of the most interesting aspects is that one way to do this is by booting your acquired image via something like LiveView. Another means is to mount the image file as a drive letter from a like system. At that point, you can image the entire volume or dump only selected files.

Notice at no point did I say, "...insert your dongle...", or "...run this EnScript...". It turns out that Volume Shadow Copies can be enumerated and accessed via WMI, meaning that once you have an image mounted, you may be able to (haven't tried it yet) automatically process what you need.

I was doing some research into processing the new Windows Event Log format (new as of Vista and Windows 2008, that is...) for inclusion into timeline analysis, and what I've been able to find out is that if you extract the pertinent .evtx files from your acquired image, you may be able to process them via LogParser, but again...on a like system. Andreas Schuster did a great job in documenting the format, but .evtx files are a combination of binary, and binary XML...eesh! Note - you may need to consider using something like wevtxutil in your live response activities...

Okay, I'm not sayin' that commercial forensic analysis suites are no longer useful...after all, ProDiscover 6.0 allows you to access Volume Shadow Copies if you're accessing the remote system live via the servlet...which means that if you're using PD for live response, you can likely automate what you need via Perl-based ProScripts.

So where does that leave us? Folks, I'm gonna sound the ol' "the age of Nintendo forensics is over " trumpet yet again, and the dawn of the educated, knowledgeable, sofis...soffis......sophisticated responder is upon us!

One World, Under F-Response

Matt Shannon is one of those guys that comes along and has a noticeable and definite impact on the world of Incident Response. First there was Nigilant32, then there was F-Response, with which Matt and his crew were able to provide a whole new...and much needed...capability to incident responders.

In October 2008, at the SANS Forensic Summit, Matt and Aaron Walters gave an excellent presentation on Voltage (F-Response + Volatility), showing how a responder can deploy F-Response and use functionality based on Volatility to fight malware. The presentation and the implementation were awesome!

More recently, Matt's shown how F-Response can be used with Nuix and Intella (be sure to check out the videos), clearly showing how F-Response's tool-agnostic framework can be used to really leverage the capabilities of other tools. Matt and Jamie Butler of Mandiant also recently announced that Memoryze supports F-Response.

Well, Matt's gone and done it again with the F-Response Enterprise Management Console (blip.tv video...even if you don't have F-Response EE yet, you should still watch this video)! Until now, pushing out F-Response EE to one system required some work in the command prompt, but now, Matt's made it so that it takes more effort for me to play BrickBreaker on my BlackBerry than it does for me to push out F-Response EE to one, two, or a dozen systems on a network!

So that's what I did...I fired up my Window 7 Ultimate Beta VM and basically followed Matt's video. As a caveat to this, I do have some experience working with F-Response EE via the command prompt, so it may have gone a bit more smoothly for me than for a first time user...but Matt's video is the best place to start. In the video, Matt walks through the various components of the UI and how you use each piece of information.

You can scan a workgroup or domain, IP address range, or directly connect to a system. I chose to connect directly to the system itself, in order to try out that functionality. Once I got connected to the VM (this is the VM I downloaded from BitTorrent, so it appears with the TuxDistro-PC system name), I could clearly see the system in the UI.

From there, all I needed to do is walk through the FEMC interface to install F-Response on the remote system and start the service with the name I provided through the UI. Since I wanted to see the physical memory (and had selected that through the UI) on the remote system, once F-Response was up and running and I had connected to the remote system, I could see two targets. The first target listed (:1) is the physical memory from the remote system, and the second target listed (:0) is the hard drive. At this point, notice that I haven't had to open the iSCSI Initiator console at all...all of the functionality for managing the use of F-Response EE is handled through a single interface.

Pretty cool so far...at this point, this has all just been a couple of mouse clicks. So the next step is to fire up the Disk Manager on the system from which I'm running all this...the memory from the remote system appears as Disk3, and the hard drive appears as Disk4. As the memory does not consist of a recognized file system, it's going to be accessible as \\.\PhysicalDisk3, and can be accessed via FTK Imager or Memoryze, which just reinforces how F-Response is a tool-agnostic platform. The larger partition from Disk4 got mapped to my analysis system as the I:\ drive, and from there I was able to run tools of my own, like RegRipper, which allows me to perform a modicum of triage and analysis.

These will show up in the FEMC UI, you don't NEED to go to the Disk Manager to see and access them...I simply show them here for the sake of transitioning from the CLI method. The physical disks themselves are shown in the Connect tab (you may need to refresh the UI to see them, but they'll be there). Also, you can follow what's happening in the Messages tab, and even cut-n-paste all of the messages from your session and use those in your case notes as your documentation.

Matt blogged on the FEMC here.

I've got two words for you. Suh. WEET! There's no question...for what amounts to a very modest price, you (consultant, IT staffer, etc.) have the capability to get answers NOW, whether you're responding to an incident, or addressing an HR issue, or even just network or system troubleshooting. For example, the current model of incident response is when something happens, many organizations call someone; from there, it takes time set up a conference bridge, describe to someone who isn't familiar with your infrastructure what's going on, and then they have to grab their gear and get on a plane...it could be 24 (or more) hours before someone's on-site, and then they have collect data. With F-Response and the FEMC, you can now preserve the data (i.e., in the case of new malware, collect a memory dump), provide it to consultants, and start getting answers while whomever is designated to come on-site is still looking for flights!

Windows 7 Beta

It's probably kind of early to go posting about Windows 7...yes, the beta is out, but it will likely be a while before we start seeing widespread use of it. As an incident responder who deals primarily with corporations, I see a lot of XP and Windows 2003, but so far, no Vista.

So, like many, when the Windows 7 Ultimate Beta hit the streets, I started taking a look at it. As many would expect, and as Matthieu found out, things have changed in memory. Didier also found out that things changed with respect to how the UserAssist key entries are "encrypted"...rather than being ROT-13 encrypted, the value names are now Vigenere encrypted. Didier was able to determine the cipher key for his system; apparently, the same key is used across all installations!

Okay, let's hold up for just a second...why are these value names even encrypted? I mean, honestly, what's the point? Look at most of the value names, and no one knows what they mean when they aren't encrypted!

All right then...what were we talking about? Oh, yeah...so Didier did a fantastic job of figuring out what was going on with the new encryption scheme. He also figured out some of the new elements stored in the binary data. So using this information, I located some code on PerlMonks to decrypt strings using the Vigenere cipher; I then tweaked it to include handling special characters, numbers and letters that were capitalized. I added parsing of the data in the way that Didier described, and then logged into my Windows 7 Ultimate Beta VM and did some stuff (updated Defender, launched Solitaire, and opened a command prompt and ran ftp.exe). I then shut off the VM, pulled out the NTUSER.DAT and ran it through the new RegRipper plugin I'd just written, and got some really interesting stuff, a portion of which is shown below:

C:\Program Files\Windows Defender\MSASCui.exe
Last Run = 0
C:\Program Files\Internet Explorer\iexplore.exe
Last Run = Wed Jan 21 18:53:28 2009
C:\Program Files\Microsoft Games\solitaire\solitaire.exe
Last Run = Wed Jan 21 19:03:09 2009
C:\Windows\system32\cmd.exe
Last Run = Wed Jan 21 19:04:14 2009

This is just a partially-redacted (redaction much more effective than what either MS or Adobe has used in the past...) excerpt of the output, and I'll get with Didier to see about further testing and verification, but so far, so good, it seems.

One thing that hasn't changed is that F-Response works like a champ with Windows 7, as Matt found out and blogged about. Even access to physical memory works! Don't be the last on your block to get your copy of F-Response!