DNS / email · Check
Sensitive-looking subdomain discovered via Certificate Transparency logs
Every public TLS certificate is logged to public Certificate Transparency (CT) logs. We searched the CT logs for your apex domain and found one or more hostnames with `admin`, `internal`, `staging`, `dev`, `jenkins`, `vpn`, or similar labels that did not surface in our standard subdomain probe. Those are the exact hostnames attackers scan for first.
Why it matters
Treat this as a discovery aid, not a vulnerability: verify each hostname is intentional, harden anything still public (VPN, allowlists, basic auth), and revoke/cancel unused certificates so they stop appearing as targets.
Real-world risk
Public Certificate Transparency logs are the first place attackers look to enumerate your infrastructure. Sensitive-looking hostnames there (admin, dev, jenkins, vpn, internal, etc.) often run less-hardened stacks than production.
Fix steps (in order)
- Review each hostname listed: confirm it's intentional and currently in use.
- For any non-production hostname that needs to stay reachable, restrict access (VPN, IP allowlists, or basic auth) and apply production-grade TLS, patching, and auth.
- For decommissioned hostnames, revoke or let the certificate expire and remove the DNS record so the name stops appearing in new CT entries.
- Subscribe to CT log alerts for your domains (crt.sh has free RSS; commercial monitors exist) so you spot new certs the moment they appear.
Topic explainer
DMARC, SPF, and DKIM explained: the email authentication trio →
A practical guide to email authentication: what SPF, DKIM, and DMARC each do, why all three are needed, and how to roll out a DMARC policy that actually blocks spoofed mail.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (dns_ct_log_sensitive_subdomain) clears once the externally-observable signal is in place.