Mindset & Methodology

Read this first. Before any tool, any payload, any scanner - read this.

Core Principles

Read the scope and enforce it - Know what is in scope, what is out of scope, and what vulnerabilities the program accepts. Configure your tools (Burp, FFUF, etc.) to match. Scope mistakes kill your reputation.
Understand the application first - What did the developers intend? What is the business logic? Click through every feature. Intercept all traffic. You cannot hack what you do not understand.
You will only find what you test for - Have a checklist. Test for edge cases. This is never a script you run. You have to do this manually.
It is the methodology, not the tool - Tools come and go. Understand what you are doing and why. Any tool that does the job is fine.
Always prove security impact - A valid bug is not always a security issue. Ask yourself: if an attacker exploits this, what is the impact on the business or users?

Order of Operations

Scope -> Understand -> Enumerate -> Test -> Exploit -> Document

1. Scope

Read the full program rules, in-scope assets, out-of-scope assets, and out-of-scope vulnerability types
Note rate limits (e.g. 5 req/sec), automated tool restrictions, and disclosure rules
Configure Burp Suite scope immediately (Target > Scope Settings > Advanced)
If a domain is not listed in scope, it is out of scope - period

2. Understand

Navigate the application like a normal user first
Click every link, fill every form, use every feature
Watch Burp HTTP History as you browse - see what requests happen behind the scenes
Identify the tech stack: framework, language, server, CDN, WAF
Tools: Wappalyzer, BuiltWith, curl -I, browser dev tools
Ask: What is the purpose of this application? What data does it handle? What would be critical to protect?

3. Enumerate

Subdomain enumeration: subfinder, assetfinder, amass, crt.sh, Google dorks
Directory enumeration: ffuf, feroxbuster, dirbuster
Technology fingerprinting: Wappalyzer, BuiltWith, securityheaders.com
Review JavaScript files for endpoints, API keys, hardcoded secrets
Check for common files: robots.txt, sitemap.xml, .git/, .env, web.config
Probe alive subdomains: httprobe, httpx
Screenshot alive hosts: gowitness, eyewitness

4. Test

Go through each feature with Burp Repeater
Test every input field, parameter, header, and cookie
Remove parameters, add parameters, change methods (GET to POST, PUT, DELETE)
Test every security control you encounter - just because a control exists does not mean it works properly
Check authentication flows for logic issues and edge cases
Check authorization by testing with different user roles (use containers for session separation)
Think: what did the developer assume would never happen?

5. Exploit

Confirm the vulnerability is real and reproducible
Determine the full impact before reporting
Use the minimum access needed to prove the bug - do not access unnecessary user data
For blind vulnerabilities, use webhook.site or your own listener to confirm out-of-band

6. Document

Keep notes as you go, not after the fact
Log: what you tested, what you found, what worked, what didn’t
Screenshots of before/after states
Save all Burp requests/responses relevant to findings

Recurring Instructor Advice

These are direct patterns from the course instructors (Heath Adams, Alex Olson, Jonah Burgess):

“Reconnaissance is everything” - The deeper you dig, the better hunter you are. Don’t just look at the main web page. Everyone is looking there. Find the assets others aren’t finding.
“Step through the application” - Before every lab, every target, the instructor’s first move is: test the functionality, see what it does, look at it in Burp. Every. Single. Time.
“Understand what is happening under the hood” - This will pay real dividends in the long run. Don’t just fire payloads. Know why they work.
“Whenever you see a security control, think about how to test that control” - CSRF tokens exist? Test if the value is checked. Rate limiting? Test its boundaries. Filters? Test if they are recursive.
“Just because there is a security control doesn’t mean it works properly” - Many people see a control and give up. That is exactly where you find interesting bugs.
“Always pay attention to the content length” - When fuzzing or testing, changes in response size are your signal. Sort by length. Look for outliers.
“Think about edge cases” - What happens with old tokens? Tokens from other sessions? Empty values? Extremely long values? Different HTTP methods?
“Consider what information you have and what you do next with it” - Found usernames via IDOR? Those become targets for auth attacks. Found a tech version? Search for CVEs. Chain findings.
“Read write-ups for 30 minutes a day” - Study real bug bounty reports. Learn from others’ methodology. Pick a topic and study the attack patterns.
“Do a little bit of programming every day - 20 minutes” - Understanding the code makes you better at breaking it. Free Code Camp, The Odin Project.

Common Beginner Mistakes

From the triage team’s perspective (ranked by frequency):

Lack of information in reports - Insufficient steps to reproduce, missing proof of concept, unclear impact
Ignoring program scope and rules - Testing out-of-scope assets, using forbidden automated tools
Exaggerating severity - Describing low-impact bugs as critical without evidence
Not considering user/business impact - Focusing on technical details without explaining real-world consequences
Noisy reports - Submitting multiple reports for the same vulnerability with slight variations
Submitting low-impact issues - Missing headers, missing cookie flags, spelling errors - these are not bugs
Reporting without verifying - Submitting before confirming the vulnerability is reproducible and the impact is real
Not reading the out-of-scope vulnerability list - Many valid pen test findings are explicitly out of scope in bug bounty (username enumeration, missing rate limiting, self-XSS, etc.)
Firing automated scanners without reading program rules - Many programs explicitly forbid automated scanning
Giving up when a security control is present - See a CSRF token and move on. See a WAF and move on. Test the control instead.

