The ultimate beginner’s guide to the Ax Framework

Just imagine what you could do with your own botnet—what you could do as the conductor to an orchestra of devices that carry out tasks on demand. This can both be a daydream and a legal nightmare, if you create one using…ahem…traditional methods.

As a red teamer or bug bounty hunter, it’s likely you’re already renting a remote machine to assist you on engagements. However, unless you are in the automation game (or rich, nice), this machine may be lacking in storage and RAM, or bandwidth. This means when you do need to carry out a resource-intensive task, it strains the system and takes what seems like an eternity to complete. Not to mention that over time, as a result of testing new tools and switching between targets, it has become a disorganized mess. Can you even remember all the installations and customizations you’ve made? When was the last time you downloaded new wordlists?

Now that you think about it, a botnet may not be that desirable. Managing one machine is already a hassle….

Guess what. You’re in luck because the Ax Framework provides a solution to all these issues. With Ax, you can centrally create and manage 100+ cloud devices in a matter of minutes, distribute a workload among them, and receive rapid, reliable results. You can even make the instances shut down at the end, saving you a hefty cloud bill.

Installation and configuration

The machine you install Ax on becomes the Ax Controller, which assumes the administrative role. The Controller manages all aspects of Ax by using utility scripts.

1. The easiest way to install Ax is by running the following command:
   bash <(curl -s https://raw.githubusercontent.com/attacksurge/ax/master/interact/axiom-configure) --runView alternative installation methods here.
   
2. Follow the prompts. Eventually, you will be prompted to enter your cloud provider and provide your API key.At the time of writing, Ax supports the following cloud computing providers: AWS, Azure, Digital Ocean, GCP, Hetzner, IBM Cloud, Linode, and Scaleway.

   Select a region and default size (CPU, RAM). Once you have, press enter to save the configuration settings to a new profile by supplying an account name.

   

   

   

Build an image

Ax allows you to build a “base image,” which acts as a template for your virtual machines. You can select from a set of premade Packer Provisioner template files or create your own. Once a selection is made, Ax will create a temporary instance, install the modules listed in the provisioner file (along with their dependencies), take a snapshot of the build, and then delete the instance.

The available image options are: default, reconftw, barebones, and custom. To view what each includes, click here.

1. For the sake of this article, use the default image (although it is recommended that you create your own). Be patient, as the initial build can take some time.
2. Launch a new shell session using the following command: /usr/bin/zsh

Initializing and using a single instance

With everything set up, you can now use Ax.

If the commands ever become unavailable, first try adding the responsible directory to your system’s path by running the following command: export PATH=$PATH:~/.axiom/interact

1. Let’s begin by listing the available snapshots: ax images ls
   Currently, the only available snapshot is the one we just created. This is set as the default snapshot that will be used if no other is specified. The default configurations are in the ~/.axiom/axiom.json file.
2. To launch a single virtual machine named demo01, run: ax init demo01The other arguments that can be used are:
   

   Argument	Description
   –run	Generates a random name.
   –image <image>	Specify the image to use.
   –region <region>	Specify the region the device should be located in.
   –deploy <profile>	Adds additional configuration settings. For example, the desktop profile will install and configure a GUI on the remote machine, allowing you to control it using a remote desktop client. The configuration files for available profiles are stored in ~/.axiom/profiles
   –shell	Automatically connect to the instance after initialization via SSH.
   –size <vm size>	Specify the size of the machine.
   –no-select	By default, the initialized machine is automatically “selected.” All subsequent actions will be run in its context. This flag disables this automatic selection.
   –debug	Displays detailed information about the process.
   –help	Displays these arguments.

   

    

3. Now, connect to the instance: ax ssh demo01Note that SSH keys have already been created. Convenient, huh?
4. You now have a functional remote server that can assist you in security testing. It comes with a bunch of hacking tools preinstalled 😎. Take some time to navigate through the file system to discover what is included in the default image.When you are done, disconnect by entering “exit.”

Using multiple instances

The beautiful thing about Ax is you can command multiple instances in sync.

1. Create another virtual machine named demo02. Once it is initialized, list all of your account instances with: ax ls
2. Now, select both instances with: ax select demo\*This command will update the ~/.axiom/selected.conf file.
3. Last time, when using only one instance, we connected to it directly. Instead, use the following to execute an arbitrary command on both instances: exec [command]Try running pip3 install git+https://github.com/codingo/Interlace.git if you get an error resembling the following:/home/username/.axiom/interact/axiom-exec: line 345: -tL: command not found
cat: /home/username/.axiom/tmp/exec/1731419513/hosts_preflight: No such file or directory
cp: cannot stat '/home/username/.axiom/tmp/exec/1731419513/hosts_preflight': No such file or directory
/home/username/.axiom/interact/axiom-exec: line 356: --silent: command not found
tail: cannot open '/home/username/.axiom/tmp/exec/1731419513/logs/*' for reading: No such file or directory
tail: no files remaining
/home/username/.axiom/interact/axiom-exec: line 426: -tL: command not found
/home/username/.axiom/interact/axiom-exec: line 421: --silent: command not found
Killing remote processes in a background job
4. When you are done testing commands, power off the instances with: ax power off ‘demo\*’

Ax fleets

Instead of creating instances one by one, Ax allows you to initialize them in bulk in what are referred to as “fleets.”

1. Let’s start with a clean slate. Delete the two instances we made earlier with: ax rm ‘\*’
2. Let’s create five instances with: ax fleet demofleet -i 3
   You may need to contact your cloud provider to increase your instance limit depending on how many you want to create. 

Ax modules

Ax Framework comes with more than 100 built-in modules to choose from. These modules are predefined terminal commands for security tools packaged in a way that allows them to be executed across your instances in parallel. There are two types of modules:

1. Simple modules: These are commands for tools that can handle a list of targets at once.
2. One-shot modules: These are designed for tools that need to run against one target at a time.

Both types of modules are defined in JSON format and stored in the ~/.axiom/modules/ directory.

Ax Framework comes with more than 100 built-in modules to choose from, including ones you may already be familiar with, such as subfinder, nmap, and ffuf.

You can list the available modules with: ax scan –list

The modules use variables surrounded by underscore characters as placeholders that get replaced with your supplied values at runtime:

Ax scan

With a fleet of instances awaiting your command, ax scan utilizes modules to assign an equal portion of the workload among them.

The command syntax for running a scan is:

ax scan <input> -m <module> -o <output file> <additional arguments>

Ax supports various output file formats. The available types are listed as ext properties within a module’s JSON file. By default, if no file extension is specified using the output argument -o, the module will use the first command and its associated extension.

To demonstrate, let’s use the subfinder module:

1. Create a wordlist named inputfile.txt containing three target domains.
2. Run the following command: ax scan inputfile.txt -m subfinder -o subs.txt
3. Once the scans are complete, the results of all three will be merged into the subs.txt file.
4. Directories following the naming convention /<module>+<timestamp> will be created prior to a scan’s execution under the /home/op/scan/ directory on the participating remote machines. Once a scan is complete, each file within this directory will contain the data resulting from the portion of the scan that the instance was responsible for.

Custom modules

Although any additional arguments made available by the tool can be supplied, to save time, custom modules can be created. Modules are written as JSON files and saved in the ~/.axiom/modules directory.

To demonstrate, let’s create a custom simple module using nmap:

1. Create a file within the ~/.axiom/modules/ directory named “custom-nmap.json” with the following contents:
   

   [ { "command": "sudo nmap -sS --top-ports 1500 -iL input -v -oN output", "ext": "txt" } ]

   The module above will SYN scan the top most popular 1,500 ports on each target in the input file list. The output will be verbose, and the results will be stored in a txt file.

    

2. Run the custom module with: ax scan inputfile.txt -m custom-nmap -o portscans.txtTo avoid overwriting files with matching names, any existing file will be backed up with the date and time appended to its name.

   Since nmap already has a native way to iterate through a list of targets via the -iL argument, this custom module is best written as a simple module.However, even modules that usually only take a single target to run against can iterate through a list by utilizing loops. To demonstrate, let’s create a custom module using ffuf:1. Create a file within the ~/.axiom/modules/ directory named custom-ffuf.json with the following contents:[
{
"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/raft-small-directories.txt",
"ext": "dir"
}
]The module above will fuzz for directories on each target in the input file via a loop that reads each line. For every output file, the associated target name will be used and stripped of colons and forward slashes, as they are not allowed in file names. The fuff tool will use the raft-small-directories.txt wordlist that is already downloaded to the remote instance.

   

   

   Although this provides a convenient way to use ffuf on multiple targets, the downside is that simple modules do not have access to threading using Interlace.

Conclusion

You should now have a solid understanding of how to use the Ax Framework. Remember to read up on creating your own image, as this could allow you to discover areas that others using the default image may miss. With Ax, you can eliminate the time-wasting task of manually configuring and managing remote machines, giving you more time to focus on what really matters—finding bugs. Work smarter, not harder.

Until next time, love y’all.

• Ninjeeter