Thank you for doing this interview! Can you please introduce yourself?

My name is Ibram Marzouk, and I usually go by @ibram or @0xibram. I’m 15 years old and currently living in Virginia. I started as a web developer about 4 years, but then got interested in bug bounties because I thought the idea of getting paid for hacking applications was awesome. I have been doing bug bounties for about 18 months now and I usually hack on Bugcrowd and HackerOne.

Q: How do you manage your personal life, work, and bug bounties? Do you do bug bounties as a job or a hobby?

I only do bug bounties for fun and to improve my skills (and some extra cash as well ;)). It’s really just a hobby for me, however when I first started I used to spend all my time doing bug bounties and that impacted my personal life and I didn’t have time for anything else so I had to switch to part time. I don’t have a job so my day is basically going to school and then I would start hacking or work on other projects at night.

Q: How much time do you spend on Hunting for Bugs? On average, how many bugs do you think you report per month?

I usually spend about 20 to 30 hours a week hunting for bugs. This changes a lot though and it really depends on the amount of free time I have, my schedule, etc. I usually report 10 to 20 bugs every month but that usually increases when, for example, I receive more invitations to private programs.

Q: How long did it take you until you found your first significant/high impact/payout vulnerability?

My first high severity bug was discovered about 6 months into bug bounty. It was an IDOR vulnerability that I discovered in an internal API endpoint. This IDOR vulnerability allowed me to access support tickets by other users which usually contained PII.

