Running the ./havoc CLI with the -p option will drop you into an interactive console. If a profile is specified, the profile's corresponding connection parameters will be used. If no profile is specified, the default profile will be used. If a default profile does not exist, the ./havoc CLI will terminate with an error.

To start the ./havoc CLI in console mode with a specific profile, use the following command:
./havoc -p <profile>

To exit the ./havoc CLI console, type exit or press Ctrl+D.

The ./havoc CLI console supports the following administration commands:

Users

When the ./havoc platform is deployed, an initial admin user is created along with an API key and secret. The admin user can create additional admin and non-admin users that are allowed to interact with the Campaign API. Admin users have full administrative control of all Campaign resources, including the ability to create and delete users as well as reset users' API key and secret. Non-admin users have full control of all resources except for the users resource however, they can reset their own API key and secret.

Create a user
create_user --user_id=<user_id> --admin=[yes|no]

--user_id - (required) a unique identifier to associate with the user.
--admin - (optional) specify whether or not the user has admin privileges (defaults to no).

Delete a user
delete_user --user_id=<user_id>

--user_id - (required) the user_id of the user to be deleted.

Get a user's details
get_user --user_id=<user_id>

--user_id - (required) the ID of the user to get.

List users
list_users

Update a user
update_user --user_id=<user_id> --new_user_id=<new_user_id> --admin=[yes|no] --reset_keys=[yes|no]

--user_id - (required) the user_id associated with the user to make updates to.
--new_user_id - (optional) a new unique identifier to associate with the user.
--admin - (optional) - add or remove admin privileges for the user (defaults to no change).
--reset_keys - (optional) - forces a reset of the user's API key and secret (if not present, keys are not changed).

Users can use this method to reset their own API key and secret however, they will not be able to change their own user_id or admin status.

Portgroups

Portgroups are useful for container tasks that are expecting inbound connections from a victim machine, e.g. a Metasploit Framework container task that is running a reverse_tcp handler will need a port opened to allow inbound connections to whichever port the reverse_tcp handler is listening on. Portgroups must be managed in two steps. First, the portgroup must be created. Once it exists, rules permitting access to the container task can be added to the portgroup. A portgroup has to be assigned to a task at task launch. See Launching Container Tasks section of the Usage Through CLI Console page for more information. A portgroup that is associated with a running task cannot be deleted. Terminating the task or using the kill_task method will ensure that the task is disassociated with the portgroup. Portgroups cannot be associated with remote container tasks. See Launching Remote Container Tasks section of the Usage Through CLI Console page for more information about exposing ports on remote container tasks.

Create a portgroup
create_portgroup --portgroup_name=<portgroup_name> --porgroup_description=<portgroup_description>

--portgroup_name - (required) a unique identifier to associate with the portgroup.
--porgroup_description - (required) a description containing the purpose of the portgroup.

Delete a portgroup
delete_portgroup --portgroup_name=<portgroup_name>

--portgroup_name - (required) the name of the portgroup to be deleted.

Get a portgroup's details
get_portgroup --portgroup_name=<portgroup_name>

--portgroup_name - (required) the name of the portgroup to retrieve details for.

List portgroups
list_portgroups

Update a portgroup to add or remove a portgroup rule
update_portgroup_rule --portgroup_name=<portgroup_name> --portgroup_action=[add|remove] --ip_ranges=<CIDR_range> --port=<port_number> --ip_protocol=[udp|tcp|icmp]

--portgroup_name - (required) the name of the portgroup to modify.
--portgroup_action - (required) indicate whether to add or remove a rule.
--ip_ranges - (required) the IP address range that is allowed access by the portgroup rule.
--port - (required) the port number that the IP ranges are allowed to access.
--ip_protocol - (required) the IP protocol that IP ranges are allowed to use.

Note that ICMP rules can currently only be used to open all ICMP traffic types.

Domains

Domains provide a way to make hosted zones in your AWS account available for use with container tasks. For instance, if you would like to run a listener on a PowerShell Empire task that accepts connections to a domain instead of an IP address, you can use the domain resource to manage the domains that are available for this purpose. Once the domain is present, you can use the run_task command to execute a container task with a host name and domain name.

Note that this method does not register the domain or create the hosted zone for you. You must have an existing domain with a corresponding hosted zone present in the AWS account where your ./havoc deployment resides.
Domains cannot be associated with remote container tasks.

