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.
Thursday, March 28, 2013
There Are Four Lights: Malware Indicators in the Registry
It can be extremely beneficial to understand various artifacts that malware creates on a system, particularly in light of the fact that AV isn't catching everything. Most AV appears to look for and then scan across executable files...some AV does find indicators based on text-based data, such as JavaScript code, etc.
Not all malware uses the Registry for persistence. For example, Theola uses a Chrome plugin to perform bank fraud, and W32/Crimea modifies imm32.dll in order to remain persistent (I found this variant in 2010; this is a write-up from another variant from 2007).
Not all malware creates really obvious indicators in the Registry, either. Corey talked about indicators for a variant of ZeroAccess. However, I analyzed a system that had been infected with another variant of ZA, one that created the HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8AD9C840-044E-11D1-B3E9-00805F499D93} key, the effect of which is explained in this GreyHatHacker blog post. While this isn't a persistence mechanism, it does illustrate an indicator of a malware infection.
"Detecting" Persistence Mechanisms
There was a SANS webcast in January 2012 titled Detecting Persistence Mechanisms, during which a number of persistence mechanisms were mentioned, including several found in the Registry. However, something that wasn't mentioned was how to actually go about detecting persistence mechanisms being created by malware. Corey recently published an excellent blog post titled, Tracking Down Persistence Mechanisms, which does a great job of illustrating how easy it is to quickly examine the contents of autostart (or "ASEP") locations, particularly in the Registry.
The process I use to detect the use of Registry persistence mechanisms and other malware artifacts is to start by adding the key LastWrite times from the Registry hives (both NTUSER.DAT and USRCLASS.DAT for users) to my timeline. This is exactly how I found the ZeroAccess artifact I described earlier in this blog post...the modified key was right there in the timeline. I even went so far as to examine the hive file extracted from a VSC created just prior to the LastWrite time of the key, and I was able to determine that the LastWrite time was, in fact, when the key was created (i.e., the key didn't exist in the hive file from the VSC). Timelines are a fantastic way to add context to the data that you're looking at, as well as to increase your relative level of confidence in the validity of that data. However, timeline analysis is best utilized as part of an overall analysis plan, developing pivot points and items of interest via other data retrieval and analysis mechanisms.
Once I find an interesting Registry artifact in close proximity to other activity on the system that is associated with the malware, I have a number of options available to me. Many times, I will open the hive in a viewer and take a look at what information is contained in the key itself...examine the subkeys, values and data. I can correlate this with information gleaned from online searches, and very often, quickly write a new or modify an existing RegRipper plugin. I then ensure that the Registry artifact is included as part of my shortened view of the overall timeline, along with a clear description of why it's significant, along with supporting documentation and references. This serves the purpose of not only providing information to my customer, but also documenting the information for my own use. In most cases, this entire process covers a span of a couple of minutes, maybe up to an hour depending up how much information is out there and available.
When Does It Start, and Why Does It Matter?
Where within the system that malware creates it's persistence mechanism has significant impact on your investigation, in part because investigations no longer center around the question of "was the system infected?"
Take a look at this ThreatExpert report; the report points to a Registry value within the user hive that the malware adds data to in order to remain persistent, and then states:
...so that %AppData%\skype.dat runs every time Windows starts
IMHO, this can be easily misinterpreted. If the analyst assumes that "Windows" refers to the system, then the statement is incorrect. However, if "Windows" refers to the shell, then it is correct...but to a point. In this case, the malware will start the next time that user logs into the system, and the Windows Explorer shell starts for that user.
Ok...but so what? Well, this can be a very important distinction to make. For example, let's say that someone from the helpdesk logs into an account on a user's workstation in order to assist with or fix something. They go to a web site to download a patch or update, and while it's installing, they do a bit of surfing...and the system gets infected. If the malware infects the system within the context of only that user account (i.e., creates a Registry persistence mechanism in the "HKCU" hive), then that malware will not be launched again until that user account is used to log into that system again. Where this distinction is important is in cases of the "Trojan Defense" (was the system infected, and did the malware execute?), as well as PCI forensic audits, where the PCI Council requires the analyst to identify the "window of compromise" in a dashboard area of the report. For merchants that know about how many credit card transactions they have in a given time period, that "window of compromise" can have a significant effect on the overall outcome of the report, potential fines levied by the council, etc. I examined a system once where the malware was identified and deleted by an on-demand AV scan less than 48 hrs after it was created on the system, and the intruder didn't upload a new version of the malware (albeit with the same name) for 6 weeks...which, like I said, had a significant impact on the overall outcome of the investigation.
In another example, I've seen a server systems that were infected with malware when an administrator logged in and performed some series of activities (usually web surfing or checking email...hey, it happens...) that led to the infection, with the persistence mechanism for the malware being in the Administrator user's NTUSER.DAT. When the server is rebooted, the malware doesn't persist and begin running again until the user logs into that account...in some cases, depending upon the server, that could be for several days or weeks. Once again, this is a very important distinction to make.
The ThreatExpert report mentioned above is only an example...it isn't the only site where these sorts of messages can be seen. I've seen reports at the MMPC site that state that malware creates a persistence mechanism in the HKCU\..\Run key so that it "starts whenever the system starts". The same is true for a number of reports at AV vendor sites.
Wow6432Node
I discussed Wow6432Node in a previous blog post, and Corey has discussed this as well. And yes, it is very important to point out yet again. And again. And again. Why is that? Because I honestly believe that most analysts are missing this source of data.
Not all malware uses the Registry for persistence. For example, Theola uses a Chrome plugin to perform bank fraud, and W32/Crimea modifies imm32.dll in order to remain persistent (I found this variant in 2010; this is a write-up from another variant from 2007).
Not all malware creates really obvious indicators in the Registry, either. Corey talked about indicators for a variant of ZeroAccess. However, I analyzed a system that had been infected with another variant of ZA, one that created the HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8AD9C840-044E-11D1-B3E9-00805F499D93} key, the effect of which is explained in this GreyHatHacker blog post. While this isn't a persistence mechanism, it does illustrate an indicator of a malware infection.
"Detecting" Persistence Mechanisms
There was a SANS webcast in January 2012 titled Detecting Persistence Mechanisms, during which a number of persistence mechanisms were mentioned, including several found in the Registry. However, something that wasn't mentioned was how to actually go about detecting persistence mechanisms being created by malware. Corey recently published an excellent blog post titled, Tracking Down Persistence Mechanisms, which does a great job of illustrating how easy it is to quickly examine the contents of autostart (or "ASEP") locations, particularly in the Registry.
The process I use to detect the use of Registry persistence mechanisms and other malware artifacts is to start by adding the key LastWrite times from the Registry hives (both NTUSER.DAT and USRCLASS.DAT for users) to my timeline. This is exactly how I found the ZeroAccess artifact I described earlier in this blog post...the modified key was right there in the timeline. I even went so far as to examine the hive file extracted from a VSC created just prior to the LastWrite time of the key, and I was able to determine that the LastWrite time was, in fact, when the key was created (i.e., the key didn't exist in the hive file from the VSC). Timelines are a fantastic way to add context to the data that you're looking at, as well as to increase your relative level of confidence in the validity of that data. However, timeline analysis is best utilized as part of an overall analysis plan, developing pivot points and items of interest via other data retrieval and analysis mechanisms.
Once I find an interesting Registry artifact in close proximity to other activity on the system that is associated with the malware, I have a number of options available to me. Many times, I will open the hive in a viewer and take a look at what information is contained in the key itself...examine the subkeys, values and data. I can correlate this with information gleaned from online searches, and very often, quickly write a new or modify an existing RegRipper plugin. I then ensure that the Registry artifact is included as part of my shortened view of the overall timeline, along with a clear description of why it's significant, along with supporting documentation and references. This serves the purpose of not only providing information to my customer, but also documenting the information for my own use. In most cases, this entire process covers a span of a couple of minutes, maybe up to an hour depending up how much information is out there and available.
When Does It Start, and Why Does It Matter?
Where within the system that malware creates it's persistence mechanism has significant impact on your investigation, in part because investigations no longer center around the question of "was the system infected?"
Take a look at this ThreatExpert report; the report points to a Registry value within the user hive that the malware adds data to in order to remain persistent, and then states:
...so that %AppData%\skype.dat runs every time Windows starts
IMHO, this can be easily misinterpreted. If the analyst assumes that "Windows" refers to the system, then the statement is incorrect. However, if "Windows" refers to the shell, then it is correct...but to a point. In this case, the malware will start the next time that user logs into the system, and the Windows Explorer shell starts for that user.
Ok...but so what? Well, this can be a very important distinction to make. For example, let's say that someone from the helpdesk logs into an account on a user's workstation in order to assist with or fix something. They go to a web site to download a patch or update, and while it's installing, they do a bit of surfing...and the system gets infected. If the malware infects the system within the context of only that user account (i.e., creates a Registry persistence mechanism in the "HKCU" hive), then that malware will not be launched again until that user account is used to log into that system again. Where this distinction is important is in cases of the "Trojan Defense" (was the system infected, and did the malware execute?), as well as PCI forensic audits, where the PCI Council requires the analyst to identify the "window of compromise" in a dashboard area of the report. For merchants that know about how many credit card transactions they have in a given time period, that "window of compromise" can have a significant effect on the overall outcome of the report, potential fines levied by the council, etc. I examined a system once where the malware was identified and deleted by an on-demand AV scan less than 48 hrs after it was created on the system, and the intruder didn't upload a new version of the malware (albeit with the same name) for 6 weeks...which, like I said, had a significant impact on the overall outcome of the investigation.
In another example, I've seen a server systems that were infected with malware when an administrator logged in and performed some series of activities (usually web surfing or checking email...hey, it happens...) that led to the infection, with the persistence mechanism for the malware being in the Administrator user's NTUSER.DAT. When the server is rebooted, the malware doesn't persist and begin running again until the user logs into that account...in some cases, depending upon the server, that could be for several days or weeks. Once again, this is a very important distinction to make.
The ThreatExpert report mentioned above is only an example...it isn't the only site where these sorts of messages can be seen. I've seen reports at the MMPC site that state that malware creates a persistence mechanism in the HKCU\..\Run key so that it "starts whenever the system starts". The same is true for a number of reports at AV vendor sites.
Wow6432Node
I discussed Wow6432Node in a previous blog post, and Corey has discussed this as well. And yes, it is very important to point out yet again. And again. And again. Why is that? Because I honestly believe that most analysts are missing this source of data.
Monday, March 25, 2013
Links
New HEFCBlog book is out!
David Cowen posted that his new book is out! The book is titled, Computer Forensics InfoSec Pro Guide (Beginner's Guide). David's also got a new web site to go along with the book...learndfir.com. There isn't a great deal of information available about this book or its contents yet, but Dave has always been a fount of great things for DFIR, so keep your eyes on the site. David did state on his blog that he's working on some "links, documents, and forensic images", so look for good things to come.
If you're going to get David's book, I would recommend that you also consider Brett Shaver's book, Putting the Suspect Behind the Keyboard, which provides an investigator's perspective and insight into determining who was sitting at the keyboard.
CyberThreat Detection
Lesley Carhart posted this article over on the Motorola Solutions Community site, mentioning the need for log monitoring, particularly in the face of Mandiant's APT1 report. A lot of what Lesley says in the post has been mentioned before, but I tend to think that it's important to keep the same message consistent and repeated...just look around and see all of the organizations that get hit and don't have any of what she mentions implemented.
One statement made in the article that caught my attention was:
Attackers frequently spread laterally, system to system, using legitimate accounts and services. Would your organization detect this?
The reason this caught my attention was that as far back as I can remember, even going back to the 2012 DoD CyberCrime Conference, one of the primary complaints about the mention of "lateral movement" is that there is a dearth of information regarding what that looks like...so, how would an organization be able to detect this sort of activity if the folks who know what it looks like aren't sharing the information? This was the case at DC3 2012...I heard a couple of attendees lamenting the fact that for all of the presentations that included "APT" in the title, none of them actually provided actionable information. I can only say that I attended three of those presentations, and not one of the authors actually listed what that lateral movement within the infrastructure looks like to an analyst.
Using RegRipper
Ken posted the Work Smarter, Not Harder article to his blog this weekend, which, in part, raises awareness of how to make the most effectively use of RegRipper. In his post, Ken discusses using some basic functionality of RegRipper...creating custom profiles...and ties that to another recent blog post. I greatly appreciate the time that Ken took to not only use the tool, but to write about his experience and use of the tool...I think that this really validates how easy-to-use these tools can be, and how effective their use can be in pursuing an examination. It's one thing for me to write about how to use the tool, it's something else entirely for someone like Ken to share a real-world example of how he used the tool to complete analysis.
One thing that Ken says in the post is:
Running rip.exe -r ntuser.dat -f ntuser-all, for example, will run every ntuser.dat specific plugin against the ntuser.dat file.
A bit of clarification is required here...the command will run every "ntuser.dat-specific plugin listed in the ntuser-all profile against the ntuser.dat file". My point is that analysts should not assume that every plugin intended to be run against the NTUSER.DAT file is listed in the ntuser-all profile. This file is a flat text file, with no extension (which simply means that it does not end in ".txt" or ".dat", or...anything) that contains a list of plugins that you'd like to run, in the order that you'd like to run them. It's always good to check and ensure that the plugins you want to be included in the profile are actually listed. If not, they're very easy to add, as Ken described in his post.
My own custom RegRipper profile for retrieving program execution artifacts from the NTUSER.DAT hive includes the following plugins:
userassist
sysinternals
compatassist
applets
autorun
muicache
runmru
As many folks are aware, I teach a couple of courses. During the courses, I invariably meet people who "use" RegRipper on a regular basis...what this most often amounts to is downloading RegRipper v2.5 (if you watched the SANS webcast from January 2013 closely, you could see that Mandiant is still on v2.02...) and simply running the UI version of RegRipper. But there's so much more available through the tool, as Ken described in his post.
For example, I get asked, "...is there a list of available plugins?" on a regular basis. This is why I provided a very simple facility through rip.exe to output a list of plugins (described in this blog post), including an option for CSV output. An example of a command line that I discuss in the courses, for providing just a list of plugins that retrieve information from the NTUSER.DAT hive is:
C:\tools>rip -l -c | find ",NTUSER,DAT," /i > ntuser.csv
Run this command, and then open the resulting .csv file in Excel for easy review. An alternative would be to simply drop the "find" portion of the command, open the resulting .csv file in Excel, and then sort of the third column to list the plugins based on the hive file.
You can also take this same approach to create specific profiles for USB device tracking within various hives, as well.
Side Note: One question is regularly ask users of RegRipper is, what would make RegRipper a 'better' tool. More/better documentation? Some additional functionality? If there's a specific plugin that you'd like to see created, you can take a look at Adam's 3RPG site (he blogged about creating four RR plugins in 15 min.), or you can contact me and request the plugin - all I'll need is a concise description of what you're looking for, and some sample data. If you provide this information, I'm able to get plugins turned around rather quickly. There is a LOT of information out there embedded in Registry hive files, and relying on a small group of people to create the plugins, when we're not seeing this information, amounts to a significant loss for the community.
"Cyber" Insurance
Something I've been watching with a bit of fascination is the spread of "cyber" insurance. Looking back over the response and analysis engagements that I've performed or been involved with over the years, including PCI forensic audits, this is a very interesting development. You'd need to review the annual reports from companies such as Mandiant, Trustwave and Verizon to see the effect that compliance regulations have had on organizations getting compromised...based on previous year's reports, one might think that there hasn't been much of an effect.
What's clear is that the issue of organizations getting "hacked" is getting even more attention.
CyberGuardians post
I did not attend the SANS Cyber Thread Intelligence Summit 2013, but I did get to read about it at the CyberGuardians blog. Having been engaged in DFIR work for some time, I thought that both the presentations and the reviews of them were very insightful, and that the focus of DFIR work was moving in the right direction. So many times as an emergency responder, I would show up and find that the on-site IR team was completely hamstrung, with no ability to get any sort of meaningful information during an incident. In many cases, even the most basic information needed to simply assess systems had to be requested from network or systems ops folks...this was true not only at commercial and private sector sites, but also within the federal government.
What I really took away from the post is the realization that a mainstream organization such as SANS is now espousing the need for organizations to not only effectively consume (i.e., make use of) threat intelligence, but to also produce and share threat intelligence, as well. A number of consulting organizations offer this as a service, but some of them focus solely on one are of the IR spectrum (i.e., network sources, and not bringing memory- or host-based artifacts into the equation). Part of the problem with this is that, while these are excellent services, many of the potential consumers of this intelligence are simply neither prepared nor equipped to make effective use of this information.
ImDisk
A new version of the ImDisk Toolkit is available, which works on Windows up to Win8 (32- and 64-bit).
Training
There are still seats available for the 9-10 April offering of Timeline Analysis at our Reston location, as well as for the Windows Forensic and Registry Analysis course combo to be held at the Santa Cruz PD training facility. If you're interested in any of these courses, but cannot make it to the Reston location, contact us about sponsoring the training at your location.
David Cowen posted that his new book is out! The book is titled, Computer Forensics InfoSec Pro Guide (Beginner's Guide). David's also got a new web site to go along with the book...learndfir.com. There isn't a great deal of information available about this book or its contents yet, but Dave has always been a fount of great things for DFIR, so keep your eyes on the site. David did state on his blog that he's working on some "links, documents, and forensic images", so look for good things to come.
If you're going to get David's book, I would recommend that you also consider Brett Shaver's book, Putting the Suspect Behind the Keyboard, which provides an investigator's perspective and insight into determining who was sitting at the keyboard.
CyberThreat Detection
Lesley Carhart posted this article over on the Motorola Solutions Community site, mentioning the need for log monitoring, particularly in the face of Mandiant's APT1 report. A lot of what Lesley says in the post has been mentioned before, but I tend to think that it's important to keep the same message consistent and repeated...just look around and see all of the organizations that get hit and don't have any of what she mentions implemented.
One statement made in the article that caught my attention was:
Attackers frequently spread laterally, system to system, using legitimate accounts and services. Would your organization detect this?
The reason this caught my attention was that as far back as I can remember, even going back to the 2012 DoD CyberCrime Conference, one of the primary complaints about the mention of "lateral movement" is that there is a dearth of information regarding what that looks like...so, how would an organization be able to detect this sort of activity if the folks who know what it looks like aren't sharing the information? This was the case at DC3 2012...I heard a couple of attendees lamenting the fact that for all of the presentations that included "APT" in the title, none of them actually provided actionable information. I can only say that I attended three of those presentations, and not one of the authors actually listed what that lateral movement within the infrastructure looks like to an analyst.
Using RegRipper
Ken posted the Work Smarter, Not Harder article to his blog this weekend, which, in part, raises awareness of how to make the most effectively use of RegRipper. In his post, Ken discusses using some basic functionality of RegRipper...creating custom profiles...and ties that to another recent blog post. I greatly appreciate the time that Ken took to not only use the tool, but to write about his experience and use of the tool...I think that this really validates how easy-to-use these tools can be, and how effective their use can be in pursuing an examination. It's one thing for me to write about how to use the tool, it's something else entirely for someone like Ken to share a real-world example of how he used the tool to complete analysis.
One thing that Ken says in the post is:
Running rip.exe -r ntuser.dat -f ntuser-all, for example, will run every ntuser.dat specific plugin against the ntuser.dat file.
A bit of clarification is required here...the command will run every "ntuser.dat-specific plugin listed in the ntuser-all profile against the ntuser.dat file". My point is that analysts should not assume that every plugin intended to be run against the NTUSER.DAT file is listed in the ntuser-all profile. This file is a flat text file, with no extension (which simply means that it does not end in ".txt" or ".dat", or...anything) that contains a list of plugins that you'd like to run, in the order that you'd like to run them. It's always good to check and ensure that the plugins you want to be included in the profile are actually listed. If not, they're very easy to add, as Ken described in his post.
My own custom RegRipper profile for retrieving program execution artifacts from the NTUSER.DAT hive includes the following plugins:
userassist
sysinternals
compatassist
applets
autorun
muicache
runmru
As many folks are aware, I teach a couple of courses. During the courses, I invariably meet people who "use" RegRipper on a regular basis...what this most often amounts to is downloading RegRipper v2.5 (if you watched the SANS webcast from January 2013 closely, you could see that Mandiant is still on v2.02...) and simply running the UI version of RegRipper. But there's so much more available through the tool, as Ken described in his post.
For example, I get asked, "...is there a list of available plugins?" on a regular basis. This is why I provided a very simple facility through rip.exe to output a list of plugins (described in this blog post), including an option for CSV output. An example of a command line that I discuss in the courses, for providing just a list of plugins that retrieve information from the NTUSER.DAT hive is:
C:\tools>rip -l -c | find ",NTUSER,DAT," /i > ntuser.csv
Run this command, and then open the resulting .csv file in Excel for easy review. An alternative would be to simply drop the "find" portion of the command, open the resulting .csv file in Excel, and then sort of the third column to list the plugins based on the hive file.
You can also take this same approach to create specific profiles for USB device tracking within various hives, as well.
Side Note: One question is regularly ask users of RegRipper is, what would make RegRipper a 'better' tool. More/better documentation? Some additional functionality? If there's a specific plugin that you'd like to see created, you can take a look at Adam's 3RPG site (he blogged about creating four RR plugins in 15 min.), or you can contact me and request the plugin - all I'll need is a concise description of what you're looking for, and some sample data. If you provide this information, I'm able to get plugins turned around rather quickly. There is a LOT of information out there embedded in Registry hive files, and relying on a small group of people to create the plugins, when we're not seeing this information, amounts to a significant loss for the community.
"Cyber" Insurance
Something I've been watching with a bit of fascination is the spread of "cyber" insurance. Looking back over the response and analysis engagements that I've performed or been involved with over the years, including PCI forensic audits, this is a very interesting development. You'd need to review the annual reports from companies such as Mandiant, Trustwave and Verizon to see the effect that compliance regulations have had on organizations getting compromised...based on previous year's reports, one might think that there hasn't been much of an effect.
What's clear is that the issue of organizations getting "hacked" is getting even more attention.
CyberGuardians post
I did not attend the SANS Cyber Thread Intelligence Summit 2013, but I did get to read about it at the CyberGuardians blog. Having been engaged in DFIR work for some time, I thought that both the presentations and the reviews of them were very insightful, and that the focus of DFIR work was moving in the right direction. So many times as an emergency responder, I would show up and find that the on-site IR team was completely hamstrung, with no ability to get any sort of meaningful information during an incident. In many cases, even the most basic information needed to simply assess systems had to be requested from network or systems ops folks...this was true not only at commercial and private sector sites, but also within the federal government.
What I really took away from the post is the realization that a mainstream organization such as SANS is now espousing the need for organizations to not only effectively consume (i.e., make use of) threat intelligence, but to also produce and share threat intelligence, as well. A number of consulting organizations offer this as a service, but some of them focus solely on one are of the IR spectrum (i.e., network sources, and not bringing memory- or host-based artifacts into the equation). Part of the problem with this is that, while these are excellent services, many of the potential consumers of this intelligence are simply neither prepared nor equipped to make effective use of this information.
ImDisk
A new version of the ImDisk Toolkit is available, which works on Windows up to Win8 (32- and 64-bit).
Training
There are still seats available for the 9-10 April offering of Timeline Analysis at our Reston location, as well as for the Windows Forensic and Registry Analysis course combo to be held at the Santa Cruz PD training facility. If you're interested in any of these courses, but cannot make it to the Reston location, contact us about sponsoring the training at your location.
Monday, March 18, 2013
There are Four Lights: Program Execution
I'd seen a tweet recently where someone was asking about information regarding the last time a user launched an application on a system. The system had an SSD drive, and as such, application Prefetching was disabled, by default. Therefore, one of the more well-known artifacts that indicate program execution was not available to the analyst. The fact is that there are a number of locations available on Windows systems that will maintain indications of program execution. Although not all of them allow the program execution or application launch to be tied directly to a user, or to be correlated to a specific time, they may be useful, nonetheless.
A valuable aspect of these locations is that they will very often persist beyond the deletion or removal of the application.
This category of artifacts can assist you in implementing an analysis matrix for your examination.
This post will be directed at providing information about artifacts that provide indications of program execution; many of the artifacts listed will not be able to allow the analyst to state explicitly that a user last launched an application at a specific date and time; rather, analysts should be aware of the artifacts, and be able to apply them (and others) as needed. These artifacts can be used in a number of cases, in order to demonstrate a window of compromise, malware detection (just because you detected malware, does that mean that it actually ran??), etc.
Application Prefetch Files
Application prefetch files are a great source of information about applications run on the system, as well as when they were last run (although they are not specific to a user). However, Windows server systems do not have application prefetching enabled by default, and application prefetching is disabled by default when Windows sees that it's being run from an SSD drive.
Shortcut/LNK files and Jump Lists
I include shortcut/LNK files and Jump Lists together because Jump Lists are comprised of LNK streams (this goes back to my post on understanding data structures). And they can both provide indications of program execution (as well as access to remote storage). In order to determine which application was launched, you may need to do some file extension analysis, or in the case of Jump Lists, start with an AppID lookup.
Browser History
With the exception of what was described in this blog post, the existence of a browser history will demonstrate the browser had been launched, within the context of a specific user. In most cases, the specific records requested will include time stamps. Also, don't forget to check things like bookmarks/favorites, etc., which will provide other indications of the use of the browser, even after the browser history has been cleared or trimmed (most browsers have an automatic process for clearing out older history and cache entries, independent of the user specifically performing the action). Also, for IE, check out the RegRipper menuorder.pl plugin.
Hibernation Files
While hibernation files will not explicitly put the suspect at the keyboard, much like crash dump files, they can be used to demonstrate that an application was (or wasn't) running at one time. If you're going to analyze hibernation files, I strongly recommend that you consider using Volatility, or take the course taught by these folks.
Windows Event Log
I was analyzing a Windows 2008 R2 server not long ago, and found that an intruder had installed and run Havij and some other, similar tools. Interesting enough, the Application Experience Event Log included entries indicating that the application had been installed on, as well as removed from the system. Remember, Process Tracking isn't always enabled within audit configuration, but there may be other ways to determine indications of applications or programs being executed via serivces starting (event ID 7035/7036), etc.
Registry
The Windows Registry can contain a number of interesting keys and values that can provide indications of applicaitons being launched, or programs being executed. In many cases, much like the file system, these locations can contain information about program execution long after the deletion/removal of the application or program.
MSIs
Windows maintains a list of applications that were installed via Microsoft Installer (*.msi) files. While this does not tie directly the execution of the program, it can indicate that it was installed.
RecentDocs
The user's RecentDocs key can provide indications of program execution, even if indirectly. For example, an .exe file may have been opened, but rather than launched, the user had opened it in a hex editor...which itself is an indication of "program execution" (of the hex editor). You may have to perform file extension analysis or timeline analysis in order to determine specifically which application was used to open the file.
Also, be sure to check the OpenSaveMRU and OpenSavePidlMRU subkeys beneath the ComDlg32 key.
AppCompatCache
An old favorite, Corey Harrell has talked about this Registry value on his blog. Also, if you really want to get the available information about this value, check out what Mandiant has to say about it. They discovered and publicized it, and even wrote up an excellent white paper on parsing the value data. It's important to keep in mind that the last modification time for each application that is retrieved by the various tools is from the file system.
MUICache
I've found over the years that some applications run within the user context have had entries created as values beneath this Registry key. Now, the values do not have a time stamp associated with them
*Tracing
MS states that the Routing and Remote Access protocol has some pretty extensive tracing capabilities used for troubleshooting. During exams, I've seen applications with networking capabilities included in subkeys beneath this key.
*DirectDraw, etc.
There are a number of subkeys beneath the Microsoft key (in the Software and NTUSER.DAT hives) that have names like DirectDraw, Direct3D, etc., and some of these may have a subkey named MostRecentApplication, which provides the name of the last application to make use of the capability. I have seen this most often used by legitimate applications, such as iexplorer.exe, but it may also lead to malware (see this Sophos ZBot writeup).
SysInternals
While this key is particular to a specific set of applications, the fact is that in order to run the SysInternals utilities, you need to accept the EULA, which creates a Registry subkey beneath the SysInternals key. This can be very useful during an exam.
AppCompatFlags (NTUSER.DAT)
This key contains artifacts of applications executed by a user under the Program Compatibility Assistant, even if no compatibility modes are applied.
UserAssist
These artifacts provide indications of applications that the user launched by clicking on them through the shell, either double-clicking an icon on their Desktop or through Windows Explorer, or by selecting the Start button and clicking on the application through the program menu.
RunMRU
This Registry key provides indications of commands that the user has typed in at the Start->Run box.
AutoStart locations - *Run keys, Windows Services, etc.
You would need to correlate these entries to when the system was started, or when the user logged in. This can be extremely significant. If something (malware or another application) is set to autostart based on when a user logs in (usually found within the HKCU hive), then the last time that the application executed could be well after the system was started. This may not be significant to the examination, but it does go to overall clarity and correctness of your findings.
LANDesk
I've seen a couple of instances where a system I was examining had LANDesk installed; part of the functionality of LANDesk includes the application writing Registry keys for each application launched on the system, including values for when the application was first and last launched, the user account used to launch the application the last time it was run, etc. This proved very useful, particularly when included in a timeline.
Windows Services/AutoStart Locations
Windows Services can provide some excellent information regarding the start of an application; however, do not assume that because a service is listed that it automatically started with the system booted. This is not always the case. An analyst needs to check the start type of the service, as well as check the Windows Event Log for events with ID 7035/7036 (indicate a service start). Another artifact that can be extremely useful when examining services is the Enum\Root\LEGACY_* keys within the System hive; the subkeys beneath these keys for each service are created the first and last time, respectively, that the service was run, and like other artifacts, will persist after the service was either disabled or removed from the system.
The same is true with other autostart locations; you need to be clear on the location and the effect that it has on the application start...even MS has gotten this one wrong. If the application is listed in a user hive (HKCU), then it will start when the user logs in, NOT when the system starts.
'*' indicates Registry keys that may also have a counterpart found in the Wow6432Node path.
The artifacts described in this blog post are intended to assist analysts in understanding where to look for indications that applications has been run on a system. In some cases, the artifacts may tie the program execution to a specific user, and other times, to a specific time. These artifacts are not specific to malware...in fact, I tend to attribute other, specific artifacts to the "malware" artifact category. Other artifacts may be specific to applications...for example, the Terminal Services Client will maintain a list of systems to which a user has connected in both Jump Lists, as well as beneath a Registry key in the NTUSER.DAT hive, indicating that the user launched the application. IE (versions 5-9) has Registry artifacts, as well. Applications that include MRU lists will allow the analyst to demonstrate the use of that application, by a user, at a specific time.
Resources
Network artifacts found in the Registry
A valuable aspect of these locations is that they will very often persist beyond the deletion or removal of the application.
This category of artifacts can assist you in implementing an analysis matrix for your examination.
This post will be directed at providing information about artifacts that provide indications of program execution; many of the artifacts listed will not be able to allow the analyst to state explicitly that a user last launched an application at a specific date and time; rather, analysts should be aware of the artifacts, and be able to apply them (and others) as needed. These artifacts can be used in a number of cases, in order to demonstrate a window of compromise, malware detection (just because you detected malware, does that mean that it actually ran??), etc.
Application Prefetch Files
Application prefetch files are a great source of information about applications run on the system, as well as when they were last run (although they are not specific to a user). However, Windows server systems do not have application prefetching enabled by default, and application prefetching is disabled by default when Windows sees that it's being run from an SSD drive.
Shortcut/LNK files and Jump Lists
I include shortcut/LNK files and Jump Lists together because Jump Lists are comprised of LNK streams (this goes back to my post on understanding data structures). And they can both provide indications of program execution (as well as access to remote storage). In order to determine which application was launched, you may need to do some file extension analysis, or in the case of Jump Lists, start with an AppID lookup.
Browser History
With the exception of what was described in this blog post, the existence of a browser history will demonstrate the browser had been launched, within the context of a specific user. In most cases, the specific records requested will include time stamps. Also, don't forget to check things like bookmarks/favorites, etc., which will provide other indications of the use of the browser, even after the browser history has been cleared or trimmed (most browsers have an automatic process for clearing out older history and cache entries, independent of the user specifically performing the action). Also, for IE, check out the RegRipper menuorder.pl plugin.
Hibernation Files
While hibernation files will not explicitly put the suspect at the keyboard, much like crash dump files, they can be used to demonstrate that an application was (or wasn't) running at one time. If you're going to analyze hibernation files, I strongly recommend that you consider using Volatility, or take the course taught by these folks.
Windows Event Log
I was analyzing a Windows 2008 R2 server not long ago, and found that an intruder had installed and run Havij and some other, similar tools. Interesting enough, the Application Experience Event Log included entries indicating that the application had been installed on, as well as removed from the system. Remember, Process Tracking isn't always enabled within audit configuration, but there may be other ways to determine indications of applications or programs being executed via serivces starting (event ID 7035/7036), etc.
Registry
The Windows Registry can contain a number of interesting keys and values that can provide indications of applicaitons being launched, or programs being executed. In many cases, much like the file system, these locations can contain information about program execution long after the deletion/removal of the application or program.
MSIs
Windows maintains a list of applications that were installed via Microsoft Installer (*.msi) files. While this does not tie directly the execution of the program, it can indicate that it was installed.
RecentDocs
The user's RecentDocs key can provide indications of program execution, even if indirectly. For example, an .exe file may have been opened, but rather than launched, the user had opened it in a hex editor...which itself is an indication of "program execution" (of the hex editor). You may have to perform file extension analysis or timeline analysis in order to determine specifically which application was used to open the file.
Also, be sure to check the OpenSaveMRU and OpenSavePidlMRU subkeys beneath the ComDlg32 key.
AppCompatCache
An old favorite, Corey Harrell has talked about this Registry value on his blog. Also, if you really want to get the available information about this value, check out what Mandiant has to say about it. They discovered and publicized it, and even wrote up an excellent white paper on parsing the value data. It's important to keep in mind that the last modification time for each application that is retrieved by the various tools is from the file system.
MUICache
I've found over the years that some applications run within the user context have had entries created as values beneath this Registry key. Now, the values do not have a time stamp associated with them
*Tracing
MS states that the Routing and Remote Access protocol has some pretty extensive tracing capabilities used for troubleshooting. During exams, I've seen applications with networking capabilities included in subkeys beneath this key.
*DirectDraw, etc.
There are a number of subkeys beneath the Microsoft key (in the Software and NTUSER.DAT hives) that have names like DirectDraw, Direct3D, etc., and some of these may have a subkey named MostRecentApplication, which provides the name of the last application to make use of the capability. I have seen this most often used by legitimate applications, such as iexplorer.exe, but it may also lead to malware (see this Sophos ZBot writeup).
SysInternals
While this key is particular to a specific set of applications, the fact is that in order to run the SysInternals utilities, you need to accept the EULA, which creates a Registry subkey beneath the SysInternals key. This can be very useful during an exam.
AppCompatFlags (NTUSER.DAT)
This key contains artifacts of applications executed by a user under the Program Compatibility Assistant, even if no compatibility modes are applied.
UserAssist
These artifacts provide indications of applications that the user launched by clicking on them through the shell, either double-clicking an icon on their Desktop or through Windows Explorer, or by selecting the Start button and clicking on the application through the program menu.
RunMRU
This Registry key provides indications of commands that the user has typed in at the Start->Run box.
AutoStart locations - *Run keys, Windows Services, etc.
You would need to correlate these entries to when the system was started, or when the user logged in. This can be extremely significant. If something (malware or another application) is set to autostart based on when a user logs in (usually found within the HKCU hive), then the last time that the application executed could be well after the system was started. This may not be significant to the examination, but it does go to overall clarity and correctness of your findings.
LANDesk
I've seen a couple of instances where a system I was examining had LANDesk installed; part of the functionality of LANDesk includes the application writing Registry keys for each application launched on the system, including values for when the application was first and last launched, the user account used to launch the application the last time it was run, etc. This proved very useful, particularly when included in a timeline.
Windows Services/AutoStart Locations
Windows Services can provide some excellent information regarding the start of an application; however, do not assume that because a service is listed that it automatically started with the system booted. This is not always the case. An analyst needs to check the start type of the service, as well as check the Windows Event Log for events with ID 7035/7036 (indicate a service start). Another artifact that can be extremely useful when examining services is the Enum\Root\LEGACY_* keys within the System hive; the subkeys beneath these keys for each service are created the first and last time, respectively, that the service was run, and like other artifacts, will persist after the service was either disabled or removed from the system.
The same is true with other autostart locations; you need to be clear on the location and the effect that it has on the application start...even MS has gotten this one wrong. If the application is listed in a user hive (HKCU), then it will start when the user logs in, NOT when the system starts.
'*' indicates Registry keys that may also have a counterpart found in the Wow6432Node path.
The artifacts described in this blog post are intended to assist analysts in understanding where to look for indications that applications has been run on a system. In some cases, the artifacts may tie the program execution to a specific user, and other times, to a specific time. These artifacts are not specific to malware...in fact, I tend to attribute other, specific artifacts to the "malware" artifact category. Other artifacts may be specific to applications...for example, the Terminal Services Client will maintain a list of systems to which a user has connected in both Jump Lists, as well as beneath a Registry key in the NTUSER.DAT hive, indicating that the user launched the application. IE (versions 5-9) has Registry artifacts, as well. Applications that include MRU lists will allow the analyst to demonstrate the use of that application, by a user, at a specific time.
Resources
Network artifacts found in the Registry
Saturday, March 16, 2013
BinMode: IE Index.dat
I've posted on the need for analysts to understand data structures before, and I recently conducted some analysis that I think illustrates this point extremely well.
The purpose of this blog post is to illustrate how certain artifacts can be used to detect the presence of malware on a system. While a tool for doing so is described, this is not a blog post about parsing histories for all of the browsers a user may or could have used, in part because the artifacts examined do not pertain to other browsers.
Not long ago, I tweeted that I'd written a plugin for the Forensic Scanner that gets statistics from IE (version 5 - 9) index.dat browser history files for all user profiles on the system. Almost immediately, someone tweeted asking, "what if the user isn't using IE?" That's a good question, but it misses the point of the analysis technique and of having the plugin in the first place.
I was analyzing a system recently that had been infected with ZeroAccess (see the Sophos report), and one of the things I was aware of the malware was capable of doing was click-fraud. In my analysis, I saw that the malware used an autostart persistence mechanism that was outside the scope of the user context...my timeline illustrated the artifacts being created. Knowing that much of the malware that communicates off-system will use the WinInet API functions to do so, I began looking at the index.dat files for the various user profiles available on the system. What I found was that the NetworkService account had much more significant "browser history" than the 'normal' user account on the system.
That's exactly right...there's no typo. The NetworkService account. How could that be? That's not something you see very often, is it? I mean, how does someone sit down at the keyboard and log into the account, and launch IE? The answer is...they don't. What happens is that when code using the WinInet API is run at privileges other than those of a user, the artifacts are created in another account profile. For example, back when Windows XP was more prevalent in my analysis lab, I would see systems on which the Default User profile had a populated index.dat file. I've seen the same thing with the LocalService account; this may depend upon which process the malware is injected into, and where that process falls in the svchost.exe hierarchy.
So my point is that for malware detection, checking all user accounts for statistics regarding their index.dat files might be a good idea. Once you understand the data structures in question - that is, the headers of the index.dat file, which, thanks to Joachim Metz, are well documented - this becomes a trivial task.
I started by writing a simple script that would parse the contents of the header of the index.dat file and tell me a little bit about what I could expect to see. Based on the format specification for the file, I was interested in things like the offset to the HASH table, as well as the directories beneath the "Temporary Internet Files\Content.IE5" folder and the number of cache files in each folder. This information is stored in the headers of the files, and is very easy to parse out and display. I got the script working and it proved to be very useful. However, I know that there's a process to using the script...I have to determine which user profiles are available, determine the version of Windows being examined, and based on those two pieces of information, type in the appropriate path to the index.dat file in question. By hand. Seriously?
So, I created a system class plugin for the Forensic Scanner to do all of this for me. Automatically. System class plugins are run against the entire system, whereas user class plugins are run against each user profile selected by the analyst. Based on the specific artifacts that I'm looking for, a system class plugin is exactly what I need.
What follows is an excerpt of the output from the ie_stats.pl plugin. First, the Administrator account profile:
g:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size : 163840
Hash Table Offset : 0x5000
Number of blocks : 1152
Number of alloc. blocks: 1089
Dir: LPVS8JVQ Files: 90
Dir: IR1PLUTE Files: 89
Dir: 5K3JMTA3 Files: 88
Dir: O3VB95DY Files: 89
As you can see, the Administrator account has some browser history associated with it. The hash table is located at offset 0x5000 within the index.dat file, and there are four subdirectories, each containing a number of cache files.
g:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size : 32768
Hash Table Offset : 0x0
Number of blocks : 128
Number of alloc. blocks: 32
Dir: O8WMK2SC Files: 0
Dir: UAAUTN4C Files: 0
Dir: Q323MBYB Files: 0
Dir: 4VRPMD81 Files: 0
Okay, so this is what an empty index.dat looks like; the Default User profile has no IE history associated with it...there is no hash table, and the subdirectories don't contain any files.
g:\Documents and Settings\NetworkService\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size : 9437184
Hash Table Offset : 0x5000
Number of blocks : 73600
Number of alloc. blocks: 58784
Dir: EIQLTWH3 Files: 384
Dir: KFSPU8SK Files: 384
Dir: ABR75H1M Files: 384
Dir: 5QI7EWW7 Files: 384
Dir: TTYX5IX2 Files: 384
Dir: 5GDCH3XG Files: 383
Dir: KZZXKXWH Files: 383
Dir: LA2SZ5HL Files: 383
Dir: TLRE11UL Files: 383
Dir: IYT9OTGD Files: 383
Dir: 58I9EM25 Files: 383
....
The NetworkService account was the one that set off alarms! As you can see, this profile has a significant history! Parsing the actual index.dat file and displaying the entries in a micro-timeline (just the URL records) illustrated a significant amount of activity in a relatively short amount of time, with more URLs being requested per second than most users are capable of typing in or clicking via the browser.
In this case, I used the command line version of the Forensic Scanner to run a single plugin. I had mounted the image file via FTK Imager, and it appeared on my system as the G:\ volume. I then typed the following command:
C:\Perl\scanner>fscan.pl -s g:\windows\system32 -p ie_stats
That's all it took. Again, this is NOT a comprehensive analysis...this is a quick check to see if I could expect any potential issues. Another way to run this would be to select the "malware" artifact category...the ie_stats.pl plugin is included in that category. Also, the purpose of running this plugin is NOT to find indications of browser activity, for all browsers, and for all users. Instead, the purpose of this plugin is to check for something very specific...it does so automatically, accurately, and very, very quickly. This entire exercise took only a couple of minutes, most of which was spent mounting the image file...once that was done, the plugin ran very quickly, and provided me with the information I needed. I don't want to list all of the URL and REDR records from the NetworkService profile index.dat because just from what we see above (not all of the directories are listed) there are around 4000 or so files in the cache subdirectories.
Again, the purpose of this blog post is to illustrate an analysis technique. In the past, what I've done is to use ProDiscover to populate the "Internet History View" from within the image, and look for indications of service accounts with URL records in their index.dat. However, the methodology used by ProDiscover is more comprehensive...it searches the entire file system, and parses all of the records out of each index.dat file that it finds. In this case, that's much more than what I'm looking for.
This analysis technique can be combined with other tools into a more comprehensive process, as described in this blog post. Parsing application prefetch (*.pf) files and finding indications of wininet.dll as one of the loaded modules might be something to correlate with this analysis technique.
Resources
Rob Hensing's post on the Default User with an IE browser history
ForensicsWiki page: IE History File Format
Extremely relevant post from Hogfly (2007)
The purpose of this blog post is to illustrate how certain artifacts can be used to detect the presence of malware on a system. While a tool for doing so is described, this is not a blog post about parsing histories for all of the browsers a user may or could have used, in part because the artifacts examined do not pertain to other browsers.
Not long ago, I tweeted that I'd written a plugin for the Forensic Scanner that gets statistics from IE (version 5 - 9) index.dat browser history files for all user profiles on the system. Almost immediately, someone tweeted asking, "what if the user isn't using IE?" That's a good question, but it misses the point of the analysis technique and of having the plugin in the first place.
I was analyzing a system recently that had been infected with ZeroAccess (see the Sophos report), and one of the things I was aware of the malware was capable of doing was click-fraud. In my analysis, I saw that the malware used an autostart persistence mechanism that was outside the scope of the user context...my timeline illustrated the artifacts being created. Knowing that much of the malware that communicates off-system will use the WinInet API functions to do so, I began looking at the index.dat files for the various user profiles available on the system. What I found was that the NetworkService account had much more significant "browser history" than the 'normal' user account on the system.
That's exactly right...there's no typo. The NetworkService account. How could that be? That's not something you see very often, is it? I mean, how does someone sit down at the keyboard and log into the account, and launch IE? The answer is...they don't. What happens is that when code using the WinInet API is run at privileges other than those of a user, the artifacts are created in another account profile. For example, back when Windows XP was more prevalent in my analysis lab, I would see systems on which the Default User profile had a populated index.dat file. I've seen the same thing with the LocalService account; this may depend upon which process the malware is injected into, and where that process falls in the svchost.exe hierarchy.
So my point is that for malware detection, checking all user accounts for statistics regarding their index.dat files might be a good idea. Once you understand the data structures in question - that is, the headers of the index.dat file, which, thanks to Joachim Metz, are well documented - this becomes a trivial task.
I started by writing a simple script that would parse the contents of the header of the index.dat file and tell me a little bit about what I could expect to see. Based on the format specification for the file, I was interested in things like the offset to the HASH table, as well as the directories beneath the "Temporary Internet Files\Content.IE5" folder and the number of cache files in each folder. This information is stored in the headers of the files, and is very easy to parse out and display. I got the script working and it proved to be very useful. However, I know that there's a process to using the script...I have to determine which user profiles are available, determine the version of Windows being examined, and based on those two pieces of information, type in the appropriate path to the index.dat file in question. By hand. Seriously?
So, I created a system class plugin for the Forensic Scanner to do all of this for me. Automatically. System class plugins are run against the entire system, whereas user class plugins are run against each user profile selected by the analyst. Based on the specific artifacts that I'm looking for, a system class plugin is exactly what I need.
What follows is an excerpt of the output from the ie_stats.pl plugin. First, the Administrator account profile:
g:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size : 163840
Hash Table Offset : 0x5000
Number of blocks : 1152
Number of alloc. blocks: 1089
Dir: LPVS8JVQ Files: 90
Dir: IR1PLUTE Files: 89
Dir: 5K3JMTA3 Files: 88
Dir: O3VB95DY Files: 89
As you can see, the Administrator account has some browser history associated with it. The hash table is located at offset 0x5000 within the index.dat file, and there are four subdirectories, each containing a number of cache files.
g:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size : 32768
Hash Table Offset : 0x0
Number of blocks : 128
Number of alloc. blocks: 32
Dir: O8WMK2SC Files: 0
Dir: UAAUTN4C Files: 0
Dir: Q323MBYB Files: 0
Dir: 4VRPMD81 Files: 0
Okay, so this is what an empty index.dat looks like; the Default User profile has no IE history associated with it...there is no hash table, and the subdirectories don't contain any files.
g:\Documents and Settings\NetworkService\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size : 9437184
Hash Table Offset : 0x5000
Number of blocks : 73600
Number of alloc. blocks: 58784
Dir: EIQLTWH3 Files: 384
Dir: KFSPU8SK Files: 384
Dir: ABR75H1M Files: 384
Dir: 5QI7EWW7 Files: 384
Dir: TTYX5IX2 Files: 384
Dir: 5GDCH3XG Files: 383
Dir: KZZXKXWH Files: 383
Dir: LA2SZ5HL Files: 383
Dir: TLRE11UL Files: 383
Dir: IYT9OTGD Files: 383
Dir: 58I9EM25 Files: 383
....
The NetworkService account was the one that set off alarms! As you can see, this profile has a significant history! Parsing the actual index.dat file and displaying the entries in a micro-timeline (just the URL records) illustrated a significant amount of activity in a relatively short amount of time, with more URLs being requested per second than most users are capable of typing in or clicking via the browser.
In this case, I used the command line version of the Forensic Scanner to run a single plugin. I had mounted the image file via FTK Imager, and it appeared on my system as the G:\ volume. I then typed the following command:
C:\Perl\scanner>fscan.pl -s g:\windows\system32 -p ie_stats
That's all it took. Again, this is NOT a comprehensive analysis...this is a quick check to see if I could expect any potential issues. Another way to run this would be to select the "malware" artifact category...the ie_stats.pl plugin is included in that category. Also, the purpose of running this plugin is NOT to find indications of browser activity, for all browsers, and for all users. Instead, the purpose of this plugin is to check for something very specific...it does so automatically, accurately, and very, very quickly. This entire exercise took only a couple of minutes, most of which was spent mounting the image file...once that was done, the plugin ran very quickly, and provided me with the information I needed. I don't want to list all of the URL and REDR records from the NetworkService profile index.dat because just from what we see above (not all of the directories are listed) there are around 4000 or so files in the cache subdirectories.
Again, the purpose of this blog post is to illustrate an analysis technique. In the past, what I've done is to use ProDiscover to populate the "Internet History View" from within the image, and look for indications of service accounts with URL records in their index.dat. However, the methodology used by ProDiscover is more comprehensive...it searches the entire file system, and parses all of the records out of each index.dat file that it finds. In this case, that's much more than what I'm looking for.
This analysis technique can be combined with other tools into a more comprehensive process, as described in this blog post. Parsing application prefetch (*.pf) files and finding indications of wininet.dll as one of the loaded modules might be something to correlate with this analysis technique.
Resources
Rob Hensing's post on the Default User with an IE browser history
ForensicsWiki page: IE History File Format
Extremely relevant post from Hogfly (2007)
Thursday, March 07, 2013
Wow6432Node: Registry Redirection
What is Registry redirection?
MS has a nice little explanation of Registry redirection and reflection here. Note that this MS page indicates that Registry reflection was removed as of Windows 7 and Windows 2008 R2.
In short, when a 32-bit application makes a call to write to the Registry on a 64-bit Windows system, by default, it doesn't go where we expect. A number of years ago, I was performing analysis of a 64-bit Windows 2003 server that we thought had been compromised via SQL injection...only I couldn't find the instance of the MS SQL Server listed in the Software hive. It turns out that I had to look beneath the Wow6432Node key
This page at MS provides information regarding Registry keys affected by Wow64.
What does it mean to us?
Well, for one...this is huge. No, I mean, it's HUGE. H. U. G. E. Why is that? Well, most of the malware I've seen over the years has been compiled for 32-bit platforms. While I haven't seen many 64-bit XP and 2003 systems (I have seen a few), I have seen a number of 64-bit Windows 7 systems, and all of the Windows 2008 R2 systems I've analyzed have been 64-bit.
So, if you're looking in the usual locations for malware...say, the Software\Microsoft\Windows\CurrentVersion\Run key, in either the HKLM or HKCU hives...then you're only going halfway and potentially missing a great deal of critical data in the Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run key. And unfortunately, most of us seem to be only going halfway.
This should be nothing new to the DFIR community. Redirection and virtualization of the Registry were discussed on pp 246 and 247, respectively, in Windows Forensic Analysis 2/e (published in 2009), as well as on pg 132 of WFAT 3/e. This topic is also discussed in this blog post.
Elizabeth S., from Google, discussed the Run keys extensively in her presentation at the 2012 SANS Forensic Summit. You'll notice that if you read through the presentation, she culled a lot of data about Registry keys from an AV vendor site. It appears that most of the testing platforms used by the vendor may be 32-bit, which may be why the Wow6432Node key isn't mentioned.
A good number of the RegRipper plugins that are affected by Registry redirection have been (or are being) updated to support Wow6432Node (where applicable, of course), and Corey Harrell has identified several others that need to be updated, as well. We're working on getting updated plugins into a new public distribution, so please bear with us.
Note that similar differences apply to the file system, as well, due to redirection. For example, on 64-bit systems, 32-bit applications can be found in the C:\Program Files (x86) and C:\Windows\SysWOW64 folders.
Resources
SamLogic.net article
Windows Confidential article
MS has a nice little explanation of Registry redirection and reflection here. Note that this MS page indicates that Registry reflection was removed as of Windows 7 and Windows 2008 R2.
In short, when a 32-bit application makes a call to write to the Registry on a 64-bit Windows system, by default, it doesn't go where we expect. A number of years ago, I was performing analysis of a 64-bit Windows 2003 server that we thought had been compromised via SQL injection...only I couldn't find the instance of the MS SQL Server listed in the Software hive. It turns out that I had to look beneath the Wow6432Node key
This page at MS provides information regarding Registry keys affected by Wow64.
What does it mean to us?
Well, for one...this is huge. No, I mean, it's HUGE. H. U. G. E. Why is that? Well, most of the malware I've seen over the years has been compiled for 32-bit platforms. While I haven't seen many 64-bit XP and 2003 systems (I have seen a few), I have seen a number of 64-bit Windows 7 systems, and all of the Windows 2008 R2 systems I've analyzed have been 64-bit.
So, if you're looking in the usual locations for malware...say, the Software\Microsoft\Windows\CurrentVersion\Run key, in either the HKLM or HKCU hives...then you're only going halfway and potentially missing a great deal of critical data in the Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run key. And unfortunately, most of us seem to be only going halfway.
This should be nothing new to the DFIR community. Redirection and virtualization of the Registry were discussed on pp 246 and 247, respectively, in Windows Forensic Analysis 2/e (published in 2009), as well as on pg 132 of WFAT 3/e. This topic is also discussed in this blog post.
Elizabeth S., from Google, discussed the Run keys extensively in her presentation at the 2012 SANS Forensic Summit. You'll notice that if you read through the presentation, she culled a lot of data about Registry keys from an AV vendor site. It appears that most of the testing platforms used by the vendor may be 32-bit, which may be why the Wow6432Node key isn't mentioned.
A good number of the RegRipper plugins that are affected by Registry redirection have been (or are being) updated to support Wow6432Node (where applicable, of course), and Corey Harrell has identified several others that need to be updated, as well. We're working on getting updated plugins into a new public distribution, so please bear with us.
Note that similar differences apply to the file system, as well, due to redirection. For example, on 64-bit systems, 32-bit applications can be found in the C:\Program Files (x86) and C:\Windows\SysWOW64 folders.
Resources
SamLogic.net article
Windows Confidential article
Tuesday, February 19, 2013
BinMode: Understanding Data Structures
As most analysts are aware, the tools we use provide a layer of abstraction over the data with which we're engaged. What we see can often depend upon the tool that we're using. For example, if a tool is written by a developer and the intended user is an administrator, then while the tool may be useful to a DFIR analyst, it may not provide all of the information that is truly useful to that analyst, based on the goals of their examination, the data that's actually presented by the tool, etc.
This is why understanding the data structures that we're working with can often be very beneficial.
By understanding what is actually available in the data structures, we can:
1. Make better use of the information that is available.
2. Locate deleted data in unallocated space (or other unstructured data)
A good recent example of this is the discussion of Java *.idx files, and the resulting parsers that have been created. Understanding the actual data structures that make up the headers and subsequent sections of these files lets us understand what we're looking at. For example, for a successful download, the header contains a field that tells us the size of the content. Most legitimate downloads also include this information in the server response, but malicious downloads of Java content don't always include this information. As such, we have not only have a good way for determining what may be a suspicious download, but we also have a pivot point we can use...we can use the content size to look for files of that size that were created on the system.
Another example of this is the IE history file format (thanks to Joachim for all the work he's done in documenting the format). A lot of analysts run various tools to parse out the user's IE web browser history, but how many understand what's actually in the structure? I'm not saying that you've memorized it and parse everything by hand, but rather that you know enough about it at least be curious when something is missing. For example, according to Joachim's documentation, each "URL" record can contain multiple time stamps, including when the page requested was last modified, last sync'd, and when it expires. I say "can" because in some cases, these may be set to 0. Further, according to the documentation, there's a flag setting that we can use to determine if the HTTP request was a GET or POST request.
How else can this be helpful? Mandiant's recently released APT intel report provides a great deal of useful information, including references to "wininet" on page 31. The WinInet API is what produces the artifacts most commonly associated with IE. As such, if your organization uses Firefox or Chrome, rather than IE, or you see that the "Default User", "NetworkService", or "LocalService" profiles begin developing quite large IE histories, this may be an indicator of activity.
I've used the documented format for Windows XP and 2003 Event Log records to not only parse the Event Log files on a system, but also locate and recover deleted event records from unallocated space. In fact, I had an instance where the intruder had cleared the Security Event Log after gaining access to the system, but I was able to recover 334 deleted event records from unallocated space, including the record that showed when they'd initially logged into the system.
Addendum, 20 Feb: I've mentioned DOSDate format time stamps in this blog before, as well as the data structures in which they're used (shell items in shellbag artifacts, ComDlg32 Registry subkey values, LNK files, Jump Lists, etc.). They're very pervasive across all Windows platforms, and more so on Windows 7 systems. This MS link provides some information regarding how these time stamps are constructed, as well as how they can play havok with timeline analysis if you're not familiar with them.
This doesn't apply just to Windows systems. A great example of this is Mari's recent blog post, Finding and Reverse Engineering Deleted SMS Messages. Mari provides a complete walk-thru of the data source being examined, going so far as to not only identify the data structure, but to also demonstrate how she did this, as well as to show how someone could go about identifying deleted SMS messages.
What's really interesting is that back in the day, there used to be more of a focus on understanding data structures. For example, some DF training programs would require candidates to parse partition tables and compute NTFS MFT data runs.
This is why understanding the data structures that we're working with can often be very beneficial.
By understanding what is actually available in the data structures, we can:
1. Make better use of the information that is available.
2. Locate deleted data in unallocated space (or other unstructured data)
A good recent example of this is the discussion of Java *.idx files, and the resulting parsers that have been created. Understanding the actual data structures that make up the headers and subsequent sections of these files lets us understand what we're looking at. For example, for a successful download, the header contains a field that tells us the size of the content. Most legitimate downloads also include this information in the server response, but malicious downloads of Java content don't always include this information. As such, we have not only have a good way for determining what may be a suspicious download, but we also have a pivot point we can use...we can use the content size to look for files of that size that were created on the system.
Another example of this is the IE history file format (thanks to Joachim for all the work he's done in documenting the format). A lot of analysts run various tools to parse out the user's IE web browser history, but how many understand what's actually in the structure? I'm not saying that you've memorized it and parse everything by hand, but rather that you know enough about it at least be curious when something is missing. For example, according to Joachim's documentation, each "URL" record can contain multiple time stamps, including when the page requested was last modified, last sync'd, and when it expires. I say "can" because in some cases, these may be set to 0. Further, according to the documentation, there's a flag setting that we can use to determine if the HTTP request was a GET or POST request.
How else can this be helpful? Mandiant's recently released APT intel report provides a great deal of useful information, including references to "wininet" on page 31. The WinInet API is what produces the artifacts most commonly associated with IE. As such, if your organization uses Firefox or Chrome, rather than IE, or you see that the "Default User", "NetworkService", or "LocalService" profiles begin developing quite large IE histories, this may be an indicator of activity.
I've used the documented format for Windows XP and 2003 Event Log records to not only parse the Event Log files on a system, but also locate and recover deleted event records from unallocated space. In fact, I had an instance where the intruder had cleared the Security Event Log after gaining access to the system, but I was able to recover 334 deleted event records from unallocated space, including the record that showed when they'd initially logged into the system.
Addendum, 20 Feb: I've mentioned DOSDate format time stamps in this blog before, as well as the data structures in which they're used (shell items in shellbag artifacts, ComDlg32 Registry subkey values, LNK files, Jump Lists, etc.). They're very pervasive across all Windows platforms, and more so on Windows 7 systems. This MS link provides some information regarding how these time stamps are constructed, as well as how they can play havok with timeline analysis if you're not familiar with them.
This doesn't apply just to Windows systems. A great example of this is Mari's recent blog post, Finding and Reverse Engineering Deleted SMS Messages. Mari provides a complete walk-thru of the data source being examined, going so far as to not only identify the data structure, but to also demonstrate how she did this, as well as to show how someone could go about identifying deleted SMS messages.
What's really interesting is that back in the day, there used to be more of a focus on understanding data structures. For example, some DF training programs would require candidates to parse partition tables and compute NTFS MFT data runs.
Training
Interested in Windows DFIR training? Windows Forensic Analysis, 11-12 Mar; Timeline Analysis, 9-10 Apr. Pricing and Calendar. Send email here to register. Each course includes access to tools and techniques that you won't find anywhere else, as well as a demonstration of the use of the Forensic Scanner.
On 10-12 June 2013, a Windows Forensic Analysis and Registry Analysis combo course will be hosted at the Santa Cruz PD training facility.
Course descriptions and other info on the courses is available here. Pricing for the combo course is $749 per seat, and will be listed on the ASI training page shortly.
Course descriptions and other info on the courses is available here. Pricing for the combo course is $749 per seat, and will be listed on the ASI training page shortly.
Saturday, February 16, 2013
Java, Timelines, and Training
A lot of interesting things have gone on lately...and I'm sure that there's more to come. I thought I'd take a moment to raise awareness of some of what happened recently,
Java In The News
Corey posted some links to tools the other day over on the jIIr blog. In the blog post, he talks about IDX parsers...not long ago, there was a flurry of activity around Java deployment cache index (*.idx) files, and what was contained in them.
You can find my IDX parsing code here. I updated it recently to support a variant to version 605 index files that I happened to see (that's one of the things I love about open source....).
Okay, so what's the big deal with this stuff? Is it just the "flavor-of-the-week" when it comes to DFIR analysis? I wouldn't think so...in fact, I'd suggest that if you do any sort of work with respect to malware or intrusion/compromise analysis, I would suggest to you that this is a pretty big deal. In fact, it's likely that anyone doing any sort of DFIR analysis is going to run up against this at some point...you may not recognize it at first, but it's likely to be there.
Remember this graphic from the SANS Forensic blog post from last year? Right in the middle of the super timeline, there are two *.idx files being created. This is from last year...during a recent examination, I added the metadata extracted from *.idx files to my own timeline, because the infection routine started with Java being run. I discuss that a little bit below.
Did anyone see this article recently? Java exploit? Yeah, apparently, that's what it was. I'd bet that the systems that were examined had some pretty interesting *.idx files on them.
I would suspect that as awareness of these artifacts are raised, analysts will begin to recognize that it's now easier to perform a root cause analysis, and to determine the initial infection vector. IMHO, the primary reason why this isn't done more often is because most assume that it takes too long to do an investigation; however, in not performing these investigations, we're missing out on a great deal of value information and intelligence that we can use to better protect our infrastructures.
Timeline Analysis
As I mentioned above, I used my own *.idx parser to add information from these files to a timeline...and this really helped my analysis.
First, as I do sometimes, I parsed the data separately and created a mini-timeline from just the data from the *.idx files. I do this, because in a full timeline, any times that data just gets lost. Now, I could have done something like created the events file, and then pulled out the information for the *.idx files using the type command, and piping that through find. Either way works.
Doing this showed me quite a bit about what the user likes to do during the day. I think what was most revealing about this data was that it made clear how much Java is used on the Internet. In a way, it was kind of fascinating, but at the same time, this didn't have much of anything to do with analysis goals. The fact was that while my timeline showed modifications to several cache directories when the system was being infected, what I did not see was the *.idx files that should have been part of the infection process.
One of the things I teach in my courses is that we need to understand artifacts so that you can not only recognize what's there, but so that you can also see when something that should be there isn't...and I had just such a case recently. There were a couple of possibilities as to what I was seeing, and one thing I found was that the installed AV had detected the malware; it quarantined the malware (i.e., created a file in the Quarantine directory) but the AV logs also stated quite clearly that (a) it was unable to remove the files from their original location, and (b) the AV software could not alert the user (notifications were disabled). Unfortunately, the logs did not go back all the way to the date of the infection, so I could not determine if the AV had actually detected the malware when it was installed, or if the detection I was seeing in the logs was a result of a product update that occurred after the infection. However, I did see that a file with the extension ".idx" had been created in the Quarantine folder, and had since been deleted. That wasn't definitive, but it was possible that the AV product had found something malicious in at least one *.idx file and had quarantined it. This would definitely account for the modification that occurred to the cache folder during the infection routine.
So, from the data I was looking at, there were two possibilities...one was that the AV had detected the infection, and while it was able to remove some of the files, it was unable to remove the actual malware itself...and since most AV products do nothing about the malware persistence mechanisms, the malware remained active (as confirmed by other artifacts).
The other possibility was that during the infection process, the malware "cleaned up" behind itself. After all, right there in the timeline, I could see that during the infection process, the Security Center was disabled, and the malware disabled the mechanism it used to gain access to the system. This was a multiple-stage infection...it started with Java via IE, downloaded something that ran and created files on the system. The second stage .exe file was deleted, but there were plenty of artifacts on the system that clearly showed not only that it had run, but also under what user context it had run. And it was clear that the infection process had also closed off the first stage of the infection.
So, there were some interesting findings in the analysis...all of the above was determined within the first 6 hours of analysis. As analysts, however, we're finders of fact, facts that we base and the data that I did have available had me leaning more toward the first possibility than the second. But the fact is that using these techniques, I had enough data to clearly identify not just the facts, but the gaps, as well.
Addendum: After my initial post, I saw this post at the KrebsOnSecurity blog, and this one on disabling Java for the browser on the Sophos site. Within minutes, I had written a RegRipper plugin to extract the UseJava2IExplorer value.
Resources
One of my own blog posts on the topic
ForensicsWiki Java Page
Mark Woan's format specification document
Training
Interested in Windows DFIR training? Windows Forensic Analysis, 11-12 Mar; Timeline Analysis, 9-10 Apr. Pricing and Calendar. Send email here to register. Each course includes access to tools and techniques that you won't find anywhere else, as well as a demonstration of the use of the Forensic Scanner.
On 10-12 June 2013, a Windows Forensic Analysis and Registry Analysis combo course will be hosted at the Santa Cruz PD training facility.
Course descriptions and other info on the courses is available here. Pricing for the combo course is $749 per seat, and will be listed on the ASI training page shortly.
Course descriptions and other info on the courses is available here. Pricing for the combo course is $749 per seat, and will be listed on the ASI training page shortly.
Wednesday, February 13, 2013
Hosted Training
On 10-12 June 2013, a Windows Forensic Analysis and Registry Analysis
combo course will be hosted at the Santa Cruz PD training facility.
Course descriptions and other info on the courses is available here. Pricing information for the combo course will be available on the ASI training page shortly.
If you are interested in registering for a seat in the training, please contact me here. As the date of the course approaches, information regarding parking, what to bring, etc., will be provided.
Course descriptions and other info on the courses is available here. Pricing information for the combo course will be available on the ASI training page shortly.
If you are interested in registering for a seat in the training, please contact me here. As the date of the course approaches, information regarding parking, what to bring, etc., will be provided.
Wednesday, February 06, 2013
There Are Four Lights: The Forensic Scanner
I made a push recently via social media to raise awareness about the Forensic Scanner, and based on some of what I saw come back, I'd like to take a moment to describe what the Forensic Scanner is, and perhaps clear us some misconceptions about the tool.
Just a quick reminder to everyone...in Nov, 2012, the Forensic Scanner moved from the Google Code site to this GitHub site. If you're going to try the Forensic Scanner, make sure that you run it as Administrator...if you have an admin account and you still have UAC enabled, you won't have what you think are full Admin rights on the box. Check out Corey's blog post on the topic.
First off, the Forensic Scanner is just a tool, nothing more. Like any other tool, if you don't understand how it was designed to be used, you very likely won't be using it to it's full capacity, or in it's most effective manner. Scanner applications have been used in various segments of infosec for quite some time. When I did vulnerability assessments back in the late '90s, we used scanner products to do some of the heavy lifting. Even today, there are scanners available for web app assessments, but the key point to remember is that these applications are not intended to replace analysts, or remove analysts from the picture. Instead, they are intended to perform a wide range of repeatable tests, so that an analyst can review the results and then focus their analysis efforts. This is also the intention of the Forensic Scanner.
The Forensic Scanner is:
A library of corporate knowledge/intel: An analyst may spend 8, 16, 24 hours or more in analysis and find something new. Take this finding, for example. One way to address a finding like this is for the analyst to keep it to himself...but that doesn't really help anyone, does it? An alternative might be to hold a brown-bag lunch with other analysts, put together a PPT, and tell them what you found. But how much more useful would it be to write a plugin, and share it with the other analysts? Within a few minutes, other analysts would have full access to the capability (i.e., finding the issue, or not...) without ever having to have the same experiences as the first analyst. On a team of eleven analysts, if it took 16 hours for the first analyst to find the issue, you've just saved the team, as a whole, 16 hrs x 10 analysts = 160 hours of time. This time can mean a great deal to your customer, as you will be providing with information they need to make critical business decisions in an extremely efficient manner.
By creating and maintaining plugins for these findings, the information is maintained in an accessible manner while the examiner who found the artifact is on vacation, or well after they left the organization. With the proper oversight, the plugin won't simply have lines of code...it will include references and explanations, so that the findings are not only repeatable, but they can be easily understood and explained.
How are you at memorizing the paths to various web browser history files on different versions of Windows (i.e., XP vs Windows 7)? How are you at mapping USB device usage? Do you want to have that available at the push of a button? That's what the Forensic Scanner can give you.
A force multiplier: By looking back at your last engagement and creating or updating plugins based on your findings, and then providing them to the team, you've bridged the gap between a checklist and actually implementing the checklist. This allows the experience of each analyst to be shared with others, which can lead to more work being done by the same number of analysts, in a much more efficient and timely manner.
A path to a competitive advantage: Analysts are going to find things that others either don't see, or haven't seen yet. As such, writing a plugin that you keep private within your team can lead to providing better, more comprehensive results to your customers, in a more timely manner. Based on the plugins you have in your library, you may be able to determine not only the malware that infected a system, but also determine the initial infection vector, in a much more timely manner. This means that you can provide not just findings, but intelligence to your customer, that they can then use to protect themselves.
The Forensic Scanner is NOT intended to replace any of the current tools that you own and use. Rather, the purpose of the Forensic Scanner is to augment and optimize your use of those tools that you already own, and get you to the point of deep engagement with those tools much sooner.
Deployment Scenarios
When I first had the idea for the Forensic Scanner,
Lab Tech: A lab tech receives an image, and as part of the verification and in-processing procedures, runs a scan of the mounted image. The lab tech then contacts the designated analyst to let her know that the image and report are in a specific location, either in the "cloud", or to be retrieved in some other manner. Rather than having to run through all of the checks herself, the examiner can review the report and focus her analysis faster, providing much more comprehensive and timely findings.
LE examiner: An LE examiner might be interested in P2P file sharing, and one of the biggest issues for LE (at all levels) is that the examiners are cops first. This makes it very difficult to keep up on various analysis techniques and artifacts, but the Forensic Scanner puts that right at your fingertips. Perhaps your cases involving illicit images don't require you to do much more than find and catalog the images, and you're done. Or perhaps you need more...did the user actually access the images at any point? Did the transfer of the files involve a USB storage device of any kind? Was a digital camera or a smartphone connected to the system?
Consultant: A consultant or even an IT security staff member can be on-site, performing triage and acquisitions. They can run a report, and because the report contains no sensitive (PII, PHI, PCI, etc.) information, they can archive/protect the report, and ship it off to another analyst who is off-site, who can then perform analysis of the report. The analyst can then respond to the on-site consultant, providing information that can then help them focus their efforts ("..acquire these 5 systems instead of all 300...").
Interested in Windows DFIR training? Windows Forensic Analysis, 11-12 Mar; Timeline Analysis, 9-10 Apr. Pricing and Calendar. Send email here to register. Each course includes access to tools and techniques that you won't find anywhere else, as well as a demonstration of the use of the Forensic Scanner.
Just a quick reminder to everyone...in Nov, 2012, the Forensic Scanner moved from the Google Code site to this GitHub site. If you're going to try the Forensic Scanner, make sure that you run it as Administrator...if you have an admin account and you still have UAC enabled, you won't have what you think are full Admin rights on the box. Check out Corey's blog post on the topic.
First off, the Forensic Scanner is just a tool, nothing more. Like any other tool, if you don't understand how it was designed to be used, you very likely won't be using it to it's full capacity, or in it's most effective manner. Scanner applications have been used in various segments of infosec for quite some time. When I did vulnerability assessments back in the late '90s, we used scanner products to do some of the heavy lifting. Even today, there are scanners available for web app assessments, but the key point to remember is that these applications are not intended to replace analysts, or remove analysts from the picture. Instead, they are intended to perform a wide range of repeatable tests, so that an analyst can review the results and then focus their analysis efforts. This is also the intention of the Forensic Scanner.
The Forensic Scanner is:
A library of corporate knowledge/intel: An analyst may spend 8, 16, 24 hours or more in analysis and find something new. Take this finding, for example. One way to address a finding like this is for the analyst to keep it to himself...but that doesn't really help anyone, does it? An alternative might be to hold a brown-bag lunch with other analysts, put together a PPT, and tell them what you found. But how much more useful would it be to write a plugin, and share it with the other analysts? Within a few minutes, other analysts would have full access to the capability (i.e., finding the issue, or not...) without ever having to have the same experiences as the first analyst. On a team of eleven analysts, if it took 16 hours for the first analyst to find the issue, you've just saved the team, as a whole, 16 hrs x 10 analysts = 160 hours of time. This time can mean a great deal to your customer, as you will be providing with information they need to make critical business decisions in an extremely efficient manner.
By creating and maintaining plugins for these findings, the information is maintained in an accessible manner while the examiner who found the artifact is on vacation, or well after they left the organization. With the proper oversight, the plugin won't simply have lines of code...it will include references and explanations, so that the findings are not only repeatable, but they can be easily understood and explained.
How are you at memorizing the paths to various web browser history files on different versions of Windows (i.e., XP vs Windows 7)? How are you at mapping USB device usage? Do you want to have that available at the push of a button? That's what the Forensic Scanner can give you.
A force multiplier: By looking back at your last engagement and creating or updating plugins based on your findings, and then providing them to the team, you've bridged the gap between a checklist and actually implementing the checklist. This allows the experience of each analyst to be shared with others, which can lead to more work being done by the same number of analysts, in a much more efficient and timely manner.
A path to a competitive advantage: Analysts are going to find things that others either don't see, or haven't seen yet. As such, writing a plugin that you keep private within your team can lead to providing better, more comprehensive results to your customers, in a more timely manner. Based on the plugins you have in your library, you may be able to determine not only the malware that infected a system, but also determine the initial infection vector, in a much more timely manner. This means that you can provide not just findings, but intelligence to your customer, that they can then use to protect themselves.
The Forensic Scanner is NOT intended to replace any of the current tools that you own and use. Rather, the purpose of the Forensic Scanner is to augment and optimize your use of those tools that you already own, and get you to the point of deep engagement with those tools much sooner.
Deployment Scenarios
When I first had the idea for the Forensic Scanner,
Lab Tech: A lab tech receives an image, and as part of the verification and in-processing procedures, runs a scan of the mounted image. The lab tech then contacts the designated analyst to let her know that the image and report are in a specific location, either in the "cloud", or to be retrieved in some other manner. Rather than having to run through all of the checks herself, the examiner can review the report and focus her analysis faster, providing much more comprehensive and timely findings.
LE examiner: An LE examiner might be interested in P2P file sharing, and one of the biggest issues for LE (at all levels) is that the examiners are cops first. This makes it very difficult to keep up on various analysis techniques and artifacts, but the Forensic Scanner puts that right at your fingertips. Perhaps your cases involving illicit images don't require you to do much more than find and catalog the images, and you're done. Or perhaps you need more...did the user actually access the images at any point? Did the transfer of the files involve a USB storage device of any kind? Was a digital camera or a smartphone connected to the system?
Consultant: A consultant or even an IT security staff member can be on-site, performing triage and acquisitions. They can run a report, and because the report contains no sensitive (PII, PHI, PCI, etc.) information, they can archive/protect the report, and ship it off to another analyst who is off-site, who can then perform analysis of the report. The analyst can then respond to the on-site consultant, providing information that can then help them focus their efforts ("..acquire these 5 systems instead of all 300...").
Interested in Windows DFIR training? Windows Forensic Analysis, 11-12 Mar; Timeline Analysis, 9-10 Apr. Pricing and Calendar. Send email here to register. Each course includes access to tools and techniques that you won't find anywhere else, as well as a demonstration of the use of the Forensic Scanner.
Subscribe to:
Posts (Atom)