Tourist Periscope will manage tourist information on the We

S21sec labs is leading the project Tourist Periscope with the aim of developing the technological solution that will help the tourist sector to detect the different market opportunities and to reduce the strategic decision taking risk by predicting tourist trends.

The Internet is a source of innumerable amounts of information, which often represents a threat for a company as it cannot manage this volume of information or it could mean a business opportunity hard to detect among so much data circulating through the Net.

The exponential increase of information in the tourist sector is translated into serious difficulties for tourist companies, institutions and administrations when managing, identifying and optimising the search for contents of interest for their business.

For this reason, S21sec and thanks to its experience in the development of open-source information classification, indexing and information search technologies, will create the application Tourist Periscope in its R&D centre in security S21sec labs and in cooperation with agents specialised in the tourist sector, from both the academic and corporate environments. This R&D project is framed within the INNPACTO projects of the Ministry of Economy and Competitiveness. The new IT platform will be oriented at the tourist sector and will be able to carry out an efficient information management and rationalisation according to the profile of the client and the purpose that is to be achieved. This new tool is able to carry out analysis of the tourist environment in a customised way and integrated with social networks, generating a Tourist Intelligence unit.

The purpose of Tourist Periscope is to provide companies in the tourist sector with a new user-friendly technological solution to detect the different market opportunities and to reduce the strategic decision taking risk by being ahead of tourist behaviour.

S21sec Marketing Department

New SpyEye Campaign with mobile complement

More than a year ago we saw for the first time how ZeuS had incorporated a mobile component in an attempt to steal the SMS sent by the banks while making a transfer. Later, SpyEye incorporated the same technique.

Recently, we have seen a new campaign affecting Spanish banks, which urges the user to install a component if their phone is Android. While the first samples came from Symbian and BlackBerry, later versions incorporated Android among its objectives. The widespread use of this platform, along with the ease of developing applications for it, makes it one of the favourite objectives of malware creators.

Infection of a mobile device is not a trivial task, so the user must be tricked, through social engineering, into infecting themselves. For this reason, it is important to understand the risks, as a user who is unaware of the threat that their mobile can be infected, is completely vulnerable to this attack.

In the case in hand, upon visiting the banking entity’s website, an infected computer will try to convince the user to install an application on the mobile phone, making them believe that they are installing a program to secure communications.

Image 1: The user is asked for their phone operating system and phone number (Spanish)

Then comes the verification of the installation, asking for a activation code that the mobile displays once the application is installed.

Image 2: The user confirms an activation code received on their mobile (Spanish)

Finally, a successful installation message is displayed to the user.

Image 3: Application installed successfully – you are now protected (Spanish)

If the mobile is an Android phone, SpyEye simply informs the user that they do not require any further security.

Image 4: Your phone does not require any further security (Spanish)

Despite the fact that many times we have heard the term "SpyEye for Android" incorrectly used, we must be clear that the component that infects mobiles is not a version of SpyEye, as it is not capable of intercepting on-line banking navigation or anything similar. This is a very simple application, able to forward received SMSs to an external server using a simple GET request with the data as parameters. It is a merely a complement, totally unrelated to the malware that infects the computer and it could be used interchangeably with any banking trojan.

As an example of the application’s simplicity, the encryption of the string containing the URI of the dropzone consists solely of swapping the values "=", "-" and "q", as can be seen in the following example, very similar to the original URI.

This means that we are facing a new infection campaign which, from a technical point of view, really adds nothing new, but we must stress that people need to understand this kind of threat to avoid falling into the trap.

Mikel Gastesi

S21sec e-crime

Murofet: Changing to zlib

Time passes and in the world of malware new threats continue to emerge, but the established threats still continue to evolve and everything points to this continuing.

In this blog, we will once again talk about Zeus and, in particular, the version known as Murofet.

Around June, we discussed the different branches of Zeus. We have seen how the developers have implemented new functionality such as P2P and domain name generation in what is known as Murofet 2.0.

In one of the latest samples received, we saw how something didn’t quite fit with the usual behaviour. This was investigated in greater depth and we have discovered that certain sections, instead of being compressed with UCL, have changed to being compressed with zlib.

Image 1: Use of zlib v 1.2.5

Zeus has evolved considerably. Gone is the time when each botnet did not have its own key and encryption consisted of only a simple xor and little more. Recent developments show the creators increasing maturity. They have stopped trying to reinvent the wheel and have been incorporating already existing cryptographic algorithms, much more robust than their predecessors, something completely logical.

