Hacking on Bug Bounties for Four Years

• Intro & Motivations
• Findings
• Analysis
• Collaboration
• Methodology

I value transparency a lot, especially when it comes to the bug bounty space. Bug bounty hunters all around the world are submitting a range of reports where the issues found span across multiple domains, often leveraging numerous techniques and methodologies. However, if you’re not already an active bug bounty hunter who has a good understanding of what a bounty program expects, or will pay out for, you have a major disadvantage compared to someone who does have this knowledge. I hope through this blog post, I can demystify the sort of issues bug bounty programs pay for.

The last blog post I did in this series was around four years ago, 120 days, 120 bugs. In the last four years, a lot has happened. I moved to Europe for six months, I moved interstate in Australia twice, I won a live hacking event, I co-founded a company and helped build an attack surface management platform with a team of people I consider family.

Unlike my previous blog post, I did not set myself a goal to find a bug a day. Instead, I participated in bug bounties whenever time allowed. There were many months where I found nothing at all, which often terrified me when it came to evaluating my self worth as a hacker. I also admitted to myself, that I might be a good hacker, but there is always going to be a better hacker out there, and I’ve made my peace with that as a hyper-competitve person.

If you don’t have an excellent understanding of fundamental application security attacks and weaknesses before you approach bug bounties, in my opinion, you are wasting your time. Practice and learn more here.

If you’re looking for a paid, more extensive resource, check out and practice with PentesterLab.

Participating so heavily in bug bounties has given us the knowledge at Assetnote about what security teams actually care about. It’s the reason we can maintain high signal when we are continuously finding exposures.

My primary motivation for this blog post is to educate the masses on what bug bounty programs are paying out for.

For example, would you know that you could submit a dangling EC2 IP (subdomain pointing to an EC2 IP that is no longer owned by the company) as a bug report without reading the proof in the pudding below? I’ve been paid for this by programs, so clearly they value this sort of information.

Below are all of my findings for the last four years. I’ve redacted information where necessary, but by reading the titles, it should give you a good understanding of what I was reporting to programs.

I can tell you that the exact amount made, after calculating all of the payouts in the table above, is $635,387.47 made in 1590 days (4 years, 4 months). This is not the total amount I have made all-time in bounties. This figure is only inclusive of the HackerOne platform, no other platforms that I have submitted bugs to have been counted in this blog post. I report the vast majority of my bugs to programs on HackerOne.

I know hackers in the bug bounty community that are capable of making hundreds of thousands within weeks or months. Sadly, that’s not me, but I do find them inspiring. As I said earlier in this blog post, I came to terms with the fact that there are better hackers out there, and these days, I am proud to sit at rank 43rd on HackerOne at the time of writing this.

If you divide the amount of money by the number of days, you will quickly work out that it averages out to roughly $400 USD a day. I could have been earning this amount or more by working as a consultant with a high day rate, but the difference is, I made all of the ~635k on my own terms.

I worked when and where I wanted to and didn’t touch a bounty program for weeks if I wasn’t feeling up to it.

There were at least 62 bugs in the table above that were the direct result of automation. This accounts for 18% of the total number of bugs I reported in the last 4 years. This is a pretty interesting takeaway, and proves to me that automation is one of the facets that leads to success in finding security issues.

These companies paid me quite a lot of money in order to lock down their attack surfaces. While earning this money and learning new techniques along the way, we built as much of the workflows, techniques, tooling and methodologies into Assetnote. We found that by translating bug bounty success, into a more digestible enterprise product, we were able to successfully establish ourselves as a key player in the attack surface management space.

Today, we have a strong customer base that uses our product to not only find exposures as they happen immediately, but also more creatively to reduce their bug bounty spend, not paying for issues that are found through automation. Assetnote’s platform has been thoroughly tested against attack surfaces in the last four years of my bug bounty hunting, and is capable of continuously finding security vulnerabilities.

A majority of the bugs were only possible due to automated asset discovery, but still required some manual inspection and exploitation. Large scale asset identification is still a key pillar of my success.

In terms of criticality, there were 24 SQLi’s, 22 SSRFs, 20 IDORs, and at least 11 RCEs.

I focused my time mainly on Uber as I simply enjoyed it more and valued the team working there – first with Matthew Bryant, Collin Greene and then with Joel Margolis after Matt and Collin had left.

