Español | English
rss facebook linkedin Twitter

New Feodo variant follows Geodo steps

Cridex (aka Feodo/Bugat) activity reached its zenith towards the end of 2013 and early 2014 in which it almost disappeared until it returned again in June reincarnated as what the guys at baptized as Geodo.

Earlier this week, S21sec's Ecrime team detected what seems to be an evolution of one of the old variants -unrelated to Geodo- which has new and noteworthy features.

First of all, it uses a loader with limited functionality as the first infection step used to download the main trojan module in the form of a DLL using the following paths and injecting itself into explorer.exe as in earlier versions:

Trojan network communication is done through the typical 8080 although the path is a bit different from what we are used to:

Once the installation step is completed, the trojan downloads the configuration file which is just a gzip file with a fake header:

The config file uses the XML like format seen on previous versions which has the following structure:
  • modules: Embedded new modules encoded in Base64:
    • vnc_x32
    • vnc_x64
    • socks_x32
    • socks_x64
    • bot_x32
    • bot_x64
  • httpshots y clickshots: URL patterns for which the trojan must perform screenshots
  • formgrabber: URL patterns used for form grabbing
  • bconnect: Back Connect Server
  • vncconnect: VNC Server
  • redirects: External resources references used on injections
  • httpinjects: Entity URL patterns with their corresponding injections

Affected entities seems to be mainly from UK, Ireland, United Arabian Emirates and Qatar, with some injections designed to bypass second authentication factor which, in combination with the VNC module, will allow the attacker to supplant the victim's online banking session.

So it seems that after some months of silence on Cridex world, a new old friend (dressed up for the ocassion) joins Geodo on its journey.

Santiago Vicente
S21sec Ecrime
Follow us on Twitter: @smvicente, @S21sec, @S21secSecurity

The MD5 signatures of the files analyzed by S21sec were:
  • loader: 9d81ac7604ef2a0096537396a4a91193
  • bot_x32: 04b55edf43a006f9c531287161fa2fa8
  • vnc_x32: c73c3c18b74c67e88d5b3f4658016dcd
Other hashes for the rest of the modules are:
  • vnc_x64: 5ecfc1d3274845bf5ff3f66ca255945e
  • socks_x32: 53eb0e59b5bb574df5755527dc3d4f47
  • socks_x64: 0dfc66eadbd9e88b2262ac848eadee8f
  • bot_x64: 4df1cef98bbc174ba02f17d2ca6c0a58

New GOZ first steps

From the very begining of the operation against the infamous Murofet/Gameover/ZeusP2P banking trojan (known as Operation Tovar) the botnet growth has stalled and it seems it has been abandoned since then. Instead of recovering control over the botnet, it seems that botmasters (or new ones) decided to create a new botnet from scratch using  a new GOZ version. We will analyze the main new features throughout the post.


  • The new trojan has replaced the Peer-to-Peer (P2P) mechanism in favor of a Fast-Flux network using a new domain generation algorithm (DGA).
  • The public key included within the trojan (which is XORed in the same way) is no longer used to verify the signature of the resources exchanged via P2P and is now used as part of the classic symmetric + asymmetric communication schema in which the payload is ciphered with the symmetric key whilst the random generated key is ciphered with the public key before it is sent to the command and control server. The scheme is similar to the one used, for instance, by Cryptolocker (Murofet related) or Cridex/Bugat/Feodo/Geodo.
Taking into account DGA is based on a hardcoded seed, creating a new botnet is just a matter of changing both, the seed, and the public key in the binary.


Whereas the cypher has been kept unchanged in some way, there has been some modifications due to the new communication scheme seen above. In short:
  • RC4 is maintained for the configuration stored in the system registry
  • The communication with the command and control panel is now based on AES256 + RSA.


The configuration has remained largely unchanged. In fact, most injections and target entities are old and they even contain variables which belongs to features no longer present on the current version like those related with the P2P proxy:

Therefore, it seems that we are facing what seems to be a lite version of GOZ which, somehow, reminds us Licat, its predecessor. Far from reducing the prominence of the trojan, even if the configuration files may lead us to think that it has been released in haste, features such as the DGA seed may lead to a boom of new GOZ botnets which will start a new cat and mouse chase.

Santiago Vicente
S21sec Ecrime
Follow us on Twitter: @smvicente, @S21sec, @S21secSecurity

New trojans on the horizon? (II)

As an addition to the information related to a new ZeuS variant published once again by Trusteer researchers, we would like to point that this botnet has been active since at least December 2013 and it does not show any feature that would have been observed before.

In fact, it is a slightly modified ZeuS version which incorporates features seen previously in other variants like the Virtual Machine present on KINS or the usage of AES-128 as cipher algorithm for the config which, in fact, in latest versions (those numbered as 4.6.X.X) was reverted to the original ZeuS RC4 algorithm with the peculiarity that, the seed, has been replaced by an AES key.

In regard to the activity of the related botnet it has been steadily declining since we began to monitor it:

As for its affectation, far from being focused in Canadian entities, its main targets are: USA, Spain and UK companies:

In conclusion, this is just one of the many variants of ZeuS already known to us.

Finally, some hashes from two of the different variants distributed by this botnet:
  • 0179c28d71902967b1ba46d3c5b10840 v4.6.2.0
  • 5b6568992e08028aff46fb6bf8e7519d v3.3.2.0

Ecrime Department

New Trojans on the Horizon? (I)

Last weekend we have seen some heat around a post published by IBM regarding the discovery of a new banking trojan. In the article, they stated that, recently, Trusteer researchers had discovered a new malware sample whose behaviour resembled those of Zeus and Carberp. As this sounded quite strange, we reviewed all the info available and, for us, there is no evidence to support that we are facing a new banking trojan but just a variant of the Kins trojan sight by S21sec a while ago.

Related to this, during 2014, S21sec has seen the following activity regarding banking trojans:

As you can see, en 2014 Kins has dethroned Citadel which held the crown since 2013. As this seems to be the norm on the trojan battlefield we are pretty confident that we will see new banking trojans in the future but, right now, there are not enought data to make any guesses. Of course, it is needless to say that we will keep you informed whenever we had any interesting info on the topic.

Ecrime Department

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:

  • 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:


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

(+34 902 222 521)

24 hours a day, 7 days a week

© Copyright S21sec 2013 - All rights reserved