Login
Β
MR.Handler is a specialized tool designed for responding to security incidents on Linux systems. It connects to target systems via SSH to execute a range of diagnostic commands, gathering crucial information such as network configurations, system logs, user accounts, and running processes. At the end of its operation, the tool compiles all the gathered data into a comprehensive HTML report. This report details both the specifics of the incident response process and the current state of the system, enabling security analysts to more effectively assess and respond to incidents.
FreshRSS $ pip3 install colorama
$ pip3 install paramiko
$ git clone https://github.com/emrekybs/BlueFish.git
$ cd MrHandler
$ chmod +x MrHandler.py
$ python3 MrHandler.py
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.
Bashfuscator is a modular and extendable Bash obfuscation framework written in Python 3. It provides numerous different ways of making Bash one-liners or scripts much more difficult to understand. It accomplishes this by generating convoluted, randomized Bash code that at runtime evaluates to the original input and executes it. Bashfuscator makes generating highly obfuscated Bash commands and scripts easy, both from the command line and as a Python library.
The purpose of this project is to give Red Team the ability to bypass static detections on a Linux system, and the knowledge and tools to write better Bash obfuscation techniques.
This framework was also developed with Blue Team in mind. With this framework, Blue Team can easily generate thousands of unique obfuscated scripts or commands to help create and test detections of Bash obfuscation.
This is a list of all the media (i.e. youtube videos) or links to slides about Bashfuscator.
Though Bashfuscator does work on UNIX systems, many of the payloads it generates will not. This is because most UNIX systems use BSD style utilities, and Bashfuscator was built to work with GNU style utilities. In the future BSD payload support may be added, but for now payloads generated with Bashfuscator should work on GNU Linux systems with Bash 4.0 or newer.
Bashfuscator requires Python 3.6+.
On a Debian-based distro, run this command to install dependencies:
sudo apt-get update && sudo apt-get install python3 python3-pip python3-argcomplete xclip
On a RHEL-based distro, run this command to install dependencies:
sudo dnf update && sudo dnf install python3 python3-pip python3-argcomplete xclip
Then, run these commands to clone and install Bashfuscator:
git clone https://github.com/Bashfuscator/Bashfuscator
cd Bashfuscator
python3 setup.py install --userOnly Debian and RHEL based distros are supported. Bashfuscator has been tested working on some UNIX systems, but is not supported on those systems.
For simple usage, just pass the command you want to obfuscate with -c, or the script you want to obfuscate with -f.
$ bashfuscator -c "cat /etc/passwd"
[+] Mutators used: Token/ForCode -> Command/Reverse
[+] Payload:
${@/l+Jau/+<b=k } p''"r"i""n$'t\u0066' %s "$( ${*%%Frf\[4?T2 } ${*##0\!j.G } "r"'e'v <<< ' "} ~@{$" ") } j@C`\7=-k#*{$ "} ,@{$" ; } ; } ,,*{$ "}] } ,*{$ "} f9deh`\>6/J-F{\,vy//@{$" niOrw$ } QhwV#@{$ [NMpHySZ{$" s% "f"'"'"'4700u\n9600u\r'"'"'$p { ; } ~*{$ "} 48T`\PJc}\#@{$" 1#31 "} ,@{$" } D$y?U%%*{$ 0#84 *$ } Lv:sjb/@{$ 2#05 } ~@{$ 2#4 }*!{$ } OGdx7=um/X@RA{\eA/*{$ 1001#2 } Scnw:i/@{$ } ~~*{$ 11#4 "} O#uG{\HB%@{$" 11#7 "} ^^@{$" 011#2 "} ~~@{$" 11#3 } L[\h3m/@{$ "} ~@{$" 11#2 } 6u1N.b!\b%%*{$ } YCMI##@{$ 31#5 "} ,@{$" 01#7 } (\}\;]\//*{$ } %#6j/?pg%m/*{$ 001#2 "} 6IW]\p*n%@{$" } ^^@{$ 21#7 } !\=jy#@{$ } tz}\k{\v1/?o:Sn@V/*{$ 11#5 ni niOrw rof ; "} ,,@{$" } MD`\!\]\P%%*{$ ) }@{$ a } ogt=y%*{$ "@$" /\ } {\nZ2^##*{$ \ *$ c }@{$ } h;|Yeen{\/.8oAl-RY//@{$ p *$ "}@{$" t } zB(\R//*{$ } mX=XAFz_/9QKu//*{$ e *$ s } ~~*{$ d } ,*{$ } 2tgh%X-/L=a_r#f{\//*{$ w } {\L8h=@*##@{$ "} W9Zw##@{$" (=NMpHySZ ($" la'"'"''"'"'"v"'"'"''"'"''"'"'541\'"'"'$ } &;@0#*{$ ' "${@}" "${@%%Ij\[N }" ${@~~ } )" ${!*} | $@ $'b\u0061'''sh ${*//J7\{=.QH }
[+] Payload size: 1232 charactersYou can copy the obfuscated payload to your clipboard with --clip, or write it to a file with -o.
For more advanced usage, use the --choose-mutators flag, and specify exactly what obfuscation modules, or Mutators, you want to use in what order. Use also the -s argument to control the level of obfuscation used.
bashfuscator -c "cat /etc/passwd" --choose-mutators token/special_char_only compress/bzip2 string/file_glob -s 1
[+] Payload:
"${@#b }" "e"$'\166'"a""${@}"l "$( ${!@}m''$'k\144'''ir -p '/tmp/wW'${*~~} ;$'\x70'"${@/AZ }"rin""tf %s 'MxJDa0zkXG4CsclDKLmg9KW6vgcLDaMiJNkavKPNMxU0SJqlJfz5uqG4rOSimWr2A7L5pyqLPp5kGQZRdUE3xZNxAD4EN7HHDb44XmRpN2rHjdwxjotov9teuE8dAGxUAL'> '/tmp/wW/?
??'; prin${@#K. }tf %s 'wYg0iUjRoaGhoNMgYgAJNKSp+lMGkx6pgCGRhDDRGMNDTQA0ABoAAZDQIkhCkyPNIm1DTQeppjRDTTQ8D9oqA/1A9DjGhOu1W7/t4J4Tt4fE5+isX29eKzeMb8pJsPya93' > '/tmp/wW/???
' "${@,, }" &&${*}pri''\n${*,}tf %s 'RELKWCoKqqFP5VElVS5qmdRJQelAziQTBBM99bliyhIQN8VyrjiIrkd2LFQIrwLY2E9ZmiSYqay6JNmzeWAklyhFuph1mXQry8maqHmtSAKnNr17wQlIXl/ioKq4hMlx76' >'/tmp/wW/??
';"${@, }" $'\x70'rintf %s 'clDkczJBNsB1gAOsW2tAFoIhpWtL3K/n68vYs4Pt+tD6+2X4FILnaFw4xaWlbbaJBKjbGLouOj30tcP4cQ6vVTp0H697aeleLe4ebnG95jynuNZvbd1qiTBDwAPVLT tCLx' >'/tmp/wW/?
?' ; ${*/~} p""${@##vl }ri""n''tf %s ' pr'"'"'i'"'"'$'"'"'n\x74'"'"'f %s "$( prin${*//N/H }tf '"'"'QlpoOTFBWSZTWVyUng4AA3R/gH7z/+Bd/4AfwAAAD8AAAA9QA/7rm7NzircbE1wlCTBEamT1PKekxqYIA9TNQ' >'/tmp/wW/????' "${@%\` }" ;p''r""i$'\x6e'''$'\164'"f" %s 'puxuZjSK09iokSwsERuYmYxzhEOARc1UjcKZy3zsiCqG5AdYHeQACRPKqVPIqkxaQnt/RMmoLKqCiypS0FLaFtirJFqQtbJLUVFoB/qUmEWVKxVFBYjHZcIAYlVRbkgWjh' >'/tmp/wW/?
' ${*};"p"rin''$'\x74f' %s 'Gs02t3sw+yFjnPjcXLJSI5XTnNzNMjJnSm0ChZQfSiFbxj6xzTfngZC4YbPvaCS3jMXvYinGLUWVfmuXtJXX3dpu379mvDn917Pg7PaoCJm2877OGzLn0y3FtndddpDohg'>'/tmp/wW/?
?
' && "${@^^ }" pr""intf %s 'Q+kXS+VgQ9OklAYb+q+GYQQzi4xQDlAGRJBCQbaTSi1cpkRmZlhSkDjcknJUADEBeXJAIFIyESJmDEwQExXjV4+vkDaHY/iGnNFBTYfo7kDJIucUES5mATqrAJ/KIyv1UV'> '/tmp/wW/
???' ${*^}; ${!@} "${@%%I }"pri""n$'\x74f' %s '1w6xQDwURXSpvdUvYXckU4UJBclJ4OA'"'"' |""b${*/t/\( }a\se$'"'"'6\x34'"'"' -d| bu${*/\]%}nzi'"'"'p'"'"'${!@}2 -c)" $@ |$ {@//Y^ } \ba\s"h" ' > '/tmp/wW/
??
' ${@%b } ; pr"i"\ntf %s 'g8oZ91rJxesUWCIaWikkYQDim3Zw341vrli0kuGMuiZ2Q5IkkgyAAJFzgqiRWXergULhLMNTjchAQSXpRWQUgklCEQLxOyAMq71cGgKMzrWWKlrlllq1SXFNRqsRBZsKUE' > '/tmp/wW/??
?'"${@//Y }" ;$'c\141t' '/tmp/wW'/???? ${*/m};"${@,, }" $'\162'\m '/tmp/wW'/???? &&${@^ }rmd\ir '/tmp/wW'; ${@^^ } )" "${@}"
[+] Payload size: 2062 charactersFor more detailed usage and examples, please refer to the documentation.
Adding new obfuscation methods to the framework is simple, as Bashfuscator was built to be a modular and extendable framework. Bashfuscator's backend does all the heavy lifting so you can focus on writing robust obfuscation methods (documentation on adding modules coming soon).
Bashfuscator was created for educational purposes only, use only on computers or networks you have explicit permission to do so. The Bashfuscator team is not responsible for any illegal or malicious acts preformed with this project.
Mimicry is a security tool developed by Chaitin Technology for active deception in exploitation and post-exploitation.
Active deception can live migrate the attacker to the honeypot without awareness. We can achieve a higher security level at a lower cost with Active deception.
English | δΈζζζ‘£
docker info
docker-compose version
docker-compose build
docker-compose up -d
update config.yaml,replace ${honeypot_public_ip} to the public IP of honeypot service
./mimicry-tools webshell -c config.yaml -t php -p webshell_path
| Tool | Description |
|---|---|
| Web-Deception | Fake vulnerabilities in web applications |
| Webshell-Deception | live migrate webshell to the honeypot |
| Shell-Deception | live migrate ReverseShell/BindShell to the honeypot |
sandfly-entropyscan is a utility to quickly scan files or running processes and report on their entropy (measure of randomness) and if they are a Linux/Unix ELF type executable. Some malware for Linux is packed or encrypted and shows very high entropy. This tool can quickly find high entropy executable files and processes which often are malicious.
Entropy is a measure of randomness. For binary data 0.0 is not-random and 8.0 is perfectly random. Good crypto looks like random white noise and will be near 8.0. Good compression removes redundant data making it appear more random than if it was uncompressed and usually will be 7.7 or above.
A lot of malware executables are packed to avoid detection and make reverse engineering harder. Most standard Linux binaries are not packed because they aren't trying to hide what they are. Searching for high entropy files is a good way to find programs that could be malicious just by having these two attributes of high entropy and executable.
Usage of sandfly-entropyscan:
-csv output results in CSV format (filename, path, entropy, elf_file [true|false], MD5, SHA1, SHA256, SHA512)
-delim change the default delimiter for CSV files of "," to one of your choosing ("|", etc.)
-dir string directory name to analyze
-file string full path to a single file to analyze
-proc check running processes (defaults to ELF only check)
-elf only check ELF executables
-entropy float show any file/process with entropy greater than or equal to this value (0.0 min - 8.0 max, defaults 0 to show all files)
-version show version and exit
Search for any file that is executable under /tmp:
sandfly-entropyscan -dir /tmp -elf
Search for high entropy (7.7 and higher) executables (often packed or encrypted) under /var/www:
sandfly-entropyscan -dir /var/www -elf -entropy 7.7
Generates entropy and cryptographic hashes of all running processes in CSV format:
sandfly-entropyscan -proc -csv
Search for any process with an entropy higher than 7.7 indicating it is likely packed or encrypted:
sandfly-entropyscan -proc -entropy 7.7
Generate entropy and cryptographic hash values of all files under /bin and output to CSV format (for instance to save and compare hashes):
sandfly-entropyscan -dir /bin -csv
Scan a directory for all files (ELF or not) with entropy greater than 7.7: (potentially large list of files that are compressed, png, jpg, object files, etc.)
sandfly-entropyscan -dir /path/to/dir -entropy 7.7
Quickly check a file and generate entropy, cryptographic hashes and show if it is executable:
sandfly-entropyscan -file /dev/shm/suspicious_file
Do spot checks on systems you think have a malware issue. Or you can automate the scan so you will get an output if we find something show up that is high entropy in a place you didn't expect. Or simply flag any executable ELF type file that is somewhere strange (e.g. hanging out in /tmp or under a user's HTML directory). For instance:
Did a high entropy binary show up under the system /var/www directory? Could be someone put a malware dropper on your website:
sandfly-entropyscan -dir /var/www -elf -entropy 7.7
Setup a cron task to scan your /tmp, /var/tmp, and /dev/shm directories for any kind of executable file whether it's high entropy or not. Executable files under tmp directories can frequently be a malware dropper.
sandfly-entropyscan -dir /tmp -elf
sandfly-entropyscan -dir /var/tmp -elf
sandfly-entropyscan -dir /dev/shm -elf
Setup another cron or automated security sweep to spot check your systems for highly compressed or encrypted binaries that are running:
sandfly-entropyscan -proc -entropy 7.7
git clone https://github.com/sandflysecurity/sandfly-entropyscan.git
go build
./sandfly-entropyscan
There are a some basic build scripts that build for various platforms. You can use these to build or modify to suit. For Incident Responders, it might be useful to keep pre-compiled binaries ready to go on your investigation box.
build.sh - Build for current OS you're running on when you execute it.
We use a simple method for seeing if a file may be an executable ELF type. We can spot ELF format files for multiple platforms. Even if malware has Intel/AMD, MIPS and Arm dropper binaries we will still be able to spot all of them.
It's possible to flag a legitimate binary that has a high entropy because of how it was compiled, or because it was packed for legitimate reasons. Other files like .zip, .gz, .png, .jpg and such also have very high entropy because they are compressed formats. Compression removes redundancy in a file which makes it appear to be more random and has higher entropy.
On Linux, you may find some kinds of libraries (.so files) get flagged if you scan library directories.
However, it is our experience that executable binaries that also have high entropy are often malicious. This is especially true if you find them in areas where executables normally shouldn't be (such as again tmp or html directories).
The entropy calculation requires reading in all the bytes of the file and tallying them up to get a final number. It can use a lot of CPU and disk I/O, especially on very large file systems or very large files. The program has an internal limit where it won't calculate entropy on any file over 2GB, nor will it try to calculate entropy on any file that is not a regular file type (e.g. won't try to calculate entropy on devices like /dev/zero).
Then we calculate MD5, SHA1, SHA256 and SHA512 hashes. Each of these requires going over the file as well. It's reasonable speed on modern systems, but if you are crawling a very large file system it can take some time to complete.
If you tell the program to only look at ELF files, then the entropy/hash calculations won't happen unless it is an ELF type and this will save a lot of time (e.g. it will ignore massive database files that aren't executable).
If you want to automate this program, it's best to not have it crawl the entire root file system unless you want that specifically. A targeted approach will be faster and more useful for spot checks. Also, use the ELF flag as that will drastically reduce search times by only processing executable file types.
For incident responders, running sandfly-entropyscan against the entire top-level "/" directory may be a good idea just to quickly get a list of likely packed candidates to investigate. This will spike CPU and disk I/O. However, you probably don't care at that point since the box has been mining cryptocurrency for 598 hours anyway by the time the admins noticed.
Again, use the ELF flag to get to the likely problem candidate executables and ignore the noise.
There is a script called scripts/testfiles.sh that will make two files. One will be full of random data and one will not be random at all. When you run the script it will make the files and run sandfly-entropyscan in executable detection mode. You should see two files. One with very high entropy (at or near 8.0) and one full of non-random data that should be at 0.00 for low entropy. Example:
./testfiles.sh
Creating high entropy random executable-like file in current directory.
Creating low entropy executable-like file in current directory.
high.entropy.test, entropy: 8.00, elf: true
low.entropy.test, entropy: 0.00, elf: true
You can also load up the upx utility and compress an executable and see what values it returns.
Sandfly Security produces an agentless endpoint detection and incident response platform (EDR) for Linux. Automated entropy checks are just one of thousands of things we search for to find intruders without loading any software on your Linux endpoints.
Get a free license and learn more below:
https://www.sandflysecurity.com @SandflySecurity
With this application, it is aimed to accelerate the incident response processes by collecting information in linux operating systems.
Information is collected in the following contents.
/etc/passwd
cat /etc/group
cat /etc/sudoers
lastlog
cat /var/log/auth.log
uptime/proc/meminfo
ps aux
/etc/resolv.conf
/etc/hosts
iptables -L -v -n
find / -type f -size +512k -exec ls -lh {}/;
find / -mtime -1 -ls
ip a
netstat -nap
arp -a
echo $PATH
git clone https://github.com/anil-yelken/pylirt
cd pylirt
sudo pip3 install paramiko
The following information should be specified in the cred_list.txt file:
IP|Username|Password
sudo python3 plirt.py
https://twitter.com/anilyelken06
https://medium.com/@anilyelken
With this application, it is aimed to accelerate the incident response processes by collecting information in windows operating systems via winrm.
Information is collected in the following contents.
IP Configuration
Users
Groups
Tasks
Services
Task Scheduler
Registry Control
Active TCP & UDP ports
File sharing
Files
Firewall Config
Sessions with other Systems
Open Sessions
Log Entries
git clone https://github.com/anil-yelken/pywirt
cd pywirt
pip3 install pywinrm
The following information should be specified in the cred_list.txt file:
IP|Username|Password
https://twitter.com/anilyelken06
https://medium.com/@anilyelken
ShoMon is a Shodan alert feeder for TheHive written in GoLang. With version 2.0, it is more powerful than ever!
Can be used as Webhook OR Stream listener
Utilizes shadowscatcher/shodan (fantastic work) for Shodan interaction.
Console logs are in JSON format and can be ingested by any other further log management tools
CI/CD via Github Actions ensures that a proper Release with changelogs, artifacts, images on ghcr and dockerhub will be provided
Provides a working docker-compose file file for TheHive, dependencies
Super fast and Super mini in size
Complete code refactoring in v2.0 resulted in more modular, maintainable code
Via conf file or environment variables alert specifics including tags, type, alert-template can be dynamically adjusted. See config file.
Full banner can be included in Alert with direct link to Shodan Finding.
IP is added to observables
Parameters should be provided via conf.yaml or environment variables. Please see config file and docker-compose file
After conf or environment variables are set simply issue command:
./shomon
go build . go build -ldflags="-s -w" . could be used to customize compilation and produce smaller binary.docker pull ghcr.io/kaansk/shomondocker pull kaansk/shomondocker build -t shomon .docker run -it shomondocker-compose run -d
|
PersistenceSniper is a Powershell script that can be used by Blue Teams, Incident Responders and System Administrators to hunt persistences implanted in Windows machines. The script is also available on Powershell Gallery. |
Why writing such a tool, you might ask. Well, for starters, I tried looking around and I did not find a tool which suited my particular use case, which was looking for known persistence techniques, automatically, across multiple machines, while also being able to quickly and easily parse and compare results. Sure, Sysinternals' Autoruns is an amazing tool and it's definitely worth using, but, given it outputs results in non-standard formats and can't be run remotely unless you do some shenanigans with its command line equivalent, I did not find it a good fit for me. Plus, some of the techniques I implemented so far in PersistenceSniper have not been implemented into Autoruns yet, as far as I know. Anyway, if what you need is an easy to use, GUI based tool with lots of already implemented features, Autoruns is the way to go, otherwise let PersistenceSniper have a shot, it won't miss it :)
Using PersistenceSniper is as simple as:
PS C:\> git clone https://github.com/last-byte/PersistenceSniper
PS C:\> Import-Module .\PersistenceSniper\PersistenceSniper\PersistenceSniper.psd1
PS C:\> Find-AllPersistence
If you need a detailed explanation of how to use the tool or which parameters are available and how they work, PersistenceSniper's Find-AllPersistence supports Powershell's help features, so you can get detailed, updated help by using the following command after importing the module:
Get-Help -Name Find-AllPersistence -Full
PersistenceSniper's Find-AllPersistence returns an array of objects of type PSCustomObject with the following properties:
PS C:\> Find-AllPersistence | Where-Object "Access Gained" -EQ "System"
Of course, being PersistenceSniper a Powershell-based tool, some cool tricks can be performed, like passing its output to Out-GridView in order to have a GUI-based table to interact with.
As already introduced, Find-AllPersistence outputs an array of Powershell Custom Objects. Each object has the following properties, which can be used to filter, sort and better understand the different techniques the function looks for:
Find-AllPersistence without a -ComputerName parameter, PersistenceSniper will run only on the local machine. Otherwise it will run on the remote computer(s) you specify;Let's face it, hunting for persistence techniques also comes with having to deal with a lot of false positives. This happens because, while some techniques are almost never legimately used, many indeed are by legit software which needs to autorun on system boot or user login.
This poses a challenge, which in many environments can be tackled by creating a CSV file containing known false positives. If your organization deploys systems using something like a golden image, you can run PersistenceSniper on a system you just created, get a CSV of the results and use it to filter out results on other machines. This approach comes with the following benefits:
Find-AllPersistence comes with parameters allowing direct output of the findings to a CSV file, while also being able to take a CSV file as input and diffing the results.
PS C:\> Find-AllPersistence -DiffCSV false_positives.csv
Β
One cool way to use PersistenceSniper my mate Riccardo suggested is to use it in an incremental way: you could setup a Scheduled Task which runs every X hours, takes in the output of the previous iteration through the -DiffCSV parameter and outputs the results to a new CSV. By keeping track of the incremental changes, you should be able to spot within a reasonably small time frame new persistences implanted on the machine you are monitoring.
The topic of persistence, especially on Windows machines, is one of those which see new discoveries basically every other week. Given the sheer amount of persistence techniques found so far by researchers, I am still in the process of implementing them. So far the following 31 techniques have been implemented successfully:
The techniques implemented in this script have already been published by skilled researchers around the globe, so it's right to give credit where credit's due. This project wouldn't be around if it weren't for:
I'd also like to give credits to my fellow mates at @APTortellini, in particular Riccardo Ancarani, for the flood of ideas that helped it grow from a puny text-oriented script to a full-fledged Powershell tool.
This project is under the CC0 1.0 Universal license. TL;DR: you can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
