DNS is a crucial service for all companies and organizations to run their business. No matter how tightly you restrict outbound access from your network, DNS will be one of the services you need to turn on in order to be able to access the Internet. Without proper DNS management and good network security policy, malware could bypass your security and establish covert channels with external Botnet C&C (Command and Control) servers.
In this blog, I would like to share one of the interesting findings I discovered recently while I performed research on malware behaviors and DNS security.
Fig. 1 – Malware Sample Information from VirusTotal
Trojan.Generic.KDV.769996 is the malware that I will discuss. The detailed information for it from VirusTotal is shown in Fig.1. Most security vendors are able to detect it as malicious although they give different names to this malware. I will use the name that BitDefender refers in this blog. I also downloaded the malware network traffic from VirusTotal. The file has a name with hash value of FDE418EB1CD8996C980CA9610B944759. It was a network traffic capture file when the malware was running.
This malware sample was submitted on Oct 26, 2012, and the malware file has metadata with timestamp of Oct 5, 2012. So we can guess that the malware was first released around in October 2012. The timestamp information is helpful for us to trace back the domains/servers and their registration entity at that time period. I will discuss it later.
Fig. 2 – DNS traffic inside malware network traffic
The pcap file contains 63 packets, but most of them are ICMP/ARP traffic. In our study, we only focus on DNS query/response traffic. Fig. 2 shows all the 8 DNS packets in the network traffic. Here is what we find in the pcap.
- IP address 10.0.2.15 is an infected machine, and IP address 8.8.8.8 is the public DNS server from Google.
- On the first 4 DNS packets, the infected machine 10.0.2.15 sends normal DNS query for legitimate domains, such as windows.com, update.microsoft.com to the Google public DNS server 8.8.8.8, and Google public DNS server resolves the domain to the IP address. Everything looks good, nothing suspicious.
- On pkt #48, the infected machine 10.0.2.15 does DNS query to windows-update.net. It seems to be a normal DNS query for the Microsoft applications or windows services, but actually www.windows-update.net has no relationship to Microsoft and/or Windows. Actually it turns out to be a suspicious/malicious domain. On pkt #49, we can see that, Google public DNS server resolves the domain to IP address 203.223.135.218, which is located in Malaysia.
I did WHOIS search on both the IP address 203.223.135.218 and the domain windows-update.net. Fig.3 shows the WHOIS[3] information on IP address and Fig. 4 shows the domain history information.
The interesting thing is that the domain was registered as early as in year 2004, and then expired, and then someone else registered again, and so on and so on. Fig. 5 shows the domain information on www.windows-update.net registered in 2012.
Fig. 3 – WHOIS information on IP address 203.223.135.218
Fig. 4 – Registration history of windows-update.net
Clearly we can see that, the malware executable file was created on Oct 5, 2012, and the windows-update domain was re-created on Oct 15 (associated with this malware), and the malware was first reported to VirusTotal on Oct 26, 2012.
From the above information, the domain windows-update.net was created at ideaaweb.com on Oct 15, and then moved to parkpage.foundationapi.com on Sep 26, 2013. One month later, the DNS servers were updated again, and finally the domain was removed or expired on Nov 7, 2013.
- Once the infected machine gets the IP address 203.223.135.218, instead using Google public DNS server, now it directly use this IP as DNS server to perform DNS query. As we can see in the pkt #50 in Fig. 2, it does some random domain/subdomain queries which can be interpreted only by the suspicious DNS server. Although windows-update.net looks to be web server, it actually runs DNS services as well. As you can see “imnqa-mJ6MgqKmrIKipqLAYHBgbGJ6hJR6YGxg.g.r” is not a valid domain, but malicious DNS server 203.223.135.218 does provide some responses to the infected machine, “LS4.g.s A 158.181.170.207”. Most likely the malicious server suggests client communicate to other machine such as 158.181.170.207, but we could not confirm it here because the pcap does not capture any further traffic.
As of today, when we do whois query on the domain windows-update.net, it is not a valid domain anymore. That means, if we ever re-run the malware sample, we may not be able to see the same behavior/response from the pcap.
Overall, this malware Trojan.Generic.KDV.769996 seems to be very stealthy. First, before it does DNS query to the malicious/suspicious domains, it sends out some background noises on DNS queries for some legitimate/popular domains in order to hide the activity. Second, the malicious domain is formed by common and popular English words, which makes the domain looks legitimate. And last, the malware talks to web server using DNS protocol directly, and encodes some communications within DNS protocol channel.
If network administrator can apply a good network security policy and enforce that all DNS traffic must redirect to company-owned DNS servers, it will detect the fake DNS query on “imnqa-mJ6MgqKmrIKipqLAYHBgbGJ6hJR6YGxg.g.r” and infected host would not be able to get the information on the IP 158.181.170.207.
To summarize this blog, without proper DNS management and good network security policy, malware can bypass the DNS query to external private-owned DNS server and establish stealthy C&C channels for data exfiltration and other bad behaviors. So make sure that you prevent unauthorized DNS resolution in your environment, and subscribe to Infoblox’s DNS Firewall threat intelligence feed to keep yourself protected from threats like these.
About Me:
This is Jianhong Xia, and I work in the Threat Intelligence Group in Infoblox. My research is focused in network security, malware/vulnerability research, DNS tunneling and DGA detection and data mining on massive DNS data in AWS. Before I joined Infoblox, I spent 8 years in McAfee Labs developing NSP (Network Security Platform) and doing network vulnerability research. Before I joined McAfee, I was Ph.D. student in Department of Electrical and Computer Engineering, University of Massachusetts Amherst.
References
- Generic.KDV.769996 information on VirusTotal Website, https://www.virustotal.com/en/file/29c05ced38dfbb5a3de17c74659f2a6023e82d4e0b4a052059c9a5738b23e65d/…
- WHO IS REQUEST lookups and research tools, http://whoisrequest.org/history/windows-update.net