My First Subdomain Takeover

In 2021, while researching a programme on Bugcrowd, I found a subdomain that still directed visitors towards a website provider but was not configured to serve a site there. I created a project on Tilda, associated that hostname with it, and published a proof-of-concept page through the company's subdomain.

The finding became my first subdomain takeover bounty: $500, with the report classified as P2 and eventually marked Resolved. The company and hostname are anonymised here.

The useful part of the investigation was the sequence of evidence: discover a name, inspect its DNS, investigate a service response, and confirm which account could publish content at that address.

How a subdomain can serve someone else's page

Companies connect subdomains such as campaign.example.com to external services for landing pages, documentation, or support sites. If a site is disconnected but its DNS records remain, visitors may still reach the provider. A takeover becomes possible when another account can claim the abandoned hostname there.

The researcher controls the content served at the hostname without changing the company's DNS. MDN describes this failure. Although often associated with dangling CNAME records, it can also affect A records pointing to a hosting provider, as this investigation illustrates.

Discover names, then check what resolves

I began with subdomain enumeration using subfinder, assetfinder, and findomain. Using several discovery tools gave me a collection of candidate names to investigate. I then used dnsx to validate their DNS resolution.

Discovery and validation answer different questions. A name can appear in historical or indexed data without still resolving. Conversely, a name that resolves may lead to a perfectly normal service. Neither result establishes a vulnerability by itself.

Subfinder collects subdomains from passive sources, while dnsx supports DNS queries and resolution checks. In this workflow, they helped reduce a broad list to addresses whose current configuration I could examine.

I scanned the resulting subdomains with nuclei and subdomain takeover templates. One result indicated a possible unconfigured Tilda service. Nuclei uses templates to match responses against defined conditions. I followed up on the Tilda match by checking whether my account could publish at the affected hostname.

Inspect the DNS answer

I checked the candidate with host. The lookup returned two IPv4 addresses for the subdomain, confirming that the name still resolved.

Combined with the unconfigured-service response, these addresses gave me a candidate to test through Tilda's domain settings.

Where Tilda's domain binding became the security boundary

Tilda's custom-domain guide describes entering a hostname in Site Settings → Domain and pointing its A records to the supplied IP address. That documents the connection workflow, rather than the internal validation used during my 2021 test.

In shared hosting, the destination IP gets a request to the provider's infrastructure. The HTTP Host header then identifies the requested hostname, which the service maps to a customer project. The security-sensitive operation is creating that hostname-to-project binding in the provider's control plane: who is allowed to make their project the destination?

A legacy-style shortcut is to treat “this hostname already resolves to our infrastructure” as sufficient validation. That proves reachability, but carries no evidence tying the requesting account to the domain owner. An abandoned A record satisfies the same check for a new claimant. My test demonstrated that Tilda accepted the association and served my page without a DNS change from me; I did not inspect its implementation or establish why its validation allowed that claim. This is a historical observation, not a claim that the same flow remains exploitable today.

I initially thought I needed to pay to create the account required for the test. I looked for another Tilda takeover report and contacted its researcher on Telegram. They explained that I could use a test account, which let me continue.

Confirm control with a proof of concept

After creating the Tilda site, I configured the target subdomain as its custom domain. I then published a page identifying the takeover and opened the company's hostname in the browser.

The page I controlled appeared through the target subdomain. That established the effect that the scanner result alone could not: another account could supply content at the company's address.

Compare the vulnerable and protected behaviour

Advance through the model below to try a new project association after the original site is disconnected.

The protected version requires independent proof of domain ownership before accepting the new association. It illustrates a defensive boundary, rather than the specific fix applied to this finding.

Explain the impact precisely

The demonstrated access was control of web content at one subdomain. That matters because visitors can recognise the company's domain and assume that its pages are operated by the company.

An attacker could use that position for misleading content, impersonation, or a fraudulent form. Those are potential consequences of the content control, not additional actions needed to demonstrate the finding. The proof of concept identified the takeover directly.

Report the finding and follow the resolution

I wrote a report and submitted it to the Bugcrowd programme. A few days later, I received the $500 bounty. The report summary shows the P2 priority and its resolved status.

The activity history records the reward, a message acknowledging the finding and the need to fix it, and the later transition to Resolved.

Verify ownership before activating a route

A stronger binding flow issues an unpredictable verification token for the exact hostname and requesting tenant, then asks the customer to publish it in a DNS TXT record. The provider verifies the token before activating the route. The abandoned A record cannot satisfy this new challenge: the claimant must control DNS or obtain the domain owner's cooperation. TXT is one way to provide independent proof; merely adding a generic TXT value shared by every customer would not fix the missing account binding.

For a modern multi-tenant service, make verification and activation separate states. Keep unverified hostnames inactive, enforce exclusive bindings across tenants, and require fresh proof for a transfer to another tenant. Check and commit the ownership decision atomically so concurrent claims cannot bypass it. An HTTP verification file served by the very project awaiting approval would be circular: it would let the claimant use the disputed route to authorise that route.

Azure App Service provides a concrete example: its domain verification ID in an asuid.{subdomain} TXT record prevents a different subscription from validating the custom domain unless the DNS token is changed. The protection depends on that record being present; it should be provisioned alongside the application and routing records.

The domain owner's cloud lifecycle needs the same care. Track custom hostnames and their provider resources together in infrastructure as code. During retirement, remove or repoint the DNS record while retaining control of the old resource through the relevant DNS cache expiry window, then release the binding. Monitor for DNS records whose provider resources have been deleted. Microsoft's dangling-DNS guidance covers this lifecycle risk. These are architectural mitigations, rather than a description of the fix applied to this report.

Adapted from my original post on X, published on 6 June 2023, about research carried out in 2021. The screenshots come from that post and have been cropped or anonymised where needed; the interactive examples use fictional data.