@aegis-scan/skills 0.4.0 → 0.5.1

package/skills/offensive/airecon-fork/tools-semgrep/SKILL.md

@@ -0,0 +1,202 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+# semgrep — Usage Guide for AIRecon
+
+semgrep is a static analysis tool that finds patterns in source code. It is fundamentally different
+from network scanners — it reads code files and reports where specific patterns appear. This means
+it is only useful when you have actual source code or client-side files to analyze. Running semgrep
+on an empty directory or before code has been obtained produces nothing useful.
+
+semgrep findings are NOT confirmed vulnerabilities. They are leads that require manual reading
+and verification. Every semgrep hit must be manually inspected before any further action is taken.
+
+---
+
+## MANDATORY PRE-CONDITIONS (All must be true before using semgrep)
+
+  [ ] You have actual source code, configuration files, or client-side assets to analyze.
+      This means you have already obtained one or more of the following:
+        - JavaScript bundles extracted from a live web application
+        - Source code from an exposed git repository (via git-dumper, GitLab API, etc.)
+        - Configuration files discovered during directory enumeration
+        - Uploaded or leaked source archives found during OSINT
+  [ ] The code is written to disk and accessible — semgrep cannot analyze remote URLs.
+      Extracted files must be in the workspace before semgrep can read them.
+  [ ] You have a specific hypothesis about what you are looking for.
+      State it: "I extracted the JS bundle and want to find hardcoded API keys and secrets"
+      or "I have the backend Python source and want to find SQL concatenation patterns."
+      NOT: "I will run semgrep to find vulnerabilities" — this is too vague.
+  [ ] You have selected a ruleset that matches the programming language of the code you found.
+      Running a Java ruleset on JavaScript produces false negatives. Match language precisely.
+
+Using semgrep before obtaining source code = produces zero output, wastes time.
+Running semgrep without reading its findings manually = not security testing, it is checkbox theater.
+
+---
+
+## What semgrep Is Good At (When Code Is Available)
+
+  STRONG USE CASES:
+    - Finding hardcoded secrets, API keys, and tokens in JS bundles or config files
+    - Detecting dangerous function calls: eval(), exec(), system(), unserialize(), etc.
+    - Identifying SQL string concatenation patterns that suggest injection vulnerability
+    - Finding insecure cryptographic usage (MD5, SHA1 for passwords, weak RNG)
+    - Spotting prototype pollution sinks in JavaScript (obj[key] = value patterns)
+    - Detecting SSTI-prone template rendering calls
+    - Mapping all locations where user input touches dangerous sinks (DOM XSS sources/sinks)
+    - Finding dangerously misconfigured security headers in framework config files
+
+  WEAK USE CASES (manual reading is better):
+    - Business logic flaws — patterns cannot capture intent
+    - Authorization bypass — requires understanding of the full request flow
+    - Race conditions — timing-dependent, not findable via static patterns
+    - Complex chained vulnerabilities — semgrep sees one file at a time, not the full system
+
+  semgrep finds WHERE code might be dangerous.
+  You must determine IF it actually is dangerous by reading the surrounding context manually.
+
+---
+
+## Source Code Acquisition — Get This First
+
+Before semgrep can be used, code must be obtained. Priority order:
+
+  1. EXPOSED GIT REPOSITORY:
+     If /.git/ is accessible: use git-dumper to reconstruct the full source tree.
+     If GitLab/GitHub is linked in JS or robots.txt: clone or access the repo directly.
+     Output: a full source directory you can analyze.
+
+  2. JAVASCRIPT BUNDLE EXTRACTION:
+     After browser profiling: collect all .js URLs from the page source.
+     Download each bundle: curl -s <url> -o output/js/<filename>.js
+     De-obfuscate if minified: js-beautify output/js/<filename>.js -o output/js/<filename>_clean.js
+     Output: readable JS files for analysis.
+
+  3. EXPOSED CONFIGURATION FILES:
+     If directory enumeration found config files (.env, config.yml, settings.py, web.config, etc.):
+     Download them: curl -s <url> -o output/configs/<filename>
+     Output: configuration files for secret and misconfiguration analysis.
+
+  4. SOURCE CODE ARCHIVE:
+     If a .zip, .tar.gz, or backup file was found: download and extract it.
+     Output: a source tree for analysis.
+
+  DO NOT run semgrep until at least one of the above has produced files on disk.
+
+---
+
+## Ruleset Selection — Language and Context Must Match
+
+  JAVASCRIPT / TYPESCRIPT (extracted from web app):
+    Detect secrets and dangerous patterns:
+      semgrep --config=p/javascript -l javascript output/js/ --json -o output/semgrep_js.json
+    Detect prototype pollution and DOM XSS sinks:
+      semgrep --config=p/xss output/js/ --json -o output/semgrep_xss.json
+    Detect hardcoded secrets:
+      semgrep --config=p/secrets output/js/ --json -o output/semgrep_secrets.json
+
+  PYTHON (backend source if obtained):
+    Detect injection patterns and insecure functions:
+      semgrep --config=p/python output/src/ --json -o output/semgrep_python.json
+    OWASP top 10 patterns:
+      semgrep --config=p/owasp-top-ten output/src/ --json -o output/semgrep_owasp.json
+
+  JAVA (if backend source is available):
+      semgrep --config=p/java output/src/ --json -o output/semgrep_java.json
+
+  PHP (if CMS or backend PHP source obtained):
+      semgrep --config=p/php output/src/ --json -o output/semgrep_php.json
+
+  CONFIGURATION FILES (any language — secret and credential detection):
+      semgrep --config=p/secrets output/configs/ --json -o output/semgrep_config_secrets.json
+      semgrep --config=p/trailofbits output/ --json -o output/semgrep_tob.json
+
+  GENERIC PATTERNS (use when language is uncertain or mixed codebase):
+      semgrep --config=p/security-audit output/ --json -o output/semgrep_audit.json
+
+  NEVER use these patterns:
+    semgrep --config=auto .         (auto config on empty or irrelevant directory)
+    semgrep --config=p/java output/js/  (wrong language for the files you have)
+    semgrep . --config=r/all        (all rules on all files = noise, not signal)
+
+---
+
+## Interpreting Results — Every Finding Requires Manual Reading
+
+semgrep output is a list of pattern matches, not a list of vulnerabilities.
+
+After semgrep completes, for EVERY finding:
+
+  STEP 1: Open the flagged file at the flagged line.
+    Read the surrounding 20-30 lines. Understand what the code is doing.
+    Ask: "Is this actually dangerous in this specific context?"
+
+  STEP 2: Trace the data flow.
+    For injection findings: where does the input come from? Is it user-controlled?
+    For secret findings: is this a real credential or a placeholder/example?
+    For dangerous function findings: what data is passed to this function?
+
+  STEP 3: Determine exploitability.
+    Can you construct a request that reaches this code path with malicious input?
+    If yes: manually craft the proof-of-concept. Test it.
+    If no: discard the finding. Do not report unverified semgrep hits.
+
+  STEP 4: Classify severity based on actual impact, not semgrep's severity label.
+    semgrep's severity is based on the rule, not your specific target's context.
+    A "HIGH" semgrep finding on dead code is not a vulnerability.
+    A "LOW" semgrep finding on a critical authentication path may be critical.
+
+  A semgrep finding is NOT a vulnerability report.
+  Only call create_vulnerability_report after manual exploitation confirmation.
+
+---
+
+## Common High-Value Findings to Prioritize
+
+When reading semgrep output, prioritize investigating these first:
+
+  SECRETS (immediate action required):
+    API keys, tokens, passwords, private keys found in code
+    → Try to use them: verify they are real and active
+    → Check scope: is the key for a service within the target's infrastructure?
+
+  SQL CONCATENATION:
+    String concatenation in database query construction
+    → Trace the input source manually
+    → Test the specific endpoint with manual injection probes first
+
+  EVAL / EXEC PATTERNS:
+    eval(), exec(), system(), shell_exec(), subprocess.call() with variable input
+    → Trace what reaches these functions
+    → Is it truly user-controlled? Which endpoint?
+
+  DANGEROUS DESERIALIZATION:
+    unserialize(), ObjectInputStream, pickle.loads() on untrusted data
+    → Confirm the data source is user-controlled
+    → Identify the deserialization library for gadget chain selection
+
+  PROTOTYPE POLLUTION SINKS:
+    obj[key] = value, Object.assign() with user input
+    → Confirm which client-side functionality is affected
+    → Verify if this leads to XSS or logic bypass
+
+---
+
+## Workflow Integration (Where semgrep Fits)
+
+  Phase 1 STEP 4 (Front-End & API Schema Extraction):
+    After JS bundle download and de-obfuscation: run semgrep on the cleaned JS files.
+    Purpose: find hidden endpoints, secrets, and dangerous patterns in client-side code.
+
+  Phase 2 (Attack Surface Expansion):
+    After git repository exposure is confirmed: run semgrep on the extracted source.
+    Purpose: map all injection sinks, dangerous function calls, and hardcoded credentials.
+
+  Phase 3+ (Vulnerability Testing):
+    semgrep findings from earlier phases guide which endpoints and parameters to test manually.
+    The finding tells you WHERE to look. Manual testing tells you IF it is exploitable.
+
+  NEVER:
+    Run semgrep before any source code has been obtained.
+    Report semgrep findings without manual verification.
+    Run semgrep with a ruleset that does not match the language of the files you have.

