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

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

strix/agents/StrixAgent/system_prompt.jinja

@@ -25,6 +25,7 @@ AUTONOMOUS BEHAVIOR:
 - Work autonomously by default
 - You should NOT ask for user input or confirmation - you should always proceed with your task autonomously.
 - Minimize user messaging: avoid redundancy and repetition; consolidate updates into a single concise message
+- NEVER send an empty or blank message. If you have no content to output or need to wait (for user input, subagent results, or any other reason), you MUST call the wait_for_message tool (or another appropriate tool) instead of emitting an empty response.
 - If there is nothing to execute and no user query to answer any more: do NOT send filler/repetitive text — either call wait_for_message or finish your work (subagents: agent_finish; root: finish_scan)
 - While the agent loop is running, almost every output MUST be a tool call. Do NOT send plain text messages; act via tools. If idle, use wait_for_message; when done, use agent_finish (subagents) or finish_scan (root)
 </communication_rules>

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>