Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 2 hours 41 min ago

Inside the Gootkit C&C server

15 hours 18 min ago

The Gootkit bot is one of those types of malicious program that rarely attracts much attention from researchers. The reason is its limited propagation and a lack of distinguishing features.

There are some early instances, including on Securelist (here and here), where Gootkit is mentioned in online malware research as a component in bots and Trojans. However, the first detailed analysis was published by researchers around two years ago. That was the first attempt to describe the bot as a standalone malicious program, where it was described as a “new multi-functional backdoor”. The authors of that piece of research put forward the assertion that the bot’s features were borrowed from other Trojans, and also provided a description of some of Gootkit’s key features.

In September 2016, we discovered a new version of Gootkit with a characteristic and instantly recognizable feature: an extra check of the environment variable ‘crackme’ in the downloader’s body. This feature was not present in the early versions. Just as interesting was the fact that we were able to gain access to the bot’s C&C server, including its complete hierarchal tree of folders and files and their contents.


As was the case earlier, the bot Gootkit is written in NodeJS, and is downloaded to a victim computer via a chain of downloaders. The main purpose of the bot also remained the same – to steal banking data. The new Gootkit version, detected in September, primarily targets clients of European banks, including those in Germany, France, Italy, the Netherlands, Poland, etc.

The Trojan’s main propagation methods are spam messages with malicious attachments and websites containing exploits on infected pages (Rig Exploit Kit). The attachment in the spam messages contained Trojan-Banker.Win32.Tuhkit, the small initial downloader that launched and downloaded the main downloader from the C&C server, which in turn downloaded Gootkit.

Examples of infected pages used to spread the Trojan

While carrying out our research we detected a huge number of the initial downloader versions that were used to distribute the Trojan – most of them are detected as Trojan.Win32.Yakes. Some of the loaders were extremely odd, like the one shown below. It clearly stated in its code that is was a loader for Gootkit.

Section of code from one of the initial downloaders

Some versions of Gootkit are also able to launch the main body with administrator privileges bypassing UAC. To do so, the main loader created an SDB file and registered it in the system with the help of the sdbinst.exe utility, after which it launched the bot with elevated privileges without notifying the user.

‘Crackme’ check

The new version of Gootkit is distinct in that it checks the environment variable ‘crackme’ located in the downloader body. It works as follows: the value of the variable is compared to a fixed value. If the two values differ, the bot starts to check if it has been launched in a virtual environment.

Checking the global variable in the downloader’s body

To do so, the bot checks the variable ‘trustedcomp’, just like it did in earlier versions.

Checking the bot’s body for launch in a virtual environment

The Trojan’s main body

The Trojan’s main file includes a NodeJS interpreter and scripts. After unpacking, the scripts look like this:

NodeJS scripts that make up the Trojan’s main body

The scripts shown in the screenshot constitute the main body of the Trojan. Gootkit has about a hundred various scripts, but they are mostly for practical purposes (intermediate data handlers, network communication DLLs, wrapper classes implementations, encoders etc.) and not of much interest.

The Trojan itself is distributed in an encrypted and packed form. Gootkit is encrypted with a simple XOR with a round key; unpacking is performed using standard Windows API tools. The screen below shows the first 255 bytes of the transferred data.

The Trojan’s packed body

The first three DWORDs denote the sizes of the received, unpacked and packed data respectively. One can easily check this by subtracting the third DWORD from the first DWORD, which leaves 12 bytes – i.e., the size of these variables.

Stealing money

Interception of user data is done the standard way, via web injections into HTTPS traffic (examples of these web injects are shown below). After the data is sent to the C&C server, it is processed by parsers, each of which is associated with the website of a specific bank.

Fragment of parser code

Communication with the C&C

In the version of Gootkit under review, the C&C address is the same as the address from which the Trojan’s main body is downloaded; in earlier versions, these two addresses sometimes differed. While generating a request, the Trojan uses its unique User Agent – any request that does not specify a User Agent will be denied.

The unique GootKit User Agent

Communication with the C&C comes down to the exchange of a pre-defined set of commands, the main ones being:

  • Request a list of files available to the Trojan (P_FS:FS_READDIR);
  • Receive those files (P_FS:FS_GETFILE/FS_GET_MULTIPLEFILES);
  • Receive update for the bot (P_FS: FS_GETFILE);
  • Obtain screenshot (P_SPYWARE:SP_SCREENSHOT);
  • Upload list of processes (P_SPYWARE:SP_PROCESSLIST);
  • Terminate process (P_SPYWARE:SP_PROCESSKILL);
  • Download modules (P_FS: FS_GETFILE);
  • Receive web injects (P_ SPYWARE:SP_SPYWARE_CONFIG).

The bot’s main commands and sub-commands

The C&C addresses (two or three in number) are hardwired in the loader’s body and can also be saved in the registry. The body of the data packet may vary depending on the request type, but always includes the following variables:

  • Size of data packet, plus eight;
  • Check value XORed with a constant;
  • Command type;
  • Command sub-type.

In the screen below, the C&C requests registration information from the bot during its first launch.

Request from C&C, example of variables

The response in this case will contain detailed information about the infected computer, including:

  • Network adapter parameters;
  • CPU details, amount of RAM;
  • User name, computer name.

Regardless of the request type, data is communicated between the C&C and the bot in the format protobuf.

When the main body is downloaded, the address that the loader contacts typically ends in one of the following strings:

  • /rbody32;
  • /rbody64;
  • /rbody320.

Mystery solved…rather easily

We found a configuration error that often appears on botnet C&C servers and took advantage of it to capture a complete tree of folders and files, as well as their contents, from one of the GootKit C&C servers.

Contents of GootKit C&C server

The C&C server contains a number of parsers for different banking sites. These parsers are used (provided the user data is available) to steal money from user accounts and to send notifications via Jabber. The stolen data is used in the form of text files, with the infected computer’s IP address used as the file name.

Stolen data and logs on the bot’s C&C server

Example of stolen data in one of the text files

Other data (bank transfers and logs) is also stored in text file format.

Parser logs

An analysis of the bot’s web injects and parser logs has shown that the attackers primarily target the clients of German and French banks.

Distribution of web injects across domain zones

Excerpts from parser logs

Analysis of the server content and the parsers made it clear that the botnet’s creator was a Russian speaker. Note the comments in the screen below.

A fragment of script including the author’s comments in Russian

Moreover, Gootkit most probably has just one owner – it’s not for sale anywhere and, regardless of the downloaders’ modifications or type of admin panel, the code in NodeJS (the Trojan’s main body) is always the same.

Examples of Gootkit web injects


Gootkit belongs to a class of Trojans that are extremely tenacious, albeit not very widespread. Because it’s not very common, new versions of the Trojan may remain under the researchers’ radar for long periods.

It should also be noted that the users of NodeJS as a development platform set themselves certain limitations, but simultaneously get a substantial degree of flexibility and simplicity when creating new versions of the Trojan.

Kaspersky Lab’s security products detect the Trojan GootKit and all its associated components under the following verdicts:

  • Trojan-Banker.Win32.Tuhkit (the initial downloader distributed via emails);
  • Trojan.Win32.Yakes (some modifications of the main downloader);
  • HEUR:Trojan.Win32.Generic (the bot’s main body, some modifications of the downloader).


The “notification” ransomware lands in Brazil

Tue, 10/25/2016 - 03:57

It’s unusual for a day to go by without finding some new variant of a known ransomware, or, what is even more interesting, a completely new one. Unlike the previously reported and now decrypted Xpan ransomware, this same-but-different threat from Brazil has recently been spotted in the wild. This time the infection vector is not a targeted remote desktop intrusion, but a more massively propagated malicious campaign relying on traditional spam email.

Since the infection is not done manually by the bad guys, their malware has a higher chance of being detected and we believe that is one of the reasons for them to have added one more level of protection to the code, resorting to a binary dropper to launch the malicious payload.

Given that this particular ransomware is fairly well known by now, instead of opting for the usual branding and marketing efforts in which most ransomware authors invest time, this group has decided to choose an unnamed campaign, showing only an email address for technical support and a bitcoin address for making the payment. It has become a kind of urban legend that if you can’t find something on Google, then it doesn’t exist.

Not very long ago, we saw the birth of truly autochthonous Brazilian ransomware, without much technical sophistication and mainly based on an open-source project. While there’s a long road ahead for local bad guys to achieve the level of the key players on the ransomware scene, this particular family is interesting to study since there have been versions in English, Italian, and now Brazilian Portuguese. Is this ransomware being sold as a commodity in underground forums with Brazilian crews just standing on the shoulders of giants? Or is this a regional operation just starting out?

As one of the very few ransomware variants that prepend a custom ‘Lock.’ extension to the encrypted files instead of appending it, the task of recognizing this malware is not particularly difficult. However, understanding its true origins could still be considered an ongoing debate.

The drop

If we trust that the first transaction corresponds to the very first victim, the campaign has probably been active since 2016-04-04 17:29:26 (April 4th, 2016). In reality, this is not exactly accurate. The timestamp of the original dropper shows that the sample was actually compiled at the beginning of October:

That would mean that the criminal behind the campaign might have had different ransomware campaigns running in the past, or is just using the same BTC wallet for more than his criminal deeds.

The dropper is protected by the popular .NET obfuscator SmartAssembly, as can be seen by the string “Powered by SmartAssembly”. Once executed, it tries to mask itself in the Alternate Data Stream of the NTFS file system in Windows:

“%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\Sims.exe:Zone.Identifier

It’s capable of disabling Windows LUA protection:

(cmd.exe /c %WINDIR%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
Reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f)

The mechanism used to write new information to the registry is quite unusual: it uses the official windows application ‘migwiz.exe’ in order to bypass the UAC screen, not requiring any action from the user to execute with elevated privileges.

The malware is able to do that by writing a library ‘cryptbase.dll’ to the same folder as the ‘migwiz.exe’ file. Then, as soon as it’s launched, the process will load this library, which has a WinExec call that will launch the command line provided by the parameter.

The reason why they are using MigWiz is because this process is one that is in Microsoft’s auto-elevate list, meaning it can be elevated without asking for explicit permission.

As a simple mean of information gathering, the dropper will read the name of the infected computer:


Moreover, it includes data stealer techniques, such as retrieving information from the clipboard, or while it’s being typed on the keyboard. Additionally it has the capability to reboot the user’s machine.

@4333be: push ebp
@4333bf: mov ebp, esp
@4333c1: sub esp, 14h
@4333c4: push ebx
@4333c5: mov ebx, dword ptr [ebp+08h]@4333c8: lea eax, dword ptr [ebp-04h]@4333cb: push eax
@4333cc: push 00000028h
@4333ce: call dword ptr [00482310h] ;GetCurrentProcess@KERNEL32.DLL
@4333d4: push eax
@4333d5: call dword ptr [0048202Ch] ;OpenProcessToken@ADVAPI32.DLL
@4333db: test eax, eax
@4333dd: je 0043341Eh
@4333df: lea ecx, dword ptr [ebp-10h]@4333e2: push ecx
@4333e3: push 00487D68h ;SeShutdownPrivilege

Finally, it drops and executes the file tmp.exe (corresponding hash B4FDC93E0C089F6B885FFC13024E4B9).

Hello sir, hello madam, your fines have been locked

After the infection has been completed, as is usual in all ransomware families, the ransom note is shown. This time, it is written in Brazilian Portuguese and demanding 2000 BRL, which equates to around 627 USD or 1 BTC at the time of writing.

The bitcoin address provided (1LaHiL3vTGdbXnzyQ9omsYt8nFkUafXzK4) for payment shows total deposits for 1.89 BTC although many transactions have been made since the creation of this wallet. This is leading us to believe that either the criminal has been using the wallet for other purposes or they have bargaining with the victims and offering them a lower price, as depicted by the amount in each transaction.

The ransom note is very succinct, without giving any special payment URL or any other type of information. The victim will have to learn about bitcoin payments the hard way, and should they need support they can reach the criminals through a single email point of contact.

Ola Sr(a),
TODOS os seus arquivos foram BLOQUEADOS e esse bloqueio somente serão DESBLOQUEADOS
caso pague um valor em R$ 2000,00 (dois Mil reais) em Bitcoins
Após o pagamento desse valor, basta me enviar um print para o email
que estarei lhe enviando o programa com a senha para descriptografar/desbloquear o seus arquivos.
Caso o pagamento não seja efetuado, todos os seus dados serão bloqueados
permanentemente e o seu computador sera totalmente formatado
(Perdendo assim, todas as informações contidas nele, incluindo senhas de email, bancárias…)
O pagamento deverá ser efetuado nesse endereço de Bitcoin:
Para converter seu saldo em bitcoins acesse o site:

Growth of ransomware in Brazil

The growth of ransomware in Brazil has been nothing short of impressive, taking into consideration that during October 2016 alone the popular ransomware family Trojan-Ransom.NSIS.MyxaHaTpyne.gen family grew by 287.96%, and another of the usual suspects Trojan-Ransom.Win32.CryptXXX.gen grew by 56.96%, (when compared to the previous month in each case.)

In 2016, the 3 most important families of ransomware have been Trojan-Ransom.Win32.Blocker, accounting for 49.63% of the total infections,

Trojan-Ransom.NSIS.Onion, 29.09%, and Trojan-Ransom.Win32.Locky, 3.99%.

Currently, Brazil is the eighth most affected country worldwide as far as ransomware infections go for this year, and ranked first in Latin America.

Indicators of compromise

File: 04.exe
Size: 1049600
Compiled: Saturday, October 8 2016, 11:22:30 – 32 Bit .NET

File: tmp.exe
Size: 842220
MD5: BB4FDC93E0C089F6B885FFC13024E4B9
Compiled: Sunday, January 29 2012, 21:32:28 – 32 Bit

Windows zero-day exploit used in targeted attacks by FruityArmor APT

Thu, 10/20/2016 - 04:56

A few days ago, Microsoft published the “critical” MS16-120 security bulletin with fixes for vulnerabilities in Microsoft Windows, Microsoft Office, Skype for Business, Silverlight and Microsoft Lync.

One of the vulnerabilities – CVE-2016-3393 – was reported to Microsoft by Kaspersky Lab in September 2016.

Here’s a bit of background on how this zero-day was discovered. A few of months ago, we deployed a new set of technologies in our products to identify and block zero-day attacks. These technologies proved their effectiveness earlier this year, when we discovered two Adobe Flash zero-day exploits – CVE-2016-1010 and CVE-2016-4171. Two Windows EoP exploits have also been found with the help of this technology. One is CVE-2016-0165. The other is CVE-2016-3393.

Like most zero-day exploits found in the wild today, CVE-2016-3393 is used by an APT group we call FruityArmor. FruityArmor is perhaps a bit unusual due to the fact that it leverages an attack platform that is built entirely around PowerShell. The group’s primary malware implant is written in PowerShell and all commands from the operators are also sent in the form of PowerShell scripts.

In this report we describe the vulnerability that was used by this group to elevate privileges on a victim’s machine. Please keep in mind that we will not be publishing all the details about this vulnerability because of the risk that other threat actors may use them in their attacks.

Attack chain description

To achieve remote code execution on a victim’s machine, FruityArmor normally relies on a browser exploit. Since many modern browsers are built around sandboxes, a single exploit is generally not sufficient to allow full access to a targeted machine. Most of the recent attacks we’ve seen that rely on a browser exploit are combined with an EoP exploit, which allows for a reliable sandbox escape.

In the case of FruityArmor, the initial browser exploitation is always followed by an EoP exploit. This comes in the form of a module, which runs directly in memory. The main goal of this module is to unpack a specially crafted TTF font containing the CVE-2016-3393 exploit. After unpacking, the module directly loads the code exploit from memory with the help of AddFontMemResourceEx. After successfully leveraging CVE-2016-3393, a second stage payload is executed with higher privileges to execute PowerShell with a meterpreter-style script that connects to the C&C.

EOP zero-day details

The vulnerability is located in the cjComputeGLYPHSET_MSFT_GENERAL function from the Win32k.sys system module. This function parses the cmap table and fills internal structures. The CMAP structure looks like this:

The most interesting parts of this structure are two arrays – endCount and startCount. The exploit contains the next cmap table with segments:

