Bug bounty hunting is inherently difficult——not only have the best hackers already combed over the targets, you’re also a sole entity trying to outwit organizations that make billions in revenue. Additionally, it can be discouraging to sit and have your monitor burn your retinas for hours, losing cones and rods, only to end a session with nothing to show.
Just as my grandpappy used to say (for the sake of this article): “You’ll eventually break something if you mess around with it long enough.”
Even though you are bugless now, you will get one. To help you along your way, here are some high-level concepts that may be holding you back.
You’re stuck in a tutorial blackhole
I’m extremely guilty of this, I know better——yet it’s hard to break the habit. There’s so much to learn in such a technical field and it’s also fun. Programming, vulnerability classes, new white papers, CTF challenges, and labs——it is never ending. In fact, I am purposely excluding any links to resources in this article, to avoid anyone going down an educational rabbit hole.
However, nearly every time I have actually listened to the advice of veteran hunters and taken what I feel to be my lack of skills out into the real world, I end up finding something.
When thinking about my first valid reported bug, I was legitimately unprepared. Just like you, I thought I may never find one. However, the time spent on a target resulted in an exploited IDOR vulnerability that allowed me to arbitrarily view sensitive data of anyone I wanted to within a government database. Once you do find something (and you will, I believe in you), the adrenaline you get from sending that report and talking with the triage team will motivate you to get back out there. Due to the boost in excitement, not too long after my first bug, I found two XSS vulnerabilities on a different target. But then, I got sucked back into the tutorial blackhole and it was months before I found another. DO NOT GET SUCKED BACK IN. Once you do find one, and you will, it will be the catalyst that pushes you toward finding another.
While simulated exercises will train your eyes to look out for certain clues in a general sense, requests generated by real web applications and the responses they receive can be much more complex. With complexity comes more opportunities for the developers to miss something.
I suggest hunters implement a steadily decreasing ratio of learning to real-world hunting. I am currently in the midst of lessening my learning:real world hunting ratio, as advised numerous times by my mentor. As a beginner, start out by spending 70% of your time learning and 30% of your time on targets. Every two or three months, decrease learning by 10% and allocate that toward real bug hunting. Eventually, when you hit 30% in learning, you can decide how to adjust on your own. There’s nothing wrong with attributing more time to learning at this point either; the key aspect is that you are still out there in the trenches.
So, no matter how new you are, set down the books and go out there and actually hunt. While I am still an advocate of continuous learning, as this is a dynamically changing industry, the concept is straightforward: you will not find bugs on real targets if you never spend any time on real targets.
Pick the right targets
A web application that is composed of mostly static assets is not going to be the best to test. What you want is a dynamic target that offers a lot of functionality. The more the server has to process what you supply it, the more opportunities there are for mistakes. This is what you capitalize on.
Sure, there may be forgotten directories and files that lack the proper permission levels to ensure their security, but the complexity of ensuring that any user submitted data is handled appropriately is your best bet at finding a vulnerability.
Developers and security teams have to protect against an infinite number of data combinations that come their way. This will always be the case and leaves the defending side at a constant disadvantage.
Stick to a target
Patience is key. Up until recently, as a beginner you have assumed the intended end user-role when you use web applications. Bug bounty hunting is all about the unintended user behavior. Parsing through how everything works under the hood is still foreign to you. Right now, you are conditioning yourself to the workload required.
You may come across post after post of hackers celebrating their wins. Your algorithm is fine-tuned to feed you what you want to see, but if you look closely, you’ll see the names that pop up the most often are usually hunting on the same target or two. If you view recent “hall of famers,” you will typically see that the majority of their points are earned on the same program.
Finding bugs, especially the ones that will pay big, requires a deep understanding of the target. By knowing the web application more than some of the developers do, you are in a prime position to find bug after bug. Was there a feature flag with a Boolean value that when set to true revealed functionality in a beta state? Great, just check back in every so often to see if it is live and you’ll be one of the first to test it for vulnerabilities. Did a changelog just drop? This won’t take long to catch up on. You’ve already read all the other available documentation. Oh, they added a new permission role? Well, the last one that was released had some privilege escalation issues, let’s try similar methods again.
See the advantage? Every new target seems overwhelming, no matter how long you’ve been hacking. Changing targets just because you haven’t found a bug within the first three days is a huge reason you may not find anything. This also includes subdomains. The same way it’s ill advised to switch between programs and domains, it’s also a bad idea to switch between subdomains. Be absolutely certain that you have given 110% on a specific target before you think about throwing in the towel. The thing is, the more you look and the more you understand how a target works under the hood on a business logic level, the more confident you will be that there’s something to exploit nearby.
Just like my article-specific grandpappy used to say, “Stick to a web application, be persistent, read all available documentation, try everything, and do it for three weeks. Then ask yourself if you should move on.”
Automation is a whole other ballgame
Automated vulnerability scanning tools, overly aggressive recon, and not to mention setting up the infrastructure needed to compete with the best of the best, is not the best use of your time as a beginner (but that’s just like, my opinion dude). This may be more warranted if you come from a development or engineering background, but if you don’t know what to look for in the first place, trying to automate “I’m not sure” is time better spent. There are so many people out there running the same tools that are even more configured than what you just cloned from Github. This is not to discourage you, but to guide you toward activity that is more valuable.
While fuzzing and running the most aggressive nmap and sqlmap scans may hit something if you’re lucky, it’s more about noticing the right conditions for the right tools rather than just firing a machine gun of requests at a poor server hoping something pops. We all dream of that magical subdomain or endpoint that hasn’t been touched since Altoids Sours were still around, but solely focusing on finding an untested area is usually a fruitless endeavor and that time could have been spent actually sending data to be processed by the server. Also, there are the rules of engagement to worry about.
Engage with the community
You’re not alone in this. There are others out there that have not found their first bug either (and again, I promise both of you will find a bug). Even the hackers that now find bugs at a steady rate can remember the time when that was not the case. While independence is a benefit of bug hunting, it can also be a detriment in other aspects.
Have you ever brought it up in normal conversation to someone outside of the field? It’s a dead-end conversation as everything sounds like gibberish to the untrained ear. By placing yourself in spaces that are built around cybersecurity, you can find the answers to your questions, speak up when you proudly know the answers to the questions of others, and find a lended ear for venting your frustrations or obstacles. Nine times out of ten, they will also do more than listen—they’ll provide possible solutions.
Another benefit of engaging with the security community is you gain access to a crowdsourced hub of information. That key tactic that could have made the difference between finding a bug or not, may have gone unnoticed by you. With meetups, chat servers, and entire conventions available, you can get the tips and tricks used by others to help you along the way. At least personally, everyone I have met so far has been great and helpful.
So, join that channel. Go to that convention. It’s worth it.
The real bounties are the fun we had along the way
As corny as it may sound, if you’re just in it for the money, you’re in the wrong place, muchacho/a. If you think you’ll find a $50,000 vulnerability in your first week (though, the chance is nonzero), you’re going to be disappointed. Actually, a lot of the money that the big names make comes from live hacking events and invites to private programs. Obviously, getting those invitations means you have a pretty good track record on public programs hosted on bug bounty platforms. You can read a bit more about that here.
In a sense, you have to enjoy being frustrated and that frustration will add more fuel to your stubbornness. You should be a perpetual stubbornness machine. All of this is like a text based video game that you can enjoy the highs and lows of. Who knew that sitting could be such an emotional endeavor? Getting hit with a dupe or the dreaded informational may be a downer, but the thrill of even awaiting the designation will keep you up at night, in the most exciting way.
The toolkit you need
There are an endless number of blogs out there talking about the latest must-use tool. But the most important tools, the ones that can’t get enough recognition, are persistence, patience, and attention to detail.
If you know how to intercept requests and responses using an HTTP proxy and use a keyboard, you are ready to go out into the real world on a real target.
Get out of the labs. Get out of the books. Get out of this very blog right now (he says, conveniently at the end) and go delve into a web application with a program on Bugcrowd. You will find a bug. And when you do, let me know so I can celebrate your win.