A unique ‘fileless’ bot attacks news site visitors

In early March, we received a report from an independent researcher on mass infections of computers on a corporate network after users had visited a number of well-known Russian online information resources. The symptoms were the same in each case: the computer sent several network requests to third-party resources, after which, in some cases, several encrypted files appeared on the hard drive.

The infection mechanism used by this malware proved to be very difficult to identify. The websites used to spread the infection are hosted on different platforms and have different architectures. None of our attempts to reproduce the infections were successful. A quick analysis of KSN statistics that might help to identify the connection between compromised resources and the malicious code being distributed did not yield any results, either. However, we did manage to find something that the news sites had in common.

Infection sources

For purposes of analysis, we selected two information resources which we knew had been used to distribute the malware— http://www.ria.ru/ (a major Russian news agency) and http://www.gazeta.ru/ (a popular online newspaper). Regularly saving the contents of these resources did not identify any third-party JS scripts occasionally showing up, iframe tags, 302 errors or any other formal attributes indicating that the resources have been compromised. The only thing they had in common was that they both used AdFox advertisement management system codes, through which teaser exchange was arranged.

 

The code on the main page of RIA.ru that is used to download additional content from AdFox.ru

We discovered that the malware is loaded via the teasers on AdFox.ru.

Here is how the infection was carried out. A JS script for one of the teasers loaded on the site included an iframe that redirected the user to a malicious site in the .EU domain containing a Java exploit.

 

The contents of an infected and a clean JS script

Analysis of the exploit’s JAR file demonstrated that it exploits a Java vulnerability (CVE-2011-3544). Cybercriminals have been exploiting this vulnerability since November in attacks targeting both MacOS and Windows users. Exploits for this vulnerability are currently among the most effective and are included in popular exploit packs.

However, the exploit used in this case was unique and had not been included in any exploit packs: the cybercriminals used their own payload in the attack.

 

Part of the JAR file’s payload

‘Fileless’ malware

As a rule, the operation of such an exploit involves saving a malicious file, usually a dropper or downloader, on the hard drive. However, in this case we were in for a surprise: no new files appeared on the hard drive.

After seizing all necessary privileges on the victim computer, the exploit does not install malware on the hard drive using Java. Instead, it uses its payload to inject an encrypted dll from the web directly into the memory of the javaw.exe process. The address from which the library is to be downloaded is encrypted in the iframe that was included in the JS script downloaded from AdFox.ru:

<applet code="Applet.class" archive="/0GLMFss"><param name="cookie" value="j::eHff8dCis:ys4iNfnUWP7yy"></applet>

 

A new malicious RWE section in the JAVAW.exe process

After successfully injecting and launching the malicious code (dll), Java begins to send requests to third-party resources, which look like Google search requests: “search?hl=us&source=hp&q=%s&aq=f&aqi=&aql=&oq=”…

These requests include data on the browsing history taken from the user’s browser, as well as a range of additional technical information about the infected system.

In other words, what we are dealing with here is a very rare kind of malware – the so-called ‘fileless’ malicious programs that do not exist as files on the hard drive but operate only in the infected computer’s RAM. The best known examples of such threats are the CodeRed and Slammer worms, which caused mass outbreaks at the beginning of the last decade.

This kind of malware only remains operational until the operating system is restarted, but in this case this is not a critical issue for the Trojan’s authors.

One reason for this is that the ‘fileless’ malware operates as a bot: after sending a series of requests to the command server and receiving replies, the exploit uses several different methods to disable UAC (User Account Control). After this the bot can install the Lurk Trojan on the infected machine. It is worth noting that the decision as to whether to install Lurk on the system is made on the cybercriminals’ server.

The second reason is that the chances of the user returning to the infected website after rebooting the system are high. This would result in re-infection, with the bot returning to the victim computer’s RAM.

Because no file is written to the hard drive, it becomes much harder to detect the problem using antivirus software. If the exploit is not detected, the bot can be successfully loaded into RAM, becoming virtually invisible.

Lurk

The Trojan-Spy.Win32.Lurk malware can be installed either using commands “regsrv32” and “netsh add helper dll” or via the ShellIconOverlayIdentifiers branch of the system registry. Lurk installs its additional modules as encrypted dll files.

 

Part of the Lurk code responsible for downloading additional modules

The analysis of the additional modules used by Lurk has provided an insight into the malicious program’s functionality: it steals users’ sensitive data to gain access to online banking services at several large Russian banks. Kaspersky Lab first detected this malware in July 2011. Based on our analysis of the protocol used by Lurk to communicate to the command servers, we determined that over a period of several months, these servers processed requests from up to 300,000 infected machines.

Reasons behind the incident

After sorting out the technical side of the problem, we notified the Adfox administration of the incident. They promptly took action, resulting in the detection and removal of the malware from the infected banner.

In the course of the investigation it was determined that the cybercriminals had used the account of an Adfox customer to change the code of news headline banners by adding an iframe redirecting users to the malicious site.

After modifying code in one of the banners, they were able to attack not only users on one news site, but also visitors to other resources carrying this banner. As a result, there could be tens of thousands of users who were attacked. At the same time, banners of other AdFox clients did not contain the malicious code.

Conclusion

This is a unique attack, because the cybercriminals used their own PE file downloader (payload) that can work without creating malicious files in the infected system, operating entirely inside a trusted Java process.

Using a teaser network is one of the most effective methods that attackers can used to install malicious code, since it results in a large number of popular resources linking to the code.

This attack targeted Russian users. However, we cannot rule out that the same exploit and the same fileless bot will be used against people in other parts of the world: they can be distributed via similar banner or teaser networks in other countries. It is likely that other malware, not just Trojan-Spy.Win32.Lurk will be used in the process.