For the four years of hacking on Uber, I was able to come up with a methodology when approaching their assets by having a deep understanding of their architecture, and development practices. This was absolutely key to my success, and I’m sure other successful bug bounty hunters have a specific way they approach a program. Every company is different when it comes to hacking them.

Throughout these four years, I collaborated with and learnt a lot from (in no particular order):

• Andre – we owned [redacted] together through ObjectStateFormatter deserialization

I came across a host and using all of my techniques when it comes to attacking .NET applications, I was able to find a few serious issues, but not command execution. At the time, research was released around how it is possible to achieve RCE through the VIEWSTATE parameter, via insecure deserialization, if you have the machineKey.

I enlisted Andre to help, and he was able to not only successfully leak the machineKey, but also was one of the first people to create a tool to exploit this vulnerability.

Andre’s heavy experience in CTFs were key to our success in this collaboration.

• Joel – we owned Facebook together through an XXE in a vendor product

I asked Joel for help when I was reversing a vendor product that Facebook had put up on their attack surface, under one of their corporate domains.

I was able to get the source code of this product by spinning up an AMI from Amazon’s Marketplace and then getting a shell on the deployed instance. However, when trying to debug a tricky potential XXE through XSD’s I wasn’t able to go further by just reading the source code.

I didn’t know why my exploits weren’t working.

Joel’s experience when it came to Java was key to our success here. He decompiled the jar files, he created an intelliJ project and fixed all of the errors. Then we started debugging it step by step.

It was an absolute pleasure watching Joel work this out and I look forward to collaborating with him in the future.

• Naffy – for helping me understand the best attack against Yahoo’s attack surface is persistence

I’ve known Naffy for almost a decade now, and the biggest thing I have taken away from him is that any attack surface can be broken into given enough time and effort. In the early days of bug bounties, Naffy was dominating the leaderboard for Yahoo’s bounty program – due to this he has a lot of experience with large attack surfaces.

Yahoo, now owned by Verizon, have an incredible amount of infrastructure and assets deployed on the internet. However, the noise on the attack surface is ridiculous to deal with.

What Naffy showed me was that with enough persistence and time, things break, and we have to be watching closely to capitalise on that.

• Sean – I’ve lost count of the number of things we have owned together

Every time I have been in a tricky situation where I struggle with exploiting an issue due to technical complexities or lack of knowledge, Sean has been the one to push through and help develop proof-of-concept exploits.

Sean has been able to translate high-risk security issues into automation very successfully and it has led to a lot of vulnerabilities that we have disclosed together.

• Oscar – I did a lot of collaboration on bounties with Oscar while I was at Bishop Fox

I used to talk with Oscar, daily, when I was at Bishop Fox. Oscar played a huge role when it came showing me how to hyper-optimise the speed at which DNS bruteforcing is possible.

While I worked with him, I found him to be incredibly switched on and most of all, a kind person. He has contributed to many bounty successes while I was working at Bishop Fox.

• Huey – we fine tuned my methodology on Uber together

JavaScript source maps are a brilliant way to better understand the internals of any client-side application. I look for source map files now every time I find JavaScript files, and that is thanks to Huey.

On Uber, we have used sourcemap files to better understand the GraphQL queries and API endpoints that are being used by Uber applications, to further exploit them. I have a better understanding of JavaScript thanks to Huey.

• Anshuman – we audited source code together for a PayPal live hacking event

For a recent live hacking event, we took apart the CMS called PencilBlue as it was being used by a particular target. Together, we had a blast auditing the source code, beating each other to different flows in the application source code and bonding over the speed at which we approach attack surfaces.

• Rhys – he helped me convert a stolen secret into an account takeover

At a live hacking event, I discovered credentials such as secret keys that were leaked through Google’s cached pages. A development asset which printed all of the environment variables and secrets in plain text was being proxied through ngrok, and Google had managed to not only index, but cache it, with all of the secrets in place.

After stealing these secrets from the cached copy, I asked Rhys to help me prove impact. He definitely delivered, by converting the tokens I stole, into an interactionless account takeover. Rhys is also very switched on. He won that live hacking event by miles.

• Mathias – read about our collaboration in a blog post from Assetnote.

We gained access to Mozilla’s internal AWS network by exploiting WebPageTest.

There are probably more people that I worked with over the years, but I cannot immediately recall. My point to you is that collaboration has been really important when it comes to growth and success in bug bounties.

