Your attack surface: subdomains

1 Introduction

Your company website is example.com, but it is rarely alone. Over the years people add mail., shop., staging., vpn., jenkins. and a test server someone set up for a demo in 2021. Each of these names is a door into your organisation, and the full list of them is your attack surface.

Attackers do not start by attacking your main site, which is usually the best maintained. They start by listing your subdomains, because the forgotten ones are where old software, default passwords and missing patches live. This list is easy to build from public sources, and the Subdomains section of a domain scan shows you the same list an attacker would get, so you can clean it up first.

Lists in the report: hosts serving a website, names that resolve, and every name ever seen

2018

Chrome starts requiring public TLS certificates to be logged in Certificate Transparency

Public

Certificate logs can be searched by anyone, so a hostname on a certificate is not a secret

2 How It Works

DNS does not let anyone ask "give me every name under example.com". So subdomains are found indirectly, from traces they leave in public places. The biggest source is Certificate Transparency (CT): every certificate a public authority issues is written to append-only public logs, with the hostnames it covers. Request a certificate for staging-admin.example.com and that name is published within minutes, for good.

Discover

Collect every name ever seen for the domain, mostly from certificate logs. Old and dead names are included.

Resolve

Ask DNS which of those names still answer today, and with which address (A, AAAA) or alias (CNAME).

Visit

Open the homepage of each name that resolves to a public address, like a browser would, and note what software answers.

What an attacker does with the list

The names alone tell a story: vpn and remote say where employees log in, dev, test and staging point at copies of your application that are often less protected than production, and grafana, gitlab or jenkins name the exact product to look up exploits for. Tools that automate this (subfinder, amass, crt.sh searches) are free and take seconds to run. Nothing in this section is hidden information: it is what anyone can already see.

3 Detailed Analysis

Subdomains on the web

This is the most useful list. Each subdomain that resolves to a public address was visited once: its homepage and its TLS certificate, nothing deeper. Each row shows the HTTP status, the certificate state, a grade, the software detected and any known vulnerabilities (CVEs) for those versions.

Software with a version number

When a server announces nginx 1.18.0 or Apache 2.4.49, the report matches it against the vulnerability database. A host marked known exploited runs a version with a flaw attackers actively use (it is on the CISA KEV list): patch or take it offline first. Even without a CVE, hide version banners (server_tokens off; in nginx, ServerTokens Prod in Apache).

The grade

It counts six HTTP security headers, then drops letters for transport problems: plain HTTP, an expired or mismatched certificate, old TLS 1.0 or 1.1. APIs, error pages and CDN challenges get no letter, the row says why.

The page title is a clue

A title like "Login", "Dashboard", "Welcome to nginx" or "Index of /" on a subdomain you do not recognise is worth a look today. Admin panels and default install pages should never face the internet.

Active subdomains

Every name that still resolves in DNS, with its A (IPv4), AAAA (IPv6) and CNAME values. A name can be active without serving a website: a mail server, a VPN gateway or an internal IP published by mistake all appear here. You can check any line yourself:

dig +short A staging.example.com
dig +short CNAME old-shop.example.com

Private addresses in public DNS

An A record such as 10.0.4.12 or 192.168.1.20 is unreachable from outside, but it still maps your internal network for free. Keep internal names in an internal DNS zone.

CNAMEs to third-party platforms

A CNAME to a hosting, storage or SaaS platform is safe only while the target account exists. If you closed it, the name can be claimed by someone else: see subdomain takeover.

Wildcard DNS

If *.example.com resolves, any name answers, so "active" means little. The report says so with a banner and leaves out names that answer only through the wildcard.

All discovered subdomains

The full history: every name found in certificate logs, marked Active if it resolves today, Inactive if not. A warning sign in the "Suspicious Keyword" column means the name contains a word that usually points at a sensitive service (a VPN, an admin or test environment, for example). Review those first.

Inactive is not the same as gone

A name that no longer resolves is harmless on its own. It matters when DNS still points at it somewhere, or when the server behind it is still running on a raw IP. Names that used to exist are covered in ghost subdomains.

Use it as an inventory

Go through the list with the people who own each service. Every name should have an owner and a reason to exist. The ones nobody claims are the ones to shut down.

Reducing your exposure, in order

Urgent: patch or take offline any host marked known exploited, then any host with critical CVEs. Fix takeover findings the same day.

This week: put admin panels, CI servers, monitoring dashboards and staging behind a VPN or an SSO-protected access proxy (Zero Trust access). They should not show a login page to the whole internet.

This month: decommission what nobody owns. Delete the DNS record and stop the server, in that order, so no name points at a released resource.

Hygiene: hide software versions, add security headers, renew or remove expired certificates, and rescan after each change.

Keeping names out of certificate logs

You cannot remove a name from CT logs once published. You can avoid publishing new ones:

Wildcard certificates: a trade-off

A certificate for *.example.com shows only the wildcard in the logs, not each host. The cost: the same private key is copied to every server using it, so one compromised server exposes the key for all of them. Use wildcards per environment if at all, never one key across the whole company. It also hides nothing from DNS guessing: common names like vpn are found by brute force anyway.

Internal services, internal certificates

A service only staff use does not need a public certificate. A private certificate authority (or your access proxy's certificate) keeps its name out of public logs entirely.

Hiding is not protecting

An obscure name buys time, not safety. A host that is patched and behind authentication is fine even when everyone knows its name.

Map your attack surface on mlab.sh

A domain scan lists the subdomains found in certificate logs, checks which still resolve, visits each public one and matches the software it finds against known vulnerabilities.

Scan your domain on mlab.sh

4 Red Flags

A host marked known exploited

The software it runs has a vulnerability used in real attacks. This is the first thing to fix in the whole report.

Admin, CI or monitoring tools open to the internet

Jenkins, GitLab, Grafana, phpMyAdmin or a router admin page answering publicly invites password guessing and exploit attempts. Put them behind a VPN or SSO.

Staging or test copies of your application

They often run older code, debug modes and real data copied from production. Restrict them to your team or switch them off between uses.

Subdomains nobody in the company recognises

A forgotten agency project or an old campaign site is unpatched by definition. Find the owner or decommission it.

Expired certificates and plain HTTP on live hosts

A sign that nobody maintains the host any more, and an open door for interception. Renew and redirect to HTTPS, or remove the host.

Related Modules

Subdomain takeover and dangling DNS

How a forgotten CNAME or NS record lets anyone serve content on your subdomain, and how to find and clean up dangling DNS before an attacker does.

Certificates, CAA and Certificate Transparency

Who may issue certificates for your domain, what public certificate logs reveal, and why shared certificates matter.

Known vulnerabilities on your website

How a scan matches software versions to CVEs, what CVSS, EPSS and CISA KEV mean, and how to prioritise patching.