Documentation.

Everything about GBounty and GBounty Profiles Designer

Navigation Menu

GBounty 

GBounty is a command-line tool that can be used to scan web applications for vulnerabilities. It takes a target URL, list of URL, raw request or multiples raw requests in a zip file as input and uses a set of pre-defined rules (called “profiles”, the same ones used by the Burp Bounty Pro extension) to analyze the target and identify potential vulnerabilities. GBounty supports a number of flags that allow you to customize the behavior of the tool.

GBounty Usage

First of all, you need to put the GBOUNTY_LICENSE_KEY environment variable on your system.

To set an environment variable in Windows, you can use the set command in a Command Prompt or PowerShell window. For example, to set the GBOUNTY_LICENSE_KEY environment variable to abc123, you can use the following command: 

set GBOUNTY_LICENSE_KEY=abc123

To set an environment variable in macOS or Linux, you can use the export command in a terminal window. For example, to set the GBOUNTY_LICENSE_KEY environment variable to abc123, you can use the following command:

export GBOUNTY_LICENSE_KEY=abc123

Keep in mind that these commands will only set the environment variable for the current terminal session. To make the environment variable persist across terminal sessions, you will need to add the set or export command to your shell’s startup script (e.g., ~/.bashrc or ~/.bash_profile).

 GBounty supports a number of flags that allow you to customize the behavior of the tool.

Usage:
  gbounty [flags]

Flags:
  -h, --help
        Show help
  --update
        Update app and profiles
  --update-app
        Update app
  --update-profiles
        Update profiles

TARGET INPUT:
  -u, --url value
        If specified, it will be used as the target url
        Can be used more than once: -u url1 -u url2
  -uf, --urls-file string
        If specified, each line present on the file will be used as the target urls
  -rf, --requests-file string
        If specified, each file present on the requests file will be used as the target url and request template
        Only zipped (.zip) requests files are supported
  -rr, --raw-request value
        If specified, contents on given path will be used as the target url and request template
        Can be used more than once: --raw-request path/requests/req1.txt --raw-request path/requests/req2.txt
  -pf, --params-file string
        If specified, each line present on the file will be used as a request parameter
        Used in combination with --params-split
  -ps, --params-split int
        Determines the amount of parameters (-pf/--params-file) included into each group (default: 10)
        Use one (1) to scan every param individually
  -pm, --params-method string
        Determines the HTTP method the params (-pf/--params-file) will be included into (default: "GET")
        Supported methods are: "GET" (url) and "POST" (www/url-encoded, body)
  -pe, --params-encoding string
        Determines the encoding the params (-pf/--params-file) will be included into (default: "url")
        Supported encodings are: "url" (application/x-www-form-urlencoded) and "json" (application/json)
        Only used when --params-method/-pm is set to "POST"

Options for --url (-u) and --urls-file:
  -X, --method string
        If specified, it will be used as default HTTP method for request templates
  -H, --header value
        If specified, they will be used as the default HTTP header(s) for request templates
        Can be used more than once: -H "Accept: application/json" -H "Content-Type: application/json"
  -d, --data value
        If specified, it will be used as the default HTTP body data for request templates
PROFILE OPTIONS: -p, --profiles value Determines the path where profile file(s) will be read from (default: "./profiles/") It can also be used with the path to a specific profile file Can be used more than once: -p profiles/XSS.bb -p profiles/SQLi.bb -t, --tag value If specified, only profiles tagged with provided tags will be used Can be used more than once: -t tag1 -t tag2 -active, --only-active If specified, only active profiles will be analyzed during the scan -passive, --only-passive If specified, only passive profiles will be analyzed during the scan -psreq, --only-passive-req If specified, only passive request profiles will be analyzed during the scan -psres, --only-passive-res If specified, only passive response profiles will be analyzed during the scan -tags, --print-tags Print available profile tags RUNTIME OPTIONS: -c, --concurrency int Determines how many target URL(s) will be scanned concurrently (default: 10) -r, --rps int Determines the limit of requests per second (per URL) (default: 10) -s, --silent If specified, no results will be printed to stdout -sos, --save-on-stop Saves the scan's status when stopped -f, --from string Scan's identifier to be used to continue -m, --in-memory Use memory (only) as scan storage -ih, --interaction-host string If specified, the interaction host is injected into {IH} and {BC} labels -email, --email-address string If specified, the email address is injected into {EMAIL} labels --proxy-address string If specified, requests are proxied to the given address To specify host and port use host:port --proxy-auth string If specified, proxied requests will include authentication details OUTPUT OPTIONS: -o, --output string Determines the path where the output file will be stored to By default, the output file is formatted as plain text -j, --json If specified, the output file will be JSON-formatted By default, the output file is formatted as plain text -md, --markdown If specified, the output file will be Markdown-formatted By default, the output file is formatted as plain text -a, --all If specified, results will include all requests and responses By default, only those requests that caused a match are included in results As it causes a noisy output, must be used in combination with -o/--output flag -areq, --all-requests If specified, results will include all requests By default, only those requests that caused a match are included in results As it causes a noisy output, must be used in combination with -o/--output flag -ares, --all-responses If specified, results will include all responses By default, only those requests that caused a match are included in results As it causes a noisy output, must be used in combination with -o/--output flag -se, --show-errors If specified, failed requests are included in results -sr, --show-responses If specified, those requests that caused a match are printed with the corresponding response -ste, --stream-errors If specified, failed requests are printed to stdout during the scan (live) By default, they are only printed at the end, only when the -se/--show-errors flag is provided -stm, --stream-matches If specified, those requests that caused a match are printed to stdout during the scan (live) Enabled by default, can be disabled with --stream-matches=false or -stm=false DEBUG OPTIONS: -v, --verbose If specified, the internal logger will write warning and error log messages -vv, --verbose-extra If specified, the internal logger will write info, warning and error log messages -vvv, --verbose-all If specified, the internal logger will write debug, info, warning and error log messages -vout, --verbose-output string If specified, the internal logger will write the log messages to a file EXAMPLES: gbounty -u https://example.org -X POST -d "param1=value1&=value2" -t XSS -r 20 -a -o /tmp/results.json --json gbounty --urls-file domains.txt -c 200 -r 10 -p /tmp/gbounty-profiles --silent --markdown -o /tmp/results.md gbounty --requests-file requests.zip -r 150 --proxy-address=127.0.0.1:8080 -o /tmp/results.txt --all gbounty --raw-request 1.txt --raw-request 2.txt --interaction-host xxxxxx.burpcollaborator.net

