joeavanzato/trawler

PowerShell script to help Incident Responders discover potential adversary persistence mechanisms.

trawler's Issues

Pester-based Test Creation

Currently, the code base lacks any form of testing - Pester tests should be developed to help keep development stable and ensure that functionality is not impacted when making any changes.

Parse WMI Repository OBJECTS.DATA

For offline drive analysis, we cannot directly query CIM classes for obvious reasons.

Data related to WMI is stored in a few locations, provided below;
C:\Windows\System32\wbem\Repository\OBJECTS.DATA - Objects managed by WMI
C:\Windows\System32\wbem\Repository\INDEX.BTR - Index of files imported into OBJECTS.DATA
C:\Windows\System32\wbem\Repository\MAPPING*.MAP - Related OBJECTS.DATA with INDEX.BTR

Reference: https://netsecninja.github.io/dfir-notes/wmi-forensics/

A mechanism must be developed to, at minimum, extract CommandLine/Script FilterToConsumer Bindings to help assist alerting on suspicious CIM objects.

Multiple tools exist for this, taking slightly different approaches;

• https://github.com/woanware/wmi-parser - C# using Regex to scan lines for relevant strings
• https://github.com/davidpany/WMI_Forensics/blob/master/PyWMIPersistenceFinder.py - Python, original version of above.
• https://github.com/mandiant/flare-wmi - Multiple tools from Mandiant for parsing the entire WMI structure

Need to research the above and determine what is enough for this use-case - probably the basic regex scan will work 'good enough' for detecting the relevant FilterToConsumer bindings for offline boxes but need to test first.

Discover and Parse Certificate Files for offline analysis

Currently we are using PowerShell cmdlets to retrieve this information - need to get the same information from the files directly for use in deadbox analysis.

Json output instead of csv for detections

I have a thought on a somewhat easy way to transition from csv to json if that is something that you're interested in. In quite a few places where detections are created to be output they look similar to this:

$detection = [PSCustomObject]@{
            Name = 'Narrator Missing DLL is Present'
            Risk = 'Medium'
            Source = 'Windows Narrator'
            Technique = "T1546: Event Triggered Execution"
            Meta = "File: "+$item.FullName+", Created: "+$item.CreationTime+", Last Modified: "+$item.LastWriteTime
        }

I think we could take the Metadata and use the object directly so it will convert to json better. i.e.:

$detection = [PSCustomObject]@{
            Name = 'Narrator Missing DLL is Present'
            Risk = 'Medium'
            Source = 'Windows Narrator'
            Technique = "T1546: Event Triggered Execution"
            Meta =  $item | Select FullName, CreationTime, LastWriteTime
        }

This way we are able to convert the PSCustomObject into proper json using the headers that correlate to the object. I think a couple helper methods could be created to easily convert to either json or csv with somewhat minimal uplift.

Malformed character escape error running script

I got a script error when it was in the Registry parsing part.

parsing "C:\\Program Files (x86)\\Microsoft\\EdgeUpdate\\.*\psmachine.*\.dll" - Malformed \p{X} character escape.
At C:\Users\MyName\Downloads\trawler.ps1:11400 char:37
+ ...           if ($_.Value -match $default_hklm_com_lookups[$data.Name]){
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException

I'm not sure what the scanned string was, let me know how I can find out if you need help.

Additional persistence info

It's a bit dated by now but take a look at these launch points, in case there is something useful there that you aren't taking into account yet.

Parse BITS Queue Manager Database for offline analysis

Will likely use https://github.com/mgreen27/Invoke-BitsParser or a variation for this since the hard work has already been done. Just need to cherry-pick and refactor for my own needs on this one.

Allow specification of different Target Drive

In forensic investigations, investigators may end up mounting a target device from their analyst device - can we make Trawler work in these types of situations by allowing investigators to override the target drive?

For example, a drive may be mounted as 'D:', in which case the environment variables used throughout the script ($env:homedrive, $env:ProgramData, etc) will all be incorrect targets for analysis.

Regex Error while parsing

WARNING: Regex Error while parsing string: C:\\Program Files (x86)\Google\Update\.\psmachine..dll
WARNING: Please report this issue at https://github.com/joeavanzato/Trawler/issues

Variable Typo

On line 15,139 of trawler.ps1 there is a variable named "$finhert", which I believe should be "$finherit" (with an i) as it is in the following lines. This is in the function "Check-TerminalServicesInitialProgram".

Location of pwrshsip.dll in Check-TrustProviderDLL

In function Check-TrustProviderDLL the pwrshsip.dll can also be found in C:\Windows\System32.