Certificate Transparency Noise at a Four-Brand Retailer

Start with passive resolution and ownership attribution, not with a scanner. Deduplicate by lowercase hostname and resolved IP, then group by apex domain and certificate SAN. For each hostname, resolve DNS and chase CNAMEs: a CNAME to a cloud CDN, marketing platform, or other known SaaS is evidence that the name is not client-owned infrastructure. Put those in an excluded bucket and record the CNAME as the reason. For names that resolve into the client's approved IP ranges, confirm with reverse DNS, RDAP/WHOIS netblock ownership, and TLS certificate organization fields. Build three buckets: confirmed in-scope and owned, ambiguous/third-party, and dead. Prioritize the confirmed bucket by function: VPN, Jenkins, legacy-api, and admin-labelled hosts first; dev/stg last unless they expose authentication. Send the ambiguous list to the client with the CNAME/IP evidence and request written confirmation. This is defensible because you tied each target to an IP/netblock and a DNS or certificate record rather than treating a hostname string as ownership.

Hypotheses: (a) a decommissioned host still answering with a default vhost; (b) a shared reverse proxy serving multiple brands, where the certificate is simply misconfigured; (c) shadow IT or an acquired brand's host; (d) an edge WAF or CDN returning 403 before the origin. The expired certificate for a different brand is the strongest clue: it suggests shared infrastructure or a stale vhost, not necessarily an exploitable service. The lowest-risk next step is not directory brute force. First check whether the resolved IP belongs to the client's approved ranges; if not, stop and ask. If it does, send one benign request with the correct Host header for each brand and compare body, headers, and certificate. Check CT logs for SANs, passive DNS history, and whether the IP is shared. Only after ownership is confirmed, run a small, rate-limited vhost discovery using known brand names, single-threaded. Document every request and stay under the client's rate limit.

1. 'Is the IP/netblock behind legacy-api owned or managed by you, or by a vendor?' This determines whether you can touch it at all; if vendor-managed, you need that vendor's authorization and may have to exclude it. 2) 'Are dev-, stg-, and Jenkins hosts in scope even though they are not customer-facing?' Scope says all brand domains, but non-production often sits in a different account or is run by engineering; the answer decides whether you spend the limited active-scan window on them. 3) 'Which marketing vendor is in the SPF include, and do you authorize testing of mail authentication?' The ~all record with a vendor include is a spoofing finding, but testing it can affect deliverability, so you need permission before sending any mail. Each question maps to a scope boundary, not curiosity. Until answered, continue only passive work: CT, DNS, certificate parsing, and public repository searches.