Español | English
rss facebook linkedin Twitter

NeoPocket: A new ATM malware

In 2013, during the late September the discovery of a new malware family - known as Ploutus - was announced. The malware was designed to attack a specific brand of ATM cash machines that were widely used in Mexico. Since then, the threat has evolve and new variants have been observed in different countries.

Recently we were requested to investigate a similar attack, where possibly ATM malware had been used to empty out cash machines. We expected it to be Ploutus, however there were several controversial facts. First of all, the compromised ATMs belonged to a different model than the one we saw in the case of Ploutus. Secondly, regarding to the obtained malware sample, there were no code similarities at the binary level when we compare it with Ploutus. Moreover, the newly identified malware was not even created in the same development environment as Ploutus had been.

After doing some research, we have come to a conclusion: we were dealing with an unclassified malware family, yet unknown to the public. We decided to internally refer to it as NeoPocket, borrowing the name from a character string spotted in the binary. In the following lines, we would like to give some technical insights about the internals of this new threat, NeoPocket.

Malware setup and activation

NeoPocket was developed in Visual Basic, and however we do not possess the original dropper or the installation media, most likely the infection vector origins from a USB drive and the attacker must have had physical access to the ATM  machines. There are other evidences that support the theory of the usage of an external drive, such as that the threat  accepts commands from an USB drive and it also always tests if the USB is  available on the infected system. It also checks whether it is being launched from the root directory, only in this case it would perform installation operations.

If executed from the root directory of any drive, it popups its installation dialog, requesting an activation code to enter:



The activation code needs to be given as a response to another number (in our picture is 7600519) in order to authorize the installation. The code is generated using the current date as seed:


If the code was correct , the malware verifies the presence of a few file locations that belong to the targeted ATM software:


When all checks are OK, the malware copies itself into the ATM software's directory and creates the following files:
  • Casas.txt
  • devices2.ini
  • devicex.ini
  • borrar.exe
A registry key is created as well, in order to survive system reboot. The malware also tampers the ATM software's configuration file, hijacking the default IpHost parameter:


All relevant communication between the ATM machine and the control host is then redirected through the port number 6000, where the threat listens and acts as a malicious proxy.

After a successful installation, it displays a notifying message:


The threat also has a timer function that is called periodically to ensure automatic access to the USB drive by constantly updating the Start value of the registry key \SYSTEM\CurrentControlSet\Services\USBSTOR\

Information theft

The threat monitors windows captions looking for a specific content:
  • Escriba la clave ‘A’
  • Escriba la clave ‘B’
  • Enter the key ‘A’
  • Enter the key ‘B’
If any of the above is found, the malware activates its keylogger and the captured keystrokes then are written into two files casaA1.txt or casaB1.txt respectively (the digits in the filename may be incremental).

As mentioned earlier the malware hijacks the default TCP communication  in which relies the ATM's software, by  modifying its *.ini file and redirecting traffic to port 6000:


This smart move allows the attacker to carry out a Man In The Middle attack.


As a result, all the information supposed to be going directly to the ATM's software, now goes through on the malware's filter function and logged into the file Casas.txt

Here is a table summarizing the files and their purpose relating with the malware's activity:


Interaction and control

The way to interact with the malware is through the hijacked raw socket described in the previous point. It stores the data from transactions, as well as the user inputs may it come from the keyboard strokes or from touchscreen. 

The malware looks for patterns within the incoming data-stream. These patterns, work as valid commands to collect information and also to trigger additional functionality


Finally, the rest of the control is performed using the USB drive.

In this fashion, the creation some files with specific names in the root of drive is enough, as the when the malware detects them it will execute a series of default actions. The so called command are the following:


Recommendations
  • Physically harden  the entire ATM, do not just limit to the cash safety box. The ATM's computer should be isolated as well, not allowing unauthorized access to its components, ports and slots. Periodically schedule integrity checks, especially after maintenance and routine checks have been performed.
  • Consider to install additional surveillance systems like CCTV, or increment the number of them.
  • Control USB and CD-ROM access at the BIOS level. Protect the BIOS with password..
  • Upgrade from Windows XP to a more recent version of the operating system (or choose an alternate OS), since we all know that support for Windows XP has ended. ATMs running Windows XP Embedded (Toolkit and Runtime) may be an exception to this as there is an extended support for them, however only until 12th of January, 2016.
  • Use third party solutions that provide real-time protections, such as Lookwise Device Manager for ATM

