This chapter covers subdomain takeover, a critical attack vector in penetration testing where an attacker claims a subdomain that points to a deleted or unclaimed external service. For the PT0-002 exam, this topic falls under Domain 3.0 (Attacks and Exploits), specifically Objective 3.2: Exploit network-based vulnerabilities. While not a high-volume topic, it appears in 2-3 questions typically, often in scenario-based multiple-choice or performance-based simulations. Mastering subdomain takeover requires understanding DNS mechanics, cloud service provisioning, and the specific conditions that enable the attack.
Jump to a section
Imagine a shopping mall where each store is a subdomain. A large brand (the parent domain) leases spaces to various businesses. When a business closes (DNS record pointing to a service that is no longer used), the brand may leave the storefront sign up (DNS CNAME record) but the store itself is empty. A malicious actor can then rent that same space from the mall (claim the abandoned cloud service resource, like an Azure Web App or AWS S3 bucket) and put up their own storefront, tricking customers into thinking it's the original business. The mall management (DNS provider) doesn't verify that the store is actually occupied; they just see the lease (CNAME) and direct traffic accordingly. The attacker can now serve malicious content, steal credentials, or host phishing pages under the legitimate brand's subdomain, all because the DNS record was never cleaned up after the original service was decommissioned.
What is Subdomain Takeover?
Subdomain takeover is an attack where a threat actor gains control over a subdomain of a target domain by registering a cloud service resource (e.g., an Azure Web App, AWS S3 bucket, GitHub Pages site) that the subdomain's DNS record points to, but which has been deleted or is unclaimed. The attacker then hosts malicious content on that resource, effectively hijacking the subdomain. This attack exploits the time gap between when a DNS record is created and when the corresponding cloud resource is claimed, or more commonly, when the cloud resource is decommissioned but the DNS record remains.
Why Does It Exist?
Organizations often use third-party services (CDNs, cloud platforms, SaaS) to host content under their branded subdomains. For example, a company might set up blog.example.com as a CNAME pointing to example.github.io. If the company later decides to move its blog elsewhere and deletes the GitHub Pages site but forgets to remove the DNS CNAME record, the subdomain blog.example.com now points to an unclaimed GitHub Pages resource. An attacker can then create a GitHub Pages site with the same name (example) and claim the subdomain.
How It Works Internally
DNS Resolution: When a user visits sub.example.com, their DNS resolver looks up the record. If it's a CNAME record, the resolver follows the alias to the target domain (e.g., target.cloudservice.com). If that target domain resolves to an IP address that serves content from a cloud service, the user's browser loads that content.
Cloud Service Provisioning: Cloud platforms (AWS, Azure, GitHub, etc.) allow users to create resources with custom domains. For example, an Azure Web App can be configured to accept requests for sub.example.com. The platform validates that the user owns the domain by checking a TXT record or verifying via the DNS provider. However, if the DNS record already points to the platform, anyone can claim the resource as long as they can prove ownership of the cloud service resource name (e.g., the Azure Web App name).
Claiming a Deleted Resource: When a cloud resource is deleted, the platform releases the resource name. If a DNS CNAME still points to that name, an attacker can immediately create a new resource with the same name and configure it to accept requests for the subdomain. The platform will serve the attacker's content for that subdomain.
Key Components and Defaults
DNS Record Types: Subdomain takeover typically involves CNAME records, but NS records (delegated subdomains) can also be hijacked if the name servers are deleted.
Common Vulnerable Services: AWS S3, AWS CloudFront, Azure Web Apps, Azure Traffic Manager, GitHub Pages, Heroku, Shopify, and many others.
Detection Tools: subjack, tko-subs, nuclei, dig, nslookup. Common command: subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt
Verification Commands: dig CNAME sub.example.com shows the target. curl -I https://sub.example.com often returns a 404 or 400 error if unclaimed, or a specific cloud provider error page (e.g., "NoSuchBucket", "404 - Site Not Found").
Step-by-Step Attack Mechanism
Enumerate Subdomains: Use tools like Sublist3r, Amass, or Subfinder to discover subdomains of the target domain.
Check for Vulnerable Records: For each subdomain, perform a DNS lookup to see if it points to an external service. Common patterns: CNAME to *.cloudfront.net, *.azurewebsites.net, *.s3.amazonaws.com, *.github.io.
Verify Unclaimed Resource: Send an HTTP request to the subdomain. If the response is a 404, 400, or a specific error page (e.g., "The specified bucket does not exist"), the resource is likely unclaimed and vulnerable.
Claim the Resource: Register the same resource name on the corresponding cloud platform. For example, if sub.example.com CNAMEs to myapp.azurewebsites.net, create an Azure Web App named myapp. Configure the custom domain to accept requests for sub.example.com (requires verifying domain ownership via TXT record, but if the DNS record already points to Azure, the verification may be bypassed or simplified).
Host Malicious Content: Upload a phishing page, a script, or a redirect to your malicious server.
Interaction with Related Technologies
CDN Services: CloudFront distributions can be hijacked similarly. If a CNAME points to d123.cloudfront.net and the distribution is deleted, an attacker can create a new distribution with the same CNAME.
Email Services: Subdomain takeover can also affect email security. For example, if mail.example.com points to a third-party email service that is decommissioned, an attacker could set up a mail server to intercept or spoof emails.
SSL/TLS: If the attacker can obtain an SSL certificate for the subdomain (via Let's Encrypt or other providers), they can serve HTTPS content, making the attack more convincing.
Mitigation
Regularly audit DNS records and remove outdated entries.
Use non-routable CNAME records or placeholder resources to prevent claiming.
Monitor for error responses indicating unclaimed resources.
Implement DNS record expiration policies.
Exam Relevance
PT0-002 tests your ability to identify subdomain takeover vulnerabilities in a given scenario. You may be asked to select the appropriate tool to detect it, interpret DNS records, or recommend remediation. The exam often presents a scenario where a company decommissioned a service but left DNS records, and asks what an attacker can do. Common wrong answers include "DNS poisoning" or "phishing" without the specific subdomain takeover mechanism.
Subdomain Enumeration
Use tools like Sublist3r, Amass, or Subfinder to gather a list of subdomains for the target domain. These tools query public sources (certificate transparency logs, search engines, DNS brute-forcing) to find subdomains. The output is a text file of potential subdomains. For example: `sublist3r -d example.com -o subdomains.txt`. This step is critical because you need a comprehensive list to check each one for vulnerable DNS records.
DNS Record Inspection
For each subdomain, perform a DNS lookup to identify CNAME or NS records. Use `dig CNAME sub.example.com` or `nslookup -type=CNAME sub.example.com`. Look for records pointing to external services like `*.azurewebsites.net`, `*.s3.amazonaws.com`, `*.cloudfront.net`, `*.github.io`, etc. These are potential takeover targets. Also check NS records for delegated subdomains. Record the target hostname for each vulnerable subdomain.
Vulnerability Verification
Send an HTTP request to the subdomain to see if the resource is unclaimed. Use `curl -I https://sub.example.com` or a browser. Look for specific error messages: AWS S3 returns `NoSuchBucket`, Azure returns `404 - Site Not Found`, GitHub Pages returns a 404 page with "There isn't a GitHub Pages site here." If you get a 200 OK, the resource is claimed. Automated tools like `subjack` perform this check by sending requests and matching responses against known fingerprints.
Resource Claiming
Register the same resource name on the corresponding cloud platform. For example, if the CNAME points to `myapp.azurewebsites.net`, go to the Azure portal and create a Web App named `myapp`. For AWS S3, create a bucket with the exact name (e.g., `myapp.s3.amazonaws.com`). Some platforms require domain ownership verification via a TXT record; however, if the DNS record already exists, you can often bypass this by using the same verification method the original owner used, or by exploiting the fact that the platform may not re-verify if the CNAME is already pointing to it.
Malicious Content Deployment
Once you control the cloud resource, configure it to serve your content. For a phishing attack, upload a replica of the login page of the target organization. For a redirect, set up a 301 redirect to your malicious server. Ensure SSL/TLS is configured (many platforms offer free certificates) to make the site appear legitimate. Test that `https://sub.example.com` now serves your content. This completes the takeover, and any traffic to that subdomain will be under your control.
Enterprise Scenario 1: Azure Web App Takeover
A large enterprise, Contoso, used Azure Web Apps to host its blog at blog.contoso.com. The Web App was named contoso-blog and the DNS CNAME pointed to contoso-blog.azurewebsites.net. After migrating to a new CMS, the IT team deleted the Azure Web App but forgot to remove the DNS record. An attacker enumerated subdomains, found the CNAME, verified the 404 error, and created a new Web App named contoso-blog in their own Azure subscription. They configured the custom domain blog.contoso.com (Azure requires a TXT record for verification, but the attacker used a separate verification method by exploiting the fact that the CNAME already existed, or they simply created the Web App and waited for Azure to automatically issue a certificate). The attacker then hosted a phishing page mimicking the company's login portal. Employees visiting blog.contoso.com were prompted to enter their credentials, which the attacker captured.
Enterprise Scenario 2: AWS S3 Bucket Takeover
A media company, MediaCorp, used an S3 bucket named media.mediacorp.com to host static assets. The DNS CNAME pointed to media.mediacorp.com.s3.amazonaws.com. When the company switched to a CDN, they deleted the bucket but left the DNS record. An attacker found the subdomain, verified the NoSuchBucket error, and created a bucket with the same name in their own AWS account. They uploaded malicious JavaScript that could steal session cookies from the main site. Since the subdomain was used for assets, browsers would load the attacker's script, leading to widespread data theft.
Performance and Scale
Subdomain takeover is particularly dangerous for large organizations with hundreds of subdomains. Manual auditing is impractical; automated scanning tools like subjack can check thousands of subdomains per minute. The attack is low-cost for the attacker (just the cost of the cloud resource, often free tier) and high-impact because the subdomain carries the trust of the parent domain.
Misconfiguration Consequences
Common misconfigurations include: (1) Not removing DNS records after decommissioning services, (2) Using wildcard CNAME records that point to external services, (3) Failing to monitor for error responses from cloud services. A single missed record can lead to a full compromise of the subdomain's trust.
PT0-002 Objective 3.2: Exploit Network-Based Vulnerabilities
Subdomain takeover is specifically tested as a network-based vulnerability because it exploits DNS resolution and cloud service provisioning. The exam expects you to:
Identify the conditions that make a subdomain vulnerable (DNS record pointing to a deleted/unclaimed external service).
Select the correct tool for detection (e.g., subjack, tko-subs, nuclei).
Interpret DNS records (CNAME, NS) and HTTP responses (404, 400, specific error messages).
Recommend remediation (remove outdated DNS records, use non-routable CNAMEs, monitor for error responses).
Common Wrong Answers
DNS Poisoning: Candidates often confuse subdomain takeover with DNS cache poisoning. DNS poisoning corrupts the resolver's cache with false records, while subdomain takeover exploits legitimate DNS records pointing to unclaimed resources. The key difference: in takeover, the DNS record is valid but the target resource is gone.
Phishing: While subdomain takeover enables phishing, the question may ask for the *vulnerability* itself. The correct answer is "subdomain takeover" not "phishing." Phishing is the outcome, not the vulnerability.
Man-in-the-Middle (MITM): MITM requires intercepting traffic; subdomain takeover is about controlling the endpoint. If the exam asks "What attack allows an attacker to host malicious content under a legitimate subdomain?" the answer is subdomain takeover, not MITM.
DNS Zone Transfer: Zone transfer is a different vulnerability where an attacker obtains a copy of the DNS zone. It does not directly enable subdomain takeover.
Exam-Verbatim Values
Common CNAME targets: *.azurewebsites.net, *.s3.amazonaws.com, *.cloudfront.net, *.github.io.
HTTP error codes: 404 (Not Found), 400 (Bad Request), or specific messages like "NoSuchBucket" (AWS), "404 Site Not Found" (Azure), "There isn't a GitHub Pages site here."
Detection tools: subjack, tko-subs, nuclei with takeover templates.
Remediation: "Remove or update DNS records" is the primary fix.
Edge Cases
NS Record Takeover: If a subdomain is delegated (NS record pointing to external name servers) and those name servers are deleted, an attacker can register the same name servers and gain control of the entire subdomain zone.
CloudFront: If a CloudFront distribution is deleted but the CNAME remains, an attacker can create a new distribution with the same CNAME.
Email Services: Subdomain takeover can affect SPF, DKIM, and DMARC records if the mail server subdomain is hijacked.
Eliminating Wrong Answers
When faced with a multiple-choice question, look for the answer that involves DNS records pointing to a decommissioned external service. If the scenario mentions a 404 error or a specific cloud provider error, subdomain takeover is the likely answer. Eliminate answers that describe traffic interception (MITM), cache corruption (DNS poisoning), or social engineering (phishing) as the primary vulnerability.
Subdomain takeover occurs when a DNS record (typically CNAME) points to a decommissioned or unclaimed external service, allowing an attacker to claim that service and host malicious content.
Common vulnerable services include AWS S3, Azure Web Apps, GitHub Pages, Heroku, and CloudFront.
Detection tools: subjack, tko-subs, nuclei; verification via dig and curl looking for 404 or specific error messages like 'NoSuchBucket'.
PT0-002 tests this under Objective 3.2 (Exploit Network-Based Vulnerabilities) in scenario-based questions.
The primary remediation is to remove or update outdated DNS records and monitor for error responses from cloud services.
NS record delegation can also be hijacked if the external name servers are deleted.
Subdomain takeover is not the same as DNS poisoning; it does not involve corrupting DNS caches.
Always verify vulnerability by attempting to claim the resource; a 404 error alone may not guarantee claimability.
These come up on the exam all the time. Here's how to tell them apart.
Subdomain Takeover
Exploits existing valid DNS records pointing to unclaimed resources.
Does not modify DNS server data; relies on orphaned records.
Attacker claims the external resource (e.g., S3 bucket, Azure Web App).
Requires enumeration of subdomains and verification of unclaimed services.
Remediation: Remove or update DNS records; monitor for error responses.
DNS Cache Poisoning
Exploits vulnerabilities in DNS resolver software to inject false records.
Corrupts the cache of a DNS resolver with forged responses.
Attacker does not claim resources; they redirect traffic to malicious IPs.
Requires spoofing DNS responses or exploiting resolver bugs.
Remediation: Patch DNS software, enable DNSSEC, use random transaction IDs.
Mistake
Subdomain takeover requires compromising the DNS server.
Correct
No. The DNS server is not compromised. The attacker exploits the fact that a legitimate DNS record points to an unclaimed external resource. The DNS record itself is valid; the issue is that the target resource is no longer controlled by the domain owner.
Mistake
Only CNAME records are vulnerable to takeover.
Correct
While CNAME records are the most common, NS records (delegated subdomains) are also vulnerable. If a subdomain's name servers are deleted, an attacker can register those name servers and control the entire subdomain zone.
Mistake
Subdomain takeover is only possible with cloud services like AWS and Azure.
Correct
Many third-party services are vulnerable, including GitHub Pages, Heroku, Shopify, Zendesk, and even CDN providers like Fastly and Cloudflare (if the service is decommissioned). Any service that allows custom domains and releases resource names upon deletion is a potential target.
Mistake
If the cloud resource returns a 404 error, it is definitely vulnerable to takeover.
Correct
A 404 error indicates the resource does not exist, but it may not always be claimable. Some platforms require domain ownership verification via a TXT record before serving content. However, many platforms allow claiming if the DNS record already points to them, or if the verification can be bypassed. Always attempt to claim to confirm.
Mistake
Subdomain takeover is a passive attack that does not require any action from the attacker.
Correct
It is an active attack. The attacker must enumerate subdomains, verify vulnerability, and then actively claim the resource by creating a new service on the cloud platform. It is not passive like sniffing traffic.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Subdomain takeover is an attack where a penetration tester (or attacker) gains control of a subdomain by claiming an external cloud service resource (like an AWS S3 bucket or Azure Web App) that the subdomain's DNS record points to, but which has been deleted or is unclaimed. The tester then hosts content on that resource, effectively hijacking the subdomain. It's a critical vulnerability because it leverages the trust of the parent domain.
Use tools like `subjack`, `tko-subs`, or `nuclei` with takeover templates. These tools enumerate subdomains, check DNS records (CNAME, NS), and send HTTP requests to see if the target resource returns a 404 or a specific error message (e.g., 'NoSuchBucket' for AWS S3). Manual verification involves using `dig CNAME sub.example.com` and `curl -I https://sub.example.com`.
Subdomain takeover exploits a valid DNS record that points to an unclaimed external resource; the DNS server is not compromised. DNS poisoning corrupts the DNS resolver's cache with forged records, redirecting traffic to malicious IPs. In takeover, the attacker claims the resource; in poisoning, they spoof responses. Both are network attacks but with different mechanisms.
Yes. If a subdomain is delegated (NS record pointing to external name servers) and those name servers are deleted, an attacker can register the same name servers and gain control of the entire subdomain. This is less common but more impactful because the attacker can create any records for that subdomain.
Popular tools include `subjack` (Go-based, fast), `tko-subs` (Python, supports multiple services), `nuclei` (with takeover templates), and `SubOver` (Python). For DNS enumeration, `Sublist3r`, `Amass`, and `Subfinder` are used. Manual tools: `dig`, `nslookup`, `curl`.
Regularly audit DNS records and remove any that point to decommissioned services. Use non-routable CNAME records or placeholder resources to prevent claiming. Monitor for error responses from cloud services (e.g., 404, NoSuchBucket) and set up alerts. Implement a DNS record lifecycle management policy.
Yes, it is common because many organizations forget to clean up DNS records after migrating or decommissioning services. Automated scanning tools make it easy for attackers to find vulnerable subdomains at scale. High-profile takeovers have occurred against companies like Shopify, Uber, and the US Department of Defense.
You've just covered Subdomain Takeover in Pentesting — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?