A Small Bug Bounty Toolkit: What Each Tool Actually Does

Bug bounties have revolutionized the security field, allowing organizations to crowdsource their security testing. Whether you're a seasoned hunter or just starting, having the right toolkit is essential. Here are the top 10 tools every bug bounty hunter needs in their arsenal.

What is Bug Bounty?#

Before diving into the tools, let's define the field. Bug bounties are crowdsourcing programs where organizations reward individuals - ethical hackers - for discovering and reporting security vulnerabilities in their systems. Rewards can range from cash prizes to job offers and swag.

The Essential Toolkit#

1. Burp Suite#

The Swiss Army Knife of Web Security

Burp Suite is arguably the most popular tool for web application security testing. Developed by PortSwigger, it acts as a proxy between your browser and the target application, allowing you to intercept, inspect, and modify traffic.

• Key Features: Proxy, Scanner (Pro), Intruder, Repeater, Decoder.
• Editions: Community (Free), Professional, Enterprise.

2. SQLMap#

Automated SQL Injection

SQLMap is an open-source penetration testing tool that automates the detection and exploitation of SQL injection flaws. It's incredibly powerful and can take over database servers if vulnerabilities are found.

• Capabilities: Database fingerprinting, data retrieval, file system access, and OS command execution via out-of-band connections.

3. Wappalyzer#

Technology Profiler

Knowing your target's stack is half the battle. Wappalyzer is a browser extension and tool that reveals the technologies used on a website.

• Identifies: CMS, frameworks, eCommerce platforms, JavaScript libraries, analytics tools, and more.

4. Shodan#

Search Engine for the Internet of Things

Unlike Google, which crawls web pages, Shodan crawls the internet for connected devices. It's a goldmine for finding exposed servers, webcams, IoT devices, and insecure databases.

• Use Case: Reconnaissance and finding assets that shouldn't be public.

5. Nmap#

Network Mapper

Created by Gordon Lyon, Nmap is the standard for network discovery and security auditing. It's used to Uncover hosts and services on a computer network by sending packets and analyzing the responses.

• Functions: Host discovery, port scanning, version detection, and OS detection.

6. Acunetix#

Automated Web Scanner

Acunetix is an automated tool that audits web applications for exploitable vulnerabilities like SQL Injection and Cross-Site Scripting (XSS). It's known for its speed and accuracy in scanning HTML5 and JavaScript-heavy applications.

7. Subfinder#

Subdomain Discovery

Subfinder is a tool designed for one thing: passive subdomain enumeration. It uses passive online sources to find valid subdomains for websites, which is a critical step in expanding your attack surface during reconnaissance.

• Pros: Fast, modular, and effective.

8. Google Dorking#

Advanced Search Techniques

Also known as "Google Hacking," this technique uses advanced Google search operators to find security holes, configuration files, and hidden data that websites have accidentally exposed to the public internet.

• Example: filetype:sql "password" or inurl:admin

9. Nessus#

Vulnerability Scanner

Nessus is a widely used remote security scanning tool. It checks computers for vulnerabilities that hackers could exploit. It runs thousands of checks to identify missing patches, misconfigurations, and malware.

10. DirBuster#

Directory Brute Forcing

DirBuster is a multi-threaded Java application designed to brute force directories and file names on web/application servers. It helps you find hidden pages and folders that aren't linked anywhere on the site.

• Note: While DirBuster is a classic, modern alternatives like ffuf or gobuster are also popular for this purpose.

Conclusion#

Guide to these tools will significantly enhance your bug bounty hunting capabilities. Remember, tools are just enablers - your creativity and persistence are what will ultimately lead you to the bugs. Happy hunting!

Task Map#

Burp Suite Notes#

Scope the target first. Every request outside scope slows the proxy and can break ToS. Use match-and-replace rules to attach a marker header; it helps tell scanner traffic from manual traffic in logs.

Shodan Query Patterns#

Copy code
http.title:"ViewState" port:443
org:"Example Bank" http.status:200
ssl:"example.com" port:8443

Shodan indexes banners, not the web app. An open Jenkins or an old Tomcat on a nonstandard port is what it catches.

sqlmap Invocation#

Copy code
sqlmap -u "https://target/item?id=1" --batch --dbs
sqlmap -u "https://target/item?id=1" -p id --level=3 --risk=2 --dump

--risk over --level widens payload classes; level widens parameter coverage. Do not run level 5 against production without a staging copy to confirm.

Nuclei Usage#

Copy code
nuclei -u https://target -t cves/ -severity high,critical
nuclei -l urls.txt -t misconfiguration/ -rate-limit 50

Rate-limit. Default templates are safe, but a 200-host list at full speed trips WAFs and gets the range blocked.

Triage Discipline#

Scanner output is input to triage, not a report. For each hit ask: is it reachable, is it exploitable, and would a customer notice if it were abused. Write that in the report; it is the part a triager actually reads.

Arjun: Parameter Discovery#

Copy code
arjun -u https://target/page -m GET --stable

Hidden parameters like debug, admin, callback, or redirect surface when the response length shifts. That shift is the flag to dig further.

dalfox for XSS#

Copy code
dalfox url 'https://target/search?q=test' -b https://burp:8080

dalfox pairs reflection detection with DOM checks. Review each claim; the tool reports candidates, you verify with the browser.

interactsh for SSRF#

Copy code
interactsh-client
# Use the generated subdomain in payloads like
# http://<sub>.oast.fun/img

When the server fetches your URL, the callback server logs host and path. That log is the evidence for SSRF.

waybackurls#

Copy code
waybackurls https://target | grep -E 'php|=|/api/'

