Establish scheme, host, redirects and request state
Needs: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons
Shell commands
# Baseline
curl -skL -D headers.txt -o body.html http://TARGET:PORT/
curl -sk -o /dev/null -w 'code=%{http_code} bytes=%{size_download} type=%{content_type} redirect=%{redirect_url}\n' http://TARGET:PORT/
# Variant — explicit virtual-host candidate
curl -sk -H 'Host: CANDIDATE.DOMAIN' http://TARGET:PORT/
# Variant — preserve cookies and follow redirects
curl -skL -c cookies.txt -b cookies.txt http://TARGET:PORT/PATH
# Variant — replay through Burp Community
curl -sk -x http://127.0.0.1:8080 http://TARGET:PORT/PATH
Decisive output: record the scheme, hostname/
Hostheader, port, redirects, page title, certificate names, server/framework clues and whether the view is anonymous or authenticated.
Use a separate cookie jar per identity. Do not mix anonymous, ordinary-user and administrator evidence.
Confirm the proxy listener is active on
127.0.0.1:8080. Use-konly for the controlled lab because it disables destination-certificate verification.
Verify → Record final URL, host, status, redirects, cookies and authentication context before comparing payload results.
If it fails → A redirect loop or generic default page may indicate a wrong host or missing session rather than a nonexistent application. More detail ↓
Explanation & examples
Establish scheme, host, redirects and request state
- USE WHEN
- An HTTP endpoint, redirect or hostname-dependent response
- STARTING ACCESS
- A reachable HTTP application and recorded anonymous or authenticated request state
- RESULT
- A reproducible application identity and baseline request
Recognize the clue
Request the assigned HTTP endpoint without following redirects blindly; inspect location, cookies and alternate scheme/hostname behavior.
curl -skD headers.txt -o body.html http://TARGET:PORT/
curl -skI https://TARGET:PORT/
HTTP/1.1 302 Found
Location: https://HOSTNAME/
Set-Cookie: SESSION_COOKIEMeans: The hostname/scheme redirect identifies the application request context to reproduce.
Confirm: Confirm the hostname routes to the assigned address and preserve its TLS/Host/session state.
- After validation
- The correct named request reaches a distinct application: map its functions.
- Ruled out in this context
- The candidate name produces only the default missing-host response: discard that virtual-host inference.
- Still inconclusive
- Redirect loops can mean missing cookies/host routing; repair the normal request before testing vulnerabilities.
Troubleshooting: A redirect loop or generic default page may indicate a wrong host or missing session rather than a nonexistent application.
Decisive output: record the scheme, hostname/
Hostheader, port, redirects, page title, certificate names, server/framework clues and whether the view is anonymous or authenticated.
Variant — explicit virtual-host candidate
Compare it with a random hostname. A different status alone is weak evidence; compare body, length, title and redirects.
Variant — preserve cookies and follow redirects
Use a separate cookie jar per identity. Do not mix anonymous, ordinary-user and administrator evidence.
Variant — replay through Burp Community
Confirm the proxy listener is active on 127.0.0.1:8080. Use -k only for the controlled lab because it disables destination-certificate verification.
Why it works
TLS SNI, Host, redirects and cookies can select different applications. A response from the IP URL does not describe every hostname served by that listener.
Worked example · hypothetical
Observation: the IP URL redirects to a hostname. Test: send the correct Host/SNI while routing to the assigned address. Illustrative output: a distinct application login appears. Interpretation: map that application separately.
New identity, privilege, host or route? Re-enumerate → All topic tasks →