Subdomain takeover happens when DNS still points a subdomain at a third-party service but the underlying resource at that service has been removed, expired, or was never fully claimed. If the provider allows another customer to register that same resource name, an attacker may be able to take it over and host content on a trusted subdomain of the victim organisation.
An example of this is when a company uses cloud-based storage (such as S3 buckets) to host static content for a subdomain, but then deletes the bucket without removing the DNS record. If the bucket name becomes available again, an attacker can create a new bucket with the same name and serve malicious content at that subdomain.
The weakness is usually caused by incomplete decommissioning and often affects SaaS platforms and application front-ends. The DNS record remains in place after the service has been retired, leaving a dangling reference to infrastructure the organisation no longer controls.
A hijacked subdomain can be used for phishing, hosting malware, abusing trust relationships, setting cookies for parts of the parent domain in some scenarios, or undermining email and browser-based trust assumptions. Because the content is served from the organisation’s own namespace, users and internal teams may trust it more implicitly than a lookalike external domain.
This is occasionally identified through external penetration testing where the wider domain and subdomains are in-scope for an assessment. Organisations that rely heavily on third-party or cloud hosting platforms should treat DNS hygiene and service decommissioning as an important part of their attack surface management and vulnerability management processes to reduce their overall risk of subdomain takeover.