The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1
Latest posting
By rating
By popularity

Join our blog

You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.


The more people switch to 64-bit platforms, the more 64-bit malware appears. We have been following this process for several years now. The more people work on 64-bit platforms, the more 64-bit applications that are developed as well. Sometimes these include some very specific applications, for example, banking applications.... If someone wants to hack into an application like this and steal information, the best tool for that would also be a 64-bit agent. And whats the most notorious banking malware? ZeuS, of course the trendsetter for the majority of todays banking malware. Its web injects have become a fundamental must-have feature of almost every banking malware family. And it was only a matter of time until a 64-bit version of ZeuS appeared but we didnt expect it to happen quite so soon.

Thats because cybercriminals dont actually need a 64-bit version. ZeuS is mostly intended to intercept data passing through browsers, and modify that data allowing the operator to steal information related to online banking, to wire transactions or to cover his tracks. But nowadays people still use 32-bit browsers even on 64-bit operating systems. So, 32-bit versions of ZeuS have been sufficient to keep the thieves satisfied with their earnings.

Then, out of the blue, we spotted a 32-bit ZeuS sample maintaining a 64-bit version inside. And its turned out that this 64-bit version has already been recorded being present in the wild at least since June, 2013 and compilation date specified in the sample is April 29, 2013! Moreover, this ZeuS version works via Tor. The initial 32-bit sample injects malicious code into target processes. If the target process belongs to a 64-bit application, ZeuS injects its 64-bit version into the process; otherwise, it pushes the 32-bit version. We ran tests to see how the 64-bit ZeuS works inside a 64-bit Internet Explorer and it demonstrated the usual ZeuS functionality: in any case, the web injects functioned as usual.


Two days ago FireEye reported that the recent CVE-2013-3906 exploit has begun to be used by new threat actors other than the original ones. The new infected documents share similarities with previously detected exploits but carry a different payload. This time these exploits are being used to deliver Taidoor and PlugX backdoors, according to FireEye.

At Kaspersky Lab we have also detected that yet another APT group has just started spreading malicious MS Word documents exploiting CVE-2013-3906. This APT actor is the Winnti group, which we described in detail here. They have sent spear-phishing emails with an attached document containing the exploit. As usual the Winnti perpetrators are trying to use this technique to deliver 1st stage malware - PlugX.

We became aware of an attack against one gaming company which constantly undergoes attacks from the Winnti group. The MS Word document containing the exploit shows the same TIFF picture - 7dd89c99ed7cec0ebc4afa8cd010f1f1 that triggers the exploitation of the vulnerability, as in the Hangover attacks. If the exploitation is successful, the PlugX backdoor is downloaded from a remote URL:


For several months, we have been monitoring an ongoing cyber-espionage campaign against South Korean think tanks. There are multiple reasons why this campaign is extraordinary in its execution and logistics. It all started one day when we encountered a somewhat unsophisticated spy program that communicated with its master via a public e-mail server. This approach is rather inherent to many amateur virus-writers.

However, there were a few things that attracted our attention:

  • The public e-mail server in question was Bulgarian - mail.bg.
  • The compilation path string contained Korean hieroglyphs.

The complete path found in the malware presents some of the Korean strings:


The rsh word, by all appearances, means a shortening of Remote Shell and the Korean words can be translated in English as attack and completion, i.e.:


We managed to identify several targets. Here are some of the organizations that the attackers were interested in targeting:

The Sejong Institute
The Sejong Institute is a non-profit private organization for public interest and a leading think tank in South Korea, conducting research on national security strategy, unification strategy, regional issues, and international political economy.

While researching PlugX propagation with the use of Java exploits we stumbled upon one compromised site that hosted and pushed a malicious Java applet exploiting the CVE 2013-0422 vulnerability. The very malicious Java application was detected heuristically with generic verdict for that vulnerability and it would have been hardly possible to spot that particular site between tons of other places where various malicious Java applications were detected with that generic verdict. But it was a very specific search conducted back then and this site appeared in statistics among not so many search results. Well, to be honest it was a false positive in terms of search criteria, but in this case it was a lucky mistake.

The infectious website was an Internet resource named - minjok.com and it turned out to be a news site in Korean and English languages covering mostly political events around the Korean peninsula. We notified an editor of this site about the compromise and although he has not responded, the site got closed after a while.

This is how minjok.com is described at http://www.northkoreatech.org/the-north-korean-website-list/minjok-tongshin/:

Description of minjok.com

Research|Winnti returns with PlugX

Dmitry Tarakanov
Kaspersky Lab Expert
Posted April 15, 12:30  GMT

