Login
sttr is command line software that allows you to quickly run various transformation operations on the string.
FreshRSS // With input prompt
sttr
// Direct input
sttr md5 "Hello World"
// File input
sttr md5 file.text
sttr base64-encode image.jpg
// Reading from different processor like cat, curl, printf etc..
echo "Hello World" | sttr md5
cat file.txt | sttr md5
// Writing output to a file
sttr yaml-json file.yaml > file-output.json
You can run the below curl to install it somewhere in your PATH for easy use. Ideally it will be installed at ./bin folder
curl -sfL https://raw.githubusercontent.com/abhimanyu003/sttr/main/install.sh | sh
curl -sS https://webi.sh/sttr | sh
curl.exe https://webi.ms/sttr | powershell
See here
If you are on macOS and using Homebrew, you can install sttr with the following:
brew tap abhimanyu003/sttr
brew install sttr
sudo snap install sttr
yay -S sttr-bin
scoop bucket add sttr https://github.com/abhimanyu003/scoop-bucket.git
scoop install sttr
go install github.com/abhimanyu003/sttr@latest
Download the pre-compiled binaries from the Release! page and copy them to the desired location.
sttr command.// For interactive menu
sttr
// Provide your input
// Press two enter to open operation menu
// Press `/` to filter various operations.
// Can also press UP-Down arrows select various operations.
sttr -h
// Example
sttr zeropad -h
sttr md5 -h
sttr {command-name} {filename}
sttr base64-encode image.jpg
sttr md5 file.txt
sttr md-html Readme.md
sttr yaml-json file.yaml > file-output.json
curl https: //jsonplaceholder.typicode.com/users | sttr json-yaml
sttr md5 hello | sttr base64-encode
echo "Hello World" | sttr base64-encode | sttr md5
These are the few locations where sttr was highlighted, many thanks to all of you. Please feel free to add any blogs/videos you may have made that discuss sttr to the list.
ROPDump is a tool for analyzing binary executables to identify potential Return-Oriented Programming (ROP) gadgets, as well as detecting potential buffer overflow and memory leak vulnerabilities.
<binary>: Path to the binary file for analysis.-s, --search SEARCH: Optional. Search for specific instruction patterns.-f, --functions: Optional. Print function names and addresses.python3 ropdump.py /path/to/binary
python3 ropdump.py /path/to/binary -s "pop eax"
python3 ropdump.py /path/to/binary -f
An open-source, prototype implementation of property graphs for JavaScript based on the esprima parser, and the EsTree SpiderMonkey Spec. JAW can be used for analyzing the client-side of web applications and JavaScript-based programs.
This project is licensed under GNU AFFERO GENERAL PUBLIC LICENSE V3.0. See here for more information.
JAW has a Github pages website available at https://soheilkhodayari.github.io/JAW/.
Release Notes:
JAW-V2 branch.JAW-V1 branch.The architecture of the JAW is shown below.
JAW can be used in two distinct ways:
Arbitrary JavaScript Analysis: Utilize JAW for modeling and analyzing any JavaScript program by specifying the program's file system path.
Web Application Analysis: Analyze a web application by providing a single seed URL.
Use the collected web resources to create a Hybrid Program Graph (HPG), which will be imported into a Neo4j database.
Optionally, supply the HPG construction module with a mapping of semantic types to custom JavaScript language tokens, facilitating the categorization of JavaScript functions based on their purpose (e.g., HTTP request functions).
Query the constructed Neo4j graph database for various analyses. JAW offers utility traversals for data flow analysis, control flow analysis, reachability analysis, and pattern matching. These traversals can be used to develop custom security analyses.
JAW also includes built-in traversals for detecting client-side CSRF, DOM Clobbering and request hijacking vulnerabilities.
The outputs will be stored in the same folder as that of input.
The installation script relies on the following prerequisites: - Latest version of npm package manager (node js) - Any stable version of python 3.x - Python pip package manager
Afterwards, install the necessary dependencies via:
$ ./install.sh
For detailed installation instructions, please see here.
You can run an instance of the pipeline in a background screen via:
$ python3 -m run_pipeline --conf=config.yaml
The CLI provides the following options:
$ python3 -m run_pipeline -h
usage: run_pipeline.py [-h] [--conf FILE] [--site SITE] [--list LIST] [--from FROM] [--to TO]
This script runs the tool pipeline.
optional arguments:
-h, --help show this help message and exit
--conf FILE, -C FILE pipeline configuration file. (default: config.yaml)
--site SITE, -S SITE website to test; overrides config file (default: None)
--list LIST, -L LIST site list to test; overrides config file (default: None)
--from FROM, -F FROM the first entry to consider when a site list is provided; overrides config file (default: -1)
--to TO, -T TO the last entry to consider when a site list is provided; overrides config file (default: -1)
Input Config: JAW expects a .yaml config file as input. See config.yaml for an example.
Hint. The config file specifies different passes (e.g., crawling, static analysis, etc) which can be enabled or disabled for each vulnerability class. This allows running the tool building blocks individually, or in a different order (e.g., crawl all webapps first, then conduct security analysis).
For running a quick example demonstrating how to build a property graph and run Cypher queries over it, do:
$ python3 -m analyses.example.example_analysis --input=$(pwd)/data/test_program/test.js
This module collects the data (i.e., JavaScript code and state values of web pages) needed for testing. If you want to test a specific JavaScipt file that you already have on your file system, you can skip this step.
JAW has crawlers based on Selenium (JAW-v1), Puppeteer (JAW-v2, v3) and Playwright (JAW-v3). For most up-to-date features, it is recommended to use the Puppeteer- or Playwright-based versions.
This web crawler employs foxhound, an instrumented version of Firefox, to perform dynamic taint tracking as it navigates through webpages. To start the crawler, do:
$ cd crawler
$ node crawler-taint.js --seedurl=https://google.com --maxurls=100 --headless=true --foxhoundpath=<optional-foxhound-executable-path>
The foxhoundpath is by default set to the following directory: crawler/foxhound/firefox which contains a binary named firefox.
Note: you need a build of foxhound to use this version. An ubuntu build is included in the JAW-v3 release.
To start the crawler, do:
$ cd crawler
$ node crawler.js --seedurl=https://google.com --maxurls=100 --browser=chrome --headless=true
See here for more information.
To start the crawler, do:
$ cd crawler/hpg_crawler
$ vim docker-compose.yaml # set the websites you want to crawl here and save
$ docker-compose build
$ docker-compose up -d
Please refer to the documentation of the hpg_crawler here for more information.
To generate an HPG for a given (set of) JavaScript file(s), do:
$ node engine/cli.js --lang=js --graphid=graph1 --input=/in/file1.js --input=/in/file2.js --output=$(pwd)/data/out/ --mode=csv
optional arguments:
--lang: language of the input program
--graphid: an identifier for the generated HPG
--input: path of the input program(s)
--output: path of the output HPG, must be i
--mode: determines the output format (csv or graphML)
To import an HPG inside a neo4j graph database (docker instance), do:
$ python3 -m hpg_neo4j.hpg_import --rpath=<path-to-the-folder-of-the-csv-files> --id=<xyz> --nodes=<nodes.csv> --edges=<rels.csv>
$ python3 -m hpg_neo4j.hpg_import -h
usage: hpg_import.py [-h] [--rpath P] [--id I] [--nodes N] [--edges E]
This script imports a CSV of a property graph into a neo4j docker database.
optional arguments:
-h, --help show this help message and exit
--rpath P relative path to the folder containing the graph CSV files inside the `data` directory
--id I an identifier for the graph or docker container
--nodes N the name of the nodes csv file (default: nodes.csv)
--edges E the name of the relations csv file (default: rels.csv)
In order to create a hybrid property graph for the output of the hpg_crawler and import it inside a local neo4j instance, you can also do:
$ python3 -m engine.api <path> --js=<program.js> --import=<bool> --hybrid=<bool> --reqs=<requests.out> --evts=<events.out> --cookies=<cookies.pkl> --html=<html_snapshot.html>
Specification of Parameters:
<path>: absolute path to the folder containing the program files for analysis (must be under the engine/outputs folder).--js=<program.js>: name of the JavaScript program for analysis (default: js_program.js).--import=<bool>: whether the constructed property graph should be imported to an active neo4j database (default: true).--hybrid=bool: whether the hybrid mode is enabled (default: false). This implies that the tester wants to enrich the property graph by inputing files for any of the HTML snapshot, fired events, HTTP requests and cookies, as collected by the JAW crawler.--reqs=<requests.out>: for hybrid mode only, name of the file containing the sequence of obsevered network requests, pass the string false to exclude (default: request_logs_short.out).--evts=<events.out>: for hybrid mode only, name of the file containing the sequence of fired events, pass the string false to exclude (default: events.out).--cookies=<cookies.pkl>: for hybrid mode only, name of the file containing the cookies, pass the string false to exclude (default: cookies.pkl).--html=<html_snapshot.html>: for hybrid mode only, name of the file containing the DOM tree snapshot, pass the string false to exclude (default: html_rendered.html).For more information, you can use the help CLI provided with the graph construction API:
$ python3 -m engine.api -h
The constructed HPG can then be queried using Cypher or the NeoModel ORM.
You should place and run your queries in analyses/<ANALYSIS_NAME>.
You can use the NeoModel ORM to query the HPG. To write a query:
example_query_orm.py in the analyses/example folder.$ python3 -m analyses.example.example_query_orm
For more information, please see here.
You can use Cypher to write custom queries. For this:
example_query_cypher.py in the analyses/example folder.$ python3 -m analyses.example.example_query_cypher
For more information, please see here.
This section describes how to configure and use JAW for vulnerability detection, and how to interpret the output. JAW contains, among others, self-contained queries for detecting client-side CSRF and DOM Clobbering
Step 1. enable the analysis component for the vulnerability class in the input config.yaml file:
request_hijacking:
enabled: true
# [...]
#
domclobbering:
enabled: false
# [...]
cs_csrf:
enabled: false
# [...]
Step 2. Run an instance of the pipeline with:
$ python3 -m run_pipeline --conf=config.yaml
Hint. You can run multiple instances of the pipeline under different screens:
$ screen -dmS s1 bash -c 'python3 -m run_pipeline --conf=conf1.yaml; exec sh'
$ screen -dmS s2 bash -c 'python3 -m run_pipeline --conf=conf2.yaml; exec sh'
$ # [...]
To generate parallel configuration files automatically, you may use the generate_config.py script.
The outputs will be stored in a file called sink.flows.out in the same folder as that of the input. For Client-side CSRF, for example, for each HTTP request detected, JAW outputs an entry marking the set of semantic types (a.k.a, semantic tags or labels) associated with the elements constructing the request (i.e., the program slices). For example, an HTTP request marked with the semantic type ['WIN.LOC'] is forgeable through the window.location injection point. However, a request marked with ['NON-REACH'] is not forgeable.
An example output entry is shown below:
[*] Tags: ['WIN.LOC']
[*] NodeId: {'TopExpression': '86', 'CallExpression': '87', 'Argument': '94'}
[*] Location: 29
[*] Function: ajax
[*] Template: ajaxloc + "/bearer1234/"
[*] Top Expression: $.ajax({ xhrFields: { withCredentials: "true" }, url: ajaxloc + "/bearer1234/" })
1:['WIN.LOC'] variable=ajaxloc
0 (loc:6)- var ajaxloc = window.location.href
This entry shows that on line 29, there is a $.ajax call expression, and this call expression triggers an ajax request with the url template value of ajaxloc + "/bearer1234/, where the parameter ajaxloc is a program slice reading its value at line 6 from window.location.href, thus forgeable through ['WIN.LOC'].
In order to streamline the testing process for JAW and ensure that your setup is accurate, we provide a simple node.js web application which you can test JAW with.
First, install the dependencies via:
$ cd tests/test-webapp
$ npm install
Then, run the application in a new screen:
$ screen -dmS jawwebapp bash -c 'PORT=6789 npm run devstart; exec sh'
For more information, visit our wiki page here. Below is a table of contents for quick access.
Pull requests are always welcomed. This project is intended to be a safe, welcoming space, and contributors are expected to adhere to the contributor code of conduct.
If you use the JAW for academic research, we encourage you to cite the following paper:
@inproceedings{JAW,
title = {JAW: Studying Client-side CSRF with Hybrid Property Graphs and Declarative Traversals},
author= {Soheil Khodayari and Giancarlo Pellegrino},
booktitle = {30th {USENIX} Security Symposium ({USENIX} Security 21)},
year = {2021},
address = {Vancouver, B.C.},
publisher = {{USENIX} Association},
}
JAW has come a long way and we want to give our contributors a well-deserved shoutout here!
@tmbrbr, @c01gide, @jndre, and Sepehr Mirzaei.
Little AV/EDR Evasion Lab for training & learning purposes. (๏๏ธ under construction..)โ
____ _ _____ ____ ____ ___ __ _____ _
| __ ) ___ ___| |_ | ____| _ \| _ \ / _ \ / _| |_ _| |__ ___
| _ \ / _ \/ __| __| | _| | | | | |_) | | | | | |_ | | | '_ \ / _ \
| |_) | __/\__ \ |_ | |___| |_| | _ < | |_| | _| | | | | | | __/
|____/_\___||___/\__| |_____|____/|_| \_\ \___/|_| |_| |_| |_|\___|
| \/ | __ _ _ __| | _____| |_
| |\/| |/ _` | '__| |/ / _ \ __|
| | | | (_| | | | < __/ |_ Yazidou - github.com/Xacone
|_| |_|\__,_|_| |_|\_\___|\__|
BestEDROfTheMarket is a naive user-mode EDR (Endpoint Detection and Response) project, designed to serve as a testing ground for understanding and bypassing EDR's user-mode detection methods that are frequently used by these security solutions.
These techniques are mainly based on a dynamic analysis of the target process state (memory, API calls, etc.),
Feel free to check this short article I wrote that describe the interception and analysis methods implemented by the EDR.
In progress:
Usage: BestEdrOfTheMarket.exe [args]
/help Shows this help message and quit
/v Verbosity
/iat IAT hooking
/stack Threads call stack monitoring
/nt Inline Nt-level hooking
/k32 Inline Kernel32/Kernelbase hooking
/ssn SSN crushing
BestEdrOfTheMarket.exe /stack /v /k32
BestEdrOfTheMarket.exe /stack /nt
BestEdrOfTheMarket.exe /iat
An automatic Blind ROP exploitation python tool
BROP (Blind ROP) was a technique found by Andrew Bittau from Stanford in 2014.
Most servers like nginx, Apache, MySQL, forks then communicates with the client. This means canary and addresses stay the same even if there is ASLR and PIE. So we can use some educated brute force to leak information and subsequently craft a working exploit.
There is 3 customs vulnerable examples provided in this repository. You can run it directly or build the Dockerfile
BROPPER will then dump the binary :
It's then possible to extract all ROP gadgets from the dumped binary using ROPgadget for example :
$ ROPgadget --binary dump
Gadgets information
============================================================
0x0000000000001177 : adc al, 0 ; add byte ptr [rax], al ; jmp 0x1020
0x0000000000001157 : adc al, byte ptr [rax] ; add byte ptr [rax], al ; jmp 0x1020
0x0000000000001137 : adc byte ptr [rax], al ; add byte ptr [rax], al ; jmp 0x1020
...
...
...
0x0000000000001192 : xor ch, byte ptr [rdi] ; add byte ptr [rax], al ; push 0x16 ; jmp 0x1020
0x000000000000182e : xor eax, 0x891 ; mov rdi, rax ; call rcx
0x0000000000001861 : xor eax, 0xffffff22 ; mov rdi, rax ; call rcx
Unique gadgets found: 235To use this script:
python3 -m pip install -r requirements.txt
python3 bropper.py -t 127.0.0.1 -p 1337 --wait "Password :" --expected Bad --expected-stop Welcome -o dump$ python3 bropper.py -h
usage: bropper.py [-h] -t TARGET -p PORT --expected-stop EXPECTED_STOP --expected EXPECTED --wait WAIT -o OUTPUT [--offset OFFSET] [--canary CANARY] [--no-canary] [--rbp RBP] [--rip RIP] [--stop STOP]
[--brop BROP] [--plt PLT] [--strcmp STRCMP] [--elf ELF]
Description message
options:
-h, --help show this help message and exit
-t TARGET, --target TARGET
target url
-p PORT, --port PORT target port
--expected-stop EXPECTED_STOP
Expected response for the stop gadget
--expected EXPECTED Expected normal response
--wait WAIT String to wait before sending payload
-o OUTPUT, --output OUTPUT
File to write dumped remote binary
--offset OFFSET set a offset value
--canary CANARY set a canary valu e
--no-canary Use this argument if there is no stack canary protection
--rbp RBP set rbp address
--rip RIP set rip address
--stop STOP set stop gadget address
--brop BROP set brop gadget address
--plt PLT set plt address
--strcmp STRCMP set strcmp entry value
--elf ELF set elf addressPull requests are welcome. Feel free to open an issue if you want to add other features.
A DLL Loader With Advanced Evasive Features
"Atom" function via the command line.CRC32 string hashing algorithm.AtomLdr's unhooking method looks like the following
the program Unhooking from the \KnwonDlls\ directory is not a new method to bypass user-land hooks. However, this loader tries to avoid allocating RWX memory when doing so. This was obligatory to do in KnownDllUnhook for example, where RWX permissions were needed to replace the text section of the hooked modules, and at the same time allow execution of functions within these text sections.
This was changed in this loader, where it suspends the running threads, in an attempt to block any function from being called from within the targetted text sections, thus eliminating the need of having them marked as RWX sections before unhooking, making RW permissions a possible choice.
This approach, however, created another problem; when unhooking, NtProtectVirtualMemory syscall and others were using the syscall instruction inside of ntdll.dll module, as an indirect-syscall approach. Still, as mentioned above, the unhooked modules will be marked as RW sections, making it impossible to perform indirect syscalls, because the syscall instruction that we were jumping to, can't be executed now, so we had to jump to another executable place, this is where win32u.dll was used.
win32u.dll contains some syscalls that are GUI-related functions, making it suitable to jump to instead of ntdll.dll. win32u.dll is loaded (statically), but not included in the unhooking routine, which is done to insure that win32u.dll can still execute the syscall instruction we are jumping to.
The suspended threads after that are resumed.
It is worth mentioning that this approach may not be that efficient, and can be unstable, that is due to the thread suspension trick used. However, it has been tested with multiple processes with positive results, in the meantime, if you encountered any problems, feel free to open an issue.
PayloadConfig.pc file, that contains the encrypted payload, and its encrypted key and iv.PayloadConfig.pc file will then replace this in the AtomLdr project.AtomLdr project as x64 Release.AtomLdr.dll using rundll32.exe, running Havoc payload, and capturing a screenshotAtomLdr.dll's Import Address TablePayloadBuilder.exe, to encrypt demon[111].bin - a Havoc payload fileAtomLdr.dll using rundll32.exe
EntropyReducer algorithm is determined by BUFF_SIZE and NULL_BYTES values. The following is how would EntropyReducer organize your payload if BUFF_SIZE was set to 4, and NULL_BYTES to 2.
BUFF_SIZE, if not, it pads it to be as so.BUFF_SIZE chunk from the payload, and makes a linked list node for it, using the InitializePayloadList function, initializing the payload as a linked list.NULL_BYTES, that will be used to lower the entropyObfuscate function here.Obfuscation Algorithm was serializing the linked list, the first thing that must be done here is to deserialize the obfuscated payload, generating a linked list from it, this step is done here in the Deobfuscate function.BUFF_SIZE and NULL_BYTES. However, it can be determined using the following equationFinalSize = ((OriginalSize + BUFF_SIZE - OriginalSize % BUFF_SIZE ) / BUFF_SIZE) * (BUFF_SIZE + NULL_BYTES + sizeof(INT))
".ER" file generated as an example of deserializing and deobfuscating it.All you have to do is add EntropyReducer.c and EntropyReducer.h files to your project, and call the Deobfuscate function. You can check PoC/main.c for reference.
In this example, BUFF_SIZE was set to 3, and NULL_BYTES to 1.
FC 48 83)5.883, view by pestudio.7.110.7.210
4.093
This tool is a simple PoC of how to hide memory artifacts using a ROP chain in combination with hardware breakpoints. The ROP chain will change the main module memory page's protections to N/A while sleeping (i.e. when the function Sleep is called). For more detailed information about this memory scanning evasion technique check out the original project Gargoyle. x64 only.
The idea is to set up a hardware breakpoint in kernel32!Sleep and a new top-level filter to handle the exception. When Sleep is called, the exception filter function set before is triggered, allowing us to call the ROP chain without the need of using classic function hooks. This way, we avoid leaving weird and unusual private memory regions in the process related to well known dlls.
The ROP chain simply calls VirtualProtect() to set the current memory page to N/A, then calls SleepEx and finally restores the RX memory protection.
The overview of the process is as follows:
This process repeats indefinitely.
As it can be seen in the image, the main module's memory protection is changed to N/A while sleeping, which avoids memory scans looking for pages with execution permission.
Since we are using LITCRYPT plugin to obfuscate string literals, it is required to set up the environment variable LITCRYPT_ENCRYPT_KEY before compiling the code:
C:\Users\User\Desktop\RustChain> set LITCRYPT_ENCRYPT_KEY="yoursupersecretkey"
After that, simply compile the code and run the tool:
C:\Users\User\Desktop\RustChain> cargo build
C:\Users\User\Desktop\RustChain\target\debug> rustchain.exe
This tool is just a PoC and some extra features should be implemented in order to be fully functional. The main purpose of the project was to learn how to implement a ROP chain and integrate it within Rust. Because of that, this tool will only work if you use it as it is, and failures are expected if you try to use it in other ways (for example, compiling it to a dll and trying to reflectively load and execute it).
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
ropr is a blazing fast multithreaded ROP Gadget finder
ROP (Return Oriented Programming) Gadgets are small snippets of a few assembly instructions typically ending in a ret instruction which already exist as executable code within each binary or library. These gadgets may be used for binary exploitation and to subvert vulnerable executables.
When the addresses of many ROP Gadgets are written into a buffer we have formed a ROP Chain. If an attacker can move the stack pointer into this ROP Chain then control can be completely transferred to the attacker.
Most executables contain enough gadgets to write a turing-complete ROP Chain. For those that don't, one can always use dynamic libraries contained in the same address-space such as libc once we know their addresses.
The beauty of using ROP Gadgets is that no new executable code needs to be written anywhere - an attacker may achieve their objective using only the code that already exists in the program.
Typically the first requirement to use ROP Gadgets is to have a place to write your ROP Chain - this can be any readable buffer. Simply write the addresses of each gadget you would like to use into this buffer. If the buffer is too small there may not be enough room to write a long ROP Chain into and so an attacker should be careful to craft their ROP Chain to be efficient enough to fit into the space available.
The next requirement is to be able to control the stack - This can take the form of a stack overflow - which allows the ROP Chain to be written directly under the stack pointer, or a "stack pivot" - which is usually a single gadget which moves the stack pointer to the rest of the ROP Chain.
Once the stack pointer is at the start of your ROP Chain, the next ret instruction will trigger the gadgets to be excuted in sequence - each using the next as its return address on its own stack frame.
It is also possible to add function poitners into a ROP Chain - taking care that function arguments be supplied after the next element of the ROP Chain. This is typically combined with a "pop gadget", which pops the arguments off the stack in order to smoothly transition to the next gadget after the function arguments.
Easy install:
cargo install ropr
the application will install to ~/.cargo/bin
From source:
git clone https://github.com/Ben-Lichtman/ropr
cd ropr
cargo build --release
the resulting binary will be located in target/release/ropr
Alternatively:
git clone https://github.com/Ben-Lichtman/ropr
cd ropr
cargo install --path .
the application will install to ~/.cargo/bin
rax with a value from another register I may choose to filter by the regex ^mov eax, ...;: 