If we focus on the gang behind Murofet, in particular, we can see an ongoing development, distinguishing itself ever more from the official version. The changes that have been introduced, step by step, both at the internal level (in terms of the modification of characteristics in the configuration file’s encryption) and the added characteristics mentioned previously, indicate an in-depth knowledge of the subject.

In addition, we must not forget the detail that the first variant was seen before the source code leaked, which makes it clear that the group behind it have very clear objectives.

We will keep playing.

Jozsef Gegeny and Mikel Gastesi

S21sec e-crime

Murofet v2.0 (ZeuS P2P)

Following on from the previous post about the ZeuS "ACH transaction canceled" distribution campaign, we now turn to look at the distributed binary.

This is version 2.0 of the Zeus variant known as Murofet. It has come to be named ZeuS P2P, due to some of its characteristics, which make use of this technique.

Of all recent versions, this is most evolved with many modifications from the original version. It is rumoured that this version could come from original author of ZeuS, as the modifications require a deep understanding of the original work.

The relationship to the original Murofet can be clearly seen in the configuration files. They are at the same time different from those of the original ZeuS and yet similar to each other. They have new labels in some sections and an easily detectable feature, the ERCP delimiter, as shown in the following image:


In this variant the trojan uses a P2P structure to obtain the configuration file, which is an interesting modification. To do this, it uses a few incorporated IPs, firstly, and attempts to communicate with them via UDP:


Once in communication with the bots belonging to the P2P network, if a newer version is detected, this will be downloaded, using TCP and its own protocol:


If P2P communication fails, it changes to use domain name generation, as the first Murofet version did.

The storage route, both for the binary and the registry paths, are similar to previous versions, but in this version the configuration file is stored with only RC4 encryption without the XOR layer (also known as VisualEncrypt; logically, because it does not provide any security).

Similarly, there is evidence that the trojan deletes the RC4 key from memory after each use, in a clear attempt to prevent it from being detected.

Finally, the C&C server shown in the configuration file appears to be false, in a clear attempt to mislead and delay any analysis.

In summary, this is a modified version of ZeuS, with very advanced characteristics and changes aimed at protecting itself from automatic analysis of the binary and self preservation against the destruction of the network infrastructure, but without any notable functional changes.


Jozsef Gegeny & Santiago Vicente
S21sec e-crime

New ZeuS distribution campaign: ACH transaction canceled

Our team has detected a ZeuS trojan distribution by email campaign that has been running for some days. The malicious emails include a link to a supposed report about a cancelled transaction, which is actually an HTML page that loads Javascript code into the victim’s browser. This code tries to exploit different vulnerabilities in Java, Flash and PDF to install ZeuS 2.0 on the system. This is one of the latest versions of ZeuS which uses P2P as part of its infrastructure.

The subject of the emails detected so far is “ACH transaction canceled” and in the body of the mail there is information about a supposed transaction that has been cancelled. If the victim wants further information then they have to visit a link that contains a report about the transaction:

For a few seconds the victim sees a screen indicating that they must wait. Meanwhile 4 scripts, stored on different domains are loaded into user’s browser. They are little more than simple redirections towards the site where the code (that will attempt to perform the exploitation) resides.

There are currently three different domains hosting the malicious content, created on the 2nd, 6th and 9th of November and they resolve to the same IP, located in Russia. This malicious content is obfuscated Javascript code that belongs to the BlackHole exploit kit.

Once the code is “de-obfuscated”, several functions can be seen that attempt to exploit vulnerabilities in various plugins installed in the victim’s browser:

• Java (CVE-2010-3552, CVE-2010-0886)

• Flash

• PDF (CVE-2010-0188, CVE-2009-0927, CVE-2009-4324, CVE-2008-2992, CVE-2007-5659)

• Media Player

They all use the same (or very similar) shellcode, whose objective is to download and execute the malicious code in question. In the case of the analyzed shellcode, besides executing the binary, stored on the system with a .dll extension, it launches the application Regsvr32 with the parameter -s (silent mode) to try to register the DLL in the system, although the infection has already taken place (the first call to WinExec in the image below).

As mentioned before, the downloaded binary is a ZeuS (P2P version). In the second part of this post we are giving more details (behaviour, affected entities, etc.). Meanwhile update your applications and don’t click on any suspicious links.

Jose Miguel Esparza
S21sec e-crime
(Blog / Twitter)

DUQU: A new threat

General Information

According to the report presented by Symantec, this trojan was detected for the first time on the 14th of October and later, on the 7th of September they found samples of the driver uploaded to VirusTotal.

According to Symantec, this could herald an attack similar to Stuxnet, written by the authors themselves or at least by programmers with access to the source code. However, this Trojan contains code related to industrial control systems.

