The Curious Case Of The PERL.com Website Hijack
An OSINT-based analysis of the perl.com domain hijack incident.
In late January 2021 disturbing news surfaced on Twitter regarding the registration details of perl.com, the website of the once popular PERL programming language. It seems that suddenly the domain changed ownership and was moved to a different server from where it originally was being hosted. Usually things like this happen in relatively rare scenarios where a company (or an individual) forget to renew their domain and the ownership of it lapses, resulting in the domain name getting returned to the pool of available domains, from where it can get snapped up by any willing buyer.
Exactly that happened years ago to Microsoft’s hotmail.co.uk domain; it also happened to Foursquare, and it happened to several other, more or less know online entities over the years. However, in the case of perl.com, this is NOT what occurred.
The website was previously hosted by Network Solutions LLC using the Bitnames servers. But suddenly, on the 30th December 2020, the ownership of perl.com was transferred to a Chinese domain registrar Bizcn.com. On Jan 27th 2021 the ownership was moved to Key-Systems GmbH, a German domain hosting provider. Notably, the servers also changed from Bitnames to Afternic (seems to belong to GoDaddy).
So this is a classic case of a domain hijacking.
This happens when an unauthorized change of DNS configuration occurs. Essentially, the name resolution for the domain is performed by a rogue name server.
Alternatively, the attacker alters registration contact details and claims ownership of any domains legitimately registered by the victim.
It’s crucial to understand that the content of the hijacked website could change completely – or it does not necessarily change at all.
It’s not very hard to clone the contents of the previous site and carry on with it as usual, after making malicious uploads that target the users.
The bottom line is: changes to website hosting and DNS are not always reflected on the site itself, therefore using services such as The Wayback Machine or Urlscan will not always be helpful – instead, one needs to focus on the historical DNS examination.
Which by the way is a very useful angle whenever conducting OSINT on any websites and IP addresses.
Some of the resources that I found helpful for the historical DNS analysis of perl.com were:
- Security Trails – this is a paid tool, but once you sign up you get access to the free features, which in many cases will be sufficient to provide further leads.
- WhoIS Request – free web based tool, allows you to track name server changes since 2002 for the most popular top level domains out there.
- Complete DNS – also free and also web based, paid option is available but not necessary.
- Spyse – offers a lot of useful information, but DNS history is somewhat vague and incomplete. Use this one in conjunction with other tools, then compare the results to fill the gaps.
During the period of time between 28th January and 5th February 2021, the perl.com was not resolving correctly.
The new registrant details were not available publicly, which was a notable change from the previously transparent owner Tom Christiansen to an anonymous person seemingly residing in Chisinau in Moldova (not 100% accurate, I know).
In the meantime, it turned out that the perl.com domain was put up for sale through the available domains listing on Afternic:
The original URL to the listing (no longer active):
https://www.afternic.com/listings/drawmaster
NOTE: This username alone can be a wide angle for further OSINT research, something I did not have the time to delve into. Given the fact that there exists a possible connection to Moldova, which is a bi-lingual, Russian and Romanian speaking country, I would concentrate on sifting through the occurrences of the “drawmaster” username in the Russian and Romanian language sources.
Examples:
I am NOT saying these accounts are in any way related to this incident, what I am saying that the handle might or not be related – this is something that requires a lot more research, and could prove inconclusive at best.
When it comes to the websites linked to the perl.com hijack, other researchers have connected the dots on this faster than I did.
One compelling theory posted on Domain Gang blamed Chinese hackers for a coordinated hijack of perl.com and other domains – for purely monetary gain.
The whole thing appeared to be an elaborate scam aimed at making a quick buck at the expense of somebody naive enough to risk forking out a six figure sum for a domain name that ultimately could be restored to the rightful owner (I will discuss how such restorations are possible later on).
But there was still one more angle to explore – the IP address associated with perl.com during the hijack:
The IP address 35.186.238.101 indeed has a bad reputation according to multiple sources:
- https://talosintelligence.com/reputation_center/lookup?search=35.186.238.101
- https://www.virustotal.com/gui/ip-address/35.186.238.101/detection
- https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a35.186.238.101&run=toolpage
This could be coincidental and it is possible that the attacker’s motive was monetary gain – but it also appears possible that something more sinister could have been planned or at least attempted – especially since other websites associated with that IP have in the past been identified as involved in distribution of spam, malware and ransomware.
https://www.icann.org/news/blog/documentation-is-key-to-recovering-hijacked-domain-names
Conclusion
Thankfully for the owners of perl.com and the whole PERL community, the DNS host record was returned into the legitimate hands several days ago.
Due to everything that happened, some problems with resolving the DNS might still persist.
Brian Foy, who originally reported the problem on Twitter, created an issue on Github where he provided the recent update and is asking users to report any difficulties when visiting the website:
“Verisign restored the DNS on Feb 2, but various servers may have cached values or may have sinkholed it. I want to know if there are parts of the world that are still seeing different answers. Thumbs up if you see the right results. Comment if you can see something different.”
This is what the correct DNS information for perl.com should look like:
PS. Useful information from ICANN on what to do in the case of domain hijacking and why documentation is crucial in the whole process can be found here.
