Wildcard DNS and the 200-for-Everything WAF

Start by fingerprinting the wildcard itself. Send a request to a random nonexistent name such as zzq7.corp-example.com and record the response status, body length, body hash, title, and headers. That baseline is your filter. For each of the 50 candidates, request the hostname through the same edge address and compare the body hash and length to the baseline. If a candidate returns exactly 1,842 bytes with the same hash and headers, treat it as a wildcard false positive unless another signal contradicts that.

Do not rely on DNS alone: the wildcard resolves everything. Use TLS SNI and certificate inspection. A real host often presents a certificate whose SAN includes that specific name or an application-specific wildcard, while the cheap wildcard endpoint may present a generic edge certificate. Check for unique redirects, Set-Cookie names, security headers, and content types. api.corp-example.com returning 401 JSON is already a strong signal because the wildcard returns HTML 200.

At five requests per second, 50 candidates plus baselines is trivial. Use two rounds: first one request per candidate, then a second request only for ambiguous cases to rule out load-balancer variance. Keep a table of hostname, DNS CNAME, certificate SAN, status, length, body hash, and title. Prioritize confirmed hosts by distinct auth behavior and application content, not by name alone.

Calibrate first. Request 10 random paths on the confirmed host, such as /zzq7a, /zzq7b, and so on, and record the distribution of body lengths, body hashes, titles, content types, and response times. If all missing paths return the same 1,842-byte shell, use a filter on that exact size and hash. If the WAF reflects the requested path, lengths will vary, so compare normalized bodies and look for app-specific strings rather than relying on status codes.

Use at least three criteria: body similarity to the calibrated 404 shell, presence of application-specific markers such as a login form or API error schema, and response headers or content type. A fourth useful criterion is response time, but it is weaker because of caching and WAF behavior. Run a wordlist at the program limit of five requests per second, not at the tool default of 40 threads. Disable recursion until a directory is confirmed by a distinct body or header. Seed the wordlist with endpoints found in JavaScript: /api/, /graphql, /export, /admin, and versioned API paths. Manually inspect outliers rather than trusting the scanner. If the WAF returns 200 for everything, a hit is a response that differs from the calibrated shell in a stable, reproducible way, confirmed by a second request.

The hostname is inside *.corp-example.com and is not excluded, so the hostname itself is in scope. The fact that it resolves to a private address is a signal of an internal service exposed through DNS, not permission to scan 10.0.0.12 or the surrounding network. Test only through admin.corp-example.com and do not pivot to the IP address, other internal ranges, or adjacent services.

Confirm the host is real and not a wildcard artifact using the same fingerprinting process: certificate SAN, body hash, headers, and a second request. Then perform minimal, non-destructive checks: whether the login page is reachable, whether it exposes a product or version banner, and whether default or weak credentials are in scope under the program rules. Do not brute force. If authentication is required, stop at the login page unless the program explicitly allows credential testing. Document the private-IP resolution and the exposed login page as a potential internal exposure finding. If the program has a rule against testing internal-looking assets, ask the program owner before proceeding. The judgement call is to treat scope as hostname-based and to avoid using the web app as a network pivot.