Continuing our investigation into Winnti, in this post we describe how the group tried to re-infect a certain gaming company and what malware they used. After discovering that the company-s servers were infected, we began to clean them up in conjunction with the company-s system administrator, removing malicious files from the corporate network. This took a while because it was not clear at first exactly how the cybercriminals had penetrated the corporate network; we couldn-t find a way to completely stop attacks penetrating the network and malicious files kept appearing. An analysis performed by the gaming company itself led us to the conclusion that the infection started after establishing working contacts with a South Korean gaming company. This was also confirmed by our research: as we wrote before, the Winnti group is most active in East Asia and we identified 14 infected gaming companies in South Korea.

In the course of our efforts to remove the infection, the gaming company sent us suspicious files that were appearing on their computers. Many of these files were samples of Winnti malware. As soon as information about the malicious files was added to our antivirus databases, our products were used to remove Winnti malware from the gaming company-s corporate network. However, the attackers reacted very rapidly: new malware samples mysteriously appeared on computers from which the infection had been completely removed the previous day. Eventually, though, our efforts proved successful and further access to the gaming company-s computers was denied to the attackers.

However, just as we expected, it was too early to celebrate. Exactly one month after the gaming company-s network had been cleaned, the Winnti group returned. The system administrator sent us suspicious files, which had been attached to messages sent to company employees. This was run-of-the-mill spearphishing: the attackers introduced themselves as computer game developers and pretended to be looking for opportunities related to working with large publishers.


During our research on the Winnti group we discovered a considerable amount of Winnti samples targeting different gaming companies. Using this sophisticated malicious program cybercriminals gained remote access to infected workstations and then carried out further activity manually.

Naturally, we were keen to find out how the malicious libraries spread across a local network. To do so, we tracked the attackers- activity on an infected computer.

1st attempt: virtual machine #1

At the beginning of the investigation we ran the malicious programs on a virtual machine, which worked fairly well - we even spotted some cybercriminal activity. But they quickly realized it wasn-t a computer they wanted to net. Once that was the case, the attackers- servers stopped responding to requests from bots working on virtual machines.

This is what we managed to learn at this stage of our monitoring.

First of all, the perpetrators looked at what was happening on the victim-s desktop. After that they enabled the remote command line and used it to browse the root folder of the current disk, searched for the file winmm.dll, and checked the operating system version. The ListFileManager plugin then came into play. It works with the file system and the attackers used it to browse the folders C:\Windows and C:\Work. Then they tried to restart the computer, but made a mistake in the parameters of the ?shutdown command, having typed ?shutdown /t /r 1 (the computer should have been restarted in 1 second), but after a while they shut the computer down completely with the use of the correct command ?shutdown /s /t 1.

Research|PlugX is becoming mature

Dmitry Tarakanov
Kaspersky Lab Expert
Posted November 27, 09:19  GMT

Recently, a new Remote Administration Tool has been discovered that started appearing here and there in targeted attacks. This tool is PlugX. Researchers have even tracked someone suspected of creating that malware one of the members of the Chinese hacking group NCPH, which is allegedly in the service of PLA. Among others, this group has been accused of attacking high-profile US organizations.

But PlugX has been detected in targeted attacks not only against military, government or political organizations, but also against more or less ordinary companies. And this is quite a strange situation. No matter whether penetrators have been hired or they work for themselves, if they tend to attack serious organizations/persons how come weve also seen very different types of targets - absolutely peaceful companies hit by the same group? We could not locate any site where this tool (or rather its kit or builder) has been offered for use, so we cant confirm that PlugX has been shared between cybercriminal communities or other potential attackers (although we cant deny that possibility).

On our side we have detected attacks using this infamous tool against a company which is far from military, politics, critical infrastructure and so on. This company has been bombarded for a month with spear-phishing emails with attachments containing exactly this PlugX program. The first samples were of the same type that had been already described, i.e. some sort of debug version with plenty of logging of potential errors in a bug.log file. But several days ago attackers sent a bunch of emails with a new version of PlugX. This version differs from the previous one in terms of logging activity. The virus writer has removed almost all the lines of code for processing potential errors that were present in the old version. The following awful picture represents where the logging function has been invoked in the old version of PlugX code:

Incidents|Shamoon The Wiper: further details (Part II)

Dmitry Tarakanov
Kaspersky Lab Expert
Posted September 11, 14:30  GMT
Tags: Targeted Attacks, Wiper

There have been persistent media reports that the Shamoon wiper malware we previously covered is linked to attacks against Saudi Aramco.

The hardcoded date in the body of destructor matches exactly the declaration by a hacker group about the date and time when the Saudi Aramco company would had been hit but we still cannot definitively confirm that Shamoon was to blame for those attacks.