To compute how much memory to allocate to internal structures, the function executes this code:

After computing this number, the function allocates memory for structures in the following way:

The problem is that if we compute the entire table, we will achieve an integer overflow and the cnt variable will contain an incorrect value.

In kernel, we see the following picture:

The code allocates memory only for 0x18 InternalStruct but then there is a loop for all the segments range (this value was extracted from the file directly):

Using the cmap table, the v44 variable (index) could be controlled and, as a result, we get memory corruption. To achieve it, the attacker can do the following:

  1. Make an integer overflow in win32k!cjComputeGLYPHSET_MSFT_GENERAL
  2. Make a specific segment ranges in font file to access interesting memory.

What about Windows 10? As most of you know, the font processing in Windows 10 is performed in a special user mode process with restricted privileges. This is a very good solution but the code has the same bug in the TTF processing.

As a result, if you load/open this font exploit in Windows 10, you will see the crash of fontdrvhost.exe:

Kaspersky Lab detects this exploit as:

  • HEUR:Exploit.Win32.Generic
  • PDM:Exploit.Win32.Generic

We would like to thank Microsoft for their swift response in closing this security hole.

* More information about the FruityArmor APT group is available to customers of Kaspersky Intelligence Services. Contact:

‘Adult’ video for Facebook users

Mon, 10/17/2016 - 04:57

In April of this year, we registered some mass attacks on Facebook users in Russia. As a result, many Russian-speaking users of the social network fell victim to fraudsters. Half a year later the fraudsters have used the same tactics to attack Facebook users in Europe.

The attackers use a compromised Facebook account to post a link to an adult video that is supposedly on the popular YouTube service. In order to attract potential victims, “likes” are added from the account holder’s list of friends. The fraudsters rely on the user or their friends being curious and those who would like to watch an “18+” video.

Clicking on the link opens a page made to look like YouTube.

However, a quick look at the address bar is enough to see that the page has nothing to do with YouTube. During the latest attack the fraudsters distributed a “video” located on the domain. The domain is not currently available, but we discovered more than 140 domains with the same registration data that can be used for similar purposes.
After trying to start the video, a pop-up banner appears prompting the user to install a browser extension. In this particular example, it was called ‘Profesjonalny Asystent’ (Professional assistant), but we also came across other names.

The “View details” message explains that if the extension is not installed, the video cannot be viewed.

The attackers are banking on an intrigued victim not being interested in the details and just installing the extension. As a result, the extension gains rights to read all the data in the browser, which the fraudsters can later use to get all the passwords, logins, credit card details and other confidential user information that is entered. The extension can also continue spreading links to itself on Facebook, but now in your name and among your friends.

We strongly recommend not clicking such links and not installing suspicious browser extensions. It’s also worth checking if any suspicious extensions have already been installed. If any are discovered, they should be immediately removed via the browser settings, and the passwords for sites that are visited most often, especially online banking, should be changed.

CryPy: ransomware behind Israeli lines

Thu, 10/13/2016 - 05:26

A Tweet posted recently by AVG researcher, Jakub Kroustek, suggested that a new ransomware, written entirely in Python, had been found in the wild, joining the emerging trend for Pysomwares such as the latest HolyCrypt, Fs0ciety Locker and others.

This Python executable comprises two main files. One is called and the other The first is responsible for error-logging on Windows platforms, while the second, the encryptor, is the actual locker. Within the encryptor are a number of functions including two calls to the C&C server. The C&C is hidden behind a compromised web server located in Israel. The Israeli server was compromised using a known vulnerability in a content management system called Magento, which allowed the threat actors to upload a PHP shell script as well as additional files that assist them in streaming data from the ransomware to the C&C and back.

A notable point to mention is that the server was also used for phishing attacks, and contained Paypal phishing pages. There are strong indications that a Hebrew-speaking threat actor was behind these phishing attacks. The stolen Paypal credentials were forwarded to another remote server located in Mexico and which contains the same arbitrary file upload technique, only with a different content management.

It is a known practice for attackers to look for low-hanging fruit into which they can inject their code in order to hide their C&C server. One such example was the CTB-Locker for web servers reported last March.

Ransomware Analysis


SHA1: ad046bfa111a493619ca404909ef82cb0107f012
MD5: 8bd7cd1eee4594ad4886ac3f1a05273b
Size: 5.22 MB
Type: exe

To reverse the executable one should first conduct a number of checks using a convenient debugger. The universal steps for unpacking an unknown packer start with trying to set a memory breakpoint on popular functions that packers use, such as VirtualAlloc.

If the breakpoint hits, the next step involves switching to user mode and setting a hardware breakpoint (on access). That will assist in inspecting where exactly the program initializes the memory block. In most cases, an executable magic header (MZ) should appear in the memory block. However, in this case the following screenshot shows the readable data that was allocated to that memory block:

After the data was allocated to the memory block, it appeared to be using VM code (python vm) to execute the code. For those who are not familiar with the term, VM code is the process of creating new instruction sets based on the author’s request. The CPU uses those instruction sets to understand the instructions.

py2exe simply converts the code to x86 assembly, the architecture used on the CPU for communication, and, by loading a python DLLs, loads all the modules into the memory.

We found that the executable file was generated using py2exe. The first indicator was a stack PUSH instruction to add the string – PY2EXE_VERBOSE: a module that compiles Python scripts to Microsoft Windows executables.

PY2EXE module string disclosure

A module that reverse the operation of the py2exe can be found in Github and is called unpy2exe. This module will revert the executable back to its origin Python compiled code (i.e. .pyc file). From that format, another step will be required to fully revert to the original code. We randomly chose to use EasyPythonDecompiler.

Fully decompiled Python scripts

In it’s current state, the executable fails to encrypt the file system, simply because the threat actors must have migrated from the current server to another. By doing so, they deleted the remaining traces of the PHP files they used for data collection from a victim’s machine. The following is the log file that is generated upon exception:

Error log file being generated by the

The scripts in Python use two files:

  • Name:
    md5: dfd6237e26babdbc2b32fa0d625c2d16
    SHA1: 38fe7b64113e467375202e2708199b45a22b25a6
    Size: 3Kb
    This file throws an “error” to show that the program failed to execute if there is a problem.
  • Name:
    md5: 1ed3f127a0e94394ef049965bbc952ef
    SHA1: 73122712b4563fadcc9871eb3fe0efdcf70bb608
    Size: 9Kb
    This script encrypts the victim’s files.

The ransomware disables the following features from the compromised machine:
By overwriting the registry policies it disables Registry Tools, Task Manager, CMD and Run.

list of registry manipulations

It then continues with changing bcdedit to disable recovery and ignore boot status policy.

Upon successful encryption, the ransomware will encrypt the following file extensions:
*.mid, *.wma, *.flv, *.mkv, *.mov, *.avi, *.asf, *.mpeg, *.vob, *.mpg, *.wmv, *.fla, *.swf, *.wav, *.qcow2, *.vdi, *.vmdk, *.vmx, *.gpg, *.aes, *.ARC, *.PAQ, *.tar.bz2, *.tbk, *.bak, *.tar, *.tgz, *.rar, *.zip, *.djv, *.djvu, *.svg, *.bmp, *.png, *.gif, *.raw, *.cgm, *.jpeg, *.jpg, *.tif, *.tiff, *.NEF, *.psd, *.cmd, *.class, *.jar, *.java, *.asp, *.brd, *.sch, *.dch, *.dip, *.vbs, *.asm, *.pas, *.cpp, *.php, *.ldf, *.mdf, *.ibd, *.MYI, *.MYD, *.frm, *.odb, *.dbf, *.mdb, *.sql, *.SQLITEDB, *.SQLITE3, *.asc, *.lay6, *.lay, *.ms11 (Security copy), *.sldm, *.sldx, *.ppsm, *.ppsx, *.ppam, *.docb, *.mml, *.sxm, *.otg, *.odg, *.uop, *.potx, *.potm, *.pptx, *.pptm, *.std, *.sxd, *.pot, *.pps, *.sti, *.sxi, *.otp, *.odp, *.wks, *.xltx, *.xltm, *.xlsx, *.xlsm, *.xlsb, *.slk, *.xlw, *.xlt, *.xlm, *.xlc, *.dif, *.stc, *.sxc, *.ots, *.ods, *.hwp, *.dotm, *.dotx, *.docm, *.docx, *.DOT, *.max, *.xml, *.txt, *.CSV, *.uot, *.RTF, *.pdf, *.XLS, *.PPT, *.stw, *.sxw, *.ott, *.odt, *.DOC, *.pem, *.csr, *.crt, *.key and wallet.dat to encrypt crypto currency wallets

The files are encrypted using AES with CBC mode for the following paths:

[userhome]\\My Documents\\
[userhome]\\My Music\\
[userhome]\\My Pictures\\
[userhome]\\My Videos\\
*userhome - The current user home directory

When the encryption step is done, the ransomware will remove the restore points and write the README_FOR_DECRYPT.txt file and execute it. The following screen shot is the ransom note:

CryPy Ransomware Note embedded in the Python code

The threat actor behind the attack asks the victim to contact it via email, and to send a request to the following two email addresses to receive the decryption program:

(1) m4n14k@sigaint[.]org
(2) blackone@sigaint[.]org

Note that the ransom note contains mistakes, implying that it has been written by a non-English speaker. First, the headline is missing a ‘T’ in “IMPORTAN INFORMATION”. Second, the sentence “Decrypting of your files…” is syntatically wrong. Native speakers will be able to find additional mistakes.

The threat actor claims that files will be deleted every 6 hours, which reflects the approach of more advanced ransomwares. However, it forgets to mention proof of decryption or a channel that can be used in cases where the payment process is not responsive. This points to the executable being at an early stage of development.

The ransomware survives a reboot by adding the following keys to the registry:

regkey Software\\Microsoft\\Windows\\CurrentVersion\\Run subkey Adobe_ReaderX data %TEMP%\\mw.exe regkey Software\\Microsoft\\Windows\\CurrentVersion\\Run subkey explore_ data [userhome]\\Appdata\\local\\DCBC2A71-70D8-4DAN-EHR8-E0D61DEA3FDF.exe

The code for adding the values to the registry are located on the functions autorun() and autorun2().

These keys cause the computer to execute the files after the computer is restarted.

Right before launching the ransom note, the script calls a delete_shadow() function that takes no arguments, and simply executes the following command line code to remove all shadow copies and prevent recovery from backup:

os.system("vssadmin Delete shadows /all /Quiet")

Lastly, the file calls autorun2() fuction that copies the ransomware from its current location to C:\\Users\\\\AppData\\Local with hardcoded name:

C2 Communication

The ransomware hides behind an Israeli web server which was compromised using Shell script arbitrary upload written in PHP. The compromise and upload were possible because the server carried a vulnerable Magento CMS.

The executable transfers data over an unencrypted HTTP channel in clear-text. This allows for easy traffic inspection using a network listener. The following screenshot is the traffic being sent to the server:

Inspecting the Magento exploit and the compromised server, we found that the origin of the upload carries the title Pak Haxor – Auto Xploiter and the email ardiansyah09996@gmail[.]com and that the file was uploaded in August 2016, which aligns with the case in subject. The following screenshot reveals how attackers are using massive exploiters that scan for vulnerable web servers and exploit the vulnerability, which they later visit to expand their control over the server:

Part of such an exploitation technique is dropping additional PHP scripts to refine a more sophisticated attack, such as the CryPy ransomware.

One such script can be found hard-coded in the CryPy Python code, in the form of a GET request. The request is sent with two parameters to a script that was uploaded using the Auto Xploiter and carries the name victim.php. By reviewing the Python code it is easier to understand the type of data being presented in Base64 encoding format.

As seen in the screenshot above, the configurl parameter accepts a URL querystring where the victim_info input value of the info parameter is derived from the platform module.

uname() is used when one wants to return a tuple of system, node, release, version, machine and processor values. These are encoded with Base64.

The next parameter is ip which contains the socket.gethostname() which basically collects an IP address.

The querystring is then sent to urllib.urlopen(), which will send a GET request to the selected server and read the reponse content into glob_config.

The response contains a JSON format payload which is checked for the following keys:
x_ID – the victim’s unique ID to request their decryption keys after payment.
x_UDP – Not used; perhaps saved for future use.
x_PDP – Not used; perhaps saved for future use.

The second call is implemented in a function called generate_file() which is responsible for fetching a unique key for each file before encryption.

We have seen in recent lockers that, in order to demonstrate trust and integrity, the victim is able to decrypt one/two files before processing the payment. This proves decryptor validity. In order to randomly choose a file, the attacker must first generate a unique token for each one. The second PHP script found in the code is savekey.php which is described in the following screenshot and is suspected to have the C2 IP in it. It was however deleted long before we were able to reach it.

As for the first call, the second sends two parameters. The first is the file’s name and the other is the victim ID. In return, the server responds with two keys:
X – Unique key after encryption which will be appended to the file’s header.
Y – New filename which will be stored instead of the previous one.

These parameters are then sent to an encryption routine, along with the file’s original name.






8bd7cd1eee4594ad4886ac3f1a05273b crypy.exe



Five myths about machine learning in cybersecurity

Wed, 10/12/2016 - 06:35

Machine learning has long permeated all areas of human activity. It not only plays a key role in the recognition of speech, gestures, handwriting and images – without machine learning it would be difficult to imagine modern medicine, banking, bioinformatics and any type of quality control. Even the weather forecast cannot be made without machines capable of learning and generalization.

I would like to warn about, or dispel, some of the misconceptions associated with the use of ML in the field of cybersecurity.

Myth №1: Machine learning in information security is a novelty

For some reason, discussion of artificial intelligence in cybersecurity has become all the rage of late. If you haven’t been following this theme over the longer term, you may well think it’s something new.

A bit of background: one of the first machine learning algorithms, the artificial neural network, was invented in the 1950s. Interestingly, at that time it was thought the algorithm would quickly lead to the creation of “strong” artificial intelligence. That is, intelligence capable of thinking, understanding itself and solving other tasks in addition to those it was programmed for. Then there is so-called weak AI. It can solve some creative tasks – recognize images, predict the weather, play chess, etc. Now, 60 years later, we have a much better understanding of the fact that the creation of true AI will take years, and what today is referred to as artificial intelligence is in fact machine learning.


When it comes to cybersecurity, machine learning is nothing new either. Algorithms of this class were first implemented 10-12 years ago. At that time the amount of new malware was doubling every two years, and once it became clear that simple automation for virus analysts was not enough, a qualitative leap forward was required. That leap came in the form of processing the files in a virus collection, which made it possible to search for files similar to the one being examined. The final verdict about whether a file was malicious was issued by a human, but this function was almost immediately transferred to the robot.

In other words, there’s nothing new about machine learning in cybersecurity.

Myth №2: Machine learning in cybersecurity is straightforward – everything’s already been thought of

It’s true that for some spheres where machine learning is used there are a few ready-made algorithms. These spheres include facial and emotion recognition, or distinguishing cats from dogs. In these and many other cases, someone has done a lot of thinking, identified the necessary signs, selected an appropriate mathematical tool, set aside the necessary computing resources, and then made all their findings publicly available. Now, every schoolkid can use these algorithms.

Machine learning determines the quality of cookies by the number of chocolate chips and the radius of the cookie

This creates the false impression that the algorithms already exist for malware detection too. That is not the case. We at Kaspersky Lab have spent more than 10 years developing and patenting a number of technologies. And we continue to carry out research and come up with new ideas because … well, that’s where the next myth comes in.

Myth №3: Machine learning – do it once and forget about it

There is a conceptual difference between malware detection and facial recognition. Faces will remain faces – nothing is going to change in that respect. In the majority of spheres where machine learning is used, the objective is not changing with time, while in the case of malware things are changing constantly and rapidly. That’s because cybercriminals are highly motivated people (money, espionage, terrorism…). Their intelligence is not artificial; they are actively combating and intentionally modifying malicious programs to get away from the trained model.

That’s why the model has to be constantly taught, sometimes even retrained from scratch. Obviously, with rapidly modifying malware, a security solution based on a model without an antivirus database is worthless. Cybercriminals can think creatively when necessary.

