It was not so long ago we saw Google blacklist complete sets of subdomains such as the co.cc domains. (http://www.seroundtable.com/co-cc-google-removal-13644.html) These were known to be hosting malicious websites. About the same time, I also started to investigate new ways of identifying domains connected to malicious content by analyzing the DNS information.
During my research I simply performed AXFR checks on domains that looked suspicious, but I quickly noticed that it was not only machines hosting phishing sites that have weak configurations in their nameservers. Many government sites, and nameservers handling TLD (Top Level Domains), allow AXFR. This is not a vulnerability in itself, but the information collected from the nameservers can be very valuable for attackers.
AXFR is the opcode for DNS zone transfer, this is a type of DNS requests that will allow you as en external person obtain all DNS information for a specific domain. It is used for administrators to replicate the databases containing the DNS data across a set of DNS servers. This also allows attackers to obtain all DNS data for a specific domain
Targetted attacks and hacktivism has been a very hot topic lately. This has put some pressure on governments, organisations and many large companies. We have seen that security has become a higher priority within companies, but it seems that most focus is on the new and technical vulnerabilities, which have resulted in the fact that old and trivial vulnerabilities are being forgotten.
One of my first checks was to see how many of the top level domains out there actually support AXFR. I based my research on the IANA TLD list available at https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2011/07/20083519/tlds-alpha-by-domain.txt. To my surprise about 30% out of all nameservers handling TLD allowed AXFR.
This got my brain ticking, and I wrote a simple script that could add names before the TLD and try to perform an AXFR on the available nameservers for that domain. This could be useful to check for co.cc, cz.co and other domains. I know that there are some “standards” for how domains are setup. For example, a lot of governments use the word “gov” before the TLD to specify that it’s a government site; for example gov.se and gov.com.
I decided to simply add a check for this in my script, and once again, to my surprise, I found a lot of government domains allowing AXFR – a total of 12% allows AXFR:
But this project had a different purpose. I wanted to identify sites somehow linked to malicious content, so I started to enumerate nameservers and collect data from the different nameservers. After a while I noticed that the persons registering domains used in malware campaigns often used hostnames which could be distinguished from a valid domain name. The domain name often contained random characters, or the names of the company they were trying to attack.
Ability to identifying malicious sites
This practice, of using domain names with random characters or the name of a victim company, is a very common practice for phishing sites. It is very common to see a domain name consisting of login.yahoo.com.somedomain.com or something similar, for example.
I simply parsed my database and looked for strings that are commonly used in phishing sites. One example of a phishing site I detected is shown below in the screenshot:
For a very long time DNS information has been very interesting to analyze, and the recentnoise regarding DNS security and malicious domains is yet more proof that we need to keep monitoring this protocol.
One of my co-workers, Eugene Aseev, wrote an interesting article regarding the recent blacklist of domains: you can read his blog post here:
I am quite shocked at the amount of data I was able to harvest via AXFR transfers, and how many sites there are that still allow this. Enumeration is one of the most important steps in a targeted attack, and DNS zone transfers can give the attacker a lot of interesting information, and a complete list of potential targets. I really advise everyone to review their zones and setup, and make sure that no unnecessary data is leaked