FLAGS

--help, -h: This flag displays usage and flag information for the gbounty tool. When used, the tool will print a list of available flags and a brief description of each flag’s purpose.

--update: This flag updates both the app and profiles.

--update-app: This flag updates only the gbounty app.

--update-profiles: This flag updates only the vulnerability profiles.

To use gbounty to scan a website, you would first need to specify the target URL of the website you want to scan using the -u or --url flag. For example, if you wanted to scan the website at

TARGET INPUT

To use gbounty to scan a website, you would first need to specify the target URL of the website you want to scan using the -u or --url flag. For example, if you wanted to scan the website at https://example.com, you would use the following command:

gbounty -u https://example.com

This would scan the https://example.com website using the default settings for gbounty. For example, to scan the https://example.com and https://example.com/redirect.php?url=/ URLs, you would use the -u flag like this:

gbounty -u https://example.com -u https://example.com/redirect.php?url=/

Alternatively, you can specify a file containing a list of URLs to scan, with one URL per line, using the -uf or --urls-file flag. For example, if you had a file named urls.txt that contained the following lines:

www.example.com
www.example.com/test.php?id=2783
www.example.com/login.php?redirect=/
www.example.com/submit.php?user=test&password=test www.example.org
www.example.org/test.php?account_id=34
www.example.org/login.php?redirect_uri=/
www.example.org/submit.php?search=test

You could use the -uf flag to tell gbounty to use the URLs contained in the urls.txt file as the targets for its scans.

gbounty -uf /path/to/urls.txt

You can use the --raw-request flag with gbounty to specify one or more raw request templates that gbounty should use when conducting its scans. The --raw-request flag can be used multiple times to specify multiple request templates.

Here is an example of how the -rr flag might be used:

gbounty --raw-request /path/requests/req1.txt --raw-request /path/requests/req2.txt

The format of the raw request req1.txt could be something like this:

POST /search.php HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 24
Connection: close

search=test&goButton=go

The -rf or --requests-file flag can be used to specify a file containing a list of raw request that gbounty should use when conducting its scans. This flag allows users to specify a specific file containing the raw request that gbounty should use, rather than specifying the raw request files directly on the command line. The file that is specified with the -rf flag must be a zipped file containing one raw request per file. This allows users to organize their raw request into multiple files and then easily specify all of the raw requests at once using the -rf flag.

Here is an example of how the -rf flag might be used:

gbounty -rf requests.zip

This command would tell gbounty to use the raw request contained in the requests.zip file when conducting its scans.

By default, gbounty does not scan any URLs or use any request templates unless the -u, -uf, -rf, or -rr flags are used to specify the target URL(s) and request templates.

You can then use additional flags to customize the behavior of the tool, such as specifying the profiles to use, the HTTP method to use for requests, and so on.

Options for –url (-u) and –urls-file (-uf):

  • -X or --method: This flag allows you to specify a default HTTP method that gbounty should use when conducting its scans. The HTTP method specifies the type of action that the request is intended to perform, such as GET, POST, PUT, or DELETE. For example, you could use the -X flag like this: gbounty -X POST -u https://example.com. This would tell gbounty to use the POST method as the default HTTP method for its scans (overriding the default method of the request and profiles.).
  • -H or --header: This flag allows you to specify default HTTP headers that gbounty should use when conducting its scans. HTTP headers are used to provide additional information about the request, such as the content type, encoding, or authentication credentials. The -H flag can be used multiple times to specify multiple default headers. For example, you could use the -H flag like this: gbounty -H "Accept: application/json" -H "Content-Type: application/json". This would tell gbounty to use the Accept and Content-Type headers with the specified values as the default headers for its scans.
  • -d or --data: This flag allows you to specify a default HTTP body data that gbounty should use when conducting its scans. The HTTP body data is the data that is sent along with the request, and it can be used to provide additional information or parameters for the request. For example, you could use the -d flag like this: gbounty -d "{\"username\":\"admin\",\"password\":\"password123\"}". This would tell gbounty to use the specified data as the default HTTP body data for its scans.

PROFILE OPTIONS

To customize the behavior of gbounty, you can use a combination of flags to specify different settings. For example, to specify the profiles to use when scanning the target URL, use the -p or --profiles flag followed by the path to the directory containing the profiles, or the path to a specific profile file, like this:

gbounty -u https://example.com -p /path/to/profiles

This will scan the target URL using the profiles in the /path/to/profiles directory. Alternatively, to use the XSS.bb and SQLi.bb profile files specifically, you would use the -p flag like this:

gbounty -u https://example.com -p ./profiles/XSS.bb -p ./profiles/SQLi.bb

The -p flag can be used more than once, allowing you to specify multiple profile files or directories to use. By default, gbounty uses the profile files in the ./profiles/ directory.

Next, you can use the -t or --tag flag to specify one or more tags that should be used to filter the profiles that gbounty uses when conducting its scans. Only profiles that are tagged with the specified tags will be used. The -t flag can be used multiple times to specify multiple tags. For example, you could use the -t flag like this:

