|
||
|
||
Note: A special thanks to Ed Gibbs, WhoisXML API’s Advanced Threat Researcher & Technical Account Manager, for his help with ideation and compiling the subdomains used in this post.
Subdomains help organizations sort different sections of their websites neatly. Looking at the subdomains of some websites, for example, we usually see subdomains like shop[.]domain[.]com and blog[.]domain[.]com, which help users navigate the sites efficiently.
But we couldn’t help but notice subdomains that might be revealing a lot about a company’s Internet infrastructure and resources—maybe even far too much. We explored a few examples in this post to illustrate why.
We refer to exposed subdomains as those that are returned by a subdomain lookup tool. Whether they resolve to live sites or pages or not, these subdomains can be considered part of the website infrastructure since they are still listed.
To illustrate, we looked up subdomains that contain the name of 23 of the most popular cloud service providers and found more than 96,000 subdomains. The chart below reflects this data.
Website administrators and developers may find it easier to name subdomains after the services they represent. For instance, solarwinds[.]domain[.]com is probably dedicated to the SolarWinds service and staging[.]domain[.]com indicates that it is for testing website changes. With this naming convention, there would be less confusion within the organization.
At the same time, outsiders would find it easier to discover and analyze the solutions and services the organization uses. These outsiders could include competitors. After all, competitor monitoring is part of every business.
Threat actors may also benefit from the exposure of these subdomains. They could use social engineering or brute-force attacks to gain access to them.
More than 10,000 subdomains pertain to the use of Kubernetes, and running them via a website screenshot lookup proved interesting. Most of them resolve to:
Unauthorized and forbidden pages
Login pages
404 pages
Several subdomains resolved to pages that show 401 (unauthorized) and 403 (forbidden) errors, rendering them inaccessible to outsiders.
However, an alarming number of subdomains resolved to login pages, which could be vulnerable to malicious actors. Below is an image of some of the subdomain screenshots.
Hundreds of subdomains also resolve to 404 pages, which could make them prime targets for subdomain takeover.
One subdomain that stood out is kubernetes[.]arankieskamp[.]com, which resolves to a page that only shows the IP address 62[.]210[.]180[.]72 as shown below. The IP address is tagged “malicious” on VirusTotal.
A reverse IP lookup on 62[.]210[.]180[.]72 revealed three connected domains and subdomains:
We found a similar page resolution for the subdomains kubernetes[.]a1z[.]us and mail[.]kubernetes[.]a1z[.]us, but this time a name server (NS) is shown. The screenshot result of the subdomain is below.
A reverse NS lookup on ns3[.]byzland[.]com returned 10 related domains, but a1z[.]us is not among them. The image below shows the domains using ns3[.]byzland[.]com as NS.
Lastly, some subdomains resolve to index pages, such as kubernetes[.]bnedibles[.]in, www[.]kubernetes[.]dbelninodev[.]com, www[.]kubernetes[.]eskygroup[.]com, and kubernetes[.]cerebra[.]tech. The latter even shows the cluster and build details as shown by the screenshot below.
The subdomain mblkubernetes[.]manuia[.]pro also exposes the Kubernetes pod and node:
The screenshots of other subdomain groups are similar to what we found for the Kubernetes subdomains. Most resolve to 401 and 403 pages, but some also led to 404 and actual login pages, which threat actors could exploit.
While helpful in organizing websites, subdomains may also reveal too much about a company’s infrastructure. Organizations may need to change their naming system, at least for crucial solutions and systems. Furthermore, some may need to learn how to hide critical subdomains from outsiders.
Security investigators and researchers can contact us to learn more about the subdomains, screenshots, and other artifacts mentioned in this post.
Sponsored byDNIB.com
Sponsored byRadix
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byCSC
Sponsored byVerisign
Sponsored byIPv4.Global
A World-Renowned Source for Internet Developments. Serving Since 2002.
I think we need to reiterate a piece of advice about host naming conventions from decades ago: pick a random topic (eg. gemstones) and name hosts using terms from that topic. That way when the machine gets repurposed or moved the hostname won’t be obsolete/misleading. The same would apply here, pick arbitrary terms to use for subdomains rather than anything descriptive. If all your AWS servers are under gemstone.domain.com and all the Kubernetes stuff under rhine.domain.com, your people will probably remember the meaning easily but it doesn’t give anyone outside the organization any clue.
Just remember that it won’t take any clues from the domain name to figure out what’s in it. Seeing that all the addresses under a given subdomain are AWS addresses tells the attacker what they’re dealing with regardless of how obfuscated the subdomain and host names are. I’d be much more worried about those login pages and the like open to the public (I prefer to deploy cloud servers inside a virtual network and use gateways and VPNs to grant access so I never expose anything on the servers I didn’t intend to expose).
Jonathan thank you for highlighting subdomains. Clearly there can be hundreds, thousands or tens of thousands of subdomains of a common singlular domain name.
All too often, rather than collapse the subdomains to the single, actionable root domain name and increment a count by 1, companies that seek to get free flowing whois data that had been hobbled by the consequences of GDPR enforcement are talking to lawmakers and regulators and tricking them by painting a false picture of abuse statistics by incrementing the count by tens of thousands of subdomains in threat reports.
A registry or registrar can only take action on a single domain name, and in fact subdomain use actually is often a place that badfolk hide their tracks - setting up “bad stuff” subdomains amidst a number of fellow legitimate tenants - to where taking down the root domain name is entirely inappropriate.
While it is unlikely that people will stop such irresponsible manipulative cognitive distortion to enlist sentiment with policy makers or regulators unfamiliar with the DNS, the further context of subdomains vs core domains in this article will help those unfamiliar with how domain names work can understand them better, and interpret the hyperbole appropriately.