Kansa: Get-LogparserStack.ps1

Kansa is an incident response framework written in PowerShell, useful for data collection and analysis. Most of the analysis capabilities in Kansa require Logparser, which is a very handy tool for creating SQL-like queries over data sets that may be comprised of a single file or many files.

Because adversaries usually want to leave a small footprint, one technique for finding them is frequency analysis -- looking for outliers across many systems. This technique has been written about before. As such, most of the analysis tools in Kansa are scripts that stack-rank or perform frequency analysis of specific fields in a given data set. Some examples include:

• Get-ASEPImagePathMD5Stack.ps1
• Get-ASEPImagePathLaunchStringMD5UnsignedStack.ps1
• Get-ASEPImagePathLaunchStringMD5UnsignedTimeStack.ps1
• ...

And the list goes on. These script names are fairly descriptive, but they are a mouthful and they are not very flexible as they contain hardcoded Logparser queries with set field names.

Kansa needed a more flexible stack-ranking solution and now it has one.

Get-LogparserStack.ps1 can be used to perform frequency analysis against any delimited file or set of files, so long as the set all has the same schema and the same header row across each file. Unlike all other Kansa utilities, Get-LogparserStack.ps1 is interactive. After reading the first two lines of each input file and confirming that they all have the same header row, the script prompts the user for the field she wishes to pass to Logparser's COUNT() function, then the script prompts the user for the fields she wishes to GROUP BY.

Below is a screen shot of the script in action against a small set of Autorunsc data from five systems. The frequency analysis is against the "Image Path" field with both "Image Path" and MD5 being added to the GROUP BY clause. As you can see in the screen shot, the resulting query quickly bubbles up an outlier, a dll from one system does not match the same dll from the other four systems.

Figure 1: Get-Logparser.ps1 quickly shows that one dll is not like the others.

Get-LogparserStack.ps1 is a new utility and as such, may mature a bit in time. One potential feature would be to make it non-interactive, so it can be scripted.

As with nearly all of the scripts that make up Kansa, Get-LogparserStack.ps1 can be used in conjunction with Logparser.exe outside the framework to perform frequency analysis of any data set, providing the schemas match and each file in the set has a header row.

If you use it and encounter any bugs, please open an issue in Kansa's GitHub page.

Kansa: Get-AutorunscDeep.ps1 -- Taking Autorunsc to 11

I wanted to put up a quick post about a new Kansa collector I recently added -- Get-AutorunscDeep.ps1. Sysinternals' Autoruns is a great utility for finding auto-start extension points in Windows and one I've blogged about a number of times.

Kansa has had a collector that wraps around Autorunsc.exe from Sysinternals almost since I began writing Kansa in March of 2014. It's such a great little utility for enumerating so many persistence mechanisms in Windows, though by no means, does it cover all of them.

Get-AutorunscDeep.ps1 goes to 11. How so? There are two ways that Get-AutorunscDeep.ps1 improves on Autorunsc.exe alone.

1. Get-AutorunscDeep.ps1 includes code written by my friend @z4ns4tsu (who will be speaking at the SANS 2015 DFIR Summit) that calculates the Shannon Entropy of Autorunsc's Image Path property. As many of you well know, packed binaries are common in malware families and those binaries have higher entropy than many legit binaries, so knowing a file's entropy can be a useful lead generation tool when dealing with large amounts of data.
2. Get-AutorunscDeep.ps1 goes a step further than Autorunsc.exe alone for common interpreters that execute scripts such as cmd.exe, PowerShell.exe or wscript.exe that may call .bat, .ps1 or .vbs files repsectively. Below in Figure 1, I've run the latest version of Autorunsc.exe and saved the output to a csv file, then loaded that csv file into a PowerShell variable called $data, then I'm dumping the contents of $data for any entry that calls a PowerShell script:

Figure 1: Output of Autorunsc.exe for a PowerShell ASEP (Click to enlarge)

Note that in Figure 1, Autorunsc.exe provides hashes of the PowerShell.exe binary itself. I've worked investigations where adversaries have taken existing ASEP entries and modified the scripts that are called, planting their own malicious code in those scripts. If you've got an ASEP that runs via PowerShell, cmd.exe or wscript.exe on hundreds or thousands of hosts and you use Autorunsc.exe to collect that data, a few of the scripts called by that interpreter could have been modified by an attacker and you'd have no visibility into it via Autorunsc.exe alone.

Get-AutorunscDeep.ps1 solves this problem, in most cases, by adding a hash of the script called by the interpreter. So for ASEPs like cmd.exe, PowerShell.exe and wscript.exe that call scripts, you'll see the hash of the binary itself as Autorunsc.exe calculates it, and you'll get the hash of the script because Get-AutorunscDeep.ps1 will calculate it for you, assuming it can find and read the script. Below in Figure 2, is an example of what this looks like, the data was collected from the same host as above, but remotely using Kansa:

Figure 2: Output of Get-AutorunscDeep.ps1 for the same PowerShell ASEP (Click to enlarge)