gbounty -u https://example.com -t tag1 -t tag2

This would tell gbounty to only use profiles that are tagged with tag1 and tag2.

The -tags or --print-tags flag can be used to print a list of available profile tags to the terminal.

gbounty -tags

This command would tell gbounty to scan the default profile path (./profiles/) and print a list of all the tags that are used by the profile files that it finds.

The -active, -passive, -psreq, and -psres flags can all be used to control which types of profiles gbounty uses when conducting its scans.

  • -active or --only-active: This flag specifies that only active profiles should be used when conducting the scan. Active profiles are profiles that actively send requests to the target URLs in order to test for vulnerabilities. This flag can be used like this: gbounty -active.
  • -passive or --only-passive: This flag specifies that only passive profiles should be used when conducting the scan. Passive profiles are profiles that do not actively send requests to the target URLs, but instead analyze the responses that the target URLs send in order to identify potential vulnerabilities. This flag can be used like this: gbounty -passive.
  • -psreq or --only-passive-req: This flag specifies that only passive request profiles should be used when conducting the scan. Passive request profiles are passive profiles that analyze the requests that are sent to the target URLs in order to identify potential vulnerabilities. This flag can be used like this: gbounty -psreq.
  • -psres or --only-passive-res: This flag specifies that only passive response profiles should be used when conducting the scan. Passive response profiles are passive profiles that analyze the responses that are sent by the target URLs in order to identify potential vulnerabilities. This flag can be used like this: gbounty -psres.

These flags can be used in combination with each other and with other flags to control the profiles that gbounty uses when conducting its scans. For example, you could use the -active and -passive flags together like this:

gbounty -u https://example.com -active -passive

This would tell gbounty to use both active and passive profiles when conducting the scan. Similarly, you could use the -psreq and -psres flags together like this:

gbounty -u https://example.com -psreq -psres

This would tell gbounty to use passive request and response profiles when conducting the scan. You could also combine these flags with other flags, such as the -p or --profiles flag, to specify which profile files gbounty should use when conducting the scan. For example:

gbounty -u https://example.com -p /profiles/XSS.bb -psreq -psres

This would tell gbounty to use the XSS.bb profile file, and to only use passive request and response profiles when conducting the scan.

By default, the four types of tests are executed: -active -passive -psreq -psres

RUNTIME OPTIONS

The -c or --concurrency flag specifies the number of target URLs that gbounty should scan concurrently. The default value is 10, but you can specify a different value if you want. For example, to specify that gbounty should scan 20 URLs concurrently, you could use the -c flag like this: gbounty -c 20.

Here is an example of how the -c flag can be used in a gbounty command:

gbounty -uf urls.txt -c 20

In this example, the -c flag is used to specify that gbounty should scan 20 URLs concurrently. This means that gbounty will open 20 parallel connections to the target URLs and scan them simultaneously. This can be useful for speeding up the scanning process, but it can also increase the load on the target server and potentially cause issues, so it is important to use this flag with caution.

The -r or --rps flag specifies the maximum number of requests per second (per URL) that gbounty should make when conducting its scans. The default value is 10, but you can specify a different value if you want. For example, to specify that gbounty should make a maximum of 20 requests per second per URL, you could use the -r flag like this: gbounty -r 20.

Here is an example of how the -r flag can be used in a gbounty command:

gbounty -u https://example.com -r 20

In this example, the -r flag is used to specify that gbounty should make a maximum of 20 requests per second per URL. This means that gbounty will not make more than 20 requests to any given URL in any given second. This can be useful for limiting the load on the target server, but it can also slow down the scanning process, so it is important to use this flag with caution.

The -s or --silent flag specifies that gbounty should not print any results to the standard output (stdout) while it is conducting its scans. By default, gbounty will print results to stdout as it scans the target URLs, but if you want to suppress this output, you can use the -s flag.

Here is an example of how the -s flag can be used in a gbounty command:

gbounty -u https://example.com -s

In this example, the -s flag is used to specify that gbounty should not print any results to stdout while it is conducting its scans. This means that you will not see any output in your terminal window as gbounty scans the target URLs. This can be useful if you want to run gbounty in the background without any output, but it can also make it difficult to monitor the progress of the scans, so it is important to use this flag with caution.

The -sos or --save-on-stop flag specifies that gbounty should save the status of its scans when they are stopped. By default, when a gbounty scan is stopped, any progress made up to that point is lost and the scan must be started from the beginning if it is resumed. However, if you use the -sos flag, gbounty will save the status of the scan when it is stopped, so that it can be resumed from the same point later.

Here is an example of how the -sos flag can be used in a gbounty command:

gbounty -u https://example.com -sos

In this example, the -sos flag is used to specify that gbounty should save the status of its scans when they are stopped. This means that if the scan is stopped for any reason, gbounty will save the progress made up to that point, so that the scan can be resumed from the same point later. This can be useful if you want to stop a scan temporarily and resume it later, without losing any progress.

The -f or --from flag specifies that gbounty should resume a previously-stopped scan using a specific identifier. This flag can only be used in conjunction with the -sos flag, and it allows you to specify the identifier of the scan that you want to resume. By default, gbounty will not resume any scans when it is restarted, but if you use the -f flag, gbounty will resume the scan with the specified identifier.

Here is an example of how the -f flag can be used in a gbounty command:

gbounty -u https://example.com -f 01GKE4Q3NMS0BQN1Z111YX3VFE

The -f flag is used to specify that gbounty should resume the scan with the identifier “01GKE4Q3NMS0BQN1Z111YX3VFE” when it is restarted. This means that if the scan is stopped and then restarted, gbounty will resume the scan from the same point where it left off, using the “01GKE4Q3NMS0BQN1Z111YX3VFE” identifier.

