My Twitter account lit up with the "#HTCIACON" hash tag this passed Monday morning, apparently due to the HTCIA Conference. I was seeing a lot of tweets from HBGary, etc., so I went by the conference web page and took a look at the agenda. As you can imagine, anything with the word "Registry" in it catches my eye immediately, and I saw that there was a lab that had to do with "network artifacts in the Registry". I took a look at the abstract for the lab, and it seemed to focus on the NetworkList key in the Vista+ Registry...that's great for showing wired and wireless networks that a system has connected to, as well as providing some useful information that can be used in WiFi geolocation (discussed here, updated tool named "macl.pl" is here).
This is a great start, but what about after the system is connected to particular networking media? What other "network artifacts" can be found in the Registry? That's where we can dig into additional sources of information, specifically other Registry keys and values, to look for those additional network artifacts.
Something else to think about is, what if some of the artifacts that you're pursuing have been deleted? Some tools (CCleaner, etc.) will "erase" lists of known artifacts. Some tools, such as USB Oblivion, are targeted to more specific artifacts. As such, knowing more about the artifacts or artifact categories that you're interested in will help you determine (a) if some sort of "cleaning" has likely occurred, and (b) provide you with other indicators that you might be able to pursue.
This information can be useful in cases involving violations of acceptable use policies within organizations; however, they are not specifically restricted to such cases. I've used these artifacts in a number of intrusion cases, particularly where the compromised system was accessed remotely via RDP.
Here are some of the RegRipper plugins you can use to collect some other network artifacts, primarily from the user's hives:
networklist.pl - The networklist.pl plugin gives me what was described in the abstract for the conference lab I mentioned; network profile, first/last connection date (in SYSTEMTIME format, based on the system's localtime), gateway MAC address, and the network type (wired, wireless, broadband). The TLN version of this plugin will allow you to incorporate this information into your timeline.
shellbags.pl - As I mentioned previously, shellbags can provide a great deal of information regarding access to network resources; you might not only find indications of access to UNC paths, but also the use of Windows Explorer to access FTP resources (my publisher used to have me do this in order to transfer chapters...). I should note that I've found entries such as these during exams. If you do find information regarding access to FTP in the user's shellbags, you might also want to check out the Software\Microsoft\FTP\Accounts subkeys within the user hive, as well...not only will you find the host connected to, as well as the username used to access the site (if successful).
muicache.pl - If the user uses the command line FTP utility that is native to Windows (ftp.exe), rather than Windows Explorer, to access an FTP site, you may find a reference to that executable in the user's MUICache key (in Windows 7, located in the USRCLASS.DAT hive). Of course, if another GUI FTP client was used, you might expect to find information about that usage via the userassist.pl plugin.
mndmru.pl - This plugin parses the users "Map Network Drive MRU" key data, showing the network drives that the user has mapped via the Map Network Drive Wizard.
runmru.pl - A user may decide to click the Start button, and then simply type a UNC path into the "Run:" box; this information will be available via the runmru.pl plugin.
typedpaths.pl - The TypedPaths key maintains a history of the locations typed into the Windows Explorer Address Bar; similar to the RunMRU key, a user can type UNC paths to network resources into this location.
tsclient.pl - If the user accesses other systems via RDP, you will find references to those connections in the Software\Microsoft\Terminal Services Client subkeys, specifically beneath the Default and Servers subkeys. Of course, if you do find indications of off-system communications via this key, and you're analyzing a Windows 7 system, be sure to include the user Jump Lists in your analysis, as well.
There are also application-specific Registry entries to consider, as well. For example, the vncviewer.pl plugin is in version 20080325 at the moment, which means that it was originally written almost 4 1/2 years ago.
Are there any other network artifacts within the Registry that you might be interested in that aren't covered here? If so, let me know, or comment here.
The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics", as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".
Pages
▼
Tuesday, September 18, 2012
Monday, September 17, 2012
News
Tools
Autopsy v3 is in beta...check it out here. There are lots of screenshots, so if you're looking for a free, open source alternative to commercial analysis frameworks, take a look. Also, consider DFF, another useful framework (discussed in DFwOST) to help get you started in analysis, or to use side-by-side with your other tools in order to validate what you're seeing. If you're in Chantilly, VA, during the first week of Oct, be sure to sign up for OSDFC; it looks like Brian's going to be talking about Autopsy there.
Speaking of open source tools, Volatility has really taken off, with the establishment of the Volatility Labs blog, as well as month of Volatility Plugins (MoVP). In the month of September alone, there have been half a dozen or so posts. I really like how the descriptions of the plugins are laid out, as each provides several sections, including the Effects on Forensics, a description of what the plugin helps reveal. What I really like about this is that too often, in our age of "social" media, too many times, simply linking to something, or clicking "Like" or "Favorite" or retweeting something means that we miss out on the valuable insight that could easily be provided. Good on the folks from Volatility for contributing to the growth of the community in more ways than simply providing a tool to make memory collection and analysis achievable, for a variety of platforms.. To see more of what these folks bring to the table, be sure to check out the Open Memory Forensics Workshop prior to OSDFC, albeit a short distance from the OSDFC venue; OMFW is a half-day conference on 2 Oct, in Chantilly, VA, with presentations by some of the big names (and big heads!!) in memory forensics.
If you're not sure about using Volatility for analysis, check out the SemperSecurus post regarding using Volatility to analyze the Cridex malware. In the post, Andre refers to a number of the useful Volatility commands for extracting information from a memory dump.
If you're using Volatility, or want to, be sure to check out MemGator, for memory sample automated extraction and HTML reporting. According the write-up, MemGator is also capable of extracting TrueCrypt keys. If you do have access to a memory dump from a supported OS, this is a great tool to run through that dump through initial processing, before you move on to more targeted analysis.
Blogosphere
Christian Buia has an interesting EMC blog post where he discusses threat actor's lateral movement within an infrastructure via the Task Scheduler.
The latest rendition of the jobparse.pl Perl code that I wrote, which Christian mentions in the post, can be found here, and Jamie's Python tool is discussed here.
Christian's blog post is very valuable to the community, as there have been a number of times (such as at the DC3 conference last January) where presenters have stated that "..lateral movement was used...", but don't go beyond that; I heard several attendees lament this fact, because without knowing what this "looks like", how would they find it within their infrastructure. Christian gives an example of what this can "look like" within the infrastructure. Some things you might find via host-based analysis would be indications of the use of at.exe on the primary node (Prefetch file, etc.), and artifacts of a Scheduled Task having been run on the secondary node (Windows Event Log entries, Scheduled Task logs, etc.). Now, this is not the only means of lateral movement that can be used; there is also psexec and it's variants, as well.
Sploited has some updates to TLN tools, which is pretty cool. So far, three tools have been posted on the Google Code site for the project. I haven't tried these tools yet, but I am looking for an opportunity to do so soon. This is a great example of how someone in our industry sees a need and decides to step up and fill it...too many times, I think that many of us are hesitant to do so much as express a need...I'm not saying sit down and learn to program, I'm saying simply express a need..."...it would be useful to have X." After all, most of the folks in the community, from the Volatility crew to the person who writes a DOS batch file to tie RegRipper rip.exe commands together all start that way.
Windows 8 is more than on it's way out...check out Claus's Windows 8 Linkage post to see some of the new stuff available.
Threat Intel
I found this very interesting Trend Micro write-up on the Tinba banking trojan, said to be the "smallest", as it reportedly weighs in at 20KB. Write-ups like these can often provide a great deal of threat intelligence, but they can also sometimes fall a bit short with respect the amount of intelligence that can be derived from them and used within your own infrastructure. I don't think that this is necessarily an intentional omission; rather, I think that in most cases, it's due to the perspective of the organization (in this case, an AV vendor), as well as the analyst(s) performing the actual analysis (malware RE folks). What I mean by that is that if you're a reverse engineer who's really good at using a debugger and analyzing memory, your analysis is going to be slanted in that direction. Very often what I try to do is read between the lines and see what isn't said, and what host-based artifacts should be there that aren't discussed, so that the information provided can be used as part of a root cause analysis.
A couple of things I found interesting within the write-up:
This malware apparently uses the user's Run key for persistence. Many sites, including Microsoft themselves, have stated this persistence mechanism allows the malware to remain persistent following a system boot...however, it is more correct to say that it allows the malware to start automatically the next time the user logs in to the system. Yes, the malware will run after a reboot, but only after that user logs in again.
Note: the write-up states that the malware creates a Registry "key" for itself; this is incorrect - it creates a Registry value beneath the Run key. This may not be a huge distinction to many, but when it comes to things like incorporating Registry data into timeline analysis, it will make a significant difference. Registry keys include embedded time stamps within their structure, referred to as the key "LastWrite" time; Registry values do not have this element in their structure.
I did not find any mention within the write-up as to which platform was used to analyze the malware; we can assume, based on a couple of the screen captures, that it was likely Windows XP, but there's no indication as to whether the platform is 32- or 64-bit. This is important to consider, because if the malware is 32-bit and infects a 64-bit system, the location of the persistence mechanism will be slightly different.
The malware also apparently modifies another Registry value that controls Internet Explorer; specifically, within the "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" key, the value "1609" is modified to 0. There is other malware out there that makes similar modifications, and MS is kind enough to provide a KB article that describes what the various values beneath these keys refer to.
Something else that the malware does is modify the user.js Firefox file within the user's profile; as there doesn't seem to be any indication of time stamp manipulation, this should show up as an "M..." entry for that file in your timeline. The modification that the malware makes apparently disables anti-phishing warnings in Firefox.
While there is some discussion of the malware communications mechanism, it mostly centers on the fact that comms are encrypted. Earlier in the write-up, the report states that the malware primarily uses 4 DLLs, one of which is ws2_32.dll. This may provide it's off-system communications capabilities, and for host-based analysts, it can tell us something else. For example, if this is the only DLL utilized for off-system communications, and others such as wininet.dll are not used, then this would tell us that we should not expect to see artifacts of the communications in the user's index.dat file, and we should probably consider spelunking into the pagefile for artifacts of communications.
Autopsy v3 is in beta...check it out here. There are lots of screenshots, so if you're looking for a free, open source alternative to commercial analysis frameworks, take a look. Also, consider DFF, another useful framework (discussed in DFwOST) to help get you started in analysis, or to use side-by-side with your other tools in order to validate what you're seeing. If you're in Chantilly, VA, during the first week of Oct, be sure to sign up for OSDFC; it looks like Brian's going to be talking about Autopsy there.
Speaking of open source tools, Volatility has really taken off, with the establishment of the Volatility Labs blog, as well as month of Volatility Plugins (MoVP). In the month of September alone, there have been half a dozen or so posts. I really like how the descriptions of the plugins are laid out, as each provides several sections, including the Effects on Forensics, a description of what the plugin helps reveal. What I really like about this is that too often, in our age of "social" media, too many times, simply linking to something, or clicking "Like" or "Favorite" or retweeting something means that we miss out on the valuable insight that could easily be provided. Good on the folks from Volatility for contributing to the growth of the community in more ways than simply providing a tool to make memory collection and analysis achievable, for a variety of platforms.. To see more of what these folks bring to the table, be sure to check out the Open Memory Forensics Workshop prior to OSDFC, albeit a short distance from the OSDFC venue; OMFW is a half-day conference on 2 Oct, in Chantilly, VA, with presentations by some of the big names (and big heads!!) in memory forensics.
If you're not sure about using Volatility for analysis, check out the SemperSecurus post regarding using Volatility to analyze the Cridex malware. In the post, Andre refers to a number of the useful Volatility commands for extracting information from a memory dump.
If you're using Volatility, or want to, be sure to check out MemGator, for memory sample automated extraction and HTML reporting. According the write-up, MemGator is also capable of extracting TrueCrypt keys. If you do have access to a memory dump from a supported OS, this is a great tool to run through that dump through initial processing, before you move on to more targeted analysis.
Blogosphere
Christian Buia has an interesting EMC blog post where he discusses threat actor's lateral movement within an infrastructure via the Task Scheduler.
The latest rendition of the jobparse.pl Perl code that I wrote, which Christian mentions in the post, can be found here, and Jamie's Python tool is discussed here.
Christian's blog post is very valuable to the community, as there have been a number of times (such as at the DC3 conference last January) where presenters have stated that "..lateral movement was used...", but don't go beyond that; I heard several attendees lament this fact, because without knowing what this "looks like", how would they find it within their infrastructure. Christian gives an example of what this can "look like" within the infrastructure. Some things you might find via host-based analysis would be indications of the use of at.exe on the primary node (Prefetch file, etc.), and artifacts of a Scheduled Task having been run on the secondary node (Windows Event Log entries, Scheduled Task logs, etc.). Now, this is not the only means of lateral movement that can be used; there is also psexec and it's variants, as well.
Sploited has some updates to TLN tools, which is pretty cool. So far, three tools have been posted on the Google Code site for the project. I haven't tried these tools yet, but I am looking for an opportunity to do so soon. This is a great example of how someone in our industry sees a need and decides to step up and fill it...too many times, I think that many of us are hesitant to do so much as express a need...I'm not saying sit down and learn to program, I'm saying simply express a need..."...it would be useful to have X." After all, most of the folks in the community, from the Volatility crew to the person who writes a DOS batch file to tie RegRipper rip.exe commands together all start that way.
Windows 8 is more than on it's way out...check out Claus's Windows 8 Linkage post to see some of the new stuff available.
Threat Intel
I found this very interesting Trend Micro write-up on the Tinba banking trojan, said to be the "smallest", as it reportedly weighs in at 20KB. Write-ups like these can often provide a great deal of threat intelligence, but they can also sometimes fall a bit short with respect the amount of intelligence that can be derived from them and used within your own infrastructure. I don't think that this is necessarily an intentional omission; rather, I think that in most cases, it's due to the perspective of the organization (in this case, an AV vendor), as well as the analyst(s) performing the actual analysis (malware RE folks). What I mean by that is that if you're a reverse engineer who's really good at using a debugger and analyzing memory, your analysis is going to be slanted in that direction. Very often what I try to do is read between the lines and see what isn't said, and what host-based artifacts should be there that aren't discussed, so that the information provided can be used as part of a root cause analysis.
A couple of things I found interesting within the write-up:
This malware apparently uses the user's Run key for persistence. Many sites, including Microsoft themselves, have stated this persistence mechanism allows the malware to remain persistent following a system boot...however, it is more correct to say that it allows the malware to start automatically the next time the user logs in to the system. Yes, the malware will run after a reboot, but only after that user logs in again.
Note: the write-up states that the malware creates a Registry "key" for itself; this is incorrect - it creates a Registry value beneath the Run key. This may not be a huge distinction to many, but when it comes to things like incorporating Registry data into timeline analysis, it will make a significant difference. Registry keys include embedded time stamps within their structure, referred to as the key "LastWrite" time; Registry values do not have this element in their structure.
I did not find any mention within the write-up as to which platform was used to analyze the malware; we can assume, based on a couple of the screen captures, that it was likely Windows XP, but there's no indication as to whether the platform is 32- or 64-bit. This is important to consider, because if the malware is 32-bit and infects a 64-bit system, the location of the persistence mechanism will be slightly different.
The malware also apparently modifies another Registry value that controls Internet Explorer; specifically, within the "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" key, the value "1609" is modified to 0. There is other malware out there that makes similar modifications, and MS is kind enough to provide a KB article that describes what the various values beneath these keys refer to.
Something else that the malware does is modify the user.js Firefox file within the user's profile; as there doesn't seem to be any indication of time stamp manipulation, this should show up as an "M..." entry for that file in your timeline. The modification that the malware makes apparently disables anti-phishing warnings in Firefox.
While there is some discussion of the malware communications mechanism, it mostly centers on the fact that comms are encrypted. Earlier in the write-up, the report states that the malware primarily uses 4 DLLs, one of which is ws2_32.dll. This may provide it's off-system communications capabilities, and for host-based analysts, it can tell us something else. For example, if this is the only DLL utilized for off-system communications, and others such as wininet.dll are not used, then this would tell us that we should not expect to see artifacts of the communications in the user's index.dat file, and we should probably consider spelunking into the pagefile for artifacts of communications.
Thursday, September 06, 2012
32-bit EXEs on a 64-bit System
Anyone who's done digital analysis of Windows systems knows that they can be pretty complex beasts to analyze. To add a little "fun" to the mix, the location of artifacts on a 64-bit Windows system will depend on whether the programs used are 32- or 64-bit programs.
Wait...what?
Now, what does all this mean? Let's say you have a copy of a malware sample, and you submit it to VirusTotal, or you already know what the malware is identified and known as to some of the various AV vendors. When you read the AV vendor write-ups on the malware, you'll notice that they very rarely identify the analysis platform used; so, if the malware uses the Run key for persistence, you might open the Software hive in a viewer and navigate to the Run key, not find any unusual entries, and then simply assume that the malware either didn't execute, or failed to completely install and run.
You should be aware that 64-bit Windows system perform redirection when it comes to 32-bit applications. What this means is that if you check the PE header of the malware file and find that it was compiled for 32-bit platforms, and the system you're analyzing is a 64-bit platform, you're going to need to look in a few additional (maybe I should say "other", instead) areas for your artifacts.
Registry redirection primarily affects the Software and NTUSER.DAT hives; there's (apparently) no "WOW6432Node" subkey in the System hive (I haven't seen one yet). As such, if malware usually uses the Run key, then you should check the Run keys in both the HLKM\Software\Microsoft\Windows\CurrentVersion and the HLKM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion paths.
Something to be aware of is that none of the RegRipper plugins available in the current archive that check the Run keys in either the Software or NTUSER.DAT hives account for redirection. I have a number of plugins in my own repository that do take this into account, and have been responsible for some pretty cool/significant finds.
Now, most times, within the file system, all we usually see with respect to redirection is that when we install 32-bit applications on a 64-bit system, we'll see a C:\Program Files directory as well as a C:\Program Files (x86) directory. However, due to file system redirection, 32-bit malware that, for example, attempts to write a file to the C:\Windows\config\systemprofile \AppData\Local folder (on a Windows 7 or Win2008R2 system), on a 64-bit system will actually write that file to the to C:\Windows\SysWOW64\config\systemprofile\AppData\Local folder. Use of environment variables such as %Temp% will have a similar effect.
Again, I have yet to see any Registry redirection that applies to the System hive. I have seen 32-bit malware installed on 64-bit Windows systems as a service, and the services entries went right into the ControlSet00n\services\ subkeys.
Note: The current version of the appcompatcache.pl plugin includes some simple checks (via grep()) for potentially suspicious paths, such as those that contain the term "temp". Based on some recent findings, I'm going to go back to that and add a check for SysWOW64...and I will likely add that check to other plugins, as well.
So What?
So, why should anyone care about any of this at all? Well, let's say that you're doing some analysis of a system, and you think that there may be malware on the system, malware for which several AV vendor write-ups state that it uses the Run key for persistence. Okay, so we run RegRipper or open the hive in a viewer and navigate to that key...but we don't see a reference to any unusual files. At this point, what do we do? In some cases, many of us might check that item off of our checklist, and move on to the next step. However, did we really complete that check? After all, AV vendor write-ups are notorious for not providing complete information...I have yet to see a write-up that states, "...here is the PE header info for this malware, and we performed dynamic analysis by running the malware in a Windows XP SP3 (32-bit) VirtualBox VM..", and to be honest, I don't think that I've seen that because to the AV vendors, none of that is important. But to an incident responder or a digital forensic analyst, it can be very important.
A couple of months ago, I was looking at a Software hive from a system that had been compromised, and I found some interesting artifacts in the Microsoft\Tracing key. Now, this was a 64-bit Windows system I was analyzing, and I knew that at least one of the programs that had been installed on the system was 32-bit, so I decided to check the WOW6432Node\Microsoft\Tracing key, and not only did I find the subkeys that I thought would be there, but I also found references to other 32-bit programs, as well.
So, when performing analysis or asking questions in order to further your analysis, it is important to realize that not only is it very important to be aware of the version of Windows that you are analyzing, but it's also important to be aware of whether the version is 32- or 64-bit, as this can have a significant impact on where you look for artifacts, in both the file system as well as the Registry.
This also applies to when we're sharing information within the community; for example, after having read this blog post, it should be pretty clear that this write-up of ADrive on ForensicArtifacts.com involved a 32-bit app run on a 64-bit system. However, if you weren't aware of this, would you look for the \Wow6432Node\Microsoft\Tracing\ADrive Desktop_RASAPI32 key, not find "Wow6432Node" in the Software hive, and then just figure that the application had not been run?
Resources
Registry Redirection
File System Redirector
Wait...what?
Now, what does all this mean? Let's say you have a copy of a malware sample, and you submit it to VirusTotal, or you already know what the malware is identified and known as to some of the various AV vendors. When you read the AV vendor write-ups on the malware, you'll notice that they very rarely identify the analysis platform used; so, if the malware uses the Run key for persistence, you might open the Software hive in a viewer and navigate to the Run key, not find any unusual entries, and then simply assume that the malware either didn't execute, or failed to completely install and run.
You should be aware that 64-bit Windows system perform redirection when it comes to 32-bit applications. What this means is that if you check the PE header of the malware file and find that it was compiled for 32-bit platforms, and the system you're analyzing is a 64-bit platform, you're going to need to look in a few additional (maybe I should say "other", instead) areas for your artifacts.
Registry redirection primarily affects the Software and NTUSER.DAT hives; there's (apparently) no "WOW6432Node" subkey in the System hive (I haven't seen one yet). As such, if malware usually uses the Run key, then you should check the Run keys in both the HLKM\Software\Microsoft\Windows\CurrentVersion and the HLKM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion paths.
Something to be aware of is that none of the RegRipper plugins available in the current archive that check the Run keys in either the Software or NTUSER.DAT hives account for redirection. I have a number of plugins in my own repository that do take this into account, and have been responsible for some pretty cool/significant finds.
Now, most times, within the file system, all we usually see with respect to redirection is that when we install 32-bit applications on a 64-bit system, we'll see a C:\Program Files directory as well as a C:\Program Files (x86) directory. However, due to file system redirection, 32-bit malware that, for example, attempts to write a file to the C:\Windows\config\systemprofile \AppData\Local folder (on a Windows 7 or Win2008R2 system), on a 64-bit system will actually write that file to the to C:\Windows\SysWOW64\config\systemprofile\AppData\Local folder. Use of environment variables such as %Temp% will have a similar effect.
Again, I have yet to see any Registry redirection that applies to the System hive. I have seen 32-bit malware installed on 64-bit Windows systems as a service, and the services entries went right into the ControlSet00n\services\ subkeys.
Note: The current version of the appcompatcache.pl plugin includes some simple checks (via grep()) for potentially suspicious paths, such as those that contain the term "temp". Based on some recent findings, I'm going to go back to that and add a check for SysWOW64...and I will likely add that check to other plugins, as well.
So What?
So, why should anyone care about any of this at all? Well, let's say that you're doing some analysis of a system, and you think that there may be malware on the system, malware for which several AV vendor write-ups state that it uses the Run key for persistence. Okay, so we run RegRipper or open the hive in a viewer and navigate to that key...but we don't see a reference to any unusual files. At this point, what do we do? In some cases, many of us might check that item off of our checklist, and move on to the next step. However, did we really complete that check? After all, AV vendor write-ups are notorious for not providing complete information...I have yet to see a write-up that states, "...here is the PE header info for this malware, and we performed dynamic analysis by running the malware in a Windows XP SP3 (32-bit) VirtualBox VM..", and to be honest, I don't think that I've seen that because to the AV vendors, none of that is important. But to an incident responder or a digital forensic analyst, it can be very important.
A couple of months ago, I was looking at a Software hive from a system that had been compromised, and I found some interesting artifacts in the Microsoft\Tracing key. Now, this was a 64-bit Windows system I was analyzing, and I knew that at least one of the programs that had been installed on the system was 32-bit, so I decided to check the WOW6432Node\Microsoft\Tracing key, and not only did I find the subkeys that I thought would be there, but I also found references to other 32-bit programs, as well.
So, when performing analysis or asking questions in order to further your analysis, it is important to realize that not only is it very important to be aware of the version of Windows that you are analyzing, but it's also important to be aware of whether the version is 32- or 64-bit, as this can have a significant impact on where you look for artifacts, in both the file system as well as the Registry.
This also applies to when we're sharing information within the community; for example, after having read this blog post, it should be pretty clear that this write-up of ADrive on ForensicArtifacts.com involved a 32-bit app run on a 64-bit system. However, if you weren't aware of this, would you look for the \Wow6432Node\Microsoft\Tracing\ADrive Desktop_RASAPI32 key, not find "Wow6432Node" in the Software hive, and then just figure that the application had not been run?
Resources
Registry Redirection
File System Redirector
Monday, September 03, 2012
Links, Tools, Etc.
Windows 8 Forensics
There is some great information circulating about the Interwebs regarding Windows 8 forensics. There's this YouTube video titled A Forensic First Look, this blog post that addresses reset and refresh artifacts, the Windows 8 Forensics Guide (this PDF was mentioned previously on this blog), this blog post on the Windows 8 TypedURLsTime Registry key, and Kenneth Johnson's excellent PDF on Windows 8 File History...in addition to a number of other available resources. Various beta and pre-beta versions of Windows 8 have been out for some time, and with each release there seems to be something new...when I went from the first version available for developers to the Consumer Preview, one of the first things I noticed was that I was no longer able to disable the Metro interface.
So what does all this mean? Well, just like when Windows XP was released, there were changes that would affect how we within the digital analysis community would do our jobs, and the same thing has been true since then with every new OS release. While our overall analysis process wouldn't change, there are aspects of the new operating system and it's included technologies that require us to update the specifics of those processes.
Timeline Analysis
Over at the Sploited blog, there's an excellent post on how to incorporate Java information into your TLN-format timeline, in order to help determine the exploit used to compromise a system. In addition to the information available in the two previous posts (here, and here, respectively), this post includes code for parsing .idx files, and incorporating log entries into a TLN-format timeline.
Just to be clear, this is NOT a RegRipper plugin (there is often times confusion about this...), but is instead a file parser that you can use to incorporate data into your timeline, similar to parsing Prefetch file metadata. As such, it can very often add some much-needed detail and context to your analysis.
Posts such as this go hand-in-hand with the excellent work that Corey Harrell has done in determining exploit footprints on compromised systems.
PList Parser
If you do forensics on iDevices, or you get access to iDevice backups via iTunes on a system, you might want to take a look at Maria's PList Parser. Parsing these files can provide you with a great deal of insight into the user's behavior while using the device. Maria said that she used RegRipper as the inspiration for her tool, and it's great to see tools like this become available.
ScheduledTask File Parser
Jamie's released a .job file parser, written in Python. These files, on WinXP and 2003 systems, are in a binary format (in later versions of Windows, they're XML) and like other files (ie, Prefetch files) can contain some significant metadata. In the past, I've found analysis of these artifacts to particularly useful when responding to incidents involving certain threat actors that moved laterally within the compromised infrastructure...one way of doing so was to schedule tasks on remote systems.
Not only does Jamie provide an explanation of what a .job file "looks like", but she also provides references so that folks can look this information up themselves, and develop a deeper understanding of what the tool is doing, should they choose to do so. Also, don't forget the great work Jamie has done with her MBR parser, particularly if you're performing some sort of malware detection on an acquired image.
Registry Analysis
I ran across this write-up on Wiper recently via Twitter,
In the write-up, the authors state:
"...we came up with the idea to look into the hive slack space for deleted entries."
Hhhmm...okay. My understanding of "slack space", with respect to the file system, is that it's usually considered to be what's left over between the logical and physical space consumed by a file. Let's say that there's a file that's 892 bytes, and in order to save it to disk, the system will allocate 2 512 byte sectors, or 1024 bytes. As such, the slack space would be that 132 bytes that remains between the logical end of the file, and end of the second physical sector.
Now, this can be true for the hive files themselves, as some data may exist between the logical end of the hive, and the end of the last physical sector. This may also be true for value data, as well...if the 1024 bytes are allocated for a value, but only 892 bytes are actually written to the allocated space, there may be slack space available.
However, if you look at the graphic associated with the comment (excellent use of Yaru, guys!), the first 4 bytes (DWORD) of the selected data are a positive value, indicating that the key was deleted. As such, the key becomes part of the unallocated space of the hive file, just like the sectors of a deleted file become part of the unallocated space of a volume or disk. So, the value appears to have been part of unallocated space of the hive file, rather than slack space.
With respect to overall Registry analysis, perhaps "...we came up with the idea..." isn't the most systematic approach to that analysis. Admittedly, the authors found something very interesting, but I'd be interested to know if the authors found an enum\Root\Legacy_RAHDAUD64 key in that Registry hive they were looking at, or if they found a Windows Event Log record with source "Service Control Manager" and an ID of 7035 (indicating a service start message had been sent), and then opted to check for deleted keys in the hive after determining that there was no corresponding visible keys for a service of that name in the System hive.
Looking for Suspicious EXEs
Adam wrote an interesting blog post on finding suspicious PE files via clustering...in short, assuming PE files may have been subject to timestomping (ie, intentional modification of MFT $STANDARD_INFORMATION attribute time stamps), and attempting to detect these files by "clustering" the PE file compile times.
You can read more about methods for detecting malicious files by reading Joel Yonts' GIAC Gold Paper, Attributes of Malicious Files.
There is some great information circulating about the Interwebs regarding Windows 8 forensics. There's this YouTube video titled A Forensic First Look, this blog post that addresses reset and refresh artifacts, the Windows 8 Forensics Guide (this PDF was mentioned previously on this blog), this blog post on the Windows 8 TypedURLsTime Registry key, and Kenneth Johnson's excellent PDF on Windows 8 File History...in addition to a number of other available resources. Various beta and pre-beta versions of Windows 8 have been out for some time, and with each release there seems to be something new...when I went from the first version available for developers to the Consumer Preview, one of the first things I noticed was that I was no longer able to disable the Metro interface.
So what does all this mean? Well, just like when Windows XP was released, there were changes that would affect how we within the digital analysis community would do our jobs, and the same thing has been true since then with every new OS release. While our overall analysis process wouldn't change, there are aspects of the new operating system and it's included technologies that require us to update the specifics of those processes.
Timeline Analysis
Over at the Sploited blog, there's an excellent post on how to incorporate Java information into your TLN-format timeline, in order to help determine the exploit used to compromise a system. In addition to the information available in the two previous posts (here, and here, respectively), this post includes code for parsing .idx files, and incorporating log entries into a TLN-format timeline.
Just to be clear, this is NOT a RegRipper plugin (there is often times confusion about this...), but is instead a file parser that you can use to incorporate data into your timeline, similar to parsing Prefetch file metadata. As such, it can very often add some much-needed detail and context to your analysis.
Posts such as this go hand-in-hand with the excellent work that Corey Harrell has done in determining exploit footprints on compromised systems.
PList Parser
If you do forensics on iDevices, or you get access to iDevice backups via iTunes on a system, you might want to take a look at Maria's PList Parser. Parsing these files can provide you with a great deal of insight into the user's behavior while using the device. Maria said that she used RegRipper as the inspiration for her tool, and it's great to see tools like this become available.
ScheduledTask File Parser
Jamie's released a .job file parser, written in Python. These files, on WinXP and 2003 systems, are in a binary format (in later versions of Windows, they're XML) and like other files (ie, Prefetch files) can contain some significant metadata. In the past, I've found analysis of these artifacts to particularly useful when responding to incidents involving certain threat actors that moved laterally within the compromised infrastructure...one way of doing so was to schedule tasks on remote systems.
Not only does Jamie provide an explanation of what a .job file "looks like", but she also provides references so that folks can look this information up themselves, and develop a deeper understanding of what the tool is doing, should they choose to do so. Also, don't forget the great work Jamie has done with her MBR parser, particularly if you're performing some sort of malware detection on an acquired image.
Registry Analysis
I ran across this write-up on Wiper recently via Twitter,
In the write-up, the authors state:
"...we came up with the idea to look into the hive slack space for deleted entries."
Hhhmm...okay. My understanding of "slack space", with respect to the file system, is that it's usually considered to be what's left over between the logical and physical space consumed by a file. Let's say that there's a file that's 892 bytes, and in order to save it to disk, the system will allocate 2 512 byte sectors, or 1024 bytes. As such, the slack space would be that 132 bytes that remains between the logical end of the file, and end of the second physical sector.
Now, this can be true for the hive files themselves, as some data may exist between the logical end of the hive, and the end of the last physical sector. This may also be true for value data, as well...if the 1024 bytes are allocated for a value, but only 892 bytes are actually written to the allocated space, there may be slack space available.
However, if you look at the graphic associated with the comment (excellent use of Yaru, guys!), the first 4 bytes (DWORD) of the selected data are a positive value, indicating that the key was deleted. As such, the key becomes part of the unallocated space of the hive file, just like the sectors of a deleted file become part of the unallocated space of a volume or disk. So, the value appears to have been part of unallocated space of the hive file, rather than slack space.
With respect to overall Registry analysis, perhaps "...we came up with the idea..." isn't the most systematic approach to that analysis. Admittedly, the authors found something very interesting, but I'd be interested to know if the authors found an enum\Root\Legacy_RAHDAUD64 key in that Registry hive they were looking at, or if they found a Windows Event Log record with source "Service Control Manager" and an ID of 7035 (indicating a service start message had been sent), and then opted to check for deleted keys in the hive after determining that there was no corresponding visible keys for a service of that name in the System hive.
Looking for Suspicious EXEs
Adam wrote an interesting blog post on finding suspicious PE files via clustering...in short, assuming PE files may have been subject to timestomping (ie, intentional modification of MFT $STANDARD_INFORMATION attribute time stamps), and attempting to detect these files by "clustering" the PE file compile times.
You can read more about methods for detecting malicious files by reading Joel Yonts' GIAC Gold Paper, Attributes of Malicious Files.