Running Process Analysis - Part 1 Data Collection

Comparing artifacts to a baseline is one of the simplest ways to find indicators of compromise.  Basically, you have a known good baseline of data used to compare with host data.  If there are differences, then you might have an indicator of compromise to hunt down.  This basic analysis method can be used for many different host artifacts.  In this article, I will focus on running processes.

When evaluating processes, first think about what properties you might want to compare.  A simple comparison might just be the name of the process, but malware can be much stealthier than just running under its name like "evil_process".  One of the ways malware can disguise itself is by using common names but running from incorrect locations.  In this case the path of the process executable would be a good property to check.  What about an instance where the malware is actually infected a legitimate process.  I'm not talking about process hollowing.  I'll save that discussion for a later post.  In a simpler context, the malware could just overwrite the legitimate executable.  In this case we could analyze the hash of the executable.

So far we have decided to look at the name, path and hash of the running process objects.  How could we get this data using a PowerShell script?  Fortunately, PowerShell has a built-in cmdlet that will retrieve process objects for each running process on a host machine.  You could find this cmdlet using a search.  This search takes advantage of PowerShell's consistent naming convention and superior documentation.  These attributes combine to make PowerShell a very discoverable language.  Here is how we could search for a cmdlet to retrieve running processes.

To make sure the cmdlet does what you expect, you can review the documentation.  PowerShell's documentation is top notch and will not only give you a terrific description of the cmdlet, but descriptions of all of its parameters along with several examples.



Next, we need to test and see if the cmdlet provides all the properties we want to analyze.  From the previous discussion, what we want is name, executable path and a hash of the executable.  To discover all the properties of objects returned from our cmdlet, simply pipe the results to Get-Member.  This command will perform what's called "introspection" and display the object types along with their associated properties and methods.



Looking at the list of properties returned, we can see 2 of the 3 properties we need are contained in these process objects.  The only one not contained is the file hash of the executable.  That's ok, we can add that one in using a different cmdlet.  How could we find a cmdlet that will return a hash of file?  You guessed it with Get-Command.



Let's test this cmdlet out and find out what type of object it returns along with its properties.  We'll just run it against a file on our computer and pipe the results to Get-Member.



Looking at the properties, it appears the "hash" property contains the data we need for our script.

Now lets start putting this together.  We need to run Get-Process but only need 2 of the automatic object properties.  We also need a third custom property that will use Get-FileHash to generate the property value.  We can use the Select-Object cmdlet to select object properties along with creating our own custom properties.  We can pipe objects to Select-Object to enumerate the properties.  We'll start with the 2 automatic properties.



Now we need to add the custom property.  To add a custom property, simply add a hashtable to the list of properties.  Hashtables in PowerShell can be created with a special operator @{}.  Inside the curly braces place the key/value pairs.  This syntax is <key>=<value>.  For custom properties we need two keys: name and expression.  These can be abbreviated with n and e.  Name will be a string that is the name of the new property and expression will be a script block that returns the value for the new custom property.  So it looks like this:



Note the $_ is used to reference the current object in the pipeline.  Now we have the command all built out we can view the data right on the screen, save the results to variable or export the results to a file for analysis later.

In the next post we will add to the functionality of this command by exporting the data and comparing it to a baseline.

Why PowerShell

While there are some great tools out there for cyber threat hunting, most require some type of agent installed on the hosts or a centralized server to function effectively.  Unfortunately, host and sever configuration for many networks, especially those on DoD or other government systems is very controlled and the agents required for those tools simply can't be installed.  In those instances, cyber threat hunters must "live off the land" when collecting host data across networks.  This means we must use tools already present on hosts/servers to hunt for indicators of compromise.

Fortunately, most of the networks I deal with and many other networks are already administered using PowerShell.  This means that not only is PowerShell installed on most of the host machines, but the network is already configured to allow PowerShell commands to be remotely executed.  Since PowerShell rides on the .NET framework, there are many providers available to expose data critical to cyber threat hunting.  Additionally, PowerShell has the ability to leverage WMI so even if standard .NET classes or PowerShell's thousands of built-in cmdlets/functions don't expose the data you need, WMI probably does.

PowerShell was built to help administrators get back on the command line and automate tasks for management of network systems.  It is very well documented and supported.  Unfortunately, much of what I find online in the way of PowerShell support/examples revolve around system administration tasks and not threat hunting.  There are some unique challenges a threat hunter might have when leveraging PowerShell that a system administrator may not have.  For example, since a threat hunter is likely to be limited to whatever is installed on host systems, he or she may have to use older cmdlets or WMI if an older version of PowerShell is installed.  I have seen many cases where someone creates an amazing PowerShell script for threat hunting data collection but it doesn't function on all or some of the hosts in a network because it relies on functionality not available in older versions.  Threat hunters have to be flexible and not just rely on scripts that can't be customized for specific situations.  Additionally, threat hunters may have to work around network limitations.  Recently, I was on a network where the WinRM service was disabled on several machines.  While WinRM is necessary for standard PowerShell remoting, there is more than one way to skin a cat.  In this case we leveraged RPC using specific PowerShell cmdlets in Windows PowerShell v5.1.

This post was intended to just give you a taste of why PowerShell is an important tool for cyber threat hunting.  In future posts, I will show real-world examples and hypotheticals to illustrate how PowerShell can be leveraged for threat hunting.