Trawler is a PowerShell script designed to help Incident Responders discover potential indicators of compromise on Windows hosts, primarily focused on persistence mechanisms including Scheduled Tasks, Services, Registry Modifications, Startup Items, Binary Modifications and more.
Currently, trawler can detect most of the persistence techniques specifically called out by MITRE and Atomic Red Team with more detections being added on a regular basis.
Just download and run trawler.ps1 from an Administrative PowerShell/cmd prompt - any detections will be displayed in the console as well as written to a CSV ('detections.csv') in the current working directory. The generated CSV will contain Detection Name, Source, Risk, Metadata and the relevant MITRE Technique.
Or use this one-liner from an Administrative PowerShell terminal:
iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/joeavanzato/Trawler/main/trawler.ps1'))
Certain detections have allow-lists built-in to help remove noise from default Windows configurations (10/2016/2019/2022) - expected Scheduled Tasks, Services, etc. Of course, it is always possible for attackers to hijack these directly and masquerade with great detail as a default OS process - take care to use multiple forms of analysis and detection when dealing with skillful adversaries.
If you have examples or ideas for additional detections, please feel free to submit an Issue or PR with relevant technical details/references - the code-base is a little messy right now and will be cleaned up over time.
Additionally, if you identify obvious false positives, please let me know by opening an issue or PR on GitHub! The obvious culprits for this will be non-standard COMs, Services or Tasks.
-scanoptions : Tab-through possible detections and select a sub-set using comma-delimited terms (eg. .\trawler.ps1 -scanoptions Services,Processes)
-hide : Suppress Detection output to console
-snapshot : Capture a "persistence snapshot" of the current system, defaulting to "$PSScriptRoot\snapshot.csv"
-snapshotpath : Define a custom file-path for saving snapshot output to.
-outpath : Define a custom file-path for saving detection output to (defaults to "$PSScriptRoot\detections.csv")
-loadsnapshot : Define the path for an existing snapshot file to load as an allow-list reference
-drivetarget : Define the variable for a mounted target drive (eg. .\trawler.ps1 -targetdrive "D:") - using this alone leads to an 'assumed homedrive' variable of C: for analysis purposes
PersistenceSniper is an awesome tool - I've used it heavily in the past - but there are a few key points that differentiate these utilities
Overall, these tools are extremely similar but approach the problem from slightly different angles - PersistenceSniper provides all information back to the analyst for review while Trawler tries to limit what is returned to only results that are likely to be potential adversary persistence mechanisms. As such, there is a possibility for false-negatives with trawler if an adversary completely mimics an allow-listed item.
Trawler supports loading an allow-list from a 'snapshot' - to do this requires two steps.
That's it - all relevant detections will then draw from the snapshot file as an allow-list to reduce noise and identify any potential changes to the base image that may have occurred.
(Allow-listing is implemented for most of the checks but not all - still being actively implemented)
Often during an investigation, analysts may end up mounting a new drive that represents an imaged Windows device - Trawler now partially supports scanning these mounted drives through the use of the '-drivetarget' parameter.
At runtime, Trawler will re-target temporary script-level variables for use in checking file-based artifacts and also will attempt to load relevant Registry Hives (HKLM\SOFTWARE, HKLM\SYSTEM, NTUSER.DATs, USRCLASS.DATs) underneath HKLM/HKU and prefixed by 'ANALYSIS_'. Trawler will also attempt to unload these temporarily loaded hives upon script completion.
As an example, if you have an image mounted at a location such as 'F:\Test' which contains the NTFS file system ('F:\Test\Windows', 'F:\Test\User', etc) then you can invoke trawler like below;
.\trawler.ps1 -drivetarget "F:\Test"
Please note that since trawler attempts to load the registry hive files from the drive in question, mapping a UNC path to a live remote device will NOT work as those files will not be accessible due to system locks. I am working on an approach which will handle live remote devices, stay tuned.
Most other checks will function fine because they are based entirely on reading registry hives or file-based artifacts (or can be converted to do so, such as directly reading Task XML as opposed to using built-in command-lets.)
Any limitations in checks when doing drive-retargeting will be discussed more fully in the GitHub Wiki.
Β
TODO
Please be aware that some of these are (of course) more detected than others - for example, we are not detecting all possible registry modifications but rather inspecting certain keys for obvious changes and using the generic MITRE technique "Modify Registry" where no other technique is applicable. For other items such as COM hijacking, we are inspecting all entries in the relevant registry section, checking against 'known-good' patterns and bubbling up unknown or mismatched values, resulting in a much more complete detection surface for that particular technique.
This tool would not exist without the amazing InfoSec community - the most notable references I used are provided below.
acltoolkit
is an ACL abuse swiss-army knife. It implements multiple ACL abuses.
pip install acltoolkit-ad
or
git clone https://github.com/zblurx/acltoolkit.git
cd acltoolkit
make
usage: acltoolkit [-h] [-debug] [-hashes LMHASH:NTHASH] [-no-pass] [-k] [-dc-ip ip address] [-scheme ldap scheme]
target {get-objectacl,set-objectowner,give-genericall,give-dcsync,add-groupmember,set-logonscript} ...
ACL abuse swiss-army knife
positional arguments:
target [[domain/]username[:password]@]<target name or address>
{get-objectacl,set-objectowner,give-genericall,give-dcsync,add-groupmember,set-logonscript}
Action
get-objectacl Get Object ACL
set-objectowner Modify Object Owner
give-genericall Grant an object GENERIC ALL on a targeted object
give-dcsync Grant an object DCSync capabilities on the domain
add-groupmember Add Member to Group
set-logonscript Change Logon Sript of User
options :
-h, --help show this help message and exit
-debug Turn DEBUG output ON
-no-pass don't ask for password (useful for -k)
-k Use Kerberos authentication. Grabs credentials from ccache file (KRB5CCNAME) based on target parameters. If valid credentials cannot be found, it will use the ones specified in the
command line
-dc-ip ip address IP Address of the domain controller. If omitted it will use the domain part (FQDN) specified in the target parameter
-scheme ldap scheme
authentication:
-hashes LMHASH:NTHASH
NTLM hashes, format is LMHASH:NTHAS H
$ acltoolkit get-objectacl -h
usage: acltoolkit target get-objectacl [-h] [-object object] [-all]
options:
-h, --help show this help message and exit
-object object Dump ACL for <object>. Parameter can be a sAMAccountName, a name, a DN or an objectSid
-all List every ACE of the object, even the less-interesting ones
The get-objectacl
will take a sAMAccountName, a name, a DN or an objectSid as input with -object
and will list Sid, Name, DN, Class, adminCount, LogonScript configured, Primary Group, Owner and DACL of it. If no parameter supplied, will list informations about the account used to authenticate.
$ acltoolkit waza.local/jsmith:Password#123@192.168.56.112 get-objectacl
Sid : S-1-5-21-267175082-2660600898-836655089-1103
Name : waza\John Smith
DN : CN=John Smith,CN=Users,DC=waza,DC=local
Class : top, person, organizationalPerson, user
adminCount : False
Logon Script
scriptPath : \\WAZZAAAAAA\OCD\test.bat
msTSInitialProgram: \\WAZZAAAAAA\OCD\test.bat
PrimaryGroup
Sid : S-1-5-21-267175082-2660600898-836655089-513
Name : waza\Domain Users
DN : CN=Domain Users,OU=Builtin Groups,DC=waza,DC=local
[...]
OwnerGroup
Sid : S-1-5-21-267175082-2660600898-836655089-512
Name : waza\Domain Admins
Dacl
ObjectSid : S-1-1-0
Name : Everyone
AceType : ACCESS_ALLOWED_OBJECT_ACE
Ac cessMask : 256
ADRights : EXTENDED_RIGHTS
IsInherited : False
ObjectAceType : User-Change-Password
[...]
ObjectSid : S-1-5-32-544
Name : BUILTIN\Administrator
AceType : ACCESS_ALLOWED_ACE
AccessMask : 983485
ADRights : WRITE_OWNER, WRITE_DACL, GENERIC_READ, DELETE, EXTENDED_RIGHTS, WRITE_PROPERTY, SELF, CREATE_CHILD
IsInherited : True
$ acltoolkit set-objectowner -h
usage: acltoolkit target set-objectowner [-h] -target-sid target_sid [-owner-sid owner_sid]
options:
-h, --help show this help message and exit
-target-sid target_sid
Object Sid targeted
-owner-sid owner_sid New Owner Sid
The set-objectowner
will take as input a target sid and an owner sid, and will change the owner of the target object.
$ acltoolkit give-genericall -h
usage: acltoolkit target give-genericall [-h] -target-sid target_sid [-granted-sid owner_sid]
options:
-h, --help show this help message and exit
-target-sid target_sid
Object Sid targeted
-granted-sid owner_sid
Object Sid granted GENERIC_ALL
The give-genericall
will take as input a target sid and a granted sid, and will change give GENERIC_ALL DACL to the granted SID to the target object.
$ acltoolkit give-dcsync -h
usage: acltoolkit target give-dcsync [-h] [-granted-sid owner_sid]
options:
-h, --help show this help message and exit
-granted-sid owner_sid
Object Sid granted DCSync capabilities
The give-dcsync
will take as input a granted sid, and will change give DCSync capabilities to the granted SID.
$ acltoolkit add-groupmember -h
usage: acltoolkit target add-groupmember [-h] [-user user] -group group
options:
-h, --help show this help message and exit
-user user User added to a group
-group group Group where the user will be added
The add-groupmember
will take as input a user sAMAccountName and a group sAMAccountName, and will add the user to the group
$ acltoolkit set-logonscript -h
usage: acltoolkit target set-logonscript [-h] -target-sid target_sid -script-path script_path [-logonscript-type logonscript_type]
options:
-h, --help show this help message and exit
-target-sid target_sid
Object Sid of targeted user
-script-path script_path
Script path to set for the targeted user
-logonscript-type logonscript_type
Logon Script variable to change (default is scriptPath)
The set-logonscript
will take as input a target sid and a script path, and will the the Logon Script path of the targeted user to the script path specified.