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 [email protected].