Late last autumn, the detector described in one of our previous posts, Cognitive Research: Learning Detectors of Malicious Network Traffic, started to pick up a handful of infected hosts exhibiting a new kind of malware behavior. Initially, the number of infections were quite low, and nothing had drawn particular attention to the findings. Recently, this changed when we observed a significant uptake in the number of infections during the first few weeks of 2016. These infections were linked to a Trojan commonly known as DNSChanger. In our findings, this Trojan was delivered by a modular malware called Mamba. Our root cause analysis strongly suggests that the Trojan is spread by leveraging an established base of adware, unwanted applications, and ad injectors.
DNSChanger is a Trojan that changes the DNS settings on the infected host. The Trojan replaces the name servers with their own in order to direct HTTP and other requests from the host to a set of attacker-controlled servers that can intercept, inspect, and modify the host traffic. By using PowerShell, DNSChanger can execute commands on the infected host, which opens the door to remote access by the attackers. Persistence on the host is achieved by creating a scheduled task that runs daily.
When executed, the Trojan performs a connectivity check to the following servers:
Once connectivity is verified, the Trojan contacts one of the command-and-control (C&C) servers from the list embedded in the binary. Our samples contain the following domains:
The traffic to these servers is HTTP-based, where each request contains three parameters, each containing data encoded using a custom function that resembles Base64.
The first and second parameters are the most interesting, as they contain the information sent to the C&C servers. The first parameter contains system information, such as OS type, version of service pack currently installed, architecture, and privileges of the user. It also contains some specific information related to the malware, such as job ID, build number, registration date, and registration ID. The second parameter contains information about the DNS configuration used by the malware, such as three different sets of C&C domains, DNS server list, session ID, time interval for tasks, and timeouts. The decoded information can be seen in the image below:
As mentioned, the Trojan modifies the name server configurations on the host. Once the Trojan controls the name servers, the botmaster gains knowledge of all the sites visited by the user and can redirect the user to malicious servers without the user noticing the change.
Here is an example of how this Trojan can inject malicious code in the web sites visited by the user:
- The host makes a DNS request to the default name server asking for www.google-analytics.com.
- The malicious name server owned by the attacker responds with modified DNS records crafted for www.google-analytics.com.
- This directs the request to a server owned by the attacker instead of the legitimate server. It asks for www.google-analytics.com/analytics.js.
- The server controlled by the attacker returns its own modified version of the requested resource ‘analytics.js.’
- The resource obtained is loaded by the web browser which may then execute code sent by the attacker.
The Trojan is known to respond with its own version of resources for (at least) the following services:
An example of a modified ‘analytics.js’ file modified and served by DNS Changer is shown below:
Massive increase on the number of infections
Since last autumn, the population of this threat had not significantly differed from other Trojans with similar characteristics. This has changed quite dramatically: since the end of 2015, and especially in January 2016, we have observed a significant increase in the number of infected hosts. As observed by Cognitive Threat Analytics, the infection rate has grown from less than 10 hosts per million to more than 100 hosts per million in a span of weeks.
When adware becomes malware
DNSChanger has been delivered by another Trojan named Mamba. Mamba is a small, highly-modular, Python-based Trojan. All of the DNSChanger infections in last month’s surge included this Trojan as a delivery vehicle. Mamba has the ability to download other pieces of malicious software. It also has hidden and not commonly known capabilities, such as password stealing and exfiltration of information about the host and files from the host.
How did the original infection occur? An in-depth analysis of these infections failed to find any instances of Mamba or DNSChanger on hosts that were not already compromised by adware, PUAs, or ad-injector software. Specifically, applications like Adware Multiplug, System Healer, YouTube Downloader, and BrowseFox were the source of the second stage of infections. In some cases, other malware and adware types were delivered to the same hosts.
The Cisco Annual Security Report showed that 85% of the companies analyzed were compromised with some type of adware or PUA. The rapid growth of DNSChanger clearly illustrates persistent adware presence in company networks. Any adware infection can escalate to full-blown malware presence with direct and negative impact to the business.
- Neutralize Cyber Threats: Reversing Encrypted Callbacks of Trojan Dynamer
- Trojan.Zlob.Q Technical Details | Symantec