Subdomain Takeover Response Playbook: Reclaiming Dangling DNS and Reviewing Cookie Exposure

A CNAME left pointing at a deleted cloud app or storage endpoint lets anyone who claims that resource name serve content, collect cookies and send phishing from your own domain. Subdomain takeover is one of the most common findings in bug bounty programmes, and the response is rarely just "delete the record": you need to know what was served, which cookies and tokens the subdomain could receive, and why your deprovisioning process left it behind. This playbook template covers response to a reported or detected takeover of a subdomain through dangling CNAME, NS or MX records, using Microsoft, GitHub, MDN and MITRE guidance and the lifecycle in NIST SP 800-61 Rev. 3. It is written for security operations, DNS and web platform owners. Adapt the bracketed text before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [DNS Owner] and [Web Platform Owner], with your own names. "Must" is mandatory; "should" is recommended.
• Decision points are marked D1 to D5. Record each decision, who made it and when.
• For how the attack works and how to prevent it, read the Subdomain Takeover and Dangling DNS Guide. If the attacker changed your registrar or authoritative DNS rather than claiming a dangling resource, use the DNS Hijack Playbook instead.

1. Scope and triggers

1.1 This playbook applies when a hostname under a domain [Organisation] owns resolves to, or delegates to, a resource that [Organisation] no longer controls, whether or not a third party has claimed it yet. MITRE ATT&CK describes subdomain hijacking under T1584.001 Compromise Infrastructure: Domains, where DNS entries point to non-existent or deprovisioned resources.

1.2 Related techniques once a subdomain is held: T1566.002 Spearphishing Link (phishing from a trusted name) and T1539 Steal Web Session Cookie (cookies scoped to the parent domain).

2. Roles and contacts

3. Detection and triage

1. Capture evidence first. Before changing DNS, save the current DNS answers for the name (CNAME chain, NS, MX, TXT), screenshots and HTTP responses of what it serves, and the certificate presented. Record certificate transparency entries for the name. Once you delete the record, the attacker's content is no longer reachable for review.
2. Identify the target resource. Which provider and service does the record point to (for example an Azure App Service, Blob Storage endpoint, Front Door, CDN endpoint, Traffic Manager profile, public IP DNS label, API Management, or a GitHub Pages site)? Microsoft lists these Azure resource types as affected.
3. Find when it went dangling. Use deletion dates from the cloud activity log, DNS change history and the asset inventory. The exposure window starts there, not at the report date.
4. Size the cookie exposure. List cookies set with a Domain attribute of the parent domain. MDN documents that a cookie with Domain=example.com is also sent to its subdomains, while a cookie without Domain is host-only. Any parent-scoped session or authentication cookie could have been received by the taken-over host, and Microsoft notes an attacker can obtain a valid TLS certificate for it.
5. Check trust lists. Search for the hostname in OAuth and SAML redirect URIs, CORS allowed origins, Content Security Policy allowlists, SPF includes, email allowlists, mobile app link files and partner configurations.
6. Check traffic. Look for links to the subdomain in your own emails, pages and apps that would send users or data to it.

D1: Severity. Critical: claimed and serving content, or receiving parent-scoped session cookies, or listed as an OAuth redirect or CORS origin. High: claimed with no evidence of abuse. Medium: dangling but unclaimed. An NS delegation to a zone someone else can create is at least High, because it gives control of every name beneath it.

4. Containment

D2: Delete the record or reclaim the resource? Microsoft's remediation order is to remove CNAME records pointing at resources no longer provisioned, or, if traffic must keep flowing, provision resources with the FQDNs in the dangling CNAMEs. Delete when the name is no longer needed; reclaim when it is linked from places you cannot change quickly.

4.1 Invalidate sessions if parent-scoped authentication cookies were exposed (D1 Critical): force sign-out and rotate session signing keys where the platform allows.

4.2 Remove trust: take the hostname out of OAuth redirect URIs, CORS and CSP lists, and any partner allowlist, at the same time as the DNS change.

5. Eradication

