@aegis-scan/skills 0.4.0 → 0.5.1

package/skills/offensive/airecon-fork/reconnaissance-ctf-methodology/SKILL.md

@@ -0,0 +1,435 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+# CTF Challenge Methodology — Thinking + Execution Framework
+
+How to approach Capture The Flag challenges. This covers both methodology AND execution
+discipline to prevent common mistakes.
+
+---
+
+## Understanding CTF
+
+CTF challenges are designed puzzles where every element is intentional. Unlike bug bounty,
+there are no false positives — if something looks strange, it IS the vulnerability.
+The challenge author placed every component deliberately.
+
+### CTF Categories
+
+CTF is broad. The challenge type determines your approach:
+
+- **Web** — Vulnerable web applications (the most common in pentest-style CTFs)
+- **Crypto** — Cryptographic weaknesses, cipher breaking, key recovery
+- **Forensics** — Analyzing files, memory dumps, packet captures, steganography
+- **Pwn/Binary** — Buffer overflows, format strings, ROP chains, heap exploitation
+- **Reverse Engineering** — Analyzing compiled binaries to understand hidden logic
+- **Misc** — Anything goes: OSINT, scripting, puzzles, unconventional challenges
+
+This skill focuses on **web CTF** since AIRecon's tools are web-focused, but the thinking
+principles apply to all categories.
+
+---
+
+## CRITICAL: Execution Discipline
+
+These rules prevent the most common failure modes. Follow them STRICTLY.
+
+### Rule 1: Maintain Session State Across ALL Requests
+
+Web applications use cookies to track sessions. If you don't persist cookies, the
+application forgets who you are and every request starts from zero.
+
+**EVERY curl command MUST include both `-c` and `-b` with the same cookie file in the output directory:**
+- `-c output/cookies.txt` saves cookies from the response
+- `-b output/cookies.txt` sends saved cookies with the request
+- Use BOTH on EVERY request, not just the first one
+
+If you see a 302 redirect back to a login page, it means your session was lost because
+you forgot to send cookies.
+
+### Rule 2: Never Repeat the Same Request
+
+If you already fetched a URL and read its content, DO NOT fetch it again.
+You already have the information. Use it.
+
+If you need to reference earlier data, recall it from your conversation context.
+The data is already in your memory from the previous tool output.
+
+### Rule 3: Understand Exit Codes
+
+When using `grep` or similar filtering commands:
+- **Exit code 0** = matches were found (success)
+- **Exit code 1** = NO matches were found (this is NOT an error — it means the pattern
+  simply wasn't present in the data)
+- **Exit code 2+** = actual error (syntax problem, file not found, etc.)
+
+When the execute tool reports "ERROR: Command failed (exit code: 1)" after a grep,
+it means the pattern was NOT found. This is useful information — the flag is not in
+that response. Move to the next endpoint.
+
+### Rule 4: Use the Correct Workspace Paths
+
+Your workspace follows a strict structure based on the target:
+```
+/workspace/<target>/
+    command/        ← command execution logs (auto-saved)
+    output/         ← YOUR output files go here
+    tools/          ← custom scripts you create
+    vulnerabilities/ ← vulnerability reports (auto-saved)
+```
+
+For example, if the target is `localhost:8080`:
+- Save curl output to: `/workspace/localhost:8080/output/main_page.html`
+- Save scripts to: `/workspace/localhost:8080/tools/exploit.py`
+
+**Never use** `/workspace/output/` (missing target) or `output/` (relative).
+
+### Rule 5: Don't Use read_file for Files You Haven't Saved
+
+The `read_file` tool reads files from the workspace. If you haven't explicitly saved
+a curl response to a file, the file doesn't exist. Either:
+- Save it: `curl -s URL > output/filename.html`
+- Or just read the curl output directly — it's already in your conversation context
+
+### Rule 6: Handle Redirects With Session
+
+A 302 redirect after login means the login succeeded and the app wants to redirect you.
+But a redirect changes POST to GET and may drop cookies. To handle multi-step flows:
+
+1. Make each request separately (don't use `-L` for POST requests)
+2. Read the `Location` header from the response
+3. Make a NEW GET request to that location, with cookies
+
+### Rule 7: Read the Full Response Before Acting
+
+Don't pipe curl through `head -100` or `grep` on the first request. Read the ENTIRE
+response first. After you understand the full page, use grep for specific searches.
+
+### Rule 8: Track Your Discoveries
+
+As you test, keep a mental inventory of what you've found:
+- **Credentials discovered**: (from comments, config files, error messages)
+- **Endpoints discovered**: (from HTML links, JavaScript, form actions)
+- **Hidden fields discovered**: (from form analysis)
+- **Session state**: (are you logged in? which user?)
+
+Every new piece of information should inform your next action.
+
+---
+
+## Core Principle: Read Before You Act
+
+The single most important skill in CTF is **reading carefully**.
+
+### Read HTML Completely
+
+Every line matters. The flag or the path to it is hidden in the response:
+- Comments that developers "forgot" to remove
+- Hidden form fields that reveal internal structure
+- JavaScript code that shows how the application ACTUALLY works
+- Error messages that leak implementation details
+- HTTP headers that reveal the technology stack
+
+### Read JavaScript Completely
+
+JavaScript is the map of the application. It shows you:
+- Every API endpoint the frontend communicates with
+- The exact URL patterns and parameter names
+- How data flows between pages
+- Authentication and authorization logic on the client side
+- AJAX calls that reveal backend routes invisible in the HTML
+
+**IMPORTANT:** JavaScript is often at the BOTTOM of the HTML page. If you only read the
+first part of a response, you miss the most critical information.
+
+### Read Error Messages
+
+Errors are not failures — they are information:
+- A 400 Bad Request tells you what the server EXPECTED
+- A 404 tells you the URL pattern is wrong — re-examine the source
+- A 405 tells you the HTTP method is wrong
+- A 500 may leak stack traces, file paths, database queries
+- A 302 redirect tells you WHERE the application wants you to go
+
+---
+
+## Methodology: Observe → Hypothesize → Test → Adapt
+
+### Step 1: Observe
+
+Fetch the application and absorb EVERYTHING. Don't rush to test.
+- What does this application do? What is its purpose?
+- What technology is it built with?
+- What are all the routes, forms, and interactive elements?
+- What does the JavaScript reveal about the backend?
+- Are there HTML comments, hidden fields, or debug information?
+- What does the HTTP response header tell you about the server?
+
+### Step 2: Hypothesize
+
+Based on your observations, form theories about where the vulnerability is:
+- "This form has a multi-step flow — maybe the second step has weaker validation"
+- "These numeric IDs in the URL suggest predictable identifiers"
+- "This search parameter reflects input back — possible injection point"
+- "The JavaScript reveals an endpoint not linked in the UI"
+- "This hidden field contains a user ID — maybe I can change it"
+
+### Step 3: Test
+
+Test ONE hypothesis at a time. Use the right tool for the job:
+- **curl / execute**: When you need to see raw HTTP responses, control exact headers,
+  manage cookies manually, or chain multiple requests
+- **browser_action**: When you need to interact with JavaScript-heavy applications,
+  see rendered pages, click buttons, fill forms interactively
+- **Caido proxy**: When you need to intercept and modify requests in-flight, replay
+  requests with modifications, or analyze traffic patterns
+
+### Step 4: Adapt
+
+If your test fails, DON'T repeat it. Adapt:
+- Analyze WHY it failed — what did the error tell you?
+- Go back to the response and read it again more carefully
+- Form a NEW hypothesis based on the error
+- Try a different approach or a different part of the application
+
+---
+
+## Web CTF Thinking Patterns
+
+### Pattern: Multi-Step Authentication
+
+Many web apps split authentication across multiple pages. Each page has its own form
+with its own fields. You MUST interact with each page separately, following the
+application's intended flow but looking for weaknesses at each step.
+
+**Think about:**
+- What fields does this specific form expect?
+- What happens when I submit? Where does it redirect?
+- Can I manipulate the redirect destination?
+- Can I skip a step entirely?
+- Are there hidden fields I can modify?
+
+### Pattern: Object References
+
+When you see identifiers in URLs or responses (numbers, UUIDs, slugs), ask yourself:
+- Who does this object belong to?
+- Can I access objects that belong to other users?
+- Is there a sequential pattern I can predict?
+- What happens if I use an ID that shouldn't be accessible to me?
+
+### Pattern: Client-Side Trust
+
+Applications often trust client-side data. Think about:
+- Hidden form fields that could be editable
+- Cookie values that encode user information
+- Client-side validation that can be bypassed
+- Prices, permissions, or roles stored in the request
+
+### Pattern: Information Leakage
+
+Developers leave traces. Think about:
+- HTML comments with development notes
+- Backup files or configuration files accessible via URL
+- Error messages that reveal code structure
+- Response headers that leak technology information
+- API endpoints that return more data than the UI shows
+
+### Pattern: Injection Points
+
+Wherever user input enters the application, think about:
+- Is this input reflected in the response?
+- Is this input used in a database query?
+- Is this input used in a file path?
+- Is this input used in a system command?
+- Is this input used in a template?
+
+### Pattern: Session and State
+
+Think about how the application tracks who you are:
+- How is your session maintained after login?
+- Can you forge or modify session tokens?
+- What happens if you perform actions without a valid session?
+- Can you escalate permissions by manipulating session data?
+
+---
+
+## Tool Selection: Context Matters
+
+There is no "best tool" — each tool has a purpose:
+
+### Use curl (execute) when:
+- You need to see the raw, unprocessed HTTP response
+- You want full control over headers, cookies, and request body
+- You're testing specific parameter values
+- You need to chain multiple requests with shared cookies
+- You want to automate testing with loops or scripts
+
+### Use browser_action when:
+- The application relies heavily on JavaScript for rendering
+- You need to interact with dynamic elements (dropdowns, modals, AJAX)
+- You need to fill forms that have client-side validation
+- You want to see what a real user sees
+- JavaScript execution is required to trigger certain behaviors
+
+### Use Caido when:
+- You want to intercept and modify requests between browser and server
+- You need to replay a captured request with slight modifications
+- You want to analyze the full traffic flow of a complex interaction
+- You're testing race conditions or need precise request timing
+- You need to compare responses across multiple modified requests
+
+### Write custom scripts (execute with Python) when:
+- You need to automate a specific testing pattern
+- The vulnerability requires complex multi-step exploitation
+- You need to brute-force a specific parameter space
+- You want to parse and analyze large responses programmatically
+
+---
+
+## Common Mistakes in CTF
+
+1. **Not reading the full response** — The answer is in the data you already received
+2. **Repeating the same request** — If it failed, change your approach
+3. **Guessing URL patterns** — Read the JavaScript to find exact endpoints
+4. **Sending extra form fields** — Only send what the form expects
+5. **Using the wrong HTTP method** — Check the form's method attribute
+6. **Ignoring redirects** — Follow them to see where the app takes you
+7. **Not managing cookies** — Authentication requires session persistence
+8. **Running recon scanners** — CTF is a focused puzzle, not a wide-net hunt
+9. **Over-automating** — Sometimes manually reading a response reveals the flag
+10. **Not thinking about the challenge author's intent** — Ask "what did they WANT me to find?"
+
+---
+
+## Flag Detection Pattern
+
+The flag is the proof that you solved the challenge. You must actively look for it
+in EVERY response you receive.
+
+### Flag Formats
+
+Flags follow recognizable patterns, but the format varies by CTF:
+- `FLAG{...}` — the most common format
+- `flag{...}` — lowercase variant
+- `CTF{...}` — competition-specific prefix
+- Custom formats: `XBOW{...}`, `HTB{...}`, `picoCTF{...}`, etc.
+- Sometimes the flag is a plain string described in the challenge instructions
+
+**IMPORTANT:** Always check the challenge description for the expected flag format.
+If the challenge says "the flag is in format FLAG{...}", that's what you search for.
+
+### Where Flags Appear
+
+Flags can be embedded ANYWHERE in the application's responses. Develop the habit of
+scanning every response you receive:
+
+- **In the HTTP response body** — embedded in HTML, JSON, or plain text
+- **In HTTP response headers** — custom headers like `X-Flag:` or `X-Secret:`
+- **In HTML comments** — `<!-- FLAG{...} -->`
+- **In database records** — accessible through data access vulnerabilities
+- **In files on the server** — accessible through file access vulnerabilities
+- **In error messages** — verbose errors may include flag data
+- **In cookies or tokens** — decoded JWT payloads, base64-encoded cookie values
+- **In JavaScript variables** — hardcoded in client-side code
+- **In API responses** — JSON fields you don't see in the UI
+
+### Detection Approach
+
+After EVERY significant interaction with the application:
+1. Scan the full response for the expected flag pattern
+2. Check if any new data was revealed that you haven't seen before
+3. Look for base64-encoded strings and decode them — they may contain the flag
+4. If you retrieve structured data (JSON, database rows), examine EVERY field
+
+### When You Find the Flag
+
+The moment you see a string matching the expected flag pattern:
+1. Confirm it matches the expected format exactly
+2. Report it immediately — don't continue testing
+
+---
+
+## CTF Reporting
+
+CTF reports must be detailed and professional. Finding the flag is only half the work —
+documenting the vulnerability, exploitation path, and evidence is equally important.
+
+### When to Report
+
+Call `create_vulnerability_report` immediately when you find the flag.
+Do NOT continue testing after finding the flag.
+
+### Report Quality Standard
+
+Every field should demonstrate clear, evidence-based analysis. The report should read
+like a professional penetration test finding.
+
+### How to Fill Each Field
+
+**title**: Specific vulnerability name with affected endpoint.
+Describe WHAT vulnerability and WHERE it was found. Be precise.
+
+**description**: Executive summary covering:
+- What vulnerability was found
+- How it was exploited
+- What data was exposed
+- The flag that was extracted
+Write this as a clear paragraph explaining the full finding.
+
+**target**: The full target URL (e.g., `http://localhost:8080`)
+
+**impact**: What an attacker could do with this vulnerability:
+- What data is exposed
+- How many records or users are affected
+- Business consequences
+
+**technical_analysis**: Root cause analysis:
+- WHY the vulnerability exists (what check or control is missing)
+- What the expected secure behavior should be vs actual behavior
+- How the authentication/session mechanism works (if relevant)
+
+**poc_description**: Step-by-step exploitation walkthrough with HTTP evidence:
+1. Initial interaction — show the first request and what was discovered
+2. Exploitation — show the exact request that exploits the vulnerability
+3. Flag extraction — show the exact response containing the flag
+Include actual HTTP status codes for every step.
+
+**poc_script_code**: A complete, automated exploitation script that reproduces the
+finding end-to-end. Should be executable Python or a series of curl commands.
+The script must:
+- Handle authentication if needed
+- Perform the exact exploit steps
+- Search for and extract the flag
+- Print the flag when found
+
+**remediation_steps**: Concrete fix recommendations:
+- Code-level fix (authorization check before returning data)
+- Architecture-level fix (use opaque IDs, implement RBAC)
+- Detection (access logging, rate limiting)
+
+**flag**: The exact flag string: `FLAG{...}`
+
+### Optional but Recommended
+
+- **attack_vector** through **availability** (CVSS): Include if you can assess it accurately
+- **endpoint**: The specific vulnerable endpoint
+- **method**: The HTTP method used
+- **suggested_fix**: A code snippet showing the fix
+
+### Reporting Mindset
+
+Think of the report as something that would be submitted to a client. Even though it's
+a CTF, the quality should match professional penetration testing standards:
+- Evidence-based (show actual HTTP requests and responses)
+- Technically detailed (explain the root cause, not just the symptoms)
+- Actionable (tell the developer exactly how to fix it)
+- Complete (someone else should be able to reproduce this from your report alone)
+
+---
+
+## Summary
+
+CTF is problem-solving, not tool-running. **Read carefully, think deeply, test precisely.**
+Every element in a CTF is there for a reason. The flag is always reachable through the
+vulnerability the author intended. Your job is to understand the application deeply enough
+to find that path. Maintain session state, track your discoveries, and never repeat yourself.
+When you find the flag, report it with the same quality as a professional pentest finding.

package/skills/offensive/airecon-fork/reconnaissance-dorking/SKILL.md

@@ -0,0 +1,182 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: dorking
+description: Google dorking and OSINT search techniques for passive reconnaissance — find exposed panels, leaked credentials, sensitive files, and attack surface using web_search without API keys
+---
+
+# Dorking & OSINT Reconnaissance
+
+Dorking = leveraging search engine operators to find exposed systems, sensitive files, credentials, and configuration information without touching the target directly.
+
+**Tool to use**: `web_search` (SearXNG backend — supports full Google dork operators, no API key required)
+**Results**: auto-saved to `output/dork_results.txt`
+
+> NOTE: Shodan, Censys, FOFA require API keys not available here. Use Google dork equivalents via `web_search` instead.
+
+---
+
+## Google Dork Operators
+
+    site:target.com                          # Restrict to domain
+    inurl:admin site:target.com             # URL contains "admin"
+    intitle:"index of" site:target.com      # Page title contains text
+    filetype:pdf site:target.com            # File extension filter
+    intext:"password" site:target.com       # Body text contains
+    ext:env site:target.com                 # File extension (same as filetype)
+
+---
+
+## High-Value Google Dorks
+
+### Exposed Admin Panels
+
+    site:target.com inurl:admin
+    site:target.com inurl:login
+    site:target.com inurl:dashboard
+    site:target.com inurl:"/wp-admin/"           # WordPress admin
+    site:target.com inurl:"/administrator/"      # Joomla admin
+    site:target.com inurl:"/phpmyadmin/"
+    site:target.com inurl:"/manager/html"        # Tomcat manager
+    site:target.com inurl:"/jenkins/"
+    site:target.com inurl:"/kibana/"
+    site:target.com inurl:"/grafana/"
+
+### Sensitive Files
+
+    site:target.com filetype:env
+    site:target.com filetype:log
+    site:target.com filetype:sql
+    site:target.com filetype:bak
+    site:target.com filetype:conf
+    site:target.com filetype:xml inurl:config
+    site:target.com ext:php.bak
+    site:target.com ext:old
+    site:target.com ext:txt inurl:password
+
+### Exposed Credentials / Secrets
+
+    site:target.com intext:"DB_PASSWORD"
+    site:target.com intext:"api_key"
+    site:target.com intext:"BEGIN RSA PRIVATE KEY"
+    site:target.com intext:"AWS_SECRET_ACCESS_KEY"
+    site:target.com filetype:env intext:"SECRET_KEY"
+
+### Directory Listing
+
+    site:target.com intitle:"index of"
+    site:target.com intitle:"index of /" inurl:backup
+    site:target.com intitle:"index of" intext:".sql"
+    site:target.com intitle:"index of" intext:"id_rsa"
+
+### Vulnerable Parameters
+
+    site:target.com inurl:".php?id="              # Potential SQLi
+    site:target.com inurl:"?redirect="            # Open redirect
+    site:target.com inurl:"?file="                # LFI potential
+    site:target.com inurl:"?page="
+    site:target.com inurl:"/cgi-bin/"
+    site:target.com inurl:"upload.php"
+
+### Git Exposure
+
+    site:target.com inurl:"/.git/config"
+    site:target.com intitle:"index of /.git"
+
+### Error Messages
+
+    site:target.com intext:"Warning: mysql_"
+    site:target.com intext:"PHP Warning"
+    site:target.com intext:"Error in your SQL syntax"
+    site:target.com intext:"Traceback (most recent call last)"
+
+---
+
+## GitHub / Code Repository Dorking
+
+Search GitHub for secrets related to target — no API key needed:
+
+    site:github.com "target.com" "api_key"
+    site:github.com "target.com" password
+    site:github.com "target.com" "DB_PASSWORD"
+    site:github.com "target.com" "BEGIN RSA PRIVATE KEY"
+    site:github.com "target.com" "SECRET_KEY"
+    site:github.com "@target.com" password
+    site:github.com org:target-org ".env"
+
+---
+
+## Certificate Transparency (Subdomain Discovery)
+
+Find ALL subdomains including internal/staging via TLS cert logs:
+
+    # Search crt.sh for subdomains:
+    web_search("site:crt.sh %.target.com")
+    web_search("crt.sh target.com subdomains")
+
+    # Direct URL to browse manually:
+    # https://crt.sh/?q=%.target.com
+
+---
+
+## Passive Subdomain Enumeration via Dorking
+
+    site:target.com -www                         # Exclude www, find subdomains
+    site:*.target.com                            # Wildcard subdomain search
+    web_search("site:dnsdumpster.com target.com")
+
+---
+
+## Pastebin / Paste Sites
+
+    site:pastebin.com target.com
+    site:pastebin.com "target.com" password
+    site:paste.ee target.com
+
+---
+
+## Using web_search for Dorking
+
+All dorks run via AIRecon's `web_search` tool — no API key needed:
+
+    # Pattern: web_search("<dork query>")
+
+    web_search("site:target.com filetype:env")
+    web_search("site:target.com inurl:admin intitle:login")
+    web_search("site:target.com intext:\"DB_PASSWORD\"")
+    web_search("site:target.com intitle:\"index of\" intext:.sql")
+    web_search("site:github.com \"target.com\" api_key")
+    web_search("site:crt.sh %.target.com")
+
+    # Results are auto-saved to output/dork_results.txt
+
+---
+
+## Shodan / Censys / FOFA
+
+> These tools require API keys. If the user provides an API key, use it via web_search:
+> - `web_search("shodan target.com port:6379")` → redirects to Shodan results page
+> - Without API key: use Google dork equivalents above instead
+
+---
+
+## Pro Tips
+
+1. Start with `site:target.com` — discover ALL indexed pages and unexpected subdomains
+2. `filetype:env` + `filetype:log` + `filetype:sql` = highest-value dorks for credential exposure
+3. `intitle:"index of"` reveals backup files, SQL dumps, key files
+4. GitHub dorking finds internal tools and hardcoded secrets deleted from main but still searchable
+5. Certificate transparency (`crt.sh`) finds ALL subdomains including internal/staging
+6. Run all dorks in sequence — results accumulate in `output/dork_results.txt`
+
+## Summary
+
+Dorking strategy (zero API key required):
+1. `site:target.com` → map all indexed pages and subdomains
+2. `filetype:env|log|sql|bak` → find sensitive files
+3. `inurl:admin|login|api` → identify attack surfaces
+4. `intext:"DB_PASSWORD|api_key|SECRET"` → find leaked credentials
+5. `site:github.com "target.com"` → GitHub secret search
+6. `site:crt.sh %.target.com` → full subdomain list from cert transparency
+
+All results via `web_search()` — auto-saved to `output/dork_results.txt`.