The full story of the DNSChanger Trojan

Date : January 06, 2009

Overview

DNSChanger is a family of Trojan which, as its name can tell, alters the DNS settings of infected computers (to force the computer to use a rogue DNS server) in order to redirect the user to malicious web sites or services. As a reminder, the DNS protocol allows systems to obtain the IP address of a server from its name: this process is called DNS resolution, and it happens for instance each time a user enters an URL in its favourite web browser.

The rogue DNS servers which receive the infected machines’ requests may perform all that is imaginable regarding redirections:
  • Redirect legitimate web sites names (banking sites, online payment sites …) to malicious servers hosting copies of these web sites (phishing),
  • Redirect mail servers name to fake servers which can thus have access to sent and received e-mails and of course connection credentials,
  • Modify the way the DNS resolution of specific names is performed in order to block or prevent antivirus updates or to cause antivirus solutions to download malicious updates. If we are to believe this post from McAfee Avert Labs blog, certain rogue DNS servers can block the download of Microsoft security updates but also the download of other widely used software updates.

This kind of attacks is actually very simple but also definitely efficient and dangerous. In fact, it is not always easy to notice that the DNS configuration of a system has been modified especially because the malicious DNS server responses are in most cases the same as the ones sent by a legitimate server. Moreover, a bad DNS configuration can be active for a long time on a system, even if the antivirus solution was able to remove the Trojan.

This article draws up the history of the DNSChanger Trojan family and describes in particular the latest variant of this malware which appeared in the beginning of December.


“DNSChanger”: a long history

The first version of DNSChanger, which might be actually rather considered as a precursor, was discovered in 2003. This Trojan was generally called Qhosts by the antivirus editors (see the technical pages from CA, McAfee or Symantec). It simply alters the “hosts” file of infected Windows systems (file usually located in the %WINDIR%SYSTEM32DRIVERSETC directory) so that names such as “google.com” will be redirected to servers (IP addresses) owned by the attackers.

A recent variant of this Trojan (QHosts-113 - McAfee) modifies the system “hosts” file in such a way that well-known antivirus editor domain names such as “kaspersky.com”, “Symantec.com” or “mcafee.com” are redirected to the local (loopback) IP address 127.0.0.1. The main effect of this action is that the victim user will be unable to access the legitimate antivirus web sites.

In most cases, when the Trojan is installed on the system, the default location for the “hosts” file is modified (via the Windows registry) so that the original file will not be altered. This makes more difficult to detect the change in the “hosts” file.

The main limit to the “hosts file alteration” attack is that the attacker has to install a new “hosts” file on the compromised system each time he wants to add or modify a name resolution.


After this “Qhosts” precursor, other DNSChanger malwares appeared. The most interested one (see the description pages from F-Secure, McAfee or Symantec) is a variant of the well-known Zlob Trojan. It appeared in 2005. When it is executed on an infected system, it modifies the configuration of Windows systems by changing the value of the “NameServer” registry key in order to replace the default DNS server IP address by the IP address of a server owned by the attacker. Therefore, when a system has been infected, it will systematically send its DNS requests to the rogue DNS server for all DNS resolutions. In particular, the URLs entered in the web browser will always be redirected according to the malicious DNS server configuration. Once the system has been compromised and its DNS settings have been changed, the attacker no longer needs access to this system to modify or add specific name resolutions, it just has to change or add DNS entries on his own DNS server. The major limit of this attack is that it only affects the infected computer, in other words, the other systems on the same LAN for example are not at risk. In addition, if the infected system is properly cleaned and reconfigured, it recovers a regular DNS behaviour.

Note: A variant of DNSChanger called OSX/RSPlug (or OSX/Puper depending on the editor) has been specially designed to target Mac OS X systems.


The first next significant variant of DNSChanger (DNSChanger.f - McAfee) appeared in June 2008. If the infection mechanism remains the same (a Trojan horse), the way the malicious code changes the DNS settings on systems is new and rather original.

Let’s suppose we have a local network (LAN) in which all the computers use the same gateway to reach the Internet. Sometimes, that gateway implements multiple functions : DHCP server (it provides network connection information for computers connected to the LAN : dynamic IP address, IP of the default gateway, IP of the DNS server …), routing and IP address translations (NAT), and may even act as a DNS cache. This kind of installation may often be observed on small LANs connected to the Internet via a DSL connection (where the Internet Service Providers provides to its customers a "all-in-one box"  which is that gateway).