Myth №4: You can let security software learn on the client side

Let’s say, it processes the client’s files. Most of them will be clean, but some will be malicious. The latter are mutating, of course, but the model will learn.

However, it doesn’t work like that, because the number of malware samples passing through the computer of an average client is much smaller than the amount of malware samples collected by an antivirus lab system. And because there will be no samples for learning, there will be no generalization. Factor in the “creativity” of the virus writers (see the previous myth) and detection will fail, the model will start recognizing malware as clean files and will “learn the wrong things.”

Myth №5: It’s possible to develop a security solution that’s based solely on the ML model, without other detection methods

Why use multi-level protection based on different technologies? Why not put all your eggs in one basket if that basket is so smart and advanced? One algorithm is enough to solve everything. Right?

The thing is most malware belongs to families consisting of a large number of modifications of one malicious program. For example, Trojan-Ransom.Win32.Shade is a family of 30,000 cryptors. A model can be taught with a large number of samples, and it will gain the ability to detect future threats (within certain limits, see Myth №3). In these circumstances machine learning works well.

However, it’s often the case that a family consists of just a few samples, or even one. Perhaps the author didn’t want to go into battle with security software after his “brainchild” was immediately detected due to its behavior. Instead, he decided to attack those who had no security software installed or those who had no behavioral detection (i.e., those who had put all their eggs in one basket).

These sorts of “mini-families” cannot be used to teach a model – generalization (the essence of machine learning) is impossible with just one or two examples. In these circumstances, it is much more effective to detect a threat using time-tested methods based on the hash, masks, etc.

Another example is targeted attacks. The authors behind these attacks have no intention of producing more and more new samples. They create one sample for one victim, and you can be sure this sample will not be detected by a protection solution (unless it is a solution specifically designed for this purpose, for example, Kaspersky Anti-Targeted Attack Platform). Once again, hash-based detection is more effective.

Conclusion: different tools need to be used in different situations. Multi-level protection is more effective than a single level – more effective tools should not be neglected just because they are “out of fashion.”

The problem of Robocop

And one last thing. This is more of a warning than a myth. Researchers are currently paying more attention to what mistakes complex models are making: in some cases, the decisions they take, cannot be explained from the point of view of human logic.

Machine learning can be trusted. But critical systems (the autopilot in planes and automobiles, medicine, control services, etc.) usually have very strict quality standards; formal verification of software programs is used, while in machine learning, we delegate part of the thought process and responsibility to the machine. That’s why quality control of a model needs to be conducted by highly respected experts.

Trust me, I have a pen

Tue, 10/11/2016 - 12:40

Earlier today we became aware of a malicious website delivering Petya through the Hunter exploit kit. While there is nothing special about yet another exploit kit page, this one caught our attention because it mimics the index page of our sinkhole systems.

A malicious webpage faking one of our research systems

With cybercriminals increasingly trying to exploit trust relationships in cyberspace, it’s easy to get fooled by such attempts. We believe the criminals attempted to mimic our sinkhole systems in order to avoid being shut down by other researchers.

Just last week we were investigating a case of a serious attack that potentially breached a company. When we collected proof of the attack, we had to contact the company to help them isolate compromised systems and remediate. This brought us to a problem we commonly see today: the problem of trust.

The first reaction you normally have when someone calls you and attempts to convince you must arouse suspicion. In our investigations we normally deal with security personnel, who are highly paranoid people and do not trust anyone by nature. So far, the reaction of the company’s security staff was spot on: get the name of the caller, the company and department name, look up the company contacts using an independent, trusted, verifiable source, contact the company and confirm the facts, asking to connect to the researcher in the office immediately to do additional voice recognition. When that is done, the conversation can be resumed. Such a reaction and verification process is what we consider standard in our business. Unfortunately, we haven’t seen the same level of cautiousness among regular users.

A typical strategy for cybercriminals is to try to hide their tools, exploit kits and other malicious files on a compromised legitimate website or inject a malicious payload into a hijacked banner network account. Attackers also will rip entire websites, or just replace links to redirect visitors to attacker controlled sites, as we observed with the StrongPity watering holes. In this case, they simply counted on the confusion caused by visual appearance.

The fake webpage looks exactly the same as the original one from our research server and there is no point in finding even minor differences. Every webpage on the web can be copied and made to look identical to the source, except for the page’s original address or validated SSL certificate. PGPHtml is an alternative possibility, with each page explicitly stating its host domain or IP and then signed and verified with a public key. The server in question has been reportedly serving the Pony Trojan, hosting the Hunter Exploit Kit and distributing Petya ransomware.

We believe that this was the act of Russian-speaking cybercriminals, who send messages to our side every time their activities are affected by the work we do. We are bringing this to your attention to make you a little bit more cautious. Having said that, our first reaction was laughter, because it brought back some memories of an excellent short video on this matter shot by our colleagues from the security industry. And, because of this history of receiving messages from malware authors in their code and on sites, we think it is unlikely that this site is a watering hole targeting security researchers.

Unfortunately, this game of shadows is a well-known method not only in the criminal world but also in the world of advanced targeted attackers. We have seen in the past that some APT groups use deceiving tactics in order to try to confuse security researchers into wrong attribution. We have seen malware samples in the past where attackers from one group implanted decoys, trying to mimic the behaviour of their rivals. This is done to harden the research process or consume extra time. The attribution process, being the hardest part of any computer investigation, can easily be driven in the wrong direction. However, we have been looking at these attempts for a long time and learned to recognize such false flags. Now we would like you to be cautious and verify everything you see.

Related to this topic, our colleagues recently presented a more in-depth analysis of these techniques at VB 2016. You can read their entire paper here: Wave your false flags!

Wave your false flags!

Thu, 10/06/2016 - 04:58

 Download the full report (PDF)

As a new VirusBulletin is upon us, it’s once again time to deep dive into interesting topics in anti-malware research. This time around, we’ve chosen to focus on attribution in APT research, its methods and complications, and how intermediate-to-advanced attackers are already manipulating attribution indicators in an attempt to mislead researchers and squander limited incident response resources. False flags and deception tactics have always been discussed as possibilities in this space, but we wanted to put out a wealth of examples to advance the conversation. Our hope is that we can further the dialogue regarding attribution to involve more nuanced and daunting questions that have yet to be conclusively addressed.

When reading some of the examples, keep in mind that this was written back in February to submit to the VirusBulletin call for papers. At the time, deception techniques were a topic discussed in private between researchers, but never publicly substantiated. Since then, events over the summer have made this topic commonplace to the infosec community, if still a matter of contention and skepticism. The paper is extensive (but not exhaustive) and we hope that those of you interested in the subject will take some time to go through the reasoning and examples. The following are some takeaways we hope will pique your interest and get a dialogue going regarding the nuances of attribution as it’s currently being done:

There’s nothing straightforward about ‘whodunnit’

From the perspective of threat intelligence producers, there exist complications regarding attribution and its practical purpose. As any honest anti-malware company should admit, no institution has complete or perfect visibility into the activities of any threat actor. Different companies see different fragments; different types of service providers compliment that visibility with other types of data. This is a research space rewarded by cooperation and data exchanges. As such, when attempting to describe the activities of a threat actor, it’s difficult to suggest that a single threat intelligence product can stand as the exhaustive final chapter on any of the threat actors we investigate. Much less, provide a definitive picture of their identity, activities, and resources.

The true value of a threat intelligence product is its actionable potential, its ability to help detect and mitigate attacks, to provide clear avenues for proactive defense and improved defensive posture against a persistent and shadowy adversary, and to provide understanding to institutions and individuals outmatched and outwitted by the topdogs of the cyber espionage space. And even then, we have to consider that when it comes to wide dissemination of this information for the benefit of the public, it’s not just victims that are reading threat intelligence products. As our paper sets out to demonstrate, attackers too are keenly consuming threat intelligence research, learning from researcher methods as well as other APT groups and incorporating that information to better their own operations.

What can attribution do for you?

Threat Intelligence has come a long way in the last five years or so, and with that, more and more attribution is being done publicly by companies selling this as a product. Before that, attribution was only really done within governments and kept private or classified. These days, journalists and commentators are after the ‘sexy’ part of the story and are heavily focused on the “who” and not the “why”. While we are not arguing for or against companies performing attribution and publicly sharing their discoveries, we do pose some questions around how deep attribution really needs to go based on the role of the organization defended and its ability to take action. For governments, the most fidelity is justifiably needed, especially when the outcome of the attribution results in diplomatic sanctions, offensive operations, or demarches. But for a private company consuming threat intelligence is that level of attribution really needed to protect that organization against these attacks?

We hope the paper proves thought-provoking to threat intelligence producers and consumers alike, aligning needs and expectations, and preparing the infosec community for increasingly deceptive and manipulative interactions with our adversaries.

On the StrongPity Waterhole Attacks Targeting Italian and Belgian Encryption Users

Mon, 10/03/2016 - 19:40

The StrongPity APT is a technically capable group operating under the radar for several years. The group has quietly deployed zero-day in the past, effectively spearphished targets, and maintains a modular toolset. What is most interesting about this group’s more recent activity however, is their focus on users of encryption tools, peaking this summer. In particular, the focus was on Italian and Belgian users, but the StrongPity watering holes affected systems in far more locations than just those two. Adding in their creative waterholing and poisoned installer tactics, we describe the StrongPity APT as not only determined and well-resourced, but fairly reckless and innovative as well.

Encryption Tools

Clearly this APT is interested in encrypted data and communications. The tools targeted by this group enable practices for securing secrecy and integrity of data. For example, WinRAR packs and encrypts files with strong suites like AES-256, and TrueCrypt encrypts full hard drives all in one swoop. Both WinRAR and TrueCrypt help provide strong and reliable encryption. WinRAR enables a person to encrypt a file with AES-256 in CBC mode with a strong PBKDF2 HMAC-SHA256 based key. And, TrueCrypt provides an effective open-source full disk encryption solution for Windows, Apple, Linux, and Android systems. Using both of these tools together, a sort of one off, poor man’s end-to-end encryption can be maintained for free by putting these two solutions together with free file sharing services.

Other software applications help to support encrypted sessions and communications. Well known applications supporting end-to-end encryption are used by hundreds of millions of folks, sometimes unknowingly, every day. IM clients like Microsoft’s Skype implement 256-bit AES encrypted communications, while Putty, Winscp and Windows Remote Desktop help provide private communications and sessions with fully encrypted communications as well. Most of these communications across the wire are currently unbreakable when intercepted, at least, when the applications are configured properly.

Summer 2016 Watering Hole Resources and Trickery – WinRAR and TrueCrypt

This actor set up a particularly clever site to deliver trojanized WinRAR installers in the summer of 2016, appears to have compromised another, and this activity reminds us somewhat of the early 2014 Crouching Yeti activity. Much of the Crouching Yeti intrusions were enabled by trojanizing legitimate ICS-related IT software installers like SCADA environment vpn client installers and industrial camera software driver installers. Then, they would compromise the legitimate company software distribution sites and replace the legitimate installers with the Crouching Yeti trojanized versions. The tactics effectively compromised ICS and SCADA related facilities and networks around the world. Simply put, even when visiting a legitimate company distribution site, IT staff was downloading and installing ICS-focused malware. StrongPity’s efforts did much the same.

In the case of StrongPity, the attackers were not focused on ICS or SCADA. They set up a domain name (ralrab[.]com) mimicking the legitimate WinRAR distribution site (rarlab[.]com), and then placed links on a legitimate “certified distributor” site in Europe to redirect to their poisoned installers hosted on ralrab[.]com. In Belgium, the attackers placed a “recommended” link to their ralrab[.]com site in the middle of the localized WinRAR distribution page on winrar[.]be. The big blue recommended button (here in French) linked to the malicious installer, while all the other links on the page directed to legitimate software:

Winrar[.]be site with “recommended link” leading to malicious ralrab[.]com

The winrar[.]be site evaluated what “recommended” package a visitor may need based on browser localization and processor capability, and accordingly offered up appropriate trojanized versions. Installer resources named for french and dutch versions, along with 32-bit versus 64-bit compiled executables were provided over the summer:

  • hxxp://www.ralrab[.]com/rar/winrar-x64-531.exe
  • hxxp://www.ralrab[.]com/rar/winrar-x64-531fr.exe
  • hxxp://www.ralrab[.]com/rar/winrar-x64-531nl.exe
  • hxxp://www.ralrab[.]com/rar/wrar531.exe
  • hxxp://www.ralrab[.]com/rar/wrar531fr.exe
  • hxxp://www.ralrab[.]com/rar/wrar531nl.exe
  • hxxp://ralrab[.]com/rar/winrar-x64-531.exe
  • hxxp://ralrab[.]com/rar/winrar-x64-531nl.exe
  • hxxp://ralrab[.]com/rar/wrar531fr.exe
  • hxxp://ralrab[.]com/rar/wrar531nl.exe
  • hxxp://ralrab[.]com/rar/wrar53b5.exe

Directory listing, poisoned StrongPity installers, at rarlrab[.]com

The first available visitor redirects from winrar[.]be to ralrab[.]com first appeared on May 28th, 2016, from the dutch speaking version of the site. And around the same time, another “certified distributor” winrar[.]it served trojanized installers as well. The major difference here is that we didn’t record redirections to ralrab[.]com, but it appears the site directly served StrongPity trojanized installers:

  • hxxps://www.winrar[.]it/prelievo/WinRAR-x64-531it.exe
  • hxxps://www.winrar[.]it/prelievo/WRar531it.exe

The site started serving these executables a couple of days earlier on 5/24, where a large majority of Italian visitors where affected.

Download page, winrar[.]it

Quite simply, the download links on this site directed visitors to trojanized WinRAR installers hosted from the site itself. It’s interesting to note that both of the sites are “distributors”, where the sites are owned and managed not by rarlabs, but by local owners in individual countries.

StrongPity also directed specific visitors from popular, localized software sharing sites directly to their trojanized installers. This activity continued into late September 2016. In particular, the group redirected visitors from software aggregation and sharing site tamindir[.]com to their attacker-controlled site at true-crypt[.]com. The StrongPity controlled Truecrypt site is a complete rip of the legitimate site, now hosted by Sourceforge. Here is the Tamindir truecrypt page, looks harmless enough.

TrueCrypt page, tamindir software sharing site

Unlike the newer poisoned WinRAR installers, StrongPity hosted several  Much like the poisoned WinRAR installers, multiple filenames have been used to keep up with visitor interests. Visitors may have been directed to the site by other means and downloaded directly from the ripped and persuasive site.

true-crypt[.]com malicious StrongPity distribution site

At the very bottom of the page, there are a couple of links to the poisoned installers:

  • hxxp://www.true-crypt[.]com/download/TrueCrypt-Setup-7.1a.exe
  • hxxp://true-crypt[.]com/files/TrueCrypt-7.2.exe

Referrers include these localized software aggregates and sharers:

  • gezginler[.]net/indir/truecrypt.html
  • tamindir[.]com/truecrypt/indir

It’s interesting that Ksn recorded appearance of the the file on two unique systems in December 2015, a third in January 2016, all in Turkey, and then nothing until May 2016. Then, deployment of the installers continued mostly within Turkey in July and September 2016.

Summer 2016 Watering Hole Victim Geolocations – WinRAR and TrueCrypt

Over the course of a little over a week, malware delivered from appeared on over 600 systems throughout Europe and Northern Africa/Middle East. Likely, many more infections actually occurred. Accordingly, the country with the overwhelming number of detections was in Italy followed by Belgium and Algeria. The top countries with StrongPity malware from the site from May 25th through the first few days of June are Italy, Belgium, Algeria, Cote D’Ivoire, Morroco, France, and Tunisia.

winrar[.]it StrongPity component geolocation distribution

In a similar time-span, the over sixty visitors redirected from to for malicious file download were overwhelmingly located in one country. The top countries directed to StrongPity malware from the site from May 25th through the first few days of June are Belgium, Algeria, Morroco, Netherlands, Canada, Cote D’Ivoire, and Tunisia.

winrar[.]be StrongPity component geolocation distribution

