Artifacts
I received a request right before WFA 4/e hit the streets...after the writing and editing was complete and while the printed book was being shipped...to "talk about anti-forensics". Unfortunately, at this point, I still haven't heard any more than just that, but I've had more than a couple of instances where knowledge of artifacts and Windows structures has allowed me to gather valuable data for analysis, even when the bad guy took steps, however unknowingly, to remove other artifacts. I say "unknowingly" because sometimes the steps taken may not specifically be intended to be "anti-forensic" in nature, but may still have that effect.
Something that I've found over the years is that even when steps are taken to remove indications of activity, there may still be artifacts available that can prove valuable to an analyst. While the analyst may not be able to answer THE question that they have, there may be data available that will still provide insight into the case and allow other questions to be answered. For example, if the intruder accessed a system via RDP and removed or obscured some valuable data source (i.e., cleared the Windows Event Log, etc.) and the question you have is, "where did they access this system from?", you might not be able to answer that question. However, using other data, you would be able to show when they were active on the system, what they were doing at the time, and even demonstrate access to other systems.
To quote Blade: "When you understand the nature of a thing, you know what it's capable of." I know, I know...but I really wanted to work that quote into this post. ;-) What I'll do now is take a look at some of the things I and others have seen, and provide some thoughts as to other data sources that would be of value.
FTP Via Windows Explorer
I've seen the native ftp.exe client used on systems in a variety of cases, and not only to exfiltrate data. Back when I was doing PCI forensic analysis, we saw a good deal of SQL injection activity, some of which would use echo to create an FTP script on a system, and then launch that script using the -s switch with ftp.exe. The use of ftp.exe to infiltrate or exfil data can leave artifacts in the Registry, and for workstation systems, there will be an application prefetch file created. On XP systems, the last accessed time on the file will be updated, and there will very likely be a value created in the user's MUICache key for ftp.exe.
However, you can use Windows Explorer to connect to an FTP server. My publisher used to have me do this in order to transfer chapters, and I've seen this used a number of times on various cases. The interesting thing about this is that while it involves interaction via the GUI shell, it leaves far fewer artifacts than using the command line utility. In fact, having looked at several cases where this technique is used, the only place that I've found artifacts of this activity is in the user's shellbag artifacts. I've discussed these artifacts before, so I won't go into a great deal of detail here. Suffice to say, shellbags can be a great resource, demonstrating access to network resources such as shares (even C$ shares), MTP devices (digital cameras and smartphones), FTP sites, etc., providing artifacts of activity that you might not find anywhere else on the system.
Clearing Windows Event Logs
Ever access a system and find out that the records in the Security and System Event Logs only go back a day or two? One of the things I talk about in my books and presentations is that while it's easy to assume that the default configuration of the Event Logs caused them to roll over, it's also pretty trivial to check and see if there was some other reason for this, such as a user clearing the Event Logs. If this happens, you'll likely see a record in the Security Event Log indicating that this happened, so look for the appropriate event ID (517 or 1102). I've seen intruders do this, and I've seen admins who are responding to and troubleshooting an "incident" do this, as well. Many times when the Event Log is cleared, you'll see a user accessing the Event Viewer (usually visible via the UserAssist data) just prior to that time.
When the Event Log is cleared, that doesn't mean that all data goes away. You can try to recover Windows Event Log records using Willi Ballenthin's EVTXtract, or depending on what you're trying to illustrate, you can look to other data. For example, I've had instances when the Windows Event Logs have been cleared, but I've been able to demonstrate a user's windows of activity over time using other sources of data, such as the Registry, VSCs, etc.
The Power of Mini-, Micro-, and Nano-Timelines
Daniel Garcia recently added a review of WFA 4/e to the Amazon page for the book (thanks again, Daniel, for taking the time do to that, I greatly appreciate it); in that review he mentioned mini-timelines. Interestingly enough, I use this technique all the time. Many times, I'll grab some information and start putting together a timeline from a small subset of data sources, in order to get an idea of what's going on, and then once I have that info, I'll kick off a heftier process and let that run while I'm analyzing what I have. Or, as is often the case, the results of analyzing the mini-timeline will provide me with the direction for my next steps. This allows me to see things that I might have missed had I included voluminous amounts of file system metadata, Windows Event Logs, etc., and goes back to the technique of using overlays that I mentioned over two years ago. This technique has provided useful in a number of cases. For example, if someone is in a data center acquiring data, I can send them a batch script (similar to auto_rip) that runs various tools (RegRipper, etc.) and have them ship me the output of the tools. This allows me to start analysis while the bulk of the data is in transit, and when it shows up, I'm ready to start my focused analysis. Or, they can acquire the data and once it's been verified, send me subsets of the data (Registry hive files, Windows Event Logs, etc.) in a secure archive, allowing me to begin analysis on a few KB of data while the full archive (several hundred GB of data) is enroute.
Not long ago, I collected the NTUSER.DAT, USRCLASS.DAT and index.dat files from three user profiles within an image. These profiles were thought to be active during the time of the incident, so I parsed the Registry hives with RegRipper, and the index.dat files with a custom tool, and created a micro-timeline that showed me not just times of activity, but patterns of activity that I would have missed had I included all of the data (file system, WEVTX, Registry hives, other user profiles, etc.) available within the image. The results of this analysis allowed me to then focus my analysis on the more inclusive timeline and develop a much clearer picture of the activity that was the focus of my interest.
Browser Analysis
When we hear 'browser analysis', most of us think about data sources such as index.dat files or SQLite databases, and tools like IEF. But there are other potentially valuable data sources available to us, such as cookie files, bookmarks/favorites, and session recovery files.
If the user is using IE and you're interested in their activity during a specific point in time, you may have options available to you to get the information you're looking for. For example, the TypedURLs key (and TypedURLsTime key, if they're using Windows 8) may prove fruitful, particularly when used in conjunction with VSCs. If IE crashed (for whatever reason) while the user was browsing the web, you'll have the Travelog files available, and these can provide much more insight into what the user was doing than an index.dat record would.
The IE session restore files are structured storage/OLE format, and Yogesh has an EnScript available for parsing them. I've used strings to get the data that I want, and MiTeC's Structured Storage Viewer to view the contents of individual streams within the file. Python has a good module for parsing OLE files (I really haven't found anything that works as well in Perl, and have written some of my own stuff), and it shouldn't take too much effort to put a parser together for these files. What's really fascinating about these files is that within a timeline, you may see where the user launched IE (UserAssist data), accessed a particular site (TypedURLs key, index.dat data), but at that point, you really can't tell too much about what they did, or what sort of interaction they had with the page, or pages, that they visited. If you're lucky and there's a session saved in a Travelog file, then you can see what they were doing at the time of the crash. I've seen commands sent to database servers via default stored procedures. So, these files can be a rich source of data.
For other browsers, here's information on session restore functionality:
Chrome User Data Directory (here's a tip for restoring the last session from the command line)
Firefox - Mozilla Session Restore
Summary
My point in all this is that while in most cases we really want to see all of the data, there are times when we either don't need everything, or as is often the case, everything simply isn't available and we have to make the best use of what we have. For example, if I simply want to see when a user was active on a system, over time, I wouldn't need everything from the system, and I wouldn't need everything from the user profile. All I'd need to get started are the two Registry hives, browser history files, and maybe the Jump Lists. The total size of this data is much less than the full image, and it's even smaller if I can get someone on site to run the tools and just send me the data.
Something that I've found over the years is that even when steps are taken to remove indications of activity, there may still be artifacts available that can prove valuable to an analyst. While the analyst may not be able to answer THE question that they have, there may be data available that will still provide insight into the case and allow other questions to be answered. For example, if the intruder accessed a system via RDP and removed or obscured some valuable data source (i.e., cleared the Windows Event Log, etc.) and the question you have is, "where did they access this system from?", you might not be able to answer that question. However, using other data, you would be able to show when they were active on the system, what they were doing at the time, and even demonstrate access to other systems.
To quote Blade: "When you understand the nature of a thing, you know what it's capable of." I know, I know...but I really wanted to work that quote into this post. ;-) What I'll do now is take a look at some of the things I and others have seen, and provide some thoughts as to other data sources that would be of value.FTP Via Windows Explorer
I've seen the native ftp.exe client used on systems in a variety of cases, and not only to exfiltrate data. Back when I was doing PCI forensic analysis, we saw a good deal of SQL injection activity, some of which would use echo to create an FTP script on a system, and then launch that script using the -s switch with ftp.exe. The use of ftp.exe to infiltrate or exfil data can leave artifacts in the Registry, and for workstation systems, there will be an application prefetch file created. On XP systems, the last accessed time on the file will be updated, and there will very likely be a value created in the user's MUICache key for ftp.exe.
However, you can use Windows Explorer to connect to an FTP server. My publisher used to have me do this in order to transfer chapters, and I've seen this used a number of times on various cases. The interesting thing about this is that while it involves interaction via the GUI shell, it leaves far fewer artifacts than using the command line utility. In fact, having looked at several cases where this technique is used, the only place that I've found artifacts of this activity is in the user's shellbag artifacts. I've discussed these artifacts before, so I won't go into a great deal of detail here. Suffice to say, shellbags can be a great resource, demonstrating access to network resources such as shares (even C$ shares), MTP devices (digital cameras and smartphones), FTP sites, etc., providing artifacts of activity that you might not find anywhere else on the system.
Clearing Windows Event Logs
Ever access a system and find out that the records in the Security and System Event Logs only go back a day or two? One of the things I talk about in my books and presentations is that while it's easy to assume that the default configuration of the Event Logs caused them to roll over, it's also pretty trivial to check and see if there was some other reason for this, such as a user clearing the Event Logs. If this happens, you'll likely see a record in the Security Event Log indicating that this happened, so look for the appropriate event ID (517 or 1102). I've seen intruders do this, and I've seen admins who are responding to and troubleshooting an "incident" do this, as well. Many times when the Event Log is cleared, you'll see a user accessing the Event Viewer (usually visible via the UserAssist data) just prior to that time.
When the Event Log is cleared, that doesn't mean that all data goes away. You can try to recover Windows Event Log records using Willi Ballenthin's EVTXtract, or depending on what you're trying to illustrate, you can look to other data. For example, I've had instances when the Windows Event Logs have been cleared, but I've been able to demonstrate a user's windows of activity over time using other sources of data, such as the Registry, VSCs, etc.
The Power of Mini-, Micro-, and Nano-Timelines
Daniel Garcia recently added a review of WFA 4/e to the Amazon page for the book (thanks again, Daniel, for taking the time do to that, I greatly appreciate it); in that review he mentioned mini-timelines. Interestingly enough, I use this technique all the time. Many times, I'll grab some information and start putting together a timeline from a small subset of data sources, in order to get an idea of what's going on, and then once I have that info, I'll kick off a heftier process and let that run while I'm analyzing what I have. Or, as is often the case, the results of analyzing the mini-timeline will provide me with the direction for my next steps. This allows me to see things that I might have missed had I included voluminous amounts of file system metadata, Windows Event Logs, etc., and goes back to the technique of using overlays that I mentioned over two years ago. This technique has provided useful in a number of cases. For example, if someone is in a data center acquiring data, I can send them a batch script (similar to auto_rip) that runs various tools (RegRipper, etc.) and have them ship me the output of the tools. This allows me to start analysis while the bulk of the data is in transit, and when it shows up, I'm ready to start my focused analysis. Or, they can acquire the data and once it's been verified, send me subsets of the data (Registry hive files, Windows Event Logs, etc.) in a secure archive, allowing me to begin analysis on a few KB of data while the full archive (several hundred GB of data) is enroute.
Not long ago, I collected the NTUSER.DAT, USRCLASS.DAT and index.dat files from three user profiles within an image. These profiles were thought to be active during the time of the incident, so I parsed the Registry hives with RegRipper, and the index.dat files with a custom tool, and created a micro-timeline that showed me not just times of activity, but patterns of activity that I would have missed had I included all of the data (file system, WEVTX, Registry hives, other user profiles, etc.) available within the image. The results of this analysis allowed me to then focus my analysis on the more inclusive timeline and develop a much clearer picture of the activity that was the focus of my interest.
Browser Analysis
When we hear 'browser analysis', most of us think about data sources such as index.dat files or SQLite databases, and tools like IEF. But there are other potentially valuable data sources available to us, such as cookie files, bookmarks/favorites, and session recovery files.
If the user is using IE and you're interested in their activity during a specific point in time, you may have options available to you to get the information you're looking for. For example, the TypedURLs key (and TypedURLsTime key, if they're using Windows 8) may prove fruitful, particularly when used in conjunction with VSCs. If IE crashed (for whatever reason) while the user was browsing the web, you'll have the Travelog files available, and these can provide much more insight into what the user was doing than an index.dat record would.
The IE session restore files are structured storage/OLE format, and Yogesh has an EnScript available for parsing them. I've used strings to get the data that I want, and MiTeC's Structured Storage Viewer to view the contents of individual streams within the file. Python has a good module for parsing OLE files (I really haven't found anything that works as well in Perl, and have written some of my own stuff), and it shouldn't take too much effort to put a parser together for these files. What's really fascinating about these files is that within a timeline, you may see where the user launched IE (UserAssist data), accessed a particular site (TypedURLs key, index.dat data), but at that point, you really can't tell too much about what they did, or what sort of interaction they had with the page, or pages, that they visited. If you're lucky and there's a session saved in a Travelog file, then you can see what they were doing at the time of the crash. I've seen commands sent to database servers via default stored procedures. So, these files can be a rich source of data.
For other browsers, here's information on session restore functionality:
Chrome User Data Directory (here's a tip for restoring the last session from the command line)
Firefox - Mozilla Session Restore
Summary
My point in all this is that while in most cases we really want to see all of the data, there are times when we either don't need everything, or as is often the case, everything simply isn't available and we have to make the best use of what we have. For example, if I simply want to see when a user was active on a system, over time, I wouldn't need everything from the system, and I wouldn't need everything from the user profile. All I'd need to get started are the two Registry hives, browser history files, and maybe the Jump Lists. The total size of this data is much less than the full image, and it's even smaller if I can get someone on site to run the tools and just send me the data.