Assessing the Risk: Sub-Domain Takeover via EC2 IP Takeover

Over the past year, several Software Secured clients have received reports from independent researchers claiming to have discovered previously unknown vulnerabilities in their infrastructure. While these reports were not extortionate in nature, they typically included a technical overview of the identified issue, a request for voluntary compensation if the information proved valuable, and a link to the sender’s consulting services.

A common thread among these reports was the vulnerability in question: (Sub)Domain Takeover via EC2 Instance IP Takeover. This article examines the mechanics behind this vulnerability and evaluates whether it presents a material risk to organizations.

What is a Subdomain Takeover?

Before assessing the reported vulnerability, it's important to understand the broader concept of subdomain takeover.

A subdomain takeover occurs when a subdomain (e.g., subdomain.example.com) points to a third-party service (such as GitHub Pages, Heroku, etc.) that is no longer in use. If the original service has been decommissioned or deleted, an attacker can register a resource on that service and configure it to respond to the orphaned subdomain—effectively taking it over.

‍

This type of vulnerability is a favorite among bug bounty hunters and malicious actors alike due to its ease of discovery and potential for high impact. One notable case was reported to Uber by security researcher Arne Swinnen, who demonstrated the ability to steal session cookies via a subdomain takeover, leading to full account compromise.

Which Services Are Susceptible?

As awareness of subdomain takeovers has increased, many SaaS providers have adopted safeguards to prevent such attacks. However, not all platforms have implemented these protections, leaving gaps that attackers can exploit.

A continuously updated list of known vulnerable services and their associated indicators can be found here:
➡️ Can I Take Over XYZ?

AWS and Subdomain Takeover Risks

Within AWS, S3 and Elastic Beanstalk are commonly cited as potential vectors for subdomain takeovers. However, a less frequently discussed—but theoretically possible—attack involves EC2 instance IP takeover..

This method was outlined in a 2023 Medium post by a researcher known as "Zonduuhackerone." The premise is as follows:

• A company uses an EC2 instance to host a domain or subdomain..
  
  
• The EC2 instance is later decommissioned, but the associated DNS A record remains unchanged.
  
  
• An attacker continuously allocates new EC2 public IP addresses, checking whether any domains or subdomains resolve to them.
  
  
• If a match is found, the attacker temporarily controls the domain or subdomain.
  
  

As of the previously mentioned Medium article,, AWS owned a public IP space of approximately five million addresses. Meaning that the odds of matching a random recycled IP to an existing asset are slim, and AWS further mitigates abuse by rate-limiting IP allocation and banning suspicious accounts.

While this significantly limits the feasibility of a targeted attack, opportunistic actors—particularly bug bounty hunters—continue to test this method at scale.

Should Organizations Be Concerned?

In general, subdomain takeovers are a valid concern and can lead to significant security issues if left unchecked. However, EC2 IP-based takeovers appear to be more opportunistic than targeted. Based on the reports our clients have received, this activity may be better characterized as a form of aggressive marketing by independent researchers.

Reproducing this attack in a responsible manner is also highly impractical for consultancies or red teams. The process would involve the temporary takeover of numerous unrelated IPs and subdomains, which would violate cloud provider policies and unintentionally affect other organizations that are out of scope.

Recommended Actions for Organizations

While the specific risk posed by EC2 instance IP takeover is low, organizations should still maintain rigorous asset hygiene. Key recommendations include:

• Regularly audit DNS records, particularly after decommissioning infrastructure.
  
  
• Remove or update "dangling" subdomains that point to inactive services or IPs.
  
  
• Implement monitoring for unexpected changes in DNS configurations or unresponsive subdomains.
  
  

Furthermore, organizations should establish a clear disclosure path for researchers who identify vulnerabilities. One increasingly adopted standard is the use of a security.txt file, which provides a machine-readable way for researchers to report issues responsibly.

Organizations should take proactive steps to manage and monitor their digital assets—especially domains, subdomains, and any infrastructure that has been decommissioned. Vulnerabilities such as dangling DNS records can be exploited if left unaddressed.

Key recommendations:

• Monitor all assets
  Regularly review DNS records and ensure that domains and subdomains are not pointing to services or IPs that are no longer in use.
  
  
• Treat EC2 IP takeover takeovers with context
  While (Sub)Domain Takeover via EC2 instance IP takeover is technically possible, it’s a low-risk and opportunistic attack. Rather than focusing on this specific method, prioritize overall DNS hygiene and asset lifecycle management.
  
  
• Review unsolicited vulnerability reports carefully
  
  
  
  • Take all reports seriously, but verify them thoroughly.
    
    
  • Some may be well-intentioned; others could be part of self-promotion or based on weak evidence.
    
    
• Establish a clear vulnerability disclosure process
  If you haven’t already:
  
  
  
  • Implement a method for researchers to report security issues.
    
    
  • A good starting point is the use of a security.txt file, a proposed standard for making disclosure contact information accessible.

Without a clear reporting path, valid findings may be overlooked—and potentially exploited by malicious actors.