The -m or --in-memory flag specifies that gbounty should use memory (RAM) as the storage for its scans. By default, gbounty stores its scan data on disk, which allows it to save the status of a scan when it is stopped and then resumed later. However, if you use the -m flag, gbounty will store its scan data in memory instead of on disk. This can be useful if you want to speed up gbounty’s performance, but it means that gbounty will not be able to save the status of a scan when it is stopped, so the scan must be restarted from the beginning if it is resumed.

Here is an example of how the -m flag can be used in a gbounty command:

gbounty -u https://example.com -m

In this example, the -m flag is used to specify that gbounty should use memory as the storage for its scans. This means that gbounty will store its scan data in memory, rather than on disk. This can improve gbounty’s performance, but it means that gbounty will not be able to save the status of a scan when it is stopped, so the scan must be restarted from the beginning if it is resumed.

The -ih or --interaction-host flag specifies that gbounty should inject a specific hostname into the {IH} and {BC} labels in its request profiles. This is useful when you want to use gbounty to test for vulnerabilities that require the use of an interaction host, such as blind cross-site scripting (XSS) vulnerabilities. The -ih flag allows you to specify the hostname that gbounty should use when injecting the {IH} and {BC} labels into its request profiles.

Here is an example of how the -ih flag can be used in a gbounty command:

gbounty -u https://example.com -ih xxxxxx.burpcollaborator.net

In this example, the -ih flag is used to specify that gbounty should inject the hostname xxxxxx.burpcollaborator.net into the {IH} and {BC} labels in its request profiles. This means that gbounty will replace any instances of the {IH} and {BC} labels in its request profiles with the hostname xxxxxx.burpcollaborator.net.

The -email or --email-address flag specifies that gbounty should inject a specific email address into the {EMAIL} label in its request profiles. This is useful when you want to use gbounty to test for vulnerabilities that require the use of an email address, such as email header injection vulnerabilities. The -email flag allows you to specify the email address that gbounty should use when injecting the {EMAIL} label into its request profiles.

Here is an example of how the -email flag can be used in a gbounty command:

gbounty -u https://example.com -email [email protected]

In this example, the -email flag is used to specify that gbounty should inject the email address [email protected] into the {EMAIL} label in its request profiles. This means that gbounty will replace any instances of the {EMAIL} label in its request profiles with the email address [email protected].

The --proxy-address flag is used to specify the hostname and port of the proxy server that gbounty should use when making requests. The --proxy-address flag takes a string argument, which should be in the format host:port, where host is the hostname of the proxy server, and port is the port number that the proxy server is listening on.

Here is an example of how the --proxy-address flag can be used in a gbounty command:

gbounty -u https://example.com --proxy-address proxy.example.com:8080

In this example, the --proxy-address flag is used to specify that gbounty should use the proxy server at proxy.example.com:8080 when making requests.

The --proxy-auth flag is used to specify the authentication details for the proxy server that gbounty should use when making requests. The --proxy-auth flag takes a string argument, which should be in the format username:password, where username is the username for authenticating with the proxy server, and password is the password for authenticating with the proxy server.

Here is an example of how the --proxy-auth flag can be used in a gbounty command:

gbounty -u https://example.com --proxy-address proxy.example.com:8080 --proxy-auth user:password

In this example, the --proxy-auth flag is used to specify that gbounty should authenticate with the proxy server using the username user and the password password.

OUTPUT OPTIONS

The -o or --output flag is used to specify the path where the output file generated by gbounty should be saved. The -o or --output flag takes a string argument, which should be the path to the output file, including the filename and the file extension.

By default, the output file generated by gbounty is formatted as plain text.  Here is an example of how the -o or --output flag can be used in a gbounty command:

gbounty -u https://example.com -o results.txt

In this example, the -o flag is used to specify that the output file generated by gbounty should be saved to a file named results.txt in the current working directory.
However, the -o or --output flag can be used in combination with the -j or --json flag to generate a JSON-formatted output file, or with the -md or --markdown flag to generate a Markdown-formatted output file.

gbounty -u https://example.com -o results.md -md

In this example, the gbounty -u https://example.com -o results.txt -md command is used to scan the target URL https://example.com, save the output file to a file named results.txt in the current working directory, and format the output file as Markdown.

gbounty -u https://example.com -o results.json -j

In this example, the gbounty -u https://example.com -o results.txt -j command is used to scan the target URL https://example.com, save the output file to a file named results.txt in the current working directory, and format the output file as JSON.

The -a or --all flag can be used in combination with the -o or --output flag to include all requests and responses in the output file generated by gbounty. By default, only those requests that caused a match are included in the output file.

Here is an example of how you could use the -a or --all flag in combination with the -o or --output flag:

gbounty -u https://example.com -o results.txt -a

In this example, the -a or --all flag is used to include all requests and responses in the output file generated by gbounty. The -o or --output flag is used to specify the path where the output file should be saved. In this example, the output file will be saved to a file named results.txt in the current working directory.

It is important to note that using the -a or --all flag can cause the output file to be very noisy, as it will include all requests and responses, not just those that caused a match. Therefore, it is recommended to use the -a or --all flag in combination with the -o or --output flag to save the results to a file, rather than printing them to the terminal. This allows you to review the results at your leisure without being overwhelmed by the sheer volume of information.

The -areq or --all-requests flag can be used in combination with the -o or --output flag to include all requests in the output file generated by gbounty. By default, only those requests that caused a match are included in the output file.

Here is an example of how you could use the -areq or --all-requests flag in combination with the -o or --output flag:

gbounty -u https://example.com -o results.txt -areq

In this example, the -areq or --all-requests flag is used to include all requests in the output file generated by gbounty. The -o or --output flag is used to specify the path where the output file should be saved. In this example, the output file will be saved to a file named results.txt in the current working directory.

