Skip to main content
Blog
Blog

How expired domains lead to cyber attacks

In 2018, British Airways was attacked through the exploitation of a third-party JavaScript package running on its site.

Jul 08, 2024 9 min read
How expired domains lead to cyber attacks, trusted origins handed to attackers
Table of Contents

TL;DR: baways.com British Airways breach domain resold on a public registry

  • Breach domain on sale: Everyone imagines breach infrastructure gets buried in a takedown, but the domain that skimmed 22 lines of card data off British Airways was available on a public registry, and cside owns baways.com today because we typed it into the search bar.
  • cside cross-references DNS: cside's first-party JavaScript agent observes each third-party script's runtime behavior in the browser 100% of sessions and cross-references DNS history and WHOIS drift, which is exactly what would flag a resurrected breach domain that a source-only scanner would miss on 95% of scripts with no DNS-hijack protection.
  • Monitor legacy dependencies: British Airways paid a fine first set at 183 million pounds and later reduced to 20 million, so the decision is not whether to renew a legacy domain, it is whether every historic third-party dependency on your site is still monitored the same way you monitor your own code.

Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.

In 2018, British Airways was attacked through the exploitation of a third-party JavaScript package running on its site. The script was compromised, and the attackers added lines of code that automatically copied all customer credit card and transaction details to a new domain: baways.com. This domain was cleverly purchased by the attackers a few days prior to the operation.

cside currently owns baways.com. If you visit the site, you'll find an explanation of the entire attack from beginning to end. The domain is now completely safe and serves educational purposes.

However, the question we're posing is this: How were we able to get a domain previously used in a cyber attack?

How we acquired baways.com

When the attack happened, the domain was hosted in Romania by a Lithuanian hosting provider which offered virtual servers at affordable rates.

Today, cside can detect such anomalies and prevent similar problems. Unfortunately, we weren't available back then. You can learn more about how this attack happened by reading the full article on baways.com.

The buzz around this attack subsided after October 2020 when British Airways received a record fine for a data breach. First set at £183m, later reduced to £20m. After July 2021, they wrapped it up by settling the legal claim with the affected customers.

As news coverage of the incident eventually stopped, the world moved on.

So, how did we manage to acquire the domain used in the largest attack of its kind at the time?

While we wish we could share an elaborate tale of sifting through dubious forums and negotiating shadowy deals, the truth is actually more unsettling. We purchased it on a public registry.

A few weeks before cside was officially established, our founder tweeted the following:

Founder Simon Wijckmans's tweet about buying the British Airways breach domain

While sifting through research for what would eventually become cside, he examined articles about the British Airways data breach. During this research, the domain in question caught his attention. Much to his amazement, it was available for anyone to claim.

Public registry listing showing the baways.com domain available for purchase

Purchasing an expired domain that was involved in a cyber attack is concerning for several reasons:

Access to data

Gaining control over a domain with previous use, can give access to the most private of data.

Inti De Ceukelaire, a cybersecurity expert from Belgium, shared this blog post in May of 2024. He had purchased several expired domains previously owned by local police services and social institutions in Belgium.

Screenshot of expired domains acquired by security researcher Inti De Ceukelaire

He ended up purchasing over 100 domains, and reported the following:

"For the 848 e-mail addresses I was able to identify within a week, I successfully obtained the password reset emails for 80 Dropbox accounts, 142 Google Drive accounts, 57 Microsoft / OneDrive / SharePoint accounts, and a dozen Smartschool and Doccle accounts. I realized that by buying these domains, I had gained access to tons of sensitive citizen information stored in the cloud accounts linked to these email addresses."

As well as:

"These weren't the only e-mails I started receiving. Shockingly, years after these email addresses were abandoned, they still received extremely sensitive information […]. Confidential justice information, information regarding released detainees and public defenders, payment reminders for people in debt, emails related to vulnerable people's health or social situation, getting invites to special committees, […]"

You can read his full investigation here.

Losing trust in your brand

The Royal Mail in the UK uses unusual-looking domains that can undermine trust. This is evident in another tweet (X post) we posted after encountering this issue ourselves. While we may be more alert to this problem, we're confident we're not the only ones uncomfortable with clicking on such links.

Founder Simon Wijckmans's tweet about a Royal Mail look-alike domain

What made the situation worse was that their own support team responded stating that this was a phishing text. But that was incorrect. An older tweet by royal mail below used the same domain as a URL shortener. This undermines trust with attentive users and shows that companies have lost track of their own domain names.

Old Royal Mail tweet that reused a now-expired link-shortener domain

