A subdomain takeover occurs when a cybercriminal takes over the subdomain of a targeted domain. Here is how to prevent such cyberthreats.
Websites have grown far beyond their humble origins, becoming platforms for countless applications that serve an organization’s every need. From email to eCommerce, from support to security, many services are now hosted under the umbrella of a company’s website. Subdomains, which are short prefixes to a site’s URL, are easy identifiers to route traffic to the appropriate service, such as mail.example.com, or support.example.com. While useful, these subdomains increase an organization’s attack surface against cybercriminals, and once compromised they can be vectors for a malicious actor to render even further harm.
The problem has become so widespread even major organizations such as have found themselves vulnerable to these types of threats. As your organization expands its services and subdomains, are you taking the proper steps to ensure they are fully secure?
What is a Subdomain Takeover?
The most common scenario for a subdomain takeover occurs when an organization abandons a third-party service, only to have its subdomain reclaimed by an attacker through that service. For example, a company selling woodworking supplies registers the subdomain sales.example.com with its domain registrar, but the actual eCommerce transactions are routed through a third-party service like SquareSpace. Now, SquareSpace is hosting a sales portal for the woodworking supplier under the subdomain sales.example.com.
The company later withdraws from selling online and focuses instead on selling its products in the physical store. Although the company no longer uses SquareSpace, it has neglected to remove the subdomain redirects to and from the service. At this juncture, a savvy attacker now has an opportunity to reactivate the dead linkage from the outside service, seizing the subdomain and potentially hosting content under the veneer of the woodworking supplier’s name.
Also read: Managing Security Across MultiCloud Environments
Assessing the Damage
The damage a hacker can inflict on a compromised website is wide-ranging, from posting pictures of dancing cats to creating phishing forms capable of gathering employee login credentials, then leveraging that information to further infiltrate company systems. Even worse, imagine a fully-cloned eCommerce site designed to capture your customers’ credit card data, along with other personal information. Such a site could become a vehicle for identity or data theft, or propagate malicious software, all at the cost of your company’s good name.
In 2020, Microsoft found itself under media scrutiny for the revelation that many of its subdomains may have been taken over, a situation made possible by “Enterprise sprawl and a lack of internal domain controls,” according to one cybersecurity expert. The consequences put at risk the safety of Microsoft customer data, such as usernames and passwords. Companies failing to secure their online assets may also face serious reputational harm and loss of business.
Preventing a Subdomain Attack
White, black, and gray hat hackers employ sophisticated tools and methodologies to locate system vulnerabilities, and even use simple lists of the most commonly used subdomains in search of abandoned ones. While there are dozens of groups and individuals who actively pursue vulnerable subdomains in the interests of securing them, companies should not rely on the good will of others when protecting their own sites. In fact, cybersecurity researchers recently informed hundreds of companies of their vulnerable subdomains, and found that only 31% of those organizations took steps to improve security in the following six months.
The best prevention is to go right to the heart of the problem. An organization’s IT team should conduct regular, systemic reviews of DNS entries to identify errors in DNS name resolution, which are indicative of a vulnerability that needs to be closed. As off-site services are no longer being used by an organization, their corresponding DNS records should be expunged as a matter of procedure. When partnering with new services, vet these vendors carefully for their security policies and proactivity against subdomain takeovers. Finally, as new services are being onboarded, the final step of that process should be the creation of the corresponding DNS record to avoid the existence of orphan records for even a brief time.
Frequent vetting of DNS entries can become burdensome for large organizations with robust web application needs, but the task is necessary to protect company reputation, customer data, and employee data. Manual reviews of DNS entries can be complemented with or replaced by automated web security audits known as Attack Surface Management services. These companies monitor your web assets for potentially risky exposures and advise your organization on how to reduce the attack surface open to cybercriminals.
Further automation is available to users of Microsoft’s Azure suite with a PowerShell tool that automatically identifies dangling DNS entries that point to unused Azure resources. Azure Defender is another tool that actively detects such entries and provides security alerts in real-time. If that’s not enough, many companies post bounties for white hats to find vulnerabilities before the bad guys do. One white hat subdomain takeover cost Starbucks $2,000, but may have saved them hundreds of thousands in potential damages otherwise.
Thwarting Future Attacks
Quick and decisive action is needed to thwart a subdomain takeover. If a problem is detected, contact the service provider of the hijacked subdomain and inform them of the fraudulent activity being conducted in your company’s name. Cleanse DNS records of offending entries. Your IT may need to conduct a forensic audit of all possible harm that was inflicted by the attack to determine what data may have been stolen, then inform unhappy customers of the breach. Often, companies fallen prey to data theft will provide free identity protection services — at the company’s expense, of course. The vastly preferable option is, naturally, prevention.
Read next: Establishing Server Security Best Practices