The Risks of Parked Domains

Organizations register domains for many reasons, the obvious one being to use as their primary online presence. In many cases organizations also register domains that they might not use but want to prevent others from using. The most prevalent reason is brand reputation protection by registering lookalike domains, including those that contain common typos (typosquatting), use uncommon top-level domains (TLDs) such as .cam or .co instead of .com, and variations on the primary domain such as bitsightratings[dot]com. This is a prudent practice, and Bitsight can help identify domains that might be used by threat actors in our Domain Squatting risk vector.

In many cases the organizations don't intend to use the domains, merely hold them in virtual escrow. The registrars know that and offer a service, called parking, whereby anyone trying to reach the domain, let's say by typing it into a web browser, actually ends up at a page hosted by the registrar. Registrars host thousands of parked domains on any given page, but the content rarely has any association with the domains themselves. Instead, registrars make money from parked domains by hosting ads. The registrant of the domain can also receive some share of the ad revenue.

Are Parked Domains Really a Security Risk?

Many organizations view parked domains as dormant, low-risk, and therefore, not worth the investment in robust security measures. This misconception and the tendency to overlook them can make parked domains an attractive target for cybercriminals, whose motives are:

Credential Stealing

Similar to man-in-the-middle (MITM) attacks, parked domains that don't have the stringent security controls of active domains may be hijacked by threat actors. They can set up lookalike sites to bait visitors who believe they've landed at a legitimate and safe web property owned by your organization into entering usernames and passwords.

Malware Distribution

Instead of, or in addition to, credential stealing, attackers can infect visitors to the lookalike site with viruses, trojans, and other malicious software. In effect the attackers turn your legitimate domain into a watering hole, causing extensive damage to end users and tarnishing the reputation of your organization.

Website Defacement

Again, with control of the parked domain an attacker can redirect web visitors to a site that contains offensive content or otherwise embarrass the legitimate owners of the parked domain.

Phishing Schemes

While the previous nefarious schemes require taking control of the domain itself, either by compromising the system hosting the parked domain or exploiting the chain of ad links, email spoofing is often overlooked by owners of parked domains. This oversight makes it trivial for attackers to use the domain in email return addresses, creating convincing phishing attacks.

But That Never Happens, Right?

As a real world example of where parked domains were exposed as a result of a registrar’s oversight, more than 60,000 parked domains were left vulnerable to domain hijacking. In this scenario the domains pointed at AWS S3 before the buckets were configured to serve content for those domains. This provided an opportunity for threat actors to claim those S3 buckets and control the content for those domains and use the implied ownership to, for example, claim a TLS certificate for the domain.

Mistakes on the part of the parking services is not the only risk; intentional exploitation by third parties is even more likely. Parking service providers typically monetize parked domains by serving ads provided by ad networks and their advertisers.

The ecosystem goes:

Ad networks don’t necessarily vet all advertisers for cybersecurity or purposeful malicious intent. There’s a rich history of malvertising going back over a decade. The ad provider has lots of options if proper security hygiene isn’t practiced by the parking service provider; to name just one, they can inject malicious JavaScript into visitors’ browsers—a common practice in exploit kits, used to scan browsers for vulnerable versions and plug-ins, and ultimately compromise the browser and end-user’s machine.

Domain parking providers are your third-party and their third-parties are part of your online supply chain (aka, 4th and nth parties). However, you don’t usually have the ability to set security standards with the parking providers; their services are consumer commodities and they’re not generally agreeable to customer terms, such as requiring them to implement strict security controls over website content. In fact, strict content controls may be counterproductive to their ultimate goal: to make money from your parked domains. Restricting advertisers from providing dynamic content, which often relies on JavaScript, is counterproductive.

The fact that there aren't a lot of publicly disclosed incidents on parked domains doesn't mean it isn't a risk. Years ago—pre-2000—someone argued that Windows RPC had never been exploited so it was okay to expose their Exchange Server to the internet. Then a year later…well, you know what happened. We call people like that future victims.

I'm Getting Bored, Break It Down for Me

To summarize the attack surface of domain parking providers:

• An attacker could compromise their DNS servers or websites. To be fair, this is unlikely because parking providers make money from their services, and domain or web server takeovers would hurt their business. Plus they’re pretty good at domain and web server security because their primary business is often domain registration, a service that's been forced to implement strong security measures because they’re a tasty target for malicious actors.
• Malicious content from the chain of stakeholders providing content (which, by the way, is out of your control). We’ve already talked about that threat vector.
• Phishing: Many owners forget to implement email security on parked domains. That means threat actors can send emails from an address using the parked domain and the recipients have no way to validate the legitimacy of the email.

Fair Enough, But What Can I Do About It?

What you should and can do about the security of parked domains are different. Parked domain providers should limit the potential for malicious content injection using Content-Security-Policy (CSP) headers, such as script-source: 'self' or from specific, trusted hosts, or frame-ancestors: 'none' or 'self'. This isn't a comprehensive list of content controls because it's unlikely that you'll be able to influence parked domain providers to implement them. Instead, since the income generated from clicks is a rounding error in most commercial or government enterprise income statements, the best security posture is to ignore domain parking altogether. You're not really parking the domain as holding it in a form of escrow.

That's right—you don't need to have a domain point to a website at all. The only requirements in a DNS zone are records for the SOA and NS. NS records point to the nameservers authoritative for the domain; the SOA record, for start of authority, contains information about the zone itself, the most important of which for our purposes is the administrative email address for the domain. This lets others know who to contact with questions or concerns about the domain. Note that the email address will be your primary domain, not the escrowed domain.

As mentioned before, domains are also used for email, so it's important to signal to the internet that the escrowed domain is not a valid sender email address. That means adding yet another couple of DNS records to the escrowed domain's zone: an SPF and DMARC record, both of which are implemented in DNS TXT records, that instruct receiving email servers to reject email from the escrowed domain.

An example DNS zone file, in BIND format, would look something like:

$ORIGIN example.com.
@       IN  SOA  ns1.someregistrar.com. hostmaster.maindomain.com. ([TTLs, etc])
        IN  NS   ns1.someregistrar.com.
        IN  NS   ns2.someregistrar.net.
ns1     IN  A    192.168.1.10
        IN  TXT  "v=spf1 -all"
_dmarc   IN  TXT "v=DMARC1; p=reject"

Note that if you don't configure a destination for www and/or the domain itself, visitors who try to browse to the site will get a "site can't be reached" error. The other obvious alternative is to point the domain at an existing website through a CNAME or redirect. The latter requires a bit more work to perform the redirect, but using a CNAME requires you to add the domain to the landing site's certificate. Choose your own adventure.

Conclusion

The business claimed the domain for a reason and it’s now a corporate or organizational asset. No asset should be left unprotected, regardless of its current use. Parked domains, often seen as low-risk, can pose significant security threats to visitors of your escrowed domains and reputational damage to your organization—the very outcome your organization was trying to prevent by registering the domains in the first place.