Flags

What follows is an exhaustive breakdown of every flag currently supported. These are listed as they appear in the help string.

Connection

    -i [ip address]       Server address

Specifies the remote host to connect to and scan. If a FQDN is given, clusterd will attempt to resolve this. Currently only IPv4 addresses are accepted, but this may change over time.

     -iL [file]            Server list

Specifies a file of IP addresses to load. This should be a readable text file with IP addresses specified, one per line. This list may contain FQDN's that will be resolved to their respective IP addresses.

     -p [port]             Server port

The port that clusterd should specifically look for. This option should be used if any of the platforms are running on non-default ports. If the port option is not given, the default ports for each service will be checked.

    --proxy [proxy://server:port]

Specify the proxy that all clusterd requests will go through. Currently clusterd only supports HTTP and HTTPS proxies, but SOCKS support will be included once the Requests library merges it. To specify an HTTP proxy, for example, one might enter: ````--proxy http://192.168.1.32:8080```. All traffic sent from clusterd will then go through this proxy.

    --proxy-auth [username:password]

If the specified proxy requires authentication, this option can be set. This accepts credentials separated by a colon.

    --timeout [seconds]   Connection timeout [5s]

Timeout for requests. If you are testing a server over a VPN, you may want to bump this value up to give the remote host more time to respond. The default setting is 5 seconds.

    --random-agent        Use a random User-Agent for requests

When submitting HTTP requests, clusterd will, by default, use the Requests library User-Agent. However, this flag can be specified which will randomly select a user agent from ./src/lib/user-agents.txt to use for all HTTP requests.

	--ssl                 Force SSL	

This enables SSL to the remote host, i.e. HTTP -> HTTPS.

Remote Host

	-a [jboss|coldfusion|weblogic|tomcat]	Hint at remote host service

By hinting at the remote platform to check for, clusterd will only check fingerprints for this specific platform. Without it, all checks will be made until a valid fingerprint is found.

	-o [windows|linux]    Hint at remote host OS

By default, clusterd assumes the remote OS is Windows. This setting is primarily important for auxiliary modules that may need to exploit LFI vulnerabilities, or for generating payloads.

	-v [version]          Specific version to test

This option will only check fingerprints whose version is matched by this string. By default, all fingerprints are checked. This can be specified with both a major version and with a major and minor.

	--usr-auth [username:password]		Login credentials for service

Specify credentials for the remote platform. This is a colon delimited value of username:password.

	--fingerprint         Fingerprint the remote system

Fingerprint the platform's auxiliary modules against the remote host. This will display which auxiliary modules are applicable to the discovered system.

	--arch [x86|x64]      Specify remote OS architecture

Specify the architecture of the remote host. Primarily used for payload generation.

Deploy

	--deploy [file]       Deploy to the discovered service

Deploy a local file to a remote host. This setting accepts either a relative or absolute path to the file to deploy.

    --undeploy [context]  Undeploy file from server

Undeploy the given app from the remote server. This will attempt to invoke standardized undeployment functions, but some traces may still remain on the server until reboot, most notably in JBoss.

	--deployer [deployer]	  Specify a deployer to use

By default, clusterd will select the first deployer applicable to the discovered fingerprint. However, if you need to use a specific deployer for any reason, this option will allow you to do that. A full list of deployers and their names can be found using the --deploy-list flag.

	--invoke              Invoke payload after deployment

Once a payload has been deployed, you can automatically invoke the payload. This is useful in scenarios where a reverse shell payload is deployed and the Metasploit handler has already been initialized.

    --rand-payload

When deploying a payload, this flag may be used to obfuscate the payload name. For example, if shell.war is being deployed and the --rand-payload flag is provided, clusterd will randomly generate a new payload name. This is especially useful when using custom payloads with alarming names, such as meterpreter_shell.war or backdoor.war.

	-b [user]             Brute force credentials for user [admin]

clusterd supports bruteforcing credentials. By default, the default user used is admin. This option supports setting a different user account name to brute force.

	--wordlist [path]     Wordlist for brute forcing passwords

This option accepts a relative or absolute path to a password list, one per line, for use in brute forcing credentials on a remote platform. This will only be invoked once clusterd encounters a scenario in which it cannot authenticate with default or user-provided credentials.

Miscellaneous

	--deployer-list [platform]         List all available deployers

List deployers currently available in clusterd, along with what versions they're applicable to. The format of the dump is: Interface (deployer name [supported versions]). This flag also accepts a single argument, platform, which then only prints a specific platform's modules.

	--aux-list [platform]           List all available exploits

List auxiliary modules currently available in clusterd. If no platform is provided, all platform auxiliary modules will be listed. This flag also accepts a single argument, platform, which then only prints a specific platform's modules.

	--gen-payload [host:port] for reverse connection 	Generate a reverse shell payload

This flag can be used to generate a reverse shell payload. Though limited, this flag can be used to quickly generate a reverse shell and deploy it to the remote server. This flag uses java/jsp_shell_reverse_tcp for all platforms except for Axis2, which uses the Java meterpreter. The required arguments are the host and port to send the connection to, where a listener should already be initialized. The generated file will be named "shell.war" or "shell.jsp" and exist in the root clusterd directory.

    --discover [discovery_file]
                    Attempt to discover application servers using the
                    specified nmap gnmap output (use -sV when scanning)

Using the output of an nmap -sV -oG scan, we can attempt to discover application servers on all open HTTP ports. This option will scan all hosts and open, HTTP-based ports parsed out of an nmap gnmap file (specified by -oG). The benefit of this is coverage of any non-standard instances of application servers across multiple hosts, ensuring only open and relevant ports are probed. This option should be used with no other flags specified: ./clusterd.py --discover subnet_scan.g

    --listen [adapter]    Adapter to listen on when needed

Some of clusterd's deployers need to make a connection back to retrieve a payload or file for deployment; this flag can be used to set the adapter to listen on. Otherwise, clusterd will select the first available adapter.

	-d                    Enable debug output

Enables debugging output, such as HTTP request information, internal state information, and more. There is currently only one level of debugging.

	-l                    Log output to file [$time$_log.log]

All output sent to stdout is also written into a timestamped file in the root clusterd directory. If debugging is enabled, this output is also written to the file.