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.
- 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.
- 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.
*** This is a Security Bloggers Network syndicated blog from trustedsignal -- blog authored by davehull. Read the original post at: https://trustedsignal.blogspot.com/2015/03/kansa-get-autorunscdeepps1-taking.html