We'll use HubSpot as a final example. They have dozens of domains with varying levels of structure. These domains are used in various scripts and across different platforms:

  • hubspot.com
  • hs-scripts.com
  • hs-banner.com
  • hs-analytics.net
  • hubapi.com
  • hsforms.com
  • hscollectedforms.net
  • ...

The risk here is that people might come across these domains in scripts and not trust them or make it easier for a bad actor to buy a domain that looks legitimate as it follows a similar format to the other domains.

Domains are used in old third-party scripts

We recently reported on the Polyfill attack. A domain that was used by an open-source project got purchased. The domain was then found injecting malicious code. This code dynamically generated payloads based on HTTP headers, activating only on specific devices, evading detection, avoiding admin users and delaying execution.

In some instances, users receive tampered JavaScript files, which include a typosquatted domain googie-anaiytics[.]com/gtags.js. This link redirects users to various sports betting and adult websites based on their region. But this being JavaScript, could at any moment introduce new attacks like formjacking, clickjacking, and broader data theft.

In the Polyfill attack, the service was outdated and no longer needed for the most part. Yet the domain remained active on thousands of websites.

If it's not the domain being bought, tools may go bankrupt, get sunsetted or stop receiving updates. When this happens, some websites fail to remove the outdated scripts from their code. If a defunct company's old domain or script is then acquired, it becomes automatically embedded into thousands of websites and opens an easy avenue for attacks.

A lot of security tools only check sources of scripts, which in these cases mentioned would not suffice. Attacks would simply be flowing through unnoticed. Read more on this issue here.

The need to monitor your scripts

This is one of the reasons that PCI DSS 4.0 will require monitoring and scanning of scripts on payment portals by March 2025. cside does this automatically, even securing third-party scripts each time a page is loaded by a user. This is done across your entire site, not just on payment portals, which even goes above and beyond their recommendations. Read here to understand why this is critical for your website's security.

How to solve the expired domain threat

This is a multifaceted issue. Simply buying an expired domain isn't illegal. However, if a domain name is trademarked, then purchasing it (known as cybersquatting) could breach copyright laws. But this will not defer attackers who usually remain anonymous and unnoticed.

Getting access to emails sent to a domain previously owned by someone else (or another company) is a grey area legally and ethically. While some countries have laws that prevent you from opening physical mail directed to someone else, the application of these laws to emails is often open for debate.

Laws that address electronic communication typically forbid the interception of communication between non-consenting or unaware participants. However, in the case of emails sent to an expired domain, one could argue that the recipient is the legitimate owner of the domain name and therefore the intended addressee.

Privacy laws also prohibit the sharing and processing of data of individuals without their consent. So by sending content to an expired email address, the sender may actually indirectly violate the recipient's privacy rights due to a lack of due diligence on the email address. A whole other problem in and of itself.

As you can see, this is an issue that’s best avoided altogether if you can.

As a company or website owner, try to retain domains with previous usage, especially those used for creating accounts and transferring data. Getting similar domains and preventing attackers from using them (this is called cybersquatting) should also be considered. Even if this could potentially add unwanted annual costs.

If you can’t, or when changing domains and email addresses, it's important to provide a reasonable adjustment period for people. If possible, enhance security measures and set auto-reply notifications for those attempting to make contact during and after this transition.

To protect your site from malicious acts caused by third-party scripts and domains in those scripts, cside is here. We fetch and analyse all the third-party scripts on your site and check each session before the code runs in your users' browsers.

You can get started for free and find our pricing tiers here.

Simon Wijckmans
Founder & CEO

Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks, web security is not an enterprise-only problem.

FAQ

Frequently Asked Questions

When a company lets a domain lapse, even a short-lived link shortener or campaign URL, anyone can re-register it. The new owner inherits any traffic, password reset emails, and trust signals that still flow to that domain.

We bought baways.com on a public registry. That single purchase shows how attackers can take over historically sensitive domains with no special access and use the inherited authority for phishing, credential theft, or skimming.

Monitor and Secure Your Third-Party Scripts

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Start free, or try Business with a 14-day trial.

cside dashboard interface showing script monitoring and security analytics
Related Articles
Book a demo

Want to walk through this with an engineer?

Thirty minutes, on your own site. Not a slide deck.

We'll show you:

Which third-party scripts are running on your site right now
Where you stand on PCI DSS 6.4.3 and 11.6.1
How much of your traffic is bots and AI agents

Rather just send a question?

Finding open slots…

Real humans only. We'd know.

Having trouble booking? Open scheduler in a new tab

What are you trying to solve?

Tell us in a line and we'll come back with something useful, not a generic pitch.

We usually help with:

Seeing which third-party scripts run on your site
PCI DSS 6.4.3 and 11.6.1 evidence
Bots, AI agents and account takeover

Prefer to just book a time? Pick a slot instead