BOOK THIS SPACE FOR AD
ARTICLE AD
Collaboration and human connection are significant trends in cybersecurity. A vast and fluctuating cyber threat landscape means new challenges and vulnerabilities are always just around the corner. Sharing knowledge, techniques, and skills empowers cybersecurity professionals and practitioners to thwart cyber-attacks and minimize risks.
As cyberattacks grow more sophisticated, attracting new talent and individuals with varied backgrounds and skill sets is crucial. Communities that provide a safe and supportive environment for professionals and beginners to connect, problem-solve, share knowledge and tips, and gain friendly support have begun sprouting up. Today, cybersecurity is one of few industries where you can learn everything you need to know online and from others in the industry.
Many have found success with the help of security-minded people in forums, open-source projects, and blogs. They are guided by a strong sense of community and giving back by creating opportunities, tools, and resources for others.
Ben Bidmead, better known as pry, has long been a part of the online cybersecurity community and has selflessly shared content and tools. Ben even created a community, 0x00sec, for both those experienced and just starting in cybersecurity to share skills, interests, and knowledge through ongoing conversation. From this online community, axiom was born. A single, dynamic cloud infrastructure framework, proudly sponsored by SecurityTrails, axiom has helped red teamers and bug hunters alike, just as they helped Ben in his early start.
In the second interview for Bug Bounty Hunting Month, we caught up with Ben to talk more about his cybersecurity beginnings, the most valuable resources to him and the candid story behind axiom. For a more technical look at axiom, you can check out our in-depth review: Axiom: A Distributed Hacking Framework for Pentesters and Red Teamers
SecurityTrails: What did your early days in cybersecurity look like and what is your experience with bug bounty hunting?
Ben Bidmead: I started by doing CTF’s, playing Overthewire, HackTheBox, and Vulnhub, and then I got into pentesting. While doing penetration testing, I learned about the bug bounty scene. I am not actually a bug hunter, but I love following and being immersed in the community. I also love the freedom of testing wide scopes. I saw an opportunity to create a community of my own, where like-minded and friendly individuals can share their experiences, and even criticism, in a safe place. I wanted to build a community where both noobies and experienced hackers can come together as equals and have a place they call their own, thus 0x00sec was born.
I have endless respect for bug hunters. They are often highly driven individuals who don’t back down from hard challenges.
ST: What were the most valuable resources for you when you started? Do you think resources for bug bounty/pentesting are more available to beginners today?
Ben: Honestly, HackTheBox and the writeups were amazing. When I first started, I spent 2-3 weeks trying to hack the same very basic box. Eventually I got user, no root. I rinsed and repeated this, watching walkthroughs by IppSec and retired boxes. Eventually, I built up some level of competence and had moved to professional work. I learned a lot more in my professional work.
Being a beginner these days is a lot easier than when I started, not very long ago. The key thing is persistence. The information is out there, you just have to be very persistent and enjoy the pain when you get stuck. Being stuck and persistent a lot will teach you many things. 0x00sec tries to facilitate this through conversation primarily in Discord.
ST: Now the hard questions - do you think finding bugs is easier during pentesting or bug bounty hunting?
Ben: Bug bounty hunting is insanely harder. By comparison, pentesting is easy. I haven’t hunted much, but the only bugs I found have been dupes! If I tried a little harder, I think I could get some good bugs, but it is definitely a lot harder. Bug bounty scopes tend to be more hardened than your typical pentesting engagement. I have endless respect for bug hunters. They are often highly driven individuals who don’t back down from hard challenges. I owe a lot to the bug hunting community. The tools I use now first became popular in bug bounty. Naturally, the community is a primary source of inspiration.
ST: Axiom was started in 2020, but the idea behind it has been around much longer. Tell us about the early start of axiom and how you discovered the need for such a tool?
Ben: Axiom was originally born out of a ruby chatbot once named “Karen.” The chatbot lived in the 0x00sec Discord server and allowed people to spin up disposable hack-box instances. This was hard to demo to people with the chatbot cruft so I turned it into a CLI tool. Thus, axiom was born. At the time, I tried to build it in Golang, but my Go was shockingly bad, and I was still learning a lot from my then flat-mate @Calumboal. I first started experimenting with Terraform and Ansible but quickly realized Packer was more akin to my needs. I learned a tremendous amount from my then devops mentor @fraq. He taught me the basics of devops and using tools like packer, ansible, kubernetes and others. Huge shoutout to him! I decided to prototype something in Bash, to spin up a single instance, and pushed the code out to the world. It seemed natural to add some extra wrappers to interact with the boxes. Then I realized we could entirely abstract interaction with infrastructure and make it extremely easy to script. We figured out you could spin up more than one instance at a time, and then axiom-scan and parallelized scanning was born.
Resolving 6 million domains in 5 minutes with 100 instances
Around August last year, I met my now partner in crime, @0xtavian. 0xt was my first sponsor for the project and heavily pushed multi-cloud support. At the time, I was in a difficult place in my life, and @0xt got me out of some pretty tough situations. At one point, I was waking up and working on axiom before work for 2-3 hours, working an 8 hour day, and then working until 4 am-5 am creating, testing, and refining axiom. I was obsessed. But I knew I had to get my thoughts into code and show my vision of what we could do. After a few months at that pace and some tender-care on the project from 0xt, we ended up with something pretty cool. I’m amazed at the response it has gotten from the community, and we’ve recently merged some really cool contributions. I’m just blown away!
ST: How does axiom differ from similar tools? What does it offer that isn’t as easy to find in other pentesting distros and tools?
Ben: I think it’s important to note that while axiom is a tool, its purpose is to distribute the workload of other already popular scanning tools. We wouldn’t have much value if not for the availability of these open-source scanning tools, which we’ve incorporated as axiom modules. We’ve just attempted to enable the distribution of these well-designed tools and have done so in a way that abstracts a lot of cloud operations into just a few commands.
If somebody inspired by axiom brings innovations to this vision or makes a tool that changes the game, my job is complete.
Anybody can write a script now to interact with a supported cloud of choice with relative ease. Also, parallelized scanning with 100 instances is, literally, 100x faster than scanning using a single instance. With axiom-scan, we’re throwing more affordable horsepower at the problem and deleting our instances as soon as we’re done. This is how you’re supposed to use the cloud - not treat it like a colo monolith you leave on for years at a time.
Executing distributed scans 1: axiom-scan http.txt -m nuclei -o nuclei.txt –stats
ST: At its core, axiom was created to be an accessible, easy to use, and budgetable for everyone tool — empowering even the weekend warrior to go against experienced teams. How did you achieve this?
Ben: Simplicity and transparency are the keys. Familiarity is also crucial. We try our best to enable users to use the tools and arguments they are most comfortable and familiar with without sacrificing the experience you get from running the tool(s) natively. One way we do this is by interpolating user-provided command-line arguments directly to the module, allowing you to enter your go-to Nmap command, for example, without alteration and have axiom seamlessly distribute the workload. To be accessible, we need to be transparent about how much it will cost you. As the default image size costs $0.007 per hour, if you take the number of instances * 0.007, you can work out your hourly cost. If you are still concerned about money, you can use my referral link and get a $100 free credit. You would have to do quite a lot of damage to blow through that in a week!
I think a top concern for people first starting is accidentally making a mistake and ending up with a bill of $200 after a few hours. We’ve heard this worry all too often, but with axiom’s default provisioning profile, it is pretty hard to make an expensive error as long as you axiom-rm ‘fleet*’ -f at the end of your scans.
Axiom proxy feature: axiom-proxy “fleet*” –single
The other factor is services like DigitalOcean are really cheap if you use them by the hour. Providers make a lot of their money from people spinning up boxes, leaving them on for years, and barely utilizing them - that’s why the price is relatively low. If you flip this script and spin up only for what you use, you end up with a system that gives you insane power for pennies on the dollar.
ST: In a nutshell, axiom automates your bug bounty workflow so you’re basically winning the game. You have created something that can give you such a competitive advantage but still decided to release it to the public. Bug bounty community really is all about giving back — what do you enjoy the most about being part of the community?
Ben: I love giving back to the community. I never intended for axiom to be a final product; I just wanted to show what was in my head. If somebody inspired by axiom brings innovations to this vision or makes a tool that changes the game, my job is complete. To me, the hacking community at large has always been about free flow and sharing of information. Cybersecurity is one of the few industries where you can learn pretty much everything you need from strangers on the internet and get a good job out of it! I am entirely self-taught and learned everything from free open-source software, articles on the internet, and IRC channels. Now that I’m in a position with opportunity and resources, it’s my moral obligation to give back to the community. I wouldn’t be here today if not for others that gave back.
The information is out there, you just have to be very persistent and enjoy the pain when you get stuck.
ST: How did axiom fit into your recon automation workflow? How do you use it?
Ben: I use axiom a few ways. Though not complete, I am currently building an automated continuous scanner. It will spin up a fleet every couple of hours, perform a distributed scan against every single bug bounty platform yet, and then repeat. Data will be diff-ed, and all urgent notifications come through telegram, while non-urgent come through Discord.
The other way I use axiom is on-the-fly scans. I will write a script to spin up 90 boxes, launch a scan, and then it will delete them when done. I’ll usually program a few options at a time.
Executing distributed scans 2: axiom-scan netflixips.txt -m httpx -o http.txt
ST: What are some ideas you are developing for the new version of axiom? What can we expect?
Ben: In the next version of axiom, we’re bringing the ability to split a wordlist across a fleet to enumerate a single target, as well as increased multi-cloud and multi-region support. We are also figuring out how to launch scans in the background beyond just a VPS with tmux - which still works. It will also include better error handling and documentation.
Final words
With the second interview of Bug Bounty Hunting Month, we’re only getting started! We hope you have enjoyed this candid look at the early days of axiom, how it was born and insights from Ben. As part of BBHM, we’re giving bug bounty hunters an epic edge with powerful data resources with the Bug Bounty Hunter’s Toolkit.