Subdomain Takeover Remediation: A Response Guide

How do you confirm one without exploiting it?

Read this section before you touch anything, because the tempting confirmation step is also the one you must not take. The definitive proof that a subdomain is takeable is to take it. On your own domain that is fine and often the fastest remediation. On anybody else's it is the exploitation step, and no amount of good intention converts it into an assessment.

The line, stated plainly

Resolving public DNS records and requesting a public HTTP response are ordinary uses of public infrastructure. Registering the vacated resource is different in kind: you are causing a provider's systems to give you control of a name belonging to somebody else. In the UK the relevant statute is the Computer Misuse Act 1990, whose section 1 offence turns on causing a computer to perform a function with intent to secure access to programs or data, knowing at the time that the access is unauthorised. "I intended to give it back" is not one of the elements. Claiming a hostname you do not own will also, in the ordinary case, breach the hosting provider's own acceptable-use terms, which is a separate problem with the same root cause.

So: on domains you control, confirm however you like, including by claiming the resource. On domains you do not control, confirm read-only and report. If you run scanning for clients, this is the same written-authorisation discipline set out in our MSP playbook, and the scope needs to name the domains explicitly. None of this is legal advice -- it is the set of questions to take to your own adviser before you write a testing procedure.

The read-only confirmation procedure

1. Resolve the whole chain, authoritatively. Query the authoritative nameservers for the hostname and follow every hop: your name may CNAME to a vanity name which CNAMEs to a platform endpoint. Note which hop is the last one that answers, because that is where the defect is. Chained records are where most misdiagnosis happens.
2. Check whether the final target exists at all. A CNAME target that itself returns NXDOMAIN is the cleanest signal available: the name you are delegating trust to is not registered with anybody. For an A or AAAA record there is no target name to check, so look instead at whether anything is listening on the address and whether what answers has any relationship to you -- a reverse DNS lookup and the certificate presented on any TLS port are both informative here.
3. Read the response body and headers. Request the hostname over HTTP and HTTPS and read what comes back. Unclaimed resources on most platforms return a distinctive, provider-worded message to the effect that no such container, application, site or store exists -- and crucially, served from the provider's infrastructure rather than yours. Note the headers too: they usually identify the platform even when the body is generic.
4. Identify the class of service, then look up the pattern. Use the table below to work out what kind of namespace you are dealing with, which determines both severity and the remediation branch. Community fingerprint references such as can-i-take-over-xyz are genuinely useful here, with the caveat the project states itself: it is community-maintained and does not guarantee accuracy. Fingerprints go stale as providers reword error pages and add ownership verification.
5. Check certificate transparency for the name. Search certificate transparency logs for the hostname. Certificates you did not request -- particularly recent ones -- suggest somebody has already completed validation while controlling the name, which changes this from a remediation into an incident.
6. Write the evidence down before you change anything. Timestamp, the DNS answers at each hop, the HTTP status, headers and body, the certificate history, and the class you assigned it. Five minutes of recording now is the difference between a clean ticket and an argument in three weeks about what the state actually was.

On automated detectors

Purpose-built takeover scanners and template-driven scanners work by enumerating names and matching responses against fingerprint sets. They are the right way to cover a large estate and they share two limitations worth knowing. They produce false positives, because a provider error page can mean "not claimed" or simply "misconfigured", and they produce false negatives on anything whose fingerprint has not been contributed yet. Run them only within a scope you are authorised to scan, and treat every hit as a candidate to be confirmed by the procedure above rather than as a finding.

If it is not your domain

Report it and stop. Look for a security.txt file at the domain -- the standard formalised as RFC 9116, which names a contact and often a disclosure policy -- then a published bug bounty or disclosure programme, then a security mailbox, then the ordinary contact route asking to be connected to whoever handles security. Send the hostname, the record chain, the observed response, the timestamp and the class of service -- enough for their engineer to reproduce a read-only check in a minute -- and say explicitly that you have not claimed the resource. Where the affected name belongs to a UK government online service and you cannot find a contact, the NCSC points reporters at the Government Vulnerability Reporting Service. For private organisations there is no equivalent backstop, which is a real limitation: if the holder will not engage, your options are persistence and, where the exposure is being actively abused, the relevant hosting provider's own abuse route.

What if somebody has already taken it over?