Sample MD5:  1a6a240d2d03eb2c66c17a6593d4b6d2

Jozsef Gegeny and Santiago Vicente

Ransom... what?

This post is not intend to be an state of the art about the different Ransomware variants, but just a review of the various techniques used by the most relevant cases we have seen in the Ecrime department of S21sec.

One of the most extended the last year was Urausy, better known as “The Police Virus”.


The malware main functionality, despite it makes use of some interesting anti-analysis tricks, is limited to create a new desktop, depending on the victim’s country show one of the previous images and block the entire system until the ransom is paid.

Luckily, the number samples detected by S21sec seems to be in obvious decline during the last months, this could mean that its end is close:


However in this world, the end of a threat is the starting point for others, as for example the variant we named RansomChild, because it makes use of child pornography images (which we are not going to show here) to boost the blackmail. Functionally it also blocks the system, but as distinctive feature it has a Domain Generation Algorithm (DGA) system, which generates C&C backup URLs from a hardcoded seed.

Cryptolocker was as well one of the most prominent during the last year:


In this case the ransom is not demanded for the infected system’s unlock, instead it is asked for to decrypt the multiple files irretrievably encrypted by the trojan. After installation, the malware is added to the Windows registry to survive reboot and starts to check C&C domains generated by a time based DGA, until one of them send back a positive reply. Then a file labelled as CryptoLockerID is sent to the server, from that file pair of unique for the infected machine keys (public and private) are generated.

Cryptolocker has been one of the most spread and harmful cryptographic Ransomwares in recent times. Although thanks to the prompt response from the sec community was possible to address it almost completely.

One that of the not so well known, but not less vicious for those who has been infected with it is the malware known as Anti-Child Porn SPAM Protection 2.0:

It also encrypts files, up to date, in an irretrievable manner and as peculiarity it is not distributed in a massive way. Instead, the attackers performs the infection “by hand”, they get access to the targeted systems (in this case Windows Server) through brute force attacks to the remote desktop service in the port 3389.

The Ransomware scheme is being so profitable, that they get out of their intended geographical scope, as one of our clients sadly realized:


In conclusion, as we have seen prevention is the best solution for this kind of malware, this is even more important in the case of the cryptographic variety, because we will not be always so lucky that the malware uses a weak encryption algorithm and some good folks have broken it, as they guys of Cassidian did with Bitcript.

So the recommendations are:
  • In first place: common sense. The social engineering plays a big role in the infection process.
  • To avoid the encryption of the files located in shared folders, it is important to restrict permissions for the users to access network drives. That could prevent that the infection of just one user with granted privileges outcomes in the fully encryption of all network drives within a company network.
  • It is strongly recommended to do scheduled and centralized backups, it should be done in a way such that the backup information is placed in a different and highly controled device.
  • Keep the system updated and harden the exposed services against brute force attacks with strong passwords.
  • In the case of the analysed Cryptolocker samples, the encryption is not performed until the trojan reaches the C&C panel, so a solution like LTI could mitigate the infection

Santiago Vicente

The Dexter trojan


Dexter is a well known trojan, it is oriented to steal credit card information in the POS systems. Despite samples of its earlier versions were spotted in December 2012, a new version known as Dexter v2 or Stardust was discovered on December 2013. Among the Stardust features there are: locate the tracks of credit card's magnetic stripe  into memory, and key logging functions. In this article we are going to analyze the communication techniques between the trojan and its command and control (c&c) panel.

Stardusts employs POST requests to send the data. The POST parameters are encrypted with using XOR with a key  is created during the malware installation and then encoded using base64. However, the XOR key is sent within the POST parameters with just plain Base64, so it could be considered as simple   data obfuscation. To each request, the server replies in a cookie,that may contain commands to control the trojan (update, uninstall, force a memory check, etc).




The function, that creates the request body, collects certain data from the machine and generates the POST string:



The parameters are added to request_body  by using the function encode_param(char *param, char *value, char* request_body), which encodes the parameters values with XOR and Base64, adding the cyphered string to the request_body. At last, the XOR key coded only using Base64, is attached in the val parameter.



The XOR encoding function shows design flaws, despite it is enough to hide the strings, it is not enough from cryptographic point of view.



The generated encryption key is 5 bytes long, however the use of the XOR function reduces the effective length to just 1 byte. The main loops are the following:


for(i=0; i
for(j=0; j
string[i] ^= xor_key[j];
}
}

Due to the commutative property of the XOR, the inside loop could be expressed as:


