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

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.

1^st 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�.

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 we�ve 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 can�t confirm that PlugX has been shared between cybercriminal communities or other potential attackers (although we can�t 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:

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:

NETINIT.EXE

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.

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 127.0.0.1 >nul && sc config TrkSvr binpath= system32\trksrv.exe && ping -n 10 127.0.0.1 >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.

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:

Spam

On 20 March, we detected a spam campaign targeting passengers of US Airways. Almost the entire week cybercriminals were sending users the following email allegedly from US Airways:

There is a brief description of the check-in procedure and a confirmation code is provided for online reservation.

The criminals are obviously banking on any recipients flying on the flight mentioned in the email clicking on the link "Online reservation details".

Different emails contained different links — for example, we noticed the following domains: sulichat.hu, prakash.clanteam.com, panvelkarrealtors.com.

After clicking the link a series of redirects eventually leads to a domain hosting BlackHole Exploit Kit.

It has become clear that the creator of the banking Trojan SpyEye have added plugin support to their code. In this new design, these plugins can be used by third parties to add extra functions to the core bot. The plugins are DLLs stored in the bot’s configuration file. Among the core plugins created for SpyEye is customconnector. As its name implies, this supports the bot’s communications with the botnet C&C or its collector. The collector is a malicious server which receives data harvested from the victim’s computer; it can be distinct from the C&C server. Since the creator of SpyEye has outsourced the botnet’s links to the C&C server, different SpyEye operators can create unique protocols governing communications between bot and server. Naturally, these protocols could make it more difficult to track the activity of SpyEye botnets. Despite this, cybercriminals have not, so far, rushed to take advantage of this opportunity: SpyEye’s old protocol in the basic customconnector.dll is still in use. Even so, we have recently spotted some changes related to this plugin.

Each plugin has a configuration file attached. If the plugin is customconnector.dll, its configuration file will be customconnector.dll.cfg. Cybercriminals can insert plain-text fragments into this config file containing settings for the plugin’s functions. Since customconnector.dll is a communication plugin, its config file has always identified the botnet’s C&C servers. The botnet operator could easily switch to a new C&C server by introducing the new URLs into the text file and updating the configuration file in the botnet.

Here is a sample configuration file:

Figure 1. A configuration file for customconnector.dll

My colleague Jorge Mieres recently found a C&C server of a botnet based on a malicious program called Ice IX. As announced on several user forums, Ice IX is a bot created using the source code of ZeuS 2.0.8.9, which became publicly available in May. The author of the new bot says the program includes substantial enhancements, which should be interesting to those cybercriminals who steal money from users with the help of banking Trojans.

Figure 1. Description of the bot

As you can see in the screenshot, the description of the new program focuses on the enhancements allegedly introduced into the ZeuS original code. These included bypassing firewalls, bypassing proactive protection provided by security products, and protection from detection by trackers. The latter obviously refers to the ZeuS Tracker https://zeustracker.abuse.ch, which has been making cybercriminals’ life difficult. The program’s author charged $600 for a version of the bot with a hardwired URL that the bot must connect to after infection (i.e., the C&C address), and $1800 for a version without a hard-coded C&C address.

Unfortunately, we were unable to obtain a sample of the enhanced Ice IX version – possibly, because nobody had purchased it. Most likely, this version included a mechanism that was similar to that implemented in ZeuS beginning with version 2.1. Here is how it worked in ZeuS: the bot included a key that was used in combination with the current date to generate 1020 domain names each day. The bot searched through this entire list, trying to find its C&C server.

At the same time, someone has apparently tested the base version of the bot kit. These samples were analyzed for differences from the original ZeuS samples used as the basis for the Ice IX bot.