DNSChanger Trojans v4.0

Earlier today SANS posted an excellent blog on a recent variant of a DNSChanger Trojan. There are some significant implications to this threat, but before I go into those, here’s a brief rundown of the main DNS-changing Trojan tactics used to date:

1. Modify Windows Hosts file to map specific domain names to specific IP addresses (McAfee classifies these Trojans as QHOSTS Trojans, more of a precursor to DNSChangers
2. Modify Windows registry settings to reference specific (rogue) DNS servers [DNSChanger.f]
3. Create a scheduled task under Mac OS X to reference specific (rogue) DNS servers [OSX/Puper]
4. Exploit cross-site request forgery vulnerabilities in routers to overwrite the DNS server configuration offered to local area network clients [DNSChanger.f]

We’ve now seen a new tactic, which has the potential of impacting most devices on the local network–independent of the operating system or device (Windows, Linux, Internet-capable MP3 players,  digital picture frames, refrigerators, you name it). The tactic involves serving the rogue DNS server configuration over DHCP, the protocol responsible for distributing dynamic IP addresses, as well as other information, including DNS settings.

Here’s a scenario:

• Jill is using the free WiFi access point at her favorite coffee shop from her infected Windows laptop.
• Steve sits down at the next able and fires up his laptop, which requests an IP address over the wireless local area network.
• Jill’s PC injects a DHCP offer command to instruct Steve’s computer to route all DNS requests through a rogue DNS server.
• Steve fires up his web browser and navigates to his favorite 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 same applies to any local area network (LAN) where multiple system connect via DHCP.

This is significant for several reasons:

1. 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.
2. Systems that are not infected with the malware can still have the payload of communicating with the rogue DNS servers delivered to them. This is achieved without exploiting any security vulnerability.
3. Locating a poisoned system on a sizable network is often a difficult task.
4. Noninfected systems can alter between using approved DNS settings and rogue settings based on an infected system being on the LAN, and a random chance that the infected system will be able to “poison” the DCHP offer.

For those interested in the details, this DNSChanger variant drops the legitimate ArcNet NDIS Protocol Driver in the drivers directory:

• %WinDir%\system32\drivers\ndisprot.sys

The Trojan uses this driver to inject DHCP Offer packets containing the rogue DNS server IPs.

Variants using this functionality are not known to be widespread at this point, though even a single infected system could potentially impact hundreds of other systems on the LAN. Though it’s awkward to check, users could examine their DNS settings to see if they have been impacted. For example, type the following from a Windows command prompt:

ipconfig /all

For insight into some of what the DNSChanger gang is after, see this post.