Note the red marks in Figure 2 and apologies, I'm not a graphic artist. Get-AutorunscDeep.ps1 has added an MD5 hash for the Get-AutorunscDeep.ps1 script that the PowerShell executable in the above Scheduled Task is calling. You can also see the ShannonEntropy value for PowerShell.exe, another feature of Get-AutorunscDeep.ps1's output. Now consider the visibility this gives you if you have the same ASEP script deployed across thousands of hosts. Use Kansa's Get-AutorunscDeep.ps1 collector, in conjunction with Sysinternal's Autorunsc.exe, and you'll quickly be able to find versions of scripts that have been modified.

Kansa: Service related collectors and analysis

In my previous post on Kansa's Autoruns collectors and analysis scripts, I mentioned that the Get-Aurounsc.ps1 collector relies on Sysinternals' Autorunsc.exe to collect data on all of the Autostart Extension Points (ASEPs) that it has catalogued. Autorunsc and its GUI sibling, Autoruns, are great tools, but they are not comprehensive, there are other ASEPs that they don't catch, so Kansa includes a few additional modules that aim to collect additional ASEPs and additional data about ASEPs.

Get-SvcAll.ps1
Runs Get-WMIObject win32_service to collect details about all services. Output is saved as XML. Some of this same data is collected by Get-Autorunsc.ps1 above, however, this will pull additional properties for each service with some of them being specific to the type of service. If a service is running, you'll get its process id and the context it runs under (Local System, Local Service, etc.). There's even an InstallDate property, which is awesome, however, in my experience, it's never populated, which sucks.

For analysis of the data collected by Get-SvcAll.ps1, there are two very basic frequency analysis or stacking scripts as of this writing. They are Get-SvcAllStack.ps1 and Get-SvcStartNameStack.ps1. The former does its frequency analysis based on Service "Captions" and Pathnames. The Captions are the short friendly names you see when you look at the Services running on your system while the Pathnames include the path to the binary and any arguments. Here's an example from two systems where the Application Identity service has two different sets of command line arguments:

Click for larger image

Stacking by these properties across many hosts shows investigators services that may have the same Caption, but different binaries and arguments. This same kind of analysis is available in the Autoruns stacking scripts with the added benefit of stacking by file hash (e.g. MD5).

Get-SvcStartNameStack.ps1 stacks by Caption and StartName, the latter of which turns out to be the name of the account the service runs under.

Another Service analysis script, but not a stacker, is Get-SvcAllRunningAuto.ps1, which pulls the list of Services that were in a running state or set to start automatically when the Get-SvcAll.ps1 collector ran on the targets.

ASEPs not collected by Autorunsc:

As I mentioned above, Sysinternals' Autoruns and Autorunsc executables collect all the ASEPs they know to collect, but that is not the universe of ASEPs.

Windows Services can be configured to recover from failures. In my experience, restarting the service is the most common recovery option, but one option that adversaries can use is the "Run a Program" option as shown below:

Click for larger image

 

In the screen shot above, the Application Identity service is configured with a failure recovery response that will run a program called ServiceRecovery.exe from C:\ProgramData\Microsoft\ with the command line argument -L 443. This is a persistence mechanism that Autorunsc won't capture.

Kansa's Get-SvcFail.ps1 collector will collect service failure recovery information from all services. Kansa includes a few analysis scripts that will stack the service failure recovery data, but the most useful one is Get-SvcFailCmdLine.ps1, which returns the frequency count of the program and command line parameters from all the collected service failure information. The image below shows this data from a few thousand systems:

Click for larger image

In the example there are 129769 Service Failure entries, 75088 of them have the same program and command line arguments configured as a recovery option. Seems unlikely this is malicious.

In another smaller data set, the following data was returned:

Click for larger image

I include this screen shot because I've run into the customscript.cmd entry in multiple data sets and in all the cases I've investigated, I've not yet found a service that referenced customscript.cmd anywhere in the Services GUI, but you will see services reference it in the data of their Registry key values, like the following:

I've also searched file systems on hosts where I've seen this, but I've not found a file on disk called customScript.cmd. I wanted to mention it here in case you run across it. If you do see a reference to customscript.cmd that includes a path, you may have an adversary attempting to blend in with a common value.

The last Service related collector in Kansa, as of this writing, is Get-SvcTrigs.ps1, which collects another set of ASEPs that Autoruns does not collect, yet -- Service Triggers. Service Triggers are new with Windows 7 and later versions of Windows. They allow Windows Services to have more startup flexibility than the old Manual and Automatic startup modes. Now services can respond to the presence of specific hardware, group policy changes, networking events, etc. More information about Service Triggers can be found at the following links:

• http://msdn.microsoft.com/en-us/library/windows/desktop/dd405513(v=vs.85).aspx,
• http://blogs.windows.com/windows/archive/b/developers/archive/2009/10/26/windows7-trigger-start-services-part-1-introduction.aspx
• http://blogs.windows.com/windows/archive/b/developers/archive/2009/10/27/windows7-trigger-start-services-part-2-building-a-trigger-start-optimized-service.aspx.

