Creating Custom AXIOM Modules

In order to be successful in bug bounty, you have to be a little different from the crowd — use your own or lesser-known tools. In this article, we will learn the intricacies of adding your own tool as an Axiom module.

If you are interested in more about Axiom, the basics, installation, and core commands, I do recommend reading previous parts of the series.

What is an Axiom module?

Axiom modules are basically the descriptions for your tools in the instance of how they should be used. If you have installed the Axiom by using the default configuration, your list of modules can be found under the ~/.axiom/modules directory:

As you can see, there are modules prepared for a lot of well-known infosec tools already. Those modules will be executed while using axiom-scan -m <module>. So if you want to run amass module, you will execute this command: axiom-scan input.txt -m amass.

Important to note, that if you used your custom instance build — you have to make sure that it was installed on the instance as well. That’s why I recommend using the default build to get used to Axiom first since it does have all of those tools prepared.

Simple module description

Let’s inspect the contents of the module, for example using the amass tool amass.json:

  • The command parameter sets the exact command that will be run on the instance.
  • The input comes from the axiom-scan file.txt command as a distributed part of file.txt. For example, if file.txt has 100 domains list and you have 10 instances, the input for the command will receive 10 different domains.
  • The output will be used as the placeholder for the amass command to receive the output to the screen.
  • The ext defines the type of output you will receive.

If you want to use any additional amass flags for the axiom-scan file.txt -m amass command, it will be appended to the end. So to avoid constantly repeating yourself using the same flags, you could specify them here. A very good example could be used on httpx command. I would always like to search for additional ports by default, not needing to remember them each time:

Some of tools are installed via docker. For example, commix module will look like this:

Advanced module description

Let’s explore some advanced module features. The ffuf tool is very commonly used by the Bug Bounty community to find some interesting directories, files, or parameters. On the Axiom, this module looks like this:

  • _wordlist_ is the placeholder for the wordlist parameter. If the user doesn’t specify the wordlist, it will use the selected one by default.
  • _target_ here is the same as input in previous examples.
  • threads this parameter is optional, but it becomes useful if you want to have multiple scripts running on the same instance at once. For instance, when some scripts do not have inbuilt threads flags this feature might become handy.

Practical example

If you read all previous articles and this one, finally you have enough details to create your own module. I will use golang version of previous waybackrobots.py gist code from mhmdiaa which could be found here. This binary extracts web archive information for each target’s robots.txt files to find some interesting directories. It’s a pretty useful tool for old programs and has not been used by many bug hunters.

Step 1 Initialize a single instance and connect to it if you haven’t done it yet:

axiom-init wayback

axiom-connect

Step 2 Install golang binary on connected machine:

go install github.com/mhmdiaa/waybackrobots@latest

Step 3 (optional) Back up your instance:

Step 4 Create waybackrobots.json module under ~/.axiom/modules directory on your local machine:

cd ~/.axiom/modules && cp amass.json waybackrobots.json

Step 5 Test the module. I will use yahoo.com and tripadvisor.com in targets.txt as the example:

The script executed successfully on a remote instance!

Final Words

If you followed this guide carefully, you have successfully added your first Axiom module. If you are planning to use this module, I personally suggest using Python script instead, since it is more reliable. Also, you could edit that script to add more features. All in all, it’s just an example of what can be done to stand out from the crowd.

The next part will be only a practical example, including how I hunt for S3 bucket issues on a mass scale with the help of Axiom. This upcoming part will be intriguing since I have made a huge chunk of my bug bounty income using that method.

I am active on Twitter, check out some content I post there daily! If you are interested in video content, check my YouTube. Also, if you want to reach me personally, you can visit my Discord server. Cheers!

Share with your friends
© 2024 "Otterly"