Burp Suite Workflow

Initial Setup

Install FoxyProxy, configure 127.0.0.1:8080
Download and install Burp CA certificate in Firefox
Install Firefox Multi-Account Containers for testing across sessions
Install key extensions: Logger++, Autorize (requires Jython), Turbo Intruder (Community edition workaround for throttled Intruder)

Scope Configuration

Target > Scope Settings > Use Advanced Scope Control
Add the target domain (e.g. example.com matches all subdomains on any protocol)
Proxy Settings > Request Interception Rules > check “target is in scope” (after initial exploration)
Filter HTTP History to show only in-scope items

Containers (Firefox Multi-Account Containers)

Use separate containers for different user roles (e.g. Container 1 = low-priv user, Container 2 = admin)
Each container has isolated cookies, sessions, and local storage
Essential for testing authorization/access control issues without confusion

The Repeater Workflow

This is where you live. The workflow for almost every test:

Browse the application with proxy on, intercept off
Find the interesting request in HTTP History
Right-click > Send to Repeater (Ctrl+R)
In Repeater: modify parameters, headers, cookies, methods
Send and compare responses (content length, status code, body content)
Use the search bar in the response to find specific strings
Render tab shows visual page output

Intruder Workflow

Mark injection points with Add
Attack types: Sniper (single list, one position), Cluster Bomb (multiple lists, all permutations)
Sort results by status code and content length to find outliers
Use Grep Match to flag specific strings in responses
Community edition is throttled - use FFUF or Turbo Intruder for speed

Key Shortcuts

Ctrl+R: Send to Repeater
Ctrl+I: Send to Intruder
Ctrl+U: URL-encode selection
Ctrl+Shift+U: URL-decode selection

Manual Testing vs Automation

When to Test Manually

Authentication and authorization logic (MFA bypass, IDOR, privilege escalation)
Business logic flaws
Chaining vulnerabilities
Anything requiring context about how the application works
When the program forbids automated tools
When you need to understand what a payload does before sending it

When to Automate

Subdomain enumeration (subfinder, assetfinder, amass)
Directory/file brute forcing (ffuf, feroxbuster)
Screenshot collection (gowitness)
Port scanning (nmap)
Known CVE scanning for specific versions (searchsploit, nuclei)
SQL injection confirmation (sqlmap - but check rate limits first)
Fuzzing for parameter values when you already know the injection point

Key Rule

Automated scanners find maybe 10-20% of vulnerabilities. Most of your findings come from manual testing. Scanners are assistants, not replacements.
Be careful with what you include in automated scans. Login forms will get re-submitted. MFA codes will get re-triggered. Contact forms will spam the client.

Note-Taking Discipline

“Please make sure you’re taking really good notes” - Direct quote from the recon section. Not optional.
Take notes as you go, not at the end
For each target, maintain a file with:
- Scope boundaries
- Discovered subdomains and endpoints
- Tech stack (server, framework, language, CDN, WAF)
- User accounts and credentials (test accounts you created)
- Each vulnerability found: description, steps, impact, proof
- What you tested that did NOT work (prevents re-testing)
Reference resources as you go:
- PayloadsAllTheThings (payloads, bypass techniques)
- HackTricks (methodology checklists)
- PortSwigger Web Security Academy (free labs and theory)
- AppSecExplained wiki (Alex Olson’s checklist of test ideas per vulnerability type)
- OWASP Testing Guide and Cheat Sheet Series
Update notes immediately when you find something - don’t trust your memory
Keep Burp Logger++ running for a full audit trail of every request

Pre-Testing Checklist

Before you touch a target:

Quick Reference: What to Test on Every Input

For every parameter, cookie, header, or input field you find:

What happens if you remove it?
What happens if you duplicate it?
What happens if you change the value type (string to int, int to string)?
What happens if you send an extremely long value?
What happens if you send special characters (’ ” < > { } | ; &)?
What happens if you change the HTTP method?
What happens if you send a request without authentication?
What happens if you use another user’s token/session?
Does the response change in size, status code, or content?

Resources

Resource	Use
PortSwigger Web Security Academy	Free labs, theory, cheat sheets
PayloadsAllTheThings	Payload lists for every vulnerability type
HackTricks	Methodology and exploitation techniques
AppSecExplained (appsecexplained.gitbook.io)	Alex Olson’s testing checklists with edge case ideas
SecLists	Word lists for fuzzing, passwords, usernames
CRT.sh	Certificate-based subdomain discovery
OWASP Testing Guide	Comprehensive testing methodology
Bug bounty write-ups (Google: “[vuln type] bug bounty write-up”)	Real-world examples of methodology and findings

🪴 Quartz 4.0

Explorer

00 - Methodology