What is attack surface monitoring?

Attack surface monitoring is the continuous observation of everything internet-facing that carries your name, with alerts when something changes. On your own side that means new subdomains, dangling DNS records, expiring certificates and configuration drift such as a dropped security header or a weakened DMARC policy. On the outside it means signals that someone is preparing to impersonate you: a certificate issued for a lookalike domain, a typosquat registration, or a cloned copy of your website served from another host. It complements a one-time scan, which can only describe the surface at the moment it ran. Most of the external signals come from public records — Certificate Transparency logs and RDAP — so monitoring does not require scanning or touching anyone else's systems.

How do I know if someone cloned my website?

The reliable way is a canary: a small snippet in your page that references a resource on a monitoring service. On your real domain the request is unremarkable, but when a phishing kit copies your HTML and serves it from a different host, that request arrives carrying the clone's hostname, and you get an alert the first time anyone loads the copy — often before the phishing emails go out. Searching for your own text or logo file names, and watching Certificate Transparency for lookalike names, are useful secondary signals but only catch clones that were also given a similar domain. MySecScan's Domain Monitor combines the canary with daily CT-log and typosquat sweeps for a verified domain, free during the beta.

How often should attack surface monitoring run?

The external signals should be checked at least daily: new certificates appear in CT logs within minutes of issuance and phishing campaigns typically launch within days of a domain being registered, so a weekly check would miss the window in which a takedown prevents harm. Clone detection via a canary is event-driven and effectively real-time. Your own configuration drift and certificate expiry can be checked daily or weekly with expiry alerts at 30, 14 and 7 days. The more important cadence is the human one — alerts must reach someone who will act within a business day, or the monitoring is producing history rather than protection.

Attack Surface Monitoring — What to Watch Continuously

Attack surface monitoring is the continuous half of attack surface management: watching for what changes — a new subdomain, a certificate issued for a lookalike name, a typosquat domain registered yesterday, a copy of your site served from someone else's host, a certificate about to expire. A one-time scan is a photograph; monitoring is the alarm that goes off when the picture changes.

What does a one-time scan miss?

Everything that happens after it. The scan tells you your headers were fine on Tuesday. It cannot tell you that on Thursday a contractor pushed a config that dropped HSTS, that a marketing tool created promo.example.com pointing at a SaaS you'll cancel next year, or that somebody in another country registered examp1e.com and requested a certificate for it. The first two are drift on your own surface; the third is a signal that an attack on your customers is being prepared. Monitoring covers both, and the second kind is the one you cannot get any other way.

What should you watch continuously?

Ranked by how early the signal arrives relative to the harm:

Lookalike certificates — before a phishing site can show a padlock it needs a certificate, and every certificate is published in Certificate Transparency logs within minutes. A daily sweep of new certificates whose names resemble your brand is the earliest public warning that exists (how CT works).
Typosquat and lookalike registrations — domains registered with your brand plus a hyphen, a swapped letter or a different TLD. Registration data is queryable through RDAP; the registrar and date tell you how fresh the threat is.
Cloned copies of your site — phishing kits copy the real HTML wholesale. A canary in your page (a snippet that only “reports home” when the HTML is served from a different host) catches the clone the first time a victim or the attacker loads it.
New subdomains and dangling DNS — a CNAME left pointing at a decommissioned SaaS is a subdomain-takeover invitation; a new hostname nobody remembers creating is an unassessed asset.
Certificate expiry — the most boring outage in the industry, still happening weekly. Alert at 30, 14 and 7 days.
Configuration drift — HSTS, CSP, cookie flags, DMARC policy, TLS versions. Re-run the passive checks on a schedule and diff the result.
Exposed files and panels — .git, .env, backups, admin paths that appear after a deploy. See exposed .env and .git files.

How do CT logs and RDAP make this possible without scanning anyone?

Both are public records designed to be read. Certificate Transparency is a requirement for every publicly trusted certificate: the certificate authority must log it, and anyone can search the logs (crt.sh, Cert Spotter). RDAP is the structured successor to WHOIS, served by registries and registrars over HTTPS with a defined JSON format (ICANN). Querying either touches no server of the suspected attacker's and no server of yours — it is the same information a browser or a registrar already publishes. That is why the Domain Monitor runs its lookalike-certificate and typosquat sweeps this way, and why it can be offered without an agent, a port scan or any access to your infrastructure.

The clone signal is different: it comes from your own page. A one-line snippet references a tiny image on the monitoring service; on your real domain nothing interesting happens, but when the same HTML is served from login-example-verify.com, the image request carries that hostname and the clone is recorded. No data about the visitor is kept — only the cloning host and the time.

Common gotcha — alert fatigue: platforms that legitimately serve your HTML under their own hostnames (Shopify storefronts, Vercel and Netlify previews, translation proxies) look exactly like clones to a canary. Whitelist those patterns on day one (*.myshopify.com, *.vercel.app) or you will learn to ignore the alerts, and then miss the real one. The same goes for lookalike-certificate matches on brands that are also common words.

For the site owner and for the developer

For the site owner (plain English)

If a phishing email pretending to be your company reaches your customers, the domain it uses and the fake site it links to almost always existed for days before the first email went out. Attack surface monitoring is how you learn about them during those days instead of from an angry customer. The practical version for a small business: verify your domain with a monitoring service, add one line to your website, and route the alerts to someone who will act on them — a takedown request to the registrar and host, a warning to customers, or simply registering the lookalike yourself.

Verify your domain once and the Domain Monitor watches for cloned sites, lookalike certificates and typosquat registrations — daily sweeps, email alerts, whitelist for your platforms. Free during the beta, up to five domains.

Start monitoring — free →

For the developer / IT (do-it-yourself monitoring)

If you would rather run it yourself, the public sources are enough for a cron job:

# New certificates mentioning your brand in the last day (crt.sh)
curl -s "https://crt.sh/?q=%25example%25&output=json" \
  | jq -r '.[] | select(.entry_timestamp > (now - 86400 | todate)) | .name_value' | sort -u

# Is a lookalike domain registered, and since when? (RDAP bootstrap redirects to the right registry)
curl -sL "https://rdap.org/domain/examp1e.com" | jq '{status, events: [.events[] | {eventAction, eventDate}]}'

# Certificate expiry on your own hosts
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

# Config drift: re-run the passive checks and diff against last month
# https://mysecscan.com/tools/website-security-score → export findings → diff

Generating the lookalike candidate list is the tedious part — TLD swaps, hyphen insertions, homoglyphs (rn for m, 1 for l), common prefixes like login-/secure-. Open-source generators such as dnstwist produce a few hundred per brand; check them against RDAP and CT daily and alert on state changes only, never on the full list.

What do you do when an alert fires?

Lookalike certificate or new registration: capture the evidence (certificate ID, RDAP record, screenshot if a site is up), file an abuse report with the registrar and the hosting provider, and if it's serving a phishing page, report it to Google Safe Browsing and Microsoft SmartScreen so browsers warn visitors.
Cloned site: same takedown route, plus a customer notice if the clone is live and targeting logins. Rotate nothing on your side — the clone doesn't touch your systems — but do check whether the clone proxies your real login (credential harvesting) and add rate limiting there.
Your own drift: treat it as a regression — find the deploy that caused it and fix the pipeline, not just the header.
Keep the timeline. First seen, reported, taken down. Takedown times are the metric that tells you whether monitoring is paying for itself.

Attack Surface Monitoring: What to Watch Continuously (and What a One-Time Scan Misses)