A few weeks ago we recommended (via Twitter) a good article from Zach Whitaker in Tech Crunch about how he proved how easy it was to gate-crash a Zoom meeting by knowing the company's subdomain where they parked the non-employee meetings. Oops. He did let them know and wasn't up to anything untoward.

But it did get me thinking about subdomains. You know - "support.mcdonalds.com" instead of "www.mcdonalds.com".

Almost every website uses subdomains in some way or another. Even your mailserver of mail.yoursite.com is a domain. But how secure is this for companies?


Tools To Find Subdomains Out There

If you, or the next guy, or a hacker, wants to find out all the subdomains a website actually has, it's not hard. Here's a good guide and here's the subdomain finder I used for this exercise


The Experiment

This is absolutely an exercise in low-hanging fruit. We aren't employing any sophisticated hacker techniques to try to see how vulnerable a site really is. We are just going to look at subdomain lists for some sites, poke around and see if any of the names pique our curiosity, then just do a Google search of that subdomain.

For those of you who have never searched Google for all indexed pages on their site, you can Google search "site:ups.com" to find all publicly available pages in their root domain. But if you new of a certain subdomain then you could search that "site:supersecretsubdomain.ups.com" and see what you find.

Obviously, we don't endorse hacking or looking for backdoor information for nefarious purposes. We do breathe easy that anybody who would have malicious intent with something like this already knows these rudimentary techniques.

I just wanted to try this out not by picking on small companies to try to see what's findable this way. Instead, I'm going to my old saw of the top 10 companies listed on the Fortune 500. And away we go ...


Top Fortune 500 Companies

1. Walmart (521 subdomains)
We only tried a couple, but it was really easy to find an API subdomain with entry pages for some of their internal web services
Search results

2. Amazon (593)
Lots of legit, public-facing subdomains there, but some other ones too. They run so much of their myriad of services/products on subdomains (like books.amazon.com) so it's no surprise.

3. Exxon Mobil (366)
Good job protecting from Google - when we searched several subdomains there we got no results. But at minimum, the subdomain search revealed lots of different mail server names, etc.

4. Apple (599)
Nothing too juicy on a quick search of a couple. But clearly we can all find some things that should be only internal (and should not have been left to be indexed by Google).
Search results

5. CVS Health (218)
Some customer facing subdomains as to be expected. Nonetheless, we also found the addresses of a lot of developer APIs / web services.

6. Berkshire Hathaway (5)
Warren Buffet's people are able to keep a tight ship with only 5 subdomains, which is pretty easy to do when there's not a lot of customer-facing content.

7. United Health Group (101)
Still blows my mind they are the 7th biggest company around. Some API locations found there like mentioned above for other companies. They also an interesting naming/file/server convention: they keep archives of their web as their own subdomains: www-2019.unitedhealthgroup.com, etc.

8. McKesson (Medical Supplies) (390)
They have some obvious API locations, nothing too easy or revelatory there but clearly some folks in IT have left a stray testing domain or two stay live: mtsinvoicetest.mckesson.com

9. AT&T (594)
Nothing too immediately dangerous here, but these are internal documents I just found on the first subdomain I decided to search. Surprise, surprise: ATT web security isn't up to par.
Search results

10. AmerisourceBergen (Drug manufacturer) - (117)
We were able to find logins to their CMS system: cmms.amerisourcebergen.com and file transfer securestag.amerisourcebergen.com ... those were just the first two I saw. Pretty low-hanging fruit for a real hacker.


Some Risks In Subdomains

Wildcarding your SSL certificates - When you set up SSL certificates (so browsers will show HTTPS: prefix instead of less-secure HTTP:), if you set a generic rewrite rule for this across your whole site (all subdomains), it's a little bit of a security risk.

Leftover Subdomains - Here's a good article how a subdomain you may have forgotten about is a liability: .

Leftover ones from other provides - Another variation on this is let's say you have set up a subdomain dedicated to a third-party service (like shopify.yoursite.com or wiki.yoursite.com). If you stop the service but leave that empty subdomain in your server, it makes you a target for a subdomain takeover. Further reading

SEO - Getting too cute with content spread across multiple subdomains can hurt your SEO and Google search ranking. If you have some content in blog.yoursite.com and a lot in the root www.yoursite.com ... then it can water down the strength of your domain in Google's eyes. (Although let me stop there before going down an SEO rabbit hole, since this can conceivably be an asset if done properly.)


What You Can Do

- Make sure your robots.txt file makes your subdomains uncrawlable. Here's an article from us last year on Google "dorking" with robots.txt file instructions towards the bottom

- Any pages that you don't want to be searchable in Google (or other search engines), put a"No Index" in meta tags. Here are good instructions straight from the source: Google

- Take control of your whole Google Index, what shows up in Google from your site. Here's a good article; and follow Google Webmaster Tools advice.

- If you do insist in using subdomains as cloud storage for any internal purposes, make sure to assword protect the subdomains in addition to other precautions.

Feel free to email us if you have questions or thoughts.