As regards protection against this threat, we strongly suggest that all users install a patch that closes the CVE-2011-3544 vulnerability in Java. This is currently the only reliable way to prevent an infection. As we mentioned above, exploits for CVE-2011-3544 are the most effective there are and can be used to install a variety of malicious programs.

In addition, a security solution that includes web antivirus features should be used at all times. We also recommend that Kaspersky Lab users enable the Geo Filter feature, which provides manual control of the browser’s access to resources in different geographical domains, and block connections to sites in the .eu zone unless accessing them is essential. We have been detecting numerous malicious resources in this domain, including those described above, as well as servers used to distribute the Hlux Trojan, which we discussed in a recent post.

 

PS. Our heartfelt thanks go to the independent researcher, who wishes to remain anonymous, for invaluable help in preparing this publication.

DNSChanger - Cleaning Up 4 Million Infected Hosts

The internet is full of infected hosts. Let's just make a conservative guesstimate that there are more than 40 million infected victim hosts and malware serving "hosts" connected to the internet at any one time, including both traditional computing devices, network devices and smartphones. That's a lot of resources churning out cybercrime, viruses, worms, exploits, spyware. There have been many suggestions about how to go about cleaning up the mess, the challenges are complex, and current cleanups taking longer than expected.

Mass exploitation continues to be an ongoing effort for cybercriminals and a major problem - it's partly a numbers game for them. Although exploiting and infecting millions of machines may attract LE attention at some point, it's a risk some are willing to take in pursuit of millions of dollars that could probably be better made elsewhere with the same effort. So take, for example, the current DNSChanger cleanup. Here is a traditional profit motivated 4 million PC and Mac node malware case worked by the Fbi, finishing with a successful set of arrests and server takedown.

When DNSChanger was "taken down", only the "Rove Digital" DNS servers were handled, even though the statement read: "Today, with the flip of a switch, the FBI and our partners dismantled the Rove criminal enterprise". While victims might not commonly be seen as a part of an enterprise, leaving the 4 million DNSChanger infected hosts connected to the internet, with many failing to download Windows updates, may leave open a window of opportunity for other cybercriminals. And even though past botnets have been partly handled by communicating with the malicious bot code itself from usurped C2 servers, those steps are being avoided again. Bredolab (approximately 3 million or more infected hosts), Coreflood/Afcore (infected over 2 million hosts) are probably the two largest recent examples of LE sending down commands to help effectively remediate botnets. Without this type of intervention, how isthe cleanup going four months later?

Not all that well, it would seem. Approximately a half million hosts of the 4 million were infected in the US and they are not being cleaned up as planned. Meanwhile, there is a looming early March deadline for the DNSChanger Working Group to remove their Fbi/ISC DNS server replacements for the Estonian cybercrime managed malicious DNS servers. One ISP alone requested more time for the remaining 50k infected hosts on their networks. And the Fbi foresees enough of a problem that they requested the judge setting the original March 8th cutoff date to move the DNS server cutoff to July 9th, effectively doubling the amount of time allowed to clean up DNSChanger infected hosts.

A variety of voices claim that around half of the Fortune 500, hundreds of businesses, and many government agencies all maintain systems that would simply not be able to resolve domain names and become unusable if the replacement DNS servers were taken down in early March.

Which leaves the dangling question, is this extension really all that great an idea? Rick Wanner over at the SANS desk questions its value..."Frankly I am on the fence about whether or not an extension is a good idea. I certainly don't want to entertain the possibility that the companies that I do business with, and entrust my personal information to, may take more than 4 months to cleanup a known malware infection."

If places of business and government organizations can’t clean up their systems, what is being done to remediate residential systems? Well, DNS requests to the replacement servers are being monitored and the source IPs logged. These source IPs are distributed to the ISPs owning those IP addresses. From there, the ISPs are supposed to be able to track down the customers using the originating IP address and provide notification, who will then perform cleanup. The Comcast notification here:

As you see, the link directs users to an urgent warning that immediate action is required. The individual can choose to attempt to clean it themselves for free, or they can choose a $100+ service to help them clean it up:

This tool is supposed to help users identify DNSChanger and remove it for free. Well, it does identify and remove variants of DNSChanger. On my system, it also annoyingly identified ImmunityDebugger, a fairly well-known debugger, as a potentially malicious software package to remove. It seems that this Eraser puts together a number of factors when rating the legitimacy of a given piece of software on a system, including "load points" it enumerates on the system and reputation scoring, and notes that changes made with the tool can be rolled back. In a way, this can be helpful for folks that know what they are doing and what they can ignore. It will help clean up more infections than just DNSChanger too as more of a general cleanup tool, which is a good thing. Maybe it doesn't seem to be for everyone, but it's great to see the ISP providing tools for cleaning up, because they are the contact point and the tools exist. It would be great to see universal tools and more specialized tools suggested to remove DNSChnager and other infections, giving choice to customers as to what company he or she entrusts with a remediation. For example, from our side we offer TDSSKiller and our scanning tools can be downloaded with full functionality as trials.

For more complex infections related to DNSChanger, the best toolset out there probably should include TDSSKiller. Continuously updated, run it and it cleans up the latest versions of Tdss among other rootkits. Tdss is a platform of its own that has been used to distribute DNSChanger alongside other malware known to disable updates and kill AV on systems, all making cleanup extremely difficult. From there, folks can use other scanners or tools to finish DNSChanger cleanup. Any way you look at it, underestimations and misunderstanding of infections, cleanup, and the need for effective anti-malware solutions are glaringly apparent because of Operation GhostClick remediation efforts.