How to write excellent reports, techniques that save Triager’s time, and mistakes that should be avoided in reports

While bug hunting, accuracy and quality of the report plays an important role in results and rewards.

“My report was triaged and after a while the status was changed to duplicate. Why? Why is a valid report marked as n/a? I originally had a P1 report, but the status changed to P2 or P3. Why?” My answer: because reports aren’t always perfect.

Based on my experience and journey (completing nearly 150 P1 reports on Bugcrowd), writing reports can be very rewarding. I even got some awards for duplicate reports that I sent because the customer liked the report, POC, impact.

I will put some examples from my experience and previous reports and some mistakes that should be avoided in bugs/reports near the end of this blog, so be sure to check those out.

A) Report title

The first impression of the report is taken from the title, so it’s important to give the best explanation to show what the report is regarding.

Examples of low-quality titles:

• Sql injection in xxx.xxx
• XSS in xxx.xxx
• Github leaked password
• Admin account take over in xxx.xxx

Examples of high-quality titles:

• Sql injection in [xxx.xxx] parameter [xx=]
• Non-self reflected XSS in [xxx.xxx] parameter [xx=]
• Valid/internal data leaked via github for [xxx.xxx] domain
• Default credentials/auth bypass led to admin account take over in [xxx.xxx]

B) Description

The description should be brief and clear by explaining what the bug is and how you reached it.

Example of low-quality description (github leak):

• I found credentials leaked via github here https://github…… for domain xxx.xxx

Example of low-quality description (sql injection):

• I was testing xxx.xxx and I found sql injection on this panel

Example of high-quality description (github leak):

• I found valid/internal credentials leaked via github here https://github…… for domain xxx.xxx this data was leaked in **1/6/2022** by user xxxx and user xxxx employee https://linkedin……..

Example of high-quality description (sql injection):

• I was testing xxx.xxx and I found sql injection on this panel as post/get request parameter x = -*-*-*-*-*-*-*-*-*–*

Testing on wide scope:
If you find a bug on ip/domain while wide scope testing, you have to prove that the ip/domain is owned by the program by adding ssl check, reference from google/wikipedia/program/etc.. to save time for both the triage team and customer.

For example, I found a P1 on a wide scope program on domain. The client did not know that they had this domain, so the customer asked me to add my full recon steps for internal investigation.

C) Steps to reproduce

If the bug is easy to reproduce then it’s okay.

Example:

• Visit this end point xxx.xxx/…..
• Try this payload [xxxxxxxx]
• If not, you must add 2 steps to reproduce
  • 1) steps to reproduce for triage team
  • 2) steps to reproduce for customer team

Example 1: You access to end point and are allowed to create an account with full login information, then you access to some end and are allowed to inject.

• Include the steps to reproduce to save time for the triage team
  • Add your testing credentials that you used to create an account and the end point to inject and payload
• Include the steps to reproduce to save time for the customer
  • Full reproduce from a to z

Example 2: Sql injection in login panel as post request

• Include the steps to reproduce to save time for the triage team
  • Copy the request and add to the triage team to test directly with sql payload
• Include the steps to reproduce to save time for the customer
  • Full reproduction from a to z
  • Like “visit login page here xxx.xxx/…”
  • Log in with any user/password and intercept the request on login on burp
  • Test this payload on parameter username=xx etc…..

Note: If you used sqlmap, it might take a long time for you, so add full command for dbms and sql title to save time. For example, “sqlmap -r request –force-ssl –level 5 –risk 3 –dbms=”xxx” –test-filter=”title””.

D) POC: Proof of Concept

• Sql injection example:
  • Dbs name or host name is enough
  • Not ethical to dig deeper
• Leaked and/or default/weak credentials example:
  • Screenshot and/or recorded video is enough
  • Not ethical to dig deeper

E) Impact

The most important aspect of the report is to show impact. More than 70% of hunters just copy and paste general impact in the report, but you must understand the impact, as the bug might be the same, but the impact could be different. For example, stored XSS in your profile setting is not like stored XSS in normal endpoint.