It is important to note that using the -areq or --all-requests flag can cause the output file to be very noisy, as it will include all requests, not just those that caused a match. Therefore, it is recommended to use the -areq or --all-requests flag in combination with the -o or --output flag to save the results to a file, rather than printing them to the terminal. This allows you to review the results at your leisure without being overwhelmed by the sheer volume of information.

The -ares or --all-responses flag can be used in combination with the -o or --output flag to include all responses in the output file generated by gbounty. By default, only those responses that correspond to requests that caused a match are included in the output file.

Here is an example of how you could use the -ares or --all-responses flag in combination with the -o or --output flag:

gbounty -u https://example.com -o results.txt -ares

In this example, the -ares or --all-responses flag is used to include all responses in the output file generated by gbounty. The -o or --output flag is used to specify the path where the output file should be saved. In this example, the output file will be saved to a file named results.txt in the current working directory.

It is important to note that using the -ares or --all-responses flag can cause the output file to be very noisy, as it will include all responses, not just those that correspond to requests that caused a match. Therefore, it is recommended to use the -ares or --all-responses flag in combination with the -o or --output flag to save the results to a file, rather than printing them to the terminal. This allows you to review the results at your leisure without being overwhelmed by the sheer volume of information.

The -se or --show-errors flag can be used to include failed requests in the results generated by gbounty. By default, failed requests are not included in the results, as they typically do not contain any useful information for identifying vulnerabilities.

Here is an example of how you could use the -se or --show-errors flag:

gbounty -u https://example.com -o results.txt -se

In this example, the -se or --show-errors flag is used to include failed requests in the results generated by gbounty. The -o or --output flag is used to specify the path where the output file should be saved. In this example, the output file will be saved to a file named results.txt in the current working directory.

It is important to note that using the -se or --show-errors flag can cause the output file to be very noisy, as it will include failed requests in addition to those that caused a match.

The -sr or --show-responses flag can be used to include the responses to requests that caused a match in the results generated by gbounty. By default, only the requests that caused a match are included in the results, without the corresponding response.

Here is an example of how you could use the -sr or --show-responses flag:

gbounty -u https://example.com -o results.txt -sr

In this example, the -sr or --show-responses flag is used to include the responses to requests that caused a match in the results generated by gbounty. The -o or --output flag is used to specify the path where the output file should be saved. In this example, the output file will be saved to a file named results.txt in the current working directory.

Using the -sr or --show-responses flag can provide additional context and information about the requests that caused a match, as it includes the corresponding response in the results. This can be useful for understanding the nature of the vulnerability and determining the best course of action for addressing it. However, it is important to note that including the responses in the results can cause the output file to be very large, as it will include the responses to all requests that caused a match. Therefore, it is recommended to use the -sr or --show-responses flag in combination with the -o or --output flag to save the results to a file, rather than printing them to the terminal. This allows you to review the results at your leisure without being overwhelmed by the sheer volume of information.

The -ste or --stream-errors flag can be used to print failed requests to stdout during the scan. By default, failed requests are only printed at the end of the scan, and only when the -se or --show-errors flag is provided. This flag can be useful for monitoring the progress of the scan in real-time and identifying any potential issues with the requests being made.

Here is an example of using the -ste flag:

gbounty -u https://example.com -o results.txt -ste

In this example, the -ste flag is used in combination with the -u flag to specify the target URL, and the -o flag to specify the path to the output file. The failed requests will be printed to stdout during the scan, and the final results will be saved to the file specified by -o.

The --stream-matches flag allows the user to print the requests that caused a match to the standard output while the scan is still running, rather than waiting until the end of the scan. This is useful for providing live updates on the progress of the scan. The flag is enabled by default, but it can be disabled by passing --stream-matches=false or -stm=false as arguments to the gbounty command.

Here is an example of how to use the --stream-matches flag to print live updates of matching requests to the standard output:

gbounty -u https://example.com -stm

In this example, gbounty will scan the https://example.com URL, print live updates of matching requests to the standard output, and store the results of the scan in a file formatted as plain text.

DEBUG OPTIONS

To enable verbose mode for the gbounty tool, the -v, -vv, or -vvv flags can be used. These flags will enable the internal logger to write warning, error, info, and debug log messages, respectively. The log messages can be written to a file by using the -vout flag, followed by the desired path and filename for the output file.

For example, to enable verbose mode and write the log messages to a file, the following command can be used:

gbounty -u https://example.com -v -vout log.txt

This command will enable the internal logger to write warning and error log messages to the log.txt file. To enable verbose mode and write all log messages to a file, the -vvv flag can be used instead, like so:

gbounty -u https://example.com -vvv -vout log.txt

This will enable the internal logger to write all log messages (debug, info, warning, and error) to the log.txt file.

EXAMPLES

In this section will detail some examples of the use of gbounty.

gbounty -u https://example.org -X POST -d "param1=value1&param2=value2" -t XSS -r 20 -a -o /tmp/results.json --json

The gbounty command above will scan the URL https://example.org using a POST request with the data “param1=value1&param2=value2” as the request body. It will only use profiles tagged with “XSS” and will allow up to 20 requests per second. The results will include all requests and responses, and will be written to the file /tmp/results.json in JSON format.

gbounty --urls-file domains.txt -c 200 -r 10 -p /tmp/gbounty-profiles --silent --markdown -o /tmp/results.md

This command will run a gbounty scan using the target URLs specified in the domains.txt file. The scan will use 200 concurrent workers and will limit the requests per second (RPS) to 10. It will use the profile files located in the /tmp/gbounty-profiles directory, and will not print any results to standard output. The results of the scan will be written to a Markdown-formatted file at /tmp/results.md.

