.nl not affected by global domain hijacking campaign

Domain hijacks

A domain hijack is “the act of changing the registration of a domain name without the permission of its original registrant” and involves an unauthorised person changing a domain name’s records in the Domain Name System (DNS) so that it maps to a different IP address than that set by the registrant. For example, a miscreant might change the www mapping for the domain example.nl in the DNS so that visitors who log on to www.example.nl unknowingly send their traffic through an intermediate server that the miscreant uses to record their user names and passwords. Similarly, the miscreant could also change example.nl’s mail settings in the DNS so that the intermediate server receives and stores e-mails sent to any_user@example.nl.

Domain hijacks may thus have severe effects in terms of security and privacy compromises as well as reputational and financial damage, both for users and for registrants.

Account compromises

One way for a miscreant to hijack a domain name is to compromise the account through which registrants manage their domain name settings through their registrar, for instance by using user names and passwords obtained from other compromised sites. Similarly, they may also use more advanced techniques, such as spear phishing the staff of a registry to obtain the credentials of more high-value domain names.

Once the miscreant manages to compromise the account, they use the administrative panel that the registrar provides to change example.nl’s records in the DNS. For example, they could change the domain’s name servers, which results in users visiting www.example.nl being redirected to a malicious site through name servers under the miscreant’s control.

The Security and Stability Advisory Committee (SSAC) at ICANN provides an overview of actual compromises of registrant accounts that took place in the past and how they were carried out.

Global hijacking campaign

Security company FireEye recently reported that they had discovered a global domain hijacking campaign that affected “dozens of domains belonging to government, telecommunications and internet infrastructure entities across the Middle East and North Africa, Europe and North America” and suggested the campaign was state-related.

FireEye also published the techniques they found the adversaries had used, which included changing the IP addresses of a domain name (DNS A records). While FireEye did not reveal how they obtained this information, it led the Dutch National Cyber Security Centre (NCSC-NL) to issue a security alert, just like national CERTs in the US and the UK.

Analysing .nl’s DNS records

Prompted by the reports, the team here at SIDN Labs analysed the .nl zone for name server changes and initially identified 623 .nl domain names distributed across 43 registrars that shared characteristics with domains involved in the campaign.

We shared the names with NCSC-NL, who used other (undisclosed) datasets for further analysis. Based on that analysis, they reported that it was unlikely that the names had actually been compromised.

Lessons learned

While that is good news, we also learned that we will need to further extend our DNS monitoring facilities to detect domain hijacks more proactively and thus protect the security of .nl users and registrants, particularly in collaboration with NCSC-NL, our registrars, and the research community.

We were also reminded that the security of domain registration data remains a key part of global internet security and that it requires registries, registrars, and DNS operators to follow best practices such as two-factor authentication (2FA) for logging onto admin panels, domain locks for high-value domain names, carefully designed domain management privileges, and high awareness of staff of potential phishing campaigns that might target them. We and our registrars employ several of those techniques to protect .nl domain registrations, such as 2FA on the portals that our registrars provide to registrants and the registry lock that we offer at SIDN.

I personally recommend everyone working in our industry to read the SSAC advisory on this topic, and in particular the practical check list the SSAC offers in Section 6.

Cristian HesselmanDirector SIDN LabsMember of the Security and Stability Advisory Committee (SSAC)