Historical endpoints map the old surface: admin logins, staging hosts, forgotten parameters.

ffuf#

Copy code
ffuf -u https://target/FUZZ -w common.txt -fc 404 -fs 0

Match both status and size; custom 404 pages often return 200 with a standard body. Calibrate against a known-missing path first.

Organize Output#

Keep one directory per target: recon/, scans/, pocs/, reports/. Every claim in the report points to a file in the tree. A second reviewer should be able to replay the finding from the tree alone.

Timing Your Scans#

Active scanning right after a deploy finds regressions. Run passive scanning continuously. The HUD overlay in ZAP 2.16 makes passive alerts visible while you click through the site manually.

Nuclei Template Governance#

Pin a templates commit, update on a schedule, and diff new templates before running them broadly. A broken template can crash or miss; both waste a day.

Burp Logger#

Use Logger++ to tag requests you want to find later. After a session, the tagged rows are the active surface; everything else is noise.

Dependency Check#

For supply-chain angles:

Copy code
npm ls --depth=0
pip list --outdated

Cross-reference flagged packages with CVE feeds, but confirm each CVE actually applies to the versions you run.

Evidence Template#

For every tool output: command, target, time, and the exact row or packet that matters. Without that, the output is a screenshot that ages badly.

Rate Limits and Ethics#

Do not hammer a target. Set explicit rate limits on active tools, and pull from the directory when the program says to stop. A ban loses you the program and sometimes your account.

Weekly Rhythm#

How to run the toolkit through a week:

• Monday: passive recon and asset list refresh
• Tuesday: parameter discovery with Arjun
• Wednesday: Nuclei pass with rate limits set
• Thursday: manual verification of scanner output
• Friday: report write-up and tool updates
• Saturday: log files archived and evidence tree pruned

Reference Tables#

Reminders#

2. confirm before reporting
3. confirm before reporting
4. confirm before reporting
5. confirm before reporting
6. confirm before reporting
7. confirm before reporting
8. confirm before reporting
9. confirm before reporting
10. confirm before reporting
11. confirm before reporting
12. confirm before reporting
13. confirm before reporting
14. confirm before reporting
15. confirm before reporting

Command Cheatsheet#

Copy code
nuclei -u https://target -severity high
ffuf -u https://target/FUZZ -w common.txt
arjun -u https://target/?a=1

Final Notes#

2. confirm, document, report
3. confirm, document, report
4. confirm, document, report
5. confirm, document, report
6. confirm, document, report
7. confirm, document, report
8. confirm, document, report
9. confirm, document, report
10. confirm, document, report
11. confirm, document, report
12. confirm, document, report
13. confirm, document, report
14. confirm, document, report
15. confirm, document, report
16. confirm, document, report
17. confirm, document, report
18. confirm, document, report
19. confirm, document, report
20. confirm, document, report
21. confirm, document, report

Tool Comparison#

Closing Notes#

1. Verify each observation with a second independent check.
2. Prefer packet, request/response, or log evidence over prose.
3. Tie the finding to the control that should have caught it.
4. Redact secrets but keep the request shape visible.
5. Never quote a payload you have not actually tested.
6. Keep one repro per file; name it clearly.
7. Update the matrix when a new tool or a new gadget appears.
8. Shorten CI runs; the tool should fit in a normal deploy.
9. Confirm a false positive before you report it.
10. A finding without evidence is folklore.
11. Document the exact time delta or row count.
12. Record the binary version or framework version in the report.
13. Every tool output in the report ties to a command.
14. The evidence tree should let a second reader replay the finding.
15. Log the encoding and the raw bytes with the finding.
16. If a fix closes one probe, re-run the others to be sure.
17. Closing one instance rarely closes the class.
18. Rotate pretexts and rate limits so the test keeps signal.
19. Track report rate, not click rate, for awareness campaigns.
20. Keep capture files short; slice the interesting window.
21. ZAP baselines belong in CI, full scans on staging.
22. Burst the auth endpoint, then verify no lockout.
23. Diff lockfiles before running a supply-chain claim.
24. Parameter pollution hides in headers and cookies too.
25. Checksum your dependencies and rotate keys on a schedule.
26. Time-based blind is slow; always pair it with a boolean check.
27. Show the GRANTS output; it proves reachability limits.
28. DOM sinks are data-flow endpoints, not just payload targets.
29. Trusted Types and CSP sit on the same defense line.
30. Stash the tshark JSON slice with the pcap for reference.
31. A short pcap with notes beats a ten-minute capture.
32. Name files with date, host, and window.
33. A flat periodic line in the IO graph is a beacon candidate.
34. Spike bursts in Burp are usually manual, not scanner.
35. Tune Nuclei rate limits so the range is not blocked.
36. sqlmap risk/level flags widen the payload classes.
37. Arjun finds parameters that do not appear in the URL.
38. Keep WordPress plugin nonces in a separate test case.
39. XML-RPC is the slow, quiet way in. Disable it if unused.
40. Backup files in the docroot are findings by themselves.
41. Upload extension checks should run on the normalized name.
42. Homoglyphs hide inside scope lists and allowlists.
43. Normalize at the edge, log raw, never filter before decode.
44. UTF-7 and legacy codecs keep bypassing naive filters.
45. A fullwidth probe that passes is a bug in the pipeline.
46. Rotate keys, pin versions, and rotate them again after a patch.
47. Prototype pollution turns one key into a global change.
48. __proto__ is the first key to block; check constructor too.
49. Run npm ls deep; the vulnerable path is rarely the top level.
50. Refuse constructor.prototype keys at every merge point.
51. Freeze Object.prototype for the server if you must merge.