# Welcome to the Ax Framework Wiki {% hint style="info" %} **Costs:** While Ax is free and open-source, spinning up servers requires a cloud account. {% endhint %} ## Overview The Ax Framework is a free and open-source tool utilized by Bug Hunters and Penetration Testers to efficiently operate in multiple cloud environments. It helps build and deploy repeatable infrastructure tailored for offensive security purposes. Ax includes a set of Packer Provisioner files to choose from ([JSON](https://github.com/attacksurge/ax/tree/master/images/json/provisioners) or [HCL](https://github.com/attacksurge/ax/tree/master/images/pkr.hcl/provisioners)), or you can [create your own](https://ax-framework.gitbook.io/wiki/fundamentals/bring-your-own-provisioner) (recommended). Whichever [Packer](https://www.packer.io/) Provisioner you select, Ax installs your tools of choice into a "base image". Then using that image, you can deploy fleets of fresh instances (cloud hosted compute devices). When building an image using the [Default](https://github.com/attacksurge/ax/blob/master/images/pkr.hcl/provisioners/default.pkr.hcl) Provisioner, you can connect and immediately access a wide range of tools useful for both Bug Hunting and Penetration Testing. Various [Ax Utility Scripts](https://ax-framework.gitbook.io/wiki/fundamentals/ax-utility-scripts) streamline tasks like spinning up and deleting fleets of instances, parallel command execution and file transfers, instance and image backups, and many other operations. Ax Framework leverages the power of ephemeral, automated infrastructure to make cloud-based scanning operations fast and efficient. With Ax, you can quickly spin up disposable cloud instances, distribute your scanning workloads, and manage large-scale operations with ease. The framework supports running arbitrary binaries and scripts, determined by the specific Packer Provisioner you select and [Module](https://ax-framework.gitbook.io/wiki/fundamentals/scans/modules) you use. Once Ax is set up and configured, you can deploy a fleet of 50-100+ instances in just minutes, distribute a highly parallelized scan against a large scope of targets, and deliver rapid, reliable results. This functionality is known as [ax scan](https://ax-framework.gitbook.io/wiki/fundamentals/scans). Ax attempts to follow the Unix philosophy by providing building blocks that allow users to easily orchestrate one or many cloud instances. This flexibility enables the creation of continuous scanning pipelines and the execution of general, one-off, highly parallelized workloads. Currently Digital Ocean, IBM Cloud, Linode, Azure, AWS, Hetzner and GCP are officially supported cloud providers. {% hint style="info" %} **Bash:** Ax is predominantly written in Bash! This makes it easy to contribute to, and it was chosen because [early versions](https://github.com/pry0cc/axiom) were rapidly prototyped in this language. {% endhint %} Feel free to join us on discord! ## Quick links {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/2Vgm9IekPFjv2w9YoiG5" %} [Existing Users](/overview/existing-users) {% endcontent-ref %} {% content-ref url="/pages/Bg5772qnAcnjjZNw9hsb" %} [Installation Guide](/overview/installation-guide) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/vtRzyA4BUwnWj8Q17jgF" %} [Ax Controller](/overview/ax-controller) {% endcontent-ref %} {% content-ref url="/pages/qhMJ57biRGYCu4fKhd1y" %} [How it Works](/overview/how-it-works) {% endcontent-ref %} ## Fundamentals We've put together some helpful guides so you can quickly familiarize yourself with the different aspects of Ax. {% content-ref url="/pages/HQ5yPnEqkNORGBQBMebP" %} [Ax Utility Scripts](/fundamentals/ax-utility-scripts) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/905SKrbe37yH0tdO5gnp" %} [Bring Your Own Provisioner](/fundamentals/bring-your-own-provisioner) {% endcontent-ref %} {% content-ref url="/pages/gyl2Olg9EaayDTJctRAO" %} [Fleets](/fundamentals/fleets) {% endcontent-ref %} {% content-ref url="/pages/PZ8SsaMBcpFmIRHOxGBb" %} [Scans](/fundamentals/scans) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/AbJU447DOil9Qwlofpqb" %} [Modules](/fundamentals/scans/modules) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/JmNNsmf6i7Z0ThYHwRLO" %} [Adding Simple Modules](/fundamentals/scans/modules/adding-simple-modules) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/C2L93nuz2tt9VN9NGwF1" %} [Adding One-Shot Modules](/fundamentals/scans/modules/adding-one-shot-modules) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/sK0OonbrJYISsolJZsRi" %} [Merging and Module Extensions](/fundamentals/scans/modules/merging-and-module-extensions) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/YeDhD4GgPvzSLwN4wCgE" %} [Horizontal vs Vertical Scaling](/fundamentals/scans/horizontal-vs-vertical-scaling) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/gnKXVXySAsXPcvZrsl9w" %} [Responsibility](/fundamentals/responsibility) {% endcontent-ref %} {% content-ref url="/spaces/s46RuXd5f9V1SYcGUiYQ/pages/t0FKezbzS2vgk9WEITtL" %} [Terminology](/fundamentals/terminology) {% endcontent-ref %} # Existing Users We are deeply committed to maintaining continuity for Axiom Classic users, carefully preserving many of the core principles you may rely on. Most importantly, your existing automation, scripts, and modules should continue to function without any need for modifications. ## Upgrading from Axiom Classic Before proceeding with the upgrade, it is highly recommended that you back up your existing Axiom Classic folder to a safe location: ``` mkdir ~/axiom-classic && cd ~/axiom-classic && zip -r axiom-classic-bak.zip ~/.axiom/ ``` Next, backup any custom modules you might have created. ``` mkdir ~/axiom-classic/custom-modules && cp ~/.axiom/modules/custom.json ~/.axiom/modules/custom2.json ~/axiom-classic/custom-modules/ ``` After backing up, you can delete your current Axiom Classic folder and proceed with [installing](/overview/installation-guide#easy-install) the Ax Framework. **Ensure that the `~/.axiom/` folder does not exist before installing the Ax Framework.** Once Ax is installed and configured, simply copy your custom modules back into the `~/.axiom/modules/` directory. And that’s it! You are now fully prepared to use the Ax Framework. If you ever need to revert to Axiom Classic, just delete the new `~/.axiom/` folder and restore your Axiom Classic backup folder. ## Syntax Changes We've placed a strong emphasis on ensuring that existing Axiom Classic users can quickly transition to the new Ax Framework with minimal syntax changes. Here are some key changes to be aware of: **`ax` Wrapper**: The new `ax` wrapper seamlessly passes additional arguments to the appropriate `axiom-*` script in the background (located in `~/.axiom/interact/axiom-*`). This means you can fully control all aspects of the new framework without ever leaving `ax`. While this wrapper simplifies control, using it is optional—you can still run `axiom-*` scripts directly as you did before. **ax configure**: Previously, running `axiom-configure` without any arguments would start the configuration flow to install dependencies. Now, it shows the help menu instead. To start the installation flow, you’ll need to add the `--run` argument to `ax configure`. **ax account-setup:** Now officially supports [Hetzner](https://accounts.hetzner.com/_ray/pow) and [GCP](https://cloud.google.com/) as additional cloud providers. **ax build**: Previously, running `axiom-build` without any arguments would automatically start the Packer image builder. Now, this command shows the help menu. To start the image build, you’ll need to add the `--run` argument to `ax build`. **ax init**: Earlier, running `axiom-init` without arguments would initialize a single instance with a random name. Now, it brings up the help menu instead. To spin up one instance with a random name, use `axiom-init --run`. This change helps ensure you don’t miss out on the helpful options available, which were often overlooked in Axiom Classic. **ax fleet**: Similarly, running `axiom-fleet` without arguments used to create a fleet of three instances automatically. Now, it displays the help menu for the same reasons as above. To spin up a fleet of three instances, use `ax fleet -i 3`. **ax rm:** To avoid accidental deletions of instances, now all cloud providers support the optional `-f` argument to forcefully delete instances, avoiding confirmation prompts (previously only Digital Ocean, IBM Cloud and Azure supported `-f`). **ax images create**: In Axiom Classic, creating a snapshot of an existing instance for future fleets was done using `axiom-backup`. This functionality has now been moved to `ax images create`. **ax scp**: Now, `ax scp` supports optionally splitting a file across a fleet of instances, equally distributing the file (`--split`) **ax sizes**: The new `ax sizes` scripts allows you to list all instance sizes the cloud provider has to offer. Select the default instance size to use for `ax fleet` and `ax init`. To restore to the default instance size, use `ax sizes default`. **vars.sh:** You can now control the Go Lang version installed on the Ax controller and remote instances by specifying the [GolangVersion ](https://github.com/attacksurge/ax/blob/master/interact/includes/vars.sh)in `vars.sh`. You will need to rebuild (`ax build --run`) if this is changed. ### ax scan: Key Updates and Enhancements * **New Options and Refactoring**: We've added several new options to `ax scan`, and some existing options have been refactored. #### **FOLDER** * **New \_folder*****\_***** Variable Replacement**: In Axiom Classic, the path to Nuclei templates was treated as a wordlist (using the `_wordlist_` variable replacement). Now, the options `--local-folder` and `--remote-folder` have been introduced. To upload a local folder, use `--local-folder`, which utilizes the `_folder_` variable replacement. For backward compatibility, `--nuclei-templates` with `_wordlist_` is still supported, but you will receive a warning about the syntax. #### **ONE-SHOT** * **Track Finished Targets**: When using [One-Shot](/fundamentals/scans/modules/adding-one-shot-modules) modules with the `ax scan` option `--track-finished`, it now tracks which targets have been scanned and stores them in a file named `finished.txt` on the remote instances #### **OPTIMIZATIONS** * **File Uploads and Downloads**: Before a scan starts, you can now upload an arbitrary file to the remote scan working directory at runtime using `--upload`. Additionally, after the scan finishes, you can download an arbitrary file from the remote scan working directory with `--download`. * **anew Option**: The `--anew` argument has been moved from being an output type to a standalone option. Previously, you would use it like this: `axiom-scan input -m module -anew anew-output.txt`. Now, the syntax is `ax scan input -m module -o anew-output.txt --anew`. Note that this also requires the extension `"ext":"txt"`, `"ext":"oG"`, or `"ext":"csv"` to be included in the module. #### **OUTPUT** * **`-oT` / `-txt`**: \ Previously, this output type and module [extension](/fundamentals/scans/modules/merging-and-module-extensions) `"ext":"txt"` would automatically sort and deduplicate results. Now, instead of sorting, the results are simply concatenated into a single file without further processing. * **`-oG`**:\ This new output type and module [extension](/fundamentals/scans/modules/merging-and-module-extensions) `"ext":"oG"` now handles sorting and deduplication of results. * **`-jsonl`**:\ A new output type and module [extension](/fundamentals/scans/modules/merging-and-module-extensions) `"ext":"jsonl"` that supports merging JSON Lines. * **`--no-logs`**:\ This flag disables all logging. It prevents the storage of logs and terminal output. Additionally, it deletes all log files, including unmerged output files located in `~/.axiom/logs/$module+$timestamp/output`. * **Filename Format**:\ In Axiom Classic, if you didn’t specify an output filename for `axiom-scan`, it would generate one using the format `scan+$timestamp`. Now, this has been updated to `$module+$timestamp`, where `$module` represents the specific module used during the scan. #### **FLEET** * **`--shutdown-when-done`**:\ Now initiates the shutdown of instances without waiting for all the scanners to complete. #### **EXTRA ARGS** * **Explicit Extra Arguments**:\ Axiom has always automatically interpolated user-provided command-line arguments into the module, combining them with the module's command and executing them on remote instances in parallel. This core behavior remains unchanged. However, with the new Ax Framework, you now have the option to explicitly define extra arguments to be passed to the module, rather than relying solely on automatic interpolation. The `--extra-args` flag must be used with commands wrapped in either single or double quotes, depending on whether you want variable expansion to occur locally (double quotes) or remotely (single quotes). # Installation Guide {% hint style="info" %} **Note:** The machine you install Ax on is called the [Ax Controller.](/overview/ax-controller) The Controller manages all aspects of Ax, including account setup, building your Packer image, spinning up and SSHing into instances, creating new images from existing instances, deleting instances and images, managing distributed scanning, and much more! {% endhint %} ## Operating Systems Supported | OS | Supported | Easy Install | Tested | | ---------- | --------- | ------------ | ------------- | | Ubuntu | Yes | Yes | Ubuntu 22.04 | | Kali | Yes | Yes | Kali 2024.2 | | Debian | Yes | Yes | Debian 12 | | Windows | Yes | Yes | WSL w/ Ubuntu | | MacOS | Yes | Yes | MacOS 14 | | Arch Linux | Yes | No | Yes | ## Docker Install This will create a docker container, initiate ax configure and ax build and then drop you out of the docker container. After a Packer image is successfully created, you will likely have to re-exec into your docker container. ``` docker exec -it $(docker run -d -it --platform linux/amd64 ubuntu:20.04) sh -c "apt update && apt install git -y && git clone https://github.com/attacksurge/ax/ ~/.axiom/ && cd && .axiom/interact/axiom-configure --run" ``` ## Easy Install As a standard user with root privileges, run this command on any [supported](#operating-systems-supported) OS. The script will prompt for sudo when root when required. ``` bash <(curl -s https://raw.githubusercontent.com/attacksurge/ax/master/interact/axiom-configure) --run ``` ## Git Clone In most cases, the easy install should work, however, if you do want to install using git clone, this guide is your friend! Ensure that `~/.axiom/` does not exist ``` rm -rf ~/.axiom/ ``` Clone the Ax repository ``` git clone https://github.com/attacksurge/ax.git ~/.axiom/ ``` Run ax configure script ``` ~/.axiom/interact/axiom-configure ``` ## Manual To install Ax on an OS that is not on our [supported](#operating-systems-supported) list, all you have to do is ensure that you have all the right dependencies and then run `ax account-setup`. Clone the Ax repository ``` git clone https://github.com/attacksurge/ax.git ~/.axiom/ ``` ### Dependencies * Cloud providers API key * SSH Keypair (without password) * git * curl * ruby * jq - 1.6 or higher * packer - Tested with v1.5.6 * the cloud providers CLI (doctl, linode, ibmcloud, az, aws) * Interlace - (created by [codingo](https://x.com/codingo_) and [sml555](https://twitter.com/sml555_)) * rsync * add `~/.axiom/interact` to your path ## **Troubleshooting Guide** If you're experiencing an error, especially one that started recently, please follow these steps to troubleshoot the issue: 1. **Run `ax update`:** Ensure that you've successfully run `ax update` before reporting any issues. This step often resolves problems by bringing your installation up to date. 2. **Checklist:** * **Build an Image:** Have you successfully built an image with `ax build`? Check all available images with `ax images ls` to confirm. * **Cloud Provider CLI:** Ensure that the cloud provider's CLI is properly installed and authenticated by running `ax account-setup`. * **Reinstall Dependencies:** Run `ax configure --run` to reinstall all necessary dependencies. * **Rebuild Image:** If the issue persists, try building a new image by running `ax build --run`. 3. **Last Resort:** * If the problem still isn't resolved, as a last resort, delete Ax by running `rm -rf ~/.axiom` and then reinstall it from scratch. This often fixes issues that occurred during the initial installation. ## FAQ #### How can I upgrade from [Axiom Classic](https://github.com/pry0cc/axiom) to the Ax Framework? Refer to [Existing Users](/overview/existing-users) for a detailed overview of how to upgrade. #### I can't SSH in to my instances, I get permission denied/wrong password? Be default, Ax creates an SSH key named axiom\_rsa in `~/.ssh/axiom_rsa`. The reference to the SSH key is stored in `~/.axiom/axiom.json`. You can change the `sshkey` value to another SSH key as long as its stored in `~/.ssh/`. You may need need to rebuild (`ax build --run`) with your new SSH key to use it. #### I spin up `X` instances but only `Y` provision, whats wrong? Check that you havent exceeded your instance limit. After a few billing cycles you can generally increase your instance limit via opening a support ticket with the associated cloud provider #### Will distributing my scans make me a better hacker? Probably not. The Ax Framework isn't about improving your fundamental skills or intuition; it's about enhancing your efficiency and speed. Distributing your scans will undoubtedly allow you to cover more ground in less time, but the core principles of finding vulnerabilities remain unchanged. If you struggle to identify bugs without Ax, simply adding more computational power won't necessarily lead to the discovery of higher-quality bugs. Ax accelerates the process, but it doesn't replace critical thinking, creativity, and in-depth understanding. It's a tool that enhances what you already know and can do—not a shortcut to expertise. # Ax Controller The machine you install Ax on is called the Ax Controller. The Controller manages all aspects of Ax, including account setup, building your Packer image, spinning up and SSHing into instances, creating new images from existing instances, deleting instances and images, managing distributed scanning, and much more! The Ax Controller executes the various scripts in `~/.axiom/interact` and stores account credentials in `~/.axiom/accounts/$account-profile-name.json`
Ax Usage ``` Description: Welcome to the Ax Framework! You can use this wrapper to execute the various axiom scripts (located in ~/.axiom/interact/) To supply additional arguments to a script, simply append them to the command For more options, print the help menu for any script (ax init, ax fleet, ax scan, ax images, etc) Or you could just run the scripts without the wrapper (axiom-exec for example) Examples: ax configure --setup --shell zsh --unattended # Kick off axiom configuration wizard, add axiom to zsh path, avoid any prompts ax account-setup # Kick off axiom account setup wizard ax account linode # Switch to linode account (must be a valid axiom.json in ~/.axiom/accounts) ax build default # Build the Packer image with the Default provisioner located in ~/.axiom/images/provisioners/default.json ax init --run # Create axiom instance with random instane name ax fleet -i 10 -r nyc1,nyc3,fra1,sfo2 # Spin up 10 instances with random fleet prefix using Round-robin region distribution ax ls # List all instances on the account ax ssh testy01 # SSH into instance testy01 ax select testy\* # Select all instances in testy fleet (this updates ~/.axiom/selected.conf) ax scp custom-wordlist.txt 'myfleet*':/home/op/custom-wordlist.txt --split # Split and upload local wordlist to all instances in myfleet ax scan input.txt -m nuclei --nuclei-templates /home/localuser/custom-templates/ -o outputfile.txt # Run a distributed scan, upload custom nuclei templates ax rm testy\* # Delete all instances in testy fleet ax rm '\*' # Delete all instances on the account ax images ls # List all images on the account ax images create # Create a new image/snapshot of a running axiom instance ax images select axiom-testy01-1710180715 # Select image named axiom-testy01-1710180715 to use for future ax init and ax fleet ax power on rez\* # Power on all instances in fleet 'rez' ax region ls # List available regions ax region select nyc1 # Select region 'nyc1' (this updates ~/axiom.json with the new region) Usage: account Select Axiom account (axiom-account) account-setup Start Axiom account setup wizard (axiom-account-setup) build Start Axiom build wizard (axiom-build) configure Display commands to manage the configuration of axiom (axiom-configure), install dependencies, kick off axiom-account-setup and axiom-build deploy Deploy a profile stored in ~/.axiom/profiles/ (axiom-deploy) exec Evaluate shell one-liners or execute single commands on one or more instances in parallel (axiom-exec) fleet Display commands to manage fleets (axiom-fleet) images Create a new snapshot of a running axiom instance, select the new snapshot to deploy future axiom instances/fleets, get and delete images (axiom-images) init Display commands to manage initializing one axiom instance with differnet options, such as image, region, size and axiom deployment profiles (axiom-init) ls List all instances on the account (axiom-ls) power Display commands to manage powering on or off instances by name (axiom-power) region Display commands to list regions or select a region (axiom-region) rm Remove instances from the account (axiom-rm) scan Display commands to manange the distribution of arbitrary binaries and scripts across fleets of Axiom instances (axiom-scan) scp Display commands used to upload and download files from fleets (axiom-scp) select Select instances to use for exec and fleet (axiom-select) ssh Display commands to manage Axiom's ssh config file or connect to a specific Axiom instance (axiom-ssh) sync Make a copy of an instances home directoy and sync to your local filesystem (axiom-sync) update Run 'cd ~/.axiom && git pull' to update to the latest version! (axiom-update) To pass additional arguments to the script, simply append them to the command! ```
When installing the Ax Controller on Ubuntu, the following tools are installed as dependencies via `apt-get` ``` git ruby python3-pip curl iputils-ping net-tools unzip xsltproc bc rsync sudo wget nano bsdmainutils openssh-server fail2ban jq ``` Additionally, you'll have an option to install Golang. Golang is only required if using the `ax scan` flag `--anew`. If anew is not installed, `ax scan` will attempt to install it. If you decide to use Oh My Zsh during `ax configure`, the following tools are installed via apt-get ``` zsh zsh-syntax-highlighting zsh-autosuggestions ``` Interlace is also a very important dependency for Ax. Interlace (created by [codingo](https://github.com/codingo)) is responsible for all the parallelism conducted by Ax. Ax uses Interlace extensively for `ax exec`, `ax scp`, and `ax scan` ## SBOM The following is the SBOM of the Ax Controller when these options are used: `ax configure --setup --shell omz --unattended`
SBOM with Oh-My-Zsh and Golang installed {% code fullWidth="true" %} ``` |NAME |VERSION |TYPE | |---------------------------------------------------------------|----------------------------------------------------------|---------| |Interlace |1.9.8 |python | |PyGObject |3.36.0 |python | |adduser |3.118ubuntu2 |deb | |apt |2.0.10 |deb | |base-files |11ubuntu5.8 |deb | |base-passwd |3.5.47 |deb | |bash |5.0-6ubuntu1.2 |deb | |bc |1.07.1-2build1 |deb | |benchmark |0.1.0 |gem | |bigdecimal |2.0.0 |gem | |binutils |2.34-6ubuntu1.9 |deb | |binutils-common |2.34-6ubuntu1.9 |deb | |binutils-x86-64-linux-gnu |2.34-6ubuntu1.9 |deb | |bsdmainutils |11.1.2ubuntu3 |deb | |bsdutils |1:2.34-0.1ubuntu9.4 |deb | |build-essential |12.8ubuntu1.1 |deb | |bundler |2.1.2 |gem | |bzip2 |1.0.8-2 |deb | |ca-certificates |20230311ubuntu0.20.04.1 |deb | |certifi |2019.11.28 |python | |cgi |0.1.0 |gem | |chardet |3.0.4 |python | |cloud.google.com/go |v0.97.0 |go-module| |cloud.google.com/go/storage |v1.18.2 |go-module| |coreutils |8.30-3ubuntu2 |deb | |cpp |4:9.3.0-1ubuntu2 |deb | |cpp-9 |9.4.0-1ubuntu1~20.04.2 |deb | |csv |3.1.2 |gem | |curl |7.68.0-1ubuntu2.22 |deb | |d3-pprof |2.0.0 |npm | |dash |0.5.10.2-6 |deb | |date |3.0.0 |gem | |dbm |1.1.0 |gem | |dbus |1.12.16-2ubuntu2.3 |deb | |dbus-python |1.2.16 |python | |debconf |1.5.73 |deb | |debianutils |4.9.1 |deb | |delegate |0.1.0 |gem | |did_you_mean |1.4.0 |gem | |diffutils |1:3.7-3 |deb | |dirmngr |2.2.19-3ubuntu2.2 |deb | |distro |1.4.0 |python | |distro-info-data |0.43ubuntu1.16 |deb | |dmsetup |2:1.02.167-1ubuntu1 |deb | |dpkg |1.19.7ubuntu3.2 |deb | |dpkg-dev |1.19.7ubuntu3.2 |deb | |e2fsprogs |1.45.5-2ubuntu1.1 |deb | |etc |1.1.0 |gem | |fail2ban |0.11.1 |python | |fail2ban |0.11.1-1 |deb | |fakeroot |1.24-1 |deb | |fcntl |1.0.0 |gem | |fdisk |2.34-0.1ubuntu9.4 |deb | |fiddle |1.0.0 |gem | |file |1:5.38-4 |deb | |fileutils |1.4.1 |gem | |findutils |4.7.0-1ubuntu1 |deb | |fonts-lato |2.0-2 |deb | |forwardable |1.3.1 |gem | |g++ |4:9.3.0-1ubuntu2 |deb | |g++-9 |9.4.0-1ubuntu1~20.04.2 |deb | |gcc |4:9.3.0-1ubuntu2 |deb | |gcc-10-base |10.5.0-1ubuntu1~20.04 |deb | |gcc-9 |9.4.0-1ubuntu1~20.04.2 |deb | |gcc-9-base |9.4.0-1ubuntu1~20.04.2 |deb | |gdbm |2.1.0 |gem | |getoptlong |0.1.0 |gem | |gir1.2-glib-2.0 |1.64.1-1~ubuntu20.04.1 |deb | |git |1:2.25.1-1ubuntu3.13 |deb | |git-man |1:2.25.1-1ubuntu3.13 |deb | |github.com/1and1/oneandone-cloudserver-sdk-go |v1.0.1 |go-module| |github.com/Azure/azure-sdk-for-go |v55.7.0+incompatible |go-module| |github.com/Azure/go-autorest/autorest |v0.11.19 |go-module| |github.com/Azure/go-autorest/autorest/adal |v0.9.18 |go-module| |github.com/Azure/go-autorest/autorest/azure/auth |v0.4.2 |go-module| |github.com/Azure/go-autorest/autorest/azure/cli |v0.4.2 |go-module| |github.com/Azure/go-autorest/autorest/date |v0.3.0 |go-module| |github.com/Azure/go-autorest/autorest/to |v0.4.0 |go-module| |github.com/Azure/go-autorest/autorest/validation |v0.3.1 |go-module| |github.com/Azure/go-autorest/logger |v0.2.1 |go-module| |github.com/Azure/go-autorest/tracing |v0.6.0 |go-module| |github.com/Azure/go-ntlmssp |v0.0.0-20200615164410-66371956d46c |go-module| |github.com/ChrisTrenkamp/goxpath |v0.0.0-20210404020558-97928f7e12b6 |go-module| |github.com/Masterminds/goutils |v1.1.1 |go-module| |github.com/Masterminds/semver |v1.5.0 |go-module| |github.com/Masterminds/sprig |v2.22.0+incompatible |go-module| |github.com/NaverCloudPlatform/ncloud-sdk-go-v2 |v1.1.7 |go-module| |github.com/ProtonMail/go-crypto |v0.0.0-20210428141323-04723f9f07d7 |go-module| |github.com/PuerkitoBio/purell |v1.1.1 |go-module| |github.com/PuerkitoBio/urlesc |v0.0.0-20170810143723-de5bf2ad4578 |go-module| |github.com/Telmate/proxmox-api-go |v0.0.0-20220107223401-b9c909d83a3b |go-module| |github.com/agext/levenshtein |v1.2.3 |go-module| |github.com/aliyun/alibaba-cloud-sdk-go |v1.61.1028 |go-module| |github.com/aliyun/aliyun-oss-go-sdk |v2.1.8+incompatible |go-module| |github.com/antihax/optional |v1.0.0 |go-module| |github.com/apache/cloudstack-go/v2 |v2.12.0 |go-module| |github.com/apparentlymart/go-cidr |v1.0.1 |go-module| |github.com/apparentlymart/go-textseg/v13 |v13.0.0 |go-module| |github.com/armon/go-metrics |v0.3.9 |go-module| |github.com/armon/go-radix |v1.0.0 |go-module| |github.com/asaskevich/govalidator |v0.0.0-20200907205600-7a23bdc65eef |go-module| |github.com/aws/aws-sdk-go |v1.42.29 |go-module| |github.com/bgentry/go-netrc |v0.0.0-20140422174119-9fd32a8b3d3d |go-module| |github.com/bgentry/speakeasy |v0.1.0 |go-module| |github.com/biogo/hts |v1.4.3 |go-module| |github.com/blang/semver |v3.5.1+incompatible |go-module| |github.com/bmatcuk/doublestar |v1.1.5 |go-module| |github.com/c2h5oh/datasize |v0.0.0-20200825124411-48ed595a09d2 |go-module| |github.com/cenkalti/backoff/v3 |v3.2.2 |go-module| |github.com/cheggaaa/pb |v1.0.27 |go-module| |github.com/chzyer/readline |v0.0.0-20180603132655-2972be24d48e |go-module| |github.com/containerd/continuity |v0.0.0-20200413184840-d3ef23f19fbb |go-module| |github.com/davecgh/go-spew |v1.1.1 |go-module| |github.com/digitalocean/doctl |(devel) |go-module| |github.com/digitalocean/go-libvirt |v0.0.0-20201209184759-e2a69bcd5bd1 |go-module| |github.com/digitalocean/go-qemu |v0.0.0-20210326154740-ac9e0b687001 |go-module| |github.com/digitalocean/godo |v1.65.0 |go-module| |github.com/digitalocean/godo |v1.69.0 |go-module| |github.com/dimchansky/utfbom |v1.1.1 |go-module| |github.com/docker/cli |v0.0.0-20200622130859-87db43814b48 |go-module| |github.com/docker/docker |v17.12.0-ce-rc1.0.20200531234253-77e06fda0c94+incompatible|go-module| |github.com/docker/docker-credential-helpers |v0.6.3 |go-module| |github.com/docker/go-units |v0.4.0 |go-module| |github.com/dsnet/compress |v0.0.1 |go-module| |github.com/dustin/go-humanize |v1.0.0 |go-module| |github.com/dylanmei/iso8601 |v0.1.0 |go-module| |github.com/emirpasic/gods |v1.12.0 |go-module| |github.com/fatih/color |v1.12.0 |go-module| |github.com/fsnotify/fsnotify |v1.4.9 |go-module| |github.com/ghodss/yaml |v1.0.0 |go-module| |github.com/go-git/gcfg |v1.5.0 |go-module| |github.com/go-git/go-billy/v5 |v5.3.1 |go-module| |github.com/go-git/go-git/v5 |v5.4.2 |go-module| |github.com/go-logr/logr |v0.2.0 |go-module| |github.com/go-openapi/analysis |v0.20.0 |go-module| |github.com/go-openapi/errors |v0.19.9 |go-module| |github.com/go-openapi/jsonpointer |v0.19.5 |go-module| |github.com/go-openapi/jsonreference |v0.19.5 |go-module| |github.com/go-openapi/loads |v0.20.2 |go-module| |github.com/go-openapi/runtime |v0.19.24 |go-module| |github.com/go-openapi/spec |v0.20.3 |go-module| |github.com/go-openapi/strfmt |v0.20.0 |go-module| |github.com/go-openapi/swag |v0.19.14 |go-module| |github.com/go-openapi/validate |v0.20.2 |go-module| |github.com/go-ozzo/ozzo-validation |v3.6.0+incompatible |go-module| |github.com/go-resty/resty/v2 |v2.6.0 |go-module| |github.com/go-stack/stack |v1.8.0 |go-module| |github.com/gobwas/glob |v0.2.3 |go-module| |github.com/gofrs/flock |v0.8.1 |go-module| |github.com/gofrs/uuid |v4.0.0+incompatible |go-module| |github.com/gogo/protobuf |v1.3.2 |go-module| |github.com/golang-collections/collections |v0.0.0-20130729185459-604e922904d3 |go-module| |github.com/golang-jwt/jwt |v3.2.2+incompatible |go-module| |github.com/golang-jwt/jwt/v4 |v4.2.0 |go-module| |github.com/golang/groupcache |v0.0.0-20210331224755-41bb18bfe9da |go-module| |github.com/golang/mock |v1.6.0 |go-module| |github.com/golang/protobuf |v1.5.2 |go-module| |github.com/golang/snappy |v0.0.4 |go-module| |github.com/google/go-cmp |v0.5.6 |go-module| |github.com/google/go-github/v33 |v33.0.1-0.20210113204525-9318e629ec69 |go-module| |github.com/google/go-querystring |v1.1.0 |go-module| |github.com/google/gofuzz |v1.1.0 |go-module| |github.com/google/shlex |v0.0.0-20191202100458-e7afc7fbc510 |go-module| |github.com/google/uuid |v1.1.2 |go-module| |github.com/google/uuid |v1.3.0 |go-module| |github.com/googleapis/gax-go/v2 |v2.1.1 |go-module| |github.com/gophercloud/gophercloud |v0.12.0 |go-module| |github.com/gophercloud/utils |v0.0.0-20200508015959-b0167b94122c |go-module| |github.com/gorilla/websocket |v1.4.2 |go-module| |github.com/grpc-ecosystem/go-grpc-middleware |v1.2.2 |go-module| |github.com/hako/durafmt |v0.0.0-20200710122514-c0fb7b4da026 |go-module| |github.com/hashicorp/aws-sdk-go-base |v0.7.1 |go-module| |github.com/hashicorp/consul/api |v1.10.1 |go-module| |github.com/hashicorp/errwrap |v1.1.0 |go-module| |github.com/hashicorp/go-azure-helpers |v0.16.5 |go-module| |github.com/hashicorp/go-checkpoint |v0.0.0-20171009173528-1545e56e46de |go-module| |github.com/hashicorp/go-cleanhttp |v0.5.2 |go-module| |github.com/hashicorp/go-cty-funcs |v0.0.0-20200930094925-2721b1e36840 |go-module| |github.com/hashicorp/go-getter/gcs/v2 |v2.0.0-20200604122502-a6995fa1edad |go-module| |github.com/hashicorp/go-getter/s3/v2 |v2.0.0-20200604122502-a6995fa1edad |go-module| |github.com/hashicorp/go-getter/v2 |v2.0.2 |go-module| |github.com/hashicorp/go-hclog |v0.16.2 |go-module| |github.com/hashicorp/go-immutable-radix |v1.3.1 |go-module| |github.com/hashicorp/go-multierror |v1.1.1 |go-module| |github.com/hashicorp/go-oracle-terraform |v0.17.0 |go-module| |github.com/hashicorp/go-retryablehttp |v0.7.0 |go-module| |github.com/hashicorp/go-rootcerts |v1.0.2 |go-module| |github.com/hashicorp/go-safetemp |v1.0.0 |go-module| |github.com/hashicorp/go-sockaddr |v1.0.2 |go-module| |github.com/hashicorp/go-uuid |v1.0.2 |go-module| |github.com/hashicorp/go-version |v1.4.0 |go-module| |github.com/hashicorp/golang-lru |v0.5.4 |go-module| |github.com/hashicorp/hcl |v1.0.0 |go-module| |github.com/hashicorp/hcl/v2 |v2.12.0 |go-module| |github.com/hashicorp/hcp-sdk-go |v0.19.0 |go-module| |github.com/hashicorp/packer |(devel) |go-module| |github.com/hashicorp/packer-plugin-alicloud |v1.0.2 |go-module| |github.com/hashicorp/packer-plugin-amazon |v1.1.0 |go-module| |github.com/hashicorp/packer-plugin-ansible |v1.0.2 |go-module| |github.com/hashicorp/packer-plugin-azure |v1.0.8 |go-module| |github.com/hashicorp/packer-plugin-chef |v1.0.2 |go-module| |github.com/hashicorp/packer-plugin-cloudstack |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-converge |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-digitalocean |v1.0.6 |go-module| |github.com/hashicorp/packer-plugin-docker |v1.0.5 |go-module| |github.com/hashicorp/packer-plugin-googlecompute |v1.0.13 |go-module| |github.com/hashicorp/packer-plugin-hcloud |v1.0.4 |go-module| |github.com/hashicorp/packer-plugin-hyperone |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-hyperv |v1.0.3 |go-module| |github.com/hashicorp/packer-plugin-inspec |v1.0.0 |go-module| |github.com/hashicorp/packer-plugin-jdcloud |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-linode |v1.0.3 |go-module| |github.com/hashicorp/packer-plugin-lxc |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-lxd |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-ncloud |v1.0.3 |go-module| |github.com/hashicorp/packer-plugin-oneandone |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-openstack |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-oracle |v1.0.2 |go-module| |github.com/hashicorp/packer-plugin-outscale |v1.0.2 |go-module| |github.com/hashicorp/packer-plugin-parallels |v1.0.2 |go-module| |github.com/hashicorp/packer-plugin-profitbricks |v1.0.2 |go-module| |github.com/hashicorp/packer-plugin-proxmox |v1.0.7 |go-module| |github.com/hashicorp/packer-plugin-puppet |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-qemu |v1.0.4 |go-module| |github.com/hashicorp/packer-plugin-salt |v1.0.0 |go-module| |github.com/hashicorp/packer-plugin-sdk |v0.2.13 |go-module| |github.com/hashicorp/packer-plugin-tencentcloud |v1.0.5 |go-module| |github.com/hashicorp/packer-plugin-triton |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-ucloud |v1.0.1 |go-module| |github.com/hashicorp/packer-plugin-vagrant |v1.0.2 |go-module| |github.com/hashicorp/packer-plugin-virtualbox |v1.0.3 |go-module| |github.com/hashicorp/packer-plugin-vmware |v1.0.6 |go-module| |github.com/hashicorp/packer-plugin-vsphere |v1.0.4 |go-module| |github.com/hashicorp/packer-plugin-yandex |v1.1.1 |go-module| |github.com/hashicorp/serf |v0.9.5 |go-module| |github.com/hashicorp/vault/api |v1.1.1 |go-module| |github.com/hashicorp/vault/sdk |v0.2.1 |go-module| |github.com/hashicorp/yamux |v0.0.0-20210826001029-26ff87cf9493 |go-module| |github.com/hetznercloud/hcloud-go |v1.25.0 |go-module| |github.com/huandu/xstrings |v1.3.2 |go-module| |github.com/hyperonecom/h1-client-go |v0.0.0-20191203060043-b46280e4c4a4 |go-module| |github.com/imdario/mergo |v0.3.12 |go-module| |github.com/imdario/mergo |v0.3.6 |go-module| |github.com/jbenet/go-context |v0.0.0-20150711004518-d14ea06fba99 |go-module| |github.com/jdcloud-api/jdcloud-sdk-go |v1.9.1-0.20190605102154-3d81a50ca961 |go-module| |github.com/jehiah/go-strftime |v0.0.0-20171201141054-1d33003b3869 |go-module| |github.com/jmespath/go-jmespath |v0.4.0 |go-module| |github.com/josharian/intern |v1.0.0 |go-module| |github.com/joyent/triton-go |v1.8.5 |go-module| |github.com/json-iterator/go |v1.1.10 |go-module| |github.com/json-iterator/go |v1.1.11 |go-module| |github.com/kevinburke/ssh_config |v0.0.0-20201106050909-4977a11b4351 |go-module| |github.com/klauspost/compress |v1.13.5 |go-module| |github.com/klauspost/pgzip |v1.2.5 |go-module| |github.com/kr/fs |v0.1.0 |go-module| |github.com/linode/linodego |v0.30.0 |go-module| |github.com/magiconair/properties |v1.8.5 |go-module| |github.com/mailru/easyjson |v0.7.6 |go-module| |github.com/masterzen/simplexml |v0.0.0-20190410153822-31eea3082786 |go-module| |github.com/masterzen/winrm |v0.0.0-20210623064412-3b76017826b0 |go-module| |github.com/mattn/go-colorable |v0.1.8 |go-module| |github.com/mattn/go-isatty |v0.0.13 |go-module| |github.com/mattn/go-runewidth |v0.0.13 |go-module| |github.com/mattn/go-tty |v0.0.0-20191112051231-74040eebce08 |go-module| |github.com/mitchellh/cli |v1.1.2 |go-module| |github.com/mitchellh/copystructure |v1.2.0 |go-module| |github.com/mitchellh/go-fs |v0.0.0-20180402235330-b7b9ca407fff |go-module| |github.com/mitchellh/go-homedir |v1.1.0 |go-module| |github.com/mitchellh/go-testing-interface |v1.14.1 |go-module| |github.com/mitchellh/go-vnc |v0.0.0-20150629162542-723ed9867aed |go-module| |github.com/mitchellh/go-wordwrap |v1.0.1 |go-module| |github.com/mitchellh/iochan |v1.0.0 |go-module| |github.com/mitchellh/mapstructure |v1.4.1 |go-module| |github.com/mitchellh/panicwrap |v1.0.0 |go-module| |github.com/mitchellh/prefixedio |v0.0.0-20151214002211-6e6954073784 |go-module| |github.com/mitchellh/reflectwalk |v1.0.2 |go-module| |github.com/modern-go/concurrent |v0.0.0-20180306012644-bacd9c7ef1dd |go-module| |github.com/modern-go/reflect2 |v1.0.1 |go-module| |github.com/natefinch/pie |v0.0.0-20170715172608-9a0d72014007 |go-module| |github.com/nu7hatch/gouuid |v0.0.0-20131221200532-179d4d0c4d8d |go-module| |github.com/olekukonko/tablewriter |v0.0.5 |go-module| |github.com/opencontainers/go-digest |v1.0.0-rc1 |go-module| |github.com/opencontainers/image-spec |v1.0.1 |go-module| |github.com/opencontainers/runc |v1.0.0-rc95 |go-module| |github.com/oracle/oci-go-sdk/v36 |v36.2.0 |go-module| |github.com/outscale/osc-sdk-go |v1.11.2 |go-module| |github.com/packer-community/winrmcp |v0.0.0-20180921211025-c76d91c1e7db |go-module| |github.com/pelletier/go-toml |v1.9.3 |go-module| |github.com/pierrec/lz4 |v2.6.1+incompatible |go-module| |github.com/pkg/errors |v0.9.1 |go-module| |github.com/pkg/sftp |v1.13.2 |go-module| |github.com/posener/complete |v1.2.3 |go-module| |github.com/profitbricks/profitbricks-sdk-go |v4.0.2+incompatible |go-module| |github.com/rivo/uniseg |v0.2.0 |go-module| |github.com/ryanuber/go-glob |v1.0.0 |go-module| |github.com/scaleway/packer-plugin-scaleway |v1.0.4 |go-module| |github.com/scaleway/scaleway-sdk-go |v1.0.0-beta.7 |go-module| |github.com/sergi/go-diff |v1.1.0 |go-module| |github.com/shiena/ansicolor |v0.0.0-20151119151921-a422bbe96644 |go-module| |github.com/shirou/gopsutil |v3.21.11+incompatible |go-module| |github.com/sirupsen/logrus |v1.4.2 |go-module| |github.com/sirupsen/logrus |v1.7.0 |go-module| |github.com/spf13/afero |v1.6.0 |go-module| |github.com/spf13/cast |v1.4.0 |go-module| |github.com/spf13/cobra |v1.2.1 |go-module| |github.com/spf13/jwalterweatherman |v1.1.0 |go-module| |github.com/spf13/pflag |v1.0.5 |go-module| |github.com/spf13/viper |v1.8.1 |go-module| |github.com/subosito/gotenv |v1.2.0 |go-module| |github.com/tencentcloud/tencentcloud-sdk-go/tencentcloud/common|v1.0.367 |go-module| |github.com/tencentcloud/tencentcloud-sdk-go/tencentcloud/cvm |v1.0.366 |go-module| |github.com/tencentcloud/tencentcloud-sdk-go/tencentcloud/vpc |v1.0.366 |go-module| |github.com/tklauser/go-sysconf |v0.3.9 |go-module| |github.com/tklauser/numcpus |v0.4.0 |go-module| |github.com/ucloud/ucloud-sdk-go |v0.20.2 |go-module| |github.com/ufilesdk-dev/ufile-gosdk |v1.0.1 |go-module| |github.com/ugorji/go/codec |v1.2.6 |go-module| |github.com/ulikunitz/xz |v0.5.10 |go-module| |github.com/vmware/govmomi |v0.26.0 |go-module| |github.com/xanzy/ssh-agent |v0.3.0 |go-module| |github.com/yandex-cloud/go-genproto |v0.0.0-20211202135052-789603780fb2 |go-module| |github.com/yandex-cloud/go-sdk |v0.0.0-20211206101223-7c4e7926bf53 |go-module| |github.com/zclconf/go-cty |v1.10.0 |go-module| |github.com/zclconf/go-cty-yaml |v1.0.1 |go-module| |gnupg |2.2.19-3ubuntu2.2 |deb | |gnupg-l10n |2.2.19-3ubuntu2.2 |deb | |gnupg-utils |2.2.19-3ubuntu2.2 |deb | |go.mongodb.org/mongo-driver |v1.5.1 |go-module| |go.opencensus.io |v0.23.0 |go-module| |golang.org/x/crypto |v0.0.0-20201216223049-8b5274cf687f |go-module| |golang.org/x/crypto |v0.0.0-20220427172511-eb4f295cb31f |go-module| |golang.org/x/mobile |v0.0.0-20210901025245-1fde1d6c3ca1 |go-module| |golang.org/x/net |v0.0.0-20210929161516-d455829e376d |go-module| |golang.org/x/net |v0.0.0-20211216030914-fe4d6282115f |go-module| |golang.org/x/oauth2 |v0.0.0-20210819190943-2bc19b11175f |go-module| |golang.org/x/oauth2 |v0.0.0-20211005180243-6b3c2da341f1 |go-module| |golang.org/x/sync |v0.0.0-20210220032951-036812b2e83c |go-module| |golang.org/x/sys |v0.0.0-20210630005230-0f9fa26af87c |go-module| |golang.org/x/sys |v0.0.0-20220128215802-99c3d69c2c27 |go-module| |golang.org/x/term |v0.0.0-20201126162022-7de9c90e9dd1 |go-module| |golang.org/x/term |v0.0.0-20210615171337-6886f2dfbf5b |go-module| |golang.org/x/text |v0.3.6 |go-module| |golang.org/x/text |v0.3.7 |go-module| |golang.org/x/time |v0.0.0-20200630173020-3af7569d3a1e |go-module| |golang.org/x/time |v0.0.0-20210723032227-1f47c861a9ac |go-module| |golang.org/x/xerrors |v0.0.0-20200804184101-5ec99f83aff1 |go-module| |google.golang.org/api |v0.58.0 |go-module| |google.golang.org/genproto |v0.0.0-20211021150943-2b146023228c |go-module| |google.golang.org/grpc |v1.41.0 |go-module| |google.golang.org/protobuf |v1.27.1 |go-module| |gopkg.in/inf.v0 |v0.9.1 |go-module| |gopkg.in/ini.v1 |v1.62.0 |go-module| |gopkg.in/square/go-jose.v2 |v2.6.0 |go-module| |gopkg.in/warnings.v0 |v0.1.2 |go-module| |gopkg.in/yaml.v2 |v2.4.0 |go-module| |gpg |2.2.19-3ubuntu2.2 |deb | |gpg-agent |2.2.19-3ubuntu2.2 |deb | |gpg-wks-client |2.2.19-3ubuntu2.2 |deb | |gpg-wks-server |2.2.19-3ubuntu2.2 |deb | |gpgconf |2.2.19-3ubuntu2.2 |deb | |gpgsm |2.2.19-3ubuntu2.2 |deb | |gpgv |2.2.19-3ubuntu2.2 |deb | |grep |3.4-1 |deb | |gzip |1.10-0ubuntu4.1 |deb | |hostname |3.23 |deb | |idna |2.8 |python | |init-system-helpers |1.57 |deb | |io-console |0.5.3 |gem | |ipaddr |1.2.2 |gem | |iputils-ping |3:20190709-3ubuntu1 |deb | |irb |1.2.1 |gem | |javascript-common |11 |deb | |jq |1.6-1ubuntu0.20.04.1 |deb | |json |2.3.0 |gem | |k8s.io/api |v0.20.0 |go-module| |k8s.io/apimachinery |v0.20.0 |go-module| |k8s.io/client-go |v0.20.0 |go-module| |k8s.io/klog/v2 |v2.4.0 |go-module| |k8s.io/utils |v0.0.0-20201110183641-67b214c5f920 |go-module| |krb5-locales |1.17-6ubuntu4.4 |deb | |less |551-1ubuntu0.3 |deb | |libacl1 |2.2.53-6 |deb | |libalgorithm-diff-perl |1.19.03-2 |deb | |libalgorithm-diff-xs-perl |0.04-6 |deb | |libalgorithm-merge-perl |0.08-3 |deb | |libapparmor1 |2.13.3-7ubuntu5.3 |deb | |libapt-pkg6.0 |2.0.10 |deb | |libargon2-1 |0~20171227-0.2 |deb | |libasan5 |9.4.0-1ubuntu1~20.04.2 |deb | |libasn1-8-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |libassuan0 |2.5.3-7ubuntu2 |deb | |libatomic1 |10.5.0-1ubuntu1~20.04 |deb | |libattr1 |1:2.4.48-5 |deb | |libaudit-common |1:2.8.5-2ubuntu6 |deb | |libaudit1 |1:2.8.5-2ubuntu6 |deb | |libbinutils |2.34-6ubuntu1.9 |deb | |libblkid1 |2.34-0.1ubuntu9.4 |deb | |libbrotli1 |1.0.7-6ubuntu0.1 |deb | |libbsd0 |0.10.0-1 |deb | |libbz2-1.0 |1.0.8-2 |deb | |libc-bin |2.31-0ubuntu9.14 |deb | |libc-dev-bin |2.31-0ubuntu9.16 |deb | |libc6 |2.31-0ubuntu9.16 |deb | |libc6-dev |2.31-0ubuntu9.16 |deb | |libcap-ng0 |0.7.9-2.1build1 |deb | |libcap2 |1:2.32-1ubuntu0.1 |deb | |libcap2-bin |1:2.32-1ubuntu0.1 |deb | |libcbor0.6 |0.6.0-0ubuntu1 |deb | |libcc1-0 |10.5.0-1ubuntu1~20.04 |deb | |libcom-err2 |1.45.5-2ubuntu1.1 |deb | |libcrypt-dev |1:4.4.10-10ubuntu4 |deb | |libcrypt1 |1:4.4.10-10ubuntu4 |deb | |libcryptsetup12 |2:2.2.2-3ubuntu2.4 |deb | |libctf-nobfd0 |2.34-6ubuntu1.9 |deb | |libctf0 |2.34-6ubuntu1.9 |deb | |libcurl3-gnutls |7.68.0-1ubuntu2.22 |deb | |libcurl4 |7.68.0-1ubuntu2.22 |deb | |libdb5.3 |5.3.28+dfsg1-0.6ubuntu2 |deb | |libdbus-1-3 |1.12.16-2ubuntu2.3 |deb | |libdebconfclient0 |0.251ubuntu1 |deb | |libdevmapper1.02.1 |2:1.02.167-1ubuntu1 |deb | |libdpkg-perl |1.19.7ubuntu3.2 |deb | |libedit2 |3.1-20191231-1 |deb | |liberror-perl |0.17029-1 |deb | |libexpat1 |2.2.9-1ubuntu0.6 |deb | |libexpat1-dev |2.2.9-1ubuntu0.6 |deb | |libext2fs2 |1.45.5-2ubuntu1.1 |deb | |libfakeroot |1.24-1 |deb | |libfdisk1 |2.34-0.1ubuntu9.4 |deb | |libffi7 |3.3-4 |deb | |libfido2-1 |1.3.1-1ubuntu2 |deb | |libfile-fcntllock-perl |0.22-3build4 |deb | |libgcc-9-dev |9.4.0-1ubuntu1~20.04.2 |deb | |libgcc-s1 |10.5.0-1ubuntu1~20.04 |deb | |libgcrypt20 |1.8.5-5ubuntu1.1 |deb | |libgdbm-compat4 |1.18.1-5 |deb | |libgdbm6 |1.18.1-5 |deb | |libgirepository-1.0-1 |1.64.1-1~ubuntu20.04.1 |deb | |libglib2.0-0 |2.64.6-1~ubuntu20.04.7 |deb | |libglib2.0-data |2.64.6-1~ubuntu20.04.7 |deb | |libgmp10 |2:6.2.0+dfsg-4ubuntu0.1 |deb | |libgnutls30 |3.6.13-2ubuntu1.10 |deb | |libgomp1 |10.5.0-1ubuntu1~20.04 |deb | |libgpg-error0 |1.37-1 |deb | |libgssapi-krb5-2 |1.17-6ubuntu4.4 |deb | |libgssapi3-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |libhcrypto4-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |libheimbase1-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |libheimntlm0-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |libhogweed5 |3.5.1+really3.5.1-2ubuntu0.2 |deb | |libhx509-5-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |libicu66 |66.1-2ubuntu2.1 |deb | |libidn2-0 |2.2.0-2 |deb | |libip4tc2 |1.8.4-3ubuntu2.1 |deb | |libisl22 |0.22.1-1 |deb | |libitm1 |10.5.0-1ubuntu1~20.04 |deb | |libjansson4 |2.12-1build1 |deb | |libjq1 |1.6-1ubuntu0.20.04.1 |deb | |libjs-jquery |3.3.1~dfsg-3 |deb | |libjson-c4 |0.13.1+dfsg-7ubuntu0.3 |deb | |libk5crypto3 |1.17-6ubuntu4.4 |deb | |libkeyutils1 |1.6-6ubuntu1.1 |deb | |libkmod2 |27-1ubuntu2.1 |deb | |libkrb5-26-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |libkrb5-3 |1.17-6ubuntu4.4 |deb | |libkrb5support0 |1.17-6ubuntu4.4 |deb | |libksba8 |1.3.5-2ubuntu0.20.04.2 |deb | |libldap-2.4-2 |2.4.49+dfsg-2ubuntu1.10 |deb | |libldap-common |2.4.49+dfsg-2ubuntu1.10 |deb | |liblocale-gettext-perl |1.07-4 |deb | |liblsan0 |10.5.0-1ubuntu1~20.04 |deb | |liblz4-1 |1.9.2-2ubuntu0.20.04.1 |deb | |liblzma5 |5.2.4-1ubuntu1.1 |deb | |libmagic-mgc |1:5.38-4 |deb | |libmagic1 |1:5.38-4 |deb | |libmnl0 |1.0.4-2 |deb | |libmount1 |2.34-0.1ubuntu9.4 |deb | |libmpc3 |1.1.0-1 |deb | |libmpdec2 |2.4.2-3 |deb | |libmpfr6 |4.0.2-1 |deb | |libncurses6 |6.2-0ubuntu2.1 |deb | |libncursesw6 |6.2-0ubuntu2.1 |deb | |libnettle7 |3.5.1+really3.5.1-2ubuntu0.2 |deb | |libnftables1 |0.9.3-2 |deb | |libnftnl11 |1.1.5-1 |deb | |libnghttp2-14 |1.40.0-1ubuntu0.3 |deb | |libnpth0 |1.6-1 |deb | |libnss-systemd |245.4-4ubuntu3.23 |deb | |libonig5 |6.9.4-1 |deb | |libp11-kit0 |0.23.20-1ubuntu0.1 |deb | |libpam-cap |1:2.32-1ubuntu0.1 |deb | |libpam-modules |1.3.1-5ubuntu4.7 |deb | |libpam-modules-bin |1.3.1-5ubuntu4.7 |deb | |libpam-runtime |1.3.1-5ubuntu4.7 |deb | |libpam-systemd |245.4-4ubuntu3.23 |deb | |libpam0g |1.3.1-5ubuntu4.7 |deb | |libpcre2-8-0 |10.34-7ubuntu0.1 |deb | |libpcre3 |2:8.39-12ubuntu0.1 |deb | |libperl5.30 |5.30.0-9ubuntu0.5 |deb | |libpopt0 |1.16-14 |deb | |libprocps8 |2:3.3.16-1ubuntu2.4 |deb | |libpsl5 |0.21.0-1ubuntu1 |deb | |libpython3-dev |3.8.2-0ubuntu2 |deb | |libpython3-stdlib |3.8.2-0ubuntu2 |deb | |libpython3.8 |3.8.10-0ubuntu1~20.04.11 |deb | |libpython3.8-dev |3.8.10-0ubuntu1~20.04.11 |deb | |libpython3.8-minimal |3.8.10-0ubuntu1~20.04.11 |deb | |libpython3.8-stdlib |3.8.10-0ubuntu1~20.04.11 |deb | |libquadmath0 |10.5.0-1ubuntu1~20.04 |deb | |libreadline8 |8.0-4 |deb | |libroken18-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |librtmp1 |2.4+20151223.gitfa8646d.1-2build1 |deb | |libruby2.7 |2.7.0-5ubuntu1.14 |deb | |libsasl2-2 |2.1.27+dfsg-2ubuntu0.1 |deb | |libsasl2-modules |2.1.27+dfsg-2ubuntu0.1 |deb | |libsasl2-modules-db |2.1.27+dfsg-2ubuntu0.1 |deb | |libseccomp2 |2.5.1-1ubuntu1~20.04.2 |deb | |libselinux1 |3.0-1build2 |deb | |libsemanage-common |3.0-1build2 |deb | |libsemanage1 |3.0-1build2 |deb | |libsepol1 |3.0-1ubuntu0.1 |deb | |libsmartcols1 |2.34-0.1ubuntu9.4 |deb | |libsqlite3-0 |3.31.1-4ubuntu0.6 |deb | |libss2 |1.45.5-2ubuntu1.1 |deb | |libssh-4 |0.9.3-2ubuntu2.5 |deb | |libssl1.1 |1.1.1f-1ubuntu2.23 |deb | |libstdc++-9-dev |9.4.0-1ubuntu1~20.04.2 |deb | |libstdc++6 |10.5.0-1ubuntu1~20.04 |deb | |libsystemd0 |245.4-4ubuntu3.23 |deb | |libtasn1-6 |4.16.0-2 |deb | |libtinfo6 |6.2-0ubuntu2.1 |deb | |libtsan0 |10.5.0-1ubuntu1~20.04 |deb | |libubsan1 |10.5.0-1ubuntu1~20.04 |deb | |libudev1 |245.4-4ubuntu3.23 |deb | |libunistring2 |0.9.10-2 |deb | |libuuid1 |2.34-0.1ubuntu9.4 |deb | |libwind0-heimdal |7.7.0+dfsg-1ubuntu1.4 |deb | |libwrap0 |7.6.q-30 |deb | |libx11-6 |2:1.6.9-2ubuntu1.6 |deb | |libx11-data |2:1.6.9-2ubuntu1.6 |deb | |libxau6 |1:1.0.9-0ubuntu1 |deb | |libxcb1 |1.14-2 |deb | |libxdmcp6 |1:1.1.3-0ubuntu1 |deb | |libxext6 |2:1.3.4-0ubuntu1 |deb | |libxml2 |2.9.10+dfsg-5ubuntu0.20.04.7 |deb | |libxmuu1 |2:1.1.3-0ubuntu1 |deb | |libxslt1.1 |1.1.34-4ubuntu0.20.04.1 |deb | |libxtables12 |1.8.4-3ubuntu2.1 |deb | |libyaml-0-2 |0.2.2-1 |deb | |libzstd1 |1.4.4+dfsg-3ubuntu0.1 |deb | |linux-libc-dev |5.4.0-190.210 |deb | |logger |1.4.2 |gem | |login |1:4.8.1-1ubuntu5.20.04.4 |deb | |logsave |1.45.5-2ubuntu1.1 |deb | |lsb-base |11.1.0ubuntu2 |deb | |lsb-release |11.1.0ubuntu2 |deb | |make |4.2.1-1.2 |deb | |manpages |5.05-1 |deb | |manpages-dev |5.05-1 |deb | |matrix |0.2.0 |gem | |mawk |1.3.4.20200120-2 |deb | |mime-support |3.64ubuntu1 |deb | |minitest |5.13.0 |gem | |mount |2.34-0.1ubuntu9.4 |deb | |mutex_m |0.1.0 |gem | |nano |4.8-1ubuntu1 |deb | |ncurses-base |6.2-0ubuntu2.1 |deb | |ncurses-bin |6.2-0ubuntu2.1 |deb | |ncurses-term |6.2-0ubuntu2.1 |deb | |net-pop |0.1.0 |gem | |net-smtp |0.1.0 |gem | |net-telnet |0.1.1 |gem | |net-tools |1.60+git20180626.aebd88e-1ubuntu1 |deb | |netbase |6.1 |deb | |networkd-dispatcher |2.1-2~ubuntu20.04.3 |deb | |nftables |0.9.3-2 |deb | |observer |0.1.0 |gem | |open3 |0.1.0 |gem | |openssh-client |1:8.2p1-4ubuntu0.11 |deb | |openssh-server |1:8.2p1-4ubuntu0.11 |deb | |openssh-sftp-server |1:8.2p1-4ubuntu0.11 |deb | |openssl |1.1.1f-1ubuntu2.23 |deb | |openssl |2.1.2 |gem | |ostruct |0.2.0 |gem | |passwd |1:4.8.1-1ubuntu5.20.04.4 |deb | |patch |2.7.6-6 |deb | |perl |5.30.0-9ubuntu0.5 |deb | |perl-base |5.30.0-9ubuntu0.5 |deb | |perl-modules-5.30 |5.30.0-9ubuntu0.5 |deb | |pinentry-curses |1.1.0-3build1 |deb | |pip |20.0.2 |python | |power_assert |1.1.7 |gem | |prime |0.1.1 |gem | |procps |2:3.3.16-1ubuntu2.4 |deb | |pstore |0.1.0 |gem | |psych |3.1.0 |gem | |publicsuffix |20200303.0012-1 |deb | |pyinotify |0.9.6 |python | |python-pip-whl |20.0.2-5ubuntu1.10 |deb | |python3 |3.8.2-0ubuntu2 |deb | |python3-certifi |2019.11.28-1 |deb | |python3-chardet |3.0.4-4build1 |deb | |python3-dbus |1.2.16-1build1 |deb | |python3-dev |3.8.2-0ubuntu2 |deb | |python3-distro |1.4.0-1 |deb | |python3-distutils |3.8.10-0ubuntu1~20.04 |deb | |python3-gi |3.36.0-1 |deb | |python3-idna |2.8-1ubuntu0.1 |deb | |python3-lib2to3 |3.8.10-0ubuntu1~20.04 |deb | |python3-minimal |3.8.2-0ubuntu2 |deb | |python3-pip |20.0.2-5ubuntu1.10 |deb | |python3-pkg-resources |45.2.0-1ubuntu0.1 |deb | |python3-pyinotify |0.9.6-1.2ubuntu1 |deb | |python3-requests |2.22.0-2ubuntu1.1 |deb | |python3-setuptools |45.2.0-1ubuntu0.1 |deb | |python3-six |1.14.0-2 |deb | |python3-systemd |234-3build2 |deb | |python3-urllib3 |1.25.8-2ubuntu0.3 |deb | |python3-wheel |0.34.2-1ubuntu0.1 |deb | |python3.8 |3.8.10-0ubuntu1~20.04.11 |deb | |python3.8-dev |3.8.10-0ubuntu1~20.04.11 |deb | |python3.8-minimal |3.8.10-0ubuntu1~20.04.11 |deb | |racc |1.4.16 |gem | |rake |13.0.1 |gem | |rake |13.0.1-4 |deb | |rdoc |6.2.1 |gem | |readline |0.0.2 |gem | |readline-common |8.0-4 |deb | |readline-ext |0.1.0 |gem | |reline |0.1.2 |gem | |requests |2.22.0 |python | |rexml |3.2.3 |gem | |rss |0.2.8 |gem | |rsync |3.1.3-8ubuntu0.7 |deb | |ruby |1:2.7+1 |deb | |ruby-minitest |5.13.0-1 |deb | |ruby-net-telnet |0.1.1-2 |deb | |ruby-power-assert |1.1.7-1 |deb | |ruby-test-unit |3.3.5-1 |deb | |ruby-xmlrpc |0.3.0-2 |deb | |ruby2.7 |2.7.0-5ubuntu1.14 |deb | |rubygems-integration |1.16 |deb | |sdbm |1.0.0 |gem | |sed |4.7-1 |deb | |sensible-utils |0.0.12+nmu1 |deb | |setuptools |45.2.0 |python | |shared-mime-info |1.15-1 |deb | |sigs.k8s.io/structured-merge-diff/v4 |v4.0.2 |go-module| |sigs.k8s.io/yaml |v1.2.0 |go-module| |singleton |0.1.0 |gem | |six |1.14.0 |python | |ssh-import-id |5.10 |python | |ssh-import-id |5.10-0ubuntu1 |deb | |stringio |0.1.0 |gem | |strscan |1.0.3 |gem | |sudo |1.8.31-1ubuntu1.5 |deb | |systemd |245.4-4ubuntu3.23 |deb | |systemd-python |234 |python | |systemd-sysv |245.4-4ubuntu3.23 |deb | |systemd-timesyncd |245.4-4ubuntu3.23 |deb | |sysvinit-utils |2.96-2.1ubuntu1 |deb | |tar |1.30+dfsg-7ubuntu0.20.04.4 |deb | |test-unit |3.3.5 |gem | |timeout |0.1.0 |gem | |tracer |0.1.0 |gem | |tzdata |2024a-0ubuntu0.20.04.1 |deb | |ubuntu-keyring |2020.02.11.4 |deb | |ucf |3.0038+nmu1 |deb | |unzip |6.0-25ubuntu1.2 |deb | |uri |0.10.0 |gem | |urllib3 |1.25.8 |python | |util-linux |2.34-0.1ubuntu9.4 |deb | |webrick |1.6.0 |gem | |wget |1.20.3-1ubuntu2.1 |deb | |wheel |0.34.2 |python | |whois |5.5.6 |deb | |xauth |1:1.1-0ubuntu1 |deb | |xdg-user-dirs |0.17-2ubuntu1 |deb | |xmlrpc |0.3.0 |gem | |xsltproc |1.1.34-4ubuntu0.20.04.1 |deb | |xz-utils |5.2.4-1ubuntu1.1 |deb | |yaml |0.1.0 |gem | |zip |3.0-11build1 |deb | |zlib |1.1.0 |gem | |zlib1g |1:1.2.11.dfsg-2ubuntu1.5 |deb | |zlib1g-dev |1:1.2.11.dfsg-2ubuntu1.5 |deb | |zsh |5.8-3ubuntu1.1 |deb | |zsh-autosuggestions |0.6.4-1 |deb | |zsh-common |5.8-3ubuntu1.1 |deb | |zsh-syntax-highlighting |0.6.0-3 |deb | ``` {% endcode %}
This SBOM can be generated by installing the Ax Controller via docker, selecting omz as your shell and selecting yes when asked to install Golang (`--unattended` automatically installs Golang). ``` docker exec -it $(docker run -d -it --platform linux/amd64 ubuntu:20.04) sh -c "apt update && apt install git -y && git clone https://github.com/attacksurge/ax/ ~/.axiom/ && cd && .axiom/interact/axiom-configure --setup omz --unattended" ``` Then create an image from the running docker container and tag it. ``` docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 069b8a5ecae1 ubuntu:20.04 "/bin/bash" 17 minutes ago Up 17 minutes jovial_euclid docker commit 069b8a5ecae1 docker image tag 3c78f9bf86b5 ax:omz ``` Finally, install the docker sbom plugin and generate the sbom! ``` curl -sSfl https://raw.githubusercontent.com/docker/sbom-cli-plugin/main/install.sh -o install-docker-sbom.sh chmod +x install-docker-sbom.sh sudo ./install-docker-sbom.sh sudo docker sbom ax:omz ``` # How it Works Ax doesn't have any APIs; it's purely a command-line tool. Moreover, Ax doesn't even interact with any cloud provider's APIs directly. Instead, Ax wraps the cloud provider's CLI to perform cloud operations, simplifying the process. By wrapping the cloud provider's CLI, we eliminate the need to write API calls for each operation, abstracting some complexity. The cloud provider CLI functions are stored in [`~/.axiom/providers`](https://github.com/attacksurge/ax/tree/master/providers). ## Installation Flow {% hint style="info" %} **Quick Breakdown:** During the first time install, `ax configure` calls `ax account-setup`, then `ax account`and finally `ax build`. This installs all required dependencies, installs and authenticates the cloud providers CLI, and kicks off the Packer builder to create an image with your desired tools installed. {% endhint %} When you setup the Ax Controller on a [supported OS](/overview/installation-guide#supported-os), the required dependencies are first installed.