StrongPity previously set up TrueCrypt themed watering holes in late 2015. But their offensive activity surged in late summer 2016. The group set up a site directly pulled from the contents of the legitimate TrueCrypt website. From mid July to early September, dozens of visitors were redirected from tamindir[.]com to true-crypt[.]com with unsurprisingly almost all of the focus on systems in Turkey, with victims in the Netherlands as well.

tamindir[.]com to true-crypt[.]com poisoned TrueCrypt installer redirects

StrongPity Malware

The StrongPity droppers were often signed with unusual digital certificates, dropping multiple components that not only provide complete control of the victim system, but effectively steal disk contents, and can download components for further collection of various communications and contacts. Because we are talking about StrongPity watering holes, let’s take a quick look at what is being delivered by the group from these sites.

When we count all systems from 2016 infected with any one of the StrongPity components or a dropper, we see a more expansive picture. This data includes over 1,000 systems infected with a StrongPity component. The top five countries include Italy, Turkey, Belgium, Algeria, and France.

In the case of the winrar[.]be/ralrab[.]com watering hole malware, each one of the six droppers that we observed created a similar set of dropped components on disk. And, in these cases, the attackers did not re-use their fake digital certificates. In addition to installing the legitimate version of WinRAR, the dropper installed the following StrongPity components:

  • %temp%\procexp.exe
  • %temp%\sega\
  • nvvscv.exe
  • prst.dll
  • wndplyr.exe
  • wrlck.dll

Of these files, two are configurable and encrypted with the same keyless cipher, “” and “”. While one maintains several callback c2 for the backdoor to fetch more instructions and upload installed software and file paths, the other maintains something a bit more unusual. “” maintains an encrypted list of programs that maintain encrypted connections. This simple encoding takes the most significant nibble for each character, swaps the nibbles of that byte, and xors the result against the original value. Its code looks something like this:

  • x = s[i];
  • j = ((x & 0xF0)>>4);
  • y = x ^ j;

Using that cipher in the ralrab[.]com malware, the package is configured to seek out several crypto-enabled software applications, highlighting the group’s interest in users of more encryption-supported software suites.

  • putty.exe (a windows SSH client)
  • filezilla.exe (supports ftps uploads)
  • winscp.exe (a windows secure copy application, providing encrypted and secure file transfer)
  • mstsc.exe (Windows Remote Desktop client, providing an encrypted connection to remote systems)
  • mRemoteNG.exe (a remote connections manager supporting SSH, RDP, and other encrypted protocols)

Also included in StrongPity components are keyloggers and additional data stealers.


Widely available, strong cryptography software tools help provide secure and private communications that are now easily obtained and usable. In the summer of 2016, multiple encryption-enabled software applications were targeted with watering hole, social engineering tactics, and spyware by the StrongPity APT. While watering holes and poisoned installers are tactics that have been effectively used by other APT, we have never seen the same focus on cryptographic-enabled software. When visiting sites and downloading encryption-enabled software, it has become necessary to verify the validity of the distribution site and the integrity of the downloaded file itself. Download sites not using PGP or strong digital code signing certificates need to re-examine the necessity of doing so for their own customers. We have seen other APT such as Crouching Yeti and Darkhotel distribute poisoned installers and poisoned executable code, then redistribute them through similar tactics and over p2p networks. Hopefully, simpler verification systems than the current batch of PGP and SSL applications will arise to be adopted in larger numbers. Until then, strong anti-malware and dynamic whitelisting solutions will be more necessary than ever.

For more details on APT tactics like StrongPity watering holes, contact

Polyglot – the fake CTB-locker

Mon, 10/03/2016 - 04:58

Cryptor malware programs currently pose a very real cybersecurity threat to users and companies. Clearly, organizing effective security requires the use of security solutions that incorporate a broad range of technologies capable of preventing a cryptor program from landing on a potential victim’s computer or reacting quickly to stop an ongoing data encryption process and roll back any malicious changes. However, what can be done if an infection does occur and important data has been encrypted? (Infection can occur on nodes that, for whatever reason, were not protected by a security solution, or if the solution was disabled by an administrator.) In this case, the victim’s only hope is that the attackers made some mistakes when implementing the cryptographic algorithm, or used a weak encryption algorithm.

A brief description

The cryptor dubbed Polyglot emerged in late August. According to the information available to us, it is distributed in spam emails that contain a link to a malicious RAR archive. The archive contains the cryptor’s executable code.

Here are some examples of the links used:



When the infected file is launched, nothing appears to happen. However, the cryptor copies itself under random names to a dozen or so places, writes itself to the autostart folder and to TaskScheduler. When the installation is complete, file encryption starts. The user’s files do not appear to change (their names remain the same), but the user is no longer able to open them.

When encryption is complete, the cryptor changes the desktop wallpaper, (interestingly, the wallpaper image is unique to each victim) and displays the ransom message.

The cryptor’s main window

New desktop wallpaper with the “open key” block unique to each victim computer

The user is offered the chance to decrypt several files for free.

The free trial decryption window

After this, the user is told to pay for file decryption in bitcoins. The cryptor contacts its C&C, which is located on the Tor network, for the ransom sum and the bitcoin address where it should be sent.

C&C communication window

From this moment on, the cryptor allows the user to check the ransom payment status on the C&C.

Ransom payment details

If the ransom is not paid on time, the cryptor notifies the user that it’s no longer possible to decrypt their files, and that it is about to ‘self-delete’.

Last window displayed by Polyglot

Imitating CTB-Locker

Initially, this cryptor caught our attention because it mimics all the features of another widespread cryptor – CTB-Locker (Trojan-Ransom.Win32.Onion). The graphical interface window, language switch, the sequence of actions for requesting the encryption key, the payment page, the desktop wallpapers – all of them are very similar to those used by CTB-Locker. The visual design has been copied very closely, while the messages in Polyglot’s windows have been copied word for word.

The main graphical interface windows:

Polyglot CTB-Locker

List of encrypted files:

Polyglot CTB-Locker

Window for the trial decryption of 5 random files:

Polyglot CTB-Locker

The private key request window:

Polyglot CTB-Locker

The desktop wallpapers:

Polyglot CTB-Locker

The ‘connection failed’ error message:

Polyglot CTB-Locker

Offline decryption instructions:

Polyglot CTB-Locker

The similarities do not stop there. Even the encryption algorithms used by the cybercriminals have clearly been chosen to imitate those used in CTB-Locker.

Polyglot CTB-Locker Algorithms used for file encryption File content is packed into a ZIP archive and then encrypted with AES-256. File content is compressed with Zlib and then encrypted with AES-256. Algorithms used while working with the keys ECDH (elliptic curve Diffie-Hellman), curve25519, SHA256. ECDH (elliptic curve Diffie-Hellman), curve25519, SHA256. Extensions of encrypted files File extensions are not changed. File extensions are changed, depending on version:
– .ctbl
– .ctb2
– 7 random lower-case Latin symbols Demo decryption 5 files are decrypted for free as a demo. Their decryption keys and file names are saved in the registry. 5 files are decrypted for free as a demo. Their decryption keys are only stored in the RAM memory while the process is running. C&C location C&C is in the Tor network, communication is via a public tor2web service. C&C is in the Tor network, communication is via a Tor client integrated into the Trojan, or (in some versions of CTB-Locker) via a public tor2web service. Traffic protection / obfuscation Bitwise NOT operation. AES encryption.

That said, we should note the following: a detailed analysis has revealed that Polyglot was developed independently from CTB-Locker; in other words, no shared code has been detected in the two Trojans (except the publicly available DLL code). Perhaps the creators of Polyglot wanted to disorient the victims and researchers, and created a near carbon copy of CTB-Locker from scratch to make it look like a CTB-Locker attack and that there was no hope of getting files decrypted for free.

C&C communication

The Trojan contacts the C&C server located on Tor via a public tor2web service, using the HTTP protocol.

Prior to each of the below data requests, a POST request is sent with the just one parameter: “live=1”.

Request 1.

At the start of operation, the Trojan reports the successful infection to the C&C. The following data is sent to the C&C:

“ip”:””,         //ip address of the infected computer
“method”:”register”,         //action type. “register” = Trojan informs C&C of new infection
“uid”:”xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,         //Infected computer’s ID
“version”:”10f”,         //Trojan version contained in its body
“info”:”Microsoft (build xxxx), 64-bit”,         //OS version on the infected computer
“description”:” “,         //Always a whitespace (” “)
“start_time”:”14740xxxxx”,         //Trojan’s start time
“end_time”:”0″,         //Encryption finish time. 0 = no encryption has run yet
“user_id”:”5″         //Number hardwired in the sample

This data block is passed through a bitwise NOT operation, encoded into Base64 and sent to the C&C in a POST request.

Contents of the sent request

Parameters of the POST request:

signature – CRC32 from the sent data
ver – Trojan version
gcdata – data, with contents as described above.

Request 1 and the reply received from the C&C

Request 2.

When the Trojan has finished encrypting the user’s data, it sends another request to the C&C. The content of the request is identical to that of request 1 except the field “end_time”, which now shows the time encryption was completed.

Request 3.

This is sent to the C&C to request the bitcoin address for payment and the ransom sum to be paid.


The C&C replies to this request with the following data:

“address”:”xxxxxxxx”,         //bitcoin address (may vary)
“btc”:0.7,         //amount to be paid in BTC (may vary)
“usd”:319.98         //amount to be paid in USD (may vary)

Request 4.

This is sent to request a file decryption key from the C&C.


Request 5.

The Trojan reports that data decryption has been completed and states the number of decrypted files to the C&C.


Description of the encryption algorithm

During our analysis of the malicious code, it became evident that the Trojan encrypts files in three stages, creating intermediate files:

  • First, the original file is placed in a password-protected ZIP archive. The archive has the same name as the original file plus the extension “a19”;
  • Polyglot encrypts the password-protected archive with the AES-256-ECB algorithm. The resulting file again uses the name of the original file, but the extension is now changed to “ap19”;
  • The Trojan deletes the original file and the file with the extension “a19”. The extension of the resulting file is changed from “ap19” to that of the original file.

Flowchart of the search and file encryption actions performed by Polyglot

A separate AES key is generated for each file, and is nothing more than a ‘shared secret’ generated according to the Diffie-Hellman protocol on an elliptic curve. However, first things first.

Before encrypting any files, the Trojan generates two random sequences, each 32 bytes long. The SHA256 digests of each sequence become the private keys s_ec_priv_1 and s_ec_priv_2. Then, the Bernstein elliptic curve (Curve25519) is used to obtain public keys s_ec_pub_1 and s_ec_pub_2 (respectively) from each private key.

The Trojan creates the structure decryption_info and writes the following to it: a random sequence used as the basis for creating the key s_ec_priv_1, the string machine_guid taken from the registry, and a few zero bytes.

struct decryption_info

        char s_rand_str_1[32];
        char machine_guid[36];
        char zeroes[12];

Using the private key s_ec_priv_2 and the cybercriminal’s public key mal_pub_key produces the shared secret mal_shared_secret = ECDH(s_ec_priv_2, mal_pub_key). The structure decryption_info is encrypted with algorithm AES-256-ECB using a key that is the SHA256 digest of this secret. For convenience, we shall call the obtained 80 bytes of the encrypted structure encrypted_info.

Only when Polyglot obtains the encrypted_info value does it proceed to generate the session key AES for the file. Using the above method, a new pair of keys is generated, f_priv_key and f_pub_key. Using f_priv_key and s_ec_pub_1 produces the shared secret f_shared_secret = ECDH(f_priv_key, s_ec_pub_1).

The SHA256 digest of this secret will be the AES key with which the file is encrypted.

To specify that the file has already been encrypted and that it’s possible to decrypt the file, the cybercriminals write the structure file_info to the start of each encrypted file:

struct file_info

        char label[4] = {‘H’,’U’, ‘I ‘, 0x00};
        uint32_t label2 = 1;
        uint64_t archive_size;
        char f_pub_key[32];
        char s_ec_pub_1[32];
        char s_ec_pub_2[32];
        char encrypted_info[80];

The elliptic curve, the Diffie-Hellman protocol, AES-256, a password-protected archive – it was almost flawless. But not quite, because the creator of Polyglot made a few mistakes during implementation. This gave us the opportunity to help the victims and restore files that had been encrypted by Polyglot.

Mistakes made by the creators

As was mentioned earlier, all the created keys are based on a randomly generated array of characters. Therefore, the strength of the keys is determined by the generator’s strength. And we were surprised to see the implementation of this generator:

A graphical representation of the random sequence generation procedure

Let’s convert this function into pseudocode so it’s easier to follow:

Please note that when another random byte is selected, the entire result of the function rand() is not used, just the remainder of dividing the result by 32. Only the cybercriminal knows why they decided to make the random string this much weaker – an exhaustive search of the entire set of the possible keys produced by such a pseudo-random number generator will only take a few minutes on a standard PC.

Taking advantage of this mistake, we were able to calculate the AES key for an encrypted file. Although there was a password-protected archive below the layer of symmetric encryption, we already knew that the cybercriminal had made another mistake.

Let’s look at how the archive key is generated:

We can see that the key length is only 4 bytes; moreover, these are specific bytes from the string MachineGuid, the unique ID assigned to the computer by the operating system. Furthermore, a slightly modified MachineGuid string is displayed in the requirements text displayed to the victim; this means that if we know the positions in which the 4 characters of the ZIP archive password are located, we can easily unpack the archive.

The MachineGuid string displayed in the requirements screen


Files that are encrypted by this cryptor can be decrypted using Kaspersky Lab’s free anti-cryptor utility RannohDecryptor Version

All Kaspersky Lab solutions detect this cryptor malware as:


c8799816d792e0c35f2649fa565e4ecb – Trojan-Ransom.Win32.Polyglot.a

TeamXRat: Brazilian cybercrime meets ransomware

Thu, 09/29/2016 - 12:42

Brazilian cybercriminals are notorious for their ability to develop banking trojans but now they have started to focus their efforts in new areas, including ransomware. We discovered a new variant of a Brazilian-made ransomware, Trojan-Ransom.Win32.Xpan, that is being used to infect local companies and hospitals, directly affecting innocent people, encrypting their files using the extension “.___xratteamLucked” and asking to pay the ransom.

The Kaspersky Anti-Ransom team decrypted the Xpan Trojan, allowing them to rescue the files of a Hospital in Brazil that had fallen victim to this Ransomware family.

Actually, this is not the first ransomware to come out of Brazil. In the past, we investigated TorLocker and its flawed encryption, which was created and negotiated worldwide by a Brazilian cybercriminal. We also saw a lot of copycats use HiddenTear in local attacks. Trojan Ransom Xpan was created by an organized gang, which used targeted attacks via RDP that abused weak passwords and wrong implementations.

In this post, we’ll explain this new Ransomware family and how Brazilian coders are creating new ransomware from scratch.

The group behind the attack

The group identifies itself as “TeamXRat“and “CorporacaoXRat“.
(Translating from Portuguese to English as “CorporationXRat”)

Their first ransom trojan consisted of using a simple XOR based encryption, described by some victims here (most of the victims are from Brazil). The new version of Xpan Ransomware shows that the cybercriminals behind it have improved the code to make it more complex, also switching the encryption scheme.

The ransom texts used by the group are written in Portuguese from Brazil. The messages do not inform how much the victim has to pay to retrieve their files, nor the payment method required (which is usually Bitcoins). Instead, they instruct the victim to send an email to one of the anonymous email services Mail2Tor or For example,, and providing the public key used by the ransomware to encrypt the files. Older versions of this ransomware also used e-mail accounts from another Email service – Protonmail, such as, currently deactivated.

When the victim gets in touch with the group, they start to negotiate the ransom payment. All communication is in Portuguese and they request 1 btc (about 603 USD) to decrypt the files. The group also claims that the payment is a “donation” arguing that “they exploited flaws in your system and carried out the attack in order to make sure you increase your security”. Finally, the cybercriminals also offer to decrypt one file for free:

“For me only the ‘donation’ is important. Not your files. If your files are important to you, I advise you to make the donation; otherwise, you’ll lose all your files”

Xpan, how it works

The sample is UPX packed. Once executed it checks the default language of the infected system set in the following registry key: HKLM\SYSTEM\CONTROLSET001\CONTROL\NLS\LOCALE

