Get Paid: Your First Bug Bounty
ToxSec | Cashing in on your first bug bounty program.

You’ve put in the hours, crushed the labs, and maybe earned a certification. You’ve picked a platform, like HackerOne, Bugcrowd, or Intigriti, and are looking at a list of programs. The common question is: “How do I turn these skills into cash?”
This guide won’t rehash vulnerability classes you already know. It’s a direct, practical framework for applying your lab skills to live targets to land your first paid bug.

0x00 The Mindset: From Hobbyist to Pro
Hunting for bounties is a business. To get paid, you need to operate like a professional, not a hobbyist.
- It’s a Marathon, Not a Sprint
You probably won’t find a paying bug in your first hour or even your first day. Top-tier hunters can go weeks without a find. Profitability depends on persistence and methodically understanding how an application works to find vulnerabilities others have missed.
- Embrace the “N/A”
Most of your attempts will result in a “Not Applicable” finding. This isn’t failure. Each dead end teaches you about the application’s defenses, helping you focus your billable hours on more promising areas.
- Read the Rules. Twice.
The fastest way to waste time is to submit out-of-scope bugs. Before you do anything, read the entire program policy. Your time is money, so focus only on what the program will pay for:
In-scope and out-of-scope assets.
Excluded vulnerability types (e.g., “Self-XSS,” “Username Enumeration”).
Rules of Engagement (e.g., “No DDoS testing”). Getting banned is bad for business.
0x01 The Setup: Maximizing Your ROI
Systematic preparation maximizes your return on investment (ROI). Don’t start randomly.

Don’t start with Google or Apple. These programs are saturated with top talent, lowering your chances of finding a unique, paying bug.
Look for programs with a wide scope, like
*.example.com. This provides more surface area to find bugs before others do.Consider starting with a VDP (Vulnerability Disclosure Program). Think of it as an unpaid internship. You won’t get cash, but you’ll get a real-world portfolio and reputation you can leverage later.
Check response times. Platforms often display program statistics. A responsive team means faster triage, faster validation, and faster payment.
Interpreting the Scope
Example: If the scope is
*.api.example.com,v1.api.example.comis a potential payday, butwww.example.comis a waste of time.Make a list. A simple text file of your paying targets will keep you focused.
Gathering Your Tools
You don’t need expensive tools to start. Your core money-making toolkit is:
A proxy like Burp Suite Community or OWASP ZAP.
Your browser’s developer tools.
A simple text editor for notes.
Pro-Tip: Use a separate browser profile for hunting to keep your work organized and efficient.
0x02 The Hunt: Finding Bugs That Pay
With your target selected and tools ready, it’s time to find a vulnerability that will cash out.
Step 1: Reconnaissance
For wide-scope targets, start with subdomain enumeration. Tools like
subfinderor online services like crt.sh can uncover forgotten assets that are often less tested and more profitable.Look for more than just websites. Run a quick port scan (
nmap -T4 -F) on your discovered subdomains to find other potentially vulnerable services.
Step 2: Manual Exploration
Pick one application from your recon list that has complex features (e.g., user profiles, complex forms, file uploads). Complexity is where bugs, and money, hide.
With your proxy on, use the application. The goal is to understand the application’s logic. Your proxy history is a map to potential payouts.
Step 3: Looking for Low-Hanging Fruit to Build Confidence
Target common vulnerability classes to get your first payment quickly.

Reflected XSS: Use a simple payload like
“><script>alert(document.domain)</script>in every URL parameter and form field.IDOR (Insecure Direct Object References): If you see a URL like
/user/profile/554, try changing the number to555. Accessing another user’s data is an almost guaranteed payout.Information Disclosure: Check the source code (
Ctrl+U) for developer comments or hardcoded keys. Check for exposed files like.git,.env, orrobots.txt. These are quick wins.
0x03 The Payout: Writing Reports
Finding a bug is step one. Writing a report that gets you paid is step two. Think of your report as an invoice.
Verification
Can you reproduce the bug consistently?
Is it in scope? Check the policy again to make sure you’re eligible for payment.
What is the real-world impact? Higher impact means a higher bounty. How could an attacker use this to make or cost the company money?

Writing a High-Quality Report
Clear Title: “Reflected XSS on
example.com/searchvia theqparameter”Vulnerability Type: Cross-Site Scripting (Reflected)
Step-by-Step Reproduction:
Go to
https://example.com/searchIn the search box, enter the payload:
“><script>alert(1)</script>Click “Search.”
Observe the JavaScript alert box that appears.
Proof of Concept (PoC): Screenshots or a short GIF are your evidence.
Impact: Explain the financial or security risk. “An attacker could send a victim a malicious link. If clicked, the attacker could execute JavaScript in the victim’s browser, allowing for session cookie theft and account takeover, leading to financial loss or data breach.”
Submitting and Waiting
Submit the report. Be patient; triage is part of the payment process.
Remain professional and polite in all communications. Good relationships can lead to faster payouts and even private invites.

Conclusion: It’s a Business
The process of reconnaissance, exploration, testing, and reporting is the core loop of your bug hunting business. Finding your first bug validates this process and your skills.
Expect duplicates and ‘Not Applicable’ reports; they are the cost of doing business. Treat each one as a learning experience. With each valid submission, you are contributing to a safer internet.

Now, pick a program, read the scope, and start hunting. Good luck.
Want more information on writing effective bounties? Check out the ToxSec blog here.




