Seizing subdomains. How I took over Microsoft subdomains and how to perform such attacks

A few years ago, I managed to take over subdomains on Microsoft websites and got access to the mail and files of Outlook and OneDrive users, as well as user profile data on Today, I am going to share with the hacking community the details of that attack and explain how it can be performed now, in 2020.

Takeover via forgotten CNAME records

Modern companies use various cloud services. To simplify the connection, organizations use subdomains of their main domains, while the content is directly serviced by the cloud service. In that situation, a company administrator just adds a DNS record in the CNAME (Canonical Name Record or Alias Record) format with a link to the respective cloud service – and voila!

For instance, to bind GitHub Pages to the domain, the DNS services should be configured as follows:

$ dig +nostats +nocomments +nocmd 1728 IN CNAME 3529 IN A

But what happens if the repository is removed along with the configured binding to the domain The problem is that the DNS record pointing to it will most probably remain intact because such records are added by the administrator, and in most cases, no one controls their timely deletion. This is all about the human factor, welcome to the real world…

As a result, the attacker may create a repository and bind it to! Because the CNAME already points to, the attacker gains control over the content of

The hijacked corporate subdomain can be used to steal session cookies, perform phishing attacks, and bypass CORS and CSP restrictions.

Domain takeover via external links

It is also possible to take over domains that don’t belong to the organization – provided that the organization uses links to them to load external scripts. Imagine, for instance, the following application page: Application


If the subdomain can be taken over using the CNAME scheme, then the attacker would be able to control the content and execute arbitrary code in the context. If the domain has expired or was deleted, the attacker can register it again and gain control over all its subdomains.

Hijacking Outlook and OneDrive sessions

A few years ago, I managed to take over numerous Microsoft subdomains, including those used by This enabled me to intercept user sessions in Outlook and OneDrive.

When you register any Azure service (e.g. a virtual server or a virtual hosting), a name is provided to be subsequently addressed, either directly of via CNAME. For instance, if the application name is XYZ, this application will be available at

Various Azure services use different sets of domains; such domains may slightly differ from each other and have prefixes indicating the region where the resource is located:


Microsoft also uses this mechanism in its applications and shares its namespaces with other users. A quick analysis shows that many subdomains use Azure services and point to the above domain list.

What happens when Microsoft stops using a service and deletes it? You can register an Azure service of the same name using your account. As a result, the existing CNAME record will point to a service under your control.

So, how was the attack implemented practically? First, I retrieved subdomain lists from Certificate Transparency logs. Then I used dictionary attacks to identify subdomains pointing to Azure cloud services. The domain attracted my attention. It pointed (CNAME) to the domain that could not be resolved further (NXDOMAIN).

$ dig
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16373


I created an Ubuntu virtual machine in Azure and registered a service of the same name,, without any problem.

Registering a service with the name ncuprdmigreporting

Registering a service with the name ncuprdmigreporting

The DNS name is now mine!

The DNS name is now mine!

I launched the virtual machine, started nginx on it, opened the address in my browser, and was delighted to see the message: “Welcome to nginx!” The domain was under my control.

The addresses of the Outlook and OneDrive services are and, respectively. The analysis has shown that session cookies created for both services are set for the entire domain, which means that I can intercept user sessions.

Analyzing session cookies on

Analyzing session cookies on

But the session cookies are protected by the Secure flag and can be transmitted only using HTTPS – so, I needed an SSL certificate. Without any problem, I got it with Let’s Encrypt using the same VM. Bingo!

In fact, I was lucky to get a certificate: some Microsoft domains are blacklisted by Let’s Encrypt, and certificate requests issued for them are blocked. Fortunately, wasn’t on the blacklist.

Let's Encrypt blocks issuance of certificates for *

Let’s Encrypt blocks issuance of certificates for *

Now I can control the website content via HTTPS and intercept session cookies. I created a simple page with the PoC and attempted to hijack a session. It was sufficient to insert the session cookies to get into the user’s session – regardless of the browser or IP address. Even if the user changes the password or ends the session, this won’t affect the functionality of the stolen session that remains active and usable!

I repeated this trick with and got access to my own account data. In addition, while reviewing the web server’s logs, I noticed plenty of Xbox consoles addressing my server; a malefactor could try to make them parts of a botnet.

Microsoft could fix this problem, for instance, by prohibiting the creation of arbitrary names on Azure. Instead, the cloud service could generate either the entire names or their postfixes. I reported the problem to Microsoft under the Bug Bounty Program and received the reward.


  • July 14, 2017: the vulnerability reported to Microsoft
  • July 20, 2017: Microsoft confirmed the report
  • December 12, 2017: the problem has been fixed
  • October 28, 2018: the bounty has been paid