string[i] ^= xor_key[0] ^ xor_key[1] ^ xor_key[2] ^ xor_key[3] ^ xor_key[4] 

What is the same as:


xor_value = xor_key[0] ^ xor_key[1] ^ xor_key[2] ^ xor_key[3] ^ xor_key[4];
for(i=0; i
string[i] ^= xor_value;
}

That, in practical terms, changes the length ot the XOR key to a 1 byte value.

Back again in the communication analysis, in the case of the strokes.log file exists, which is generated by the keylogger is decrypted with the same xor_encode function, but this time a special key located within the file's first 4 bytes. Once the file has been decrypted, the request parameter ks is generated and encoded with the same XOR key used in the rest of the parameters.


The first time it communicates with the dropzone adds the parameters unm,cnm,query and spec with the user, host name, OS version and architecture (“32 bits” or “64 bits”) of the infected machine. 
After send the request, it reads the response cookie, cyphered in the same fashion as the request and process the reply looking for commands.  

The reply has the following format:

   #[command1][;command2][…]$

It may send an empty reply using the string: '#$'

The accepted commands for the malware are:

  • checkin: forces the credit card data submission
  • scanin: forces a memory scan looking for credit card data
  • uninstall: uninstalls the trojan
  • download: downloads a file from an specified URL
  • update: downloads a new version of the malware and installs it 



The usage of cookies to send the answer from the server, is an original trick to hide the trojan communications during a dynamic analysis  or while inspecting network traffic. Even through the POST parameters should be enough for an IDS to detect the presence of the trojan.

Marcos Agüero
S21sec ecrime

Citadel "involution"

Thanks to our Analysis Platform, which analyzes and classifies thousands of samples every day, we are able to track malware families that may affect our clients. Among them it is, of course, Citadel,  one of the most popular trojans of which we have talked a lot before.

Through the control, and analysis of updates we can monitor the activity of each botnet, we can see if they are growing or shrinking, which entities are targeted, when it becomes inactive and so on.

Even thouhg many months have passed since latest version (3.1.0.0) was released, and despite it was taken for granted that it was going to be replaced by other banking trojan families, the fact is that, nowadays, despite the take down operation carried on by Microsoft in order to eliminate the threat, there are some Citadel botnets which remain active.

Certainly, since the begining of the year, we are seeing a noticeable drop regarding to the number of samples entering the analyzers each day.

The following graphics show the evolution during the past 10 months of the three most popular versions of the trojan:




Of course, this data would be incomplete without the information regarding the number of samples analyzed within that period.

As you can see in the following graphic, the number of samples that enter the Analysis Platform has grown considerably lately:


Right now, almost 90% of the active botnets are using the 1.3.5.1 version of the trojan which is, in fact, the most extended one. To our mind, the main reasons behind this are:
  • The 1.3.5.1 version was the last one that, as far as we know, was sold "freely"
  • The leak of Citadel's 1.3.5.1 builder has allowed a lot of cybercriminals to create a botnet for free even if they will, of course, lack any official updates.

Advanced Cyber Security Services
S21sec

ZeuS timeline (and III)



In this last post of the series dedicated to the timeline ZeuS trojan (and its leaks) [1][2], we are going to show some numbers that S21sec have being collecting regarding them.

The number of botnets detected in past few years has raised up to 2.300, most of them being ZeuS ones. In order to show this in a visual form, we have created a chart that groups them by version. As you can see, the two main ZeuS versions (2.1.0.1 and 2.0.8.9) account for almost 50% of the attacks.


As can be observed in the following chart, the prime target of the attacks is financial sector, specifically online banking, that pose 87.5% of the total targeted entities.


Though historically online banking affectation has been really high, we have seen a drop lately mainly due to the flourish of new variants which target other sectors in order to attain their goal. Regarding this, online banking security is getting better every year, and hence, thef by means of banking transactions has dropped significally. Following chart shows how online banking affectation has dropped from an historic average of 88% to a 86.8% in 2013.


