Thanks to the heads up from Eric, I've updated the RegRipper plugins for parsing this data. However, my testing was extremely limited; I had only one System hive file (from a Windows 10 TP VM that I'd set up) on which to test the parsing code. A dearth of testing data has been an issue since I started writing tools, and it seems that even TaoSecurity has recognized the need for test data.
Interestingly enough, I happened across a System hive file from a Windows 2012 system, and the updates to the parser seemed to work just fine. Again, I said "a" hive...so testing has been extremely limited.
AppCompatCache/ShimCache
When working with the AppCompatCache or "ShimCache" data, analysts need to remember the context of the information, and in particular, the time stamps in the data. In most cases, the time stamp is the last modification time for the file in question, from the file system metadata, specifically, the $STANDARD_INFORMATION attribute. It is NOT the date and time that the application was executed.
When working with the AppCompatCache or "ShimCache" data, analysts need to remember the context of the information, and in particular, the time stamps in the data. In most cases, the time stamp is the last modification time for the file in question, from the file system metadata, specifically, the $STANDARD_INFORMATION attribute. It is NOT the date and time that the application was executed.
Dumping Passwords
Speaking of the Registry, I ran across this little gem that describes how to dump passwords in plain text from Windows 8.1/2012 systems. I'm a big proponent for finding out what things look like on systems, and it's pretty clear reading through the blog post what an analyst would look for in an acquired image, to determine if something similar to what was described in the post had occurred on the system.
However, I'll put this out there...rather than hoping to find these indicators on a system, why not make IR scoping easier on yourself through the use of process creation monitoring at the endpoints?
Malware Persistence
Here's a good blog post on malware persistence. There's some focus on MS's AutoRuns tool, so it's likely to be familiar to a lot of folks. What I thought was interesting is the number of times we see the Run key being the point of persistence for malware; while many will suggest that this location is 'well known', there are also those of us who see it used time and time again, even when the incident is 'detected' through external, third-party notification. Some may think that the Run key is passe, but hey, it still works, and works well...so why not use it, right?
EVT vs EVTX
Every now and then, I still get an opportunity to analyze Windows XP and 2003 systems...most often, I tend to find myself working with Windows 7 and Windows 2008 R2 systems. Working with older versions of Windows can sometimes necessitate the use of different tools in order to conduct analysis; specifically, when working with the Event Logs, they're in a different location, as well as in a different binary format.
When working with Windows XP and 2003 (and yes, Windows 2000) Event Logs (*.evt files), I'll use evtrpt and evtparse. These tools were written specifically for the binary format of the *.evt files found on Windows 2000, XP, and 2003 systems, and are not intended for use against the *.evtx files found on Vista+ systems.
Evtrpt
This is a tool I wrote a while back to provide me with information about the contents of an EVT file; how many records exist, how many source/ID pairs exist, and what date range do the events cover. What's cool about this tool is that it doesn't use the MS API...which means that it can be run on Linux, and it doesn't rely on the header information of the EVT file to tell it how many records exist.
Evrtp is a command line tool, and takes just one argument...the path to the file you're interested in parsing. If you just type the name of the tool at the command prompt, you'll get a message that says "You must enter a filename". That seems to be pretty straightforward, and adding the full path to the .evt file of interest is all I need to do.
So, I run the tool against an Event Log file that I've extracted from an image, and one of the things I see in the output is the date range for the event records in that file:
Fri Sep 27 17:32:26 2013 to Tue Apr 28 17:37:58 2015
Cool, it covers the time that I'm interested in. Above the date range in the output, I get a list of event sources and IDs, as well as a count of each. For login attempts, the tool also breaks down the login/logoff type. For example, I see the following entry:
Security 538,3 18938
What this tells me is that for the source "Security", there are 18938 events with ID 538 and type 3.
I ran the tool against the other Event Log files from the system, as well. For the Application Event Log, the date range was:
Thu Jan 10 01:52:02 2013 to Tue Apr 28 15:36:04 2015
What I found most interesting from the output of the tool was this entry:
Symantec AntiVirus 51 2
Remember the tool I use for Windows Event Logs, wevtx.bat? The one that uses the eventmap.txt file? Well, in that file, Symantec AntiVirus/51 event records indicate that the product detected malware. Understanding the context of these event source/ID pairs can be extremely valuable, and the evtrpt tool can give you an idea of what pairs are available. For McAfee, I'd look for McLogEvent/257 pairs.
Something of interest from the output of the System Event Log was:
Application Popup 26 11
Application Popup 44 1
So, hopefully by now you can see how useful this tool can be for a quick look at the Event Log files.
Evtparse
This tool operates similar to the evtrpt tool, but the output allows you to see more about the Event Log records. Typing just the name of the tool at the prompt will show you the syntax information, along with example command lines you can use to run the tool. I use this tool to parse through the *.evt file (or files) and add the entries to a timeline of system activity. The command line to launch this tool does not take many arguments, because most of the data that you may want to include in each timeline entry (system name, user name, etc.) is included within each event record.
Why Do I Need The Event Source and the event ID?
Something I see a great deal of within the DFIR community is that Windows Event Log records are referred to only by their ID number. Ok, you're probably wondering...so what? Who cares? Well, it can be important...if someone says that they have mulitple event ID 4100 records, I would have to ask, which source? There are a number of event IDs that have multiple different event sources, each of which can provide completely different context to the situation.
So What?
Why does any of this matter? Context is extremely important when conducting analysis, and in particular when communicating findings to other analysts, as well as to clients. One example was mentioned earlier in this post...the time stamps in the AppCompatCache/ShimCache data is the last modification time of the file, from the file system metadata (the Mandiant white paper is only 5 pages long and is an easy read...).
Another example comes from the output of another RegRipper plugin...the LastWrite time for one of the subkeys from the USBStor key is just that...the key LastWrite time, which is analogous to a file's last modification time. It is NOT the last time that USB device was written to.
So, when communicating findings from the Event Log (or, Windows Event Log on Vista+ systems), providing the event source AND ID can be extremely important for context. If someone just says, "...event ID 4100...", then the very next question should be, "...which event source?" When documenting findings in your case notes, include both the source and ID, as well as a reference, for (possible) inclusion in the eventmap.txt file.
No comments:
Post a Comment