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.
No comments:
Post a Comment