In addition, it’s able to query local time and obtain the computer name from the registry using several commands like net.exe, sc.exe, and taskkill.exe. Interestingly, it also deletes any Proxy setting defined in the system, located in: HKCU\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\INTERNET SETTINGS\ZONEMAP.

Since the targets are companies and corporations, the group might use proxies blocking access to certain Web resources. It is highly probable that this technique is used to “set victim’s free” while emailing the attackers or accessing BTC resources online.

After completing its execution, the ransomware displays the following image in the affected system:

“All your files were encrypted using a RSA 2048 bits encryption”

The sample is written in C++ and uses STL, being built as a console application. During the lenght of its execution, it logs all its actions to the console, only to clear it once the encryption process has finished.

The operation of this malware is ‘guided’ by the configuration data block stored inside the body of the Trojan:

Decrypted configuration block

The configuration contains the following details:

  • Drive letters which will be processed;
  • Blacklisted substrings: the files whose path contain any of these strings will not be encrypted;
  • Ransomware text message for the victim;
  • Extension of the encrypted files (in this case, .____xratteamLucked);
  • Name of the file with ransom notes;
  • Console commands to be executed prior to the process of file encryption;
  • Console commands to be executed after the encryption;
  • A public RSA-2048 key in the MSBLOB format.

Part of the pseudocode of the main procedure

From Xorist to Xpan

A previous ransomware sample that was believed to be part of the TeamXRat ransomware campaign used a simple encryption algorithm known as TEA (or Tiny Encryption Algorithm). After comparing this original version (dubbed Xorist) against this new Xpan variant, we could observe that now they are using an AES-256 encryption scheme.

Xorist ransomware TEA constant

Xpan ransomware now has evolved to use AES-256 encryption

Xorist Xpan Will automatically start when user is logged in. It uses the following registry key for persistence: SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run No persistence used. Tiny Encryption Algorithm AES-256 ASM, MS Linker C++, MinGW compiler Includes a list of files that are to be encrypted. Will encrypt everything except .exe and .dll files and files with blacklisted substrings in the path.

The developers have clearly shifted their development procedures in the Xpan malware. It’s typical for cybercriminals to evolve their techniques once a decryption method has been found for their ransomware, or that specific variant is widely detected.

List of file extensions that Xorist ransomware will search and encrypt

File Encryption

The trojan uses the implementation of cryptographic algorithms provided by MS CryptoAPI. The files are encrypted by AES-256 in CBC mode.

There are 2 known versions of this trojan that can be distinguished by their extensions. The 1st one uses “___xratteamLucked” (3 ‘_’ symbols) and the second one – “____xratteamLucked” (4 ‘_’ symbols).

These 2 versions employ different techniques to encrypt the files, which we will describe in more detail.

Version 1 (3 ‘_’ symbols in the extension)

The trojan generates a single 255-symbol password for all files. This password is encrypted by RSA-2048 and put into the ransom note (concatenated with the public key). Then the trojan produces a 256-bit key from this password using the API CryptDeriveKey; this key will be used to encrypt all files.

When processing each file, the malware adds the string ‘NMoreira’ to the beginning of the original file and encrypts the file content by 245-byte blocks using the AES-256 algorithm in CBC mode. Each block is additionally XOR’ed with a random byte which is stored before the padding of the corresponding block.

Version 2 (4 ‘_’ symbols in the extension)

For each file, the trojan generates a new 255-symbol password, encrypts this password by RSA-2048 and puts this data into the beginning of each encrypted file. Then, the trojan produces a 256-bit key from this password using the API CryptDeriveKey, and uses this key to encrypt the original file content (AES-256 CBC).

File search and encryption is carried out by multiple threads, each thread processes its disk.

Ransomware in action: console output inform the files encrypted

After encryption is completed, the malware will change the wallpaper in the desktop and display this file, with the ransom note:

The ransom note, in Portuguese

Before encrypting the data in the affected system, the ransomware executes the following commands, aiming to stop popular database services, to be sure that database files will be encrypted as well, so they cause a greater damage to the victim:

echo Iniciando pre comandos

echo Parando Firbird
sc config FirebirdServerDefaultInstance start=disabled
taskkill /IM fb_inet_server.exe /F
net stop FirebirdServerDefaultInstance

echo parando SQL SERVE

taskkill /IM sqlservr.exe /F
sc config MSSQLSERVER start=disabled
sc config MSSQL$SQLEXPRESS start=disabled

echo parando poostgree
taskkill /IM pg_ctl.exe /F
sc config postgresql-9.0 start=disabled
net stop postgresql-9.0

After the execution, the ransomware deletes itself from the system, to remove the original infector:

@echo off
  goto Delete
  @timeout 5
  @del “path\sample_name.exe”
  if exist “path\sample_name.exe”
  goto WaitAndDelete
  @del %0

After the encryption has finished, the trojan modifies the registry to add a custom handler for the action of double-clicking on any of the encrypted files. As a result, when the victim clicks on a file with the extension “.____xratteamLucked“, the command stored in the registry is executed, and this command shows the ransom notes in a new window using msg.exe (a standard utility which is a part of Windows distribution).

Windows Registry modified by the ransom

How they attack

Most of the attacks performed by TeamXRat are performed manually, installing the ransomware in the hacked server. To achieve that, they perform RDP (Remote Desktop Protocol) brute force attacks. Connecting remote desktop servers directly to the Internet is not recommended and brute forcing them is nothing new; but without the proper controls in place to prevent or at least detect and respond to compromised machines, brute force RDP attacks are still relevant and something that cybercriminals enjoy. Once the server is compromised, the attacker manually disables the Antivirus product installed on the server and proceeds with the infection itself.

We are also aware that vulnerabilities such as MS15-067 and MS15-030 in the RDP protocol, which allow remote code execution if an attacker sends a specially crafted sequence of packets to a targeted system, can be used by cybercriminals if a server is not patched and exposed to attacks.

As we saw in the recent xDedic research, vulnerable servers with exposed RDP connections are very valuable assets in the hands of cybercriminals. Not surprisingly, Brazil was the country with the most compromised servers being offered in the underground market to any cybercriminal.

xDedic: compromised Brazilian RDP servers were available in the underground market

Decryption: we can help!

If the victim pays the ransom, the cybercriminals will send this tool to decrypt the files:

Decryption tool sent by the bad guy after payment

But the good news is that the Kaspersky Anti-Ransom team was able to break the encryption used by the Xpan Trojan. This effort made possible the decryption of files belonging to a Hospital in Brazil, which was hit by this Ransomware family.

If you’re a victim of this new Ransomware family and need help to decrypt your files, please DON’T PAY the ransom. Instead, contact us via support.


As we can see, Brazilian bad guys are now diversifying their “business” with new ransomware families developed from scratch, abandoning older versions that used XOR encryption and adopting new, more robust encryption algorithms. This is a clear signal that they have started to explore new schemes with new targets and newer types of attacks.

As we forecasted in the beginning of this year, we expect ransomware attacks to gain ground on banking trojans and to transition into other platforms. Ransomware has two advantages over traditional banking threats: direct monetization using an anonymous payment system (usually Bitcoin), and relatively low cost per victim. Certainly, this is very attractive to Brazilian crooks, well-known for their banking trojans development. Brazilian law enforcement is very good at catching criminals (although they are not always convicted and imprisoned) by “following the money”, something that we know it’s not entirely possible for Bitcoin payments.

We detect this new threat as
Trojan-Ransom.Win32.Xpan.a and PDM:Trojan.Win32.Generic.

We’ll keep an eye out or new variants, which surely will appear from same or other threat actors.

MD5 reference: 34260178f9e3b2e769accdee56dac793

Future attack scenarios against ATM authentication systems

Thu, 09/22/2016 - 05:57

A lot has already been said about current cyber threats facing the owners of ATMs. The reason behind the ever-growing number of attacks on these devices is simple: the overall level of security of modern ATMs often makes them the easiest and fastest way for fraudsters to access the bank’s money. Naturally, the banking industry is reacting to these attacks by implementing a range of security measures, but the threat landscape is continually evolving. In order to prepare banks for what they should expect to see from criminals in the near future, we’ve prepared an overview report of future cyberthreats to ATMs. The report will – we hope – help the industry to better prepare for a new generation of attack tools and techniques.

The report comprises two papers in which we analyze all existing methods of authentication used in ATMs and those expected to be used in the near future, including: contactless authentication through NFC, one-time password authentication and biometric authentication systems, as well as potential vectors of attacks using malware, through to network attacks and attacks on hardware components.

We looked into what is going on underground around these technologies and were surprised to discover that there are twelve manufacturers out there that are already offering fake fingerprint scanners, otherwise known as biometric skimmers. There are also at least three other vendors researching devices that will be able to illegally obtain data from palm vein and iris recognition systems.

This is a major trend, because the problem with biometrics is that, unlike passwords or pin codes which can be easily modified in the event of compromise, it is impossible to change your fingerprint or iris image. Thus if your data is compromised once, it won’t be safe to use in the future. That is why it is extremely important to keep such data secure and transmit it in a secure way. Biometric data is also recorded in modern passports – called e-passports – and visas. So, if an attacker steals an e-passport, they not only steal the document, but also that person’s biometric data. As a result they steal a person’s identity.

The biometric data can also be accessed by criminals as a result of hacking into a bank’s infrastructure, which is also a major issue: if you lose the biometric database of your clients it won’t be possible to solve this problem just by recalling compromised payment cards. This is an unrecoverable loss and thus it is a kind of threat that the industry has never experienced before.

In general, network-based attacks against ATMs will be a headache for the security personnel of financial organizations in the coming years simply because, based on our penetration testing experience, the network infrastructure of a bank is very often built in a way that a hacker can exploit to gain access and take control of some critical parts of the network, including the network of ATMs. And this situation is not going to change any time soon, due to many reasons, one of which is the sheer size of financial organizations’ networks and the time-consuming and expensive task of upgrading them.

Nevertheless, by publishing this report we’d like to draw attention to the problem of ATM security now and in the near future, and to speed up the development of a truly secure ecosystem around these devices.

Read the full report here

Read the description of attacks here

Contact Us Should you want to learn more on how to hack ATMs as well as ensure reliable protection, contact us filling in the form below!
  • First Name*
  • Second Name*
  • Email*
  • Company*
  • Number of PCs in your Company*
  • CountryUnited StatesUnited KingdomRussiaAfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAntigua and BarbudaArgentinaArmeniaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBruneiBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaColombiaComorosCongo, Democratic Republic of theCongo, Republic of theCosta RicaCôte d'IvoireCroatiaCubaCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFaroe IslandsFijiFinlandFranceFrench PolynesiaGabonGambiaGeorgiaGermanyGhanaGreeceGreenlandGrenadaGuamGuatemalaGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsraelItalyJamaicaJapanJordanKazakhstanKenyaKiribatiNorth KoreaSouth KoreaKosovoKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMauritaniaMauritiusMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNew ZealandNicaraguaNigerNigeriaNorthern Mariana IslandsNorwayOmanPakistanPalauPalestine, State ofPanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarRomaniaRwandaSaint Kitts and NevisSaint LuciaSaint Vincent and the GrenadinesSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbiaSeychellesSierra LeoneSingaporeSint MaartenSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSpainSri LankaSudanSudan, SouthSurinameSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTuvaluUgandaUkraineUnited Arab EmiratesUruguayUzbekistanVanuatuVatican CityVenezuelaVietnamVirgin Islands, BritishVirgin Islands, U.S.YemenZambiaZimbabwe
jQuery(document).bind('gform_post_render', function(event, formId, currentPage){if(formId == 13) {} } );jQuery(document).bind('gform_post_conditional_logic', function(event, formId, fields, isInit){} ); jQuery(document).ready(function(){jQuery(document).trigger('gform_post_render', [13, 1]) } );

The banker that can steal anything

Tue, 09/20/2016 - 06:58

In the past, we’ve seen superuser rights exploit advertising applications such as Leech, Guerrilla, Ztorg. This use of root privileges is not typical, however, for banking malware attacks, because money can be stolen in numerous other ways that don’t require exclusive rights. However, in early February 2016, Kaspersky Lab discovered Trojan-Banker.AndroidOS.Tordow.a, whose creators decided that root privileges would come in handy. We had been watching the development of this malicious program closely and found that Tordow’s capabilities had significantly exceeded the functionality of most other banking malware, and this allowed cybercriminals to carry out new types of attacks.


A Tordow Infection begins with the installation of a popular app, such as VKontakte, DrugVokrug, Pokemon Go, Telegram, Odnoklassniki or Subway Surf. In this particular case, we’re not talking about the original apps but copies that are distributed outside the official Google Play store. Malware writers download legitimate applications, disassemble them and add new code and new files.

Code added to a legitimate application

Anyone who possesses even a little knowledge of Android development can do it. The result is a new app that is very similar to the original, performs all the stated legitimate functions, but that also has the malicious functionality that the attackers need.

How it works

In the case in question, the code embedded in the legitimate app decrypts the file added by the cybercriminals in the app’s resources and launches it.

The launched file calls the attacker’s server and downloads the main part of Tordow, which contains links to download several more files – an exploit to gain root privileges, new versions of malware, and so on. The number of links may vary depending on the criminals’ intentions; moreover, each downloaded file can also download from the server, decrypt and run new components. As a result, the infected device is loaded with several malicious modules; their number and functionality also depend on what the Tordow owners want to do. Either way, the attackers get the chance to remotely control the device by sending commands from the C&C.

As a result, cybercriminals get a full set of functions for stealing money from users by applying the methods that have already become traditional for mobile bankers and ransomware. The functionality of the malicious app includes:

  • Sending, stealing, deleting SMS.
  • Recording, redirecting, blocking calls.
  • Checking the balance.
  • Stealing contacts.
  • Making calls.
  • Changing the C&C.
  • Downloading and running files.
  • Installing and removing applications.
  • Blocking the device and displaying a web page specified by a malicious server.
  • Generating and sending a list of files contained on the device; sending and renaming of files.
  • Rebooting a phone.
Superuser rights

In addition to downloading modules belonging to the banking Trojan, Tordow (within the prescribed load chain of modules) also downloads a popular exploit pack to gain root privileges, which provides the malware with a new attack vector and unique features.

Firstly, the Trojan installs one of the downloaded modules in the system folder, which makes it difficult to remove.

Secondly, using superuser rights the attackers steal the database of the default Android browser and the Google Chrome browser if it’s installed.

Code for sending data from browsers to the server

These databases contain all the logins and passwords stored by the user in the browser, browsing history, cookies, and sometimes even saved bank card details.

Login and password from a specific site in the browser database

As a result, the attackers can gain access to several of the victim’s accounts on different sites.

And thirdly, the superuser rights make it possible to steal almost any file in the system – from photos and documents to files containing mobile app account data.

These attacks can result in the theft of huge amounts of critical user data. We recommend that users do not install apps from unofficial sources and use antivirus solutions to protect Android-based devices.

Fooling the ‘Smart City’

Thu, 09/15/2016 - 04:59

The concept of a smart city involves bringing together various modern technologies and solutions that can ensure comfortable and convenient provision of services to people, public safety, efficient consumption of resources, etc. However, something that often goes under the radar of enthusiasts championing the smart city concept is the security of smart city components themselves. The truth is that a smart city’s infrastructure develops faster than security tools do, leaving ample room for the activities of both curious researchers and cybercriminals.

Smart Terminals Have Their Weak Points Too

Parking payment terminals, bicycle rental spots and mobile device recharge stations are abundant in the parks and streets of modern cities. At airports and passenger stations, there are self-service ticket machines and information kiosks. In movie theaters, there are ticket sale terminals. In clinics and public offices, there are queue management terminals. Even some paid public toilets now have payment terminals built into them, though not very often.

Ticket terminals in a movie theater

However, the more sophisticated the device, the higher the probability that it has vulnerabilities and/or configuration flaws. The probability that smart city component devices will one day be targeted by cybercriminals is far from zero. Сybercriminals can potentially exploit these devices for their ulterior purposes, and the scenarios of such exploitation come from the characteristics of such devices.

  • Many such devices are installed in public places
  • They are available 24/7
  • They have the same configuration across devices of the same type
  • They have a high user trust level
  • They process user data, including personal and financial information
  • They are connected to each other, and may have access to other local area networks
  • They typically have an Internet connection