Create a domain
create_domain --domain_name=<domain_name> --hosted_zone=<zone_id>

--domain_name - (required) the domain name associated with the domain to be created.
--hosted_zone - (required) the zone ID of the hosted zone associated with the domain.

Delete a domain
delete_domain --domain_name=<domain_name>

--domain_name - (required) the name of the domain to be deleted.

If you specified a domain during deployment of your ./havoc campaign, that domain will be used as your Campaign API domain and cannot be deleted with this method.

Get a domain
get_domain --domain_name=<domain_name>

--domain_name - (required) the name of the domain to retrieve details for.

List domains
list_domains

Task Types

Task types reflect the various container tasks that are supported by the ./havoc platform. Each container task has a unique set of commands that can be used to instruct the container to perform various activities. The get_task_type method will provide a list of supported commands for the specified task type.

Create a task type
create_task_type --task_type=<task_type_name> --source_image=<source_image_url> --capabilities=<commands> --cpu=<number> --memory=<number>

--task_type - (required) provide a name to be used when referring to the task type.
--source_image - (required) provide the public registry entry for the container (make sure to include the image version, e.g. ":latest".
--capabilities - (required) a comma-separated list of commands that the container task supports.
--cpu - (required) amount of cpu units reserved for the task. This parameter maps to CpuShares in the Create a container section of the Docker Remote API and the --cpu-shares option to docker run. The number of CPU units is linked with the amount of memory allocated for the container. See the Task Size section of Amazon's Task definition parameters for more information about allocating CPU units and memory.
--memory - (required) a number that represents the amount (in MiB) of memory to present to the container. If your container attempts to exceed the memory specified here, the container is killed. This parameter maps to Memory in the Create a container section of the Docker Remote API and the --memory option to docker run. The amount of memory allocated is linked with the number of CPU units for the container. See the Task Size section of Amazon's Task definition parameters documentation for more information about allocating CPU units and memory.

Delete a task type
delete_task_type --task_type=<task_type_name>

--task_type - (required) the name of the task type to be deleted.

Get a task type
get_task_type --task_type=<task_type_name> - Get details of a given task type.

--task_type - (required) the task_type you want to retrieve details for.

List task types
list_task_types

Tasks

The currently running container tasks associated with your ./havoc deployment will be reflected as tasks. For more information about launching and interacting with tasks, see the Usage page.

Get a task's details
get_task --task_name=<task_name>

--task_name - (required) the name of the task to retrieve details for.

List tasks
list_tasks

Kill a task
kill_task --task_name=<task_name>

--task_name - (required) the name of the task to kill.

Note that the kill_task method should only be used on cloud container tasks that are unresponsive or on remote container tasks that have already been terminated but are still listed in the list_tasks output. When the kill_task method is invoked for a cloud task, an ECS API call is made that force kills the container in ECS and the container's task details are deleted from various tables in DynamoDB. In this case, the container does not go through its normal termination process so there won't be any container task confirmation that the task terminated. For remote container tasks that are killed this way, it is assumed that the actual container has already exited so the Campaign API simply deletes the container task's entry from the "tasks" table in DynamoDB. If a remote container task has already exited but still appears in the list_tasks output, that implies that the container did not go through its normal termination process meaning that there won't be any container task confirmation that the task terminated.

Workspace

The workspace is a place to store files that are shared amongst all container tasks. This is useful for payloads that are generated by one container task and then distributed by another. When a container task starts up, it automatically downloads all of the files in the workspace to a local directory on the container task. If a payload is generated by a container task, you can instruct the container task to push the payload up to the workspace. See the Interacting with Container Tasks section of the Usage Through CLI Console page for more information about using the workspace to share files between container tasks.

Create a file
create_file --file_name=<file_name> --file_path=<file_path>

--file_name - (required) the name of the file to upload.
--file_path - (required) the path to the local directory where the file resides.

Delete a file
delete_file --file_name=<file_name>

--file_name - (required) the name associated with the file you would like to delete from the shared workspace.

Get a file
get_file --file_name=<file_name> --file_path=<file_path>

--file_name - (required) the name of the file to download.
--file_path - (required) the path to the local directory to download the file to.

List files
list_files