It all started after I noticed they were using api.example.com/v1 in all API calls so I decided to run wfuzz on api.example.com/* and see if they have anything else on that subdomain. The tool found /v1 which was expected, however, it also found /internal. As you’ve probably guessed, this was an internal API. Running wfuzz on api.example.com/internal/* returned some interesting results. One of the results was /internal/docs which was a Swagger UI instance and it contained everything about this internal API. From there, I was able to test all the endpoints and the only interesting endpoint was /get_tickets which returned all the support tickets of a user. I was awarded a $3k bounty for this issue.

Q: Of all the bugs you’ve found, what was your favorite/most interesting?

This is one of my favorite bugs just because I learned a lot about AWS while trying to exploit it and it was really fun.

So it all started when I noticed that the application I was testing had the option to use webhooks to get notifications. Such functionality is usually vulnerable to SSRF (btw, check out Jobert’s awesome post on SSRF). I already knew that the app was running on Amazon EC2 so the first that came to my mind was, of course, EC2 Instance Metadata. Cloud providers such as AWS, Google Cloud Platform, and DigitalOcean allows users (or applications) to retrieve information about the machine using a local address, which is 169.254.169.254 in the case of AWS.

So, after reading the EC2 metadata docs for a couple minutes, I tried to fetch the /latest/meta-data/hostname endpoint which returns the hostname of the machine… but it didn’t work unfortunately. My guess was that the application was comparing my input to some kind of list with dangerous IPs. About 20 minutes of trying to bypass that blacklist, I got the idea of setting up a domain that points at 169.254.169.254 and then using that domain as my webhook url hoping that application won’t check what the domain is pointing to. And it actually worked (yay!). So right now I had access to the EC2 instance metadata and I was ready to write my report.

I sent the report to the company’s team and they triaged it in less than an hour. However, I didn’t want to stop there and wanted to see how far I can go with this bug. I asked the team for permission to try to explore and see what can be done with this and they agreed. After reading the docs even more and doing some research, I had access to the credentials of this AWS account using the /latest/meta-data/iam/security-credentials/* endpoint. While still trying to go further, I stumbled upon this talk by Andres Riancho which talked about a very similar case to mine. Using his tool, nimbostratus, I was able to access the database of the application using the snapshot-rds module which uses the RDS API to create a snapshot of the DB, restores it, changes its password, and then changes its policy so that anyone can connect to it.

This bug was fixed in a couple of hours and the team was pretty happy about it!

Q: When and how did you have your breakthrough? When did you realize hacking and bug bounties was something you wanted to dedicate your time to? Please share your insights and the problems you faced to becoming an established bug bounty hacker?

I knew bug bounty, and hacking in general, is something that I want to do for living after I got my first bounty and knowing that I’m actually helping companies out there secure themselves while getting paid. One of the problems that I had when I was starting was that I never tried to dig deeper or think differently and always looked for common vulnerabilities which were usually duplicates. This is a very common problem for people who’re starting in bug bounty… so don’t look for common vulnerabilities!

Q: What do you do to keep up with all the new trends?

Twitter.

Q: Do you collaborate with other hackers? Can you name a few?

I’ve collaborated with @Zombiehelp54, @secgeek, @RojanRijal, and @samwcyo a lot before. I’m always down to collaborate with other hackers so let me know if you want to ;).

Technical Questions

Q: How do you approach a target? What is your routine like? What is your recon process like? What kind of information do you seek in your information gathering process? And how does this information help you?

I always start by doing recon. I start by using sublist3r, altdns, subbrute, censys.io to discover subdomain and hosts related to the target. Then, I’d start port scanning using masscan or nmap on the list of subdomain that I found in the previous step. While doing port scanning, I’d use gobuster or wfuzz for content discovery some of the lists from SecLists. I also look at robots.txt and previous versions of it on archive.org (thanks @zseano) because it will most likely contain interesting endpoints. While waiting for the previous stuff to finish, I’d start exploring the application and get to know it more. I use builtwith.com to try to find information about the technology stack that is being used because it might be helpful in exploiting some vulnerabilities later. Also, I try to find any developers blog or docs to help me understand the application even more.

I should have some decent information about the target by now and should be ready to find some vulnerabilities.

Q: Do you always look for all vulnerabilities types when you approach a website?

I usually look for most vulnerabilities types when testing a web application but sometimes this changes. So for example, if it’s an old program then I will test for high severity bugs only because the chance of finding them will be higher than low severity bugs. Also, it depends on the functionality that I am testing so if I’m dealing with a request that I think interacts with the server then I would test for the appropriate vulnerabilities only. I recently started reporting P1 and P2 bugs only just because I want to increase my average severity on Bugcrowd and signal and impact on HackerOne.

Q: Do you use any tools? Do you have your own tools that you have written to automate/facilitate your work? What Burp extensions do you use? Is there a tool that not a lot of people use that you think they should?

Most of the tools that I use are listed in the previous answers and all of them are for recon as I like manual testing. Here is a small list of the tools that I use: nmap, masscan, gobuster, sublist3r, altdns, censys.io, google, wpscan, sqlmap.

Q: This is one of our most popular questions: How do you test for Server Side vulnerabilities such as RCE, SQLi, etc?

As I said before, the types of vulnerabilities that I test for depend on the specific functionality or request that I’m currently testing. For example, if it’s a request that allows downloading files then I would test for LFI and if it’s an API that retrieves user information with a given user id then I would check for SQLi and so on… When testing for vulnerabilities like RCE, SQLi, LFI and most server-side vulnerabilities I try to look for weird behaviours. Does sending ’ gives you an error or different content and sending \’ gives no error and displays normal page? if yes, then you probably have SQLi (backslash powered scanning ftw). It’s just a matter of observing and guessing what happens on the back end and then testing for vulnerabilities that might work in this specific case.

Q: How often do you find a bug that has been overlooked after a bounty program has been established and a horde of researchers have been digging?

Very often. It’s very likely that you will find bugs in old programs because they push new code all the time which means new vulnerabilities are possible. I usually start testing new features (posted on their twitter account, blog, etc…) on old programs first just because less hackers have probably tested it.

Q: Do you think being a pentester, web developer, or being in a related field, helps you with bug bounties? Where should they start?

I personally think that it helps a lot. For example, having experience with the programming language or technologies that are being used by the target will definitely help in exploiting some vulnerabilities.

Time to wrap it up!

Q: What kind of music do you listen to?

I actually prefer to hack in very quiet environments but when I decide to listen to music, I just listen to piano or Spotify’s Top 50.

Q: What do you do when you aren’t hacking?

Playing video games (Overwatch mostly), hanging out with friends, shopping, and playing sports.

Q: What kind of impact/role have bug bounties played in your life?

Bug bounties have helped me financially and also in improving my hacking skills.

Q: What is an advice you received as a beginner that helped you with your bug bounty career?

“Keep digging.”

Q: What is one area of hacking (web, mobile, hardware, etc) you wish you knew more about / plan on focusing your learning on?

Binary exploitation and reverse engineering. I’ve actually started working on this recently.

Q: If someone with basic technical background asked you, “where should I start?”, what are 3 things you would recommend they do before diving into bug bounties?

1. Read. Start reading books (yaworsk’s Web Hacking 101 is a great example), blog posts/write ups by other hackers, and reports from HackerOne’s Hacktivity.
2. Practice. There are a lot of vulnerable machines and web applications that you download and start hacking. This will help you a lot.
3. Ask. Don’t be afraid to ask other people to help you figure out stuff. However, questions that a single google search can answer are no bueno.

Q: Someone was eager to know, what do you put on your toast?

Nutella ❤️

Q: What’s your worst bug bounty story/experience?

I don’t really have any very bad experiences so I don’t have an answer.

Q: If you had to pick one hacker to collaborate with, who would it be?

It’s really hard to pick only one hacker, but I’d choose Orange Tsai, he is just amazing!

Q: What’s the one feature you would like to see in the platforms?

The ability to split bounties with other hackers.

Q: What’s your favorite text editor?

Vim and Sublime Text.