In this blog post, I am going to show you some ways to review data that have been collected with the Mandiant Redline™ tool, without using the Redline interface. I will be using Mandiant's AuditParser™ tool in order to transform the Redline audit XML into tab separated data. This will let you take data and view it in different ways, as well as perform timeline analysis on data you have collected. I will focus on using data collected by a Redline Portable collector, which was configured to perform a Comprehensive Collection. The AuditParser tool will also work with audit data that have been collected with the MIR Agent, or with IOCFinder™.

Timeline analysis can be an important technique when performing an investigation on a system. It involves taking data from several sources, in this case, Redline audit data, and sorting it chronologically. This allows an analyst to see numerous data sources in a chronological fashion, allowing multiple, discrete events to be correlated together. I will be demonstrating timeline analysis, with AuditParser, on a system that is infected with malware.

The first item I want to show is how AuditParser converts audit data to the tab separated files. Once you've got the AuditParser tool, you can run it, and point to the directory of audit data that you have collected with Redline. There is also a Windows executable version of this tool available, if you do not have access to Python.

C:Documents and SettingsUserDesktopAuditParser>python AuditParser.py -i ..LR_Collection -o ..Processed_Audits
Parsing input file: ..LR_Collectionmir.w32apifiles.1176360b.xml
Parsing input file: ..LR_Collectionmir.w32eventlogs.771e480e.xml
Parsing input file: ..LR_Collectionmir.w32registryapi.3e2e3e42.xml
Parsing input file: ..LR_Collectionmir.w32scripting-persistence.27091e25.xml
...

This will output a set of files in ..Processed_Audits, which are the tab separated files, one for each audit in the input.

C:Documents and SettingsUserDesktopAuditParser>dir ..Processed_Audits
Directory of C:Documents and SettingsUserDesktopIndividual_Audits
10/19/2012 08:56 PM
20,385,250 mir.w32apifiles.1176360b.xml.txt
10/19/2012 08:56 PM
592,829 mir.w32eventlogs.771e480e.xml.txt
10/19/2012 09:00 PM
48,625,256 mir.w32registryapi.3e2e3e42.xml.txt
10/19/2012 09:01 PM
301,325 mir.w32scripting-persistence.27091e25.xml.txt
...

Now that you have these files parsed, you can start performing analysis with any software that supports processing tab separated files, such as Microsoft Excel or Apache OpenOffice. This lets you quickly sort and filter data you have collected and quickly look for anomalies. Below is a screenshot of the output of the Persistence audit. The persistence audit combines the File, Registry and Services audit to look for executable files that will persistently run on a system. Each of the columns - denoting information collected from the Registry, Filesystem and Services - can be filtered in order to perform an investigative analysis.

Click to enlarge image

If you sort by files that do not have digital signatures (Column: Signature Exists, select 'False'), one entry is found. This is a serviceDLL entry. This indicates that there is an unsigned service running on this system. The Persistence audit gives you some information you can use to further analysis. It gives the location to the file on the file system, the file owner, a hash of the file, Registry path & value information. The file full path, "c:WINDOWSimewmimachine2.dll" is not a typical location for a service DLL, so this item is definitely something worth investigating.

Click to enlarge image

You could continue reviewing data in individual audits using some of the information presented in the Persistence audit module. In fact, there is some additional information contained in the XML for the persistence item, pertaining to the file 'wmimachine2.dll.' Continuing with the individual audits would be familiar sorting and filtering operations, so that will be skipped for now. Instead, what I'm going to show next is how to timeline the audit data that we have already collected in order to identify other items of interest which have occurred around the creation of our malicious serviceDLL. In order to do this, I will rerun the AuditParser tool with the timeline switches.

C:Documents and SettingsUserDesktopAuditParser>python AuditParser.py -i ..LR_Collection -o ..Processed_Audits
ed -t --starttime 2012-10-18T00:00:00Z --endtime 2012-10-21T00:00:00Z

This will rerun AuditParser, regenerating the .txt files you already have processed and creating a new file, timeline.txt. This is a tab separated file that contains a timeline of File, Registry, Event Log, Url History, Process Item and Prefetch audit data. I picked a date range of 2012-10-18 through 2012-10-20 to timeline.

Here is a screenshot of timelined data:

Click to enlarge image

You can see that we timeline on multiple timestamps for each item. For instance, a file can have up to eight different timestamps (API + NTFS timestamps), and the AuditParser tool will create an entry for each of those timestamps.

From the Persistence audit data, you can see the file created date is "2012-10-20T01:06:55Z". You can start by narrowing down the date range of items displayed by filtering the date with the string '2012-10-20T01'. This will show you all of the activity on 2012-10-20 between 01:00:00Z and 01:59:59Z. Below is a screenshot of some activity around the time of interest.

Click to enlarge image

If you look through the data, you can see that there was a file staged in C:Recycler, named 'scvhost.exe'. This was likely executed with a command shell, cmd.exe. After scvhost.exe was executed, you can see the Eventlog record the service start for the ".NET Runtime Optimization Service v2.086521.BackUp_X86" service. Further down, you can see artifacts in the registry where the '6to4' service has been hijacked and used to host this new, malicious service. Here you can see the how the registry has been timelined, and shows the Paths and Values.

Click to enlarge image

This does not necessarily finish the investigation of this host. Malware analysis may need to be performed on the malware 'scvhost.exe' and 'wmimachine2.dll' in order to identify additional host-based and network-based indicators of compromise. The source of 'scvhost.exe' has not been identified, so that would require further investigation.

Hopefully, this demonstration of using AuditParser to process Redline audit data has been helpful, showing a new way to process and analyze the large volume of data that can be collected with Redline. The timeline capability of AuditParser can be a powerful analysis tool. If they are not already, Redline and AuditParser should become part of your investigative toolkit. You can download each tool here (Redline) and here (AuditParser).