And just about two weeks later, another energy company in the Middle East (RasGas) fell victim to another malware attack and the media has logically asked questions about whether Shamoon was responsible.

We leave the speculation up to others and concentrate strictly on sharing technical details. This is the continuation of our investigation into Shamoon:


The main Shamoon module has a resource PKCS7:113 that maintains an executable which is saved to disk as %WINDIR%\System32\NETINIT.EXE and this program poses a module to communicate with CNC. This program waits for parameters to be run with. The author was not too creative and coded a handling of just two argument values which can be ?0 or ?1.

If ?0, the program takes a second argument and treats it as a data to be passed to CNC. With this argument value, the malware connects to CNC just once and stops executing. We have not located any place in the Shamoon code where netinit.exe would be run with argument ?0.

But as you would recall, we did locate the place where netinit.exe is launched with a command line ?netinit.exe 1. The program then enters into a loop until another destructive module creates a file %WINDIR%\ inf\netfb318.pnf signaling that the time has come to wipe data and kill the operating system. While netinit.exe waits for that file it regularly connects to CNC to report itself and receiving commands.

Incidents|Shamoon the Wiper in details

Dmitry Tarakanov
Kaspersky Lab Expert
Posted August 21, 22:30  GMT
Tags: Targeted Attacks, Wiper

We continue to analyse the Shamoon malware. This blog contains information about the internals of the malicious samples involved in this campaign.

Samples nesting

The main executable (dropper) includes 3 resources, each maintains a ciphered program. The cipher is pretty simple v xor by dword. This was mentioned in our first blog-post.

Resource PKCS12:112 maintains an encoded executable, xor-ed with key value 0xFB5D7F25. It is saved to disk using a name taken from a hardcoded list in the %WINDIR%\System32 folder during the dropper execution. In turn, this module maintains resource READONE :101 (xor key: 0xF052AF15), a driver decoded and saved to disk as %WINDIR%\System32\Drivers\DRDISK.SYS.

Resource PKCS7:113 maintains an executable, xor-ed with key 0x00BAD417 and saved to disk as %WINDIR%\System32\NETINIT.EXE during dropper execution.

Resource X509:116 maintains an AMD64 version of main the Shamoon executable (dropper) xor-ed with key 0xBB1AC25C. This in turn contains almost the same set of resources as its Win32 counterpart: PKCS12:112 v this file is the AMD64 version of the 1st executable dropped, with an AMD64 version of a driver, and PKCS7:113 v the AMD64 version of NETINIT.EXE. So, 112 and 113 resources have the same xor keys in x86 and AMD64 versions of the dropper, but the drivers- keys are different: the AMD64 version is xored by 0x10CAFFA0 value when x86 is ciphered with 0xF052AF15. This picture is worth a thousand words and sums up these on disk files:

Shamoon samples nesting

So, the Shamoon main executable has been coded to work in 3 modes:

1. the sample is run as a typical program in a 32-bit OS (argument-dependent)
2. the sample is run in a 64-bit OS
3. the sample is run as a service in a 32-bit OS

64-bit environment

First, the program checks if it has been launched in a 64-bit operating system. If so, it drops the AMD64 version of the main executable by decrypting the X509:116 resource and saving the decrypted data to disk as %WINDIR%\System32\trksrv.exe. Then it creates and starts the service ?TrkSvr using the following command line:

%WINDIR%\System32\cmd.exe /c "ping -n 30 >nul && sc config TrkSvr binpath= system32\trksrv.exe && ping -n 10 >nul && sc start TrkSvr "

This branch comes to an end and the program exits.

Let-s take a look what the program does if it runs as a typical program in a 32-bit operating system.

Research|Big Brother

Dmitry Tarakanov
Kaspersky Lab Expert
Posted May 21, 14:10  GMT
Tags: SpyEye

It seems that development of the main module of SpyEye stopped with last autumn’s version 1.3.48 – and this is now the dominant strain of SpyEye malware.

SpyEye distribution by versions for the period since 1 January 2012*
* Others (7%) includes: 1.2.50, 1.2.58, 1.2.71, 1.2.80, 1.2.82, 1.2.93, 1.3.5, 1.3.9, 1.3.25, 1.3.26, 1.3.30, 1.3.32, 1.3.37, 1.3.41, 1.3.44.

But just because the authors are not developing this platform further, it doesn’t mean that SpyEye is no longer getting new functions. The core code allows anyone to create and attach their own plugins (DLL libraries). I’ve been analyzing SpyEye samples since the start of the year, and I’ve counted 35 different plugins. Below you can see a table with those plugins and the corresponding number of samples in which they were included: