I am Ben Sadeghipour (Nahamsec), I’m based out of California and I have been hacking since I was a teenager. I was introduced to bug bounties by a friend who asked me why I don’t use my hacking skills to make money (hinting to bug bounty programs). I started hacking on Yahoo when they were managing their program via emails. Eventually I signed up for an account on both HackerOne and Bugcrowd. Zerocopter has recently become another platform where I have started submitting a few reports here and there.
Bug bounties used to be a full time gig for me in 2016 but I do it now as a hobby and an extra source of income. I typically dedicate most of my time to my day job and family during the weekdays, but if I have a few hours during the night or the weekend, more than likely, I’ll be spending it on hacking. I generally try to make my plans ahead of time, so I know when I have free time to dedicate to doing bug bounties.
I spend about 15-30 hours a week on bug bounties, depending on workload and personal life. I usually report 15-20 bugs in a month.
My first impactful with a high payout bug was to Yahoo when I reported a few SQL Injections. It took me close to 6 months of hunting for bugs for almost 10 hours a day to finally be able to find something with high impact.
My favorite vulnerability was being able to get SSRF on a Dev environment that was on the internal (dev) VPN. It allowed me access to all the internal documents/apps owned by that company. Using some google/github searches, I was able to eventually get in a internal jenkins instance.
In February/March of 2016, I decided to set a goal to make a particular amount before the end of the year as well as move up on Bugcrowd and HackerOne’s leaderboard. I thought that if I set a goal and push myself to participate in bug bounties full time, I would learn more and gain more experience. In the very beginning I had a hard time finding bugs because I didn’t have a methodology/routine. I was all over the place and looking for different vulnerability types all at once. That lead me to not being able to find too many unique bugs. Eventually, I started forming a mental checklist of things I look for.
Twitter is a great tool if you follow the right people. I like reading other hackers’ blog posts or disclosed vulnerability on HackerOne. I have recently started sharing a lot of my ideas with a few friends and working with them has helped better my methodology. I got to see how they approach the same program, vulnerabilitiies or problems while hacking.
I have collaborated with @bbuerhaus, @Smiegles, @ITSecurityguard, @JobertAbma, and @Yaworsk on a few different ideas, vulnerabilities, or tools.
I like to first understand the purpose of the app and how things work. I usually try and use the app as regular user to get a better understanding of what it is meant to do. I also look into what kind of functionality they offer. For example: file uploads/external file fetches, how they access (personal/account) information, if they have a big presence on github to find common api calls, internal or dev/stage domains, etc.
Then I start doing my recon, like if there are internal subdomains in a particular pattern (i.e: domain.dev.target.com, domain.corp.target.com) and see if I can access them. I usually like using my own subdomain bruteforcer or knock.py. I have complied my own word list to brute force subdomains. If I find an interesting subdomain on a site that I don’t have on my word list, then I add it manually.
I have a small list of folders/endpoints I typically look for on subdomains. Directory bruteforcing is typically my last option depending on the app. If I find an interesting subdomain, then I may do some directory bruteforcing.
Nmap comes into play for bigger targets with a wider scope. I usually just run an nmap with a list of ports that I have selected. If I’m not in a hurry, I also like some of the scripts (like http-enum). This was a good place to start for me with nmap resources: https://hackertarget.com/7-nmap-nse-scripts-recon/ Shodan and censys are also are also a very good tool to find other properties that are owned by a company.
I also look for common parameter names on google by doing site:target.com +inurl:param. (example parameters: url, redirect, file, path, etc). As I have mentioned before, github is also another good tool to look at. You can usually find a ton of information about a target by looking them up on github. Doing so, allows you to find api/interesting endpoints, subdomains, internal apps, and etc.
I like looking for SSRF vulnerabilities. So anywhere that offers to fetch data from an external URL is where I look for vulnerabilities first. I typically first try and see if I can fetch anything from 127.0.0.1 or localhost. Then I move to port scanning (ip:port) and looking at how long it takes to respond. If all of those fail, then I move on to trying to just access a remote host with https://, http://, or ftp:// (or other protocols). If the first two work, I know that I can try using a php script to redirect them to other hosts using different ports/protocols.
I also enjoy looking for IDOR vulnerabilities. So if there are any API calls that access my profile/company data using a numerical ID on the app, I like to change as well. So if the site is looking at site.com/api/v1/userinfo/ID/address, I try and run a few different IDs. You can also use the burp intruder with numbers to brute force those values and see the difference in response lenght.
I have also recently started looking into mobile hacking. I typically use mobile applications to find extra endpoints that may not be used in the web app and I also look for hard coded keys for 3rd party services the program may be using.
Depending on the target yes. I like to first consider what vulnerability types are actually possible to find a specific target. Depending on the workflow, I pick which vulnerability types I prioritize.
I like automating my recon work as much as I can. I previously mentioned knock.py, but in cases I need extra data, I use sublist3r as well. As mentioned in one of my collaborative blog posts with Brett Buerhaus, we automate our JS recon work. So I don’t have to sit and go through hundreds of line of messy JS files.
Shodan and Censys have been two good resources to go and look for more properties belonging to programs with a wide (or wildcard) scope.
This is one of our most popular questions: How do you test for Server Side vulnerabilities such as RCE, SQLi, etc?
Over the years, I have compiled a list of payloads that may result in a weird behavior. I typically start with those payloads to test out how the application responds. If I see a weird behavior or a response, I start looking dig in deeper. I also look for applications with known vulnerabilities or default credentials that may be externally facing when they aren’t supposed to.
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?
There has been numerous times when I find simple vulnerabilities where I think they will be marked as a duplicate. Every hacker has a unique ways of approaching a target. Something that may be obvious to one person, may not be as obvious to another. So always approach a target without considering other hackers that have already looked at the program and their applications in scope.
I believe that knowing more about how things work and having that experience speeds up the process of understanding how an application works. If you are just starting AppSec/Bug bounty hunting, WAHH, Web Hacking 101, HackerOne’s Hacktivity, and twitter should be a great place to start. Also read what others are writing in order to learn how others overcome obstacles and challenges with specific vulnerabilties.
I listen to a lot of EDM, R&B, and Hip Hop. If I’m hacking and trying to focus, I usually go on youtube and listen to Trap Nation as well.
Hangout with family and friends. Play video games. I also like to travel.
I think bug bounties have changed my life for the better. It has helped me achieve a lot of long term life goals (financially) as well as allowed me to meet a ton awesome people that are interested in the same things as I am.
Don’t give up. The first bug is always the hardest, but once you find that first one, everything becomes a bit easier.
I know a tiny bit about mobile hacking but I have recently just started to learn more and more about mobile hacking.
I’m amazed that no one has said Nutella!!
A program didn’t see value in the vulnerabilities I sent them. Regardless of spending a week on them to report multiple RCE, XSS, CSRF, they ended up lowering the impact on all of them. When things like that happen, I have learned Twitter shaming doesn’t do any of us any favors and I take what’s given and move on with my life.
I have never actually collaborated with Frans or Mathias. I think those 2 hackers are on top of my list of hackers to collaborate.
Since I work with one of the platforms, I rather not make any comments on this one :)
I use Atom.