Thread by @SecGus

I've been at HackerOne for about 5 months now. It's been eye-opening seeing how all of these hackers work from the other side of the screen. Here is a list of some of the tips I've gathered 🧵🧵🧵 #BugBounty #BugBountyTips

Most of the prolific hunters will focus on one target for large amounts of time, learning the ins and outs of the application.

If you are going to go for low hanging fruit, focus on building outstanding automation and recon lists.

Data analytics to identify what works and what doesn't is extremely underrated in the bug bounty field, and can be set up to passively analyze what is generated from automation.

Use nuclei templates only as inspiration for your own custom templates. By relying on the public nuclei templates you are setting yourself up for dupes and disappointment.

It's worth picking a technology, finding ways to fingerprint said tech from a blackbox perspective. Then get extremely good at exploiting said service and formulate a list of targets which use the tech (this could be used to easily identify misconfigurations for example).

Good recon is just as important (if not more important) than exploitation. Even the worst hacker could find an XSS if it's on a half-arsed asset the development team forgot about years ago.

Just because a report get's triaged and resolved, don't forget about it! Set up passive automation to check if the bug ever regresses into a vulnerable state.

Keep track of all submitted bugs - even ones closed off as informative or N/A. Future changes in application or in program policy may make them valid.

Collaborate! Some of the biggest payouts are seen from hackers collaborating, and it's definitely more fun.

Familiarise yourself with technologies like docker and kubernetes for both automation and a quick way to spin up specific tech.

Be patient and respectful with triagers. We look at hundreds of reports per week and sometimes we make mistakes. A gentle nudge instead of a passive-aggressive message goes a long way :)

If you see a subdomain with a single numerical value (i.e. testserver1.example.com), check for other subdomains by iterating over the integer (you may find another vulnerable host).

Read the program policy carefully and make a small summary of things that may be relevant to you, such as rules that apply to a common bug type. This will help avoid disappointment and N/A later on.

I'll keep this updated as my time at HackerOne goes on. I hope this is helpful :)