Kansa: Powershell profiles potentially hazardous

On the very day I published my previous post, Kansa: Collecting WMI Event Consumer backdoors, Mark Russinovich announced the release of a new version of Autoruns that collects WMI related ASEPs. I had a chance to play around with it on a machine with a WMI Event Consumer, Event Filter and Filter-to-Consumer Binding configured and indeed, Autoruns now picks up the Event Consumers. I still recommend using Kansa's Get-WMIEvtFilter.ps1 and Get-WMIFltConBind.ps1 collector modules to grab the other two essential pieces that make Event Consumer backdoors possible. The Event Filter is the piece that will tell you what triggers the Event Consumer.

In this post I want to cover another "auto start extension point" or ASEP and it happens to be another that is not covered by Autoruns, yet. It also happens to be specific to Powershell. The Windows Powershell Profile is a script that runs, if present, each time a user or SYSTEM opens a Powershell shell. It's akin to a .bash_profile or similar shell profile on *nix systems.

Adversaries can modify an existing Powershell profile for either a user or the default system profile, planting code enabling them to maintain persistence or perform any task that Powershell is capable of given the context of the script (non-administrator users obviously being less capable than administrators or SYSTEM).

Kansa's Get-PSProfiles.ps1 collector will enumerate local accounts on remote systems and check each of them for Powershell profiles. Where Powershell profiles exist, Get-PSProfiles will collect them all in a zip file (it will also check for and collect the default Powershell profile). The zip file will then be sent back to the host where Kansa was run.

Powershell profiles can be located in a few different locations. For user profiles, they are in:

$env:userprofile\Documents\WindowsPowershell\Microsoft.Powershell_profile.ps1

And the default system profile is in:

$env:windir\System32\WindowsPowershell\v1.0\Microsoft.Powershell_profile.ps1

User Powershell profiles on XP systems are in a slightly different path and Kansa will not acquire them.

Unfortunately, there's no quick way of analyzing the collected profile scripts for malicious capabilities, at least not that I'm aware of. Analysts will have to spend time reviewing profiles for suspect code. This is a good time to mention that any ASEP script, not just Powershell profiles could be modified by adversaries to perform nefarious actions.

This is another painful reminder of the asymmetry of information security. Adversaries have many places to hide malicious bits and may only need one (or none, if they have a big enough key ring of credentials). Incident responders, depending on the nature of the incident, may have to review every known ASEP.

Enjoy the code review and happy hunting!

Kansa: Collecting WMI Event Consumer backdoors

In my previous post, Kansa: Service related collectors and analysis, I discussed the Windows Service related collectors and analysis capabilities in Kansa and noted that some of the collected data is not currently collected by Sysinternals' Autoruns.

Today I'll cover another persistence mechanism that Kansa collects, which is not currently collected by Autoruns; namely WMI Event Consumers. That link tells us "Event consumers are applications or scripts that request notification of events, and then perform tasks when specific events occur."
[Update: 2014-05-13] Mark Russinovich released a new version of Autoruns today that reports WMI information. I have not tested it yet. It will be interesting to see if it only reports data form Event Consumers and not the Event Filter, which tells what the trigger is.

For an event consumer to work, three elements are required:

• An Event Consumer -- this is the piece that performs some action
• An Event Filter -- an event query watching for defined activity -- this triggers the consumer
• A Filter-to-Consumer Binding -- this links the filter to the consumer

In my experience, WMI Event Consumers are not commonly used. So in many situations collecting the data and simply reviewing file sizes can tell you if something is worth investigating further. For example, I recently collected event consumer data from a few thousand hosts. Running the following Powershell command was enough to find which host contained a backdoor running from an event consumer:

ls *wmievtconsmr.xml | sort length -Descending | more

The output of that command follows, see if you can determine which host had the backdoor installed:

If you guessed DFWBOSSWEE01, congratulations, you may have the skills necessary to find WMI Event Consumer backdoors.

So what's in this file? Since it was collected with Kansa's Get-WMIEvtConsumer collector, which specifies its output should be written to an XML file, we can either open the XML file in a suitable editor or use the Powershell cmdlet Import-Clixml to read the file into a variable and examine the contents via the following commands:

$data = Import-Clixml .\DFWBOSSWEE01_wmievtconsmr.xml
$data | more

This command returns output like the following:

The most interesting bits above are those in the "CommandLineTemplate" property, which I've redacted a bit, but you can see there's a call to Powershell.exe and a long base 64 encoded string, which in this case was a Powershell encoded command, in essence, a script. We can decode that script via

[Convert]::ToBase64String()

Doing so would reveal that when this WMI Event Consumer is triggered, it connects to a remote site and downloads another script and runs it.

So how often is it triggered? What triggers it? To answer those questions, you'll have to review the data Kansa collected via Get-WMIEvtFilter.ps1. A consumer by itself is harmless, but if there's an Event Filter and a Filter-to-Consumer binding, then you've got all the ingredients needed for a WMI Event Consumer based backdoor.

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.