Data collected by S21sec supports this theory and we can see it just by comparing ZeuS and Citadel development over time. In 2012 (year in which Citadel was released) it accounted roughly for 24% of the samples vs. 76% of ZeuS ones (please, don't forget that we set aside all other malware families for the comparison). Nowadays, the tide has turned and ZeuS samples dropped to 41% while Citadel accounts for 59% ot the total which is even more impressive if we consider the global Citadel botnet take down action carried out by Microsoft in mid-year. Regarding this, ZeuS versions have been targeting online banking entities more then other variants, including Citadel.

The following chart shows the affectation of countries (that is, the country of the entity being targeted, as long as it still has a login form). In order to understand this chart, you must know that each sample uses to attack more than one entity at the same time, so, the higher the number of entities targeted by one trojan for a country the higher it accounts on the chart.



In this way, spanish entities are the third most targeted, with a 16% of total attacks (mainly online banking entities, but remember banking malware is targeting other sectors too). This affectation to spanish entities is bigger when talking about ZeuS, more than any other variants. Any way, spanish entities targeting has dropped from 18% in previous years to 14% in 2013.

Finally, we will like to remark that new ZeuS variants have not only managed to target new sectors, but they are also targeting entities of countries which had not appeared in the configs until now. The number of different countries whose entities were affected in 2013 has raised to 71.


As you can see, ZeuS and its variants are causing security companies and entities lots of trouble. They still dominate the scene, although with the new famlies of banking trojans that are emerging, and above all, the leak of Carberp's code, we can not make any predictions in the foreseable future.

Advanced Cyber Security Services
S21sec

ZeuS timeline (II)

On the previous post, an overview of the history of ZeuS was made. In this one, we will detail the timeline, showing the main features and differences of each one of the variants and versions that we have seen over time.

To conclude this series of articles, in the next and final part we will focus on the numbers the Ecrime department of S21sec had extracted of this threat until today.

Advanced Cyber Security Services
S21sec

ZeuS timeline (I)

In this post we will examine different variants and branches of the ZeuS Trojan family. ZeuS was discovered 7 years ago, but to this day it continues to evolve and morph, making it one of the most widely used tools to attack mainly financial organisations.
 
From the timeline above it can be seen how its evolution has taken place and, specially, the variant explosion just after the source code was leaked.
Version 1.x led to different versions, although the 1.2.4.2 version was the most successful one. That is why most of you will quickly recognize the sdra64.exe file as a ZeuS 1.2.x.
Along its evolutionary path many improvements were made both to its functionality and protection against analysis. During 2008 and 2009, the continuous development resulted in the 1.1 to 1.4 versions. By the time the changes were completed so many had been made that the developer(s) decided to number the next version 2.0.
By the end of 2009, ZeuS had established market dominance and became the defacto market leader of banking Trojans (With the SpyEye permission).
The source code leak of 2.0.8.9 during the months of April-May 2011 resulted inevitably in the spawning of many bespoke versions of ZeuS.
It is important to note that prior to the leaking of the source code there was a cluster of gangs who were working on the pre leak source code. This assemblage of developers had constructed versions of ZeuS that ran in parallel to those versions based on the leaked code. The importance of this distinction is that developers involved in purchasing(?) ZeuS, developed what is known as Licat. Licat was used in campaigns against banks and it too went through evolutionary changes that resulted in the emergence of what became known as Murofet. The main significant change to functionality came with the introduction of a P2P communication system. What the code will do is try and connect to the P2P network and it fails to it will use a DGA (Domain generation Algorithm) to make a connection. Licat only had the DGA built into it. Clearly the P2P feature allowed for the Trojan to be far more robust than pervious incarnations of it.
There are in existence a number of other variants but these only have very minor changes contained within them and a good example of this is the variant that was named ZeuS Cryptless (due to its lack of encryption in the used strings). Other examples include the ZeuS Process or ZeuS Tasks variants (because this variants doesn’t inject its code in explorer.exe and its process remains active. It also creates a windows task in order to survive a reboot) used for Click Fraud.
Since the source code leak, there have been more variants, such as ICE-IX (the latest versions are known as ZeuS 4.3.3.3), a ZeuS 2.3.2.0 version using AES for encryption, Ramnit’s banking plug-in, a variant using Tor to connect to its C&C (known as Skynet), and finally one using SSL, the most famous of which was Citadel, and the more recent KINS and PowerZeuS.
We can see that the ZeuS world has become variegated, and a great deal of time and effort is needed to keep track of all the different variants coming from this old banking Trojan. Old it may be but never the less it is still considered to be one of the major threats to the banking sector.
In the next post we will describe some differences between the variants mentioned above. Until then, if you have come across a variant which we have failed to mention then please leave a comment :)

Advanced Cyber Security Services
S21sec

(+34 902 222 521)


24 hours a day, 7 days a week



© Copyright S21sec 2013 - All rights reserved


login