In 2018, British Airways was attacked through the exploitation of a third-party JavaScript package running on their 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.
c/side 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, c/side 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 intricate 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 c/side was officially established, our founder tweeted the following:
While sifting through research for what would eventually become c/side, 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.
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.
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.
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, clearly demonstrating that companies have lost track of their own domain names.
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, creating 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. c/side 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 potentially 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, c/side is here. We proxy all the third-party scripts on your site and check each session before the code is rendered in the browser of your users.
You can get started for free and find our pricing tiers here.