Want to know how much website downtime costs, and the impact it can have on your business?
Find out everything you need to know in our new uptime monitoring whitepaper 2021



It’s a common belief that once we purchase a domain, it’ll be ours for as long as we like. Big mistake. Mainly because there are genuine threats to your domain online that mostly go unthought of. For example, hackers can gain access to your system and take your domain for ransom or cause malicious damage to you and your business. Surprised? Well, we have 5 examples of exactly when this has happened, and how hackers have managed to gain access to domains and cause mass disruption.
It may seem shocking to you but even Google, the world’s most dominant search engine, had its Vietnam region domain hijacked in 2015. The hackers used a hacking method known as DDoS (distributed denial-of-service) which is ultimately used to take down websites. They redirected users to a website that sold hacking tools to the general public. As you can expect, Google acted quickly to minimise the damage from this hack and swiftly managed to get their domain back.
The same team who caused Google’s issues also hacked Lenovo using the same method. It’s reported that the reason behind the hack was connected to “Superfish” which is a digital marketing tool for online ads. Lenovo was linked to this marketing company as it provided devices with pre-installed software towards the end of 2014 which turned out to be a security risk to the users. The software did not only collect data on the images on your browser but also other traffic that you viewed as it was acting as a proxy on the device. It seems like the hack was only carried out to cause problems for Lenovo and bring the issue to light.
A Lenovo spokesperson said “we did not do a thorough enough job understanding how Superfish would find and provide their info. That’s on us. That’s a mistake that we made.”
This attack occurred in 2018 when many domains that we are all accustomed to, noticed that highly suspicious emails were sent out to institutions around the US asking for $20000 ransom. It became apparent that the reason this was happening was due to a group hacking into the DNS provider and taking over the domain name. The group was after dormant domains that were linked to large corporations such as Mozilla, Yelp, and Mastercard to name a few. Godaddy soon fixed the issue and announced that the group had taken advantage of a weakness in its system which was quickly rectified.
In this hack which occurred in January 2017, it is believed that the hackers used the old-fashioned “phishing email” to gain access to credentials that would allow them to access the domain and gain control of the system. Phishing techniques are still one of the most-used and easiest ways to gain access to any system. The issue was quickly identified and resolved but the question is – how long did they have access to this and how many emails did they redirect to gain access to confidential information?
It might sound strange that a sponsored hack might target a consulting firm but there does seem to be a reason for this. Cafax has a consultant working for them who is employed by netnod a Swedish DNS provider and one of the 13 foundational DNS providers that control the i.root in the global distribution system. It seems the hackers were trying to gain access to netnod through the credentials of this consultant. Previously the hackers had succeeded in accessing netnod but luckily, it seemed this time they didn’t manage to.
What we can see from these 5 domain hacking examples is that it doesn’t matter how big your organisation is, there are threats out there that will do whatever they can to gain access to your information either to sell it back to you or to someone who is interested in it.
Sign up to StatusCake for free today to monitor your domain.
Share this
3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams
3 min read In the previous post, we looked at how alert noise is rarely accidental. It’s usually the result of sensible decisions layered over time, until responsibility becomes diffuse and response slows. One of the most persistent assumptions behind this pattern is simple. If enough people are notified, someone will take responsibility. After more than fourteen years
3 min read In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.
4 min read In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint. This post assumes that context. The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already
3 min read In the previous post, we explored how AI accelerates delivery and compresses the time between change and user impact. As velocity increases, knowing that something has gone wrong before users do becomes a critical capability. But detection is only the beginning. Once alerts fire and dashboards light up, humans still have to interpret what’s happening,
5 min read In a recent post, I argued that AI doesn’t fix weak engineering processes; rather it amplifies them. Strong review practices, clear ownership, and solid fundamentals still matter just as much when code is AI-assisted as when it’s not. That post sparked a follow-up question in the comments that’s worth sitting with: With AI speeding things
Find out everything you need to know in our new uptime monitoring whitepaper 2021