GBounty Usage
GBounty supports a number of flags that allow you to customize the behavior of the tool.
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:
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:
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:
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.
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:
The format of the raw request req1.txt could be something like this:
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:
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 asGET
,POST
,PUT
, orDELETE
. For example, you could use the-X
flag like this:gbounty -X POST -u https://example.com
. This would tell gbounty to use thePOST
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 theAccept
andContent-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:
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:
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:
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.
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
In this example, the -email
flag is used to specify that gbounty should inject the email address user@example.com
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 user@example.com
.
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:
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:
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:
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.
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.
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:
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:
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:
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:
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:
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:
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:
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:
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:
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
.
The gbounty
command above will scan the URL https://example.org
using a POST request with the data “param1=value1¶m2=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.
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
.
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.
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
Last updated