
You’ve heard the stories. You’ve seen the six-figure payouts on Twitter. The world of bug bounty hunting promises a path where your hacking skills can earn you money and recognition, all while making the internet safer. But when you log into HackerOne or Bugcrowd for the first time, that dream meets a harsh reality: a wall of text, thousands of competitors, and a paralyzing uncertainty of where to even begin.
This is not another success story. This is a tactical field manual.
I’m a full-time bug bounty hunter. My journey didn’t start with a critical vulnerability. It started with a $50 reward for a simple misconfiguration that took me three days to find. It started with dozens of my reports being closed as “Duplicate” or “Not Applicable.” Failure is the entry fee to this profession.
Forget the highlight reels. This guide is built from the lessons learned in the trenches. It’s a direct, no-fluff methodology designed to take you from zero to your first valid bug report. We will focus on a repeatable process, not a list of tools. Let’s get to work.
Phase 1: The Mindset – Forge Your Armor First
Before you touch a keyboard, you must adopt the professional mindset. Technical skills are worthless without the correct mental framework. This is what separates a short-lived hobby from a career.
Embrace the “Duplicate.” It is Your Validation.
The first time you submit a bug and it’s closed as a “Duplicate,” you will feel a sting of frustration. Reframe this immediately. A duplicate is not a failure; it is proof that your process works. You found a legitimate vulnerability. The only variable separating you from the payout was timing. The lesson is not “I failed,” but “I need to be faster.” Your first ten duplicates are your rite of passage.
Read the Policy. It is Your Law.
Every bug bounty program has a policy page. This is the single most important document you will read. It defines your Rules of Engagement.
- Scope: It tells you what you are allowed to test (
*.company.com) and, more importantly, what you are not allowed to test. Hacking an out-of-scope asset is a fast track to getting banned. - Exclusions: It lists the types of vulnerabilities the program will not pay for (e.g., “self-XSS,” “logout CSRF”). Reading this saves you from wasting hours finding a bug they will immediately mark as “Not Applicable.”
- Safe Harbor: Look for a “Safe Harbor” clause. This is a legal statement that says the company will not pursue legal action against you as long as you adhere to their policy. Never hack on a program that doesn’t have one.
Think Like a Builder, Not Just a Breaker.
The best bug hunters understand how web applications are built. They know how developers think, where they cut corners, and what “quick fixes” lead to vulnerabilities down the line. Don’t just learn how to exploit SQL injection; learn how a database connects to a web server. Don’t just memorize XSS payloads; learn how a browser renders JavaScript. This deeper understanding is what allows you to find bugs that automated tools will always miss.
Field Note: Your reputation is the only currency that matters in this industry. A single act of irresponsibility—disclosing a bug publicly before it’s fixed, attempting to extort a company, accessing data beyond what is necessary to prove your finding—will destroy your career before it begins. The line is absolute.
Phase 2: The Starter Kit – Your Essential Toolkit
You do not need a massive arsenal of expensive, private tools to start. The majority of paid bugs are found with a small set of free, open-source tools, combined with a sharp mind.
Your Core Toolkit:
- A Target: Sign up for accounts on the two largest bug bounty platforms: HackerOne and Bugcrowd. This is where you will find programs to test on.
- An Intercepting Proxy: This is your single most important tool. It sits between your browser and the internet, allowing you to inspect, modify, and replay web traffic.
- A Notebook: Whether it’s a physical notebook, Obsidian, or CherryTree, you need a dedicated place to take notes on every target. Document everything: subdomains you find, interesting URLs, developer comments in the source code. Your notes are your personal intelligence database.
- Reconnaissance Tools: Recon is 70% of the battle. You need to map out your target’s attack surface. We will cover this in detail, but you will start by installing these foundational tools on your machine (e.g., Kali Linux):
subfinderorfindomain: For finding subdomains.httpx: For checking which of those subdomains are live and running a web server.
Do not get lost in “tool-chain hell.” Master these core tools first. They are more than enough to find your first bug.
Field Note: The process you are about to follow is your new standard operating procedure. Consistency is more valuable than genius. Following a repeatable methodology ensures you cover your bases and don’t miss simple bugs that others overlook. This is how you move from randomly poking at websites to professionally dissecting them.
Now, we move from mindset to methodology. This is your battle plan. We will cover the two most critical decisions you’ll make at the start: choosing the right target and executing a thorough, initial reconnaissance. Get this right, and you are already ahead of 90% of other beginners.
Phase 3: Target Selection – Choosing Your First Battlefield
Your first target will define your first experience. Choosing the right one can mean the difference between a quick, motivating win and weeks of demoralizing frustration. Beginners often make the mistake of jumping on the most famous programs (like Google or Meta), which are hunted by thousands of the world’s best researchers. We will not do that.
Our strategy is to find a target with a wide scope and less competition.
Your First Target Selection Mission:
- Go to the “Programs” or “Directory” page on HackerOne or Bugcrowd.
- Filter for programs with a wildcard scope (
*) that are also VDPs (no cash bounty). - From that list, pick one that looks interesting to you. It doesn’t matter which one. Commit to hunting on this single target for at least one full week. Do not jump between programs.
Phase 4: The Reconnaissance Run – Your First 24 Hours
Reconnaissance is the art of mapping your target’s digital footprint. Our goal is to turn a single domain (company.com) into a long list of potential targets (subdomains). This is the most critical phase of bug bounty hunting.
We will use a simple, two-step process: Subdomain Enumeration and HTTP Probing.
| Recon Phase | Objective | Recommended Tools | Example Command |
|---|---|---|---|
| 1. Subdomain Enumeration | Find as many subdomains of your target as possible (e.g., dev.company.com, api.company.com, internal.company.com). | subfinder, findomain | subfinder -d company.com -o subdomains.txt |
| 2. HTTP Probing | Check which of the found subdomains are actually running a live web server. | httpx | cat subdomains.txt | httpx -o live_hosts.txt |
Your First Recon Mission (Step-by-Step):
Assuming you have chosen company.com as your target and have your tools installed on a Linux machine (like Kali):
- Enumerate Subdomains: Open your terminal and run
subfinder. This tool will query various public data sources to find subdomains associated with your target.bashsubfinder -d company.com -o company_subdomains.txtsubfinder: The tool name.-d company.com: Specifies the target domain.-o company_subdomains.txt: Saves the output to a text file.- Let this run. It may take several minutes. When it’s finished, you will have a file named
company_subdomains.txtcontaining a list of potential targets.
- Probe for Live Hosts: Not all subdomains will have a live website. We use
httpxto quickly check which ones do.bashundefined
sh
cat company_subdomains.txt | httpx -o company_live_hosts.txt
“`
* cat company_subdomains.txt: This command reads the content of your subdomains file.
* |: This is a “pipe.” It sends the output of the first command as the input to the second command.
* httpx: The probing tool.
* -o company_live_hosts.txt: Saves the list of live websites to a new file.
Mission Complete. What Now?
You have successfully completed your initial recon run. You have turned a single target into a list of dozens, or even hundreds, of live websites. This list, company_live_hosts.txt, is now your primary hunting ground.
Field Note: Automation finds noise; manual investigation finds bugs. Your recon tools gave you a map of the battlefield. Now, your job is to walk the ground, inspect every door, and jiggle every handle. This is where patience and curiosity pay off.
Welcome to the final phase. In Part 1, we established the resilient mindset required to survive in bug bounty. In Part 2, you selected a suitable first target and executed a disciplined reconnaissance run, turning a single domain into a list of live web applications. You have your targets.
Now, we hunt. This final section covers the manual investigation process—how to systematically analyze each live host for low-hanging fruit. We will then cover the most critical skill that separates beginners from professionals: writing a high-quality bug report.
Phase 5: Manual Investigation – Finding Your First Bug
Your file, company_live_hosts.txt, is your mission brief. Your objective is to go through this list, one by one, and perform a quick, manual triage. Load each URL in your browser with Burp Suite running in the background.
Your goal is not to find a complex, zero-day vulnerability. Your goal is to find a simple, often overlooked misconfiguration. We are hunting for the “low-hanging fruit.”
Your Manual Investigation Checklist:
| Check For | What It Is & Why It Matters | How to Look For It |
|---|---|---|
| Old & Forgotten Pages | Companies often have old marketing pages, temporary landing pages, or internal-only sites that are accidentally exposed. These are rarely updated and often vulnerable. | Look for subdomains like old., dev., test., internal., staging., v1., or domains with years in the name (e.g., 2021.company.com). |
| Directory Indexing | The web server is configured to show a list of all files in a directory if no index page (like index.html) is found. This can leak sensitive files or source code. | Manually navigate to common directory names like /admin/, /uploads/, /backups/, /css/, /js/. If you see a file listing instead of a “403 Forbidden” error, you’ve found something. |
| Information Disclosure in Source Code | Developers sometimes leave comments in the HTML or JavaScript source code that contain internal IP addresses, API keys, or notes about features. | Right-click on the webpage and select “View Page Source.” Skim the code for comments (<!-- ... --> or //...) and look for interesting keywords like TODO, FIXME, API_KEY, password, or internal links. |
| Simple Cross-Site Scripting (XSS) | A vulnerability where the application reflects user input back onto the page without properly cleaning it. This allows an attacker to execute malicious JavaScript. | Look for search bars or any input field. Enter a simple test string like <h1>test</h1>. If the word “test” appears on the page as a large heading, it means the site is rendering HTML. This is a strong indicator of a potential XSS flaw. |
Your First Hunt (Step-by-Step):
- Set up Burp Suite: Open Burp Suite and configure your browser to use it as a proxy.
- Work Through Your List: Open the
company_live_hosts.txtfile. Go through it line by line. - Load Each URL: For each URL, load it in your browser.
- Observe and Triage:
- Does it load a modern, complex web application, or does it look old and simple? Older sites are better targets.
- Does it have a login page? A search bar? Any place to input data?
- Right-click and “View Page Source.” Quickly scan for comments or interesting file paths.
- Try navigating to
[URL]/robots.txtand[URL]/.git/to look for exposed files.
- Take Notes: In your notebook, for every interesting host, write down a one-line summary. ”
dev.company.com– Looks old, has a search bar.” or ”internal-api.company.com– Returns a 403 Forbidden error.”
This is a numbers game. Most hosts will be uninteresting. You are looking for the one or two oddities that everyone else ignored.
Phase 6: The Report – Securing Your Payout
You found something. Maybe it’s an old dev site exposing a directory, or a search bar that reflects HTML. Now comes the most critical part: reporting it professionally. A great report on a low-severity bug can earn you respect and a bonus. A bad report on a critical bug can get it closed as “Not Applicable”.
A professional bug report must be clear, concise, and reproducible. It should contain these key sections:
The Professional Bug Report Template:
text**Title:** [Vulnerability Type] on [Vulnerable Asset/URL] via [Parameter/Function]
**Summary:**
A brief, one-paragraph summary explaining the vulnerability.
**Steps to Reproduce:**
1. [First clear, simple step]
2. [Second clear, simple step]
3. [Third clear, simple step, etc.]
4. (Optional) Include the full HTTP request from Burp Suite here.
**Proof of Concept (PoC):**
Include a screenshot or a short video (if necessary) demonstrating the bug. For an XSS, a screenshot showing the executed payload is perfect.
**Impact:**
A realistic assessment of what this vulnerability could allow an attacker to achieve. Focus on confidentiality, integrity, and availability. For example, "This could lead to the theft of user session cookies, resulting in account takeover."
Submit your report. Be professional and patient in your communication with the triage team. Even if it gets closed as a duplicate, thank them for their time and move on to the next target.
Conclusion: The Journey Begins
This guide has provided you with a tactical framework: a resilient mindset, a core toolkit, a target selection strategy, a reconnaissance methodology, and a professional reporting template. You have everything you need to find your first valid bug.
The path ahead will be filled with challenges. You will face duplicates, “Not Applicable” reports, and days where you find nothing at all. This is normal. This is the job. Every bug hunter you admire has walked this same path.
Success in this field is not a result of a secret tool or a magical payload. It is the direct result of disciplined, persistent effort over time. Now, go hunt.
Bug Bounty Hunting: The Complete FAQ
Getting Started & The Mindset
- Do I need a computer science degree to do bug bounties?
Absolutely not. Bug bounty is a meritocracy. Your ability to find valid bugs is all that matters. Many top hunters are self-taught.shubs - How much money can I realistically make as a beginner?
You should expect to make $0 for your first few months. Your initial goal is not money, but getting your first valid bug acknowledged, even if it’s just for reputation points. Your first payout will likely be small ($50-$200).reddit - Is it too late to start bug bounty hunting in 2025? Is it too saturated?
No, it’s not too late, but it is extremely competitive. You have to be persistent and strategic. While the easy bugs on major programs are gone, new programs and new features are launched every day, creating new opportunities.reddit - How many hours a week do I need to commit?
To see progress, you should aim for at least 10-15 hours per week. Consistency is more important than intensity. Hunting for two hours every day is better than a single 14-hour session on a weekend. - What’s the difference between a bug bounty and a penetration test?
In a bug bounty, you are paid per valid bug found (a “pay-for-performance” model). In a penetration test, you are paid a fixed rate for your time, regardless of how many bugs you find.mindmajix - What’s a VDP (Vulnerability Disclosure Program)?
A VDP is a program that provides a safe harbor for security research but does not offer cash rewards. They are the perfect place to start because the competition is much lower, allowing you to practice finding and reporting bugs without pressure.gist.github - What does a “Duplicate” report mean and why do I keep getting them?
It means you found a valid bug, but another hunter found and reported it first. It’s the most common outcome for beginners. It’s not a failure; it’s validation that your methods work. You just need to get faster.reddit - What does an “N/A” (Not Applicable) report mean?
It means the security team has reviewed your submission and decided it is not a valid security risk according to their policy. This often happens when you report something that is explicitly listed as “out-of-scope.” - What is a “Safe Harbor” clause and why is it essential?
It’s a legal statement in the program’s policy that promises the company will not take legal action against you for your security research, as long as you stay within the rules. Never hack on a program that doesn’t have one. - What is the most important soft skill for a bug bounty hunter?
Persistence. You will spend 99% of your time finding nothing. The ability to handle this rejection and keep hunting is what separates successful hunters from those who quit.hackerone+1
The Toolkit & Reconnaissance
- Do I need paid tools or a VPS to start?
No. All the tools you need to find your first bug are free and open-source (like Burp Suite Community, subfinder, httpx). A VPS (Virtual Private Server) is useful for running long scans, but it’s an optimization for later, not a requirement to start. - What is the single most important tool I need to learn?
Burp Suite. It is an intercepting proxy that sits between your browser and the internet, allowing you to see and manipulate all the traffic. You cannot be a web application hacker without mastering it.gist.github - What is reconnaissance (recon)?
It’s the process of mapping out your target’s digital footprint. The main goal of recon is to find as many of the company’s websites (subdomains) as possible, especially old or forgotten ones, as these are often the most vulnerable.infosecwriteups - What is subdomain enumeration?
It’s the process of finding subdomains for a target (e.g., findingdev.company.comandapi.company.comfor the targetcompany.com). Tools likesubfinderandfindomainautomate this.dev - What is HTTP probing?
After you have a list of thousands of potential subdomains, you need to check which ones are actually live web servers. A tool likehttpxquickly probes each one and gives you a list of live sites to investigate. - My recon scan returned thousands of subdomains. What do I do now?
This is normal. Your next step is to usehttpxto see which ones are live, and then manually go through the list of live sites, looking for interesting or unusual ones. - What makes a subdomain “interesting”?
Look for non-production names likedev,test,staging,uat,qa,beta,vpn, or anything with a version number likev1orold. These are often less secure than the main production website. - Should I use automated vulnerability scanners?
As a beginner, no. Relying on scanners teaches you nothing. They are noisy, often miss critical bugs, and most bug bounty programs forbid their use. You must learn to find bugs manually.intigriti - What operating system should I use?
A Linux distribution like Kali Linux or Parrot OS is recommended, as they come pre-installed with most of the tools you will need. - How important is learning to code?
It is very important for long-term success. Learning a language like Python or JavaScript will allow you to automate your recon and write your own tools. However, you can find your first bug without being a coding expert.gist.github
Finding Your First Bug
- What is the easiest type of bug for a beginner to find?
There is no single “easiest” bug, but common first finds include Information Disclosure (finding sensitive data in source code), broken links that can be taken over (subdomain takeover), or simple Cross-Site Scripting (XSS) on a forgotten subdomain. - What is a “low-hanging fruit” bug?
These are simple, often configuration-based vulnerabilities that are easy to find but often overlooked. Things like exposed admin panels with default credentials or publicly accessible.gitdirectories. - Should I hunt on
www.company.comor their subdomains?
As a beginner, focus almost exclusively on the subdomains. The main website has been tested by thousands of hunters. An old subdomain likeblog-archive.company.commay have been tested by no one. - How do I know what a company’s technology stack is?
Use a browser extension like Wappalyzer. It can often identify the web server, programming language, frameworks, and analytics tools used by a website, which can help guide your testing. - What is a “Google dork”?
It’s a specialized Google search query that uses advanced operators (likesite:,inurl:,filetype:) to find specific information that a company may have accidentally exposed on the internet. For example,site:company.com filetype:pdf confidential. - What is a “subdomain takeover”?
This happens when a subdomain (e.g.,blog.company.com) points to a third-party service (like GitHub Pages or Heroku) but the page on that service has been deleted. An attacker can then create their own page on that service and claim the subdomain, effectively taking it over. - What is reflected XSS?
It’s a type of Cross-Site Scripting where a malicious script is injected into a URL parameter (e.g.,...?search=<script>...) and the server “reflects” that script back in the HTML response, causing it to execute in the victim’s browser. - How can I practice hacking legally without being in a bug bounty program?
Use platforms specifically designed for it, like PortSwigger’s Web Security Academy, TryHackMe, or your own home penetration testing lab. - I’ve been hunting on one program for a week and found nothing. Should I switch?
It’s a balance. Sticking with one target allows you to learn it deeply. However, if you feel completely stuck, it’s okay to switch to a new program to get a fresh perspective. Don’t jump between targets every day, though. - Where can I learn about new hacking techniques?
Follow other bug bounty hunters on Twitter, read public write-ups on platforms like HackerOne’s Hacktivity, and read blogs from security research teams.
Reporting & Communication
- What is the most important part of a bug report?
The Steps to Reproduce. If the security analyst can’t reproduce your bug, they can’t validate it. Your steps must be simple, clear, and work every time.yeswehack - What is a “Proof of Concept” (PoC)?
It’s the evidence that your bug is real. This can be a simple set of steps, a URL, a screenshot, or a short video demonstrating the exploit.intigriti - Should I exaggerate the impact of my bug to get a higher payout?
Never. Security analysts can see through this immediately, and it will destroy your credibility. Be realistic and honest about the impact. A professional report on a low-severity bug is better than a hyped-up report that is not credible.bugcrowd - How long does it take for a company to respond to my report?
It varies wildly. Some programs respond in hours; others can take weeks or even months. Be patient. Nudging the program repeatedly is unprofessional. - My report was triaged. What does that mean?
“Triage” means the first line of security analysts has confirmed that your report is valid and reproducible. It has been passed along to the internal development team for a fix. This is a great sign! - My bug was fixed, but I haven’t been paid yet. What should I do?
Be patient. The payment (bounty) process is often separate from the fixing process and can take time. If it has been over a month since the fix, a single, polite follow-up is acceptable. - Can I work with other hunters?
Yes, collaboration is common. However, be very clear about the split percentages before you start working. A common split is 50/50, but it can vary based on who did what.shubs - What is a “disclosure”?
This is when the details of your bug report are made public after the bug has been fixed. This is a great way to build your reputation and help others learn. Always ask for permission before disclosing a report. - The company and I disagree on the severity of a bug. What should I do?
Respectfully state your case, providing a realistic attack scenario. If they still disagree, accept their decision gracefully. Arguing with the security team is a bad look and will harm your reputation.hackerone - English is not my first language. Will this affect my reports?
As long as your report is clear and the steps to reproduce are easy to follow, it will be fine. Use simple, direct language. You can use a bug report template to help structure your thoughts.github
The Career Path
- Can bug bounty hunting become a full-time job?
Yes, for a very small percentage of elite hunters. For most people, it’s a way to earn extra income, build skills, and have fun. It is extremely difficult to make a stable, predictable living from bug bounties alone.reddit - Does finding bugs help me get a job in cybersecurity?
Absolutely. A list of valid, acknowledged bugs on your HackerOne or Bugcrowd profile is concrete proof of your practical skills and is often more valuable to employers than a certification. - What skills should I learn after I’ve mastered the basics of web hacking?
Consider specializing in areas like mobile application hacking (iOS/Android), API security, or cloud security. - What is a private program and how do I get invited?
Private programs are not visible to the public and are invite-only. You get invited by consistently submitting high-quality reports to public programs and building a good reputation on the platform. Private programs are often less competitive and have better payouts.sec.cloudapps.cisco - What’s the difference between HackerOne and Bugcrowd?
They are the two largest platforms and are very similar. Some hunters prefer one over the other, but as a beginner, you should have a profile on both to maximize your opportunities. - I’m feeling burnt out and frustrated. What should I do?
Take a break. Burnout is very real in bug bounty. Step away for a week, work on a different skill, do some CTFs, and then come back with a fresh perspective. - What is a “live hacking event”?
These are exclusive, in-person events where a company invites a group of top hackers to test their products over a couple of days. They are highly competitive but offer large prize pools and a great networking opportunity. - How do I build a network in the bug bounty community?
Engage positively on Twitter, share what you’re learning, write blog posts about your findings (after disclosure), and help other beginners who have questions. - Should I focus on one type of bug or learn many?
When you start, it’s good to learn the basics of many bug types (the OWASP Top 10). As you gain experience, you may find you are particularly good at finding a specific type of bug (like XSS or SQLi), and specializing in that can be very profitable. - What is the one piece of advice you would give to every beginner?
Don’t give up. Your first valid bug might be your 1st report or your 100th. The only people who fail are the ones who stop trying. Every “Duplicate” and “N/A” is a lesson. Learn from it and keep hunting.