Github leaked credentials example:

• If it’s an internal domain, it’s not like a live domain. It’s not cool to just add in impact [leaked data]. For example, with an internal credentials leak, you can’t access this host because it’s internal, so this would be a (P3) bug. But, you can test the same credentials on public hosts or get an ssrf on public asset to hit this internal service so this would be a (P1) bug.

Sql inaction example:

• Now public impact. An attacker can use sql injection to bypass a web application’s authentication and authorization mechanisms and retrieve the contents of an entire database. Sqli can also be used to add, modify and delete records in a database, affecting data integrity. Under the right circumstances, sqli can also be used by an attacker to execute os commands, which may then be used to escalate an attack even further.
• For example, let’s take a look at a critical sensitive data exposure in employees panels. Sqli in this panel leads to the following:
  • Critically sensitive data exposure about admins
  • Critically sensitive data exposure about systems
• For example, in a normal web app page, sqli in this panel leads to:
  • Critically sensitive data exposure about users
  • Critically sensitive data exposure about admins
  • Critically sensitive data exposure about systems
• For example, in a shopping domain, sqli in this panel leads to:
  • Critically sensitive data exposure about credit cards
  • Critically sensitive data exposure about users
  • Critically sensitive data exposure about admins
  • Critically sensitive data exposure about systems

F) Markdown

It’s necessary to focus on markdown when writing a report. You can find a cheatsheet for markdown here. Below, I will present the most efficient usages of them.

• # used for headers
  • #description
  • #steps to reproduce
  • #poc
  • #impact
• ` `
  • I use it for commands
  • `example`
  • `git clone ……`
  • `cd ….`
  • `python sqlmap…..`
• “` “`
  • I use it for requests, responses, scripts, leaked codes
  • “`
  • Example
  • “`
  • “`
  • Requests, responses, scripts, leaked codes
  • “`
• **
  • I use this to emphasize a note or an interesting part
  • **example**
  • **this data leaked 2 hours ago by employee…**
  • **xss/sql… here as post request parameter ?xx=**

Photos and videos also play an important role in reports! Why? For example, you find a bug and send the report. Then, the customer fixes it before the report was triaged. In this case, it acts as evidence, saves time for triagers, and avoids confusion.

Some mistakes that should be avoided in bugs/reports

1) If you find the same bug on different subdomains, submit them as one vulnerability. If you submit the same bug multiple times with different subdomains, you may self-duplicate your findings.

Example:

• The ssl recorded to *.test.bugcrowd.com and you found the same bug on dev.test.bugcrowd.com, uat.test.bugcrowd.com, admin.test.bugcrowd.com, admin-dev.test.bugcrowd.com, xxx.test.bugcrowd.com
• In this case, one report for all of these subs is enough
• 2) Same bug on same parameter, name on different end points – 1 bug, 1 report.

Example:

• 15 endpoint vulnerable to xss on parameter cid=
• This should be 1 report, not 15 reports

3) Ips reports: If you find the same bug for same sub domain on different ips, it’s just 1 report.

If you write an excellent report and show good impact, I guarantee that both the triage and customer team will cooperate with you, even if your report is a duplicate. I got 3 bounties on 3 duplicate reports.

Example:

• I found an employee’s credentials leaked on github, but without any host to test. So, I started looking deeper in all repositories for this employee on github. I started searching for hosts to test the credentials until I found one and when I tested it, I got the full login. I reported it, but my report was marked as duplicate. The Bugcrowd team was very cooperative and gentle with me.

Examples of comments from customers about writing reports

Thank you for reading this report. Keep on hunting!
Godfather Orwa | Bugcrowd

About Me: 

My name is Orwa Atyat and I am from Jordan. I’m a full-time bug hunter with 130+ P1’s submitted. I’m ranked 65th all-time on Bugcrowd and was awarded top 10 in the P1 Warrior Rank.