gbounty --requests-file requests.zip -r 150 --proxy-address=127.0.0.1:8080 -o /tmp/results.txt --all

In the above example, gbounty will be run with the following options:

  • The requests file at requests.zip will be used as the target URL and request profile.
  • The maximum number of requests per second (per URL) will be 150.
  • Requests will be proxied through 127.0.0.1:8080.
  • The output will be stored in /tmp/results.txt in plain text format.
  • All requests and responses will be included in the output.
gbounty --raw-request 1.txt --raw-request 2.txt --interaction-host xxxxxx.burpcollaborator.net

The above command line will use the raw requests of the files 1.txt and 2.txt as a target URLs. It will also inject the provided interaction host into {IH} and {BC} labels. The scan will be performed with the default concurrency and requests per second settings. The results will be printed to the stdout in the default format (plain text).

LABELS

{BC} or {IH} Replaced by your interaction host specified with -ih option.
{EMAIL} Replaced by email address specified with -email option.
{CURRENT_URL} Replaced by entire original URL request.
{CURRENT_PORT} Replaced bythe original request web server port.
{CURRENT_PATH} Replaced by the original request path.
{CURRENT_HOST} Replaced by the original request host.
{CURRENT_METHOD} Replaced by the original request method. (GET, POST, etc.)
{CURRENT_QUERY} Replaced by the original request POST data query.
{CURRENT_SUBDOMAIN} Replaced by the original request subdomain. (www,docs,prod,etc)
{CURRENT_FILE} Replaced by the original request file.
{CURRENT_PROTOCOL} Replaced by the original request protocol. (http,https)
{CURRENT_USER_AGENT} Replaced by the original request user agent header value.
{CURRENT_REFERER} Replaced by the original request referer header value.
{CURRENT_ORIGIN} Replaced by the original request origin header value.
{CURRENT_ACCEPT} Replaced by the original request accept header value.
{CURRENT_CONTENT_TYPE} Replaced by the original request content type header value.
{CURRENT_ACCEPT_LANGUAGE} Replaced by the original request accept language header value.
{CURRENT_ACCEPT_ENCODING} Replaced by the original request accept encoding header value.
{CURRENT_CONTENT_LENGTH} Replaced by the original request cointent length header value.

GBounty Profiles Designer

GBounty Profiles Designer gives you the ability to create your own vulnerability profiles through a easy graphical interface. With this tool you will be able to create new vulnerability profiles in a simple and fast way, which will allow you to integrate new web vulnerabilities into your tests in a few seconds.

It has a unique customization capacity, with new insertion points and new search types. Through the design of passive and active vulnerability profiles, you will be able to carry out a complete review of the web application.

Active Profiles

Step 1 (Required): The name and author of the profile are first set.

Step 2 (Required): Here you can choose the request type:

  • Original Request: The extension get the original request that is sended to the scanner, extract insertion points, put the payloads in the selected insertion points, makes the necessary modifications and sends it to the server.
  • Raw Request: You specify a new request, inheriting fields from the original request.

Step 2.1 (Required)- Original Request -> Payloads: It sets the payload or payloads that will be sent in the selected request insertion points.

  • You can add the Payload by click on the “add” button and modifying the value, or by pasting it directly with the “Paste” button if you already have it in the clipboard.
  • You can also load a payloads file (one per line) with the “Load file” button.

Step 2.2 (Required)- Original Request -> Payload Position:

The Payload position field is to specify where each of the payloads defined in the profiles will be established. For example in a request:

GET /listproducts.php?cat=123456 HTTP/1.1
Host: testphp.vulnweb.com

Suppose that we have specified the Insertion point type is Param url value (123456). If we have the ‘-alert(1)-‘ as a payload, the Payload position can be the following:

Replace: the original value is replaced.

GET /listproducts.php?cat=‘-alert(1)-‘ HTTP/1.1
Host: testphp.vulnweb.com

Append: The value of the payload is added to the original value.

GET /listproducts.php?cat=123456‘-alert(1)-‘ HTTP/1.1
Host: testphp.vulnweb.com

Insert: The value of the payload is inserted in the middle of the original value.

GET /listproducts.php?cat=123‘-alert(1)-‘456 HTTP/1.1
Host: testphp.vulnweb.com

Step 2.4 (Required)- Original Request -> Insertion Point Type:

Here you can select the insertion points where you want the payloads to be sent.

The insertion points are the zones of the HTTP request where the specified payload will be placed. For example in this HTTP request:

POST /search.php?test=query HTTP/1.1
Host: testphp.vulnweb.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
Connection: close

searchFor=test&goButton=go

If the payload <script>alert (1)</script> is specified and the insertion point “Param body value” is selected, the HTTP requests that GBounty will make will be:

  1. Change “test” value for the payload:
POST /search.php?test=query HTTP/1.1
Host: testphp.vulnweb.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
Connection: close

searchFor=<script>alert (1)</script>&goButton=go
  1. Change “go” value, for the payload:
POST /search.php?test=query HTTP/1.1
Host: testphp.vulnweb.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
Connection: close

searchFor=test&goButton=<script>alert (1)</script>

Below you can see in detail each insertion point type.

Param body value.

Param body name.

Param URL value.

 

Param URL name.

Entire body.

User provided: Defined by the user in the Intruder tab.

Cookie value.

Cookie name.

Param json value.

Param json name.

Entire body json.

Param XML value.

Param XML name.

Param XML attr value.

Param XML attr name.

Param multipart attr value.

Param multipart attr name.

Multiple Path discovery: These insertions point type are added to the requests to discover hidden files and directories:

GET /dir1/dir2/file.php?param=value HTTP/1.1

Generate three new Insertion points:

