Presenting at SANS Institute's DFIRCON!

I am pleased to announce that I will be presenting my research on the Windows 8 Prefetch at SANS Institute's DFIRCON.  The conference will be held in Monterey, CA from March 5th to March 10th 2014.  If you have not had a chance to see the line up that will be at this conference please check out the brochure.  Thanks to Chad Tilbury and Rob Lee for giving me the opportunity to present this information to the broader audience, and to those who have read my blog and spread my research.

malsysproc

This weekend I was working on some memory analysis using Volatility, and I came across a sample that had a malicious process named svchost.exe.  Now if you have read Mandiant's M-Trends report, then you know that svchost.exe is the most common name of malware found.  If you have spent any amount of time working with Windows forensics or incident response, then you are very familiar with the reason why malware authors name their process svchost.exe.  In a normal Windows installation there are approximately 6-10 svchost processes running at any given time.  In this particular sample, it was fairly easy for me to spot the malicious process because it was exhibiting behavior that was abnormal for its name.  However, if an analyst does not have a familiarity with what behavior is "normal", then it may be difficult to determine the nature of this seemingly common process.  By then end of the analysis I had run quite a few plugins just to get the information I needed to determine the intent of this process, and I began wondering if there was some way to tie these commands together.  I first looked into writing a bash script to run multiple plugins automatically and parsing out specific information from each output, but after a few minutes Googling I realized writing my own plugin would be much cleaner.  This post describes the information I learned along the way, and will discuss the features (present and future) of the plugin I wrote.

Volatility Documentation
Upon setting out on my journey to learn how to write my own Volatility plugin, I stumbled upon the official developer's guide for Volatility 2.2.  This guide gives you all of the information you need to start writing your first plugin.  I also found a few blog posts useful, one from +Jamie Levy and one from Command Line Kung Fu where MHL shows how writing a new plugin might be a million times easier than parsing the output of multiple plugins.

malsysproc
I wrote the malsysproc plugin to be an automated method of looking at the behaviors of system processes  to look for malware hiding in plain sight.  Initially malsysproc looks at processes named svchost and lsass and determines if the process is legitimate.  This plugin will also look for processes named similarly to svchost and lsass such as lssas or scvhost.

The first test ran against each process is to check that the name of the process is actually what is expected.  I wanted to ensure the plugin doesn't overlook the lookalikes, so I initially look for processes that match a regular expression.  The regular expression is very simple, and it looks for characters to be switched around.  If a process does have letters switched around it will fail the name test.

While looking for processes named lsass.exe I keep track of each process I find, and if I find more than one lsass.exe I notify the analyst.

After running the name test, it is important to ensure that the process is running from the expected path.  Often times hackers will name their malware for a native Windows process, but they will put it in a different directory like a temp folder.  This check that the path matches the path of the native Windows process (C:\windows\system32\ for both lsass.exe and svchost.exe).

One way to spot a malicious svchost process is to run Volatility's pstree plugin.  pstree shows a graphical representation of each process' parent-child relationship.  svchost.exe should always be a child of services.exe, and if it isn't then we have a clear indicator of wrong doing.  Similarly, lsass.exe should be the child of wininit.exe for systems running Vista or better, or winlogon.exe for systems running XP or older.

Time is another valuable method to use when looking for malware posing as system processes.  In this plugin, I compare each system process' creation time to that of its parent, and if the system process was created more than 10 seconds after its parent it is flagged.  I have not done extensive testing on this test yet, but on the 3 memory samples I ran the plugin against it hasn't had any false positives.

Sometimes the Operating System gives system processes a higher base priority than that of normal user processes.  In his analysis of Stuxnet MHL notices that although Stuxnet uses the process hollowing technique to inject itself into a real lsass.exe process, it fails to properly set the base priority level of the process.  This allows us to pick out the imposter lsass.exe processes.  Unfortunately, svchost processes run at the default base priority level, so this technique cannot be used to find malicious svchost processes.

Lastly, I compare the command line arguments of each system process to a list of expect arguments.  If the process was run without or with incorrect expected arguments this test will flag the process as being suspicious.

A few future additions will be adding tests for process owner, unexpected network connections, looking for dll injection, and unexpected child processes.

Check out the code here.  Copy the file to your volatility/plugins directory, and it will be automatically added to your plugins list.

Examples

An example of running malsysproc against an image running a malicious svchost.exe process.  This process was not running out of the C:\WINDOWS\system32\ directory, did not have the correct parent process, was started much later than the other svchost.exe processes, and did not have appropriate command line parameters.

