Managing AXIOM instances
2023-9-25 01:42:50 Author: infosecwriteups.com(查看原文) 阅读量:11 收藏

Ott3rly

InfoSec Write-ups

As you probably learned from the previous part, it is usually a nice thing to have custom wordlists and tools for your remote axiom instances. In this article, I will briefly explain the features that will help you to understand how to access, modify, execute custom commands, and backup on each instance. It will also include some practical tips and the wordlists I used in my daily bug bounty.

As a prerequisite, make sure you have initialized an instance:

axiom-init <name>

After, you want to check the currently created and running instances:

axiom-ls

There are two main ways you could connect to your running Axiom instances:

axiom-ssh <name>

OR

axiom-connect <name>

After successfully connecting you will notice the following file structure:

  • /home/op — the home directory of op user. There are the most of axiom instance working files.
  • ~/go — most of the go language CLI tools are stored here.
  • ~/lists — contains the wordlists that could be used by default of other tools or supplied as an extra flag.
  • ~/nuclei-templates — the templates that will be used for the nuclei tool.
  • ~/recon — this directory contains other tools.

Some other tools are used in docker containers or as binaries in other locations. For me personally, modifying ~/lists or ~/recon directories makes most of sense, since I could add my custom tools or wordlists there:

I like to use assetnote’s wordlists most of the time for web fuzzing, so creating the assetnote directory under ~/recon makes perfect sense:

You will have an updated machine with custom wordlists ready to use with fuzzing tools such as gobuster, ffuf or feroxbuster. It is possible to snapshot that machine so next time you spawn new instances, you can use it.

Another interesting feature is using custom or inbuilt Linux commands on selected VPS. But to demonstrate that it could be done on multiple VPS instances at once, it is required to spawn another server:

You could run ifconfig command on the specified instance by:

axiom-exec ifconfig --fleet <instance>

In order to run the same command on multiple instances, firstly you need to select which machines you want to use:

axiom-select "scanner\*"

After selecting instances, you can execute mkdir command:

You will probably like to do some file transfer. It is especially useful for cases when you want to download some results stored in Axiom machines or you might want to add your own wordlists. The simple command that could be used for this:

axiom-scp <from> <to>
Uploading assetnotes dot_filenames.txt from local machine to all scanner servers

As you can see I have specified scanner* as the instances I want to transfer the same file to. Other examples on file upload or download could be easily found on Axiom docs.

Snapshots are like the save files for the games. If you want to save all work done on the server to have continue use it later — you could use axiom-backup:

Running this command usually takes much longer than CLI shows, so my advice is to check it manually. For instance on Digital ocean you could view your snapshots here.

We covered the most often-used features of this awesome tool. I hope it will greatly help on your Bug Bounty journey. It is a great initial point to start hunting, but there is more! If you want to have fewer duplicates, you have to be smarter than most hunters.

To find valid bugs, you will need to use your own tools or add a little twist to less known ones. To have a custom tool running with axiom-scan you will need to know how to create modules, since running axiom-exec every time is not efficient. Stay tuned, since the next part will be about creating your own axiom module!

Subscribe to my page to not miss any upcoming stories. Also follow me on twitter, since I am planning to share some short insights, cool tricks and bypasses there as well.


文章来源: https://infosecwriteups.com/the-power-of-axiom-part-3-b68acdf085be?source=rss----7b722bfd1b8d--bug_bounty
如有侵权请联系:admin#unsafe.sh