Then this is an incident, and the instinct to delete the record and move on is the wrong one. Deleting it is still step one -- it stops further content being served -- but a third party controlled a hostname on your domain for a period, and the work is to establish what that cost you. In rough order:

1. Capture evidence first, in minutes not hours. The DNS answers, the HTTP response and body, screenshots, headers, and the certificate history for the name. Once you change DNS this state is gone and you cannot recover it.
2. Remove the record, then reclaim if you can. Delete or re-point at infrastructure you control. If the identifier is one you could hold yourself, taking it back also prevents the same party simply re-claiming it when they notice.
3. Establish the exposure window. Work backwards: when was the resource deprovisioned, what does certificate transparency show for the name, and what do your own DNS change history and any monitoring records say. The window bounds every other question.
4. Inventory what trusted the hostname. Cookie domain scope on the parent domain is the one that matters most -- anything scoped to the parent was readable and settable by whoever held the subdomain. Then content security policy and CORS allowlists, OAuth and SAML redirect URIs and callback allowlists, API and firewall allowlists, and SPF or other DNS references. Each one is a separate decision about whether to rotate or revoke.
5. Assume sessions and tokens may be affected where scope allowed it. If cookies or tokens could have been read or set at the parent domain, treat rotation and forced re-authentication as the default rather than the escalation.
6. Consider the phishing and brand consequence. Content served on your hostname may have collected credentials or payment details from your own customers or staff. That is a customer-notification and potentially a data-protection question, not only a technical one, and it needs someone who can make that call.
7. Search for siblings before you close it. A takeover almost never arrives alone, because the process defect that produced it produced others. Audit the whole zone, including NS records and the email path, before the ticket is marked done.
8. Write the post-incident note on the process, not the record. The useful output is not "we deleted a CNAME". It is which decommissioning step was missing, who owns DNS changes now, and what would have caught it. Otherwise you will read the same ticket next year with a different hostname.

Where the exposure is significant, treat the timeline as the deliverable. Your regulator, your insurer, your auditor and your largest customer will all ask the same three questions -- when did it start, what was served, and what trusted it -- and the answers are much easier to assemble in the first week than in the third month.

What should monitoring actually watch for?

Subdomain takeover is one of the few external findings where the case for continuous monitoring over periodic auditing is straightforward rather than a sales argument. The record does not change when it becomes exploitable. The change happens in somebody else's namespace, which means an audit tells you about the moment it ran and nothing about the moment that matters. Four signals are worth alerting on:

• A known name whose target stops existing. The core signal: a hostname that resolved to a working target last cycle and now resolves to a target that does not exist, or returns an unclaimed-resource response. This is the transition from stage two to stage three, and it is the alert that matters.
• New names appearing that nobody requested. Subdomain enumeration plus certificate transparency watching tells you when a name you do not recognise starts existing -- which is both how you find records created outside your process and how you notice somebody else obtaining a certificate for your name.
• Changes to the answer, not just failures. A hostname whose target changes without a corresponding change request is worth a look whether or not anything is broken. Silent re-pointing is how an unmanaged record announces that somebody else is managing it.
• The email path, on its own schedule. Recursive SPF expansion, DKIM selector resolution and MX target checks, because none of these show up in a web scan and all of them fail silently.

Whatever you use for this -- an in-house script on a cron, an open-source scanner, or a commercial platform -- the requirement is the same: it has to enumerate names you did not tell it about, resolve each target, and alert on the transition rather than mail you a full list each time. Our buyer's guide has the questions to ask about discovery and change alerting specifically, and applies to us as much as to anyone else.

Published 24 September 2026 · Last updated 24 September 2026 · Written by Nathan Hill-Haimes, co-founder of AMVIA and SurfaceLoop. The legal discussion is oriented to the Computer Misuse Act 1990, section 1 and is not legal advice: have your own testing procedures reviewed by a qualified adviser. The email-path abuse described is sourced to Guardio Labs' February 2024 SubdoMailing research. Fingerprint references are community-maintained and carry their own accuracy disclaimers; provider namespace rules and error responses change, which is why this guide describes patterns by class of service rather than naming vendors as vulnerable. This guide deliberately cites no first-party prevalence statistic for subdomain takeover, because our September 2026 research cohort covered apex domains and IP addresses rather than enumerated subdomains. This guide may be quoted with attribution to SurfaceLoop.