Increasingly often, we see news on another electronic road sign getting hacked and displaying a “Zombies ahead” or similar message, or news about vulnerabilities detected in traffic light management or traffic control systems. However, this is just the tip of the iceberg; smart city infrastructure is not limited to traffic lights and road signs.

We decided to analyze some smart city components:

  • Touch-screen payment kiosks (tickets, parking etc.)
  • Infotainment terminals in taxis
  • Information terminals at airports and railway terminals
  • Road infrastructure components: speed cameras, traffic routers

Smart City Terminals

From a technical standpoint, nearly all payment and service terminals – irrespective of their purpose – are ordinary PCs equipped with touch screens. The main difference is that they have a ‘kiosk’ mode – an interactive graphical shell that blocks the user from accessing the regular operating system functions, leaving only a limited set of features that are needed to perform the terminal’s functions. But this is theory. In practice, as our field research has shown, most terminals do not have reliable protection preventing the user from exiting the kiosk mode and gaining access to the operating system’s functions.

Exiting the kiosk mode

Techniques for Exiting the Kiosk Mode

There are several types of vulnerabilities that affect a large proportion of terminals. As a consequence, there are existing attack methods that target them.

The sequence of operations that can enable an attacker to exit the full-screen application is illustrated in the picture below.

Methodology for analyzing the security of public terminals

Tap Fuzzing

The tap fuzzing technique involves trying to exit the full-screen application by taking advantage of incorrect handling when interacting with the full-screen application. A hacker taps screen corners with his fingers and tries to call the context menu by long-pressing various elements of the screen. If he is able to find such weak points, he tries to call one of the standard OS menus (printing, help, object properties, etc.) and gain access to the on-screen keyboard. If successful, the hacker gets access to the command line, which enables him to do whatever he wants in the system – explore the terminal’s hard drive in search of valuable data, access the Internet or install unwanted applications, such as malware.

Data Fuzzing

Data fuzzing is a technique that, if exploited successfully, also gives an attacker access to the “hidden” standard OS elements, but by using a different technique. To exit the full-screen application, the hacker tries filling in available data entry fields with various data in order to make the ‘kiosk’ work incorrectly. This can work, for example, if the full-screen application’s developer did not configure the filter checking the data entered by the user properly (string length, use of special symbols, etc.). As a result, the attacker can enter incorrect data, triggering an unhandled exception: as a result of the error, the OS will display a window notifying the user of the problem.

Once an element of the operating system’s standard interface has been brought up, the attacker can access the control panel, e.g., via the help section. The control panel will be the starting point for launching the virtual keyboard.

Other Techniques

Yet another technique for exiting the ‘kiosk’ is to search for external links that might enable the attacker to access a search engine site and then other sites. Due to developer oversight, many full-screen applications used in terminals contain links to external resources or social networks, such as VKontakte, Facebook, Google+, etc. We have found external links in the interface of cinema ticket vending machines and bike rental terminals, described below.

One more scenario of exiting the full-screen application is using standard elements of the operating system’s user interface. When using an available dialog window in a Windows-based terminal, an attacker is sometimes able to call the dialog window’s control elements, which enables him to exit the virtual ‘kiosk’.

Exiting the full-screen application of a cinema ticket vending terminal

Bike Rental Terminals

Cities in some countries, including Norway, Russia and the United States, are dotted with bicycle rental terminals. Such terminals have touch-screen displays that people can use to register if they want to rent a bike or get help information.

Status bar containing a URL

We found that the terminal system shown above has a curious feature. The Maps section was implemented using Google maps, and the Google widget includes a status bar, which contains “Report an Error”, “Privacy Policy” and “Terms of Use” links, among other information. Tapping on any of these links brings up a standard Internet Explorer window, which provides access to the operating system’s user interface.

The application includes other links, as well: for example, when viewing some locations on the map, you can tap on the “More Info” button and open a web page in the browser.

The Internet Explorer opens not only a web page, but also a new opportunity for the attacker

It turned out that calling up the virtual keyboard is not difficult either. By tapping on links on help pages, an attacker can access the Accessibility section, which is where the virtual keyboard can be found. This configuration flaw enables attackers to execute applications not needed for the device’s operation.

Running cmd.exe demonstrates yet another critical configuration flaw: the operating system’s current session is running with administrator privileges, which means that an attacker can easily execute any application.

The current Windows session is running with administrator privileges

In addition, an attacker can get the NTLM hash of the administrator password. It is highly probable that the password used on this device will work for other devices of the same type, as well.

Note that, in this case, an attacker can not only obtain the NTLM hash – which has to be brute-force cracked to get the password – but the administrator password itself, because passwords can be extracted from memory in plain text.

An attacker can also make a dump of the application that collects information on people who wish to rent a bicycle, including their full names, email addresses and phone numbers. It is not impossible that the database hosting this information is stored somewhere nearby. Such a database would have an especially high market value, since it contains verified email addresses and phone numbers. If it cannot be obtained, an attacker can install a keylogger that will intercept all data entered by users and send it to a remote server.

Given that these devices work 24/7, they can be pooled together to mine cryptocurrency or used for hacking purposes seeing as an infected workstation will be online around the clock.

Particularly audacious cybercriminals can implement an attack scenario that will enable them to get customer payment data by adding a payment card detail entry form to the main window of the bike rental application. It is highly probable that users deceived by the cybercriminals will enter this information alongside their names, phone numbers and email addresses.

Terminals at Government Offices

Terminals at some government offices can also be easily compromised by attackers. For example, we have found a terminal that prints payment slips based on the data entered by users. After all fields have been filled with the relevant data, the user taps the “Create” button, after which the terminal opens a standard print window with all the print parameters and control tools for several seconds. Next, the “Print” button is automatically activated.

A detail of the printing process on one of the terminals

An attacker has several seconds to tap the Change [printer] button and exit into the help section. From there, they can open the control panel and launch the on-screen keyboard. As a result, the attacker gets all the devices needed to enter information (the keyboard and the mouse pointer) and can use the computer for their own mercenary purposes, e.g., launch malware, get information on printed files, obtain the device’s administrator password, etc.

Public Devices at Airports

Self-service check-in kiosks that can be found at every modern airport have more or less the same security problems as the terminals described above. It is highly probable that they can be successfully attacked. An important difference between these kiosks and other similar devices is that some terminals at airports handle much more valuable information that terminals elsewhere.

Exiting the kiosk mode by opening an additional browser window

Many airports have a network of computers that provide paid Internet access. These computers handle the personal data that users have to enter to gain access, including people’s full names and payment card numbers. These terminals also have a semblance of a kiosk mode, but, due to design faults, exiting this mode is possible. On the computers we have analyzed, the kiosk software uses the Flash Player to show advertising and at a certain point an attacker can bring up a context menu and use it to access other OS functions.

It is worth noting that web address filtering policies are used on these computers. However, access to policy management on these computers was not restricted, enabling an attacker to add websites to the list or remove them from it, offering a range of possibilities for compromising these devices. For example, the ability to access phishing pages or sites used to distribute malware potentially puts such computers at risk. And blacklisting legitimate sites helps to increase the chances of a user following a phishing link.

List of addresses blocked by policies

We also discovered that configuration information used to connect to the database containing user data is stored openly in a text file. This means that, after finding a way to exit kiosk mode on one of these machines, anyone can get access to administrator credentials and subsequently to the customer database – with all the logins, passwords, payment details, etc.

A configuration file in which administrator logins and password hashes are stored

Infotainment Terminals in Taxicabs

In the past years, Android devices embedded in the back of the front passenger seat have been installed in many taxicabs. Passengers in the back seat can use these devices to watch advertising, weather information, news and jokes that are not really funny. These terminals have cameras installed in them for security reasons.

The application that delivers the content also works in kiosk mode and exiting this mode is also possible.

Exiting the kiosk mode on a device installed in a taxi makes it possible to download external applications

In those terminals that we were able to analyze, there was hidden text on the main screen. It can be selected using standard Android tools using a context menu. This leads to the search option being activated on the main screen. As a result, the shell stops responding, terminates and the device is automatically restarted. While the device is starting, all the hacker needs to do is exit to the main menu at the right time and open the RootExplorer – an Android OS file manager.

Android interface and folder structure

This gives an attacker access to the terminal’s OS and all of its capabilities, including the camera. If the hacker has prepared a malicious application for Android in advance and hosted it on a server, that application can be used to remotely access the camera. In this case, the attacker can remotely control the camera, making videos or taking photos of what is going on in the taxi and uploading them to his server.

Exiting the terminal’s full-screen application in a taxi gives access to the operating system’s functions

Our Recommendations

A successful attack can disrupt a terminal’s operation and cause direct financial damage to its owners. Additionally, a hacker can use a compromised terminal to hack into others, since terminals often form a network. After this, there are extensive possibilities for exploiting the network – from stealing personal data entered by users and spying on them (if the terminal has a camera or document scanner built into it) to stealing money (if the terminal accepts cash or bank cards).

To prevent malicious activity on public devices that have a touch interface, the developers and administrators of terminals located in public places should keep the following recommendations in mind:

  • The kiosk’s interactive shell should have no extra functions that enable the operating system’s menu to be called (such as right mouse click, links to external sites, etc.)
  • The application itself should be launched using sandboxing technology, such as jailroot, sandbox, etc. This will help to keep the application’s functionality limited to the artificial environment
  • Using a thin client is another method of protection. If a hacker manages to ‘kill’ an application, most of the valuable information will be stored on the server rather than the compromised device if the device is a thin client
  • The current operating system session should be launched with the restricted privileges of a regular user – this will make installing new applications much more difficult
  • A unique account with a unique password should be created on each device to prevent attackers who have compromised one of the terminals from using the password they have cracked to access other similar devices
Elements of the Road Infrastructure

The road infrastructure of modern cities is being gradually equipped with a variety of intelligent sensors, regulators, traffic analyzers, etc. All these sensors collect and send traffic density information to data centers. We looked at speedcams, which can be found everywhere these days.

Speed Cameras

We found speedcam IP addresses by pure chance, using the Shodan search engine. After studying several of these cameras, we developed a dork (a specific search request that identifies the devices or sites with pinpoint accuracy based on a specific attribute) to find as many IP addressed of these cameras as possible. We noticed a certain regularity in the IP addresses of these devices: in each city, all the cameras were on the same subnet. This enabled us to find those devices which were not shown in Shodan search results but which were on the same subnets with other cameras. This means there is a specific architecture on which these devices are based and there must be many such networks. Next, we scanned these and adjacent subnets on certain open ports and found a large number of such devices.

After determining which ports are open on speed cameras, we checked the hypothesis that one of them is responsible for RTSP – the real-time streaming protocol. The protocol’s architecture enables streaming to be either private (accessible with a login and password) or public. We decided to check that passwords were being used. Imagine our surprise when we realized there was no password and the entire video stream was available to all Internet users. Openly broadcast data includes not only the video stream itself, but additional data, such as the geographical coordinates of cameras, as well.

Direct broadcast screenshot from a speed camera

We found many more open ports on these devices, which can also be used to get many interesting technical details, such as a list of internal subnets used by the camera system or the list of camera hardware.

We learned from the technical documentation that the cameras can be reprogrammed over a wireless channel. We also learned from documentation that cameras can detect rule violations on specified lanes, making it possible to disable detection on one of the lanes in the right place at the right time. All of this can be done remotely.

Let’s put ourselves in criminals’ shoes and assume they need to remain undetected in the car traffic after performing certain illegal actions. They can take advantage of speed camera systems to achieve this. They can disable vehicle detection on some or all lanes along their route or monitor the actions of law-enforcement agents chasing them.

In addition, a criminal can get access to a database of vehicles registered as stolen and can add vehicles to it or remove them from it.

We have notified the organizations responsible for operating speed cameras in those countries where we identified the above security issues.


We also analyzed another element of the road infrastructure – the routers that transfer information between the various smart city elements that are part of the road infrastructure or to data centers.

As we were able to find out, a significant part of these routers uses either weak password protection or none at all. Another widespread vulnerability is that the network name of most routers corresponds to their geographic location, i.e., the street names and building numbers. After getting access to the administration interface of one of these routers, an attacker can scan internal IP ranges to determine other routers’ addresses, thereby collecting information on their locations. After this, by analyzing road load sensors, traffic density information can be collected from these sensors.

Such routers support recording traffic and uploading it to an FTP server that can be created by an attacker. These routers can also be used to create SSH tunnels. They provide access to their firmware (by creating its backup copy), support Telnet connections and have many other capabilities.

These devices are indispensable for the infrastructure of a smart city. However, after gaining access to them, criminals can use them for their own purposes. For example, if a bank uses a secret route to move large amounts of cash, the route can be determined by monitoring information from all sensors (using previously gained access to routers). Next, the movements of the vehicles can be monitored using the cameras.

Our Recommendations

To protect speed cameras, a full-scale security audit and penetration testing must first be carried out. From this, well-thought-out IT security recommendations be prepared for those who provide installation and maintenance of such speed monitoring systems. The technical documentation that we were able to obtain does not include any information on security mechanisms that can protect cameras against external attacks. Another thing that needs to be checked is whether such cameras are assigned an external IP address. This should be avoided where possible. For security reasons, none of these cameras should be visible from the Internet.

The main issue with routers used in the road infrastructure is that there is no requirement to set up a password during initial loading and configuration of the device. Many administrators of such routers are too forgetful or lazy to do such simple things. As a result, gaining access to the network’s internal traffic is sufficiently easy.


The number of new devices used in the infrastructure of a modern city is gradually growing. These new devices in turn connect to other devices and systems. For this environment to be safe for people who live in it, smart cities should be treated as information systems whose protection requires a custom approach and expertise.

This article was prepared as part of the support provided by Kaspersky Lab to “Securing Smart Cities”, an international non-profit initiative created to unite experts in smart city IT security technologies. For further information about the initiative, please visit

Rooting Pokémons in Google Play Store

Wed, 09/14/2016 - 07:50

A few days ago we reported to Google the existence of a new malicious app in the Google Play Store. The Trojan presented itself as the “Guide for Pokémon Go”. According to the Google Play Store it has been downloaded more than 500,000 times. Our data suggests there have been at least 6,000 successful infections, including in Russia, India and Indonesia. However, since the app is oriented towards English-speaking users, people in such geographies, and more, are also likely to have been hit.

Analysis reveals that the app contains a malicious piece of code that downloads rooting malware – malware capable of gaining access to the core Android operating system, in this case for the purposes of unsolicited app install and adware.

Kaspersky Lab products detect the Trojan as

At least one other version of this particular app was available through Google Play in July 2016. Further, we have tracked back at least nine other apps infected with this Trojan and available on Google Play Store at different times since December 2015.

Trojan characteristics

The Trojan has many layers of defense in place to help it bypass detection. This includes a commercial packer that decrypts the original executable file to make it harder to analyze. The unpacked executable file contains useful code related to the malicious Pokémon Go guide, and one small and obfuscated module.

Process of infection

This small module doesn’t start when the user launches the app. Instead, it waits for the user to install or uninstall another app, then checks to see if that app runs on a real device or on a virtual machine. If it turns out that it’s dealing with a device, the Trojan will wait for a further two hours before starting its malicious activity.

The first thing it does is connect to its command-and-control (CnC) server and upload data about the device, including country, language, device model and OS version.

If the server wants the Trojan to continue it will respond with an ID string. Only if the Trojan receives this ID string will it make its next request to the CnC. If it doesn’t receive anything, it will wait for two hours and then resubmit the first request. This feature is included so that the control server can stop the attack from proceeding if it wants to – skipping those users it does not wish to target, or those which it suspects are a sandbox/virtual machine, for example. Among other things, this provides an additional layer of protection for the malware.

Upon receiving the second request, the CnC server will send the Trojan a JSON file with urls. The Trojan will download this file, decrypt it and execute. In our case the Trojan downloaded a file detected as HEUR:Trojan.AndroidOS.Ztorg.a. This file is obfuscated too.

