Subdomain Takeover in a (charmy) Box

This is not the first time we write about subdomain takeover and probably it won’t be the last. Every time we find a subdomain takeover we ask ourselves “How big is this (assets management) problem?”. This time we decided to answer our own question but we got caught in the rabbit hole where we met and BoxyCharm by IPSY.

What is Subdomain takeover?

As a rule of thumbs, a subdomain takeover occurs when an attacker controls the content served by a domain or subdomain he does not own. An attacker can achieve this by exploiting dangling DNS records, for instance, a DNS record pointing to an auctionable domain the attacker can buy.

Most of the black magic around subdomain takeover happens at the DNS level. One type of record in the DNS protocol is the CNAME record. The CNAME record is a map between an alias domain e.g. and a canonical domain e.g., usually owned by two different entities. In this scenario, when entering in a web browser it will in fact show the content returned by the server points to. If is for sale, then anyone can buy and configure it to point to its own server, hence controlling the content shown by

Sometimes the “delegation chain” is a bit more complex long. Not so rare points to, which in turns points to and so on, until at some point one domain points to


A subdomain takeover often leads to malicious content being served by a trustworthy domain. The malicious content can be a very convincing web page/site aimed to steal credentials such as auth cookies, login credentials, or credit card information but it can also be a “simple” JavaScrip script loaded by major websites.

The rabbit hole

To find the answer to our initial question “How big is the Subdomain Takeover problem?”, we took Fortune 500 companies’ digital assets as a sample. We were expecting to see many domains/subdomains pointing to popular cloud providers services but at some point stood out. “is a supercloud on which you can deploy apps, containers, or K8s workloads in the best locations for you, your users and your budget” (source).

The applications will be hosted on Edge Network on a server whose IP address is dictated by the server’s geolocation chosen by the user when first creating a project. If the user selects the location “London”, the range of IPs that compose the servers hosting the user’s application will differ from the user selecting the location “Los Angeles”.


Deployed applications can optionally be accessed through users-owned custom domains/subdomains. The configuration is done on the dashboard: the user provides the domain/subdomain name and it is asked to create a CNAME record pointing to an address computed from the given domain/subdomain suffixed with “”. For it would be To complete the process the user has to click the verify button. This verification ensures it is possible to reach Edge Network through the provided domain/subdomain.

Some cloud provider services with a similar approach are prone to subdomain takeover. Amazon S3 Cloud Object Storage is a well-known one. Maybe services were also prone to subdomain takeover. Of course we had to dig deeper.

In our quest to find the answer we stumble upon the subdomain connected to Edge Network via a CNAME record pointing to It caught our attention because it did not obey the pattern we’ve described earlier: was supposed to point to The domain was properly configured, thus the subdomain was ultimately pointing to the IP address configured inside the Edge Network for Lucky us, at least at the time, IPSY had a well-established vulnerability disclosure policy.


We’ve tried to access using a web browser getting in turn a 409 Conflict error message. This error and the DNS “anti-pattern” brought another question to our minds: could we bypass the custom domain verification and control from within

We created a new project to deploy a basic web application adding as a custom domain to access it. Since was already pointing to edge network the validation succeeded, otherwise we wouldn’t be able to add the required DNS records since we don’t own the domain. Nevertheless, our web application content was not accessible at We had to step back to find out what was missing.

We confirmed our application was running properly and accessible as connecting to one of the IP addresses assigned to our project and sending manual HTTP requests with the Host request header set to Then, we checked again the DNS chain. At this point we noticed none of the IP addresses that was ultimately pointing to matched those assigned to our project. That had to be it!

Now the question was what location was boxycharm at? The DNS CNAME chain included a hint: the “lon” in the last CNAME of the chain. Could this mean the location was London?


We changed our project location to “London” and after DNS propagation, the content was served by the vulnerable subdomain. We had full control over the content served by


Attack Scenario

A bad actor could have used the vulnerable subdomain to host a phishing campaign that would allow him to steal private user information such as credentials or credit card information.

For example, bad actors could have created a clone of the official BoxyCharm online store ( with a login form whose data would be sent to their server. They could have gone even further offering a shopping cart with online payments. All payment attempts would either fail or succeed, but for sure credit card details would end-up on the attacker's controlled server.

Subdomain takeover can also be used to abuse web browser’s Same Origin Policy, allowing authenticated requests (including cookies) to other websites or APIs in the same origin.


Although the BodyCharm subdomain was not pointing to a dangling CNAME record, the way works allowed us to take control over the content being served.

If you are using, be careful when creating CNAME chains: remember to assign all the domains in the chain to your project, otherwise you may fall victim to subdomain takeover.


• 2023-05-24 - Security Advisory was sent to IPSY
• 2023-06-06 - IPSY acknowledged the vulnerability offering a $200 bounty
• 2023-07-03 - We’ve challenged IPSY to donate additional $200 to a charity 
• Never heard back from IPSY

Research by Francisco Santos, intern at Char49 at the time

Share this Post