1- GET {HERE} HTTP/1.1
2- GET /dir1{HERE} HTTP/1.1
3- GET /dir1/dir2{HERE} HTTP/1.1

Then, if you put in payload /.git/HEAD, the three new request are:

1- GET /.git/HEAD HTTP/1.1
2- GET /dir1/.git/HEAD HTTP/1.1
3- GET /dir1/dir2/.git/HEAD HTTP/1.1

without param=value.

Multiple Path discovery 1.

Multiple Path discovery 2.

Multiple Path discovery 3.

Single Path discovery.

Url path folder.

Url path filename.

Entire body xml.

Entire body multipart.

HTTP Headers: Host

HTTP Headers: User agent

HTTP Headers: Accept

HTTP Headers: Accept Language

HTTP Headers: Accept Encoding

HTTP Headers: Content Type

HTTP Headers: Origin

HTTP Headers: Referer

New HTTP Headers: X-Forwarded-For (or whichever that you specify)

Step 2.5 (Optional)- Original Request -> Match and Replace:

In this section you can replace values in the payload/request or you can insert new fields in the HTTP request.

Step 2.6 (Optional)- Original Request -> Payload encoding:

In this section you can use one or more encodings that will be applied to the payloads before being sent in the HTTP request. You can choose between:

  • URL-encode key characters
  • URL-encode all characters
  • URL-encode all characters (Unicode)
  • HTML-encode key characters
  • HTML-encode all characters
  • Base64-encode

In this section, you can also encode in “URL encode” only the payload characters that you choose:

Step 3 (Required if you choose raw request option)- Raw Request:

You have the possibility of sending Raw requests inheriting attributes of the request that is being scanned.

This means that when a HTTP request or domain is scanned, this custom RAW Request will be sent to the system that you are attacking.

You can insert these attributes wherever you want in the Raw Request. The available attributes are:

{CURRENT_URL}
{CURRENT_PORT}
{CURRENT_PATH}
{CURRENT_HOST}
{CURRENT_METHOD}
{CURRENT_QUERY}
{CURRENT_FILE}
{CURRENT_PROTOCOL}
{CURRENT_USER_AGENT}
{CURRENT_REFERER}
{CURRENT_ORIGIN}
{CURRENT_CONTENT_TYPE}
{CURRENT_ACCEPT}
{CURRENT_ACCEPT_LANGUAGE}
{CURRENT_ACCEPT_ENCODING}
{CURRENT_CONTENT_LENGTH}

Step 4 (Required)- Response->Match Type: In this section we must specify how we will look for the pattern in the HTTP response.

  • Simple string: Search for a simple string in the HTTP Response that you specify in the “Grep” section.

  • Regex: Search for a regular expression in the HTTP Response that you specify in the “Grep” section.

  • Payload: Search for a Payload (that have been specified in the Original Request->Payloads section) in the HTTP response.

  • Payload encode: If you have encoded the payload with the original request functionalities, here you look for the value of the payload before it’s encoded, in the HTTP response. In this case you look for “Payload 1…Payload N” in the HTTP Response.

  • Invariations: This option looks for the NO difference in the attributes marked in the “Attributes” section between the response of the original HTTP request and the responses of the HTTP requests modified with the payloads.

  • Variations: This option looks for the difference in the attributes marked in the “Attributes” section between the response of the original HTTP request and the responses of the requests modified with the payloads.

  • Content length difference: This option finds the difference between the content length (in bytes) of the response of the original HTTP request and the responses of the requests modified with the payloads.

  • HTTP Response codes: This option looks for the HTTP response codes. The following example will search for:
    • HTTP 200 OK
    • HTTP 403 Forbidden
    • HTTP 302 Found

  • Timeout between: This option searches in the HTTP responses for a time delay in seconds in a range that can be specified. The following example looks for a HTTP response to take between 15 seconds and 25 seconds to respond.

Step 5 (Required if you choose Simple string or Regex match type)- Response->Grep: In this section we must specify what we will look for in the HTTP response.

Simple String: What “Simple string” we will look for in the response. In this case we will look for three simple strings, “Simple String searched in the response 1”, “Simple String searched in the response 2”, “Simple String searched in the response N”.

Regex: What regular expression we will look for in the response. In this case we will look for three regular expressions, “Regular expression searched in the response 1”, “Regular expression searched in the response 2”, “Regular expression searched in the response N”.

Step 6 (Optional)- Response->Grep Options: In this section you can specify more options to create more accurate profiles and obtain fewer false positives. This options only are disponible for the Match types:

  • Simple string
  • Regex
  • Payload
  • Payload Encode

Each of the options will be detailed below:

  • Negative match: It will show you the alert, if the pattern you have set is not present in the HTTP response.
  • Case sensitive: The pattern will be searched in the HTTP response considering that it’s case sensitive.
  • Exclude HTTP headers: The pattern will NOT be searched in the HTTP headers. (Only in the body of the HTTP response)
  • Only in HTTP header: The pattern will ONLY be searched in the HTTP headers.
  • Content type: The pattern will only be searched in the HTTP response if the content type of the HTTP response is equal to the “content type” field. You can specify multiple content types separated by commas. You can also specify that ONLY look for the pattern in the HTTP response if the content type is NOT equal to this field, marking the “negative match” checkbox.
  • Status code: The pattern will only be searched in the HTTP response if the Status code of the HTTP response is equal to the “status code” field. You can specify multiple status code separated by commas. You can also specify that ONLY look for the pattern in the HTTP response if the status code is NOT equal to this field, marking the “negative match” checkbox.
  • URL Extension: It will only search for patterns if the extension of the URL to which the request is made, matches the extension or extensions specified in this field (for example, php or jsp, etc) or if it doesn’t match (negative match checkbox)