After execution, the Trojan will drop and download some more files. All downloaded files are encrypted and most of them are local root exploit packs for vulnerabilities dating from 2012 to 2015, including one that was previously used by Hacking Team.

These other files represent additional modules of the Trojan and are detected by Kaspersky Lab as:

HEUR:Backdoor.AndroidOS.Ztorg.c, HEUR:Trojan.AndroidOS.Muetan.b,, HEUR:Backdoor.AndroidOS.Ztorg.h, HEUR:Backdoor.AndroidOS.Ztorg.j,, HEUR:Trojan.AndroidOS.Hiddad.c. And a few clean tools like busybox and chattr.

Using these exploit packs the Trojan will gain root access rights to the device.

With rooting rights enabled, the Trojan will install its modules into the system folders, silently installing and uninstalling other apps and displaying unsolicited ads to the user.

Most of the other apps with this Trojan module available in Google Play had about 10,000 downloads (according to Google Play), but one – “Digital Clock” had more than 100,000 downloads.

MD5 of Malicious Files Mentioned in Article

Gugi: from an SMS Trojan to a Mobile-Banking Trojan

Mon, 09/12/2016 - 04:59

In the previous article, we described the mechanisms used by Trojan-Banker.AndroidOS.Gugi.c to bypass a number of new Android 6 security features. In this article, we review the entire Gugi mobile-banking Trojan family in more detail.

The use of WebSocket by Gugi

The mobile-banking Trojan family, Trojan-Banker.AndroidOS.Gugi is interesting due to its use of the WebSocket protocol to interact with its command-and-control servers. This protocol combines the advantages of HTTP with those of commonly used sockets: there is no need to open extra ports on a device, as all the communication goes through standard port 80. At the same time, real-time data exchange is possible.

It is worth noting that even though this technology is user-friendly, it is not that popular among attackers. Among all the mobile Trojans that utilize WebSocket technology, more than 90% are related to the Gugi family.

WebSocket Usage in Mobile SMS Trojans

We registered the first case of WebSocket technology use in mobile Trojans at the end of December 2013. It was Trojan-SMS.AndroidOS.FakeInst.fn. Judging by the code, the Trojan was created by the same malefactors who created the Trojan-Banker.AndroidOS.Gugi family.

During the initial registration, the FakeInst.fn Trojan uploads a large amount of device-related data to its server. The data includes the telephone number, the carrier information, IMEI, IMSI, etc.

From the server, the malware may receive a JSON file with the following commands (and data for the commands):

  • SMS – send a text message with specified text to a specified number;
  • intercept – enable or disable the interception of incoming SMS messages;
  • adres – change a command-and-control server address;
  • port – change a command-and-control server port;
  • contacts – send a bulk SMS message with specified content to all the contact numbers listed on the infected device.

In addition, the Trojan steals all outgoing SMS messages.

In the middle of January 2014, just a couple of weeks after discovering FakeInst.fn, a new version of the Trojan appeared. The malware was no longer using WebSocket; instead the communication was performed with the help of the HTTP protocol (GET and POST requests). Among all the installation packages of the Trojan, we could discover only two (dating back to the middle of March 2014) that utilized WebSocket. Everything seemed to indicate that the attackers decided to drop the technology for a while. They started to use it again almost two years later, in the Gugi family.

From SMS Trojans to Mobile Banking Trojans

Two years after finding the first version of Trojan-SMS.AndroidOS.FakeInst.fn, which utilized WebSocket, a new Websocket-using Trojan appeared, Trojan-Banker.AndroidOS.Gugi.a.

There are multiple matches in the Gugi code (variable and method names) with the Trojan-SMS.AndroidOS.FakeInst.fn code. The major changes within Gugi were the addition of a phishing window to steal the device user’s credit-card data and the use of WebSocket. Within all the Gugi mobile-banking Trojan family installation packages detected by us, WebSocket technology is used to communicate with the command-and-control server. Thus, the attackers had switched from Trojan-SMS to Trojan-Banker.

Evolution of the Trojan-Banker.AndroidOS.Gugi

The evolution of the Gugi Trojan can be split into two stages:


The first stage started in the middle of December 2015. The word “Fanta” is used within the name of all versions of the Trojan related to this stage, for example, “Fanta v.1.0”.

On request from the command-and-control server, Gugi Trojan version 1.0 could perform the following actions:

  • stop its operation;
  • steal all the contacts from the device;
  • steal all the SMS messages from the device;
  • send an SMS message with specified text to a specified number;
  • send a USSD request;
  • steal SMS messages from a specified group/conversation.

In late December 2015, we spotted the next version of Gugi, “Fanta v.1.1”. Its major difference from the previous version was that the code had a way of disabling the phishing window (we would like to remind you that Gugi can also be used as an SMS Trojan). Another new feature allowed contacts to be added to the infected device at the request of the server. This version was spread much more actively than the first one.

At the beginning of February 2016, we detected two new versions of Gugi, “Fanta v2.0” and “Fanta v2.1”. These versions had an increased focus on banking. First, they came with a new phishing window for stealing the username and password from the mobile banking software of one of the largest Russian banks. Secondly, the Trojan code introduced the list of phone numbers of two Russian banks. All incoming SMS messages from these numbers were not only sent to the malefactors’ server (like other SMS messages) but were hidden from the user.

These versions had a phishing window, shown either on request from the server or right after the smartphone had booted up. The window would not close until the user had entered their data.

Then, in the middle of March 2016, we found “Fanta v.2.2”. This became the most popular version of al, accounting for more than 50% of all of the installation packages related to the “Fanta” stage. Starting from this version, phishing windows were drawn over banking applications and Google Play.

Phishing window over Google Play Store

One more phishing window started to appear, right before the window for stealing credit-card data. This window read: “Link your credit card to Google Play Store and get 200 rubles for any apps!”

Additionally, starting from this version, the Trojan actively fights its removal. If the malware has Device Administrator rights, then its removal is possible only after disabling those rights. Therefore, whenever the Trojan does not have Device Administrator rights, it aggressively demands such permission, drawing its window over the device settings window.

In April 2016, we found the most recent “Fanta” version to date, “Fanta v.2.3”. That version had only one significant change: if the user disables the Device Administrator rights for the Trojan, then the malware changes the device password, effectively blocking the device.

All versions of “Fanta” are detected by the Kaspersky Lab products as Trojan-Banker.AndroidOS.Gugi.a.


The first file related to the second stage, “Lime”, was found a week before “Fanta v2.3” appeared, at the beginning of April 2016.

The installation package code for “Lime” seems to have been rewritten from the Fanta stage. The code, as well as the version names, had the word “Fanta” excluded and replaced with “Lime” in some lines. The same Trojan name, “Lime”, is seen in the administration panel through which the malefactors control this malware.

Trojan’s administration panel

Versions of the Trojan relating to the “Lime” stage do not change the device password when Device Administrator rights are disabled.

The first file discovered by us in April 2016 was version 1.1 and, judging by the code, was a test file. The next installation package related to the “Lime” stage was discovered in the middle of May 2016. It had the same version number, 1.1, but improved functionality.

The major change in version 1.1 of the “Lime” stage was that it showed new phishing windows. At that time, the Trojan could attack five banking apps of various Russian banks. Additionally, it had a new command to get the list of rules for processing incoming SMS messages. These rules define which messages should be hidden from the user and which messages should be replied to with specific messages.

Further, during the course of May 2016, we discovered files labelled 1.2 and 1.5 by the authors, even though the features of the files had not been changed.

Meanwhile, a new version of the Android OS, version 6.0, was released with security features that did not let the Trojan function properly. In June, we found a new version of the Trojan, 2.0, in which the malefactors had added support for Android 6. On Android 6 devices, the Trojan first requests permission to draw over other apps. Then, using the permission to its own advantage, it practically blocks the device, forcing the user to give Device Administrator rights to the malicious application as well as permission to read and send SMS messages and make calls.

Versions 3.0 and 3.1, which were found in July, have the same features as version 2.0 and utilize the same command-and-control server but different ports. Only one installation package for each version has been found by us. At the same time, version 2.0 continues to be actively spread.

All of the “Lime”-stage versions are detected by Kaspersky Lab products as Trojan-Banker.AndroidOS.Gugi.b and Trojan-Banker.AndroidOS.Gugi.c.


The Trojan is actively transmitted via SMS spam, with a link to phishing web pages that show a message indicating that the user has, supposedly, received an MMS picture.

Information about MMS message on phishing website

If the “show” button in the message is clicked, then the Trojan-Banker.AndroidOS.Gugi will be downloaded onto the device. It is highly likely that the name of the Trojan downloaded from such a websi фte will be similar to img09127639.jpg.apk.

As we have written in a previous post, we have encountered an explosive growth of Trojan-Banker.AndroidOS.Gugi attacks. August revealed 3 times as many users attacked by Gugi as in July, and almost 20 times as many as in June.

An amount of Kaspersky Lab mobile product users attacked by Trojan-Banker.AndroidOS.Gugi mobile-banking Trojan family

Today, the biggest number of attacks is performed by Lime version 2.0. All of the known active command-and-control servers of this Trojan are related to Lime versions 1.5 – 3.1. Not a single “Fanta” server known to us has been accessible since the middle of August 2016.

More than 93% of attacked users were located in Russia.

MD5 of Malicious Files Mentioned in Article


A malicious pairing of cryptor and stealer

Fri, 09/09/2016 - 04:59

We have already seen some cryptor attacks where malicious programs with different functions have been used in combination. For example, one version of the Shade cryptor checks victim computers for signs of accounting activity; if it finds any, it doesn’t encrypt the files, but instead installs remote control tools in the infected system. The bot can then be used by cybercriminals to steal money, a much more profitable outcome than just receiving a ransom to decrypt some files.

The owners of the RAA cryptor, however, took a different tack. The Trojan is delivered in emails that mostly target corporate users. After a successful infection, RAA executes its main task, i.e. encrypts the user’s files. However, it doesn’t stop there: some versions of RAA also include a Pony Trojan file, which steals confidential information from the infected computer. Using the stolen data, the cybercriminals can gain access to the victim’s mail clients and other resources. We can assume that the owners of RAA use these resources to carry out targeted attacks – sending out emails with the cryptor malware to the addresses on the victim’s contact list. This substantially improves the probability of subsequent infections.

In this article, we will provide details of how a pair of malicious programs – a new version of the RAA cryptor and the Pony stealer Trojan – work in unison.

The RAA cryptor

The RAA cryptor (Kaspersky Lab verdict: Trojan-Ransom.JS.RaaCrypt) was first detected in June 2016. It caught the attention of researchers and analysts due to the fact that it was written entirely in JavaScript, which is a rarity when it comes to ransomware cryptor Trojans.

We recently detected a new version of this Trojan that has a few differences from earlier known modifications. Let’s have a closer look at this particular sample, which has been assigned the verdict


The body of this new version of RAA is a script in JScript (with a .js file extension). The malicious script is sent to potential victims attached to a spam message in a ZIP file with the password ‘111’.

The attack is aimed primarily at corporate users: the message mimics finance-related business correspondence, and the script’s name is similar to those shown below:

Счета на оплату _ август 2016 согласовано и отправлено контрагенту для проведения оплаты _aytOkOTH.doc.js (Invoice_August 2016 approved and sent to contractor for payment _aytOkOTH.doc.js)

Счета на оплату _ август 2016 согласовано и отправлено контрагенту для проведения оплаты _EKWT.doc.js (Invoice_August 2016 approved and sent to contractor for payment _ EKWT.doc.js)

“Let’s presume we made a concession when we allowed you to postpone your due payment.

“We understand you may have difficulties, but do we have to wait for another two months? To be honest, we don’t really want to go to court. Please make all the payments in next few days.”

The message includes a notice saying:

“The company… notifies you that in line with internal security regulations, all outgoing emails are subject to asymmetric encryption. Dear client, your password for this message is 111.”

People who know what ‘asymmetric encryption’ is will probably just smile at this; however, the message is obviously targeting a different audience.

It should be noted that sending malicious content in a password-protected archive is a well-known trick used by cybercriminals to prevent anti-malware systems installed on mail servers from unpacking the archive and detecting any malicious content. To unpack an archive like this, the anti-malware product must automatically retrieve the password from the message, which isn’t always possible.

For an infection to occur, users have to unpack the archive themselves and launch the .js file.

Script obfuscation

The code of the malicious script was deliberately obfuscated to complicate things for malware analysts. The content of the script looks like this in the source code:

Fragment of the obfuscated code

If we restore the line breaks and indents, it becomes obvious that the obfuscation involves renamed variables and functions, as well as strings hidden in the global array. After de-obfuscation and function renaming, the same section of code becomes much easier to read.

Fragment of de-obfuscated code

The script is nearly 3,000 lines long. Most of this is taken up by an implementation of the legitimate DLL CryptoJS, and an implementation of the RSA encryption procedure, which was also taken from public sources by the cybercriminals.

How the Trojan works

To lull the victim into a false sense of security, the RAA cryptor demonstrates a fake Microsoft Word document immediately after it launches. This document is in fact an RTF file specially crafted by the cybercriminals. (The document is contained in the Trojan’s body encoded in Base64 format.)

The fake document displayed to the victim

While the user is reading the message about a document that’s supposedly not being displayed properly, the Trojan is doing its dirty work:

  • Registers itself to be autostarted with Windows;
  • Deletes the registry key associated with the VSS service (to prevent the restoring of files from shadow copies);
  • Sends a request to the C&C server (unlike all previous versions of this Trojan, this version doesn’t wait for the delivery of keys from the server – the request is only sent so the cybercriminals can collect statistics);
  • Proceeds to search for files and encrypts them.
Key generation

Unlike earlier RAA modifications, this version of the cryptor does not request an encryption key from the C&C. Instead, the Trojan generates a session key on the client. To do so, it calls the WinAPI function RtlGenRandom which is considered a cryptographically secure generator of pseudorandom numbers.

To ensure it can call WinAPI functions from JS code, the Trojan uses a legitimate third-party OCX component called DynamicWrapperX. The Trojan stores it in its body in a Base64-encoded format, and installs it in the infected system. RAA has both 32-bit and 64-bit versions of DynamicWrapperX so it can attack systems running under both Windows architectures.

The Trojan encrypts the generated session key with an RSA algorithm (the public RSA-2048 key is contained within the script) and saves it to a file with the name “KEY-…”, where the multiple periods stand for a unique 36-character infection ID.

File encryption

RAA searches for and encrypts files with the extensions .doc, .xls, .rtf, .pdf, .dbf, .jpg, .dwg, .cdr, .psd, .cd, .mdb, .png, .lcd, .zip, .rar, .csv whose names do not contain the substrings “.locked”, “~”, “$”.

When searching for files, the Trojan skips folders named “WINDOWS”, “RECYCLER”, “Program Files”, “Program Files (x86)”, “Windows”, “Recycle.Bin”, “RECYCLE.BIN”, “Recycler”, “TEMP”, “APPDATA”, “AppData”, “Temp”, “ProgramData”, and “Microsoft”.

When processing each file, RAA uses the session key to generate a file key and initialization vector (IV). The contents of the files are encrypted in different ways depending on the file size:

  • 0 to 6,122 bytes: the file is encrypted in full.
  • 6,123 to 4,999,999 bytes: three fragments are selected for encryption in different sections of the file. The first, 2000- to 2040-byte fragment is selected at the beginning of file; the location and size of the two other fragments depend on the size of the first fragment and the overall size of the file.
  • 5,000,001 to 500,000,000 bytes: two fragments of 90000-125000 bytes are selected for encryption (from the beginning and end of the file).
  • 500,000,001 bytes and larger: not encrypted.

A string is added at the end of the encrypted file that contains “IDNUM” (infection ID), “KEY_LOGIC” (indexes to construct the file key from the session key), “IV_LOGIC” (indexes to construct the IV from the session key), and “LOGIC_ID” (possible values are “1”, “2” or “3” – the selected encryption method depending on the file size). The encrypted file is given the additional extension .locked.

The string added to the end of the encrypted file

Ransom demand

When the files are encrypted, RAA displays a file with the cybercriminals’ demands and contacts in WordPad. The Trojan fills the text template with a 36-character ID which is unique for each case.

The file containing the cybercriminals’ demands

