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 Xbox.com. 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 wiki.company.com, the DNS services should be configured as follows:

But what happens if the repository is removed along with the configured binding to the domain wiki.company.com? 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 wiki.company.com! Because the CNAME wiki.company.com already points to company-wiki.github.io, the attacker gains control over the content of wiki.company.com.

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:

  
  
  


  
  ...

If the subdomain 3rdparty.com can be taken over using the CNAME scheme, then the attacker would be able to control the content and execute arbitrary code in the app.company.com context. If the domain 3rdparty.com 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 Live.com. 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 XYZ.azurewebsites.net.

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:

*.cloudapp.net
*.cloudapp.azure.com
*.azurewebsites.net
*.blob.core.windows.net
*.cloudapp.azure.com
*.azure-api.net
*.azurehdinsight.net
*.azureedge.net
*.azurecontainer.io
*.database.windows.net
*.azuredatalakestore.net
*.search.windows.net
*.azurecr.io
*.redis.cache.windows.net
*.azurehdinsight.net
*.servicebus.windows.net
*.visualstudio.com

Microsoft also uses this mechanism in its applications and shares its namespaces with other users. A quick analysis shows that many Microsoft.com 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 migreports.eduadmin.live.com attracted my attention. It pointed (CNAME) to the domain ncuprdmigreporting.cloudapp.net that could not be resolved further (NXDOMAIN).

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

I launched the virtual machine, started nginx on it, opened the address migreports.eduadmin.live.com 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 outlook.live.com and onedrive.live.com, respectively. The analysis has shown that session cookies created for both services are set for the entire live.com domain, which means that I can intercept user sessions.

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, live.com wasn’t on the blacklist.

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 xbox.com 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.

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

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 company.com

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.

s3://rapid7-opendata/fdns/any/v1/date=202002

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.

SELECT *
FROM date_202002
WHERE name LIKE '%.company.com'

You may also search only for certain CNAME records.

SELECT *
FROM date_202002
WHERE type = 'cname'
AND value LIKE '%.github.io';

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.

Brute-forcing

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".company.com"}' > subdomains.txt

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

AltDNS

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 = []
  try:
    myresolver = dns.resolver.Resolver()
    myresolver.nameservers = ['8.8.8.8','8.8.4.4']

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

  except dns.resolver.NoAnswer:
  # Getting the A record for the last CNAME
    try:
      for rdata in myresolver.query(domain, 'A'):
        result.append("[A]"+rdata.address)
    except dns.resolver.NoAnswer:
      result.append("NoAnswer")
      return result

  except dns.resolver.NXDOMAIN:
    result.append("NXDOMAIN")
    return result

  except:
    pass

  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?.”

Conclusions

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.