Certificate Transparency, a Dangling CNAME, and an Employee's GitHub
You are in the recon phase of a 10-day external test against a national retailer. Scope: example.com and *.example.com only. Explicitly out of scope: third parties, store POS networks, and social engineering. The ROE restricts you to passive sources for the first 48 hours. From certificate transparency logs you pull 214 subdomains. One of them, dev-api.example.com, is a CNAME to an unclaimed application name on a PaaS hosting provider; requesting it returns the provider's "no such app" page. Separately, an employee's public GitHub repo contains a deploy script with internal hostnames (jira.corp.example.com, db-01.corp.example.com) and a base64 blob that decodes to a set of cloud access keys. Dig shows a wildcard A record for *.example.com pointing at a WAF.
1. How do you validate the dangling CNAME without turning a finding into an incident?
Read the worked answer
Confirm the condition entirely from the outside and leave the asset unclaimed.
Reasoning: A dangling CNAME is only a finding while the target stays unclaimed. Registering the app name would (a) take control of a resource at a provider that is not in scope, (b) violate that provider's terms, and (c) convert a passive observation into an active compromise of third-party infrastructure. The evidence you need - that the CNAME points at an unregistered endpoint - is already obtainable without claiming anything.
Action: Capture dig dev-api.example.com output showing the CNAME target, a curl -I showing the provider's 404 body and identifying headers, and WHOIS/DNS confirming the target name is unregistered. Report it as a subdomain-takeover candidate with reproduction steps and the remediation (delete or repoint the record). If the client wants proof of exploitability, get written approval and the provider's tolerance in writing first - or let their DNS team remove the record and treat that as closure.
2. The GitHub repo leaks internal hostnames and what appear to be live cloud access keys. How do you handle it within this scope?
Read the worked answer
Reading public data is not testing the client, but using those keys is.
Reasoning: Pulling an employee's public repo sits outside "testing example.com" - no client system was touched, so no authorization question arises. The keys change that: authenticating to the cloud account with them is an action against a third-party provider and an asset not named in scope, and it also risks triggering the provider's abuse detection on the client. You do not need to authenticate to report it, because a leaked key is a credibility problem regardless of whether it still works.
Action: Verify nothing with the keys. Escalate immediately through the emergency contact, not the day-10 report - this may be an active breach independent of your test, and the client needs to rotate credentials now. If the ROE allows, prove exposure only against example.com-owned endpoints that consume the keys. Avoid naming the employee beyond what remediation requires; the finding is a secrets-management failure, not a personnel matter.
3. The wildcard *.example.com record will distort your later scanning. What is the practical consequence and how do you correct for it?
Read the worked answer
Every nonexistent subdomain resolves, so liveness checks stop meaning anything.
Reasoning: A wildcard A record pointing at a WAF means a scanner resolving random garbage names gets a valid IP and an HTTP response, and will report thousands of "live hosts" that map to one WAF front end. If you carry that into the vulnerability phase, you inflate host counts, attribute WAF error pages to the origin, and bury real findings under fabricated ones. The distortion is systematic, not random, so it will not average out.
Action: Establish a control: resolve several random nonexistent labels (e.g., zzq7.example.com) and fingerprint the response - status code, body hash, TLS certificate, headers. Filter enumerated hosts whose response matches the wildcard fingerprint. For any host that survives, resolve to the actual IP and confirm the service banner differs from the WAF default before including it. Report the wildcard behavior itself as a finding, since it also masks subdomain-takeover detection for the client's own team.