The cybercriminals suggest that the victims purchase a file decryption key and software from them. Two methods of communication are available: email and the Bitmessage service. The victim is expected to pay for the decryption key in bitcoins.

Plus a stealer Trojan

The damage caused by the Trojan is not limited to encrypting files. Like some of the earlier versions of RAA, the version we are examining has some added features. The Trojan contains an executable file encoded in Base64, which it writes to the hard drive at ‘C:\Users\<username>\Documents\ii.exe’ and launches after it has finished encrypting files. Analysis revealed that ‘ii.exe’ is none other than Pony, a known password-stealing Trojan (detection verdict: Trojan-PSW.Win32.Tepfer.gen).

Pony has proved to be an unusually long-lived Trojan. Its early versions supposedly emerged back in 2011, while in December 2013, as reported by the mass media, it stole the credentials of over 2 million users.

Naturally, after all that time Pony’s source code appeared on the web at some point. Analysis showed that the executable file we are analyzing here was constructed using Pony source code.

Pony: confidential data theft

To recap, Pony’s main task is to collect confidential information from an infected computer and then send it to the cybercriminals.

Step 1. Stealing information

Below is a short list of the information that Pony hunts for.

  • Passwords stored in web browsers
Microsoft Internet Explorer Google Chrome Opera Mozilla Firefox K-Meleon Яндекс.Браузер Flock
  • Credentials to dozens of the most popular FTP clients
CuteFTP 6\7\8\9\Pro\Lite FTP Navigator FlashFXP 3\4 FileZilla FTP Commander Bullet Proof FTP Client SmartFTP TurboFTP FFFTP COREFTP FTP Explorer ClassicFTP FTPClient LeapFTP FTP CONTROL FTPVoyager LeechFTP WinFTP FTPGetter ALFTP BlazeFtp Robo-FTP 3.7 NovaFTP FTP Surfer LinasFTP Cyberduck WiseFTP
  • Accounts with the most widespread mail clients
Microsoft Outlook Mozilla Thunderbird The Bat! Windows Live Mail Becky! Internet Mail Pocomail IncrediMail
  • Various cryptocurrency wallet files
PPCoin Primecoin Feathercoin ProtoShares Quarkcoin Worldcoin Infinitecoin Fastcoin Phoenixcoin Craftcoin

The Trojan also has the following capabilities:

  • Pony steals the user’s digital certificates.
  • Pony stores a list of the most widespread combinations that users use as passwords. Using this list, it attempts to gain access to the accounts on an infected computer.

Step 2. Data encryption and sending

Before sending the collected information to cybercriminals, Pony encrypts it using the RC4 algorithm. When doing so, the Trojan keeps records of the checksums for the obtained data (slightly modified results of the CRC32 algorithm are used.) The sequence is as follows:

  1. Calculate the checksum of the non-encrypted data.
  2. Write the obtained value next to the input data.
  3. Encrypt input data with the RC4 algorithm using the key that the cybercriminals specified when they compiled the Trojan.
  4. Calculate the checksum of the encrypted data.
  5. Write the obtained value next to the input data.
  6. Generate a random 4-byte key
  7. Encrypt the input data with the RC4 algorithm using the generated key.
  8. Generate a data package ready for sending that can be described with a ToSend structure (see below)
struct ToSend { dword random_key; byte* double_encrypted_data; };

A non-encrypted fragment of the generated report

Fragment of the report that is ready for sending. The encryption key is highlighted in red

When the data is brought up to the required form, Pony sends it to the cybercriminals.


Trojan-PSW.Win32.Tepfer.gen (Pony):

The Missing Piece – Sophisticated OS X Backdoor Discovered

Wed, 09/07/2016 - 09:19

In a nutshell
  • Backdoor.OSX.Mokes.a is the most recently discovered OS X variant of a cross-platform backdoor which is able to operate on all major operating systems (Windows,Linux,OS X). Please see also our analysis on the Windows and Linux variants.
  • This malware family is able to steal various types of data from the victim’s machine (Screenshots, Audio-/Video-Captures, Office-Documents, Keystrokes)
  • The backdoor is also able to execute arbitrary commands on the victim’s computer
  • To communicate it’s using strong AES-256-CBC encryption

Back in January this year we found a new family of cross-platform backdoors for desktop environments. After the discovery of the binaries for Linux and Windows systems, we have now finally come across the OS X version of Mokes.A. It is written in C++ using Qt, a cross-platform application framework, and is statically linked to OpenSSL. This leads to a filesize of approx. 14MB. Let’s have a look into this very fresh sample.

“Unpacked” Backdoor.OSX.Mokes.a

Its filename was “unpacked” when we got our hands on it, but we’re assuming that in-the-wild it comes packed, just like its Linux variant.


When executed for the first time, the malware copies itself to the first available of the following locations, in this order:

  • $HOME/Library/App Store/storeuserd
  • $HOME/Library/
  • $HOME/Library/Dock/
  • $HOME/Library/Skype/SkypeHelper
  • $HOME/Library/Dropbox/DropboxCache
  • $HOME/Library/Google/Chrome/nacld
  • $HOME/Library/Firefox/Profiles/profiled

Corresponding to that location, it creates a plist-file to achieve persistence on the system:

After that it’s time to establish a first connection with its C&C server using HTTP on TCP port 80:

The User-Agent string is hardcoded in the binary and the server replies to this “heartbeat” request with “text/html” content of 208 bytes in length. Then the binary establishes an encrypted connection on TCP port 443 using the AES-256-CBC algorithm.

Backdoor functionality

Its next task is to setup the backdoor features:

  • Capturing Audio
  • Monitoring Removable Storage
  • Capturing Screen (every 30 sec.)
  • Scanning the file system for Office documents (xls, xlsx, doc, docx)

The attacker controlling the C&C server is also able to define own file filters to enhance the monitoring of the file system as well as executing arbitrary commands on the system.

Just like on other platforms, the malware creates several temporary files containing the collected data if the C&C server is not available.

  • $TMPDIR/ss0-DDMMyy-HHmmss-nnn.sst (Screenshots)
  • $TMPDIR/aa0-DDMMyy-HHmmss-nnn.aat (Audiocaptures)
  • $TMPDIR/kk0-DDMMyy-HHmmss-nnn.kkt (Keylogs)
  • $TMPDIR/dd0-DDMMyy-HHmmss-nnn.ddt (Arbitrary Data)

DDMMyy = date: 070916 = 2016-09-07
HHmmss = time: 154411 = 15:44:11
nnn = milliseconds

If the environment variable $TMPDIR is not defined, “/tmp/” is used as the location (

Hints from the author

The author of this malware again left some references to the corresponding source files:


We detect this type of malware as HEUR:Backdoor.OSX.Mokes.a



$HOME/LibraryApp Store/storeuserd


Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/7046A194A

Banking Trojan, Gugi, evolves to bypass Android 6 protection

Tue, 09/06/2016 - 05:58

Almost every Android OS update includes new security features designed to make cybercriminals’ life harder. And, of course, the cybercriminals always try to bypass them.

We have found a new modification of the mobile banking Trojan, Trojan-Banker.AndroidOS.Gugi.c that can bypass two new security features added in Android 6: permission-based app overlays and a dynamic permission requirement for dangerous in-app activities such as SMS or calls. The modification does not use any vulnerabilities, just social engineering.

Initial infection

The Gugi Trojan is spread mainly by SMS spam that takes users to phishing webpages with the text “Dear user, you receive MMS-photo! You can look at it by clicking on the following link”.

Clicking on the link initiates the download of the Gugi Trojan onto the user’s Android device.

Circumventing the security features

To help protect users from the impо, неact of phishing and ransomware attacks, Android 6 introduced a requirement for apps to request permission to superimpose their windows/views over other apps. In earlier versions of the OS they were able to automatically overlay other apps.

The Trojan’s ultimate goal is to overlay banking apps with phishing windows in order to steal user credentials for mobile banking. It also overlays the Google Play Store app to steal credit card details.

The Trojan-Banker.AndroidOS.Gugi.c modification gets the overlay permission it needs by forcing users to grant this permission. It then uses that to block the screen while demanding ever more dangerous access.

The first thing an infected user is presented with is a window with the text “Additional rights needed to work with graphics and windows” and one button: “provide.”

After clicking on this button, the user will see a dialog box that authorizes the app overlay (“drawing over other apps”).

System request to permit Trojan-Banker.AndroidOS.Gugi.c to overlay other apps

But as soon as the user gives Gugi this permission, the Trojan will block the device and show its window over any other windows/dialogs.

Trojan-Banker.AndroidOS.Gugi.c window that blocks the infected device until it receives all the necessary rights

It gives the user no option, presenting a window that contains only one button: “Activate”. Once the user presses this button they will receive a continuous series of requests for all the rights the Trojan is looking for. They won’t get back to the main menu until they have agreed to everything.

For example, following the first click of the button, the Trojan will ask for Device Administrator rights. It needs this for self-defense because it makes it much harder for the user to uninstall the app.

After successfully becoming the Device Administrator, the Trojan produces the next request. This one asks the user for permission to send and view SMS and to make calls.

It is interesting that Android 6 has introduced dynamic request capability as a new security features

Earlier versions of the OS only show app permissions at installation; but, starting from Android 6, the system will ask users for permission to execute dangerous actions like sending SMS or making calls the first time they are attempted, or allows apps to ask at any other time – so that is what the modified Gugi Trojan does.

TSystem request for dynamic permission

The Trojan will continue to ask the user for each permission until they agree. Should the user deny permission, subsequent requests will offer them the option of closing the request. If the Trojan does not receive all the permissions it wants, it will completely block the infected device. In such a case the user’s only option is to reboot the device in safe mode and try to uninstall the Trojan.

TRepeating system request for dynamic permission

A standard banking Trojan

With the exception of its ability to bypass Android 6 security features, and its use of the Websocket protocol, Gugi is a typical banking Trojan. It overlays apps with phishing windows to steal credentials for mobile banking or credit card details. It also steals SMS, contacts, makes USSD requests and can send SMS by command from the CnC.

The Trojan-Banker.AndroidOS.Gugi family has been known about since December 2015, with the modification Trojan-Banker.AndroidOS.Gugi.c first discovered in June 2016.

Victim profile

The Gugi Trojan mainly attacks users in Russia: more than 93% of attacked users to date are based in that country. Right now it is a trending Trojan – in the first half of August 2016 there were ten times as many victims as in April 2016.

TUnique number users attacked by Trojan-Banker.AndroidOS.Gugi.

We will shortly be publishing a detailed report into the Trojan-Banker.AndroidOS.Gugi malware family, its functionality and its use of the Websocket protocol.

All Kaspersky Lab products detect all modifications of the Trojan-Banker.AndroidOS.Gugi malware family.

How Trojans manipulate Google Play

Wed, 08/31/2016 - 04:57

For malware writers, Google Play is the promised land of sorts. Once there, a malicious application gains access to a wide audience, gains the trust of that audience and experiences a degree of leniency from the security systems built into operating systems. On mobile devices, users typically cannot install applications coming from sources other than the official store, meaning this is a serious barrier for an app with malicious intent. However, it is far from easy for the app to get into Google Play: one of the main conditions for it is to pass a rigorous check for unwanted behavior by different analysis systems, both automatic and manual.

Some malware writers have given up on their efforts to push their malicious creations past security checks, and instead learned how to use the store’s client app for their unscrupulous gains. Lately, we have seen many Trojans use the Google Play app during promotion campaigns to download, install and launch apps on smartphones without the owners’ knowledge, as well as leave comments and rate apps. The apps installed by the Trojan do not typically cause direct damage to the user, but the victim may have to pay for the created excessive traffic. In addition, the Trojans may download and install paid apps as if they were free ones, further adding to the users’ bills.

Let us look into the methods how such manipulations with Google Play happen.

Level 1. N00b

The first method is to make the official Google Play app store undertake the actions the cybercriminal wants. The idea is to use the Trojan to launch the client, open the page of the required app in it, then search for and use special code to interact with the interface elements (buttons) to cause download, installation and launch of the application. The misused interface elements are outlined with red boxes in the screenshots below:

The exact methods of interaction with the interface vary. In general, the following techniques may be identified:

  1. Use of the Accessibility services of the operating system (used by modules in Trojan.AndroidOS.Ztorg).
  2. Imitation of user input (used by Trojan-Clicker.AndroidOS.Gopl.c).
  3. Code injection into the process of Google Play client to modify its operation (used by Trojan.AndroidOS.Iop).

To see how such Trojans operate. Let us look at the example of Trojan.AndroidOS.Ztorg.n. This malicious program uses Accessibility services originally intended to create applications to help people with disabilities, such as GUI voice control apps. The Trojan receives a job from the command and control server (C&C) which contains a link to the required application, opens it in Google Play, and then launches the following code:

This code is needed to detect when the required interface element appears on the screen, and to emulate the click on it. This way, the following buttons are clicked in a sequence: “BUY” (the price is shown in the button), “ACCEPT” and “CONTINUE”. This is sufficient to purchase the app, if the user has a credit card with sufficient balance connected to his/her Google account.

Level 2. Pro

Some malware writers take roads less traveled. Instead of using the easy and reliable way described above, they create their own client for the app store using HTTPS API.

The difficult part about this approach is that the operation of the self-made client requires information (e.g. user credentials and authentication tokens) which is not available to a regular app. However, the cybercriminals are very fortunate that all required data are stored on the device in clear text, in the convenient SQLite format. Access to the data is limited by the Android security model, however apps may abuse it e.g. by rooting the device and thus gaining unlimited access.

For example, some versions of the Trojan.AndroidOS.Guerrilla.a have their own client for Google Play, which is distributed with the help of the rooter Leech. This client successfully fulfils the task of downloading and installing free and paid apps, and is capable of rating apps and leaving comments in the Google store.

After launch, Guerrilla starts to collect the following required information:

  1. The credentials to the user’s Google Play account.

    Activities in Google Play require special tokens that are generated when the user logs in. When the user is already logged in to Google Play, the Trojan can use the locally cached tokens. They can be located through a simple search through the database located at /data/system/users/0/accounts.db:

    With the help of the code below, the Trojan checks if there are ready tokens on the infected device, i.e. if the user has logged on and can do activities in Google Play:

    If no such tokens are available, the Trojan obtains the user’s username and hashed password, and authenticates via OAuth:

  2. Android_id is the device’s unique ID.
  3. Google Service Framework ID is the device’s identifier across Google services.

    First, the Trojans attempts to obtain this ID using regular methods. If these fail for whatever reason, it executes the following code:

  4. Google Advertising ID is the unique advertising ID provided by Google Play services.

    Guerrilla obtains it as follows:

  5. In a similar way, the Trojan obtains hashed data about the device from the file “/data/data/“.

    When the Trojan has collected the above data, it begins to receive tasks to download and install apps. Below is the structure of one such task:

The Trojan downloads the application by sending POST requests using the links below:

  1. a search is undertaken for the request sent by the cybercriminals. This request is needed to simulate the user’s interaction with the Google Play client. (The main scenario of installing apps from the official client presupposes that the user first does the search request and only then visits the app’s page).
  2. with this request, additional information needed to download the app is collected.
  3. the token and purchase details are downloaded, used in the next request.
  4. the Trojan receives the URL and the cookie-files required to download the Android application package (APK) file.
  5. the download is confirmed (so the download counter is incremented.)
  6. the app is rated and a comment is added.

When creating the requests, the cybercriminals attempted to simulate most accurately the equivalent requests sent by the official client. For example, the below set of HTTP headers is used in each request:

After the request is executed, the app may (optionally) get downloaded, installed (using the command ‘pm install -r’ which allows for installation of applications without the user’s consent) and launched.


The Trojans that use the Google Play app to download, install and launch apps from the store to a smartphone without the device owner’s consent are typically distributed by rooters – malicious programs which have already gained the highest possible privileges on the device. It is this particular fact that allows them to launch such attacks on the Google Play client app.

This type of malicious program pose a serious threat: in Q2 2016, different rooters occupied more than a half of the Top 20 of mobile malware. All the more so, rooters can download not only malicious programs that compromise the Android ecosystem and spend the user’s money on purchasing unnecessary paid apps, but other malware as well.