1. Sweep every zone for other dangling names. In Azure, Microsoft's Get-DanglingDnsRecords.ps1 lists CNAMEs pointing to Azure resources in your subscriptions; it needs at least Reader on the subscriptions and read access to Azure Resource Graph. For other providers, resolve each CNAME and check the target exists in an account you own.
2. Request revocation of certificates the attacker obtained for your names from the issuing certificate authority, using its published revocation request process.
3. Request takedown of any cloned or phishing content still hosted under the attacker's resource with the provider's abuse team.
4. Fix the cookie design: move session cookies to host-only scope where possible. The __Host- prefix requires Secure, no Domain attribute and Path=/, which binds the cookie to the exact host. See the Cookie Security Guide.
5. Update application code and content that still references the old subdomain.

D3: Data or account compromise? If logs show users authenticating to, or sending tokens or personal data to, the claimed host during the window, treat it as a data incident and open the notification track. Microsoft's guidance specifically says to check whether secrets such as OAuth credentials or sensitive data were sent to the dangling subdomain.

6. Recovery

1. If the name is still needed, bring it back on a resource you own, with provider domain verification in place and a delete lock on the resource.
2. Where available, use DNS records tied to the resource lifecycle. Microsoft notes Azure DNS alias records become empty rather than dangling when the target resource is deleted (supported for Front Door, Traffic Manager, CDN endpoints and public IPs).
3. Monitor certificate transparency for new certificates on the name for [90] days; see the Certificate Transparency Monitoring Guide for Web Teams.
4. Confirm the name no longer resolves to third-party content from several networks.

D4: Close? The [DNS Owner] confirms the sweep found no further dangling records and the [Web Platform Owner] confirms trust lists are clean.

7. Communication and notification

• Researcher: acknowledge within [2] working days, confirm the fix, and agree disclosure timing; see the Bug Bounty and Vulnerability Disclosure Guide.
• Customers: if phishing ran from the name, publish a short notice naming the subdomain and the dates, and tell users what to do if they entered credentials.
• Regulators: where D3 is yes, [Legal and Privacy] applies the [Regulatory Register], for example GDPR Article 33 (72 hours from awareness).
• Partners: tell partners who allowlisted the name to remove it.

8. Post-incident review

8.1 Within [10] working days, using the Post-Incident Review and Root Cause Analysis Template. D5: decide whether DNS record removal becomes a mandatory step in the resource decommissioning workflow.

8.2 Record: when the resource was deleted, when the record was removed, who found it, and why decommissioning did not remove DNS. Microsoft's last remediation step is exactly this: find out why the record was not removed and fix the process.

Implementation guidance

Prevention that shortens this playbook. Keep a service catalogue of every FQDN with its owner and target, add delete locks to resources with custom domains, verify custom domains with each platform that offers it, remove DNS in the same change as the resource, and scan zones on a schedule. Trust lists decay the same way: in the ForcedLeak Salesforce Agentforce case, an expired domain still on a Content Security Policy allowlist was registered by the researcher and became an exfiltration channel. Review allowlisted domains when you review DNS.

Rollout. Phase 1: export every zone, resolve all CNAME, NS and MX targets, and assign owners (two weeks for most organisations). Phase 2: run the provider scripts and an external scanner in report-only mode and fix findings in batches; rollback for a wrongly deleted record is re-adding it from the exported zone file. Phase 3: add a DNS check to the decommissioning pipeline and a weekly scheduled scan. Small organisations with one DNS provider can do Phase 1 by hand in a day; large ones with many zones and registrars should use the Attack Surface Management Guide approach.

Framework mapping.

Metrics. Dangling records found per scan, trending to zero; median days from resource deletion to record removal; percentage of custom domains with platform verification; percentage of session cookies that are host-only; time from report to containment.

Common failure patterns.

• Deleting the record before capturing what the attacker served, leaving no evidence for impact review.
• Fixing the one reported name and never sweeping the other zones.
• Ignoring cookie scope, so sessions exposed during the window stay valid.
• Leaving the hostname in OAuth redirect lists or CSP allowlists after the DNS fix.
• Relying on wildcard records that hide deeper claimable names.
• Decommissioning workflows that delete cloud resources but leave DNS to another team.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• Microsoft: Prevent dangling DNS entries and avoid subdomain takeover
• GitHub: Verifying your custom domain for GitHub Pages
• MDN: Set-Cookie header
• MITRE ATT&CK: Compromise Infrastructure: Domains
• MITRE ATT&CK: Steal Web Session Cookie
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations

Related NHI Mgmt Group resources: Subdomain Takeover and Dangling DNS Guide · DNS Hijack Playbook · DNS Security Guide · Cookie Security Guide · Attack Surface Management Guide