When I first thought of what became the Forensic Scanner (free version available here), my goal was to provide a solution for getting analysts to the point of analyzing images acquired from systems sooner; that is, to optimize an analyst's time when it comes to dead-box analysis. Taking a page from Deming's book, my approach was to take a look at what could be optimized, and I figured that getting analysts to the point of actually doing analysis faster, by automating those tasks that we tend to do over and over again would be a great way to speed things up a bit.
The Forensic Scanner was designed to be used by mounting an acquired image on your analysis system as an accessible volume. You can mount acquired images using FTK Imager, ImDisk, ProDiscover, or even converting the image to a VHD using vhdtool.
One of the things that's come up since I started talking about the Forensic Scanner is the question of whether this tool can be used in the triage of live systems. Now, the Scanner was not designed for this purpose, particularly because some of the Perl modules used do not work against the Registry on a live system - a different API is required. However, as it turns out, with the right tools, you can, in fact, use the Forensic Scanner to triage remote live systems. For example, if you have F-Response, you can use the Forensic Scanner to retrieve information from remote live systems. I've also heard from one person recently that they were able to use the Forensic Scanner via EnCase PDE. I don't have any specifics about how they did this, and I am unable to test this myself.
If you don't have access to either of these tools, but still want to use the Forensic Scanner in an infrastructure, take a look at Andrew Hay's post regarding the NBDServer application. His methodology is a bit involved, but from the perspective of trying to perform remote incident response on a shoe-string budget, the only "costs" involved are two systems (or a VM or two...) and a bit of a learning curve.
Monday, April 29, 2013
RegRipper Updates
I've made some updates to RegRipper that I wanted to let everyone know about, in case you want to take advantage of them.
Version 2.8 is a minor update, and includes an additional function/subroutine that is available to the plugins: alertMsg(). In short, the tools (RegRipper, rip) provide the functionality, which is then used by the plugins themselves. The updates to the tools simply provide the functionality; several of the plugins have been updated to make use of that functionality. If you'd like to use this functionality, then you want to download the files rrv2.8.zip and plugins20130429.zip.
How is this alertMsg() function useful? Well, consider Corey's recent post regarding the soft_run.pl and user_run.pl plugins; in the post, he illustrates several values of interest, that point (in his case) to malware.
As such, I added two checks to both of the plugins; one checks for "Temp" or "temp" in the path found in the value data (this would catch "Local Settings\Temp", "Temporary Internet Files", and "Templates"), and the other checks to see if the path in the value data ends in ".com" or ".bat".
Other updated plugins include (but are not limited to):
So a big question is going to be, where do the alerts come from? The answer is pretty simple...they come from stuff I, and others (specifically, Corey Harrell), have seen. For example, one of the checks that occurs in the soft_run.pl and user_run.pl plugins is that every value data (i.e., path) is checked to see if it contains "[Tt]emp"; an alert will be generated if it contains "Templates", "Local Settings\Temp", or "Temporary Internet Files", for example. This is important because (a) I've seen applications set to run from those paths, and (b) you generally don't want that sort of thing to happen, particularly from "Temporary Internet Files".
Now, there are two things to keep in mind...the first is that not all plugins will necessarily generate alerts. Some plugins, such as networklist.pl, do not necessarily provide information that should be alerted on. The output of this plugin is mostly for informational purposes, and you should check it if you're looking for something specific. Other plugins do provide information that can be alerted on; for example, in winlogon.pl, one alert will be generated if the TaskMan value is found, and another will be generated if the Userinit value is found to have more than simply what is expected. Someplace that this might be useful...look for alerts from the winlogon.pl plugin, which would detect Ramnit.
The second is that of the plugins that do generate alerts, they will only generate those alerts that are included in (i.e., coded into) the plugins. You can see what is generating an alert by locating any instance of ::alertMsg() in the plugin, and taking a look at the code around it. If a plugin isn't alerting on something that you want, it may be because that alert hasn't shared that with someone...so just send me an email and I'll see what I can do (note: I may need sample data in order to test it).
Several of the plugins that were updated to include this ::alertMsg() functionality have also been converted to TLN output so that the alerts can be included in a timeline. My hope is that this will bring a considerable modicum of intelligence to timeline analysis, by including things that would be of interest directly in the timeline. In many cases, the location of the alert in the timeline may be imprecise...the time stamp value is based on the LastWrite time of the key; however, my hope is that seeing an event source of "ALERT" in the timeline (which you search on using Notepad++, etc.) will raise awareness of areas that should be checked by bringing them to the attention of the analyst.
A caveat...if you're using ripXP (is anyone using that??), then you want to use the plugins in the archive for 18 April 2013. I'll leave that archive up and available, but I will not be updating ripXP with the alertMsg() functionality, so you'll need to use the appropriate plugins. This is easy to do, simply create a separate folder for ripXP.
Version 2.8 is a minor update, and includes an additional function/subroutine that is available to the plugins: alertMsg(). In short, the tools (RegRipper, rip) provide the functionality, which is then used by the plugins themselves. The updates to the tools simply provide the functionality; several of the plugins have been updated to make use of that functionality. If you'd like to use this functionality, then you want to download the files rrv2.8.zip and plugins20130429.zip.
How is this alertMsg() function useful? Well, consider Corey's recent post regarding the soft_run.pl and user_run.pl plugins; in the post, he illustrates several values of interest, that point (in his case) to malware.
As such, I added two checks to both of the plugins; one checks for "Temp" or "temp" in the path found in the value data (this would catch "Local Settings\Temp", "Temporary Internet Files", and "Templates"), and the other checks to see if the path in the value data ends in ".com" or ".bat".
Other updated plugins include (but are not limited to):
- appinitdlls - generate an alert if the value is not blank
- appcompatcache - generate an alert for any path that includes "[Tt]emp"
- attachmgr - generates alerts per Corey's blog post (ref: KB883260)
- imagefile - generate an alert if a Debugger value is found
- user_run, soft_run - alert on paths that contain "[Tt]emp"
- winlogon, winlogon_u - added several alerts
So a big question is going to be, where do the alerts come from? The answer is pretty simple...they come from stuff I, and others (specifically, Corey Harrell), have seen. For example, one of the checks that occurs in the soft_run.pl and user_run.pl plugins is that every value data (i.e., path) is checked to see if it contains "[Tt]emp"; an alert will be generated if it contains "Templates", "Local Settings\Temp", or "Temporary Internet Files", for example. This is important because (a) I've seen applications set to run from those paths, and (b) you generally don't want that sort of thing to happen, particularly from "Temporary Internet Files".
Now, there are two things to keep in mind...the first is that not all plugins will necessarily generate alerts. Some plugins, such as networklist.pl, do not necessarily provide information that should be alerted on. The output of this plugin is mostly for informational purposes, and you should check it if you're looking for something specific. Other plugins do provide information that can be alerted on; for example, in winlogon.pl, one alert will be generated if the TaskMan value is found, and another will be generated if the Userinit value is found to have more than simply what is expected. Someplace that this might be useful...look for alerts from the winlogon.pl plugin, which would detect Ramnit.
The second is that of the plugins that do generate alerts, they will only generate those alerts that are included in (i.e., coded into) the plugins. You can see what is generating an alert by locating any instance of ::alertMsg() in the plugin, and taking a look at the code around it. If a plugin isn't alerting on something that you want, it may be because that alert hasn't shared that with someone...so just send me an email and I'll see what I can do (note: I may need sample data in order to test it).
Several of the plugins that were updated to include this ::alertMsg() functionality have also been converted to TLN output so that the alerts can be included in a timeline. My hope is that this will bring a considerable modicum of intelligence to timeline analysis, by including things that would be of interest directly in the timeline. In many cases, the location of the alert in the timeline may be imprecise...the time stamp value is based on the LastWrite time of the key; however, my hope is that seeing an event source of "ALERT" in the timeline (which you search on using Notepad++, etc.) will raise awareness of areas that should be checked by bringing them to the attention of the analyst.
A caveat...if you're using ripXP (is anyone using that??), then you want to use the plugins in the archive for 18 April 2013. I'll leave that archive up and available, but I will not be updating ripXP with the alertMsg() functionality, so you'll need to use the appropriate plugins. This is easy to do, simply create a separate folder for ripXP.
Thursday, April 18, 2013
RegRipper Plugin Updates
The RegRipper plugin archive has been updated.
The archive contains a text file that lists the updates, which are also listed here. The wiki also contains a Plugins page, where descriptions of plugins (what they check, what they're intended for, how to use the data, etc.) will be maintained.
The archive contains a text file that lists the updates, which are also listed here. The wiki also contains a Plugins page, where descriptions of plugins (what they check, what they're intended for, how to use the data, etc.) will be maintained.
Monday, April 15, 2013
Plugin: Winlogon
The Winlogon plugin is a pretty comprehensive plugin, in that since the RegRipper consolidation release, several plugins have been retired and their functionality incorporated into this one plugin.
The Winlogon plugin is a valuable resource when it comes to determining autostart information for the system. For example, the UserInit and Shell values point to the shell that is launched when a user logs in. From here:
The Winlogon key controls actions that occur when you log on to a computer running Windows 7. Most of these actions are under the control of the operating system, but you can also add custom actions here. The “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit” and “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell” subkeys can automatically launch programs.
MS KB 555648 addresses an issue where either the Shell or Userinit values have been modified.
The Winlogon plugin extracts values and data from beneath the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon key, as well as it's accompanying Wow6432Node cousin on 64-bit Windows systems, and it also collects information from several subkeys, as well.
This Microsoft page provides additional information about some of the values that appear beneath this key. Another way that a value beneath this key can be used to subvert the system is to add the TaskMan value, and point to malicious software.
Notify
This subkey maintains a running list of functionality made available to Windows systems via notification packages. In short, a "package" (DLL) can receive notifications from Windows when certain events occur. When these events occur, Windows will look for the package and launch the handler for that specific event. For example, you can have specific functions run automatically when a user logs on, locks the console, when a smartcard is plugged into the system, etc.
As with other functionality on Windows system, this also provides a great mechanism for malware (see this Cutwail example) persistence.
Special Accounts
One of the subkeys that can exist beneath the Winlogon key is the "SpecialAccounts\UserList" subkey. The values beneath this key, and each value's accompanying data, determines whether or not the specific account appears on the Welcome screen. Very often, this information is used to for legitimate purposes, so that the screen isn't cluttered with accounts that are not used for logging into the system at the console. However, this functionality can be, and has been, used for malicious purposes. I've seen this in the wild, most often when an intruder has accessed an infrastructure via RDP, and creates accounts on systems that they can use to log in; hiding the user account from the Welcome screen prevents legitimate users from seeing anything suspicious when the system is rebooted. In one instance, I saw this being used, but the "SpecialAccounts" key had been misspelled, so the functionality was not enabled.
The Winlogon plugin encapsulates data from several plugins, which led me to retire those other plugins. For example, I added the checks from the taskman.pl, notify.pl, and specaccts.pl plugins to the winlogon.pl plugin, and retired those other plugins. All of this will appear in the history file associated with the next roll-out of the plugin archive. The output of the winlogon.pl plugin also includes analysis notes, so that the analyst has information right there in the report with respect to what they should look for, and what might be suspicious.
Resources
Winlogon\Nofity entries
MS KB 102972: Explains many of the Winlogon values
The Winlogon plugin is a valuable resource when it comes to determining autostart information for the system. For example, the UserInit and Shell values point to the shell that is launched when a user logs in. From here:
The Winlogon key controls actions that occur when you log on to a computer running Windows 7. Most of these actions are under the control of the operating system, but you can also add custom actions here. The “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit” and “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell” subkeys can automatically launch programs.
MS KB 555648 addresses an issue where either the Shell or Userinit values have been modified.
The Winlogon plugin extracts values and data from beneath the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon key, as well as it's accompanying Wow6432Node cousin on 64-bit Windows systems, and it also collects information from several subkeys, as well.
This Microsoft page provides additional information about some of the values that appear beneath this key. Another way that a value beneath this key can be used to subvert the system is to add the TaskMan value, and point to malicious software.
Notify
This subkey maintains a running list of functionality made available to Windows systems via notification packages. In short, a "package" (DLL) can receive notifications from Windows when certain events occur. When these events occur, Windows will look for the package and launch the handler for that specific event. For example, you can have specific functions run automatically when a user logs on, locks the console, when a smartcard is plugged into the system, etc.
As with other functionality on Windows system, this also provides a great mechanism for malware (see this Cutwail example) persistence.
Special Accounts
One of the subkeys that can exist beneath the Winlogon key is the "SpecialAccounts\UserList" subkey. The values beneath this key, and each value's accompanying data, determines whether or not the specific account appears on the Welcome screen. Very often, this information is used to for legitimate purposes, so that the screen isn't cluttered with accounts that are not used for logging into the system at the console. However, this functionality can be, and has been, used for malicious purposes. I've seen this in the wild, most often when an intruder has accessed an infrastructure via RDP, and creates accounts on systems that they can use to log in; hiding the user account from the Welcome screen prevents legitimate users from seeing anything suspicious when the system is rebooted. In one instance, I saw this being used, but the "SpecialAccounts" key had been misspelled, so the functionality was not enabled.
The Winlogon plugin encapsulates data from several plugins, which led me to retire those other plugins. For example, I added the checks from the taskman.pl, notify.pl, and specaccts.pl plugins to the winlogon.pl plugin, and retired those other plugins. All of this will appear in the history file associated with the next roll-out of the plugin archive. The output of the winlogon.pl plugin also includes analysis notes, so that the analyst has information right there in the report with respect to what they should look for, and what might be suspicious.
Resources
Winlogon\Nofity entries
MS KB 102972: Explains many of the Winlogon values
Thursday, April 11, 2013
Plugin: specaccts.pl
As is the case with many of the RegRipper plugins, the specaccts.pl plugin initially came about because of something I read about, and after running it, it actually found what I was looking for in the wild.
Beneath the Winlogon key (specifically, HKLM\Software\Microsoft\Windows\CurrentVersion\Winlogon), there may be a subkey path of "SpecialAccounts\UserList". The values listed beneath the UserList key would be user account names, and if the data associated with a value is "0", then that account will not appear on the Welcome screen (any value greater than 0 allows the account to appear on the Welcome logon screen).
I've seen this used twice in the wild...once, it worked, and the second time, the bad guy had misspelled "SpecialAccounts", and as such, the functionality that they were trying to achieve wasn't realized. Sometimes, a little attention to detail can go a long way.
There is malware that uses these Registry keys to keep new user accounts hidden from view on a live system, such as TrojanSpy:Win32/Ursnif , Trojan:Win32/Starter, and EyeStye. As such, this plugin can provide indicators of a malware infection, an intrusion, or of malicious user intent on the system. However, keep in mind, that this functionality can also be used for legitimate purposes, such as hiding an Administrator or HelpDesk account from view on the Welcome screen.
As of this writing, Corey Harrell and I are finishing updates to a number of plugins, and looking at merging plugins where appropriate. As the information that we're looking for with the specaccts.pl plugin is beneath the Winlogon key, I've rolled the functionality into the winlogon.pl plugin, and retired the specaccts.pl plugin.
So, the functionality isn't going away...rather, it's going to be incorporated into an existing plugin.
Beneath the Winlogon key (specifically, HKLM\Software\Microsoft\Windows\CurrentVersion\Winlogon), there may be a subkey path of "SpecialAccounts\UserList". The values listed beneath the UserList key would be user account names, and if the data associated with a value is "0", then that account will not appear on the Welcome screen (any value greater than 0 allows the account to appear on the Welcome logon screen).
I've seen this used twice in the wild...once, it worked, and the second time, the bad guy had misspelled "SpecialAccounts", and as such, the functionality that they were trying to achieve wasn't realized. Sometimes, a little attention to detail can go a long way.
There is malware that uses these Registry keys to keep new user accounts hidden from view on a live system, such as TrojanSpy:Win32/Ursnif , Trojan:Win32/Starter, and EyeStye. As such, this plugin can provide indicators of a malware infection, an intrusion, or of malicious user intent on the system. However, keep in mind, that this functionality can also be used for legitimate purposes, such as hiding an Administrator or HelpDesk account from view on the Welcome screen.
As of this writing, Corey Harrell and I are finishing updates to a number of plugins, and looking at merging plugins where appropriate. As the information that we're looking for with the specaccts.pl plugin is beneath the Winlogon key, I've rolled the functionality into the winlogon.pl plugin, and retired the specaccts.pl plugin.
So, the functionality isn't going away...rather, it's going to be incorporated into an existing plugin.
Monday, April 08, 2013
Plugin: *_tln
If you've downloaded the new RegRipper plugins archive, you may have noticed several plugins whose names end in "_tln.pl". These plugins specifically output their collected information in the five-field timeline (TLN) events file format that I use for creating timelines.
Many folks using the RegRipper tools may not be aware that you can use rip.exe to determine information about the plugins that you have currently have available. For example, the following command will allow you to see all the plugins that you have, listed in a tabular format:
rip -l
This next command will allow you to see all of the plugins you have, listed in CSV format:
rip -l -c
This command will let you see all of the plugins that end in "*_tln", in CSV format:
rip -l -c | find "_tln"
Now that we have a list of the plugins that provide TLN output, we can easily include the output of the plugin in our timeline events file by using the following command:
rip -r path-p plugin -u user -s server >> events.txt
An example of how this can be useful is in adding the UserAssist data for a specific user to the timeline events file...you can do that using the following command:
rip -r path-p userassist_tln -u user -s server >> events.txt
Very easy, very straightforward, and the use of these plugins can provide us with a good deal of granularity in our timeline.
Something that's very important to understand about the TLN plugins is that, in most cases, they will not display the same information as their accompanying plugin without "_tln" in the name. In many cases, the information maintained in the keys and values extracted via the plugins is stored in a "most recently used" or "MRU" format, and as such, the LastWrite time of the key is associated with the most recent entry. An example of this is the shellbags_tln.pl plugin...running this one side-by-side with the shellbags.pl plugin won't provide you with the same information, nor the same number of lines in the output. However, this is by design...shellbag data is one of those "MRU" sources within the Registry. One exception to this is the output of the userassist_tln.pl plugin; the time stamp data extracted by this plugin is stored in the binary content of the value data.
Typing the command to list the *_tln plugins will illustrate that most of the plugins appear to be oriented toward the NTUSER.DAT and Software hives. The shellbags_tln.pl plugin was written to run against the USRCLASS.DAT hive, and lists its output based on the key LastWrite time or "MRU Time"; it does not list information in TLN format based on the created, last accessed or last modified times extracted from the shell items. The samparse_tln.pl plugin will list information in TLN format based on various time stamps associated with each user account. Also, with this plugin, you don't need to add the "-u" switch, as the user information is embedded within the hive file itself.
Many folks using the RegRipper tools may not be aware that you can use rip.exe to determine information about the plugins that you have currently have available. For example, the following command will allow you to see all the plugins that you have, listed in a tabular format:
rip -l
This next command will allow you to see all of the plugins you have, listed in CSV format:
rip -l -c
This command will let you see all of the plugins that end in "*_tln", in CSV format:
rip -l -c | find "_tln"
Now that we have a list of the plugins that provide TLN output, we can easily include the output of the plugin in our timeline events file by using the following command:
rip -r path
An example of how this can be useful is in adding the UserAssist data for a specific user to the timeline events file...you can do that using the following command:
rip -r path
Very easy, very straightforward, and the use of these plugins can provide us with a good deal of granularity in our timeline.
Something that's very important to understand about the TLN plugins is that, in most cases, they will not display the same information as their accompanying plugin without "_tln" in the name. In many cases, the information maintained in the keys and values extracted via the plugins is stored in a "most recently used" or "MRU" format, and as such, the LastWrite time of the key is associated with the most recent entry. An example of this is the shellbags_tln.pl plugin...running this one side-by-side with the shellbags.pl plugin won't provide you with the same information, nor the same number of lines in the output. However, this is by design...shellbag data is one of those "MRU" sources within the Registry. One exception to this is the output of the userassist_tln.pl plugin; the time stamp data extracted by this plugin is stored in the binary content of the value data.
Typing the command to list the *_tln plugins will illustrate that most of the plugins appear to be oriented toward the NTUSER.DAT and Software hives. The shellbags_tln.pl plugin was written to run against the USRCLASS.DAT hive, and lists its output based on the key LastWrite time or "MRU Time"; it does not list information in TLN format based on the created, last accessed or last modified times extracted from the shell items. The samparse_tln.pl plugin will list information in TLN format based on various time stamps associated with each user account. Also, with this plugin, you don't need to add the "-u" switch, as the user information is embedded within the hive file itself.
Saturday, April 06, 2013
Plugin: Findexes
The findexes.pl plugin for RegRipper is a plugin that I wrote as a result of another analyst sharing his experiences on an engagement with me. The analyst told me that he'd found some unusual references to Registry keys in malware code, which led him to determine that executable code was being stored in binary value data within the Registry.
This plugin can be run against any hive file. What it does is traverse through all of the keys (so for larger hives, it can take a little bit of time to complete), looking for values with binary data. When it finds binary data, it checks to see if that data includes "MZ". Note that it does not look in a specific location, nor at offset 0...it uses a grep() statement to see if the data includes "MZ" at all.
When the plugin completes, you get a couple of pieces of information. One is the count of values with binary data, along with the count of binary data with "MZ". If there were any values found to contain "MZ", the key path, key LastWrite time, and value name are listed.
One System hive I ran the code against found 22660 binary values but none that contained "MZ". A Software hive I ran the code against found 23190 binary values, one of which contained "MZ", and I got the key path and other data for that value.
Key: Microsoft\SystemCertificates\Disallowed\Certificates\471C949A8143DB5AD5CDF1C972864A2504FA23C9 LastWrite time: Mon Mar 28 21:26:31 2011
Value: Blob Length: 1751 bytes
Number of values w/ binary data types: 23190
Number of values w/ MZ in binary data: 1
It's pretty trivial to validate the information, in general, found by this plugin. One way to do is to simply navigate to the key(s) in a viewer, and then look at the data. Another is to add code to the plugin to dump the data out in a hex editor style view.
Now this plugin doesn't indicate that what it finds is a persistence mechanism; rather, it's used for data storage, so you might consider running it across any and all hives, including USRCLASS.DAT. The process in which I tend to use this plugin is that I'll start by creating a timeline and if I see some unusual activity in the Registry during the time window during which the system seemed to be infected (i.e., Registry and file system data, *.idx metadata, etc.). Given that the LastWrite time is only indicative of a change occurring to a Registry key, I might opt to run the plugin against hives from VSCs, rather than those within the system32\config folder, instead.
Overall, this plugin can be very useful. The plugin can be added to profiles for every hive, or can be used for pivot point analysis when examining a timeline.
This plugin can be run against any hive file. What it does is traverse through all of the keys (so for larger hives, it can take a little bit of time to complete), looking for values with binary data. When it finds binary data, it checks to see if that data includes "MZ". Note that it does not look in a specific location, nor at offset 0...it uses a grep() statement to see if the data includes "MZ" at all.
When the plugin completes, you get a couple of pieces of information. One is the count of values with binary data, along with the count of binary data with "MZ". If there were any values found to contain "MZ", the key path, key LastWrite time, and value name are listed.
One System hive I ran the code against found 22660 binary values but none that contained "MZ". A Software hive I ran the code against found 23190 binary values, one of which contained "MZ", and I got the key path and other data for that value.
Key: Microsoft\SystemCertificates\Disallowed\Certificates\471C949A8143DB5AD5CDF1C972864A2504FA23C9 LastWrite time: Mon Mar 28 21:26:31 2011
Value: Blob Length: 1751 bytes
Number of values w/ binary data types: 23190
Number of values w/ MZ in binary data: 1
It's pretty trivial to validate the information, in general, found by this plugin. One way to do is to simply navigate to the key(s) in a viewer, and then look at the data. Another is to add code to the plugin to dump the data out in a hex editor style view.
Now this plugin doesn't indicate that what it finds is a persistence mechanism; rather, it's used for data storage, so you might consider running it across any and all hives, including USRCLASS.DAT. The process in which I tend to use this plugin is that I'll start by creating a timeline and if I see some unusual activity in the Registry during the time window during which the system seemed to be infected (i.e., Registry and file system data, *.idx metadata, etc.). Given that the LastWrite time is only indicative of a change occurring to a Registry key, I might opt to run the plugin against hives from VSCs, rather than those within the system32\config folder, instead.
Overall, this plugin can be very useful. The plugin can be added to profiles for every hive, or can be used for pivot point analysis when examining a timeline.
Friday, April 05, 2013
Plugin: EMDMgmt
Shortly after announcing the RegRipper consolidation, Corey hit me with a great idea...why not create a series of posts to spotlight a particular plugin, explain what it does, how it can be used, etc. I thought that this was a great idea, and told him that I would join in, so you can expect to see posts from both of us every now and again, in which we discuss a specific plugin. Once these posts start to appear, I will add them as links to a page on the RegRipper Wiki. If anyone else decides to write a similar post, please send me the link and I'll add it to the page.
The first plugin that I thought I'd take a look at is emdmgmt.pl. "EMD" apparently stands for "external memory device", which was the working name of ReadyBoost while it was being developed. When you connect a device to a Vista+ system, the ReadyBoost service checks the device to determine its characteristics and stores this information beneath the following key:
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Emdmgmt
This key gets populated with subkeys that refer not just to thumb drives connected to the system, but also external drives, sometimes referred to as "drive enclosures" (which, of course, has to have a drive in it). It appears that ReadyBoost performs some sort of "check" of the device in order to determine it's capabilities and see if it's suitable for use.
This plugin is useful for two primary reasons. First, it's a great way to verify that certain types of devices (thumb drives, external drives) had been connected to the system at one point. This can be validated against other sources of information (System hive, etc.).
The other useful aspect of information stored in this key applies specifically to thumb drives. In particular, the subkey that applies to a thumb drive contains the device class identifier, the device serial number, the volume serial number, and possibly the volume name (if the mounted volume has a name). For example,
Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15
LastWrite: Sun Jul 17 12:13:25 2011 Z
SN: 0C90195032E36889&0
Vol Name: TEST
VSN: 6403-CD1C
This is clearly a Best Buy Geek Squad U3 thumb drive that I connected to my system. That I really like about this is the volume serial number that's listed in the output. This is translated from the information maintained at the very end of the key name. I've used this information to correlate to VSNs stored in Windows shortcut/LNK streams (shortcuts in the user's Recent folder, Jump Lists), allowing me to tie the various artifacts together in order to demonstrate not only that a particular user accessed the thumb drive, but to also demonstrate what the file system on that device looked like at the time that the user accessed it. I can then further augment this information with the output of the comdlg32.pl and shellbags.pl plugins.
The first plugin that I thought I'd take a look at is emdmgmt.pl. "EMD" apparently stands for "external memory device", which was the working name of ReadyBoost while it was being developed. When you connect a device to a Vista+ system, the ReadyBoost service checks the device to determine its characteristics and stores this information beneath the following key:
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Emdmgmt
This key gets populated with subkeys that refer not just to thumb drives connected to the system, but also external drives, sometimes referred to as "drive enclosures" (which, of course, has to have a drive in it). It appears that ReadyBoost performs some sort of "check" of the device in order to determine it's capabilities and see if it's suitable for use.
This plugin is useful for two primary reasons. First, it's a great way to verify that certain types of devices (thumb drives, external drives) had been connected to the system at one point. This can be validated against other sources of information (System hive, etc.).
The other useful aspect of information stored in this key applies specifically to thumb drives. In particular, the subkey that applies to a thumb drive contains the device class identifier, the device serial number, the volume serial number, and possibly the volume name (if the mounted volume has a name). For example,
Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15
LastWrite: Sun Jul 17 12:13:25 2011 Z
SN: 0C90195032E36889&0
Vol Name: TEST
VSN: 6403-CD1C
This is clearly a Best Buy Geek Squad U3 thumb drive that I connected to my system. That I really like about this is the volume serial number that's listed in the output. This is translated from the information maintained at the very end of the key name. I've used this information to correlate to VSNs stored in Windows shortcut/LNK streams (shortcuts in the user's Recent folder, Jump Lists), allowing me to tie the various artifacts together in order to demonstrate not only that a particular user accessed the thumb drive, but to also demonstrate what the file system on that device looked like at the time that the user accessed it. I can then further augment this information with the output of the comdlg32.pl and shellbags.pl plugins.
Thursday, April 04, 2013
RegRipper Consolidation
RegRipper has been consolidated at a single, static site.
Going forward, everything related to RegRipper will be available via (either at, or linked from) this one site. Updates to the tools will be available here, documentation will be available in the Wiki, and the latest plugin archives will be available from this site, as well.
The reason for doing this is that there just seems to be too much confusion associated with the tool. I've received emails saying that there are just too many sites that offer RegRipper, and that it's too confusing to figure out which one is the right one. So, let's just make it simple...this is the right one.
You'll notice that there's material in the Wiki, as well. We'll be using this to document and provide information in one single, static location. There is some information there now, but if there's something of interest that you can't find, let me know. I'll be happy to add or update information on the Wiki so that it's more useful.
I greatly appreciate all of the work that folks like Francesco, Brett, and Corey have put into the tool over the years. I also greatly appreciate the work of folks who have written plugins, as well as folks like Adam and "Cheeky4n6Monkey" who've written tools in an effort to make RegRipper easier to use. This consolidation does not take away from the great work that they've all done...it's simply a desire to bring everything together in one place.
So, what's different with this iteration of RegRipper? Not a lot, really. Again, it's more of a consolidation than anything else. Corey and I have put a lot of effort into "cleaning" up the plugin archive. We have updated a number of the plugins, consolidating some functionality, and adding other functionality (support for Wow6432Node where appropriate, etc.); in fact, there are so many of those little changes that we're going to forego the History page, but we'll pick it back up as we start documenting changes again going forward. So really...the biggest change is just the consolidation of everything in a single location.
Again, going forward, I'd like to have everything related to RegRipper at one site. Also, if you have any plugin requests, or just want to provide sample data for testing, please feel free to send it to me.
Finally, one more great big thanks to all of those who have supported RegRipper, by blogging about it, requesting or providing plugins, including it in an archive or distro, etc.
Going forward, everything related to RegRipper will be available via (either at, or linked from) this one site. Updates to the tools will be available here, documentation will be available in the Wiki, and the latest plugin archives will be available from this site, as well.
The reason for doing this is that there just seems to be too much confusion associated with the tool. I've received emails saying that there are just too many sites that offer RegRipper, and that it's too confusing to figure out which one is the right one. So, let's just make it simple...this is the right one.
You'll notice that there's material in the Wiki, as well. We'll be using this to document and provide information in one single, static location. There is some information there now, but if there's something of interest that you can't find, let me know. I'll be happy to add or update information on the Wiki so that it's more useful.
I greatly appreciate all of the work that folks like Francesco, Brett, and Corey have put into the tool over the years. I also greatly appreciate the work of folks who have written plugins, as well as folks like Adam and "Cheeky4n6Monkey" who've written tools in an effort to make RegRipper easier to use. This consolidation does not take away from the great work that they've all done...it's simply a desire to bring everything together in one place.
So, what's different with this iteration of RegRipper? Not a lot, really. Again, it's more of a consolidation than anything else. Corey and I have put a lot of effort into "cleaning" up the plugin archive. We have updated a number of the plugins, consolidating some functionality, and adding other functionality (support for Wow6432Node where appropriate, etc.); in fact, there are so many of those little changes that we're going to forego the History page, but we'll pick it back up as we start documenting changes again going forward. So really...the biggest change is just the consolidation of everything in a single location.
Again, going forward, I'd like to have everything related to RegRipper at one site. Also, if you have any plugin requests, or just want to provide sample data for testing, please feel free to send it to me.
Finally, one more great big thanks to all of those who have supported RegRipper, by blogging about it, requesting or providing plugins, including it in an archive or distro, etc.
Subscribe to:
Posts (Atom)