An example of malsysproc when run against a stuxnet memory image.  Because multiple lsass.exe process were found the plugin warns the analyst that this is not normal behavior.  Also, these processes do not have the correct parent process, they were started later than expected, their base priority level was at the default instead of being elevated, and they appear to have an unexpected command line (in this case it seems they have extra '\' characters to escape the '\' characters in the path itself.

There you have it.  I found a problem, researched solutions, learned the interface, and produced my first plugin in about an hour of work.  I plan to follow this post up with more detail on what a plugin requires, and how you can write your own.  Thanks for reading!

If you have any questions, comments, or concerns please let me know at jared@invoke-ir.com.

What's New in the Prefetch for Windows 8??

I am currently working on a PowerShell module that will provide a remote forensic capability for forensicators and incident responders alike.  I know many tools that parse file based forensic artifacts (Ex: Prefetch), but none of these tools parse remote artifacts.  Remote parsing provides defenders with many advantages, including a capability called Least Frequency of Occurrence (LFO).  If a defender can aggregate data from every prefetch file on every host in a large network, they can use LFO to spot anomalies, which may in turn point out malicious activity.

While creating a cmdlet, to parse Windows Prefetch files, I realized that there were many inconsistencies between the format of prefetch files on Windows XP and Windows 7.  I also realized that little research had been done regarding the structure of Windows 8 prefetch files, and assumed there would be small inconsistencies with this version as well.  I am writing a blog series to describe the methodology I used to learn Windows 8 prefetch file format, and to document some of the interesting finds along the way.

What is Prefetch?
Simply put, application prefetching is used to store information about frequently used applications to help Windows load them more quickly in the future.  This information is stored in "prefetch" files found in the %systemroot%\Prefetch\ directory.  At any given time the system can keep up to 128 (Windows XP/2003/Vista/7/2008) or 1024 (Windows 8/8.1/2012) individual prefetch files (Each one correlates to a single application).  These files contain information about the application like how many times it was run, when was it last run, what path it was run from, what external files it loaded in its first 10 seconds of execution, etc.

Understanding the Prefetch File Format (Windows 8)

This series of examples is using a cmd.exe prefetch file from Windows 8

File Signature (Offset: 0x00 8-bytes)

The first value found in the data structure is the File Signature at Offset 0x00.  The signature is a 8-byte value containing (0x1A,0x00,0x00,0x00,0x53,0x43,0x43,0x41), the first of which represents the OS (0x11 = XP, 0x17 = 7, 0x1A = 8).  The ASCII representation of the final 4 bytes is SCCA, which is commonly recognized as the Prefetch File Signature.

Application Name (Offset: 0x10 60-bytes)

Next, at Offset 0x10, we see a Unicode Formatted String that says "CMD.EXE".  This value represents the name of the application for which this prefetch record has been created.  This name can/should be compared to the name of the prefetch file itself to ensure the file name has not been tampered with.  One important detail is that this value is represented in 60 bytes, to allow for variable lengths of application names.  The standard is for the application name to be terminated by Unicode NULL (0x0000).

File Path Hash (Offset: 0x4C 4-bytes)

Have you ever wondered about those 8 random hex values in name of prefetch files?  Interestingly enough the value is a hash of the application's file path.  Remember earlier I said that one prefetch file is created for each application run?  Well...that is not entirely truthful.  A more precise explanation is that one prefetch file is created per application from a specific file path.  When cmd.exe is run from C:\Windows\system32 one prefetch record is created.  However, if I copy cmd.exe to C:\Windows and execute it, a second prefetch file will be created.

From a detection/investigation perspective this hash can be useful in finding malware hiding in plain sight.  Often times attackers will name their malware as common Windows applications, putting their version in a different directory than the real thing (Ex: Placing svchost in C:\Windows instead of C:\Windows\system32).  If they are careless and execute the malware without cleaning up their tracks, there will be a conspicuous second prefetch record for svchost that will provide investigators with some attack details.

Similarly to the application name, the file path hash is stored inside the prefetch file.  This can again be used to check for simple manipulation of the prefetch file name.

NOTE: The majority of non-unicode values are stored in Little Endian, so when parsing/reading the values make sure you flip the bytes.

Application Run Count (Offset: 0x0D 4-bytes) 

One of the more useful pieces of information found in the prefetch file is the run count, found at Offset 0xD0).  The run count tells a forensicator how many times the application has been executed. Remember this value is stored in Little Endian, so this example shows the run count to be one.

Last Access Timestamp (Offset: 0x80 8-bytes)

The last really useful piece of information found in the main section of the prefetch file is the last accessed timestamp.  This value is of extreme importance during an investigation because it tells the investigator when the program was last executed.  This value is stored as a "FILETIME" object, which is describe by Microsoft as being "the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC)".  There are plenty of way to turn the hex value into an actual time (Ex: the hex editor I'm using automatically converts hex timestamps to the actual time, or you can use PowerShell to convert the value with .NET).

Christmas coming early...Thanks Microsoft!
Some of you may be familiar with the file structure of a prefetch file in previous versions of Windows.  If you are you are probably asking why the run count (Offset 0xD0 isn't directly following the timestamp (Offset 0x80) like it always has.  Well my friends, this is because Microsoft has decided to throw us a bone for whatever reason.  Prefetch files in Windows 8 contain not one timestamp, not two timestamps, but 8 Last File Accessed Timestamps!  Below I show a quick demonstration of how the Windows 8 prefetch files store the 8 timestamps.

2 Timestamps

Above is a screen shot of the same CMD.EXE prefetch file, except I ran the application an extra time to increase the run count (0xD0) to two times.  The important thing to notice is that the original timestamp has been shifted over to Offset 0x88, and the most recent timestamp has moved in to the 0x80 position.   Well this is interesting, but what about the other 64 bytes between the 2nd timestamp and the run count value?

8 Timstamps

After some trial and error testing I was able to determine that the Windows 8 prefetch files will store the 8 most recent last accessed timestamps.  Notice in the screenshot that the original time is still there, but it has been moved all the way down to the basement (Offset: 0xB8).  It is interesting to note that there is still 16 bytes of 0's.  What ever comes of that space?

What happens after 8?!?

Well that is a good question.  I have noticed that those 0's are changed after the timestamp slots a filled, but I have yet to determine what the value represents (If anyone knows or figures it out please let me know).  I am assuming it has something to do with the timestamps because the values seem to only appear after the 8 timestamp values have been created.

Conclusion
Well this concludes the first portion of my foray into the Windows 8 Prefetch File Structure.  My next post will discuss the different sections contained within prefetch files, and what information can be found in each section.