The main objective of this new threat is to get information about ICS (industrial control systems) manufacturing companies, to help prepare for a subsequent attack against another company.

Duqu is, basically, a RAT (Remote Admin Trojan) that once introduced in a system, functions as a downloader for other trojans. It consists of a Driver, a DLL and a configuration file. These files are installed by another executable that, as yet, has not been identified. This installer registers the driver as a service that must be executed during system startup. Once executed, the driver injects the DLL into the process services.exe and if the injection is made correctly, the DLL extracts other components that are themselves then injected into other processes.

Duqu uses a valid digital certificate that was revoked on the 14th of October. It also waits 15 minutes before activating, once it arrives on a new machine (probably to avoid being detected in a sandbox). It is designed to automatically remove itself after 36 days.

McAfee’s theory is different. They argue that Duqu is being used to steal certificates from CAs in Europe, Africa and Asia, to afterwards be used for signing malicious code.

A Summary of Behaviour

The malware opens a back-door in the infected system which allows the attackers to obtain the following information from the compromised system:

• A list of the processes currently executing, the details of the user’s account and domain information.

• Names of the drives and related information, such as shared drives.

• Screen captures.

• Network information (routing tables, shared objects etc.).

• Key strokes (Keylogger).

• Names of all open windows.

• A list of shared resources.

• Exploration of files in all drives, including removable drives.

• List of all machines in the domain (through NetServerEnum)

• Name of the current module, PID, session ID, Windows directory, Temp directory.

• Operating System version, including if it is 64-bit or not.

• Information about network adapters.

• Information about local time, including the time zone.
  
  

Finally, the malware sends all the extracted information in encrypted form to a predetermined control panel (206.183.111.97), at the same time allowing the download of more malicious content from the control panel.

Possible clues for detection

Network traffic

Duqu uses the HTTP and HTTPS protocols to communicate with the control panel (C&C) found at the IP 206.183.111.97. This server is located in India, and has been disabled by the ISP (Web Werks WEBWRKS-PHLA1).

Communications within the range of IP addresses 206.53.48-61.* have been reported. It is highly recommended that communication device logs are reviewed for communications with this IP or any IP within the indicated range.

Detection on infected machines

Symantec has provided the following hashes and file names that have been identified as part of the threat.

MD5	Name	Purpose
0a566b1616c8afeef214372b1a0580c7	cmi4432.pnf	Principal DLL
94c4ef91dfcd0c53a96fdc387f9f9c35	netp192.pnf	Configuration File
e8d6b4dadb96ddb58775e6c85b10b6cc	cmi4464.PNF	Configuration File
b4ac366e24204d821376653279cbad86	netp191.PNF	Principal DLL
4541e850a228eb69fd0f0e924624b245	cmi4432.sys	Driver
0eecd17c6c215b358b7b872b74bfd800	jminet7.sys	Driver
9749d38ae9b9ddd81b50aad679ee87ec	[TEMP FILENAME]	Infostealer
c9a31ea148232b201fe7cb7db5c75f5e	Dropper

Duqu drivers have also been detected using the following file names which were not included in the Symantec report:

nfrd965.sys

adpu321.sys

The driver load is performed by adding some of the following keys to the Windows registry:

HKEY _ LOCAL _ MACHINE\SYSTEM\CurrentControlSet\Services\JmiNET3

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cmi4432

The detection of these entries in the registry of a Windows system is a clear indication that the machine is infected by Duqu.

S21sec e-crime team

Spitmo control panel

Last week, we analysed the behaviour of the mobile module used by Spyeye to redirect the victim’s SMSs to the attacker. We have now observed that a panel is used to receive the data collected by the malware, where all received messages are recovered in a simple and clear manner.

The panel that we have located is written entirely in Russian, and has only one button, to refresh the displayed data. It is very simple and its purpose is only to display the data quickly. It is important to mention that on the same host where the panel was housed there was also a SpyEye panel. The two did not appear to be related to each other, but the malware used that same URL as a dropzone.

Below you can see a simulated request, showing the behaviour of the panel and the information it would display:

The process would be as follows, the attacker performs a transfer using the banking data stolen from the user infected with the Spitmo. The moment that the Bank performs a check to see that the transaction is valid it sends an SMS to the mobile phone of the infected user. This SMS is intercepted by malware and forwarded to the panel. Almost instantly, the attacker is in possession of a valid token to carry out the transaction.

The process can be carried out without raising suspicion as it is completely transparent to the user.

All this raises doubts about how safe we are using a device that is continually interacting with the internet and over which we do not have full control of what it is doing in every moment.

Juan Carlos Montes
S21sec e-crime