package/skills/offensive/airecon-fork/tools-source-audit/SKILL.md

@@ -0,0 +1,308 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+# source_audit — Source Code Security Analysis Guide
+
+This skill covers how to find real security vulnerabilities in source code provided
+via @/path references. It applies to any engagement where you have actual source files.
+
+---
+
+## WHEN THIS SKILL APPLIES
+
+Load and follow this skill when:
+- User provides source code via @/path (e.g. "find bug in @/home/user/project/")
+- User asks to "audit", "review", "find bugs in", or "analyze" source code
+- [FILE REFERENCE — DIRECTORY] or [FILE REFERENCE — TEXT] blocks appear in context
+- User mentions a framework + source code (e.g. "find vulns in this Django app")
+
+---
+
+## STEP 0 — READ THE INJECTED CONTEXT FIRST (MANDATORY)
+
+When a user attaches files/directories with @/path, the content is already injected into
+your context. BEFORE running any tool:
+
+  1. Read the [FILE REFERENCE] block(s) in the conversation context
+  2. Identify the project language(s) from file extensions and imports
+  3. Note the Docker path (shown in the FILE REFERENCE block) — use it for execute commands
+  4. Map the overall project structure: entry points, routes, DB queries, auth logic, parsers
+
+DO NOT run scanners blindly before reading the code. Static analysis confirms WHERE patterns
+exist. Reading tells you IF they are exploitable.
+
+---
+
+## STEP 1 — LANGUAGE DETECTION
+
+Determine the primary language from file extensions in the directory tree:
+
+  .py           → Python
+  .js / .ts     → JavaScript / TypeScript
+  .go           → Go
+  .php          → PHP
+  .rb           → Ruby
+  .java         → Java
+  .cs           → C# / .NET
+  .c / .cpp     → C / C++
+  Gemfile       → Ruby (Rails likely)
+  pom.xml       → Java (Maven)
+  build.gradle  → Java / Kotlin (Gradle)
+  composer.json → PHP
+  package.json  → Node.js (JavaScript / TypeScript)
+  go.mod        → Go
+  Cargo.toml    → Rust
+  requirements.txt / pyproject.toml → Python
+
+Mixed codebases: run appropriate scanner for EACH language found.
+
+---
+
+## STEP 2 — STATIC ANALYSIS BY LANGUAGE
+
+Run the correct scanner for the detected language. All scanners write output to
+/workspace/<target>/output/. Replace <src_path> with the actual Docker path from the
+FILE REFERENCE block.
+
+### PYTHON
+  # Bandit — SAST for common security flaws (injection, hardcoded secrets, weak crypto)
+  bandit -r <src_path> -f json -o /workspace/<target>/output/bandit.json -ll
+  # Semgrep — OWASP patterns + Python-specific rules
+  semgrep --config=p/python --config=p/owasp-top-ten <src_path> --json -o /workspace/<target>/output/semgrep_py.json
+  # Secrets
+  semgrep --config=p/secrets <src_path> --json -o /workspace/<target>/output/semgrep_secrets.json
+  # Trufflehog (git history secrets — only if .git exists)
+  trufflehog filesystem <src_path> --json > /workspace/<target>/output/trufflehog.json 2>/dev/null
+
+### JAVASCRIPT / TYPESCRIPT
+  # Semgrep JS/TS
+  semgrep --config=p/javascript --config=p/typescript <src_path> --json -o /workspace/<target>/output/semgrep_js.json
+  # XSS sinks
+  semgrep --config=p/xss <src_path> --json -o /workspace/<target>/output/semgrep_xss.json
+  # Secrets in JS
+  semgrep --config=p/secrets <src_path> --json -o /workspace/<target>/output/semgrep_secrets.json
+  # npm audit (if package-lock.json exists)
+  cd <src_path> && npm audit --json > /workspace/<target>/output/npm_audit.json 2>/dev/null
+
+### GO
+  # Gosec — Go security checker
+  which gosec || go install github.com/securego/gosec/v2/cmd/gosec@latest
+  gosec -fmt json -out /workspace/<target>/output/gosec.json ./... 2>/dev/null  # run from src dir
+  # Semgrep Go
+  semgrep --config=p/golang <src_path> --json -o /workspace/<target>/output/semgrep_go.json
+
+### PHP
+  # Semgrep PHP
+  semgrep --config=p/php <src_path> --json -o /workspace/<target>/output/semgrep_php.json
+  # Semgrep secrets
+  semgrep --config=p/secrets <src_path> --json -o /workspace/<target>/output/semgrep_secrets.json
+
+### RUBY / RAILS
+  # Brakeman — Rails-specific SAST
+  which brakeman || gem install brakeman
+  brakeman <src_path> -f json -o /workspace/<target>/output/brakeman.json --no-pager 2>/dev/null
+  # Semgrep Ruby
+  semgrep --config=p/ruby <src_path> --json -o /workspace/<target>/output/semgrep_rb.json
+
+### JAVA
+  # Semgrep Java
+  semgrep --config=p/java --config=p/owasp-top-ten <src_path> --json -o /workspace/<target>/output/semgrep_java.json
+  # Secrets
+  semgrep --config=p/secrets <src_path> --json -o /workspace/<target>/output/semgrep_secrets.json
+
+### C# / .NET
+  # Semgrep C#
+  semgrep --config=p/csharp <src_path> --json -o /workspace/<target>/output/semgrep_cs.json
+
+### C / C++
+  # Flawfinder — C/C++ vulnerability scanner
+  which flawfinder || pip3 install flawfinder --break-system-packages
+  flawfinder --dataonly <src_path> > /workspace/<target>/output/flawfinder.txt
+  # Semgrep C/C++
+  semgrep --config=p/c <src_path> --json -o /workspace/<target>/output/semgrep_c.json
+
+### GENERIC (any language, secrets focus)
+  semgrep --config=p/secrets <src_path> --json -o /workspace/<target>/output/semgrep_secrets.json
+  semgrep --config=p/security-audit <src_path> --json -o /workspace/<target>/output/semgrep_audit.json
+  trufflehog filesystem <src_path> --json > /workspace/<target>/output/trufflehog.json 2>/dev/null
+
+---
+
+## STEP 3 — TRIAGE FINDINGS (MANDATORY — do not skip)
+
+After scanners complete, parse and triage the output. Start with:
+
+  python3 -c "
+  import json, sys
+  with open('/workspace/<target>/output/bandit.json') as f:
+      d = json.load(f)
+  findings = d.get('results', [])
+  high = [r for r in findings if r['issue_severity'] in ('HIGH', 'MEDIUM')]
+  for r in sorted(high, key=lambda x: x['issue_severity'])[:20]:
+      print(f\"{r['issue_severity']:8} | {r['test_id']:20} | {r['filename']}:{r['line_number']} | {r['issue_text'][:80]}\")
+  "
+
+For semgrep JSON output:
+  python3 -c "
+  import json
+  with open('/workspace/<target>/output/semgrep_py.json') as f:
+      d = json.load(f)
+  for r in d.get('results', [])[:30]:
+      sev = r.get('extra', {}).get('severity', '?')
+      msg = r.get('extra', {}).get('message', '')[:80]
+      path = r['path']
+      line = r['start']['line']
+      print(f'{sev:8} | {path}:{line} | {msg}')
+  "
+
+PRIORITIZE (investigate first):
+  1. Hardcoded secrets / API keys / passwords (immediate active credential test)
+  2. SQL string concatenation → trace to user input → test endpoint
+  3. eval() / exec() / system() / shell_exec() / subprocess with user input
+  4. Unserialize / pickle.loads() / ObjectInputStream on untrusted data
+  5. Path traversal: open() / file() with user-controlled path (no sanitization)
+  6. SSRF: requests.get(user_input) / urllib.urlopen(user_input) patterns
+  7. JWT without algorithm verification / weak secret
+  8. Insecure cryptography: MD5/SHA1 for passwords, weak RNG
+
+---
+
+## STEP 4 — MANUAL CODE REVIEW (CRITICAL STEP)
+
+For every high-priority finding from Step 3:
+
+  1. Open the file at the flagged line: use read_file tool with the Docker path
+  2. Read 30-50 lines around the finding
+  3. Trace the data flow:
+       - Where does the input ORIGINATE? (HTTP request parameter, file upload, environment var?)
+       - Does it pass through any sanitization / validation? (Is it bypassable?)
+       - Does it reach the dangerous sink UNMODIFIED?
+  4. Identify the triggering HTTP endpoint or function call
+  5. Determine exploitability: can you craft a payload that reaches this sink?
+
+For web apps — find the routes file first:
+  Python/Flask:   app.py, routes.py, views.py, blueprints/
+  Django:         urls.py, views.py
+  Express:        routes/, app.js, index.js, server.js
+  Rails:          config/routes.rb, app/controllers/
+  Laravel:        routes/web.php, routes/api.php, app/Http/Controllers/
+  Spring Boot:    @RequestMapping / @GetMapping / @PostMapping annotations
+
+For each dangerous function: grep for all callers to map the full attack surface:
+  grep -rn "eval\|exec\|system\|shell_exec\|subprocess" <src_path> --include="*.py"
+
+---
+
+## STEP 5 — VULNERABILITY CLASSES TO PRIORITIZE IN SOURCE CODE
+
+When reading code manually, look for these HIGH-IMPACT patterns:
+
+INJECTION VULNERABILITIES:
+  SQL: "SELECT ... " + user_input  OR  f"SELECT ... {var}"  (no parameterization)
+  CMD: subprocess.call(f"cmd {input}", shell=True)  OR  os.system(user_input)
+  SSTI: render_template_string(user_input)  OR  env.from_string(user_input)
+  XXE: ElementTree.parse() without defusedxml, lxml etree without resolve_entities=False
+  LDAP: ldap.search_s() with unsanitized user input
+
+AUTHENTICATION & AUTHORIZATION:
+  Hardcoded credentials in source or config files
+  JWT: "algorithm": "none"  OR  jwt.decode() without algorithm verification
+  Session tokens: predictable / non-random (time-based, sequential)
+  IDOR: queries filtered only by user-supplied ID (no ownership check)
+  Mass Assignment: Model(**request.json) with no field filtering
+
+DESERIALIZATION:
+  Python: pickle.loads(user_data)  OR  yaml.load(data, Loader=Loader)  (not SafeLoader)
+  PHP: unserialize($_GET['data'])
+  Java: ObjectInputStream.readObject()  OR  XStream.fromXML() on untrusted data
+  Ruby: Marshal.load(user_data)
+
+PATH TRAVERSAL:
+  open(user_input)  without normalization and containment check
+  send_file(user_input)  without path sanitization
+  os.path.join(base, user_input)  when user_input starts with "/"
+
+SSRF:
+  requests.get(user_input)  OR  urllib.urlopen(user_input)  without URL validation
+  Webhooks: storing user-provided URLs and fetching them server-side
+  PDF/image generation from user-supplied URLs
+
+CRYPTOGRAPHIC FAILURES:
+  hashlib.md5(password)  OR  hashlib.sha1(password)  for password storage
+  random.random()  OR  random.randint()  for tokens, nonces, reset codes (use secrets.token_hex)
+  Hard-coded IV / symmetric keys in source
+
+SECRETS IN CODE:
+  API_KEY = "sk-..."  or  PASSWORD = "hunter2"  in any source file
+  .env files committed to repo (check git log --all -p -- .env)
+  AWS credentials, private keys, tokens in comments or config
+
+---
+
+## STEP 6 — CONFIRM AND EXPLOIT
+
+A finding is only a vulnerability when exploited with evidence. For each confirmed path:
+
+  [ ] Craft the minimum payload that reaches the sink
+  [ ] Trigger it via the appropriate mechanism (HTTP request, file upload, CLI argument)
+  [ ] Capture the concrete output (error, data exfiltrated, RCE output, blind timing)
+  [ ] Document: vulnerable line → data flow → endpoint → payload → evidence
+
+For web app source code: you can start the app in Docker if it is self-contained:
+  cd /workspace/<target>
+  # Python: pip install -r requirements.txt && python app.py &
+  # Node.js: npm install && node server.js &
+  # Then test with curl -x http://127.0.0.1:48080 against localhost
+
+---
+
+## STEP 7 — REPORT
+
+Use create_vulnerability_report for EVERY confirmed, exploitable finding.
+
+Required evidence:
+  - poc_description: exact payload used + concrete output received
+  - poc_script_code: working Python/curl/bash script demonstrating exploitation
+  - technical_analysis: exact file path, line number, data flow description
+  - suggested_fix: corrected code snippet (parameterized query, safe API, sanitization)
+
+DO NOT report:
+  - Unverified semgrep/bandit findings without manual confirmation
+  - "Potential" or "possible" issues without demonstrated exploitation
+  - Informational issues (version disclosure, missing headers) unless specifically requested
+
+---
+
+## COMMON MISTAKES — AVOID THESE
+
+  WRONG: Run semgrep, copy its output as findings → REPORT ALL
+  RIGHT: Run semgrep, read flagged lines manually, trace data flow, exploit, then report
+
+  WRONG: "Found eval() at line 42 — this is RCE"
+  RIGHT: "Found eval(user_param) at line 42. user_param = request.args['cmd'].
+          Tested GET /?cmd=__import__('os').system('id') → returned 'uid=33(www-data)' in response body"
+
+  WRONG: Try to open /home/pikpikcu/.../workspace/src/ in execute
+  RIGHT: Use /workspace/<target>/uploads/ path (or whatever the FILE REFERENCE block shows)
+
+  WRONG: Report every bandit LOW finding
+  RIGHT: Focus on HIGH/MEDIUM severity + any hardcoded secrets
+
+---
+
+## DEPENDENCY VULNERABILITY SCAN (BONUS — run after main analysis)
+
+  # Python
+  pip-audit -r <src_path>/requirements.txt --format=json > /workspace/<target>/output/pip_audit.json 2>/dev/null
+  safety check -r <src_path>/requirements.txt --json > /workspace/<target>/output/safety.json 2>/dev/null
+
+  # Node.js
+  cd <src_path> && npm audit --json > /workspace/<target>/output/npm_audit.json 2>/dev/null
+
+  # Ruby
+  cd <src_path> && bundle-audit check --update > /workspace/<target>/output/bundle_audit.txt 2>/dev/null
+
+  # Java (Maven)
+  cd <src_path> && mvn org.owasp:dependency-check-maven:check 2>/dev/null || true
+
+Known CVEs in dependencies are worth reporting if the vulnerable functionality
+is actually used in the codebase — confirm usage before reporting.

package/skills/offensive/airecon-fork/tools-sqlmap/SKILL.md

@@ -0,0 +1,137 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+# sqlmap & ghauri — Usage Guide for AIRecon
+
+sqlmap and ghauri are SQL injection testing tools. They are effective ONLY when pointed at a
+specific, manually-confirmed injectable parameter. Running either against a root URL, an IP address,
+or a randomly chosen endpoint without prior manual analysis is the definition of incompetent testing.
+It produces false negatives, wastes time, and triggers WAF bans.
+
+---
+
+## MANDATORY PRE-CONDITIONS (All must be true before using sqlmap or ghauri)
+
+  [ ] You have manually browsed the application and identified a specific feature that interacts
+      with a database (e.g., search, login, product lookup, user profile, filter/sort functionality).
+  [ ] You have manually confirmed a specific URL and parameter (or POST body field) that:
+        a. Accepts user-controlled input
+        b. Shows evidence of server-side database interaction (e.g., different results for different
+           values, error messages mentioning SQL, response time anomalies on numeric inputs)
+  [ ] You have manually tested that parameter with at least one basic probe:
+        - A single quote: value'  — does the response change or error?
+        - A boolean: value AND 1=1  vs  value AND 1=2  — are responses different?
+        - A time probe: value; WAITFOR DELAY '0:0:5'-- or SLEEP(5)  — is there a delay?
+  [ ] The specific URL+parameter combination is documented in your notes before running the tool.
+  [ ] output/host_profiles.json contains an entry for this host with the parameter listed as
+      a confirmed input vector.
+
+Using sqlmap/ghauri against a bare URL with no parameter identified = TASK FAILURE.
+Using sqlmap/ghauri as the FIRST tool run on a host = TASK FAILURE.
+
+---
+
+## How to Identify SQL Injection Candidates Manually
+
+Before sqlmap touches anything, you must have found a candidate parameter. Methods:
+
+  1. BROWSER + SOURCE INSPECTION:
+     - Navigate the application as a user. Click everything. Fill every form.
+     - Look for: search bars, login forms, ID-based URLs (/user?id=5, /item/123),
+       filter parameters (?category=electronics&sort=price), report generators.
+     - In page source: look for inline SQL fragments, database error messages, numeric IDs
+       in hidden form fields or URL params.
+
+  2. MANUAL PROBE WITH CURL:
+     - For a parameter suspected to be SQL-backed, send:
+         curl "http://host/search?q=test'"           (single quote — syntax error?)
+         curl "http://host/search?q=test AND 1=1"    (tautology — same result as normal?)
+         curl "http://host/search?q=test AND 1=2"    (contradiction — different/empty result?)
+     - Compare response sizes, content, and timing across these three requests.
+     - If behavior differs between AND 1=1 and AND 1=2: strong SQL injection signal.
+
+  3. HISTORICAL URL ANALYSIS:
+     - Parse output/historical_urls.txt for URLs with numeric or ID-style parameters.
+     - Prioritize parameters named: id, uid, user_id, product_id, item, page, order, ref,
+       category, sort, filter, q, search, query, token, hash.
+
+  4. CRAWLER OUTPUT FILTERING:
+     - Parse output/urls_all_deduped.txt for parameterized URLs.
+     - Use pattern matching to extract URLs with parameters before ANY scanner touches them.
+
+---
+
+## Confirmed Candidate — Now Run sqlmap
+
+Once you have a specific URL+parameter confirmed through manual probing:
+
+  Basic detection (start here):
+    sqlmap -u "http://host/path?param=VALUE" -p param --batch --level=1 --risk=1 \
+      --output-dir output/sqlmap/
+
+  If basic detection finds nothing, escalate carefully:
+    sqlmap -u "http://host/path?param=VALUE" -p param --batch --level=3 --risk=2 \
+      --output-dir output/sqlmap/
+
+  For POST body parameters:
+    sqlmap -u "http://host/login" --data "username=admin&password=test" -p username \
+      --batch --level=2 --output-dir output/sqlmap/
+
+  For JSON body parameters:
+    sqlmap -u "http://host/api/search" --data '{"query":"test"}' \
+      --headers "Content-Type: application/json" -p query --batch --output-dir output/sqlmap/
+
+  For cookie-based injection:
+    sqlmap -u "http://host/profile" --cookie "session=VALUE" -p session \
+      --level=2 --batch --output-dir output/sqlmap/
+
+  After confirming injection exists, extract database info:
+    sqlmap -u "<confirmed_injectable_url>" --dbs --batch --output-dir output/sqlmap/
+
+  ghauri (faster, WAF-evasive alternative — same pre-conditions apply):
+    ghauri -u "http://host/path?param=VALUE" --dbs --batch
+
+NEVER use these patterns:
+  sqlmap -u "http://host/" --dbs               (no parameter identified)
+  sqlmap -u "http://host:80" --dbs             (root URL, no parameter, no evidence)
+  sqlmap -l output/live_hosts.txt              (list input, no parameter context)
+
+---
+
+## WAF Evasion (Only After Confirming Injection Exists)
+
+If a confirmed injection is being blocked by a WAF:
+
+  sqlmap -u "<url>" -p param --tamper=space2comment,randomcase --batch
+  sqlmap -u "<url>" -p param --tamper=between,charencode --batch
+  sqlmap -u "<url>" -p param --random-agent --delay=2 --batch
+
+Use web_search "sqlmap tamper <WAF vendor>" to find vendor-specific tamper scripts.
+
+---
+
+## Interpreting Results
+
+  "parameter appears to be injectable" — VERIFY MANUALLY before reporting.
+    Reproduce the detection payload manually with curl. Confirm the behavioral difference.
+
+  "fetched databases" or actual data returned — this is confirmed exploitation.
+    Document the exact injectable URL, parameter, injection type, and database output.
+    Write the reproduction curl command. THEN call create_vulnerability_report.
+
+  Empty results — do NOT escalate blindly. Consider:
+    - Is the parameter actually processed server-side (check response variance manually first)?
+    - Is there a WAF? Test for WAF with wafw00f before running sqlmap.
+    - Is the injection blind (time-based, OOB)? Requires --technique=T or --technique=U flags.
+
+---
+
+## Workflow Integration (Where sqlmap Fits)
+
+  Phase 1 (Manual Profiling): DO NOT use sqlmap or ghauri.
+  Phase 2 (Attack Surface Expansion): DO NOT use sqlmap or ghauri.
+  Phase 3 (Business Logic & Auth Testing): sqlmap/ghauri valid ONLY if a specific parameter
+    has been manually confirmed as a database-backed SQL input vector during Phase 1-2 analysis.
+  Phase 4+ (Vulnerability Chaining): sqlmap/ghauri valid for confirmed candidates.
+
+The correct sequence is always: observe -> identify candidate -> manually probe -> confirm -> then tool.
+sqlmap confirms and exploits. It does not discover. Discovery is your job.