Cybersecurity is defined by constant change. Whether it’s zero-days that disrupt operations and demand our immediate attention (e.g., tj-actions, XZ utility, and log4j), or the constant stream of updates, patches, and of course, alerts, the cyber landscape is in perpetual motion
As the numbers of disclosed vulnerabilities grow yearly and the likelihood of remediating them all becomes less and less likely, security teams can keep their organizations safe by keeping a close eye on how and when these vulnerabilities become exploitable. Successful security teams understand that something that might be benign or low risk today could suddenly raise in profile tomorrow.
In this blog post, we explore how a shift in conditions can often elevate the risk of threats that may often start off as low or moderate in severity. The specific example we’ll cover in this post is subdomain takeovers: a known issue that may not always appear critical at first glance. Within some specific scenarios though, they could rise into a drastic supply chain threat. By re-evaluating threats through the lens of its potential exploitability, security teams can stay steps ahead of potential blind spots in their defenses.
The Background
A subdomain takeover happens when an attacker gains control of an organization’s improperly configured or unused subdomain. There’s a number of ways this can happen, the simplest of which is when Domain Name System (DNS) records, specifically canonical name (CNAME) records, have been set up to point to a specific subdomain, and either:
- The subdomain expires and is available for registration by an attacker, or
- The attacker sets up virtual hosting for the subdomain before you can.
This scenario is known as “Dangling DNS”, defined by a DNS record that exists so traffic is being directed to a subdomain/resource and is therefore vulnerable to attack. Alongside canonical name (CNAME) records, the same risk is present for other DNS records: NS, MX, A and AAA records.In some instances, Dangling DNS can be the result of SaaS choices and migrations. Many organizations have help desk, eCommerce, careers, or community subdomains with a CNAME pointing to a SaaS provided subdomain. For example, support.YourBiz.com points to YourBiz.zendesk.com, and careers.YourBiz.com points to YourBiz.smartjobboard.com.
If a business stops using a SaaS provider but fails to remove or update the associated CNAME records, or if a service subscription payment lapse, attackers may be able to register the subdomain with that provider, potentially gaining control over it.
Referring to the screenshot above, an attacker can even leverage a free trial of Zendesk to take control of a help desk subdomain. The attack scope is larger still if email forwarding still exists from the support subdomain to the zendesk subdomain. Here’s an interesting real-world bug bounty case that extrapolates on such a possibility.
Dangling DNS From Cloud Providers
Another common example of Dangling DNS involves DNS records pointing to a deprovisioned or deleted cloud resource. Examples of this include object storage, load balancers, content delivery networks (CDN), container registries, databases, or web applications. It’s important to note that this is not an inherent insecurity of the cloud infrastructure itself, but rather a misconfiguration or oversight in DNS management.
Similar to the SaaS examples from above, consider this: If you use cloud object storage to host a static website on a subdomain like Amazing.YourBiz.Com and later delete the storage bucket (intentionally or not) without updating the corresponding DNS records, this opens a door for subdomain takeovers.
An attacker could then register their own S3 bucket with the same subdomain, in an environment they control, and upload content of their own. What was once your legitimate webpage found at Amazing.YourBiz.Com (and later a simple 404 error page) could now display a defaced or malicious version of your content, completely controlled by the attacker.
Given the speed of cloud development, it can be easy to overlook deprovisioned resources. At the time of this writing, a search on Shodan for the AWS specific error message for Dangling DNS due to missing S3 origin bucket returned the following result:
For the specific example of a missing S3 origin bucket, there are hundreds of results spread across the globe, with several enterprise organizations highlighted, including technology vendors. While there are many other scenarios wherein subdomains are vulnerable to takeover, there are also a variety of open-source tools available to hunt for them.
What Might An Attacker Do?
Traditionally, there have been two main options for an attacker to take. They could either produce a defaced message and attack your organization’s reputation and branding, or they could spoof a website that looks legitimate and deliver malware or attempt to steal credentials. We cover domain spoofing in detail here.
In Microsoft’s documentation, they breakdown subdomain takeover risks into the below types:
- Loss of control resulting in negative press
- Cookie harvesting from unsuspecting visitors
- Phishing campaigns leveraging authentic-looking subdomains
- Other classic web attacks: cross-site scripting (XSS), cross-site request forgery (CSRF), CORS bypass, and more.
Notably, supply chain risk is not included as a main risk.
Where is the Supply Chain Risk?
Static websites aren’t the only resources a subdomain might reference from a linked cloud service. It’s in these types of requests where the true supply chain dangers lie. For example, what happens if asset.YourBiz.com is still mapped via Route53 or CloudFront to an S3 bucket that no longer exists, and someone tries the following curl command to access it?
curl -0 https://asset.YourBiz.com/images/my-container-image.tar
Worse, what if outdated public documentation still recommends using that exact curl command, which then unknowingly points users to a resource that could be controlled by an attacker? While this may seem far-fetched, security researchers conducted an in-depth investigation into the nature of these requests and the risks they pose.
In this investigation from October 2024 to January 2025, the researchers sought deleted AWS S3 buckets with existing references pointing to them, specifically seeking buckets that may have been used within pipeline management, application development and deployment. They also limited their focus to buckets previously owned by government organizations, Fortune 500 organizations, technology and cybersecurity companies, as well as major open-source projects. Their starting intentions were simple: Ascertain how many of these deleted buckets existed, what types of artefacts were being requested from them, and in what quantity?
Four months later, they were the owners of approximately 150 S3 buckets and had seen over 8 million requests associated with them, including requests for:
- Container and virtual machine images,
- CloudFormation templates,
- Software updates,
- Pre-compiled unsigned Windows, Linux and macOS binaries,
- And, even SSLVPN server configurations.
The researchers followed a responsible disclosure process and the latent threat has since been removed after the platform provider was notified and took appropriate actions.
However, it should be noted that just because the buckets found by this specific research have been remediated, rapid cloud development means this attack surface remains a pressing concern for organizations leveraging subdomains to surface build artefacts. Should an artefact of theirs be compromised and surfaced to their customers, the reputational damage would be considerable.
As is the nature of supply chain threats, threats cascade down to customers should a major SaaS vendor fall prey to this risk. Further, if an attacker was able to take over a resource that is actively referenced and has live request traffic for these types of artefacts, the supply chain risk to those requesting can be severe and widespread. Similar to the recent tj-actions threat, an attacker could inject malicious artefacts into existing supply chains, poisoning them. The scope for remote code execution (RCE), resource hijacking, persistent backdoors, credential theft, and privilege escalation is matched only by the imagination of an attacker.
The SentinelOne Perspective
SentinelOne recommends the implementation of security across the entire software development life cycle. Supply chain threats have routinely showcased how shift-left security alone can miss these threats that cause damage at runtime. Runtime security is required to protect environments in real time, especially when there is third-party risk introduced.
As part of SentinelOne’s Singularity Platform, we have a large focus on finding and prioritizing exposures for proactive security. For subdomain takeovers specifically, SentinelOne hunts for this exploitable risk and provides evidence-based insight. Within Singularity Cloud Security, findings are presented both in the format of Severe Cloud Misconfigurations (where the risk is limited to deprovisioned cloud resources) as well as Exploit Paths from our Offensive Security Engine. Below are examples of the cloud misconfiguration related policies:
The Offensive Security Engine provides an evidence-based view, identifying the risk through the lens of an attacker’s mindset. An Exploit Path showing is represented in the below screenshot:
Referring to the screenshot above, the evidence presented is first a simple GET HTTP request to the base path followed by the response to the command, namely, the “specified bucket does not exist” error. This is the same error message from which an attacker can fingerprint the risk, get the deleted bucket name, and collect all the subdomain details necessary to perform an account takeover.
Conclusion
Staying vigilant and proactive with your cloud security is a necessity when faced with risks of this severity. Subdomain takeovers being leveraged to stage a supply chain attack is a perfect example of how a minor, overlooked issue can lead to outsized risk. SentinelOne is at hand to help organizations build and run their cloud environments securely.
For more details on how the Offensive Security Engine helps customers with its evidence-based approach to risk prioritization. For manual steps to search for Dangling DNS due to deprovisioned S3 buckets, as well as remediation steps provided in AWS guidelines, refer to our documentation here.
