Impact: What new bounty hunters still get wrong in their reports

Hola Friends,

It's been a minute since my last post. How are you? Do you feel like you've been living in an alternate timeline? Like everything feels slightly "off" ? Or perhaps it is me, having a moment, and as I'm getting older I'm finding issues with things I used to tolerate. And don't get me started with this AI silliness. Dios mio! That's a topic best left for another time.

Today, I wanted to discuss a consistent topic I keep seeing on reddit (my confirmed addiction), and that is: raging against the bug bounty triage process for reports that are either getting ignored, or simply disqualified for lack of evidence. I go into it a bit more in this post.

If you are new to bug bounty hunting, like I am, keep reading. This is for you. The magic word for today is: impact!

The Problem

I can't speak to the triage process associated on each bug bounty platform, but a recurring theme remains consistent:

• Step-1 — Initial Evaluation: A report is evaluated for quality, language, scope adherence, and demonstrable impact. This is now being automated with AI, so there's argument to be made for reports getting disqualified by bots, but all I have is anecdotal evidence.
• Step-2 — Manual Evaluation: Once a report has passed the first step of the evaluation process, it gets looked at by a person with some experience to testing and familiarity with the program. This is where a quality report matters in terms of reproduction steps, a viable POC, and demonstrable impact.
• Step-3 — Reward: If Steps-1 and 2 have been successfully completed, the report is handed off to the client for follow-up. This will be where the report (vulnerability) is accepted and the bounty rewarded.

And so, in a nutshell, the process is what it is. The step most hunters get tripped up at is where demonstrable impact is required. A hunter will insist that their vulnerability is legit and that they have successfully presented an issue. However, the problem they have is bias. The hunter will lose objectivity and fail to see where the problem with the report lied:

• The issue was out of scope — a common occurrence.
• The issue failed to demonstrate risk to the system.
• The issue did not have a viable proof-of-concept.
• The issue did not directly violate the C.I.A. triad — Confidentiality, Integrity, or Availability.

The Recommendation

Dear hunter, if you've made it this far, all is not lost. Remember you have worth. A rejected report is not an indictment on your skills. It just means you need to do better, or as the OSCP adage states, Try Harder!

When you do file a report, review the quality and integrity of the vulnerability you are describing. Is it showing impact? Is there a viable proof-of-concept? Are the steps clear? Did you provide enough evidence? I could go on, but you get the picture.

What you should NOT be doing is running to reddit for every rejection and complaining about the process if you have not done your due diligence prior to your submission. What you need to understand is that the report is as much a reflection of the platform you are working with, as much as it is a reflection of what you offer to the program you are testing. Low quality reports repeated over time will lead to a poor rating, or worse.

For better reporting advice, visit: https://kongwenbin.com/bug-bounty-9-tips-to-writing-good-bug-bounty-reports-part-1/

Conclusion

Follow this list and review your report twice before submission. And for the love of all things holy, STOP USING AI! This is gumming up the triage process and making everyone's life difficult.

And there you have it. I hope this helped you, dear hunter, get over the idea that triage is the enemy.

Ciao for now