Also please don’t just ask someone to hack something for you. In all of the cases above, the reason why collaboration was so successful was because the initial triage was done by either party. There was always the initial foothold or concept that was shared out of trust, which then led to actual collaboration on the issue. Don’t expect people are going to exploit things for you without presenting at least half the exploit chain or idea.

As I’ve talked about previously in this presentation, my methodology still revolves around the identification of assets belong to an organization on the internet.

The speed of asset identification and content discovery has increased tremendously. This is partially due to the fundamental shift in the security scene from writing tools in Python, to writing them in Golang or Rust, due to the speed benefits they entail.

We have also adopted this trend at Assetnote, and key components of our platform such as our in-house DNS resolver, has been re-written and optimized in Rust by Huey to take advantage of the speed it brings.

The one thing I have noticed when it comes to analysing an attack surface, is making sure that your tools output information in a way that highlight relationships. For example, the output of most fast DNS bruteforcing tools, simply sucks. Here’s how I prefer DNS data to be laid out – something that tracertea shared with me:

0.shopify.com -> wc.shopify.com. -> 23.227.38.64
0.0.shopify.com -> wc.shopify.com. -> 23.227.38.64
0.0.0.shopify.com -> wc.shopify.com. -> 23.227.38.64
0.0.0.0.shopify.com -> wc.shopify.com. -> 23.227.38.64
0.0.0.0.0.shopify.com -> wc.shopify.com. -> 23.227.38.64
0.0.0.0.0.0.0.shopify.com -> wc.shopify.com. -> 23.227.38.64
0.0.0.0.0.0.0.0.shopify.com -> wc.shopify.com. -> 23.227.38.64
0.0.0.0.0.0.0.0.0.shopify.com -> wc.shopify.com. -> 23.227.38.64

When you are looking at thousands of assets at once, you have no idea how much of a difference this optimisation can make. I can immediately recognise the relationships between the source and destination when it comes to analysing this DNS data.

It’s surprising that something so simple has had such a profound affect on me, but the same goes for color coding when displaying content discovery results. Most tools still lack in this area, and anyone who has had to spend the time combing through thousands of content discovery results will tell you that the task gets tiring quickly. Ultimately, I spend my time finding needles in haystacks, and colors make it so much easier.

When it comes to methodology, the program that has had the most profound affect on me is Uber, due to the ever changing attack surface.

In the four years, Uber has changed how they develop their software and deploy it. It has been extremely important to keep up with this and constantly reflect on the methodology being used to pierce through an attack surface. The continuous assessment of assets on the internet has been very effective against large attack surfaces in particular.

Attack surfaces are alive, evolving and complex at times.

When I first started hacking on Uber, I would see services such as Redis and HAProxy (admin panel) being exposed directly to the internet. I considered this to be an immature attack surface at the time as it was trivial to discover these security misconfigurations. But over the years, wow have they evolved.

These days, you simply will not find exposed services like Redis on Uber’s core attack surface, and this is a direct reflection of their processes and practices maturing internally when it comes to application security, and in a wider picture, their entire attack surface.

Instead, all of Uber’s internal and sensitive assets are routed to OneLogin at the DNS level. There have been cases where sensitive assets have slipped through the cracks and did not have OneLogin protecting them, but again, this is why monitoring attack surfaces continuously is so important.

Who knows? Someone could accidentally disable OneLogin protecting their assets for a short period of time, or spin up a sensitive asset that does not enforce OneLogin. Maybe because they are trying to test some changes, maybe because they don’t realise what they are doing.

I can confirm that the continuous monitoring of assets for security exposures is a core part of my methodology, and it is also the reason for why we inherently baked it into Assetnote.

Not included in this blog post is all of the work I put into the United Airlines bug bounty, and due to the terms and conditions of their bounty program, I cannot go into much detail, but I can say that their attack surface has helped me hone my skills in .NET application security testing.

When I initially looked at an IIS server four years ago, I wouldn’t know where to start. These days, I have a methodology that has proven to be extremely successful when it comes to IIS servers in general.

Due to this and so much more that I do when I am approaching attack surfaces, I plan on releasing more videos on our YouTube channel over the next year. Please subscribe if you haven’t already 🙂

Assetnote’s Continuous Security Platform puts the power of automated reconnaissance and large scale asset identification in the hands of security teams around the world, so that they can replicate our methodologies and successes. Knowing what assets and exposures an attack surface has is key to locking it down, and we do our best to help security teams from all over the world with this.

If you work at a business that could use help with identifying and monitoring your assets, please reach out to us.