Kansa includes a basic stacker for Service Triggers. Interpreting the data to determine what's normal and what's suspicious can be daunting and tedious. Searching on GUIDs can be of some help. Below is a frequency listing of Service Triggers from a relatively small sample, two systems.

Click for larger image

I have Service Trigger data from a few thousand machines, but I'm not at liberty to share it here, trust me when I say finding outliers is easier with a larger data set, but keep in mind, just because something is an outlier doesn't mean it's bad and the inverse is also true, just because something is common, it's not necessarily good.

There is one more ASEP that I know of that Autoruns won't catch, but that Kansa collects, but I'll save that for another post.

Kansa: Autoruns data and analysis

I want your input.

With the "Trailer Park" release of Kansa marking a milestone for the core framework, I'm turning my focus to analysis scripts for data collected by the current set of modules. As of this writing there are 18 modules, with some overlap between them. I'm seeking more ideas for analysis scripts to package with Kansa and am hopeful that you will submit comments with novel, implementable ideas.

Existing modules can be divided into three categories:

1. Auto Start Extension Points or ASEP data (persistence mechanisms)
2. Network data (netstat, dns cache)
3. Process data

In the interest of keeping posts to reasonable lengths, I'll limit the scope of each post to a small number of modules or collectors.

ASEP collectors and analysis scripts

Get-Autorunsc.ps1

Runs Sysinternals Autorunsc.exe with arguments to collect all ASEPs (that Autoruns knows about) across all user profiles, includes ASEP hashes, code signing information (Publisher) and command line arguments (LaunchString).

Current analysis scripts for Get-Autoruns.ps1 data:
Get-ASEPImagePathLaunchStringMD5Stack.ps1
Returns a frequency count of ASEPs aggregating on ImagePath, LaunchString and MD5 hash.

Get-ASEPImagePathLaunchStringMD5UnsignedStack.ps1
Same as previous stacker, but filters out signed ASEPs.

Get-ASEPImagePathLaunchStringPublisherStack.ps1
Returns frequency count of ASEPs aggregated on ImagePath, LaunchString and code signer.

Get-ASEPImagePathLuanchStringStack.ps1
Returns frequency count of ASEPs aggregated on ImagePath and LaunchString.

Get-ASEPImagePathLaunchStringUnsignedStack.ps1
Same as previous, but filters out signed code.

A picture is worth a few words, here's a sample of output for the previous analysis script for data from a couple systems:

Click for full size image

The image above shows the unsigned ASEPs on the two hosts, aggregated by ImagePath and LaunchString. You may want to know which host a given ASEP came from, however, including the host in the output above would break the aggregation. If you want to trace the 7-zip ASEP back to the host it was found on, copy the ImagePath or LaunchString value to the clipboard and from within this Output\Autorunsc\ path where the script was run, use the Powershell commandlet:

Select-String -SimpleMatch -Pattern "c:\program files (x86)\7-zip\7-zip.dll" *autoruns.tsv

The result will show the files and lines in those files, that match that pattern, each filename contains the hostname where the data came from, and the hostname is also in the file in the PSComputerName field.

Get-Autorunsc.ps1 returns the following fields:
Time: Last modification time from the Registry or file system for the EntryLocation
EntryLocation: Registry or file system location for the Entry
Entry: The entry itself
Enabled: Enabled or disabled status
Category: Autorun category
Description: A description of the Autorun
Publisher: The publisher from the code signing certificate, if present
ImagePath: File system path to the Autorun
Version: PE version info
LaunchString: Command line arguments or class id from the Registry
MD5: MD5 hash of the ImagePath file
SHA1: SHA1 hash of the ImagePath file
PESHA1: SHA1 Authenticode hash of the ImagePath file
PESHA256: SHA256 Authenticode hash of the Image Path file
SHA256: SHA256 hash of the ImagePath file
PSComputerName: The host where the entry came from
RunspaceId: The runspaceid for the Powershell job that collected the data
PSShowComputerName: A Boolean flag about whether or not the PSComputerName is included

These last three fields are artifacts of Powershell remoting.

Given the available data and the currently available analysis scripts, what other analysis capabilities make sense for the Get-Autorunsc.ps1 output?

One idea I have, is to take the idea explored in a previous post of mine, "Finding Evil: Automating Autoruns Analysis." This would be a script that takes an external dependency on a database of file hashes that are categorized as good, bad and unknown. The script would match hashes in the Get-Autorunsc.ps1 output, discarding the good, alerting on the bad and submitting unknowns to VirusTotal to see what, if anything is known about them. If VT says they are bad, insert them into the database and alert. If VT says they are good, insert them into the database and ignore them in future runs. If VT has no information on them, mark them for follow up and send them to Cuckoo sandbox or similar for analysis.

What ideas do you have? What would be helpful to you during IR?

Thanks for taking the time to read and comment with your thoughts and ideas.

If you found this information useful, please check out the SANS DFIR Summit where I'll be speaking about Kansa, IR and analysis in June.