Install
$ agentstack add skill-sekolah76-syadagentic-bug-bounty Open-source listing, not yet scanned by AgentStack. Follow the source repository for install instructions.
Security review
⚠ Flagged2 finding(s); flagged for manual review. · v0.1.0 How review works →
- • Prompt-injection patterns
- • Secret / credential exfiltration
- • Dangerous shell & filesystem operations
- • Untrusted network calls
- • Known-malicious package signatures
- high Possible prompt-injection directive.
- high Dangerous shell/eval execution.
What it can access
- ● Network access Used
- ✓ Filesystem access No
- ● Shell / process execution Used
- ● Environment & secrets Used
- ● Dynamic code execution Used
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Bug Bounty Master Workflow
Full pipeline: Recon -> Learn -> Hunt -> Validate -> Report. One skill for everything.
THE ONLY QUESTION THAT MATTERS
> "Can an attacker do this RIGHT NOW against a real user who has taken NO unusual actions -- and does it cause real harm (stolen money, leaked PII, account takeover, code execution)?" > > If the answer is NO -- STOP. Do not write. Do not explore further. Move on.
Theoretical Bug = Wasted Time. Kill These Immediately:
| Pattern | Kill Reason | |---|---| | "Could theoretically allow..." | Not exploitable = not a bug | | "An attacker with X, Y, Z conditions could..." | Too many preconditions | | "Wrong implementation but no practical impact" | Wrong but harmless = not a bug | | Dead code with a bug in it | Not reachable = not a bug | | Source maps without secrets | No impact | | SSRF with DNS-only callback | Need data exfil or internal access | | Open redirect alone | Need ATO or OAuth chain | | "Could be used in a chain if..." | Build the chain first, THEN report |
You must demonstrate actual harm. "Could" is not a bug. Prove it works or drop it.
CRITICAL RULES
- READ FULL SCOPE FIRST -- verify every asset/domain is owned by the target org
- NO THEORETICAL BUGS -- "Can an attacker steal funds, leak PII, takeover account, or execute code RIGHT NOW?" If no, STOP.
- KILL WEAK FINDINGS FAST -- run the 7-Question Gate BEFORE writing any report
- Validate before writing -- check CHANGELOG, design docs, deployment scripts FIRST
- One bug class at a time -- go deep, don't spray
- Verify data isn't already public -- check web UI in incognito before reporting API "leaks"
- 5-MINUTE RULE -- if a target shows nothing after 5 min probing (all 401/403/404), MOVE ON
- IMPACT-FIRST HUNTING -- ask "what's the worst thing if auth was broken?" If nothing valuable, skip target
- CREDENTIAL LEAKS need exploitation proof -- finding keys isn't enough, must PROVE what they access
- STOP SHALLOW RECON SPIRALS -- don't probe 403s, don't grep for analytics keys, don't check staging domains that lead nowhere
- BUSINESS IMPACT over vuln class -- severity depends on CONTEXT, not just vuln type
- UNDERSTAND THE TARGET DEEPLY -- before hunting, learn the app like a real user
- DON'T OVER-RELY ON AUTOMATION -- automated scans hit WAFs, trigger rate limits, find the same bugs everyone else finds
- HUNT LESS-SATURATED VULN CLASSES -- XSS/SSRF/XXE have the most competition. Expand into: cache poisoning, Android/mobile vulns, business logic, race conditions, OAuth/OIDC chains, CI/CD pipeline attacks
- ONE-HOUR RULE -- stuck on one target for an hour with no progress? SWITCH CONTEXT
- TWO-EYE APPROACH -- combine systematic testing (checklist) with anomaly detection (watch for unexpected behavior)
- T-SHAPED KNOWLEDGE -- go DEEP in one area and BROAD across everything else
> For the full hunting methodology — 5-phase non-linear workflow, developer psychology framework, session discipline, tool routing by phase, and Wide/Deep route selection — see skills/bb-methodology/SKILL.md.
AUTH-AWARE HUNTING (when bugs live behind a login)
Anonymous recon misses the bugs that pay most. IDOR, BOLA, mass-assignment, privilege escalation, auth bypass, SSRF behind login, and most LLM/agent bugs are invisible until you log in. Load auth once at session start and every downstream tool (httpx, katana, ffuf, nuclei, dalfox, the SQLi / SSTI / upload PoC verifiers) sends those headers automatically.
# Pick ONE of these and run hunt.py normally:
python3 tools/hunt.py --target T --cookie 'session=eyJabc...'
python3 tools/hunt.py --target T --bearer 'eyJhbGciOi...'
python3 tools/hunt.py --target T --auth-file .private/T.json
# Or via env (persists for the shell):
export BBHUNT_COOKIE='session=eyJabc...'
python3 tools/hunt.py --target T
For IDOR / BOLA hunts, load two sessions and diff behavior:
python3 tools/hunt.py --target T --auth-file .private/T-user-a.json
python3 tools/hunt.py --target T --auth-file .private/T-user-b.json
# Audit log entries carry different session_id hashes → diff which
# endpoints behaved differently per identity.
Safety: cookies/tokens never appear in logs, hunt-memory, or repr(). Only a 12-char session_id hash is recorded. .private/ is gitignored. MFA-skip and SAML signature-stripping probes deliberately stay anonymous — that's the attack they're checking for.
Full guide: docs/auth-sessions.md. Template: docs/auth.example.json.
A->B BUG SIGNAL METHOD (Cluster Hunting)
When you find bug A, systematically hunt for B and C nearby. This is one of the most powerful methodologies in bug bounty. Single bugs pay. Chains pay 3-10x more.
Known A->B->C Chains
| Bug A (Signal) | Hunt for Bug B | Escalate to C | |----------------|---------------|---------------| | IDOR (read) | PUT/DELETE on same endpoint | Full account data manipulation | | SSRF (any) | Cloud metadata 169.254.169.254 | IAM credential exfil -> RCE | | XSS (stored) | Check if HttpOnly is set on session cookie | Session hijack -> ATO | | Open redirect | OAuth redirecturi accepts your domain | Auth code theft -> ATO | | S3 bucket listing | Enumerate JS bundles | Grep for OAuth clientsecret -> OAuth chain | | Rate limit bypass | OTP brute force | Account takeover | | GraphQL introspection | Missing field-level auth | Mass PII exfil | | Debug endpoint | Leaked environment variables | Cloud credential -> infrastructure access | | CORS reflects origin | Test with credentials: include | Credentialed data theft | | Host header injection | Password reset poisoning | ATO via reset link |
Cluster Hunt Protocol (6 Steps)
1. CONFIRM A Verify bug A is real with an HTTP request
2. MAP SIBLINGS Find all endpoints in the same controller/module/API group
3. TEST SIBLINGS Apply the same bug pattern to every sibling
4. CHAIN If sibling has different bug class, try combining A + B
5. QUANTIFY "Affects N users" / "exposes $X value" / "N records"
6. REPORT One report per chain (not per bug). Chains pay more.
Real Examples
Coinbase S3->Bundle->Secret->OAuth chain:
A: S3 bucket publicly listable (Low alone)
B: JS bundles contain OAuth client credentials
C: OAuth flow missing PKCE enforcement
Result: Full auth code interception chain
Vienna Chatbot chain:
A: Debug parameter active in production (Info alone)
B: Chatbot renders HTML in response (dangerouslySetInnerHTML)
C: Stored XSS via bot response visible to other users
Result: P2 finding with real impact
TOP 1% HACKER MINDSET
How Elite Hackers Think Differently
Average hunter: Runs tools, checks checklist, gives up after 30 min. Top 1%: Builds a mental model of the app's internals. Asks "why does this work the way it does?" Not "what does this endpoint do?" but "what business decision led a developer to build it this way, and what shortcut might they have taken?"
Pre-Hunt Mental Framework
Step 1: Crown Jewel Thinking
Before touching anything, ask: "If I were the attacker and I could do ONE thing to this app, what causes the most damage?"
- Financial app -> drain funds, transfer to attacker account
- Healthcare -> PII leak, HIPAA violation
- SaaS -> tenant data crossing, admin takeover
- Auth provider -> full SSO chain compromise
Step 2: Developer Empathy
Think like the developer who built the feature:
- What was the simplest implementation?
- What shortcut would a tired dev take at 2am?
- Where is auth checked -- controller? middleware? DB layer?
- What happens when you call endpoint B without going through endpoint A first?
Step 3: Trust Boundary Mapping
Client -> CDN -> Load Balancer -> App Server -> Database
^ ^ ^
Where does app STOP trusting input?
Where does it ASSUME input is already validated?
Step 4: Feature Interaction Thinking
- Does this new feature reuse old auth, or does it have its own?
- Does the mobile API share auth logic with the web app?
- Was this feature built by the same team or a third-party?
The Top 1% Mental Checklist
- [ ] I know the app's core business model
- [ ] I've used the app as a real user for 15+ minutes
- [ ] I know the tech stack (language, framework, auth system, caching)
- [ ] I've read at least 3 disclosed reports for this program
- [ ] I have 2 test accounts ready (attacker + victim)
- [ ] I've defined my primary target: ONE crown jewel I'm hunting for today
Mindset Rules from Top Hunters
"Hunt the feature, not the endpoint" -- Find all endpoints that serve a feature, then test the INTERACTION between them.
"Authorization inconsistency is your friend" -- If the app checks auth in 9 places but not the 10th, that's your bug.
"New == unreviewed" -- Features launched in the last 30 days have lowest security maturity.
"Think second-order" -- Second-order SSRF: URL saved in DB, fetched by cron job. Second-order XSS: stored clean, rendered unsafely in admin panel.
"Follow the money" -- Any feature touching payments, billing, credits, refunds is where developers make the most security shortcuts.
"The API the mobile app uses" -- Mobile apps often call older/different API versions. Same company, different attack surface, lower maturity.
"Diffs find bugs" -- Compare old API docs vs new. Compare mobile API vs web API. Compare what a free user can request vs what a paid user gets in response.
TOOLS
Go Binaries
| Tool | Use | |------|-----| | subfinder | Passive subdomain enum | | httpx | Probe live hosts | | dnsx | DNS resolution | | nuclei | Template scanner | | katana | Crawl | | waybackurls | Archive URLs | | gau | Known URLs | | dalfox | XSS scanner | | ffuf | Fuzzer | | anew | Dedup append | | qsreplace | Replace param values | | assetfinder | Subdomain enum | | gf | Grep patterns (xss, sqli, ssrf, redirect) | | interactsh-client | OOB callbacks |
Tools to Install When Needed
| Tool | Use | Install | |------|-----|---------| | arjun | Hidden parameter discovery | pip3 install arjun | | paramspider | URL parameter mining | pip3 install paramspider | | kiterunner | API endpoint brute | go install github.com/assetnote/kiterunner/cmd/kr@latest | | cloudenum | Cloud asset enumeration | pip3 install cloud_enum | | trufflehog | Secret scanning | brew install trufflehog | | gitleaks | Secret scanning | brew install gitleaks | | XSStrike | Advanced XSS scanner | pip3 install xsstrike | | SecretFinder | JS secret extraction | pip3 install secretfinder | | sqlmap | SQL injection | pip3 install sqlmap | | subzy | Subdomain takeover | go install github.com/LukaSikic/subzy@latest |
Static Analysis (Semgrep Quick Audit)
# Install: pip3 install semgrep
# Broad security audit
semgrep --config=p/security-audit ./
semgrep --config=p/owasp-top-ten ./
# Language-specific rulesets
semgrep --config=p/javascript ./src/
semgrep --config=p/python ./
semgrep --config=p/golang ./
semgrep --config=p/php ./
semgrep --config=p/nodejs ./
# Targeted rules
semgrep --config=p/sql-injection ./
semgrep --config=p/jwt ./
# Custom pattern (example: find SQL concat in Python)
semgrep --pattern 'cursor.execute("..." + $X)' --lang python .
# Output to file for analysis
semgrep --config=p/security-audit ./ --json -o semgrep-results.json 2>/dev/null
cat semgrep-results.json | jq '.results[] | select(.extra.severity == "ERROR") | {path:.path, check:.check_id, msg:.extra.message}'
FFUF Advanced Techniques
# THE ONE RULE: Always use -ac (auto-calibrate filters noise automatically)
ffuf -w wordlist.txt -u https://target.com/FUZZ -ac
# Authenticated raw request file — IDOR testing (save Burp request to req.txt, replace ID with FUZZ)
seq 1 10000 | ffuf --request req.txt -w - -ac
# Authenticated API endpoint brute
ffuf -u https://TARGET/api/FUZZ -w wordlist.txt -H "Cookie: session=TOKEN" -ac
# Parameter discovery
ffuf -w ~/wordlists/burp-parameter-names.txt -u "https://target.com/api/endpoint?FUZZ=test" -ac -mc 200
# Hidden POST parameters
ffuf -w ~/wordlists/burp-parameter-names.txt -X POST -d "FUZZ=test" -u "https://target.com/api/endpoint" -ac
# Subdomain scan
ffuf -w subs.txt -u https://FUZZ.target.com -ac
# Filter strategies:
# -fc 404,403 Filter status codes
# -fs 1234 Filter by response size
# -fw 50 Filter by word count
# -fr "not found" Filter regex in response body
# -rate 5 -t 10 Rate limit + fewer threads for stealth
# -e .php,.bak,.old Add extensions
# -o results.json Save output
AI-Assisted Tools
- strix (usestrix.com) -- open-source AI scanner for automated initial sweep
AI-ASSISTED HUNT LOOP
Use AI as a second analyst, not as the authority.
- Decompose the feature — ask for actors, assets, trust boundaries, hidden state, and sibling endpoints.
- Generate the test matrix — anonymous vs authenticated, user A vs user B, fresh vs stale session, web vs mobile, legacy vs current API.
- Ask for developer shortcuts — where a rushed implementation would likely skip a check, reuse a helper, or trust a client-side value.
- Ask for adjacent bugs — if A is real, what B and C are likely nearby?
- Convert every idea into one request — the output must be a concrete HTTP experiment or it stays speculation.
- Proof first, report later — AI can rank hypotheses, but only live request/response diffs and cross-account deltas can promote a finding.
Good prompt shapes:
- "Given this feature, list the 10 most likely trust-boundary mistakes."
- "What sibling routes, methods, or roles should I test next?"
- "What would a tired developer probably reuse here?"
- "What is the smallest reproducible request that could prove impact?"
- "What evidence would downgrade this to N/A?"
PHASE 1: RECON
Standard Recon Pipeline
# Step 1: Subdomains
subfinder -d TARGET -silent | anew /tmp/subs.txt
assetfinder --subs-only TARGET | anew /tmp/subs.txt
# Step 2: Resolve + live hosts
cat /tmp/subs.txt | dnsx -silent | httpx -silent -status-code -title -tech-detect -o /tmp/live.txt
# Step 3: URL collection
cat /tmp/live.txt | awk '{print $1}' | katana -d 3 -silent | anew /tmp/urls.txt
echo TARGET | waybackurls | anew /tmp/urls.txt
gau TARGET | anew /tmp/urls.txt
# Step 4: Nuclei scan
nuclei -l /tmp/live.txt -severity critical,high,medium -silent -o /tmp/nuclei.txt
# Step 5: JS secrets
cat /tmp/urls.txt | grep "\.js$" | sort -u > /tmp/jsfiles.txt
# Run SecretFinder on each JS file
# Step 6: GitHub dorking (if target has public repos)
# GitDorker -org TARGET_ORG -d dorks/alldorksv3
Cloud Asset Enumeration
# Manual S3 brute
for suffix in dev staging test backup api data assets static cdn; do
code=$(curl -s -o /dev/null -w "%{http_code}" "https://${TARGET}-${suffix}.s3.amazonaws.com/")
[ "$code" != "404" ] && echo "$code ${TARGET}-${suffix}.s3.amazonaws.com"
done
API Endpoint Discovery
# ffuf API endpoint brute
ffuf -u https://TARGET/api/FUZZ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt -mc 200,201,301,302,403 -ac
HackerOne Scope Retrieval
curl -s "https://hackerone.com/graphql" \
-H "Content-Type: application/json" \
-d '{"query":"query { team(handle: \"PROGRAM_HANDLE\") { name url policy_scopes(archived: false) { edges { node { asset_type asset_identifier eligible_for_bounty instruction } } } } }"}' \
| jq '.data.team.policy_scopes.edges[].node'
Quick Wins Checklist
- [ ] Subdomain takeover (
subjack,subzy) - [ ] Exposed
.git(/.git/config) - [ ] Exposed env files (
/.env,/.env.local) - [ ] Default credentials on admin panels
- [ ] JS secrets (SecretFinder, jsluice)
- [ ] Open redirects (
?redirect=,?next=,?url=) - [ ] CORS misco
…
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: Sekolah76
- Source: Sekolah76/syadagentic
- License: MIT
- Homepage: https://github.com/Sekolah76/syadagentic
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.