$9240 Bounty in 30 days Hunt Challenge

You can read my first write-up about command injection here: Uncovering a Command Injection, $2400 Bounty.

Methodology

Year one was wide recon — DNS bruteforce, Nuclei runs, infrastructure mapping. Around $6k earned and a solid grasp of the wide-recon mindset. Year two: switching to narrow recon — targets with limited scope (*.target.com or just target.com), Burp + the application, deeply analysed auth and payment flows.

July, August

The tally after two months of part-time narrow-recon hunting across multiple targets:

• Triaged: 6 · Duplicate: 8 · Informative: 4 · N/A: 7 · All: 25 · Bounty: $350

A few of the more interesting findings from that stretch:

PII Leakage

Sign-up flow. If the email already existed, the response leaked the user's PII.

PII Leakage 2

The collaboration "suggest" endpoint returned not just name + email but addresses and phone numbers too:

Reflected XSS

On admin.target.com's sign-up page, fuzzing JS variable names surfaced an appURL parameter reflected inside a script tag. </script><script>alert(origin)</script> popped:

Reflected XSS → Admin ATO

Same XSS, weaponised into an authenticated request flow against admin.target.com:

The program later marked three of these N/A claiming the asset wasn't theirs and went silent on the remaining triaged ones. After three months without payout I left BugCrowd, moved to HackerOne, and immediately ran into a wall of duplicates and N/A.

Self-Assessment & Debugging the Mindset

Two months of effort with nothing to show. Mental fatigue. I took a few days off, opened the laptop again, and instead of touching a target I started asking myself questions:

• Do I know enough for bug hunting?
• Can the platform affect my success? If yes, why hasn't HackerOne fixed it?
• Am I doing okay, or just unlucky?

I went hunting for answers. A few resources that helped:

• Grzegorz Niedziela's YouTube playlist on the pentest → bug bounty transition.
• A tweet from Hazem showing his August results from a single program:

• A direct message to Justin Gardner. He replied:

• And a chat with Mohammad Zaheri on goal-setting and avoiding burnout.

The takeaway:

• Focus on a single program.
• Set a clear goal.
• Begin a specific challenge.
• My knowledge might not be perfect, but it's sufficient to find things based on previous findings.
• Sometimes it's just luck — but you can stack the odds.

September

I picked one program based on bounty + response-time tables and started a 30-day challenge:

Result of the 30-day challenge:

• Triaged: 9 · Duplicate: 3 · Informative: 1 · N/A: 1 · All: 14 · Bounty: $9,240

Quick sketch of each find:

1. CORS Misconfiguration. Hosting let me register an arbitrary subdomain; an API on api.target.com trusted *.arbitrary.targetsite.com for CORS. Denied — Lax cookies + Firefox protection.
2. Cache Deception. https://dashboard.target.com/my-profile/username/.css was cached.
3. Business Logic Error. On payment.target.com the "domain already registered" check ran on the response side; manipulating the response let me invoice an already-taken domain.
4. CSV Injection. Contact-form messages exported by the admin as CSV; =4+4 rendered as 8.
5. HTML Injection in Email. Same contact form — sender name rendered as HTML in the admin's notification email.
6. Weak Password-Protect Function. The page builder offered password-protection that ran client-side; the data stayed reachable in the DOM. Reported as High; the program initially downgraded it, then accepted my argument:

   

   

   

7. Access to Unpublished Posts. Direct request to a private post URL loaded the content; addresses were guessable.
8. 2FA Bypass via Authenticated Cookie. The login flow ran through an anonymous → upgraded session converted to a JWT at a "converter" page. With 2FA the upgrade goes through /login/key/<random>. Swapping the 2FA-enabled victim's session ID for an attacker's converted anonymous session and refreshing produced a JWT for the victim.
9. Pre-Account Takeover. Sign-up didn't require email verification. Pre-creating an account for [email protected] let me wait until the victim signed up via Google OAuth — the previously-saved token then gave access.
10. Reflected XSS → ATO. Re-using parameters from /login/key/<random> on the previous page produced a tag break and a reflected XSS. Exploit code grabbed the JWT.
11. ATO via Grant Access. The "request access" feature emitted an auth token to the granting attacker that survived the victim revoking access.
12. 2FA Bypass via Grant Access. Adding a dot to the email ([email protected]) made the backend treat it as a new user — the link bypassed the 2FA-prompt flow entirely. Exploitation needs the victim's mailbox, but it bypasses Google Authenticator on already-authed accounts.

Conclusion

Three months of bug bounty taught me it isn't just technical knowledge — mindset and the right kind of community matter just as much. Pick a program, set a goal, debug the mindset when output stalls, and ask people who've been there.