Step 7 (Optional)- Response->Redirections: In this section you can specify the redirection options. This options only are disponible for the Match types:

  • Simple string
  • Regex
  • Payload
  • Payload Encode

Each of the options will be detailed below:

  • Never: As the name suggests, no redirect will be followed.
  • On-site only: It will only follow the redirects that lead to the same site of origin.
  • In-scope only: It will only follow redirects that lead to a domain that is in scope.
  • Always: As the name suggests, it will follow all redirects.

Max redirections: In this field the maximum number of redirects that will follow is indicated.

Step 8 (Required)- Issue: It specifies the name that will appear in the alert and the criticality of that alert.

It’s necessary for the issue to appear, give it a “Issue Name” and complete the two fields, both the “severity” and the “confidence”. The issue descriptions are optional.

If you check the option “Don’t show this issue alert” the alert will not be shown in the dashboard, it will only be used for the Smart Scan.

Step 9 (Optional): A tag is created and assigned to the profile. These tags can be used to launch the “Scan Tags” scanner.

Passive Request Profiles

 
  • Passive Request Scanner: Look for strings/regex (or the absence of them) in HTTP requests.

Next let’s see how passive request profiles are created to look for something (or the absence of it) in the HTTP request.

Step 1 (Required): The name and author of the profile are first set.

Step 2 (Required): Specifies the pattern or patterns to search in the request.

  • You can add the pattern by click on the “add” button and modifying the value, or by pasting it directly with the “Paste” button if you already have it in the clipboard.
  • You can also load a patterns file (one per line) with the “Load file” button.

In this section you can choose in which insertion point you want to search for the pattern.

At the same time, the logical AND operator can be used when searching for a value. This allows us to further refine the profile and avoid false positives.

Step 4 (Required): Specifies which type of pattern to search in the insertion point.

  • Simple string
  • Regular expression

In this section you specify, if in the insertion point you want to search for a simple string or a regular expression.

Step 5 (Optional): Grep options are specified.

  • Negative match: It will show you the alert, if the pattern you have set is not present in the insertion point that you have chosen.
  • Case sensitive: The pattern will be searched in the insertion point considering that it’s case sensitive.
  • URL Extension: It will only search for patterns if the extension of the URL to which the request is made, matches the extension or extensions specified in this field (for example, php or jsp, etc) or if it doesn’t match (negative match checkbox)

Step 6 (Required): It specifies the name that will appear in the alert and the criticality of that alert.

It’s necessary for the issue to appear, give it a “Issue Name” and complete the two fields, both the “severity” and the “confidence”. The issue descriptions are optional.

Step 7 (Optional): A tag is created and assigned to the profile. This is useful for better organization of profiles.

Passive Response Profiles

GBounty Profiles Designer gives you the ability to create your own vulnerability profiles to the passive scanner.

  • Passive Response Scanner: Look for strings/regex (or the absence of them) in HTTP response

Next let’s see how passive response profiles are created to look for something (or the absence of it) in the HTTP response.

Step 1 (Required): The name and author of the profile are first set.

Step 2 (Required): It specifies the pattern or patterns to look for in the HTTP response.

  • You can add the pattern by click on the “add” button and modifying the value, or by pasting it directly with the “Paste” button if you already have it in the clipboard.
  • You can also load a patterns file (one per line) with the “Load file” button.
  • At the same time, the logical AND operator can be used when searching for a value. This allows us to further refine the profile and avoid false positives.

Step 3 (Required): Specifies which type of pattern to search in the response.

  • Simple string
  • Regular expression

In this section you specify, if in the insertion point you want to search for a simple string or a regular expression.

Step 4 (Optional): Specify how many times this issue will be displayed for one domain.

  • Only once per domain: Only once time for all HTTP responses in one domain.
  • All times in a domain: Every time that the pattern is detected in the domain HTTP responses.

Step 5 (Optional): Grep options are specified.

  • Negative match: It will show you the alert, if the pattern you have set is not present in the HTTP response.
  • Case sensitive: The pattern will be searched in the HTTP response considering that it’s case sensitive.
  • Exclude HTTP headers: The pattern will NOT be searched in the HTTP headers. (Only in the body of the HTTP response)
  • Only in HTTP header: The pattern will ONLY be searched in the HTTP headers.
  • Content type: The pattern will only be searched in the HTTP response if the content type of the HTTP response is equal to the “content type” field. You can specify multiple content types separated by commas. You can also specify that ONLY look for the pattern in the HTTP response if the content type is NOT equal to this field, marking the “negative match” checkbox.
  • Status code: The pattern will only be searched in the HTTP response if the Status code of the HTTP response is equal to the “status code” field. You can specify multiple status code separated by commas. You can also specify that ONLY look for the pattern in the HTTP response if the status code is NOT equal to this field, marking the “negative match” checkbox.
  • URL Extension: It will only search for patterns if the extension of the URL to which the request is made, matches the extension or extensions specified in this field (for example, php or jsp, etc) or if it doesn’t match (negative match checkbox)

Step 6 (Optional): Redirection options are specified. You can choose between the following options:

  • Never: As the name suggests, no redirect will be followed.
  • On-site only: It will only follow the redirects that lead to the same site of origin.
  • In-scope only: It will only follow redirects that lead to a domain that is in scope.
  • Always: As the name suggests, it will follow all redirects.

Max redirections: In this field the maximum number of redirects that will follow is indicated.

Step 7 (Required): It specifies the name that will appear in the alert and the criticality of that alert.

It’s necessary for the issue to appear, give it a “Issue Name” and complete the two fields, both the “severity” and the “confidence”. The issue descriptions are optional.

If you check the option “Don’t show this issue alert” the alert will not be shown in the dashboard, it will only be used for the Smart Scan.

Step 8 (Optional): A tag is created and assigned to the profile. This is useful for better organization of profiles.