Note: As a reminder, the DHCP protocol is the protocol responsible for distributing dynamic IP addresses, as well as other information, including DNS settings.

The Trojan actually directly attacks the gateway in order to change its DNS configuration. To achieve this goal, the malicious code uses two techniques:

  • The brute force attacks: The malware tries to connect to the gateway using a built-in predefined list of IP addresses that are usually used for such devices on LANs. It then tries to guess the credentials (username and password) allowing to access to the gateway administrative interface by using a list of default credentials such as (“admin”, “admin”).
  • The Cross-Site Request Forgery attacks (CSRF): The malicious code attempts to exploit vulnerabilities in the gateway that may allow it to change the DNS settings without having to authenticate on the gateway.

All the interest of an attack targeting the gateway is that it will indirectly affect all the computers located on the same LAN:

  • Either because the compromised gateway will use DHCP to provide the IP address of a rogue DNS server,
  • Or, in the case where the compromised gateway acts as a DNS cache, because it will request names from a rogue DNS server instead of the legitimate one.

In the example described above, one system infected by the DNSChanger Trojan can cause all the machines on the LAN to communicate with the rogue DNS server, which indeed dramatically increases the risk of phishing attacks.


The ultimate “DNSChanger” variant: the DHCP server

This latest variant, which appeared in the beginning of December, is described under the Trojan.Flush.M name by Symantec. This Trojan horse provides false information regarding the DNS configuration on local networks using the DHCP protocol.

Once this variant of the malware has compromised a computer, it installs a legitimate Ethernet driver generally named “ArcNet NDIS Protocol Driver” (NDISProt.sys). This virtual Ethernet adapter allows the malware to receive DHCP requests that are broadcasted by client machines on the network and to forge crafted responses containing malicious settings referencing the rogue DNS servers.

This attack technique potentially allows a single infected computer to poison the DNS settings of all the systems located on the same network, making them sending all their requests to fake DNS servers. On its blog, McAfee presents the following scenario:

  • Jill is using the free WiFi access point at her favourite coffee shop from her infected Windows laptop.
  • Steve sits down at the next table and fires up his laptop, which requests an IP address over the wireless local area network.
  • Jill’s infected PC injects a DHCP offer command to instruct Steve’s computer to route all his DNS requests through a rogue DNS server.
  • Steve fires up his web browser and navigates to his favourite social networking site, but while the browser displays the correct URL name, the rogue DNS server has actually directed the browser to another site.

The risk associated to this variant of the Trojan is significantly more critical than the one associated to the previously mentioned variants. This can be summarized by the following points:

  • An infected system can compromise the DNS resolution of all the systems next to it (computers located on the same LAN, laptops connected to the same wireless access point …).
  • Systems that are not infected with the malware can still have the payload of communicating with the rogue DNS servers. This is achieved without exploiting any security vulnerability.
  • The DNSChanger/Puper/Zlob gang has been very successful, infecting millions of PCs during the last couple of years. This gang typically uses strong social engineering to entice victims into installing the malware.
  • The attack can be considered as platform independent. The DHCP protocol is implemented on most operating systems and on a large variety of devices that have network connectivity (handheld game consoles, portable mp3 players, mobile phones, digital picture frames and so on …).
  • Locating a poisoned system on a sizable network is often a difficult task.

Recommendations

Considering the different variants of DNSChanger we described in this article, the Cert-IST can give the following recommendations:

  • Monitor or filter the DNS traffic directed to the rogue DNS servers. Most of these servers are currently located on the 85.255.112.0/20 network. The maximum protection can be achieved by e.g. blocking all the DNS requests targeting external DNS servers, excepted in very specific configurations (such as laptops).
  • Periodically check the DNS settings on all the computers connected to the company network. This task can easily be automated by using scripts in the context of the system update management (such as Microsoft SMS).
  • Encourage users to log in with accounts that have limited privileges so that a new device driver will not be able to be installed.
  • Look for names such as DNSCHAN, DNSChanger, Puper, RSPLUG or Trojan.Flush.* in the antivirus logs.
  • Use more secure configuration distribution protocols (alternatives to DHCP). There are systems that can be set up to require some forms of authentication before a client computer can receive the network configuration information.
  • Last, do not execute applications that do not come from a trusted source (it is a usual recommendation). Note that all DNSChanger variants are Trojans, in other words, the malicious code can only be installed after a user’s action.

 

Fore more information

 

Previous Previous Next Next Print Print

© 2024 Cert-IST