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.
SOURCE : http://www.securelist.com/en/blog/687/A_unique_fileless_bot_attacks_news_site_visitors