bash <(curl -s https://raw.githubusercontent.com/attacksurge/ax/master/interact/axiom-configure) --run

Then you pick what shell you'd like to use, either bash, zsh or oh my zsh

ax configure --run

You'll have an option to install Golang (not required).

ax configure --run

Then `ax configure` kicks off `ax account-setup,` where you decide what cloud provider to use.

ax account

When you select a cloud provider, `ax account-setup` calls the associated cloud provider's [account-helpers](https://github.com/attacksurge/ax/tree/main/interact/account-helpers) script. This script installs and setups the CLI and Ax account profile. After providing a valid authentication token, you select the region where you want to deploy, along with the desired instance size (CPU, RAM). Finally, you choose a name for the Ax account profile, which **stores your cloud account credentials** and other user profile information in `~/.axiom/accounts/$profile-name.json`.

ax provider

{% hint style="info" %} **Symbolic Links:** Ax supports multiple account user profiles. To list your current account user profiles, use [ax account](https://github.com/attacksurge/ax/blob/master/interact/axiom-account). To switch between different profiles, use ax account $profile. For example, running `ax account do` switches to my Digital Ocean user profile. **cloud credentials** and user profile data are stored in **`~/.axiom/accounts/$profile-name.json`**. A symbolic link to this file is created in **`~/.axiom/axiom.json`**. Another important aspect of [`ax account`](https://github.com/attacksurge/ax/blob/master/interact/axiom-account) is that it calls [`ax provider`](https://github.com/attacksurge/ax/blob/master/interact/axiom-provider). `ax provider` creates another symbolic link from the [cloud providers functions ](https://github.com/attacksurge/ax/tree/master/providers)in `~/.axiom/providers/$cloud-provider.sh` to `~/.axiom/interact/includes/functions.sh` This dynamic linking is how Ax remains flexible. When you switch accounts, the appropriate [cloud provider functions](https://github.com/attacksurge/ax/tree/master/providers) and [user profile](https://github.com/attacksurge/ax/blob/master/accounts/do.json.example) are essentially sourced. {% endhint %} ax account-setup then calls ax build. ax build creates the Packer image based on the Provisioner file chosen. After choosing your Provisioner, Packer creates a temporary cloud instance, installs all the tools found in the Provisioner file, takes a snapshot of the image and saves it. Then Packer deletes the temporary instance. {% hint style="info" %} `ax build` combines the cloud provider's Builder (either [JSON](https://github.com/attacksurge/ax/tree/master/images/json/builders) or [HCL](https://github.com/attacksurge/ax/tree/master/images/pkr.hcl/builders)) file with a Provisioner (also either [JSON](https://github.com/attacksurge/ax/tree/master/images/json/provisioners) or [HCL](https://github.com/attacksurge/ax/tree/master/images/pkr.hcl/provisioners)) file into the final Packer file, which is stored in `~/.axiom/images/$format/axiom.json` {% endhint %}

ax build barebones

{% hint style="info" %} **SSH Keys:** By default, ax creates a SSH key named axiom\_rsa in `~/.ssh/axiom_rsa`. The reference to the SSH key is stored in `~/.axiom/axiom.json`. You can change the`sshkey` value to another SSH key as long as its stored in `~/.ssh/`. You might need to rebuild (ax build) with your new SSH key to use it. {% endhint %} When the build completes you should see a success message like the one below. You might need to restart your shell.

ax build barebones

## Ax SSH Config Ax creates its own sshconfig located in `~/.axiom/.sshconfig` The sshconfig is how the Ax Controller communicates to the Ax instances (fleets). The sshconfig is generated based on your cloud inventory and allows you to connect to your Ax instances over their public or private network interface. Most Ax scripts generate a fresh SSH config before executing. You can always regenerate the sshconfig manually with `ax ssh --just-generate` or lock the sshconfig to prevent Ax from ever regenerating `ax ssh --just-generate lock`. To unlock the sshconfig run `ax ssh --just-generate` {% hint style="info" %} **Private Network Connectivity:** When creating the sshconfig from instances private IPs (ax ssh --just-generate private) you must be on the same private network as your cloud instances. {% endhint %} ## ax scan After you spin up some instances, you can run `ax scan` to perform a distributed scan using those instances (fleet). {% hint style="info" %} **ax scan:** for a detailed overview on ax scan, please visit {% endhint %}

ax fleet -i 5

The first argument passed to `ax scan` must always be an input file (bunch of IPs or URLs etc).\ `ax scan` takes a user provided input file and divides the input file by how many instances currently selected (`ax select`). In this case, we have a target list of five lines and five instances selected. So each instance will scan one target. You can also pass additional arguments to the underlying module by simply appending them to the command line. {% hint style="info" %} **Modules:** For a detailed overview on ax scan modules, please visit [/modules](/fundamentals/scans/modules) {% endhint %}

ax scan input -m dnsx -o dnsx-results --silent

`ax scan` begins by using SSH to create a scan working directory on the remote instances at `/home/op/scan/$module-$timestamp/`. You can see what `ax scan` uploads by using `ax ssh` to connect to any instance and navigating to the scan working directory on the remote instance. When an instance completes its operation, Ax creates a file named after the instance's hostname in the scan working directory on the remote instance. Ax continuously checks for these hostname files to determine the completion status of all instances. Once all instances have created their hostname files, or if Ax can no longer reach any of the instances, the scan is considered complete. Scan results are periodically downloaded throughout the process and once again when the scan finishes.

ax ssh

During the scan, you can view the results periodically downloaded to `~/axiom/tmp/$module+$timestamp/`. Once the scan is complete, the results from all scanners are merged and moved to `~/axiom/logs/$module+$timestamp/`. You can check which instances have completed their scans by navigating to the local temporary scan directory and displaying the contents of `status/completed/hosts`.

cat /home/user/.axiom/tmp/nmapx+172203724417078/status/completed/hosts

You can also monitor any instance in real-time by using `ax ssh` to connect and attach to the tmux session. A unique tmux session, named `$module+$timestamp`, is created on each remote instance to manage the scan.

tmux a -t $module+$timestamp

## More Info In summary, Ax simplifies the distribution of arbitrary binaries and scripts by configuring your cloud account CLI, building Packer images, and deploying fleets of new instances. It dynamically splits and uploads an input file to all selected instances, executing the same command across each one. Upon completing the scan, Ax downloads and merges the scan output. For more information, continue to [Ax Utility Scripts](/fundamentals/ax-utility-scripts) or [Scans](/fundamentals/scans)! # Quickstart Guide So, you have axiom installed, you're feeling pretty good about yourself, you're 10 minutes away from feeling the power of axiom! #### Ensure your build has occurred successfully If you've followed the installation steps with success, you should have run the [`axiom-configure`](https://github.com/pry0cc/axiom/wiki/A-Quickstart-Guide#axiom-configure) script at some point. axiom-configure automatically starts [`axiom-build`](https://github.com/pry0cc/axiom/wiki/A-Quickstart-Guide#axiom-build). During this time, [Packer by HashiCorp](https://www.packer.io/) will create an image. You should notice "Shutting down gracefully... Creating snapshot....". You should have a valid build in your account now, if, in doubt, you can run [`axiom-build`](https://github.com/pry0cc/axiom/wiki/A-Quickstart-Guide#axiom-build) and create a new base snapshot just in case! You can also manually edit your account details such as API key, image id, CPU, RAM etc, in the profile.json you just created `cat ~/.axiom/accounts/personal.json`. If you have a valid build in your account, skip to [`axiom-init`](https://github.com/pry0cc/axiom/wiki/A-Quickstart-Guide#axiom-init). ## ax configure **Setup and configure the axiom controller and validate cloud account** :computer:
ax configure ``` Description: Examples: axiom-configure --setup # kick off Ax configuration wizard axiom-configure --shell zsh # Set default shell to zsh via command line axiom-configure --config # Use personal.json from a file for account setup axiom-configure --config # Use personal.json data supplied by command-line for account setup (must be vaild personal.json data wrapped in single quotes) axiom-configure --shell bash --unattended --config # Use bash for default shell, do not promot, use personal.json data from file for axiom setup Usage: --setup (optional) Start axiom-configure wizard, install dependencies, kick off axiom-account-setup and axiom-build --config Setup account with data from file or supplied from the command line (must be vaild data from a personal.json axiom file) --unattended (optional) Avoid any promots, defaults to Oh My Zsh unless --shell argument is also provided --shell (optional) Add axiom to path, backup .zshrc/.bashrc to .zshrcbak/.bashrcbak --debug (optional) Enable debug mode (VERY VERBOSE!) --help Display this help menu ```
{% code fullWidth="false" %} ``` ax configure --setup ``` {% endcode %} You can provide your config file before or after running `axiom-configure`. `axiom-configure --setup --shell bash --unattended --config ~/.axiom/accounts/do.json` *** *** ## ax build **Pick a Packer provisioner** :hatching\_chick: > You must run axiom-configure before anything else. This creates your axiom.json file which is required by other commands. {% code fullWidth="false" %} ``` Description: axiom-build supports both legacy Packer JSON files as well as the new HCL format axiom-build combines a cloud provider's Builder (~/.axiom/images/$format/builders) with a Provisioner (~/.axiom/images/$format/provisioners) to generate the final Packer file (~/.axiom/images/$format/axiom.$format) Using Packer, axiom-build creates an image with the tools pre-installed, as defined by the chosen Provisioner choose between multiple Provisioners (barebones, default, reconftw, and extras) or bring your own (custom) axiom-build adds your SSH key to the image, allowing you to connect to instances created using the image by default, it creates and uses an SSH key located at ~/.ssh/axiom_ssh.pub, but you can specify a custom SSH key if needed Examples: axiom-build --run # Kick off the interactive build wizard axiom-build default # Build a new Packer image using the Default Provisioner axiom-build barebones --debug # Build a new Packer image using the Barebones Provisioner, run with --debug axiom-build --ssh-key ~/.ssh/id_rsa.pub # Set a custom SSH key (default is SSH key in ~/.ssh/axiom_ssh.pub) Usage: (optional) Name of provisioner to build, options are barebones, default, reconftw, extras or custom (provisioner must be located in ~/.axiom/images/$format/provisioners) --run (optional) Start axiom-build setup wizard --legacy (optional) Use legacy Packer JSON Builder and Provisioner instead of pkr.hcl --ssh-key (optional) Build the image using a custom SSH key (instead of using the default ssh key axiom creates ~/.ssh/axiom_ssh.pub) --debug (optional) Enable debug mode (VERY VERBOSE!) --help (optional) Display this help menu ``` {% endcode %} {% code fullWidth="false" %} ``` axiom-build default ``` {% endcode %} You can provide your provisioner inline or after running `axiom-build`. > We currently offer four different base provisioner files, and 2 custom provisioner file to build images. > > * [Default](https://github.com/attacksurge/ax/blob/master/images/provisioners/default.json) is our latest iteration of axiom provisioners. It comes with many tools installed and has been optimized for readability. Recommended for axiom-fleet. > * [ReconFTW](https://github.com/attacksurge/ax/blob/master/images/provisioners/reconftw.json) provisioner includes all tools in ReconFTW and works with most modules. Recommended for ReconFTW. > * [Barebones](https://github.com/attacksurge/ax/blob/master/images/provisioners/barebones.json) is our decently secure base install, comes with Docker, Go-lang, Interlace and nmap installed. Recommended for templating. > * [Extras](https://github.com/attacksurge/ax/blob/master/images/provisioners/extras.json) has more tools installed than our Default provisioner To use your own Provisioner, read [Bring Your Own Provisioner](https://ax-framework.gitbook.io/wiki/fundamentals/bring-your-own-provisioner). ## ax images **Manage images/snapshots with axiom-images** :cd: {% code fullWidth="true" %} ``` Description: Manage images created by 'axiom-build' or 'axiom-images' with 'axiom-images'! After creating an image, list all images on the account 'axiom-images ls' Delete images on the account that are no longer needed 'axiom-images rm $image_name' Create a new image/snapshot from a deployed instance with 'axiom-images create' (list all deployed instances with 'axiom-ls') After the new image is created, or to switch to a different image on the account, select it with 'axiom-images select $image_name' to use for 'axiom-init/axiom-fleet'! Examples: axiom-images ls # List all images on the account axiom-images get # Print details from ~/.axiom/axiom.sjon axiom-images rm axiom-default-1709878237 # Delete image named axiom-default-1709878237 from the account axiom-images create # Start 'axiom-images' image creation wizard axiom-images create testy01 # Skip image creation wizard and instead create image from testy01 instance axiom-images select axiom-barebones-1709944106 # Select image named axiom-barebones-1709944106 to use with future 'axiom-init/axiom-fleet' Usage: ls (optional) List all images on the account 'axiom-images ls' get (optional) Print information about current account, equivalent to (cat ~/.axiom/axiom.json) 'axiom-images get' rm Specify an image by name to delete (must be an image name from 'axiom-images ls') create Kick off axiom-images creation wizard or specify an instance to create an image from 'axiom-images create $instance_name' select Select a new image to use for future 'axiom-init/axiom-fleet', replaces 'imageid' in ~/.axiom/axiom.json with new 'imageid' (must be an image name from 'axiom-images ls') --debug (optional) Enable debug mode (VERY VERBOSE!) --help (optional) Display this help menu ``` {% endcode %} {% code fullWidth="true" %} ```bash axiom-images ls # List available images axiom-images use # Replace image used for axiom-init/axiom-fleet with user provided image name axiom-images rm # Delete image by name ax image create # kick off image creation wizard. Make a snapshot of a running ax instance to use for future ax init/ax fleet ``` {% endcode %} *** ## ax init **Initialize a single instance** :seedling: {% code fullWidth="true" %} ``` Description: Initialize one axiom instance with differnet options, such as image, region, size and axiom deployment profiles Examples: axiom-init --run # provision instance with random name axiom-init --deploy desktop # provision instance with random name, then deploy axiom profile 'desktop' axiom-init testy01 # provision instance named testy01 axiom-init stok01 --region nyc3 --image axiom-default-1635920849 --size s-1vcpu-2gb --deploy desktop --shell Usage: string (optional) Name of the instance, supplied as a positional first argument --run (optional) Create one instance with random name --image Manually set the image to use (default is imageid in ~/.axiom/axiom.json) --region User specified region to use (default is region in ~/.axiom/axiom.json) --deploy Deploy a profile after initialization (e.g desktop, openvpn, bbrf, wireguard) --shell (optional) Connect to instance after initialization --size VM size to use (default is size in ~/.axiom/axiom.json) --no-select (optional) Dont select instance after initialization (default is to select instance) --debug (optional) Run with set -xv, warning: very verbose --help Display this help menu ``` {% endcode %} {% code fullWidth="true" %} ```bash ax init # Init ax init --run # Init with random instance name ax init --deploy=# Init and install deployment profile ``` {% endcode %} > the `--deploy` option allows you to install a deployment profile (stored in `~/.axiom/profiles/`) *** ## ax exec **Execute a command against one or many instances** :robot: {% code fullWidth="true" %} ``` Description: Evaluate shell one-liners or execute single commands on one or more instances in parallel Specify the fleet prefix, or let axiom use selected.conf by default (located in ~/.axiom/selected.conf) Execute command(s) from a detached tmux session on the remote instances Temporarily prevent axiom's SSH key regeneration and instead connect with a cached SSH config (default is ~/.axiom/.sshconfig) Examples: axiom-exec id # Execute command id across all instances currently selected.conf (located in ~/.axiom/selected.conf) axiom-exec ifconfig --fleet testy # Execute ifconfig on testy fleet, automatically select all instances in fleet testy axiom-exec 'sudo apt dist-upgrade -y' -q --cache --fleet OtherFleet --tmux MySession01 # Quietly execute command(s) inside a detacted tmux session on the remote instances with custom session name axiom-exec whoami -q --cache --sshconfig ~/.axiom/log/exec/axiom-exec+1234567890/sshconfig --fleet oldfleet --tmux # Specify the axiom SSH config to use (default is ~/.axiom/.sshconfig) Usage: required string Command(s) to run on the remote axiom instances, multiple commands can be wrapped in single or double quotes, but not required -f/--fleet/--file Fleet prefix to execute on (default is ~/.axiom/selected.conf). Automatic wildcard support. Alternatively, can be a list of instances from a file (-f/--fleet/--file myinstances.txt) -i/--instance Single instance to execute on --sshconfig (optional string) Path to axiom's SSH config (default is ~/.axiom/.sshconfig) -q/--quiet (optional) Disable progress bar, and reduce verbosity --debug (optional) Enable debug mode (VERY VERBOSE!) --cache (optional) Temporarily do not generate SSH config and instead connect with cached SSH config --logs (optional) Do not delete logs (logs will be stored in ~/.axiom/logs/exec/axiom-exec$TIMESTAMP) --quick (optional) A faster but less reliable execution --skip-preflight (optional) Do not automatically remove instances that cant be reached (default removes instances from the queue that cant be reached) --preflight-timeout Specifies the timeout (in seconds) used when connecting to the SSH server, instead of using the default 5 seconds --help Display this help menu ``` {% endcode %} {% code fullWidth="true" %} ```bash axiom-exec id # Execute command id across all instances currently selected.conf (located in ~/.axiom/selected.conf) axiom-exec ifconfig --fleet testy # Execute ifconfig on testy fleet. Automatically select all instances in fleet testy axiom-exec sleep "$(($RANDOM % 10))" "&& id &&" echo $HOSTNAME --fleet stok # Evaluate complex one-liners on fleet stok axiom-exec 'sudo apt dist-upgrade -y' -q --cache --fleet OtherFleet --tmux MySession01 # Quietly execute command(s) inside a detacted tmux session on the remote instances with custom session name axiom-exec whoami -q --cache --sshconfig ~/.axiom/log/exec/axiom-exec+1234567890/sshconfig --fleet oldfleet --tmux # Specify the axiom SSH config to use (default is ~/.axiom/.sshconfig) ``` {% endcode %} *** ## ax ssh ## axiom-images **Manage images/snapshots with axiom-images** :cd: ##
axiom-images usage ``` Examples: axiom-images ls && axiom-images rm axiom-barebones-1634682130 && axiom-images use axiom-default-1634682131 Usage: ls List snapshots created get Display info about the current image use | set Use snapshot for axiom-init/axiom-fleet rm Remove snapshot from account help | --help | -h Print this help menu ```
```bash axiom-images ls # List available images axiom-images use # Replace image used for axiom-init/axiom-fleet with user provided image name axiom-images rm # Delete image by name ``` *** ## axiom-init **Initialize a single instance** :seedling: ##
axiom-init usage ``` Description: Initialize one axiom instance with differnet options, such as image, region, size and axiom deployment profile Examples: axiom-init # provision instance with random name axiom-init --deploy desktop # provision instance with random name, then deploy axiom profile 'desktop' axiom-init testy01 # provision instance named testy01 axiom-init stok01 --region nyc3 --image axiom-barebones-1635920849 --size s-1vcpu-2gb --deploy desktop --shell Usage: string (optional) Name of the instance, supplied as a positional first argument --image Manually set the image to use (default is imageid in ~/.axiom/axiom.json) --region User specified region to use (default is region in ~/.axiom/axiom.json) --deploy Deploy a profile after initialization (e.g desktop, openvpn, bbrf, wireguard) --shell (optional) Connect to instance after initialization --size VM size to use (default is size in ~/.axiom/account/account.json) --no-select (optional) Dont select instance after initialization (default is to select instance) --domain Manually specify the domain to use (default is specified by cloud provider) --restore Initialize with a previous backup --help Display this help menu ```
```bash axiom-init # Init axiom-init --deploy --restore # Init & deploy & restore #Note: profile argument is file name is without .json ``` > the `--deploy` option allows you to deploy a profile (stored in `~/.axiom/profiles/`). `--restore` will restore a profile. These options can be used together. ``` axiom-init ``` You can run this command without any parameters, and it will pick a name for you. This name is picked at random from a list of legends! ``` # axiom-init axiom-init jerry ``` If you supply an argument, it will be used as the instance name, in the above example we spin up an instance called "jerry". ## axiom-ls Now you have spun up an instance, you can run `axiom-ls` and get a list of all running instances. #### List your instances - `axiom-ls` *** ## axiom-exec **Execute a command against an Instance** :robot: ##
axiom-exec usage ``` Description: Evaluate shell one-liners or execute single commands on one or more instances in parallel Expand local and remote environment variables respectively Specify the fleet prefix, or let axiom use selected.conf by default (located in ~/.axiom/selected.conf) Optionally execute command(s) in a detached tmux session on the remote instances (commands run in the background) Temporarily prevent axiom's SSH key regeneration and instead connect with a cached SSH config (default is ~/.axiom/.sshconfig) Examples: axiom-exec id # Execute command id across all instances currently selected.conf (located in ~/.axiom/selected.conf) axiom-exec ifconfig --fleet testy # Execute ifconfig on testy fleet. Automatically select all instances in fleet testy axiom-exec sleep "$(($RANDOM % 10))" "&& id &&" echo $HOSTNAME --fleet stok # Evaluate complex one-liners on fleet stok axiom-exec 'sudo apt dist-upgrade -y' -q --cache --fleet OtherFleet --tmux MySession01 # Quietly execute command(s) inside a detacted tmux session on the remote instances with custom session name axiom-exec whoami -q --cache --sshconfig ~/.axiom/log/exec/axiom-exec+1234567890/sshconfig --fleet oldfleet --tmux # Specify the axiom SSH config to use (default is ~/.axiom/.sshconfig) Usage: required string Command(s) to run on the remote axiom instances, multiple commands can be wrapped in single or double quotes, but not required -f/--fleet Fleet prefix to execute on (default is ~/.axiom/selected.conf). Automatic wildcard support -i/--instance Single instance to execute on --tmux Execute commands in a detacted tmux session (commands run in the background). The default tmux session name is axiom-exec+$TIMESTAMP, or supply a custom tmux session name --sshconfig (optional string) Path to axiom's SSH config (default is ~/.axiom/.sshconfig) -q/--quiet Disable progress bar, and reduce verbosity --debug Enable debug mode (VERY VERBOSE!) --cache Temporarily do not generate SSH config and instead connect with cached SSH config --logs Do not delete logs (logs will be stored in ~/.axiom/logs/exec/axiom-exec$TIMESTAMP) --help Display this help menu ```
```bash axiom-exec id # Execute command id across all instances currently selected.conf (located in ~/.axiom/selected.conf) axiom-exec ifconfig --fleet testy # Execute ifconfig on testy fleet. Automatically select all instances in fleet testy axiom-exec sleep "$(($RANDOM % 10))" "&& id &&" echo $HOSTNAME --fleet stok # Evaluate complex one-liners on fleet stok axiom-exec 'sudo apt dist-upgrade -y' -q --cache --fleet OtherFleet --tmux MySession01 # Quietly execute command(s) inside a detacted tmux session on the remote instances with custom session name axiom-exec whoami -q --cache --sshconfig ~/.axiom/log/exec/axiom-exec+1234567890/sshconfig --fleet oldfleet --tmux # Specify the axiom SSH config to use (default is ~/.axiom/.sshconfig) ``` ## axiom-ssh **Connect to an instance - axiom-ssh** :link: ##
axiom-ssh usage ``` Description: axiom-ssh dynamically generates axiom's SSH config based on your cloud inventory. axiom-ssh allows you to connect to your axiom instances over their public or private network interface. axiom-ssh can drop you right into a freshly created tmux session on the remote instance, and can be used to attach to a preexisting tmux session. All additional SSH args are passed to SSH. Examples: axiom-ssh testy01 # SSH into instance testy01 axiom-ssh testy01 --tmux mysession1 # SSH into instance testy01 and spawn or attach to session named mysession1 axiom-ssh --just-generate # Always populate axiom's ssh config (located in ~/.axiom/.sshconfig) with public Ip details axiom-ssh --just-generate private # Always populate axiom's ssh config (located in ~/.axiom/.sshconfig) with private Ip details axiom-ssh --just-generate cache # Never regenerate axiom's ssh config axiom-ssh testy01 -L 8080:127.0.0.1:8080 -D 4040 # Port-forward 8080 to local port 8080 and dynamically port foward port 4040 to testy01 Usage: required string Instance name supplied as a positional first argument --mosh/-m (optional) Connect with mosh --just_generate (optional) Specify when to generate the SSH config file and what IPs to use. Options are public, private, cache ( default is public ) --tmux Connect to your instance and start new tmux session. If you dont include a session name one will be chosen automatically for you --tmux-attach/-t (optional) Connect to your instance and attach to tmux session by name --cache (optional) Temporarily do not generate SSH config and instead connect with cached SSH config --help (optional) Display this help menu All additional SSH args are passed to SSH. If you want additional arguments supplied to your command, simply append them to the command example: axiom-ssh -L 8080:127.0.0.1:8080 -D 4040 ```
```bash axiom-connect #automatically connects to list initialized instance axiom-connect axiom-ssh axiom-ssh --tmux axiom-ssh -m -t # Connect with mosh and attach to tmux session axiom-ssh -m -t main-15 axiom-ssh -L 8080:127.0.0.1:8080 -D 4040 # All additional SSH args are passed to SSH axiom-ssh --cache # Don't generate ssh config, just connect with cache axiom-ssh --just-generate # Generate an SSH config at ~/.axiom/.sshconfig ``` *** #### Connect to your instance - `axiom-ssh ` Now you have an instance, and it has a public IP address, you can connect to your new instance using `axiom-ssh` ``` # axiom-ssh axiom-ssh jerry ``` If you want to be dropped into a tmux session, that will remain after you disconnect, use the `--tmux` flag. ``` axiom-ssh jerry --tmux ``` To detach from this tmux session, run `ctrl+a d`, this will disconnect you from the box but leave your tmux session running (and any command running in that session!) *** ## axiom-backup **Backup an initialized instance to the cloud** :luggage: ```bash axiom-backup ``` > After running axiom-init you can set up config files, unique wordlists, private tools etc, take a snapshot of that image and use it to deploy future axiom instances/fleets. *** #### Backup an Initialized Instance - `axiom-backup ` After running axiom-init you can set up config files, unique wordlists, private tools etc, take a snapshot of that image and use it to deploy future axiom instances/fleets. ``` axiom-backup jerry ``` *** ## axiom-rm **Remove one or more axiom instances** :x: ```bash axiom-rm # Delete box by specifying the name axiom-rm -f # Forcibly delete box by specifying the axiom-rm \* # Delete all instances that start with . You must escape the asterisk. axiom-rm \* -f # Forcibly delete all instances that start with . You must escape the asterisk. axiom-rm '\*' # Delete all instances on the account. Must be wrapped in single quote and escape the asterisk. axiom-rm '\*' -f # Forcibly delete all instances on the account. Must be wrapped in single quote and escape the asterisk. ``` *** #### Delete your instance Once you're done with your instance, delete it using the command, `axiom-rm ` ``` axiom-rm jerry # or axiom-rm jerry -f ``` The -f flag will not prompt on deletion, I generally use this, but if you want to be ultra sure omit the `-f` flag. ## More Info In Summary, a few useful commands to get you up and running, to use basic instances, and interact with them. Please refer to [Filesystem Utilities](https://github.com/pry0cc/axiom/wiki/Filesystem-Utilities) for more details. # QuickStart Guide Example workflow for running ax for the first time 1. [Configure](/overview/quickstart-guide-1/configure-ax-controller) Ax Controller: `ax configure --run` 2. [Deploy](/overview/quickstart-guide-1/deploy-instances) an instance or a fleet of instances: `ax init ` or `ax fleet -i ` 3. [Run Scans](/overview/quickstart-guide-1/run-scans): `ax scan ips.txt -m nmap ...` 4. [Teardown](/overview/quickstart-guide-1/teardown-instances) instances when finished `ax rm ` # Configure Ax Controller ## Installation Follow the [#installation](#installation "mention") guide to install the Ax Controller ## ax configure Setup and configure the ax controller and validate your cloud account 💻 ### Example Usage `ax configure --run` Launch the interactive configuration workflow will step you through the following: * Install dependencies * Add ax to your shell profile * Ask to occasionally check for updates in the background * Set up access to your chosen cloud provider ### Usage run `~/.axiom/interact/axiom-configure` if ax is not yet in your shell path. ``` # axiom-configure --help █████╗ ██╗ ██╗ ██████╗ ██████╗ ███╗ ██╗███████╗██╗ ██████╗ ██╔══██╗╚██╗██╔╝ ██╔════╝██╔═══██╗████╗ ██║██╔════╝██║██╔════╝ ███████║ ╚███╔╝ ██║ ██║ ██║██╔██╗ ██║█████╗ ██║██║ ███╗ ██╔══██║ ██╔██╗ ██║ ██║ ██║██║╚██╗██║██╔══╝ ██║██║ ██║ ██║ ██║██╔╝ ██╗ ╚██████╗╚██████╔╝██║ ╚████║██║ ██║╚██████╔╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ╚═════╝ ╚═════╝ ╚═╝ ╚═══╝╚═╝ ╚═╝ ╚═════╝ Maintainer: 0xtavian 𝓪𝓵𝓻𝓲𝓰𝓱𝓽, 𝔂𝓸𝓾 𝓰𝓸𝓽 𝓶𝓮, 𝓲𝓽𝓼 𝓳𝓾𝓼𝓽 𝓪𝔁𝓲𝓸𝓶: 𝓽𝓱𝓮 𝓭𝔂𝓷𝓪𝓶𝓲𝓬 𝓲𝓷𝓯𝓻𝓪𝓼𝓽𝓻𝓾𝓬𝓽𝓾𝓻𝓮 𝓯𝓻𝓪𝓶𝓮𝔀𝓸𝓻𝓴 𝓯𝓸𝓻 𝓮𝓿𝓮𝓻𝔂𝓫𝓸𝓭𝔂! - @𝓹𝓻𝔂0𝓬𝓬 @0𝔁𝓽𝓪𝓿𝓲𝓪𝓷 Description: Examples: axiom-configure --run # kick off Ax configuration wizard axiom-configure --shell zsh # Set default shell to zsh via command line axiom-configure --config # Use personal.json from a file for account setup axiom-configure --config # Use personal.json data supplied by command-line for account setup (must be vaild personal.json data wrapped in single quotes) axiom-configure --shell bash --unattended --config # Use bash for default shell, do not promot, use personal.json data from file for axiom setup Usage: --run (required) Start axiom-configure wizard, install dependencies, kick off axiom-account-setup and axiom-build --config Setup account with data from file or supplied from the command line (must be vaild data from a personal.json axiom file) --unattended (optional) Avoid any promots, defaults to Oh My Zsh unless --shell argument is also provided --shell (optional) Add axiom to path, backup .zshrc/.bashrc to .zshrcbak/.bashrcbak --auto-update (optional) Toggle auto-update to periodically update axiom --debug (optional) Enable debug mode (VERY VERBOSE!) --help Display this help menu ``` You can provide your config inline or after running axiom-configure. `axiom-configure --shell bash --unattended --config { "do_key": "[redacted]", "region": "nyc1", "provider": "do", "default_size": "s-1vcpu-1gb", "appliance_name": "", "appliance_key": "", "appliance_url": "", "email": "", "op": "[redacted]", "imageid": "axiom-default-myimageid", "provisioner": "default", "sshkey": "id_rsa" }` ``` To get your account.json config file in this format run: cat ~/.axiom/accounts/do.json | tr '\n' ' ' | tr -s ' ' ``` ### Cloud Configuration During the initial installation, running [`ax configure`](https://github.com/attacksurge/ax/blob/master/interact/axiom-configure) will trigger [`ax account-setup`](https://github.com/attacksurge/ax/blob/master/interact/axiom-account-setup), which in turn calls [`ax account`](https://github.com/attacksurge/ax/blob/master/interact/axiom-account) along with the respective cloud provider's [`account-helper`](https://github.com/attacksurge/ax/tree/master/interact/account-helpers) script. Once this setup is complete, [`ax build`](https://github.com/attacksurge/ax/blob/master/interact/axiom-build) is executed to create your [Packer](https://www.packer.io/) image. After the image is successfully built, you can deploy fleets of servers using [`ax fleet`](https://github.com/attacksurge/ax/blob/master/interact/axiom-fleet) and distribute scans with [`ax scan`](https://github.com/attacksurge/ax/blob/master/interact/axiom-scan)! You can also just run axiom account-setup at any time. ``` $ ax account-setup Axiom Account Setup You can use this wizard to add new accounts, once made, use axiom-account to switch between profiles Please enter your provider (aws, azure, do, gcp, hetzner, ibm, linode, scaleway): ``` # Build a Base Image ## axiom-build Pick a Packer provisioner 🐣 **Running this may not be necessary if `axiom-configure --run` completed successfully.** ### Example Usage ``` # axiom-build default ``` ### Usage ``` # axiom-build -h █████╗ ██╗ ██╗ ██████╗ ██╗ ██╗██╗██╗ ██████╗ ██╔══██╗╚██╗██╔╝ ██╔══██╗██║ ██║██║██║ ██╔══██╗ ███████║ ╚███╔╝ ██████╔╝██║ ██║██║██║ ██║ ██║ ██╔══██║ ██╔██╗ ██╔══██╗██║ ██║██║██║ ██║ ██║ ██║ ██║██╔╝ ██╗ ██████╔╝╚██████╔╝██║███████╗██████╔╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ╚═════╝ ╚═════╝ ╚═╝╚══════╝╚═════╝ Maintainer: 0xtavian 𝓫𝓪𝓼𝓲𝓬𝓪𝓵𝓵𝔂, 𝓪𝔁𝓲𝓸𝓶: 𝓽𝓱𝓮 𝓭𝔂𝓷𝓪𝓶𝓲𝓬 𝓲𝓷𝓯𝓻𝓪𝓼𝓽𝓻𝓾𝓬𝓽𝓾𝓻𝓮 𝓯𝓻𝓪𝓶𝓮𝔀𝓸𝓻𝓴 𝓯𝓸𝓻 𝓮𝓿𝓮𝓻𝔂𝓫𝓸𝓭𝔂! - @𝓹𝓻𝔂0𝓬𝓬 @0𝔁𝓽𝓪𝓿𝓲𝓪𝓷 Description: axiom-build supports both legacy Packer JSON files as well as the new HCL format axiom-build combines a cloud provider's Builder (~/.axiom/images/$format/builders) with a Provisioner (~/.axiom/images/$format/provisioners) to generate the final Packer file (~/.axiom/images/$format/axiom.$format) Using Packer, axiom-build creates an image with the tools pre-installed, as defined by the chosen Provisioner Choose between multiple Provisioners (barebones, default, reconftw, and extras) or bring your own (custom) axiom-build adds your SSH key to the image, allowing you to connect to instances created using the image By default, it creates and uses an SSH key located at ~/.ssh/axiom_ssh.pub, but you can specify a custom SSH key if needed Examples: axiom-build --run # Kick off the interactive build wizard axiom-build default # Build a new Packer image using the Default Provisioner axiom-build barebones --debug # Build a new Packer image using the Barebones Provisioner, run with --debug axiom-build --ssh-key ~/.ssh/id_rsa.pub # Set a custom SSH key (default is SSH key in ~/.ssh/axiom_ssh.pub) Usage: (optional) Name of provisioner to build, options are barebones, default, reconftw, extras or custom (provisioner must be located in ~/.axiom/images/$format/provisioners) --run (optional) Start axiom-build setup wizard --legacy (optional) Use legacy Packer JSON Builder and Provisioner instead of pkr.hcl --ssh-key (optional) Build the image using a custom SSH key (instead of using the default ssh key axiom creates ~/.ssh/axiom_ssh.pub) --debug (optional) Enable debug mode (VERY VERBOSE!) --help (optional) Display this help menu ``` ### Provisoners You can provide your provisioner inline or after running axiom-build --run. We currently offer four different base provisioner files to build images. * Default is our latest iteration of axiom provisioners. It comes with all tools installed and has been optimized for readability. Recommended for axiom-fleet * ReconFTW includes all tools in ReconFTW and works with most modules. Recommended for ReconFTW. * Barebones is a decently secure base install, comes with Docker, Go-lang, Interlace and nmap installed. Recommended for templating. * Extras has more tools installed compared to default ### Custom Images If you want to bring-your-own Packer JSON provisioner, select custom. Make sure your packer json is placed in `~/.axiom/images/provisioners` See [Bring Your Own Provisioner](/fundamentals/bring-your-own-provisioner)for more information. ### # Deploy Instances Deploy one instance with axiom-init or several with axiom-fleet ## Example Usage ### axiom-init: deploy one instance Use [#axiom-init](#axiom-init "mention") to deploy one instance ``` axiom-init --run # provision instance with random name axiom-init testy01 # provision instance named testy01 axiom-init stok01 --region nyc3 --image axiom-barebones-1635920849 --size s-1vcpu-2gb --deploy desktop --shell ``` ### axiom-fleet: deploy several instances in a fleet Use axiom-fleet to deploy several instances as a fleet. ``` axiom-fleet -i 13 # Initialize a fleet, name it randomly axiom-fleet testy -i 8 # Initialize a fleet named 'testy', instances will be named, testy01, test02 etc axiom-fleet testy -i 10 --regions nyc1,lon1,ams3,fra1 # Initialize a fleet using round-robin region distribution ``` ## Usage ### axiom-init Initialize a single instance 🌱 ``` Description: Initialize one axiom instance with differnet options, such as image, region, size and axiom deployment profile Examples: axiom-init # provision instance with random name axiom-init --deploy desktop # provision instance with random name, then deploy axiom profile 'desktop' axiom-init testy01 # provision instance named testy01 axiom-init stok01 --region nyc3 --image axiom-barebones-1635920849 --size s-1vcpu-2gb --deploy desktop --shell Usage: string (optional) Name of the instance, supplied as a positional first argument --image Manually set the image to use (default is imageid in ~/.axiom/axiom.json) --region User specified region to use (default is region in ~/.axiom/axiom.json) --deploy Deploy a profile after initialization (e.g desktop, openvpn, bbrf, wireguard) --shell (optional) Connect to instance after initialization --size VM size to use (default is size in ~/.axiom/account/account.json) --no-select (optional) Dont select instance after initialization (default is to select instance) --domain Manually specify the domain to use (default is specified by cloud provider) --restore Initialize with a previous backup --help Display this help menu ``` ### axiom-fleet Spin up fleets of axiom instances ``` Description: Spin up fleets of axiom instances in one or multiple regions. Specify the name of your fleet (fleet prefix) or have axiom choose for you. Examples: axiom-fleet ctbb # Spin up 3 instances named ctbb01 ctbb02 and ctbb03 axiom-fleet -i 10 # Spin up 10 instances with random fleet prefix axiom-fleet jerry -i 25 --regions dal13,lon06,fra05 # Spin up 25 instances named jerry01 to jerry25 using Round-robin region distribution Usage: (optional) Name of fleet prefix (default is random fleet prefix) -i/--instances The number of instances to spin up -r/--regions (optional) Supply comma-separated regions to cycle through (default is region in ~/.axiom/axiom.json) --image (optional) Manually set the image to use (default is imageid in ~/.axiom/axiom.json) --debug (optional) Run with set -xv, warning: very verbose --help (optional) Display this help menu ``` # List Instances ## axiom-ls Now you have spun up an instance, you can run `axiom-ls` and get a list of all running instances. ### Example Usage ``` Listing instances in account: aws Instance Primary IP Backend IP Region Type Status $/M test01 34.223.252.120 172.31.15.197 us-west-2c t2.medium running 33.872 test02 54.149.117.15 172.31.3.67 us-west-2c t2.medium running 33.872 test03 18.237.235.64 172.31.6.251 us-west-2c t2.medium running 33.872 test04 54.187.47.29 172.31.15.201 us-west-2c t2.medium running 33.872 test05 54.245.147.45 172.31.9.104 us-west-2c t2.medium running 33.872 _ _ _ Instances 5 Total $169.360 ``` # Run Scans ## axiom-scan Run distributed scans with your instances. For more information about scans see [Scans](/fundamentals/scans) ### Example Usage {% code fullWidth="false" %} ``` axiom-select 'fleet*' # fleets should be already selected, but just in case, select can be a good idea # Format axiom-scan -m -o # Examples axiom-scan roots.txt -m subfinder -o subfinder.txt # run subfinder against all roots axiom-scan subfinder.txt -m dnsx -o dnsx.txt # run dnsx against all subfinder results axiom-scan dnsx.txt -m httpx -o httpx.txt # run httpx against all dnsx results axiom-scan httpx.txt -m gowitness -o screenshots-directory # run gowitness against all httpx results axiom-scan httpx.txt -m nuclei -o nuclei.txt # run nuclei against all httpx results axiom-scan httpx.txt -m ffuf -o ffuf.txt # run ffuf against all httpx results axiom-scan ips.txt -m nmap -oG portscan.txt # run nmap, output as greppable axiom-scan ips.txt -m nmap -oX portscan # Output and merge XMLs (this also creates an HTLM report) axiom-scan ips.txt -m nmap -p- -sV -T4 -v --open -oA nampx-scan --spinup 10 # run nmap, pass extra_args to nmap binary, output to a directory containing text, XML and Greppable results, spin up 10 instances axiom-scan ips.txt -m masscan -oG masscan.txt # Run masscan, output as greppable ``` {% endcode %} ## Usage Modules must be located in [`~/.axiom/modules/`](https://github.com/attacksurge/ax/tree/master/modules). For more information about modules, see [modules](/fundamentals/scans/modules). 
axiom-scan provides easy distribution of arbitrary binaries and scripts.
axiom-scan optionally splits user-provided input files (target lists), and wordlists and uploads them to a unique scan working directory on the remote instance.
axiom-scan combines user-provided command-line arguments with commands in the module (~/.axiom/modules) and executes the final command on the remote instance.
axiom-scan downloads and merges scan output in a variety of different formats, specified by the extension in the module (dir, txt, oG, csv, xml, jsonl, none).
individual scanning operations are executed from a detacted tmux session ($module+$timestamp) inside a unique scan working directory (/home/op/scan/$module+$timestamp) on the remote instances.

Usage:
   axiom-scan inputfile.txt -m ffuf -w /home/op/wordlist-on-remote-instance
   axiom-scan inputfile.txt -m ffuf -wL /home/localuser/local-wordlist-to-upload
   axiom-scan inputfile.txt -m ffuf -wD /home/localuser/local-wordlist-to-split-and-upload
   axiom-scan inputfile.txt -m nuclei --remote-folder /home/op/nuclei-templates-on-remote-instances -o outputfile.txt
   axiom-scan inputfile.txt -m nuclei --local-folder /home/localuser/local-custom-nuclei-template-folder-to-upload/ -o outputfile.txt
   axiom-scan inputfile.txt -m nuclei --local-config /home/localuser/local-custom-nuclei-config-file-to-upload.yaml -o outputfile.txt --anew
   axiom-scan inputfile.txt -m gowitness -oD screenshots-folder --spinup 10
   axiom-scan inputfile.txt -m nmapx -p- -sV -T4 -v --open -oA nampx-scan --spinup 100 --rm-when-done --regions dal13,lon06,fra05,sjc04

Flags:
INPUT:
   string[]              required positional first argument must always be an input file, this can be a list of URLs, IPs, hostnames, etc
   --dont-shuffle        do not randomize input file before uploading (default is to randomize)
   --dont-split          do not split input file, upload entire input file to every instance (default is to split the input file)
   --expand-cidr         automatically expand any subnet in the input file (default does not expand subnets)

MODULE:
   -m string[]           the axiom-scan module to use with the scan (must be a JSON file in ~/.axiom/modules)
   --list                print all available modules located in ~/.axiom/modules

WORDLIST:
   -w string[]                           replace _wordlist_ in module with user-provided wordlist (must be a path to a remote wordlist)
   -wD,--distribute-wordlist string[]    replace _wordlist_ in module with user-provided local wordlist to split and upload (default does not split the wordlist)
   -wL,--local-wordlist string[]         replace _wordlist_ in module with user-provided local wordlist (must be a path to a local wordlist)

FOLDER:
   --remote-folder string[]              replace _folder_ in module with user-provided remote folder (must be a path to a remote folder)
   --local-folder string[]               replace _folder_ in module with user-provided local folder to upload (must be a path to a local folder)

CONFIGURATIONS:
   --remote-config string[]              replace _config_ in module with user-provided configuration file (must be a configuration file on the remote instances)
   --local-config string[]               replace _config_ in module with user-provided local configuration file to upload (must be a local configuration file)

ONE-SHOT:
   --disable-oneshot           by default, if a module contains the string _target_ or _safe-target_ it is executed as a one-shot module. Use this flag to force disable
   --unsafe                    for one-shot modules only, axiom will transparently replace _target_ with _safe-target_ in modules at runtime, use this flag to force disable
   --track-finished            for one-shot modules only, add this flag to track finished targets (creates a file in the remote scan working directory named finished.txt)
   --threads int[]             specify the number of threads to use with one-shot modules (default uses "threads": $N key:value pair in the module)"

OPTIMIZATIONS:
   --upload string[]           before the scan, upload a file to the unique scan working directory (/home/op/scan/$module+$timestamp) on remote instances (must be a path to a local file)
   --download string[]         after the scan, download a file from the unique scan working directory (/home/op/scan/$module+$timestamp) on remote instances (must be a path to a remote file)
   --max-runtime DURATION[]    kill scan if still running after DURATION, DURATION is a floating point number with an required suffix: 'm' for minutes, 'h' for hours or 'd' for days
   --preflight-timeout int[]   specifies the timeout (in seconds) used when connecting to the SSH server, instead of using the default 15 seconds
   --skip-preflight            do not automatically remove instances that can not be reached (default removes instances from the queue that can not be reached)
   --anew                      pipe the output to anew before creating the final output file (also requires extension "ext":"txt", "ext":"oG" or "ext":"csv" to be in the module)

OUTPUT:
   -o string[]           output as default (the first ext mentioned in the module)
   -oT/-txt string[]     output as text (must also be supplied in the module using "ext":"txt")
   -oD/-oA string[]      output as directory (must also be supplied in the module using "ext":"dir" or "ext":"")
   -oG string[]          output as greppable, merge and sort unique (must also be supplied in the module using "ext":"oG")
   -oJ string[]          output as json lines, newline characters are used to delimit JSON data (must also be supplied in the module using "ext":"jsonl")
   -oX string[]          output as XML/HTML (supported for nmap and masscan)(must also be supplied in the module using "ext":"xml")
   -csv string []        output as csv, extract csv header, merge and sort unique (must also be supplied in the module using "ext":"csv")
   -none string []       do not attempt to merge the output at all (must also be supplied in the module using "ext":"none")
   --quiet               do not display findings to terminal
   --rm-logs             delete remote and local logs after scan completes, except for the unmered output files in ~/.axiom/logs/$module+$timestamp/output
   --no-logs             do not store any logs at all, do not tail terminal output. Delete all logs even the unmerged output files in ~/.axiom/logs/$module+$timestamp/output
   --stdout              only display stdout results to terminal (default displays stdout and stderr to the terminal)

FLEET:
   --custom-ssh string[]       path to custom SSH config file (default is located at ~/.axiom/.sshconfig)
   --cache                     do not regenerate SSH config prior to scan, instead use cached config (located at ~/.axiom/.sshconfig)
   --fleet string[]            supply fleet prefix to use (default uses instances in ~/.axiom/selected.conf)
   --regions string[]          round-robin region distribution using comma-separated regions to cycle through (default is region in ~/.axiom/axiom.json)
   --rm-when-done              delete the instance when finished with its job (does not wait for all instances to complete)
   --shutdown-when-done        shutdown the instance when finished with its job (does not wait for all instances to complete)
   --spinup int[]              number of instances to spin up prior to scanning (default uses instances in ~/.axiom/selected.conf)

DEBUG:
   --debug                     run with set -xv, warning: very verbose (use with --cache for less output)

EXTRA ARGS:
   string[]                    supply additional arguments to be passed to the module
   --extra-args string[]       explicitly define extra args to be passed to the module, must be wrapped single or double quotes (depending on intended variable expansion)
# Teardown Instances ## axiom-rm Remove one or more axiom instances ❌ Once you're done with your instance, delete it using the command, axiom-rm ``` axiom-rm jerry axiom-rm jerry -f # avoid confirmation prompts axiom-rm jerry01 jerry02 -f # explicitly list the names of the instances to delete axiom-rm 'jerry\*' -f # delete all instances starting with jerry axiom-rm '\*erry\*' -f # delete based on substring matches ``` The -f/--force flag will not prompt on deletion, I generally use this, but if you want to be ultra sure omit the -f flag. The -m/--multi flag deletes many instances at once. Its a faster way to delete instances and uses less API calls (with most providers) ### Help Menu ``` Description: Delete one or more cloud hosted compute devices Supports globbing (wildcarding) to match instances based on patterns in their names, such as prefix, suffix, or substring matches. Examples: axiom-rm testy01 # Delete instance named 'testy01' axiom-rm 'testy*' # Delete all instances starting with 'testy' (you may need to escape the asterisk) axiom-rm '*tess*' # Delete all instances containing the string 'tess' (you may need to escape the asterisks) axiom-rm '\*' --force --multi # Delete all instances on the account, avoid confirmation prompts, delete many instances with one API call Usage: string (required) Name of the instance(s) to delete -f/--force (optional) Avoid confirmation prompts -m/--multi (optional) Delete multiple instances at once --debug (optional) Run with set -xv, warning: very verbose --help (optional) Display this help menu ``` # Ax Utility Scripts Utility scripts to help you interact with axiom instances! ## ax **A wrapper for various axiom scripts in \~/.axiom/interact** {% code fullWidth="true" %} ``` Description: Welcome to the Ax Framework! You can use this wrapper to execute the various axiom scripts (located in ~/.axiom/interact/) To supply additional arguments to a script, simply append them to the command For more options, print the help menu for any script (ax init, ax fleet, ax scan, ax images, etc) Or you could just run the scripts without the wrapper (axiom-exec for example) Examples: ax configure --setup --shell zsh --unattended # Kick off axiom configuration wizard, add axiom to zsh path, avoid any prompts ax account-setup # Kick off axiom account setup wizard ax account linode # Switch to linode account (must be a valid axiom.json in ~/.axiom/accounts) ax build default # Build the Packer image with the Default provisioner located in ~/.axiom/images/provisioners/default.json ax init --run # Create axiom instance with random instane name ax fleet -i 10 -r nyc1,nyc3,fra1,sfo2 # Spin up 10 instances with random fleet prefix using Round-robin region distribution ax ls # List all instances on the account ax ssh testy01 # SSH into instance testy01 ax select testy\* # Select all instances in testy fleet (this updates ~/.axiom/selected.conf) ax scp custom-wordlist.txt 'myfleet*':/home/op/custom-wordlist.txt --split # Split and upload local wordlist to all instances in myfleet ax scan input.txt -m nuclei --nuclei-templates /home/localuser/custom-templates/ -o outputfile.txt # Run a distributed scan, upload custom nuclei templates ax rm testy\* # Delete all instances in testy fleet ax rm '\*' # Delete all instances on the account ax images ls # List all images on the account ax images create # Create a new image/snapshot of a running axiom instance ax images select axiom-testy01-1710180715 # Select image named axiom-testy01-1710180715 to use for future ax init and ax fleet ax sizes ls # List all available sizes (cpu and ram) to use for instances ax sizes select s-4vcpu-8gb # Select new default instance size to use for future axiom-init/axiom-fleet ax power on rez\* # Power on all instances in fleet 'rez' ax region ls # List available regions ax region select nyc1 # Select region 'nyc1' (this updates ~/axiom.json with the new region) Usage: account Select Axiom account (axiom-account) account-setup Start Axiom account setup wizard (axiom-account-setup) build Start Axiom build wizard (axiom-build) configure Display commands to manage the configuration of axiom (axiom-configure), install dependencies, kick off axiom-account-setup and axiom-build deploy Deploy a profile stored in ~/.axiom/profiles/ (axiom-deploy) exec Evaluate shell one-liners or execute single commands on one or more instances in parallel (axiom-exec) fleet Display commands to manage fleets (axiom-fleet) images Create a new snapshot of a running axiom instance, select the new snapshot to deploy future axiom instances/fleets, get and delete images (axiom-images) init Display commands to manage initializing one axiom instance with differnet options, such as image, region, size and axiom deployment profiles (axiom-init) ls List all instances on the account (axiom-ls) power Display commands to manage powering on or off instances by name (axiom-power) region Display commands to list regions or select a region (axiom-region) rm Remove instances from the account (axiom-rm) scan Display commands to manange the distribution of arbitrary binaries and scripts across fleets of Axiom instances (axiom-scan) scp Display commands used to upload and download files from fleets (axiom-scp) select Select instances to use for exec and fleet (axiom-select) sizes Manage the default instance size used by axiom-init or axiom-fleet (axiom-sizes) ssh Display commands to manage Axiom's ssh config file or connect to a specific Axiom instance (axiom-ssh) sync Make a copy of an instances home directoy and sync to your local filesystem (axiom-sync) update Run 'cd ~/.axiom && git pull' to update to the latest version! (axiom-update) To pass additional arguments to the script, simply append them to the command! ``` {% endcode %} *** ## ax configure **Setup and configure the axiom controller and validate cloud account** :computer: {% code fullWidth="true" %} ``` Description: Examples: axiom-configure --setup # kick off Ax configuration wizard axiom-configure --shell zsh # Set default shell to zsh via command line axiom-configure --config # Use personal.json from a file for account setup axiom-configure --config # Use personal.json data supplied by command-line for account setup (must be vaild personal.json data wrapped in single quotes) axiom-configure --shell bash --unattended --config # Use bash for default shell, do not promot, use personal.json data from file for axiom setup Usage: --setup (optional) Start axiom-configure wizard, install dependencies, kick off axiom-account-setup and axiom-build --config Setup account with data from file or supplied from the command line (must be vaild data from a personal.json axiom file) --unattended (optional) Avoid any promots, defaults to Oh My Zsh unless --shell argument is also provided --shell (optional) Add axiom to path, backup .zshrc/.bashrc to .zshrcbak/.bashrcbak --debug (optional) Enable debug mode (VERY VERBOSE!) --help Display this help menu ``` {% endcode %} {% code fullWidth="true" %} ``` ax configure --setup ``` {% endcode %} You can provide your config file before or after running `axiom-configure`. `axiom-configure --setup --shell bash --unattended --config ~/.axiom/accounts/do.json` *** ## ax build **Pick a Packer provisioner** :hatching\_chick: > You must run axiom-configure before anything else. This creates your axiom.json file which is required by other commands. {% code fullWidth="true" %} ``` Description: axiom-build supports both legacy Packer JSON files as well as the new HCL format axiom-build combines a cloud provider's Builder (~/.axiom/images/$format/builders) with a Provisioner (~/.axiom/images/$format/provisioners) to generate the final Packer file (~/.axiom/images/$format/axiom.$format) Using Packer, axiom-build creates an image with the tools pre-installed, as defined by the chosen Provisioner choose between multiple Provisioners (barebones, default, reconftw, and extras) or bring your own (custom) axiom-build adds your SSH key to the image, allowing you to connect to instances created using the image by default, it creates and uses an SSH key located at ~/.ssh/axiom_ssh.pub, but you can specify a custom SSH key if needed Examples: axiom-build --run # Kick off the interactive build wizard axiom-build default # Build a new Packer image using the Default Provisioner axiom-build barebones --debug # Build a new Packer image using the Barebones Provisioner, run with --debug axiom-build --ssh-key ~/.ssh/id_rsa.pub # Set a custom SSH key (default is SSH key in ~/.ssh/axiom_ssh.pub) Usage: (optional) Name of provisioner to build, options are barebones, default, reconftw, extras or custom (provisioner must be located in ~/.axiom/images/$format/provisioners) --run (optional) Start axiom-build setup wizard --legacy (optional) Use legacy Packer JSON Builder and Provisioner instead of pkr.hcl --ssh-key (optional) Build the image using a custom SSH key (instead of using the default ssh key axiom creates ~/.ssh/axiom_ssh.pub) --debug (optional) Enable debug mode (VERY VERBOSE!) --help (optional) Display this help menu ``` {% endcode %} {% code fullWidth="true" %} ``` axiom-build default ``` {% endcode %} You can provide your provisioner inline or after running `axiom-build`. > We currently offer four different base provisioner files, and 2 custom provisioner file to build images. > > * [Default](https://github.com/attacksurge/ax/blob/master/images/provisioners/default.json) is our latest iteration of axiom provisioners. It comes with many tools installed and has been optimized for readability. Recommended for axiom-fleet. > * [ReconFTW](https://github.com/attacksurge/ax/blob/master/images/provisioners/reconftw.json) provisioner includes all tools in ReconFTW and works with most modules. Recommended for ReconFTW. > * [Barebones](https://github.com/attacksurge/ax/blob/master/images/provisioners/barebones.json) is our decently secure base install, comes with Docker, Go-lang, Interlace and nmap installed. Recommended for templating. > * [Extras](https://github.com/attacksurge/ax/blob/master/images/provisioners/extras.json) has more tools installed than our Default provisioner To use your own Provisioner, read [Bring Your Own Provisioner](https://ax-framework.gitbook.io/wiki/fundamentals/bring-your-own-provisioner). ## ax images **Manage images/snapshots with axiom-images** :cd: {% code fullWidth="true" %} ``` Description: Manage images created by 'axiom-build' or 'axiom-images' with 'axiom-images'! After creating an image, list all images on the account 'axiom-images ls' Delete images on the account that are no longer needed 'axiom-images rm $image_name' Create a new image/snapshot from a deployed instance with 'axiom-images create' (list all deployed instances with 'axiom-ls') After the new image is created, or to switch to a different image on the account, select it with 'axiom-images select $image_name' to use for 'axiom-init/axiom-fleet'! Examples: axiom-images ls # List all images on the account axiom-images get # Print details from ~/.axiom/axiom.sjon axiom-images rm axiom-default-1709878237 # Delete image named axiom-default-1709878237 from the account axiom-images create # Start 'axiom-images' image creation wizard axiom-images create testy01 # Skip image creation wizard and instead create image from testy01 instance axiom-images select axiom-barebones-1709944106 # Select image named axiom-barebones-1709944106 to use with future 'axiom-init/axiom-fleet' Usage: ls (optional) List all images on the account 'axiom-images ls' get (optional) Print information about current account, equivalent to (cat ~/.axiom/axiom.json) 'axiom-images get' rm Specify an image by name to delete (must be an image name from 'axiom-images ls') create Kick off axiom-images creation wizard or specify an instance to create an image from 'axiom-images create $instance_name' select Select a new image to use for future 'axiom-init/axiom-fleet', replaces 'imageid' in ~/.axiom/axiom.json with new 'imageid' (must be an image name from 'axiom-images ls') --debug (optional) Enable debug mode (VERY VERBOSE!) --help (optional) Display this help menu ``` {% endcode %} {% code fullWidth="true" %} ```bash axiom-images ls # List available images axiom-images use # Replace image used for axiom-init/axiom-fleet with user provided image name axiom-images rm # Delete image by name ax image create # kick off image creation wizard. Make a snapshot of a running ax instance to use for future ax init/ax fleet ``` {% endcode %} *** ## ax init **Initialize a single instance** :seedling: {% code fullWidth="true" %} ``` Description: Initialize one axiom instance with differnet options, such as image, region, size and axiom deployment profiles Examples: axiom-init --run # provision instance with random name axiom-init --deploy desktop # provision instance with random name, then deploy axiom profile 'desktop' axiom-init testy01 # provision instance named testy01 axiom-init stok01 --region nyc3 --image axiom-default-1635920849 --size s-1vcpu-2gb --deploy desktop --shell Usage: string (optional) Name of the instance, supplied as a positional first argument --run (optional) Create one instance with random name --image Manually set the image to use (default is imageid in ~/.axiom/axiom.json) --region User specified region to use (default is region in ~/.axiom/axiom.json) --deploy Deploy a profile after initialization (e.g desktop, openvpn, bbrf, wireguard) --shell (optional) Connect to instance after initialization --size VM size to use (default is size in ~/.axiom/axiom.json) --no-select (optional) Dont select instance after initialization (default is to select instance) --debug (optional) Run with set -xv, warning: very verbose --help Display this help menu ``` {% endcode %} {% code fullWidth="true" %} ```bash ax init # Init ax init --run # Init with random instance name ax init --deploy=# Init and install deployment profile ``` {% endcode %} > the `--deploy` option allows you to install a deployment profile (stored in `~/.axiom/profiles/`) *** ## ax exec **Execute a command against one or many instances** :robot: {% code fullWidth="true" %} ``` Description: Evaluate shell one-liners or execute single commands on one or more instances in parallel Specify the fleet prefix, or let axiom use selected.conf by default (located in ~/.axiom/selected.conf) Execute command(s) from a detached tmux session on the remote instances Temporarily prevent axiom's SSH key regeneration and instead connect with a cached SSH config (default is ~/.axiom/.sshconfig) Examples: axiom-exec id # Execute command id across all instances currently selected.conf (located in ~/.axiom/selected.conf) axiom-exec ifconfig --fleet testy # Execute ifconfig on testy fleet, automatically select all instances in fleet testy axiom-exec 'sudo apt dist-upgrade -y' -q --cache --fleet OtherFleet --tmux MySession01 # Quietly execute command(s) inside a detacted tmux session on the remote instances with custom session name axiom-exec whoami -q --cache --sshconfig ~/.axiom/log/exec/axiom-exec+1234567890/sshconfig --fleet oldfleet --tmux # Specify the axiom SSH config to use (default is ~/.axiom/.sshconfig) Usage: required string Command(s) to run on the remote axiom instances, multiple commands can be wrapped in single or double quotes, but not required -f/--fleet/--file Fleet prefix to execute on (default is ~/.axiom/selected.conf). Automatic wildcard support. Alternatively, can be a list of instances from a file (-f/--fleet/--file myinstances.txt) -i/--instance Single instance to execute on --sshconfig (optional string) Path to axiom's SSH config (default is ~/.axiom/.sshconfig) -q/--quiet (optional) Disable progress bar, and reduce verbosity --debug (optional) Enable debug mode (VERY VERBOSE!) --cache (optional) Temporarily do not generate SSH config and instead connect with cached SSH config --logs (optional) Do not delete logs (logs will be stored in ~/.axiom/logs/exec/axiom-exec$TIMESTAMP) --quick (optional) A faster but less reliable execution --skip-preflight (optional) Do not automatically remove instances that cant be reached (default removes instances from the queue that cant be reached) --preflight-timeout Specifies the timeout (in seconds) used when connecting to the SSH server, instead of using the default 5 seconds --help Display this help menu ``` {% endcode %} {% code fullWidth="true" %} ```bash axiom-exec id # Execute command id across all instances currently selected.conf (located in ~/.axiom/selected.conf) axiom-exec ifconfig --fleet testy # Execute ifconfig on testy fleet. Automatically select all instances in fleet testy axiom-exec sleep "$(($RANDOM % 10))" "&& id &&" echo $HOSTNAME --fleet stok # Evaluate complex one-liners on fleet stok axiom-exec 'sudo apt dist-upgrade -y' -q --cache --fleet OtherFleet --tmux MySession01 # Quietly execute command(s) inside a detacted tmux session on the remote instances with custom session name axiom-exec whoami -q --cache --sshconfig ~/.axiom/log/exec/axiom-exec+1234567890/sshconfig --fleet oldfleet --tmux # Specify the axiom SSH config to use (default is ~/.axiom/.sshconfig) ``` {% endcode %} *** ## ax ssh **Connect to an instance** :link: {% code fullWidth="true" %} ``` Description: axiom-ssh dynamically generates axiom's SSH config based on your cloud inventory. axiom-ssh allows you to connect to your axiom instances over their public or private network interface. axiom-ssh can drop you right into a freshly created tmux session on the remote instance, and can be used to attach to a preexisting tmux session. All additional SSH args (such as port-forwards) are passed to SSH binary. Examples: axiom-ssh testy01 # SSH into instance testy01 axiom-ssh testy01 --tmux mysession1 # SSH into instance testy01 and spawn or attach to tmux session named mysession1 axiom-ssh --just-generate # Always populate axiom's ssh config (located in ~/.axiom/.sshconfig) with public Ip details axiom-ssh --just-generate private # Always populate axiom's ssh config (located in ~/.axiom/.sshconfig) with private Ip details axiom-ssh --just-generate cache # Permanently lock/cache axiom's ssh config so it never regenerates (to revert run axiom-ssh --just-generate) axiom-ssh testy01 -L 8080:127.0.0.1:8080 -D 4040 # Port-forward 8080 to local port 8080 and dynamically port foward port 4040 to testy01 Usage: required string Instance name supplied as a positional first argument --mosh/-m (optional) Connect with mosh --just-generate (optional) Specify when to generate the SSH config file and what IPs to use. Options are public, private, cache/lock ( default is public ) --tmux (optional) Connect to your instance and start new tmux session or connect to one (default session name is 'main') --tmux-attach/-t (optional) Only attach to tmux session if session name exists. If tmux session doesnt already exist, this will error --cache (optional) Temporarily do not generate SSH config and instead connect with cached SSH config --debug (optional) Enable debug mode (VERY VERBOSE!) --help (optional) Display this help menu All additional SSH args are passed to SSH. If you want additional arguments supplied to your command, simply append them to the command! example: axiom-ssh -L 8080:127.0.0.1:8080 -D 4040 ``` {% endcode %} {% code fullWidth="true" %} ```bash axiom-ssh #connects to list initialized instance axiom-ssh axiom-ssh --tmux axiom-ssh -m -t=main-15 axiom-ssh -L 8080:127.0.0.1:8080 -D 4040 # All additional SSH args are passed to SSH axiom-ssh --cache # Don't generate ssh config, just connect with cache axiom-ssh --just-generate # Will populate the SSH config at ~/.axiom/.sshconfig with public IPs instances on the account axiom-ssh --just-generate private # Will populate the SSH config at ~/.axiom/.sshconfig with private IPs instances on the account axiom-ssh --just-generate cache # Will permanently avoid regenerating the SSH configs. To revert run: axiom-ssh --just-generate public or just axiom-ssh --just-generate ``` {% endcode %} *** ## ax sizes **Change the default size (CPU/RAM) to use when creating instances and fleets** :chart\_with\_upwards\_trend: {% code fullWidth="true" %} ``` Description: Manage the default instance size used by 'axiom-init' or 'axiom-fleet' with 'axiom-sizes'! List all sizes the cloud provider has with 'axiom-sizes ls' and select a new one with 'axiom-sizes select $new_size' All this does is replaces the .default_size in ~/.axiom/axiom.json with a new size Examples: axiom-sizes ls # List all sizes the cloud provider offers axiom-sizes select Standard_F2 # Set a new default instance size to use with future 'axiom-init/axiom-fleet' axiom-sizes select 2,8192 # For ibm cloud, supply comma separated ram,cpu or cpu,ram values axiom-sizes default # Restore instance size to the default Usage: ls (optional) List all available instance sizes 'axiom-images ls' get (optional) Print information about currently used instance size, equivalent to (cat ~/.axiom/axiom.json) 'axiom-sizes get' select Select a new instance size to use for future 'axiom-init/axiom-fleet', replaces 'default_size' in ~/.axiom/axiom.json with new 'default_size' (must be valid instance size from 'ax sizes ls') default (optional) Restore the default instance size 'axiom-sizes default' --debug (optional) Enable debug mode (VERY VERBOSE!) --help (optional) Display this help menu ``` {% endcode %} ## ax sync **Make a copy of an instances home directory** :luggage: {% code fullWidth="true" %} ``` Usage of axiom-sync Description: Make a copy of an instances home directoy and sync to your local filesystem. Example Usage: axiom-sync instance01 instance02 string Instance name you wish to backup --help (optional) Displays this menu ``` {% endcode %} {% code fullWidth="true" %} ```bash axiom-sync # Backup the home directory of an initialized instance to the local filesystem ``` {% endcode %} > This allows you to download a copy of everything in an axiom instance to the local filesystem *** ## ax power **Power on, off and reboot instances and fleets with axiom-power.** :electric\_plug: {% code fullWidth="true" %} ``` Usage: axiom-power on 'rez\*' #turns on instances starting with 'rez' axiom-power off '\*' #turns off all instances Examples: on Power on instance by instance name off Power off instance by instance name reboot Reboot instance by instance name help | --help | -h Print this help menu ``` {% endcode %} {% code fullWidth="true" %} ```bash axiom-power on 'rez\*' # Power on all instances in fleet named rez axiom-power off 'rez\*' # Power off rez fleet axiom-power reboot 'rez\*' # Reboot rez fleet ``` {% endcode %} *** ## ax ls **List all instances on the account** {% code fullWidth="true" %} ``` ax ls ``` {% endcode %} *** ## ax rm **Remove one or more axiom instances** :x: {% code fullWidth="true" %} ```bash axiom-rm # Delete box by specifying the name axiom-rm -f # Forcibly delete box by specifying the axiom-rm \* # Delete all instances that start with . You must escape the asterisk. axiom-rm \* -f # Forcibly delete all instances that start with . You must escape the asterisk. axiom-rm '\*' # Delete all instances on the account. Must be wrapped in single quote and escape the asterisk. axiom-rm '\*' -f # Forcibly delete all instances on the account. Must be wrapped in single quote and escape the asterisk. ``` {% endcode %} *** ## ax region **Switch to a new region** :compass: {% code fullWidth="true" %} ```bash axiom-region ls # lists regions axiom-region select # select region axiom-region select ams2 ``` {% endcode %} *** ## ax account-setup **Choose your cloud provider and setup your ax profile (\~./axiom/accounts/$profile.json)** {% code fullWidth="true" %} ``` ax account-setup ``` {% endcode %} *** ## ax account **Manage user accounts** :name\_badge: {% code fullWidth="true" %} ```bash axiom-account-setup # Setup a new account axiom-account # No args, list available accounts axiom-account # Select/Switch to the specified account ``` {% endcode %} {% code fullWidth="true" %} ``` ax account # list all account profiles ax account do # switch to profile DO. Profile must be valid ax json in ~/.axiom/accounts/$profile.json ``` {% endcode %} *** ## ax scp **Copy files to and from instances. Optionally, split a file and distribute to all hosts.** :arrow\_heading\_up: {% code fullWidth="true" %} ``` Description: axiom-scp supports downloading and uploading files or folders to fleets of axiom instance or single instances axiom-scp optionally allows splitting a local file across a fleet of instances axiom-scp supports globbing to expand the instance names from a fleet prefix when the literal string '$name' is in the command, axiom-scp automatically interpolates the instances name Examples: axiom-scp mytemplates/ 'myfleet*':/home/op/custom-templates # Upload a local folder to all instances in myfleet axiom-scp custom-wordlist.txt 'myfleet*':/home/op/custom-wordlist.txt # Upload local file to all instances in myfleet axiom-scp custom-wordlist.txt 'myfleet*':/home/op/custom-wordlist.txt --split # Split and upload local wordlist to all instances in myfleet axiom-scp testy01:/home/op/download-file.txt download-file.txt # Download file from a single instance named testy01 axiom-scp 'testy*':/home/op/results.txt '~/home/localuser/folder/$name.txt' # Download file from all instances in testy fleet, when using '$name', it must be wrapped in single quotes and gets interpolated from the instance name Usage: --split (optional) Split the local file depending on the size of the fleet, equally distribute the file across the fleet --sshconfig (optional) Path of custom SSH config file to use (default uses sshconfig in ~/.axiom/.sshconfig) --cache (optional) Temporarily do not generate SSH config and instead connect with cached SSH config --debug (optional) Enable debug mode (VERY VERBOSE!) --help (optional) Display this help menu ``` {% endcode %} > Copy a remote file from all instances in myfleet to local file. `'$name'` must be wrapped single quotes. `'$name'` is a required literal string and gets interpolated from the instance name. {% code fullWidth="true" %} ``` axiom-scp 'myfleet*':/home/op/myfile.txt '~/local/folder/$name.txt' ``` {% endcode %} > Copy a remote folder from all instances in myfleet to local folder. `'$name'` must be wrapped single quotes. `'$name'` is a required literal string and gets interpolated from the instance name. {% code fullWidth="true" %} ``` axiom-scp 'myfleet*':/home/op/myfile/ '~/local/folder/$name' ``` {% endcode %} > Copy a remote file from one instance 'myfleet05' to a local file {% code fullWidth="true" %} ``` axiom-scp myfleet05:/home/op/myfile-from-myfleet05.txt '~/local/folder/myfile-from-myfleet05.txt' ``` {% endcode %} > Copy a local file to all instances in myfleet, for example uploading a custom wordlist {% code fullWidth="true" %} ``` axiom-scp myfile.txt 'myfleet*':/home/op/myfile.txt ``` {% endcode %} > Copy a local folder to all instances in myfleet, for example uploading a folder of custom nuclei templates {% code fullWidth="true" %} ``` axiom-scp mytemplates/ 'myfleet*':/home/op/custom-templates ``` {% endcode %} > Split and upload local wordlist to all instances in myfleet {% code fullWidth="true" %} ``` axiom-scp custom-wordlist.txt 'myfleet*':/home/op/custom-wordlist.txt --split ``` {% endcode %} *** ## ax select **Select what instances to use for exec, scp and fleet** {% code fullWidth="true" %} ``` axiom-select '' axiom-select 'testy\*' # Testy is an example of a fleet ``` {% endcode %} *** ## ax deploy **Deploy a profile** :mechanical\_arm: {% code fullWidth="true" %} ``` Usage of axiom-deploy Example Usage: axiom-deploy openvpn jerry01 Name of the instance, supplied as a positional first argument --cache Use SSH cache (works if recently interacted with) --remove Uninstall the profile --list List profiles --help Display this help menu ``` {% endcode %} 
axiom-deploy desktop <instance name> # Install desktop on initialized instance  
axiom-deploy covenant <instance name> # Install covenant on initialized instance  
ax deploy --list # list all available deployment profiles
> All profiles can be found in `~/.axiom/profiles` # Bring Your Own Provisioner Ax comes with several Packer Provisioners ([JSON](https://github.com/attacksurge/ax/tree/master/images/json/provisioners) or [HCL](https://github.com/attacksurge/ax/tree/master/images/pkr.hcl/provisioners)), to help you get up and running quickly. However, once you become comfortable with the system, it is highly recommended to build your own Provisioner. This reduces the risk of a successful supply chain attack against the [Default](https://github.com/attacksurge/ax/blob/master/images/pkr.hcl/provisioners/default.pkr.hcl) (and other) Provisioners. {% hint style="danger" %} **Supply Chain Security:** AttackSurge is cautious about what tools and dependencies are installed through the Default Provisioner to minimize risks associated with supply chain attacks. We have adopted Docker modules for many Python scripts requiring software dependencies, which helps isolate and manage these dependencies more securely. However, this approach does come with trade-offs, such as increased image size, which can lead to slower build and provisioning times. For Go tools, we typically use `go install` to pull in the latest versions directly to the instance's environment. While this method reduces some risks by sourcing dependencies directly from their original repositories, it is not foolproof. There's still a potential risk that a tool or one of its dependencies could pull in release files or other opaque sources, bypassing the visibility and security of a full Git commit history. This could allow malicious code to be introduced without detection. Despite these precautions, no system is entirely immune to supply chain attacks. The tools we install, or their dependencies, could still be compromised if a trusted developer's account is hacked, or if a developer unknowingly includes a malicious package. Such scenarios could lead to the introduction of harmful code, potentially compromising the instances. Importantly, any compromise of a [JSON](https://github.com/attacksurge/ax/tree/master/images/json/provisioners) or [HCL](https://github.com/attacksurge/ax/tree/master/images/pkr.hcl/provisioners) Provisioner would be contained within disposable instances. The [Ax Controller](/overview/ax-controller), which stores cloud account credentials, remains isolated and secure from these instances, unless an entirely separate vulnerability is discovered that specifically targets the Ax Controller. Given these challenges, one significant benefit of bringing your own Provisioner is the ability to tailor the security measures and controls to your specific needs. {% endhint %} To that point, its highly recommenced to create your own Provisioner. To quickly create your own Provisioner, we recommend using the [Barebones Provisioner ](https://github.com/attacksurge/ax/blob/master/images/json/provisioners/default.json)as a template. This Provisioner installs the following tools via [apt get](https://github.com/attacksurge/ax/blob/master/images/provisioners/barebones.json#L24C27-L24C179). ``` fail2ban ufw net-tools zsh zsh-syntax-highlighting zsh-autosuggestions jq build-essential python3-pip unzip git p7zip libpcap-dev rubygems ruby-dev grc ``` Oh My Zsh is also installed, followed by Golang, Docker, Interlace (required for [One-Shot Modules](/fundamentals/scans/modules/adding-one-shot-modules)) and nmap. We are confident that this approach substantially reduces the risk, although this Provisioner (Barebones) doesn't come with many pre-installed tools. {% hint style="info" %} **Custom Provisioners:** [JSON](https://github.com/attacksurge/ax/tree/master/images/json/provisioners) Provisioners need to be stored in `~/.axiom/images/json/provisioners/` and needs to end with `.json` [HCL](https://github.com/attacksurge/ax/tree/master/images/pkr.hcl/provisioners) Provisioners need to be stored in `~/.axiom/images/pkr.hcl/provisioners/` and needs to end with `.pkr.hcl` {% endhint %} One easy way to add extra tools is to copy and paste select lines from the [Default](https://github.com/attacksurge/ax/blob/master/images/json/provisioners/default.json) or [Extras](https://github.com/attacksurge/ax/blob/master/images/json/provisioners/extras.json) Provisioners and add them to a copy of the Barebones Provisioner. It is recommended to add them to any line after the [Optimizing SSH Connections](https://github.com/attacksurge/ax/blob/master/images/provisioners/barebones.json#L76) section.

cp barebones.json new.json

nano new.json

Now that we have a new Provisioner with some our of favorite tools, SecList and Trickest DNS resolvers, we can run `ax build --setup` , select `custom` and enter the name of your new Provisioner.

ax build --setup

Or my personal preference just type `ax build $name-of-new-Provisioner`

ax build new

# Fleets Spin up fleets of axiom instances in one or multiple regions. Specify the name of your fleet (fleet prefix) or have axiom choose for you. ## ax fleet **Initialize a fleet** :rocket:
axiom-fleet usage ``` Description: Spin up fleets of axiom instances in one or multiple regions. Specify the name of your fleet (fleet prefix) or have axiom choose for you. Examples: axiom-fleet ctbb # Spin up 3 instances named ctbb01 ctbb02 and ctbb03 axiom-fleet -i 10 # Spin up 10 instances with random fleet prefix axiom-fleet jerry -i 25 --regions dal13,lon06,fra05 # Spin up 25 instances named jerry01 to jerry25 using Round-robin region distribution Usage: (optional) Name of fleet prefix (default is random fleet prefix) -i/--instances The number of instances to spin up -r/--regions (optional) Supply comma-separated regions to cycle through (default is region in ~/.axiom/axiom.json) --image (optional) Manually set the image to use (default is imageid in ~/.axiom/axiom.json) --debug (optional) Run with set -xv, warning: very verbose --help (optional) Display this help menu ```
```bash axiom-fleet -i 13 # Initialize a fleet, name it randomly axiom-fleet testy -i 8 # Initialize a fleet named 'testy', instances will be named, testy01, test02 etc axiom-fleet testy -i 10 --regions nyc1,lon1,ams3,fra1 # Initialize a fleet using round-robin region distribution ``` # Scans Scanning using a fleet of Ax instances
{% hint style="info" %} **Modules**: For a comprehensive overview of Ax scan modules, see [Modules](/fundamentals/scans/modules) {% endhint %} `ax scan` is an amalgamation of the various Ax scripts (`~/.axiom/interact`) and operations. Its designed to provide an easy way to distribute any binary or script. The only requirements are: * The tool you wish to distribute needs to be installed on the remote instances. * On the [`ax controller`](/overview/ax-controller), use one of our [preexisting](https://github.com/attacksurge/ax/tree/master/modules) modules or create your own. The [module](/fundamentals/scans/modules) specifies the command to execute on the remote instances in parallel (must be a valid JSON file in `~/.axiom/modules`) * When creating custom [modules](/fundamentals/scans/modules), make sure to add the appropriate [extension](/fundamentals/scans/modules/merging-and-module-extensions) to the module's `ext` key:value pair. This tells `ax scan` how to download and [merge](/fundamentals/scans/modules/merging-and-module-extensions) the results. * Spin-up some instances beforehand using `ax fleet` and make sure they are selected (`ax select '\*'`) * Optionally use `ax scan ... --spinup $N` argument to specify how many instance to spin up at runtime. * Finally, execute the appropriate `ax scan` command, specifying the input file to distribute and the [module](/fundamentals/scans/modules) you want to execute across the fleet `ax scan my-targets.txt -m ffuf` {% hint style="info" %} **Source Code:** `ax scan` is written in bash making it very easy to review. For a detailed step-by-step walk-though of how `ax scan` works under the hood, its highly recommended to read the comments in the [source code](https://github.com/attacksurge/ax/blob/master/interact/axiom-scan)! {% endhint %} With `ax scan`, every instance executes the same command, specified in the [module](/fundamentals/scans/modules). Ax scan splits the user-provided target list (e.g., a list of IPs) into equal parts per instance. For example, if you have a target list of 10 IPs and 5 instances selected, the target list is divided into 5 equal parts (2 targets per instance). Each target list is uploaded to the appropriate instance using `axiom-scp`. To prepare the instances before the actual scan is executed, `ax scan` creates a unique folder on all remote instances to store the data needed for that particular scan invocation (`/home/op/scan/$module+timestamp`). A unique tmux session is created on each remote instance to handle the execution. If you `ax ssh` into the instance, you can attach to the tmux session (`tmux a -t $module+$timestamp`) in real-time (results are also automatically streamed from each remote instance and returned to the terminal). Locally, `ax scan` creates a separate local scan working directory for each scan invocation, located `~/.axiom/tmp/$module+timestamp`. Optional user provided command-line arguments are passed to the module (extra args) and are combined with the commands in the module. The final command is stored in a local file and then uploaded to every instance participating in the scan. Some of the data stored in the local scan working directory includes the command to run on the instances, the path of the temporary ssh sockets used for the scan, the axiom `sshconfig`, the input file, the results and the status of each scanner, located `~/.axiom/tmp/$module+timestamp`. Some logging operations are executed on the remote instances to redirect `stdout` and `stderr` to a file in the instances remote scan working directory. These files are collectively tailed across each instance and streamed to the [ax contoller](/overview/ax-controller)'s terminal in real-time. When any particular instance is finished with its portion of the total scan, ax creates a `$(hostname)` file in the instance's remote scanning working directory. During the scan, Ax checks for each `$(hostname)` file to know that part of the scan has completed. Once all instances have created their `$(hostname)`, or if Ax can no longer communicate to ALL of instances in the selected fleet or if `--max-runtime` is exceeded, the scan is considered complete and merging starts. Scan results are downloaded periodically during the scan and once again after the scan completes, just in case. ## ax scan Modules must be located in [`~/.axiom/modules/`](https://github.com/attacksurge/ax/tree/master/modules). For more information about modules, see [modules](/fundamentals/scans/modules). {% code fullWidth="true" %} ``` axiom-scan provides easy distribution of arbitrary binaries and scripts. axiom-scan optionally splits user-provided input files (target lists), and wordlists and uploads them to a unique scan working directory on the remote instance. axiom-scan combines user-provided command-line arguments with commands in the module (~/.axiom/modules) and executes the final command on the remote instance. axiom-scan downloads and merges scan output in a variety of different formats, specified by the extension in the module (dir, txt, oG, csv, xml, jsonl, none). individual scanning operations are executed from a detacted tmux session ($module+$timestamp) inside a unique scan working directory (/home/op/scan/$module+$timestamp) on the remote instances. Usage: axiom-scan inputfile.txt -m ffuf -w /home/op/wordlist-on-remote-instance axiom-scan inputfile.txt -m ffuf -wL /home/localuser/local-wordlist-to-upload axiom-scan inputfile.txt -m ffuf -wD /home/localuser/local-wordlist-to-split-and-upload axiom-scan inputfile.txt -m nuclei --remote-folder /home/op/nuclei-templates-on-remote-instances -o outputfile.txt axiom-scan inputfile.txt -m nuclei --local-folder /home/localuser/local-custom-nuclei-template-folder-to-upload/ -o outputfile.txt axiom-scan inputfile.txt -m nuclei --local-config /home/localuser/local-custom-nuclei-config-file-to-upload.yaml -o outputfile.txt --anew axiom-scan inputfile.txt -m gowitness -oD screenshots-folder --spinup 10 axiom-scan inputfile.txt -m nmapx -p- -sV -T4 -v --open -oA nampx-scan --spinup 100 --rm-when-done --regions dal13,lon06,fra05,sjc04 Flags: INPUT: string[] required positional first argument must always be an input file, this can be a list of URLs, IPs, hostnames, etc --dont-shuffle do not randomize input file before uploading (default is to randomize) --dont-split do not split input file, upload entire input file to every instance (default is to split the input file) --expand-cidr automatically expand any subnet in the input file (default does not expand subnets) MODULE: -m string[] the axiom-scan module to use with the scan (must be a JSON file in ~/.axiom/modules) --list print all available modules located in ~/.axiom/modules WORDLIST: -w string[] replace _wordlist_ in module with user-provided wordlist (must be a path to a remote wordlist) -wD,--distribute-wordlist string[] replace _wordlist_ in module with user-provided local wordlist to split and upload (default does not split the wordlist) -wL,--local-wordlist string[] replace _wordlist_ in module with user-provided local wordlist (must be a path to a local wordlist) FOLDER: --remote-folder string[] replace _folder_ in module with user-provided remote folder (must be a path to a remote folder) --local-folder string[] replace _folder_ in module with user-provided local folder to upload (must be a path to a local folder) CONFIGURATIONS: --remote-config string[] replace _config_ in module with user-provided configuration file (must be a configuration file on the remote instances) --local-config string[] replace _config_ in module with user-provided local configuration file to upload (must be a local configuration file) ONE-SHOT: --disable-oneshot by default, if a module contains the string _target_ or _safe-target_ it is executed as a one-shot module. Use this flag to force disable --unsafe for one-shot modules only, axiom will transparently replace _target_ with _safe-target_ in modules at runtime, use this flag to force disable --track-finished for one-shot modules only, add this flag to track finished targets (creates a file in the remote scan working directory named finished.txt) --threads int[] specify the number of threads to use with one-shot modules (default uses "threads": $N key:value pair in the module)" OPTIMIZATIONS: --upload string[] before the scan, upload a file to the unique scan working directory (/home/op/scan/$module+$timestamp) on remote instances (must be a path to a local file) --download string[] after the scan, download a file from the unique scan working directory (/home/op/scan/$module+$timestamp) on remote instances (must be a path to a remote file) --max-runtime DURATION[] kill scan if still running after DURATION, DURATION is a floating point number with an required suffix: 'm' for minutes, 'h' for hours or 'd' for days --preflight-timeout int[] specifies the timeout (in seconds) used when connecting to the SSH server, instead of using the default 15 seconds --skip-preflight do not automatically remove instances that can not be reached (default removes instances from the queue that can not be reached) --anew pipe the output to anew before creating the final output file (also requires extension "ext":"txt", "ext":"oG" or "ext":"csv" to be in the module) OUTPUT: -o string[] output as default (the first ext mentioned in the module) -oT/-txt string[] output as text (must also be supplied in the module using "ext":"txt") -oD/-oA string[] output as directory (must also be supplied in the module using "ext":"dir" or "ext":"") -oG string[] output as greppable, merge and sort unique (must also be supplied in the module using "ext":"oG") -oJ string[] output as json lines, newline characters are used to delimit JSON data (must also be supplied in the module using "ext":"jsonl") -oX string[] output as XML/HTML (supported for nmap and masscan)(must also be supplied in the module using "ext":"xml") -csv string [] output as csv, extract csv header, merge and sort unique (must also be supplied in the module using "ext":"csv") -none string [] do not attempt to merge the output at all (must also be supplied in the module using "ext":"none") --quiet do not display findings to terminal --rm-logs delete remote and local logs after scan completes, except for the unmered output files in ~/.axiom/logs/$module+$timestamp/output --no-logs do not store any logs at all, do not tail terminal output. Delete all logs even the unmerged output files in ~/.axiom/logs/$module+$timestamp/output --stdout only display stdout results to terminal (default displays stdout and stderr to the terminal) FLEET: --custom-ssh string[] path to custom SSH config file (default is located at ~/.axiom/.sshconfig) --cache do not regenerate SSH config prior to scan, instead use cached config (located at ~/.axiom/.sshconfig) --fleet string[] supply fleet prefix to use (default uses instances in ~/.axiom/selected.conf) --regions string[] round-robin region distribution using comma-separated regions to cycle through (default is region in ~/.axiom/axiom.json) --rm-when-done delete the instance when finished with its job (does not wait for all instances to complete) --shutdown-when-done shutdown the instance when finished with its job (does not wait for all instances to complete) --spinup int[] number of instances to spin up prior to scanning (default uses instances in ~/.axiom/selected.conf) DEBUG: --debug run with set -xv, warning: very verbose (use with --cache for less output) EXTRA ARGS: string[] supply additional arguments to be passed to the module --extra-args string[] explicitly define extra args to be passed to the module, must be wrapped single or double quotes (depending on intended variable expansion) ``` {% endcode %} {% code fullWidth="true" %} ```bash axiom-select 'fleet*' # fleets should be already selected, but just in case, select can be a good idea # Format axiom-scan -m -o # Examples axiom-scan roots.txt -m subfinder -o subfinder.txt # run subfinder against all roots axiom-scan subfinder.txt -m dnsx -o dnsx.txt # run dnsx against all subfinder results axiom-scan dnsx.txt -m httpx -o httpx.txt # run httpx against all dnsx results axiom-scan httpx.txt -m gowitness -o screenshots-directory # run gowitness against all httpx results axiom-scan httpx.txt -m nuclei -o nuclei.txt # run nuclei against all httpx results axiom-scan httpx.txt -m ffuf -o ffuf.txt # run ffuf against all httpx results axiom-scan ips.txt -m nmap -oG portscan.txt # run nmap, output as greppable axiom-scan ips.txt -m nmap -oX portscan # Output and merge XMLs (this also creates an HTLM report) axiom-scan ips.txt -m nmap -p- -sV -T4 -v --open -oA nampx-scan --spinup 10 # run nmap, pass extra_args to nmap binary, output to a directory containing text, XML and Greppable results, spin up 10 instances axiom-scan ips.txt -m masscan -oG masscan.txt # Run masscan, output as greppable ``` {% endcode %} # Modules All `ax scan` modules must be stored in [`~/.axiom/modules`](https://github.com/attacksurge/ax/tree/master/modules). To create custom modules, see [**Adding Simple Modules**](/fundamentals/scans/modules/adding-simple-modules) and [**Adding One-Shot Modules**](/fundamentals/scans/modules/adding-one-shot-modules). [Simple Modules](/fundamentals/scans/modules/adding-simple-modules) are bash commands defined within JSON files. `ax scan` can execute any bash command you supply in the module, including loops and sub-shells, as long as it's valid JSON. [One-Shot Modules](/fundamentals/scans/modules/adding-one-shot-modules) allow you to easily thread any binary or script. If the command in the module contains the string `_target_` or `_safe-target_`, `ax scan` automatically executes the module as a One-Shot Module (unless `--disable-oneshot` is used). `_target_` is replaced with the expanded target list that the current thread is running against. When creating custom modules, make sure to understand how [**Merging and** **Module Extensions**](/fundamentals/scans/modules/merging-and-module-extensions) work. These features tell `ax scan` how to download and merge scan results in various formats. When supplying extra command-line arguments to `ax scan` (also known as `extra_args`), these arguments are combined with the commands in the module. This effectively passes the extra arguments to the binary or script you are distributing at run-time. The final command is executed on all instances in parallel. To quickly familiarize yourself with the default modules included in Ax, simply run `ax scan --list`.

modules with long commands were truncated in the above screenshot for readability

Ax scan has some optional variable replacements, simplifying the process of dynamically replacing some variables at runtime, such as wordlists, config files, and folder paths. ## Variable Replacements The following variables will be replaced in both Simple Modules and One-Shot Modules at runtime:
VariableReplacement and Argument
_wordlist_
  • A wordlist on the remote instances (-w).
  • A local wordlist to upload before the scan (-wL/--local-wordlist)
  • A local wordlist to split and upload before the scan (-wD/--distribute-wordlist
_config_
  • A file on the remote instances (--remote-config)
  • A local file to upload to all instances before the scan (--local-config)
_folder_
  • A folder on the remote instances (--remote-folder)
  • A local folder to upload to all instances (--nuclei-templates or --local-folder)
The following variables will only be replaced in [One-Shot](/fundamentals/scans/modules/adding-one-shot-modules) modules at runtime:
VariableReplacement
_target_Replaced with the expanded target list that the current thread is running against
_cleantarget_Replaced with target cleaned from http:// or https://
_safe-target_Replaced with target automatically quoting for commands, stopping subcommands running
{% hint style="info" %} **Safe Target**: By default the string `_target_` in the module is automatically replaced with `_safe-target_`, unless the `ax scan` option `--unsafe` is used. {% endhint %} # Adding Simple Modules You can install tools either before or after spinning up your fleet. If you already have a fleet, simply execute `ax exec`. This command also works for updates. For example, to update Nuclei templates, run `ax exec nuclei -update-templates`. To install a package with apt-get, execute `ax exec sudo apt-get install [package-name] -y`. Adding tools to the packer build is only slightly more complicated. First, add the installation command(s) to one of the [provisioner](https://github.com/attacksurge/ax/tree/master/images/provisioners) files under the inline object. The commands must be non-interactive, wrapped in double quotes, and end with a comma for all lines except the last (i.e it needs to be valid JSON). If you need an additional set of double quotes, make sure to escape them. Next, run `ax build` to create the new packer image with your tools installed. Creating a module is also easy. Let's use [dnsx](https://github.com/attacksurge/ax/blob/master/modules/dnsx.json) as an example. Dnsx is a prime choice because it outputs to plaintext (expressed [here](https://github.com/attacksurge/ax/blob/master/modules/dnsx.json#L3)) which is simple to handle, and the results are returned one line per target without needing to be in a specific order, making them easy to merge. ``` [ { "command": "cat input | /usr/bin/dnsx -silent -r /home/op/lists/resolvers.txt -o output", "ext": "txt" } ] ``` With ax scan, every instance executes the same command specified in the module. Ax scan splits the user-provided target list (e.g., a list of IPs) into equal parts per instance. For example, if you have 5 instances, the target list is divided into 5 equal parts and uploaded to the appropriate instance. During this process, all files are renamed to "input". Each instance uses its "input" file, which is one portion of the total target list. This is crucial because all modules must include "input" for ax scan to locate the target list. Just as the module must have a file named "input", it must also have a file named "output" for the results. To download results from each instance, ax scan uses rsync via SSH to retrieve a file named "output" from each instance. The output files are then merged into one and renamed based on a user-provided argument. For tools that only output to STDOUT and not to a file, avoid using `>` to redirect the output. Instead, pipe the STDOUT to `tee` and save it to a file named "output" using `tee output`. Here’s a breakdown of the example command: ``` "cat input | /usr/bin/dnsx -silent -r /home/op/lists/resolvers.txt -o output" ``` * `cat input`: Reads the portion of the target list assigned to this instance. * `/usr/bin/dnsx -silent -r /home/op/lists/resolvers.txt`: Runs the dnsx binary with the specified resolver list. * `-o output`: Writes the results to a file named "output". * `"ext": "txt"`: Specifies that the output file extension is "txt". # Adding One-Shot Modules Ax supports two types of scan modules: [Simple Modules](/fundamentals/scans/modules/adding-simple-modules) and One-Shot Modules. If a module contains the string `_target_` or `_safe-target_`, ax scan will execute it as a One-Shot Module. One-Shot Modules utilize [Interlace](https://github.com/codingo/Interlace) to convert single-threaded command-line applications into fast, multi-threaded applications. Specifically, ax scan uses Interlace (created by [codingo](https://x.com/codingo_) and [sml555](https://twitter.com/sml555_)) to manage threading for any binary or script. Here's an example of a One-Shot Module and its benefits: ``` [ { "command": "/home/op/go/bin/ffuf -w _wordlist_ -u _target_/FUZZ -of csv -o output/_cleantarget_ -ac", "wordlist": "/home/op/lists/seclists/Discovery/Web-Content/big.txt", "ext": "csv", "threads": "1" } ] ``` Some tools only accept one target at a time rather than a list of targets from a file. This is a prime example of why One-Shot Modules are beneficial. Typically, ax scan splits a target list (e.g., IPs or URLs) and uploads parts to each instance in the fleet, renaming all parts to "input". Instead of using a One-Shot Module, you could use a Simple Module with a bash loop, like this: {% hint style="info" %} **Extensions:** While One-Shot modules can use any [module extension](/fundamentals/scans/modules/merging-and-module-extensions) (e.g., `"ext": "csv"` in the above module), every One-Shot `"command:"` must output to a directory named `output`. In the above module, the output is `output/_cleantarget_`. The output directory on the remote instance (`/home/op/scan/$module+$timestamp/output`) is automatically created for you when using One-Shot modules. {% endhint %} ``` [ { "command": "for i in $(cat input); do ffuf -w _wordlist_ -u $i/FUZZ -of csv -o output/$(echo $i | tr -d ':' | tr -d '/') -ac; done", "wordlist": "/home/op/lists/seclists/Discovery/Web-Content/big.txt", "ext": "dir" } ] ``` The above command is valid syntax, and `ax scan` can execute any bash command you supply, including loops and sub-shells (as long as its valid JSON). However, notice that the output requires cleaning to remove colons and forward slashes from the HTTPS scheme, as files can't contain these characters. This method also doesn't support easy threading. This is where Interlace is useful. By integrating Interlace, we have enabled easy threading for Ax modules. To specify the number of threads, simply add the desired number next to "threads" in the JSON object. # Merging and Module Extensions The `ax scan` tool supports downloading and merging scan outputs in various formats, determined by the extension specified in the module (e.g., txt, oG, xml, dir, none, csv, and, jsonl) and the output argument passed to `ax scan` at runtime. The specified extension guides how `ax scan` will merge the results. Let's consider the [nmap module](https://github.com/attacksurge/ax/blob/master/modules/nmap.json) as an example: ``` [ { "command": "sudo nmap -iL input -oN output", "ext": "txt" }, { "command": "sudo nmap -iL input -oG output", "ext": "oG" }, { "command": "sudo nmap -iL input -oX output", "ext": "xml" }, { "command": "sudo nmap -iL input -oA output/output", "ext": "dir" }, { "command": "mkdir output ; sudo nmap -iL input -oA output/output", "ext": "none" } ] ``` The "default" extension is always the first one mentioned in the module. In this case, the default is "txt" since `"ext": "txt"` is the first listed. If no output argument is specified, `ax scan` uses the first command and extension in the JSON object and assigns a unique name for the output file. ``` ax scan input -m nmap --quiet && cat /home/user/scan+1722134430 ```
If you add the output argument `-o`, you can specify your own output filename. However, even when using `-o`, `ax scan` will still use the first JSON object in the module by default. ``` ax scan input -m nmap --quiet -o my-custom-filename.txt ```
### txt But what if `"ext": "txt"` wasn't the first JSON object in the module, but you still wanted to use it? You could explicitly tell `ax scan` to use the JSON object with `"ext": "txt"` (and corresponding module command) by specifying the appropriate output argument in the `ax scan` command at runtime. For text, you can use either `-oT` or `-txt` as the `ax scan` output argument. ``` ax scan input -m nmap --quiet -oT my-explicit-text-output.txt ``` ``` [ { "command": "sudo nmap -iL input -oN output", "ext": "txt" }, ..snip.. ```
### oG (grepable) Outputting as grepable is very similar to `"ext": "txt"`, the only difference is that `"ext": "oG"` sorts unique (`sort -u`). To use any JSON object in the module along with the corresponding command and extension, specify the correct output argument in the `ax scan` command. For example, to output in grepable format with `"ext": "oG"`, use `-oG` in the `ax scan` command at runtime. Here's how to do it: For example: ``` ax scan input -m nmap --quiet -oG my-grepable-output.txt ``` The above `ax scan` command will use the corresponding JSON object's command and extension in the module, which in this case is: ``` ..snip.. { "command": "sudo nmap -iL input -oG output", "ext": "oG" }, ..snip.. ``` The `"command":.."` key in the JSON key:value pair must output to the appropriate file type (`"command":" ...-oG output"`). The extension must also be specified in the object's `"ext"` value (in this case `"ext": "oG"`). Finally, the `ax scan` command needs to include the appropriate output argument so it knows which extension (and command) to use: ``` ax scan input -m nmap --quiet -oG my-grepable-output.txt ```
### xml Outputting as xml is supported for only nmap and masscan at the moment, and uses [nMap\_Merger.py](https://github.com/attacksurge/ax/blob/master/interact/nMap_Merger.py) to merge xmls. For XML output with `"ext": "xml"`, use the output argument `-oX` in the `ax scan` command ``` ..snip.. { "command": "sudo nmap -iL input -oX output", "ext": "xml" }, ..snip.. ``` ``` ax scan input -m nmap --quiet -oX my-xml-output.xml ```
### dir The directory extension `"ext": "dir"` behaves a bit differently compared to other extensions. When `ax scan` detects this extension, it automatically creates an additional directory in the remote instance's scan working directory (`mkdir /home/op/$module+$timestamp/output/`). This step prevents terminal errors that would occur if the additional output directory didn't exist. ``` ..snip.. { "command": "sudo nmap -iL input -oA output/output", "ext": "dir" }, ..snip.. ``` Outputting as a directory consolidates the results from each local log directory, named after the instances (`~/.axiom/logs/$module+$timestamp/output/$instance_names/`), into a single folder, effectively "flattening" the directory structure. To avoid overwriting files with the same filename during directory flattening, a `~$n~` suffix is added to each file. In this case, each instance saves three files (`output.xml`, `output.gnmap`, and `output.nmap`) using nmap's `-oA` option in the module. The added `~$n~` suffix ensures unique filenames during consolidation. To use the directory extension, you must also specify the appropriate `ax scan` output argument at runtime (`-oD`/`-oA`). `ax scan input -m nmap --quiet -oD my-directory-output/`
### none Outputting as none takes the results from each local log directory named after the instance `~/.axiom/logs/$module+$timestamp/output/$instances_names/` , and copies those directories to a user provided output directory (preserving the directory structure). This JSON object has the extension `"ext": "none"`. When using this extension, `ax scan` ignores merging locally and instead returns unmerged results. Notice the `mkdir output` in the module command. ``` ..snip.. { "command": "mkdir output ; sudo nmap -iL input -oA output/output", "ext": "none" } ] ``` This command outputs as XML, Normal, and Grepable formats, since its using nmap's `-oA`, and because we don’t automatically create an output directory when using `"ext": "none"` (like we do for `"ext": "dir"`), we need to create the output directory as part of the command. This is for cases where someone wants to use `"ext": "none"` but still output on the remote instances to a file instead of a directory. When the scan finishes, the local results are stored in subfolders named after the instances names. To use the `none` extension, you must also specify the appropriate `ax scan` output argument at runtime (`-none`). ``` ax scan input -m nmap --quiet -none my-unmerged-results-directory/ ```
{% hint style="info" %} If this is confusing, just use modules without multiple JSON objects. Make sure the `"command":..."` outputs to the correct`"ext":`, then just use the default output argument in the ax scan command (i.e:`ax scan ... -o my-results`) {% endhint %} ### csv Outputting as CSV, extracts the CSV header from the results and merges the rows (preserving the CSV header). {% hint style="warning" %} **One-Shot Module**: Warning the following example is a [One-Shot Module](/fundamentals/scans/modules/adding-one-shot-modules). While One-Shot modules can use any [module extension](/fundamentals/scans/modules/merging-and-module-extensions) (e.g., `"ext": "csv"` in the below example), every One-Shot`"command:"` must output to a directory named `output`. In the module below, the output is `output/_cleantarget_` The extra output directory on the remote instances (`/home/op/scan/$module+$timestamp/output`) are automatically created for you when using One-Shot modules. {% endhint %} For an example, lets look at the [ffuf](https://github.com/ffuf/ffuf) [module](https://github.com/attacksurge/ax/blob/master/modules/ffuf.json) to help explain `"ext": "csv"`. ``` [ { "command": "/home/op/go/bin/ffuf -w _wordlist_ -u _target_/FUZZ -of csv -o output/_cleantarget_ -ac", "wordlist": "/home/op/lists/seclists/Discovery/Web-Content/big.txt", "ext": "csv", "threads": "1" } ] ``` Since this is the first (and in this case the only) extension in the module, and because the `"command":"...` in the module outputs to csv (`-of csv -o output/_cleantarget_`), we can use `-o` in our `ax scan` command to output as csv. `ax scan input -m ffuf -o my-csv-output.csv` If you don't add any output argument, this module will still output to csv, since its the default (first) ext mentioned in the module. `ax scan input -m ffuf` If you wanted to be explicit about the output (if you had multiple JSON objects in the same module), you could use `-csv` in the `ax scan` command: `ax scan input -m ffuf -o my-csv-output.csv` ### jsonl The jsonl (JSON lines) module extension is quite literally the same as `"ext": "oG"`, which is very similar to `"ext": "txt"`. Handling JSON Lines is very simple, since results are returned one line per target without needing to be in a specific order, making them easy to merge. Lets look at the [nuclei](https://github.com/attacksurge/ax/blob/master/modules/nuclei.json) module for an example of `"ext": "jsonl"`: ``` [ { "command": "/home/op/go/bin/nuclei -update -silent ; cat input | /home/op/go/bin/nuclei -t _folder_ -o output", "ext": "txt", "folder": "/home/op/nuclei-templates" }, { "command": "/home/op/go/bin/nuclei -update -silent ; cat input | /home/op/go/bin/nuclei -t _folder_ -jsonl output", "ext": "jsonl", "folder": "/home/op/nuclei-templates" } ] ``` As always, the module command `"command": "... -jsonl output"` needs to output in the same format as the module extension `"ext": "jsonl"`. To use this, specify the appropriate `ax scan` output argument at runtime. For JSON Lines, the `ax scan` output argument is `-oJ`. `ax scan input -m nuclei -oJ my-json-lines-output.json` ## More Info In conclusion, the `ax scan` tool offers flexible options for downloading and merging scan outputs based on the specified extension. By understanding how to use the different extensions and corresponding commands, you can effectively manage and customize your scan results to fit your specific needs. # Horizontal vs Vertical Scaling ## Horizontal vs Vertical Scaling with ax scan While most modules are designed to scan a lot of targets (horizontal scaling), with some creativity, modules can be written to scan one target with the combined power of the entire fleet (vertical scaling). With `ax scan` [modules](https://github.com/attacksurge/ax/tree/master/modules), most of the time we are splitting a target list (a bunch of IPs for example) and uploading parts of the target list to every instance, but if we wanted to do something like brute-force one target with five axiom instances, we can do that by splitting a wordlist instead. By rearranging the special `input` file in the module to point to a wordlist instead of a target list, `ax scan` will split the wordlist and run it against the target you hardcoded in the module or specified in the command-line. ### Horizontal Scaling - One to Many The following puredns module spits a target list of domains and brute-forces each domain with the entire wordlist. ``` [ { "command":"/home/op/go/bin/puredns bruteforce /home/op/lists/seclists/Discovery/DNS/dns-Jhaddix.txt --domains input --resolvers /home/op/lists/resolvers.txt | tee output", "ext":"txt" } ] ``` Example: `ax scan myrootdomains.txt -m puredns-bruteforce -o myresults`
#### `_wordlist_` Adding the special `_wordlist_` variable in the module allows `ax scan` to change the wordlist if `-w` is present the command line, but not required. This is only included to demonstrate the optional `_wordlist_` variable. ``` [ { "command":"/home/op/go/bin/puredns bruteforce _wordlist_ --domains input --resolvers /home/op/lists/resolvers.txt | tee output", "ext":"txt", "wordlist":"/home/op/lists/seclists/Discovery/DNS/dns-Jhaddix.txt" } ] ``` Example: `ax scan myrootdomains.txt -m puredns-bruteforce -w /home/op/lists/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt -o myresults` Both modules above are examples of horizontal scaling. We take the target list of domains e.g. `myrootdomains.txt`, split and upload parts of the target list to every instance and brute-force the targets with the entire wordlist. ### Vertical Scaling - Many to One If we wanted to vertically scale e.g targeting one host with the combined power of the entire fleet, lets look at the next example: ``` [ { "command": "/home/op/go/bin/puredns bruteforce input --resolvers /home/op/lists/resolvers.txt tesla.com | tee output", "ext": "txt" } ] ``` Example: `ax scan bitquark-subdomains-top100000.txt -m puredns-single -o myresults` In the above example, we are hardcoding the target tesla.com directly into the module. More importantly, the special file `input` is now positioned as a wordlist. When running the `ax scan` command we must pick a wordlist as our first positional argument to split and upload.
Alternatively, you could have a module without the hardcoded target and instead specify the target in the command line: ``` [ { "command":"/home/op/go/bin/puredns bruteforce input --resolvers /home/op/lists/resolvers.txt | tee output", "ext":"txt" } ] ``` Example: `axiom-scan bitquark-subdomains-top100000.txt -m puredns-single tesla.com -o myresults`\ The last two modules are examples of vertical scaling. We take a wordlist, e.g. `bitquark-subdomains-top100000.txt`, split it and upload parts of the wordlist to every instance. All instances brute-force a singular target .e.g. `tesla.com`. For another example of a vertical scaling module take a look at [gobuster-dns](https://github.com/pry0cc/axiom/blob/master/modules/gobuster-dns.json). ### Vertical and Horizontal Scaling - Many to Many TODO # Responsibility We want to ensure that everyone has a clear understanding of how to use Ax responsibly and ethically.\ In order to do so, we kindly ask that you take the following guidelines into consideration: * When using Ax, please be mindful of the IP ranges you are scanning. It is very easy to accidentally include a /24 subnet that should not be scanned. If the subnet is then expanded or if using the `ax scan` argument `--expand-cidr`, each of the 254 IPs in the /24 subnet will be split between all the instances in your fleet. * If you do generate any abuse complaints, your cloud account may be suspended or cancelled without prior warning * We encourage you to double-check your scan parameters and ensure that you are only scanning the IP ranges that you intend to scan. * We highly recommend that you follow the cloud providers Terms of Service and their guidelines for ethical hacking and bug bounty hunting. ### Guidelines * It is the user's responsibility to ensure that their scans do not generate abuse complaints. * Do not include any subnets in the scan configuration that you do not have permission to scan. * If you accidentally include a subnet that you should not have scanned, stop the scan immediately and remove the subnet from the configuration. * Only use Ax for legitimate purposes, such as bug bounty hunting or penetration testing, within the allowed scope of the target's bounty program or prior agreement between you and the target. * Always be mindful of your scans and take responsibility for ensuring that they do not generate abuse complaints. * Do not use Ax for any malicious or illegal activities. ### Expectations * Act responsibly and ethically. * Follow the cloud providers terms of service and comply with all applicable laws and regulations. * Promptly address any abuse complaints they receive. ### Consequences Violations of the guidelines and expectations may result in immediate termination of your account. * Ax developers are not responsible for any consequences that may result from the use of Ax. ### Conclusion We are grateful for our cloud providers cooperation in allowing the use of Ax on their platform. We encourage Ax users to act responsibly and follow the guidelines to avoid generating abuse complaints and potential consequences. # Terminology ## [Ax Controller](#ax-controller) The machine you install Ax on is called the Ax Controller. The Controller manages all aspects of Ax, including account setup, building your Packer image, spinning up and SSHing into instances, creating new images from existing instances, deleting instances and images, managing distributed scanning, and much more! The Ax Controller executes the various scripts in `~/.axiom/interact` and stores account credentials in `~/.axiom/accounts/$account-profile-name.json` ## [Build](https://ax-framework.gitbook.io/wiki/fundamentals/ax-utility-scripts#ax-build) During first time setup, you'll have to create a Packer image. This is the `ax build` process. You can also rebuild your image at any time by running `ax build --setup` ## [Instance](https://ax-framework.gitbook.io/wiki/fundamentals/ax-utility-scripts#ax-init) When you spin up one cloud compute device from the Packer image (e.g. `ax init --run`), we call it an Ax instance. ## [Fleet](#fleet) More than one instance is known as a fleet (e.g.`ax fleet -i 10`). A fleet consists of a set of hosts, these can be used for parallel file transfers, scans, or parallel command execution. ## [Interlace](https://github.com/codingo/Interlace) A Python script created by [codingo](https://x.com/codingo_) and [sml555](https://twitter.com/sml555_) to "Easily turn single threaded command line applications into a fast, multi-threaded application with CIDR and glob support."\ Ax uses Interlace extensively for all of our parallelism. ## [Simple Module](#simple-module) `ax scan` [Simple Modules](#simple-module) executes a bash command on every remote instance apart of the scan. ## [One-Shot Module](#one-shot-module) If a module contains the string `_target_` or `_safe-target_` , ax scan will execute it as a [One-Shot Module](#one-shot-module). One-Shot Modules utilize [Interlace](https://github.com/codingo/Interlace) to easily manage the threading of arbitrary binaries and scripts. ## [Selected](https://ax-framework.gitbook.io/wiki/fundamentals/ax-utility-scripts#ax-select) Using `ax select` you pick the instance(s) to use when executing `ax exec` and `ax scan` ## [Provisioner](https://ax-framework.gitbook.io/wiki/fundamentals/bring-your-own-provisioner) The file detailing what tools to install as part of the build process. ## [Provider](https://github.com/attacksurge/ax/tree/master/providers) The cloud provider and the [functions](https://github.com/attacksurge/ax/tree/master/providers) sourced to interact with it. ## [Account JSON or axiom.json](https://ax-framework.gitbook.io/wiki/fundamentals/ax-utility-scripts#ax-account) The JSON file storing you user data and cloud credentials. A symbolic link from `~/.axiom/accounts/$profile-name.json` to `~/.axiom/axiom.json` ## [Axiom Classic](https://github.com/pry0cc/axiom) Our proud origins. Axiom Classic is the first iteration of our dynamic distributed scanning framework. ## [Ax Framework](https://github.com/attacksurge/ax) Our next-gen iteration of our dynamic distributed scanning framework. Axiom Classic users should feel right at home using Ax, with all the familiarity and simplicity from Axiom. Rebuilt to last, with auditability, transparency and improved functionality as our primary motivators.