Add open redirect, subdomain takeover, and info disclosure prompt modules (#132)

Co-authored-by: Ahmed Allam <ahmed39652003@gmail.com>

strix/prompts/vulnerabilities/information_disclosure.jinja

@@ -0,0 +1,222 @@
+<information_disclosure_vulnerability_guide>
+<title>INFORMATION DISCLOSURE</title>
+
+<critical>Information leaks accelerate exploitation by revealing code, configuration, identifiers, and trust boundaries. Treat every response byte, artifact, and header as potential intelligence. Minimize, normalize, and scope disclosure across all channels.</critical>
+
+<scope>
+- Errors and exception pages: stack traces, file paths, SQL, framework versions
+- Debug/dev tooling reachable in prod: debuggers, profilers, feature flags
+- DVCS/build artifacts and temp/backup files: .git, .svn, .hg, .bak, .swp, archives
+- Configuration and secrets: .env, phpinfo, appsettings.json, Docker/K8s manifests
+- API schemas and introspection: OpenAPI/Swagger, GraphQL introspection, gRPC reflection
+- Client bundles and source maps: webpack/Vite maps, embedded env, __NEXT_DATA__, static JSON
+- Headers and response metadata: Server/X-Powered-By, tracing, ETag, Accept-Ranges, Server-Timing
+- Storage/export surfaces: public buckets, signed URLs, export/download endpoints
+- Observability/admin: /metrics, /actuator, /health, tracing UIs (Jaeger, Zipkin), Kibana, Admin UIs
+- Directory listings and indexing: autoindex, sitemap/robots revealing hidden routes
+- Cross-origin signals: CORS misconfig, Referrer-Policy leakage, Expose-Headers
+- File/document metadata: EXIF, PDF/Office properties
+</scope>
+
+<methodology>
+1. Build a channel map: Web, API, GraphQL, WebSocket, gRPC, mobile, background jobs, exports, CDN.
+2. Establish a diff harness: compare owner vs non-owner vs anonymous across transports; normalize on status/body length/ETag/headers.
+3. Trigger controlled failures: send malformed types, boundary values, missing params, and alternate content-types to elicit error detail and stack traces.
+4. Enumerate artifacts: DVCS folders, backups, config endpoints, source maps, client bundles, API docs, observability routes.
+5. Correlate disclosures to impact: versions→CVE, paths→LFI/RCE, keys→cloud access, schemas→auth bypass, IDs→IDOR.
+</methodology>
+
+<surfaces>
+<errors_and_exceptions>
+- SQL/ORM errors: reveal table/column names, DBMS, query fragments
+- Stack traces: absolute paths, class/method names, framework versions, developer emails
+- Template engine probes: {% raw %}{{7*7}}, ${7*7}{% endraw %} identify templating stack and code paths
+- JSON/XML parsers: type mismatches and coercion logs leak internal model names
+</errors_and_exceptions>
+
+<debug_and_env_modes>
+- Debug pages and flags: Django DEBUG, Laravel Telescope, Rails error pages, Flask/Werkzeug debugger, ASP.NET customErrors Off
+- Profiler endpoints: /debug/pprof, /actuator, /_profiler, custom /debug APIs
+- Feature/config toggles exposed in JS or headers; admin/staff banners in HTML
+</debug_and_env_modes>
+
+<dvcs_and_backups>
+- DVCS: /.git/ (HEAD, config, index, objects), .svn/entries, .hg/store → reconstruct source and secrets
+- Backups/temp: .bak/.old/~/.swp/.swo/.tmp/.orig, db dumps, zipped deployments under /backup/, /old/, /archive/
+- Build artifacts: dist artifacts containing .map, env prints, internal URLs
+</dvcs_and_backups>
+
+<configs_and_secrets>
+- Classic: web.config, appsettings.json, settings.py, config.php, phpinfo.php
+- Containers/cloud: Dockerfile, docker-compose.yml, Kubernetes manifests, service account tokens, cloud credentials files
+- Credentials and connection strings; internal hosts and ports; JWT secrets
+</configs_and_secrets>
+
+<api_schemas_and_introspection>
+- OpenAPI/Swagger: /swagger, /api-docs, /openapi.json — enumerate hidden/privileged operations
+- GraphQL: introspection enabled; field suggestions; error disclosure via invalid fields; persisted queries catalogs
+- gRPC: server reflection exposing services/messages; proto download via reflection
+</api_schemas_and_introspection>
+
+<client_bundles_and_maps>
+- Source maps (.map) reveal original sources, comments, and internal logic
+- Client env leakage: NEXT_PUBLIC_/VITE_/REACT_APP_ variables; runtime config; embedded secrets accidentally shipped
+- Next.js data: __NEXT_DATA__ and pre-fetched JSON under /_next/data can include internal IDs, flags, or PII
+- Static JSON/CSV feeds used by the UI that bypass server-side auth filtering
+</client_bundles_and_maps>
+
+<headers_and_response_metadata>
+- Fingerprinting: Server, X-Powered-By, X-AspNet-Version
+- Tracing: X-Request-Id, traceparent, Server-Timing, debug headers
+- Caching oracles: ETag/If-None-Match, Last-Modified/If-Modified-Since, Accept-Ranges/Range (partial content reveals)
+- Content sniffing and MIME metadata that implies backend components
+</headers_and_response_metadata>
+
+<storage_and_exports>
+- Public object storage: S3/GCS/Azure blobs with world-readable ACLs or guessable keys
+- Signed URLs: long-lived, weakly scoped, re-usable across tenants; metadata leaks in headers
+- Export/report endpoints returning foreign data sets or unfiltered fields
+</storage_and_exports>
+
+<observability_and_admin>
+- Metrics: Prometheus /metrics exposing internal hostnames, process args, SQL, credentials by mistake
+- Health/config: /actuator/health, /actuator/env, Spring Boot info endpoints
+- Tracing UIs and dashboards: Jaeger/Zipkin/Kibana/Grafana exposed without auth
+</observability_and_admin>
+
+<directory_and_indexing>
+- Autoindex on /uploads/, /files/, /logs/, /tmp/, /assets/
+- Robots/sitemap reveal hidden paths, admin panels, export feeds
+</directory_and_indexing>
+
+<cross_origin_signals>
+- Referrer leakage: missing/referrer policy leading to path/query/token leaks to third parties
+- CORS: overly permissive Access-Control-Allow-Origin/Expose-Headers revealing data cross-origin; preflight error shapes
+</cross_origin_signals>
+
+<file_metadata>
+- EXIF, PDF/Office properties: authors, paths, software versions, timestamps, embedded objects
+</file_metadata>
+</surfaces>
+
+<advanced_techniques>
+<differential_oracles>
+- Compare owner vs non-owner vs anonymous for the same resource and track: status, length, ETag, Last-Modified, Cache-Control
+- HEAD vs GET: header-only differences can confirm existence or type without content
+- Conditional requests: 304 vs 200 behaviors leak existence/state; binary search content size via Range requests
+</differential_oracles>
+
+<cdn_and_cache_keys>
+- Identity-agnostic caches: CDN/proxy keys missing Authorization/tenant headers → cross-user cached responses
+- Vary misconfiguration: user-agent/language vary without auth vary leaks alternate content
+- 206 partial content + stale caches leak object fragments
+</cdn_and_cache_keys>
+
+<cross_channel_mirroring>
+- Inconsistent hardening between REST, GraphQL, WebSocket, and gRPC; one channel leaks schema or fields hidden in others
+- SSR vs CSR: server-rendered pages omit fields while JSON API includes them; compare responses
+</cross_channel_mirroring>
+
+<introspection_and_reflection>
+- GraphQL: disabled introspection still leaks via errors, fragment suggestions, and client bundles containing schema
+- gRPC reflection: list services/messages and infer internal resource names and flows
+</introspection_and_reflection>
+
+<cloud_specific>
+- S3/GCS/Azure: anonymous listing disabled but object reads allowed; metadata headers leak owner/project identifiers
+- Pre-signed URLs: audience not bound; observe key scope and lifetime in URL params
+</cloud_specific>
+</advanced_techniques>
+
+<usefulness_assessment>
+- Actionable signals:
+  - Secrets/keys/tokens that grant new access (DB creds, cloud keys, JWT signing/refresh, signed URL secrets)
+  - Versions with a reachable, unpatched CVE on an exposed path
+  - Cross-tenant identifiers/data or per-user fields that differ by principal
+  - File paths, service hosts, or internal URLs that enable LFI/SSRF/RCE pivots
+  - Cache/CDN differentials (Vary/ETag/Range) that expose other users' content
+  - Schema/introspection revealing hidden operations or fields that return sensitive data
+- Likely benign or intended:
+  - Public docs or non-sensitive metadata explicitly documented as public
+  - Generic server names without precise versions or exploit path
+  - Redacted/sanitized fields with stable length/ETag across principals
+  - Per-user data visible only to the owner and consistent with privacy policy
+</usefulness_assessment>
+
+<triage_rubric>
+- Critical: Credentials/keys; signed URL secrets; config dumps; unrestricted admin/observability panels
+- High: Versions with reachable CVEs; cross-tenant data; caches serving cross-user content; schema enabling auth bypass
+- Medium: Internal paths/hosts enabling LFI/SSRF pivots; source maps revealing hidden endpoints/IDs
+- Low: Generic headers, marketing versions, intended documentation without exploit path
+- Guidance: Always attempt a minimal, reversible proof for Critical/High; if no safe chain exists, document precise blocker and downgrade
+</triage_rubric>
+
+<escalation_playbook>
+- If DVCS/backups/configs → extract secrets; test least-privileged read; rotate after coordinated disclosure
+- If versions → map to CVE; verify exposure; execute minimal PoC under strict scope
+- If schema/introspection → call hidden/privileged fields with non-owner tokens; confirm auth gaps
+- If source maps/client JSON → mine endpoints/IDs/flags; pivot to IDOR/listing; validate filtering
+- If cache/CDN keys → demonstrate cross-user cache leak via Vary/ETag/Range; escalate to broken access control
+- If paths/hosts → target LFI/SSRF with harmless reads (e.g., /etc/hostname, metadata headers); avoid destructive actions
+- If observability/admin → enumerate read-only info first; prove data scope breach; avoid write/exec operations
+</escalation_playbook>
+
+<exploitation_chains>
+<credential_extraction>
+- DVCS/config dumps exposing secrets (DB, SMTP, JWT, cloud)
+- Keys → cloud control plane access; rotate and verify scope
+</credential_extraction>
+
+<version_to_cve>
+1. Derive precise component versions from headers/errors/bundles.
+2. Map to known CVEs and confirm reachability.
+3. Execute minimal proof targeting disclosed component.
+</version_to_cve>
+
+<path_disclosure_to_lfi>
+1. Paths from stack traces/templates reveal filesystem layout.
+2. Use LFI/traversal to fetch config/keys.
+3. Prove controlled access without altering state.
+</path_disclosure_to_lfi>
+
+<schema_to_auth_bypass>
+1. Schema reveals hidden fields/endpoints.
+2. Attempt requests with those fields; confirm missing authorization or field filtering.
+</schema_to_auth_bypass>
+</exploitation_chains>
+
+<validation>
+1. Provide raw evidence (headers/body/artifact) and explain exact data revealed.
+2. Determine intent: cross-check docs/UX; classify per triage rubric (Critical/High/Medium/Low).
+3. Attempt minimal, reversible exploitation or present a concrete step-by-step chain (what to try next and why).
+4. Show reproducibility and minimal request set; include cross-channel confirmation where applicable.
+5. Bound scope (user, tenant, environment) and data sensitivity classification.
+</validation>
+
+<false_positives>
+- Intentional public docs or non-sensitive metadata with no exploit path
+- Generic errors with no actionable details
+- Redacted fields that do not change differential oracles (length/ETag stable)
+- Version banners with no exposed vulnerable surface and no chain
+- Owner-visible-only details that do not cross identity/tenant boundaries
+</false_positives>
+
+<impact>
+- Accelerated exploitation of RCE/LFI/SSRF via precise versions and paths
+- Credential/secret exposure leading to persistent external compromise
+- Cross-tenant data disclosure through exports, caches, or mis-scoped signed URLs
+- Privacy/regulatory violations and business intelligence leakage
+</impact>
+
+<pro_tips>
+1. Start with artifacts (DVCS, backups, maps) before payloads; artifacts yield the fastest wins.
+2. Normalize responses and diff by digest to reduce noise when comparing roles.
+3. Hunt source maps and client data JSON; they often carry internal IDs and flags.
+4. Probe caches/CDNs for identity-unaware keys; verify Vary includes Authorization/tenant.
+5. Treat introspection and reflection as configuration findings across GraphQL/gRPC; validate per environment.
+6. Mine observability endpoints last; they are noisy but high-yield in misconfigured setups.
+7. Chain quickly to a concrete risk and stop—proof should be minimal and reversible.
+</pro_tips>
+
+<remember>Information disclosure is an amplifier. Convert leaks into precise, minimal exploits or clear architectural risks.</remember>
+</information_disclosure_vulnerability_guide>

strix/prompts/vulnerabilities/open_redirect.jinja

@@ -0,0 +1,177 @@
+<open_redirect_vulnerability_guide>
+<title>OPEN REDIRECT</title>
+
+<critical>Open redirects enable phishing, OAuth/OIDC code and token theft, and allowlist bypass in server-side fetchers that follow redirects. Treat every redirect target as untrusted: canonicalize and enforce exact allowlists per scheme, host, and path.</critical>
+
+<scope>
+- Server-driven redirects (HTTP 3xx Location) and client-driven redirects (window.location, meta refresh, SPA routers)
+- OAuth/OIDC/SAML flows using redirect_uri, post_logout_redirect_uri, RelayState, returnTo/continue/next
+- Multi-hop chains where only the first hop is validated
+- Allowlist/canonicalization bypasses across URL parsers and reverse proxies
+</scope>
+
+<methodology>
+1. Inventory all redirect surfaces: login/logout, password reset, SSO/OAuth flows, payment gateways, email links, invite/verification, unsubscribe, language/locale switches, /out or /r redirectors.
+2. Build a test matrix of scheme×host×path variants and encoding/unicode forms. Compare server-side validation vs browser navigation results.
+3. Exercise multi-hop: trusted-domain → redirector → external. Verify if validation applies pre- or post-redirect.
+4. Prove impact: credential phishing, OAuth code interception, internal egress (if a server fetcher follows redirects).
+</methodology>
+
+<discovery_techniques>
+<injection_points>
+- Params: redirect, url, next, return_to, returnUrl, continue, goto, target, callback, out, dest, back, to, r, u
+- OAuth/OIDC/SAML: redirect_uri, post_logout_redirect_uri, RelayState, state (if used to compute final destination)
+- SPA: router.push/replace, location.assign/href, meta refresh, window.open
+- Headers influencing construction: Host, X-Forwarded-Host/Proto, Referer; and server-side Location echo
+</injection_points>
+
+<parser_differentials>
+<userinfo>
+https://trusted.com@evil.com → many validators parse host as trusted.com, browser navigates to evil.com
+Variants: trusted.com%40evil.com, a%40evil.com%40trusted.com
+</userinfo>
+
+<backslash_and_slashes>
+https://trusted.com\\evil.com, https://trusted.com\\@evil.com, ///evil.com, /\\evil.com
+Windows/backends may normalize \\ to /; browsers differ on interpretation of extra leading slashes
+</backslash_and_slashes>
+
+<whitespace_and_ctrl>
+http%09://evil.com, http%0A://evil.com, trusted.com%09evil.com
+Control/whitespace around the scheme/host can split parsers
+</whitespace_and_ctrl>
+
+<fragment_and_query>
+trusted.com#@evil.com, trusted.com?//@evil.com, ?next=//evil.com#@trusted.com
+Validators often stop at # while the browser parses after it
+</fragment_and_query>
+
+<unicode_and_idna>
+Punycode/IDN: truѕted.com (Cyrillic), trusted.com。evil.com (full-width dot), trailing dot trusted.com.
+Test with mixed Unicode normalization and IDNA conversion
+</unicode_and_idna>
+</parser_differentials>
+
+<encoding_bypasses>
+- Double encoding: %2f%2fevil.com, %252f%252fevil.com
+- Mixed case and scheme smuggling: hTtPs://evil.com, http:evil.com
+- IP variants: decimal 2130706433, octal 0177.0.0.1, hex 0x7f.1, IPv6 [::ffff:127.0.0.1]
+- User-controlled path bases: /out?url=/\\evil.com
+</encoding_bypasses>
+</discovery_techniques>
+
+<allowlist_evasion>
+<common_mistakes>
+- Substring/regex contains checks: allows trusted.com.evil.com, or path matches leaking external
+- Wildcards: *.trusted.com also matches attacker.trusted.com.evil.net
+- Missing scheme pinning: data:, javascript:, file:, gopher: accepted
+- Case/IDN drift between validator and browser
+</common_mistakes>
+
+<robust_validation>
+- Canonicalize with a single modern URL parser (WHATWG URL) and compare exact scheme, hostname (post-IDNA), and an explicit allowlist with optional exact path prefixes
+- Require absolute HTTPS; reject protocol-relative // and unknown schemes
+- Normalize and compare after following zero redirects only; if following, re-validate the final destination per hop server-side
+</robust_validation>
+</allowlist_evasion>
+
+<oauth_oidc_saml>
+<redirect_uri_abuse>
+- Using an open redirect on a trusted domain for redirect_uri enables code interception
+- Weak prefix/suffix checks: https://trusted.com → https://trusted.com.evil.com; /callback → /callback@evil.com
+- Path traversal/canonicalization: /oauth/../../@evil.com
+- post_logout_redirect_uri often less strictly validated; test both
+- state must be unguessable and bound to client/session; do not recompute final destination from state without validation
+</redirect_uri_abuse>
+
+<defense_notes>
+- Pre-register exact redirect_uri values per client (no wildcards). Enforce exact scheme/host/port/path match
+- For public native apps, follow RFC guidance (loopback 127.0.0.1 with exact port handling); disallow open web redirectors
+- SAML RelayState should be validated against an allowlist or ignored for absolute URLs
+</defense_notes>
+</oauth_oidc_saml>
+
+<client_side_vectors>
+<javascript_redirects>
+- location.href/assign/replace using user input; ensure targets are normalized and restricted to same-origin or allowlist
+- meta refresh content=0;url=USER_INPUT; browsers treat javascript:/data: differently; still dangerous in client-controlled redirects
+- SPA routers: router.push(searchParams.get('next')); enforce same-origin and strip schemes
+</javascript_redirects>
+
+</client_side_vectors>
+
+<reverse_proxies_and_gateways>
+- Host/X-Forwarded-* may change absolute URL construction; validate against server-derived canonical origin, not client headers
+- CDNs that follow redirects for link checking or prefetching can leak tokens when chained with open redirects
+</reverse_proxies_and_gateways>
+
+<ssrf_chaining>
+- Some server-side fetchers (web previewers, link unfurlers, validators) follow 3xx; combine with an open redirect on an allowlisted domain to pivot to internal targets (169.254.169.254, localhost, cluster addresses)
+- Confirm by observing distinct error/timing for internal vs external, or OAST callbacks when reachable
+</ssrf_chaining>
+
+<framework_notes>
+<server_side>
+- Rails: redirect_to params[:url] without URI parsing; test array params and protocol-relative
+- Django: HttpResponseRedirect(request.GET['next']) without is_safe_url; relies on ALLOWED_HOSTS + scheme checks
+- Spring: return "redirect:" + param; ensure UriComponentsBuilder normalization and allowlist
+- Express: res.redirect(req.query.url); use a safe redirect helper enforcing relative paths or a vetted allowlist
+</server_side>
+
+<client_side>
+- React/Next.js/Vue/Angular routing based on URLSearchParams; ensure same-origin policy and disallow external schemes in client code
+</client_side>
+</framework_notes>
+
+<exploitation_scenarios>
+<oauth_code_interception>
+1. Set redirect_uri to https://trusted.example/out?url=https://attacker.tld/cb
+2. IdP sends code to trusted.example which redirects to attacker.tld
+3. Exchange code for tokens; demonstrate account access
+</oauth_code_interception>
+
+<phishing_flow>
+1. Send link on trusted domain: /login?next=https://attacker.tld/fake
+2. Victim authenticates; browser navigates to attacker page
+3. Capture credentials/tokens via cloned UI or injected JS
+</phishing_flow>
+
+<internal_evasion>
+1. Server-side link unfurler fetches https://trusted.example/out?u=http://169.254.169.254/latest/meta-data
+2. Redirect follows to metadata; confirm via timing/headers or controlled endpoints
+</internal_evasion>
+</exploitation_scenarios>
+
+<validation>
+1. Produce a minimal URL that navigates to an external domain via the vulnerable surface; include the full address bar capture.
+2. Show bypass of the stated validation (regex/allowlist) using canonicalization variants.
+3. Test multi-hop: prove only first hop is validated and second hop escapes constraints.
+4. For OAuth/SAML, demonstrate code/RelayState delivery to an attacker-controlled endpoint with role-separated evidence.
+</validation>
+
+<false_positives>
+- Redirects constrained to relative same-origin paths with robust normalization
+- Exact pre-registered OAuth redirect_uri with strict verifier
+- Validators using a single canonical parser and comparing post-IDNA host and scheme
+- User prompts that show the exact final destination before navigating and refuse unknown schemes
+</false_positives>
+
+<impact>
+- Credential and token theft via phishing and OAuth/OIDC interception
+- Internal data exposure when server fetchers follow redirects (previewers/unfurlers)
+- Policy bypass where allowlists are enforced only on the first hop
+- Cross-application trust erosion and brand abuse
+</impact>
+
+<pro_tips>
+1. Always compare server-side canonicalization to real browser navigation; differences reveal bypasses.
+2. Try userinfo, protocol-relative, Unicode/IDN, and IP numeric variants early; they catch many weak validators.
+3. In OAuth, prioritize post_logout_redirect_uri and less-discussed flows; they’re often looser.
+4. Exercise multi-hop across distinct subdomains and paths; validators commonly check only hop 1.
+5. For SSRF chaining, target services known to follow redirects and log their outbound requests.
+6. Favor allowlists of exact origins plus optional path prefixes; never substring/regex contains checks.
+7. Keep a curated suite of redirect payloads per runtime (Java, Node, Python, Go) reflecting each parser’s quirks.
+</pro_tips>
+
+<remember>Redirection is safe only when the final destination is constrained after canonicalization. Enforce exact origins, verify per hop, and treat client-provided destinations as untrusted across every stack.</remember>
+</open_redirect_vulnerability_guide>

strix/prompts/vulnerabilities/subdomain_takeover.jinja

@@ -0,0 +1,155 @@
+<subdomain_takeover_guide>
+<title>SUBDOMAIN TAKEOVER</title>
+
+<critical>Subdomain takeover lets an attacker serve content from a trusted subdomain by claiming resources referenced by dangling DNS (CNAME/A/ALIAS/NS) or mis-bound provider configurations. Consequences include phishing on a trusted origin, cookie and CORS pivot, OAuth redirect abuse, and CDN cache poisoning.</critical>
+
+<scope>
+- Dangling CNAME/A/ALIAS to third-party services (hosting, storage, serverless, CDN)
+- Orphaned NS delegations (child zones with abandoned/expired nameservers)
+- Decommissioned SaaS integrations (support, docs, marketing, forms) referenced via CNAME
+- CDN “alternate domain” mappings (CloudFront/Fastly/Azure CDN) lacking ownership verification
+- Storage and static hosting endpoints (S3/Blob/GCS buckets, GitHub/GitLab Pages)
+</scope>
+
+<methodology>
+1. Enumerate subdomains comprehensively (web, API, mobile, legacy): aggregate CT logs, passive DNS, and org inventory. De-duplicate and normalize.
+2. Resolve DNS for all RR types: A/AAAA, CNAME, NS, MX, TXT. Keep CNAME chains; record terminal CNAME targets and provider hints.
+3. HTTP/TLS probe: capture status, body, length, canonical error text, Server/alt-svc headers, certificate SANs, and CDN headers (Via, X-Served-By).
+4. Fingerprint providers: map known “unclaimed/missing resource” signatures to candidate services. Maintain a living dictionary.
+5. Attempt claim (only with authorization): create the missing resource on the provider with the exact required name; bind the custom domain if the provider allows.
+6. Validate control: serve a minimal unique payload; confirm over HTTPS; optionally obtain a DV certificate (CT log evidence) within legal scope.
+</methodology>
+
+<discovery_techniques>
+<enumeration_pipeline>
+- Subdomain inventory: combine CT (crt.sh APIs), passive DNS sources, in-house asset lists, IaC/terraform outputs, mobile app assets, and historical DNS
+- Resolver sweep: use IPv4/IPv6-aware resolvers; track NXDOMAIN vs SERVFAIL vs provider-branded 4xx/5xx responses
+- Record graph: build a CNAME graph and collapse chains to identify external endpoints (e.g., myapp.example.com → foo.azurewebsites.net)
+</enumeration_pipeline>
+
+<dns_indicators>
+- CNAME targets ending in provider domains: github.io, amazonaws.com, cloudfront.net, azurewebsites.net, blob.core.windows.net, fastly.net, vercel.app, netlify.app, herokudns.com, trafficmanager.net, azureedge.net, akamaized.net
+- Orphaned NS: subzone delegated to nameservers on a domain that has expired or no longer hosts authoritative servers; or to inexistent NS hosts
+- MX to third-party mail providers with decommissioned domains (risk: mail subdomain control or delivery manipulation)
+- TXT/verification artifacts (asuid, _dnsauth, _github-pages-challenge) suggesting previous external bindings
+</dns_indicators>
+
+<http_fingerprints>
+- Service-specific unclaimed messages (examples, not exhaustive):
+  - GitHub Pages: “There isn’t a GitHub Pages site here.”
+  - Fastly: “Fastly error: unknown domain”
+  - Heroku: “No such app” or “There’s nothing here, yet.”
+  - S3 static site: “NoSuchBucket” / “The specified bucket does not exist”
+  - CloudFront (alt domain not configured): 403/400 with “The request could not be satisfied” and no matching distribution
+  - Azure App Service: default 404 for azurewebsites.net unless custom-domain verified (look for asuid TXT requirement)
+  - Shopify: “Sorry, this shop is currently unavailable”
+- TLS clues: certificate CN/SAN referencing provider default host instead of the custom subdomain indicates potential mis-binding
+</http_fingerprints>
+</discovery_techniques>
+
+<exploitation_techniques>
+<claim_third_party_resource>
+- Create the resource with the exact required name:
+  - Storage/hosting: S3 bucket “sub.example.com” (website endpoint) or bucket named after the CNAME target if provider dictates
+  - Pages hosting: create repo/site and add the custom domain (when provider does not enforce prior domain verification)
+  - Serverless/app hosting: create app/site matching the target hostname, then add custom domain mapping
+- Bind the custom domain: some providers require TXT verification (modern hardened path), others historically allowed binding without proof
+</claim_third_party_resource>
+
+<cdn_alternate_domains>
+- Add the victim subdomain as an alternate domain on your CDN distribution if the provider does not enforce domain ownership checks
+- Upload a TLS cert via provider or use managed cert issuance if allowed; confirm 200 on the subdomain with your content
+</cdn_alternate_domains>
+
+<ns_delegation_takeover>
+- If a child zone (e.g., zone.example.com) is delegated to nameservers under an expired domain (ns1.abandoned.tld), register abandoned.tld and host authoritative NS; publish records to control all hosts under the delegated subzone
+- Validate with SOA/NS queries and serve a verification token; then add A/CNAME/MX/TXT as needed
+</ns_delegation_takeover>
+
+<mail_surface>
+- If MX points to a decommissioned provider that allowed inbox creation without domain re-verification (historically), a takeover could enable email receipt for that subdomain; modern providers generally require explicit TXT ownership
+</mail_surface>
+</exploitation_techniques>
+
+<advanced_techniques>
+<blind_and_cache_channels>
+- CDN edge behavior: 404/421 vs 403 differentials reveal whether an alt name is partially configured; probe with Host header manipulation
+- Cache poisoning: once taken over, exploit cache keys and Vary headers to persist malicious responses at the edge
+</blind_and_cache_channels>
+
+<ct_and_tls>
+- Use CT logs to detect unexpected certificate issuance for your subdomain; for PoC, issue a DV cert post-takeover (within scope) to produce verifiable evidence
+</ct_and_tls>
+
+<oauth_and_trust_chains>
+- If the subdomain is whitelisted as an OAuth redirect/callback or in CSP/script-src, a takeover elevates impact to account takeover or script injection on trusted origins
+</oauth_and_trust_chains>
+
+<provider_edges>
+- Many providers hardened domain binding (TXT verification) but legacy projects or specific products remain weak; verify per-product behavior (CDN vs app hosting vs storage)
+- Multi-tenant providers sometimes accept custom domains at the edge even when backend resource is missing; leverage timing and registration windows
+</provider_edges>
+</advanced_techniques>
+
+<bypass_techniques>
+<verification_gaps>
+- Look for providers that accept domain binding prior to TXT verification, or where verification is optional for trial/legacy tiers
+- Race windows: re-claim resource names immediately after victim deletion while DNS still points to provider
+</verification_gaps>
+
+<wildcards_and_fallbacks>
+- Wildcard CNAMEs to providers may expose unbounded subdomains; test random hosts to identify service-wide unclaimed behavior
+- Fallback origins: CDNs configured with multiple origins may expose unknown-domain responses from a default origin that is claimable
+</wildcards_and_fallbacks>
+</bypass_techniques>
+
+<special_contexts>
+<storage_and_static>
+- S3/GCS/Azure Blob static sites: bucket naming constraints dictate whether a bucket can match hostname; website vs API endpoints differ in claimability and fingerprints
+</storage_and_static>
+
+<serverless_and_hosting>
+- GitHub/GitLab Pages, Netlify, Vercel, Azure Static Web Apps: domain binding flows vary; most require TXT now, but historical projects or specific paths may not
+</serverless_and_hosting>
+
+<cdn_and_edge>
+- CloudFront/Fastly/Azure CDN/Akamai: alternate domain verification differs; some products historically allowed alt-domain claims without proof
+</cdn_and_edge>
+
+<dns_delegations>
+- Child-zone NS delegations outrank parent records; control of delegated NS yields full control of all hosts below that label
+</dns_delegations>
+</special_contexts>
+
+<validation>
+1. Before: record DNS chain, HTTP response (status/body length/fingerprint), and TLS details.
+2. After claim: serve unique content and verify over HTTPS at the target subdomain.
+3. Optional: issue a DV certificate (legal scope) and reference CT entry as durable evidence.
+4. Demonstrate impact chains (CSP/script-src trust, OAuth redirect acceptance, cookie Domain scoping) with minimal PoCs.
+</validation>
+
+<false_positives>
+- “Unknown domain” pages that are not claimable due to enforced TXT/ownership checks.
+- Provider-branded default pages for valid, owned resources (not a takeover) versus “unclaimed resource” states
+- Soft 404s from your own infrastructure or catch-all vhosts
+</false_positives>
+
+<impact>
+- Content injection under trusted subdomain: phishing, malware delivery, brand damage
+- Cookie and CORS pivot: if parent site sets Domain-scoped cookies or allows subdomain origins in CORS/Trusted Types/CSP
+- OAuth/SSO abuse via whitelisted redirect URIs
+- Email delivery manipulation for subdomain (MX/DMARC/SPF interactions in edge cases)
+</impact>
+
+<pro_tips>
+1. Build a pipeline: enumerate (subfinder/amass) → resolve (dnsx) → probe (httpx) → fingerprint (nuclei/custom) → verify claims.
+2. Maintain a current fingerprint corpus; provider messages change frequently—prefer regex families over exact strings.
+3. Prefer minimal PoCs: static “ownership proof” page and, where allowed, DV cert issuance for auditability.
+4. Monitor CT for unexpected certs on your subdomains; alert and investigate.
+5. Eliminate dangling DNS in decommission workflows first; deletion of the app/service must remove or block the DNS target.
+6. For NS delegations, treat any expired nameserver domain as critical; reassign or remove delegation immediately.
+7. Use CAA to limit certificate issuance while you triage; it reduces the blast radius for taken-over hosts.
+</pro_tips>
+
+<remember>Subdomain safety is lifecycle safety: if DNS points at anything, you must own and verify the thing on every provider and product path. Remove or verify—there is no safe middle.</remember>
+</subdomain_takeover_guide>