Present time: taking over subdomains in 2020

Over two years have passed since that story. Let’s see how vulnerable domains can be identified and seized in 2020.

You can search for domains either actively or covertly. In the latter case, use data available on public services, including:

  • Google dorks;
  • SSL certificate transparency logs;
  • web scanners (e.g. Shodan and Censys);
  • DNS research tools (e.g. DNSdumpster and SecurityTrails); and
  • other open data (e.g. Rapid7 DNS archives).

Active search techniques include:

  • brute-force attacks that may be pretty efficient provided that you use right wordlists; and
  • AXFR attacks against DNS servers with unsafe configurations.

Covert intelligence collection

There are plenty of tools you can use for quiet information collection, including search engines, web scanner APIs, and other services.


Amass is a project of the OWASP Foundation; the tool effectively collects information on subdomains. To use it, type something like:

amass enum -passive -d

Rapid7 DNS

The Rapid7 Forward DNS (FDNS) dataset contains responses to DNS requests for all forward DNS names known by Rapid7’s Project Sonar. In other words, this is an archive of DNS records.

You may download and filter the records manually, but the archive size exceeds 300 GB; so, I suggest using the Amazon Athena cloud service. It allows to make SQL requests to the Rapid7 repository stored on Amazon S3.

Create a new crawler in AWS Glue. Specify the Rapid7 S3 storage as the source.


The rest of the settings can be left in their default state.

Save the settings and launch the crawler manually. Now you can search the data using SQL requests.

FROM date_202002
WHERE name LIKE ''

You may also search only for certain CNAME records.

FROM date_202002
WHERE type = 'cname'
AND value LIKE '';

It might be a good idea to use archive data over the last few months by connecting to older databases – because your primary goal are domains that are not in use anymore.


For brute-force attacks, I recommend the following wordlists: commonspeak2, sublazerwlst, and all.txt by jhaddix.

You can use massdns for quick scanning. Be careful with the interpretation of results, especially if you are looking for forgotten CNAME records. Use reliable public DNS services that don’t modify requests (e.g. Google and CloudFlare) as resolvers for massdns.

## Generating a dictionary for brute-forcing on the basis of commonspeak2:
cat commonspeak2.txt | awk '{print $1""}' > subdomains.txt

## Scanning with massdns
massdns -s 15000 -o J -r resolvers.txt company_commonspeak2.txt > subdomains_massdns.txt


How to expand the list of domain names? Of course, by permuting the existing names! For that purpose, use the AltDNS utility. Use the list of known domains as input:

## Generating permutations
altdns -i subdomains_ok.txt -o subdomains_altdns.txt -w words.txt

## Scanning with massdns
massdns -s 15000 -o J -r resolvers.txt subdomains_altdns.txt > subdomains_altdns_massdns.txt

Searching for forgotten records

Now that you have the subdomain lists, it is time to search for records remaining from deleted services. Some services (e.g. GitHub Pages) return the 404 error when you address them.

Others have a CNAME type but don’t have an IP address (NXDOMAIN). You can find such services either by reviewing amass logs or using the Python function shown below.

import dns.resolver

def lookup(domain):
  result = []
    myresolver = dns.resolver.Resolver()
    myresolver.nameservers = ['','']

    # Recursive CNAME lookup
  for rdata in myresolver.query(domain, 'CNAME'):
      if hasattr(rdata, 'target'):
        result += lookup(str(

  except dns.resolver.NoAnswer:
  # Getting the A record for the last CNAME
      for rdata in myresolver.query(domain, 'A'):
    except dns.resolver.NoAnswer:
      return result

  except dns.resolver.NXDOMAIN:
    return result


  return result

More than 30 vulnerable services can be taken over via forgotten CNAME records. Their brief descriptions can be found in the document entitled “Can I take over XYZ?.”


Experience shows that many organizations underestimate the danger of such attacks. Clients using cloud services – from small startups to well-known banks and major manufacturers – might be vulnerable to them. During the preparation of this article, it became clear that the problem still remains actual for Azure: the recent story with hacked Microsoft subdomains confirms this.

One Response to “Seizing subdomains. How I took over Microsoft subdomains and how to perform such attacks”

  1. mrGrateful1337

    Had to comment, even when I’m not used to do it, but this (content) right here is extremely valuable.

    I respect this work and I am grateful for such amount of knowledge shared here.

    Thank you, Alexander. You made literally my day, because I’ve been all day playing around with this new knowledge I obtained, ideas are just going and going since I started reading the post.

    You’re not playing around when you guys in hackmag said HIGH-QUALITY, damn!

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>