14.1 C
London
Thursday, November 23, 2017
Home Tags Malicious Software

Tag: Malicious Software

Malware, short for malicious software, is any software used to disrupt computer operations, gather sensitive information, gain access to private computer systems, or display unwanted advertising. Malicious software was called computer virus before the term malware was coined in 1990 by Yisrael Radai. The first category of malware propagation concerns parasitic software fragments that attach themselves to some existing executable content. The fragment may be machine code that infects some existing application, utility, or system program, or even the code used to boot a computer system. Malware is defined by its malicious intent, acting against the requirements of the computer user, and does not include software that causes unintentional harm due to some deficiency.

Malware may be stealthy, intended to steal information or spy on computer users for an extended period without their knowledge, as for example Regin, or it may be designed to cause harm, often as sabotage (e.g., Stuxnet), or to extort payment (CryptoLocker). ‘Malware’ is an umbrella term used to refer to a variety of forms of hostile or intrusive software, including computer viruseswormstrojan horsesransomwarespywareadwarescareware, and other malicious programs. It can take the form of executable code, scripts, active content, and other software. Malware is often disguised as, or embedded in, non-malicious files. As of 2011 the majority of active malware threats were worms or trojans rather than viruses.

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 HEUR:Trojan.AndroidOS.Ztorg.ad. 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:Trojan.AndroidOS.Ztorg.ad, HEUR:Backdoor.AndroidOS.Ztorg.h, HEUR:Backdoor.AndroidOS.Ztorg.j, HEUR:Trojan-Dropper.AndroidOS.Agent.cv, 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 Article8CB3A269E50CA1F9E958F685AE4A073C0235CE101595DD0C594D0117BB64C8C3
You don't want this pony Image: iStock A form of ransomware which also contains a data stealing Trojan has been updated to become more effective at attacking business targets with new techniques including the ability to install malware and encrypt mach...
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: “Fanta” 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. “Lime” 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. Transmission 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 0x8EB8170A6B0957ED4943DAF6BA5C0F0A0x01BC8A2C84D1481042723F347056B1B30xBF257FD4F46605A5DBE258561891D77B0x01CD86238FE594CAC2495CE6BD38FAFA0xCBCC996BF49FFE3F90B207103102177B0x4C7C48B919C26278DD849ED4BB0B31920x11F51C119BC1E7D2358E2565B22879250xFA7C61CF2563F93DEA4BB9964D2E78060xC5A727E6C6A5E57EDDB16E6556D5D6660xD644E6E68F83504787443E8C8A3CB47F0xE778EAB7A2FB55C7BC67F15A692DE2460xE6C3329A8CC357C5BA455BB3C4372DE30x8BE9C3EDED33E2ADD22DE1A96C4A6B2B
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 Trojan-Ransom.JS.RaaCrypt.ag. Propagation 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 SoftX.org 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: Calculate the checksum of the non-encrypted data. Write the obtained value next to the input data. Encrypt input data with the RC4 algorithm using the key that the cybercriminals specified when they compiled the Trojan. Calculate the checksum of the encrypted data. Write the obtained value next to the input data. Generate a random 4-byte key Encrypt the input data with the RC4 algorithm using the generated key. 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; }; 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. MD5 Trojan-Ransom.JS.RaaCrypt.ag:68288a9f7a6bc41c9550a417d1721321 Trojan-PSW.Win32.Tepfer.gen (Pony):1de05ee1437d412cd328a6b3bd45fffc
Ransomware infections like Cerber are becoming an increasing problem for businesses. Image: Check Point The majority of organisations which become infected by ransomware will give into the demands of cybercriminals for reasons ranging from the importance of the encrypted data to the perceived low costs of ransom payments. However, some companies have discovered the hard way that cybercriminals are not to be trusted, with many only paying hackers to unencrypt their files only to find that they never get their data back. The figures on reactions to ransomware from Trend Micro come following a surge in cyberattacks using the file encrypting malicious software over the last year which has resulted in it becoming the largest threat to cybersecurity, as demonstrated by some cases of Locky infections against high-profile targets. While three quarters of organisations who haven't been the victim of a ransomware attack say they wouldn't give into the demands of hackers if infected, it seems that those do suffer a ransomware infection change their tune; two thirds of companies which have fallen victim to such an attack have paid up. It's because companies fear the repercussions of losing the data that those infected have given into ransom demands, with 37 percent of organisations worried about being fined if data became lost - the fact that quietly paying a ransom could mean that the business doesn't need to go public about a breach could also be a factor in this. Another reason given for doing business with cybercriminals is that the encrypted data is highly confidential, with a third of those who've paid hackers suggesting that this is the reason they gave into ransom demand, while almost as many view the cost of a ransom as low enough to justify paying as a means of avoiding any further issues. According to the Trend Micro figures unveiled at CloudSec London, the average ransom demanded is £540 ($722) - although the payment is usually requested in Bitcoin - with although 20 percent of organisations reported ransom demands of £1000 ($1338). For many companies, the figures simply represent a reasonable amount to pay in order to get potentially sensitive data back from hackers - however, this can backfire as if hackers know they can extort money from a particular company, they could repeatedly attack it and demand payments each time. "When faced with a ransom situation, most organisations simply cannot afford to part with the encrypted data and are forced to fork out the requested amount, often more than once.

Caving in to the demands of cyber-extortionists only reassure them of their strategy and perpetuates the threat cycle," says Bharat Mistry, cybersecurity consultant at Trend Micro. If it wasn't already obvious that cybercriminals aren't exactly trustworthy, Trend Micro's figures suggest that of those companies which paid a ransom to hackers, one in five never got their data back. There is however a silver lining as of those companies who refused to give into hackers' ransom demands, 60 percent said they were able to retrieve data from back up files, while there are also schemes by security firms which provide decryption keys for certain types of ransomware for free. Meanwhile, in a qauarter of cases, the company deemed the data being held to ransom as not valuable or confidential and thus not worth paying for. Organisations affected by ransomware estimate they spent 33 hours on average fixing the issues caused by the ransomware infection. Trend Micro's figures are based on a survey of 305 IT decision makers at organisations with over 1,000 employees in the UK. READ MORE ON CYBERCRIME
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 Background 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. Startup 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/com.apple.spotlight/SpotlightHelper $HOME/Library/Dock/com.apple.dock.cache $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-07HHmmss = time: 154411 = 15:44:11nnn = milliseconds If the environment variable $TMPDIR is not defined, “/tmp/” is used as the location (http://doc.qt.io/qt-4.8/qdir.html#tempPath). Hints from the author The author of this malware again left some references to the corresponding source files: Detection We detect this type of malware as HEUR:Backdoor.OSX.Mokes.a IOCs Hash:664e0a048f61a76145b55d1f1a5714606953d69edccec5228017eb546049dc8c Files:$HOME/LibraryApp Store/storeuserd$HOME/Library/com.apple.spotlight/SpotlightHelper$HOME/Library/Dock/com.apple.dock.cache$HOME/Library/Skype/SkypeHelper$HOME/Library/Dropbox/DropboxCache$HOME/Library/Google/Chrome/nacld$HOME/Library/Firefox/Profiles/profiled$HOME/Library/LaunchAgents/$filename.plist$TMPDIR/ss*-$date-$time-$ms.sst$TMPDIR/aa*-$date-$time-$ms.aat$TMPDIR/kk*-$date-$time-$ms.kkt$TMPDIR/dd*-$date-$time-$ms.ddt Hosts:158.69.241[.]141jikenick12and67[.]comcameforcameand33212[.]com User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/7046A194A
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.
The Sir Francis Drake Hotel in San Francisco is one of the Kimpton Hotels affected by the malware. Kimpton Hotels Kimpton Hotels has become the latest hotel operator to ...
MICROSOFT HAS taken the trouble to warn Windows users about an attack that takes what trust people have left in the software and throws it out of the window. The firm explained that the problem involves macros and the use of social engineering. People are tricked into downloading and then enabling malicious content that ultimately leads to trouble when they innocently use Word. "Attackers have been using social engineering to avoid the increasing costs of exploitation due to the significant hardening and exploit mitigation investments in Windows," said the firm in a Microsoft TechNet blog post suggesting that this is a cheap shot by hackers. "Tricking a user into running a malicious file or malware can be cheaper for an attacker than building an exploit which works on Windows 10. We recently came across a threat that uses the same social engineering trick but delivers a different payload." Microsoft explained that the payload's primary purpose is to change a user's browser Proxy Server setting, which could result in the theft of authentication credentials or other sensitive information. "We detect this JScript malware as Trojan:JS/Certor.A. What's not unique is that the malware gets into the victim's computer when the victim clicks the email attachment from a spam campaign," the post said. Microsoft added that people really ought not to click on links from people or outfits that they do not know or trust.

This is good, if perhaps hoary and often ignored, advice. "To avoid attacks like we have just detailed, it is recommended that you only open and interact with messages from senders and websites that you recognise and trust," explained the firm. "For added defence-in-depth, you can reduce the risk from this threat by following [our] guidance to adjust the registry settings to help prevent OLE Embedded Objects executing altogether or running without your explicit permission." Just don't click untrusted links, people. µ
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: Use of the Accessibility services of the operating system (used by modules in Trojan.AndroidOS.Ztorg). Imitation of user input (used by Trojan-Clicker.AndroidOS.Gopl.c). 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: 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: Android_id is the device’s unique ID. 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: Google Advertising ID is the unique advertising ID provided by Google Play services. Guerrilla obtains it as follows: In a similar way, the Trojan obtains hashed data about the device from the file “/data/data/com.google.android.gms/shared_prefs/Checkin.xml“. 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: https://android.clients.google.com/fdfe/search: 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). https://android.clients.google.com/fdfe/details: with this request, additional information needed to download the app is collected. https://android.clients.google.com/fdfe/purchase: the token and purchase details are downloaded, used in the next request. https://android.clients.google.com/fdfe/delivery: the Trojan receives the URL and the cookie-files required to download the Android application package (APK) file. https://android.clients.google.com/fdfe/log: the download is confirmed (so the download counter is incremented.) https://android.clients.google.com/fdfe/addReview: 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. Conclusion 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.

The Hunt for Lurk

In early June, 2016, the Russian police arrested the alleged members of the criminal group known as Lurk.

The police suspected Lurk of stealing nearly three billion rubles, using malicious software to systematically withdraw large sums of money from the accounts of commercial organizations, including banks.

For Kaspersky Lab, these arrests marked the culmination of a six-year investigation by the company’s Computer Incidents Investigation team. We are pleased that the police authorities were able to put the wealth of information we accumulated to good use: to detain suspects and, most importantly, to put an end to the theft. We ourselves gained more knowledge from this investigation than from any other.

This article is an attempt to share this experience with other experts, particularly the IT security specialists in companies and financial institutions that increasingly find themselves the targets of cyber-attacks. When we first encountered Lurk, in 2011, it was a nameless Trojan.
It all started when we became aware of a number of incidents at several Russian banks that had resulted in the theft of large sums of money from customers.

To steal the money, the unknown criminals used a hidden malicious program that was able to interact automatically with the financial institution’s remote banking service (RBS) software; replacing bank details in payment orders generated by an accountant at the attacked organization, or even generating such orders by itself. In 2016, it is hard to imagine banking software that does not demand some form of additional authentication, but things were different back in 2011.
In most cases, the attackers only had to infect the computer on which the RBS software was installed in order to start stealing the cash. Russia’s banking system, like those of many other countries, was unprepared for such attacks, and cybercriminals were quick to exploit the security gap. We participated in the investigation of several incidents involving the nameless malware, and sent samples to our malware analysts.

They created a signature to see if any other infections involving it had been registered, and discovered something very unusual: our internal malware naming system insisted that what we were looking at was a Trojan that could be used for many things (spamming, for example) but not stealing money. Our detection systems suggest that a program with a certain set of functions can sometimes be mistaken for something completely different.
In the case of this particular program the cause was slightly different: an investigation revealed that it had been detected by a “common” signature because it was doing nothing that could lead the system to include it in any specific group, for example, that of banking Trojans. Whatever the reason, the fact remained that the malicious program was used for the theft of money. So we decided to take a closer look at the malware.

The first attempts to understand how the program worked gave our analysts nothing. Regardless of whether it was launched on a virtual or a real machine, it behaved in the same way: it didn’t do anything.

This is how the program, and later the group behind it, got its name.

To “lurk” means to hide, generally with the intention of ambush. We were soon able to help investigate another incident involving Lurk.

This time we got a chance to explore the image of the attacked computer.

There, in addition to the familiar malicious program, we found a .dll file with which the main executable file could interact.

This was our first piece of evidence that Lurk had a modular structure. Later discoveries suggest that, in 2011, Lurk was still at an early stage of development.
It was formed of just two components, a number that would grow considerably over the coming years. The additional file we uncovered did little to clarify the nature of Lurk.
It was clear that it was a Trojan targeting RBS and that it was used in a relatively small number of incidents.
In 2011, attacks on such systems were starting to grow in popularity. Other, similar, programs were already known about, the earliest detected as far back as in 2006, with new malware appearing regularly since then.

These included ZeuS, SpyEye, and Carberp, etc.
In this series, Lurk represented yet another dangerous piece of malware. It was extremely difficult to make Lurk work in a lab environment. New versions of the program appeared only rarely, so we had few opportunities to investigate new incidents involving Lurk.

A combination of these factors influenced our decision to postpone our active investigation into this program and turn our attention to more urgent tasks. A change of leader For about a year after we first met Lurk, we heard little about it.
It later turned out that the incidents involving this malicious program were buried in the huge amount of similar incidents involving other malware.
In May 2011, the source code of ZeuS had been published on the Web and this resulted in the emergence of many program modifications developed by small groups of cybercriminals. In addition to ZeuS, there were a number of other unique financial malware programs.
In Russia, there were several relatively large cybercriminal groups engaged in financial theft via attacks on RBS.

Carberp was the most active among them.

At the end of March 2012, the majority of its members were arrested by the police.

This event significantly affected the Russian cybercriminal world as the gang had stolen hundreds of millions of rubles during a few years of activity, and was considered a “leader” among cybercriminals. However, by the time of the arrests, Carberp’s reputation as a major player was already waning.

There was a new challenger for the crown. A few weeks before the arrests, the sites of a number of major Russian media, such as the agency “RIA Novosti”, Gazeta.ru and others, had been subjected to a watering hole attack.

The unknown cybercriminals behind this attack distributed their malware by exploiting a vulnerability in the websites’ banner exchange system.

A visitor to the site would be redirected to a fraudulent page containing a Java exploit.
Successful exploitation of the vulnerability initiated the launch of a malicious program whose main function was collecting information on the attacked computer, sending it to a malicious server, and in some cases receiving and installing an extra load from the server. The code on the main page of RIA.ru that is used to download additional content from AdFox.ru From a technical perspective, the malicious program was unusual. Unlike most other malware, it left no traces on the hard drive of the system attacked and worked only in the RAM of the machine.

This approach is not often used in malware, primarily because the resulting infection is “short-lived”: malware exists in the system only until the computer is restarted, at which point the process of infection need to be started anew.

But, in the case of these attacks, the secret “bodiless” malicious program did not have to gain a foothold in the victim’s system.
Its primary job was to explore; its secondary role was to download and install additional malware.

Another fascinating detail was the fact that the malware was only downloaded in a small number of cases, when the victim computer turned out to be “interesting”. Part of the Lurk code responsible for downloading additional modules Analysis of the bodiless malicious program showed that it was “interested” in computers with remote banking software installed. More specifically, RBS software created by Russian developers. Much later we learned that this unnamed, bodiless module was a mini, one of the malicious programs which used Lurk.

But at the time we were not sure whether the Lurk we had known since 2011, and the Lurk discovered in 2012, were created by the same people. We had two hypotheses: either Lurk was a program written for sale, and both the 2011 and 2012 versions were the result of the activity of two different groups, which had each bought the program from the author; or the 2012 version was a modification of the previously known Trojan. The second hypothesis turned out to be correct. Invisible war with banking software A small digression. Remote banking systems consist of two main parts: the bank and the client.

The client part is a small program that allows the user (usually an accountant) to remotely manage their organization’s accounts.

There are only a few developers of such software in Russia, so any Russian organization that uses RBS relies on software developed by one of these companies.

For cybercriminal groups specializing in attacks on RBS, this limited range of options plays straight into their hands. In April 2013, a year after we found the “bodiless” Lurk module, the Russian cybercriminal underground exploited several families of malicious software that specialized in attacks on banking software.

Almost all operated in a similar way: during the exploration stage they found out whether the attacked computer had the necessary banking software installed.
If it did, the malware downloaded additional modules, including ones allowing for the automatic creation of unauthorized payment orders, changing details in legal payment orders, etc.

This level of automation became possible because the cybercriminals had thoroughly studied how the banking software operated and “tailored” their malicious software modules to a specific banking solution. The people behind the creation and distribution of Lurk had done exactly the same: studying the client component of the banking software and modifying their malware accordingly.
In fact, they created an illegal add-on to the legal RBS product. Through the information exchanges used by people in the security industry, we learned that several Russian banks were struggling with malicious programs created specifically to attack a particular type of legal banking software.
Some of them were having to release weekly patches to customers.

These updates would fix the immediate security problems, but the mysterious hackers “on the other side” would quickly release a new version of malware that bypassed the upgraded protection created by the authors of the banking programs. It should be understood that this type of work – reverse-engineering a professional banking product – cannot easily be undertaken by an amateur hacker.
In addition, the task is tedious and time-consuming and not the kind to be performed with great enthusiasm.
It would need a team of specialists.

But who in their right mind would openly take up illegal work, and who might have the money to finance such activities? In trying to answer these questions, we eventually came to the conclusion that every version of Lurk probably had an organized group of cybersecurity specialists behind it. The relative lull of 2011-2012 was followed by a steady increase in notifications of Lurk-based incidents resulting in the theft of money.

Due to the fact that affected organizations turned to us for help, we were able to collect ever more information about the malware.

By the end of 2013, the information obtained from studying hard drive images of attacked computers as well as data available from public sources, enabled us to build a rough picture of a group of Internet users who appeared to be associated with Lurk. This was not an easy task.

The people behind Lurk were pretty good at anonymizing their activity on the network.

For example, they were actively using encryption in everyday communication, as well as false data for domain registration, services for anonymous registration, etc.
In other words, it was not as easy as simply looking someone up on “Vkontakte” or Facebook using the name from Whois, which can happen with other, less professional groups of cybercriminals, such as Koobface.

The Lurk gang did not make such blunders. Yet mistakes, seemingly insignificant and rare, still occurred.

And when they did, we caught them. Not wishing to give away free lessons in how to run a conspiracy, I will not provide examples of these mistakes, but their analysis allowed us to build a pretty clear picture of the key characteristics of the gang. We realized that we were dealing with a group of about 15 people (although by the time it was shut down, the number of “regular” members had risen to 40).

This team provided the so-called “full cycle” of malware development, delivery and monetization – rather like a small, software development company.

At that time the “company” had two key “products”: the malicious program, Lurk, and a huge botnet of computers infected with it.

The malicious program had its own team of developers, responsible for developing new functions, searching for ways to “interact” with RBS systems, providing stable performance and fulfilling other tasks.

They were supported by a team of testers who checked the program performance in different environments.

The botnet also had its own team (administrators, operators, money flow manager, and other partners working with the bots via the administration panel) who ensured the operation of the command and control (C&C) servers and protected them from detection and interception. Developing and maintaining this class of malicious software requires professionals and the leaders of the group hunted for them on job search sites.

Examples of such vacancies are covered in my article about Russian financial cybercrime.

The description of the vacancy did not mention the illegality of the work on offer.

At the interview, the “employer” would question candidates about their moral principles: applicants were told what kind of work they would be expected to do, and why.

Those who agreed got in. A fraudster has advertised a job vacancy for java / flash specialists on a popular Ukrainian website.

The job requirements include a good level of programming skills in Java, Flash, knowledge of JVM / AVM specifications, and others.

The organizer offers remote work and full employment with a salary of $2,500.
So, every morning, from Monday to Friday, people in different parts of Russia and Ukraine sat down in front of their computer and started to “work”.

The programmers “tuned” the functions of malware modifications, after which the testers carried out the necessary tests on the quality of the new product.

Then the team responsible for the botnet and for the operation of the malware modules and components uploaded the new version onto the command server, and the malicious software on botnet computers was automatically updated.

They also studied information sent from infected computers to find out whether they had access to RBS, how much money was deposited in clients’ accounts, etc. The money flow manager, responsible for transferring the stolen money into the accounts of money mules, would press the button on the botnet control panel and send hundreds of thousands of rubles to accounts that the “drop project” managers had prepared in advance.
In many cases they didn’t even need to press the button: the malicious program substituted the details of the payment order generated by the accountant, and the money went directly to the accounts of the cybercriminals and on to the bank cards of the money mules, who cashed it via ATMs, handed it over to the money mule manager who, in turn, delivered it to the head of the organization.

The head would then allocate the money according to the needs of the organization: paying a “salary” to the employees and a share to associates, funding the maintenance of the expensive network infrastructure, and of course, satisfying their own needs.

This cycle was repeated several times. Each member of the typical criminal group has their own responsibilities. These were the golden years for Lurk.

The shortcomings in RBS transaction protection meant that stealing money from a victim organization through an accountant’s infected machine did not require any special skills and could even be automated.

But all “good things” must come to an end. The end of “auto money flow” and the beginning of hard times The explosive growth of thefts committed by Lurk and other cybercriminal groups forced banks, their IT security teams and banking software developers to respond. First of all, the developers of RBS software blocked public access to their products.

Before the appearance of financial cybercriminal gangs, any user could download a demo version of the program from the manufacturer’s website.

Attackers used this to study the features of banking software in order to create ever more tailored malicious programs for it.

Finally, after many months of “invisible war” with cybercriminals, the majority of RBS software vendors succeeded in perfecting the security of their products. At the same time, the banks started to implement dedicated technologies to counter the so-called “auto money flow”, the procedure which allowed the attackers to use malware to modify the payment order and steal money automatically. By the end of 2013, we had thoroughly explored the activity of Lurk and collected considerable information about the malware.

At our farm of bots, we could finally launch a consistently functioning malicious script, which allowed us to learn about all the modifications cybercriminals had introduced into the latest versions of the program. Our team of analysts had also made progress: by the year’s end we had a clear insight into how the malware worked, what it comprised and what optional modules it had in its arsenal. Most of this information came from the analysis of incidents caused by Lurk-based attacks. We were simultaneously providing technical consultancy to the law enforcement agencies investigating the activities of this gang. It was clear that the cybercriminals were trying to counteract the changes introduced in banking and IT security.

For example, once the banking software vendors stopped providing demo versions of their programs for public access, the members of the criminal group established a shell company to receive directly any updated versions of the RBS software. Thefts declined as a result of improvements in the security of banking software, and the “auto money flow” became less effective.

As far as we can judge from the data we have, in 2014 the criminal group behind Lurk seriously reduced its activity and “lived from hand to mouth”, attacking anyone they could, including ordinary users.

Even if the attack could bring in no more than a few tens of thousands of rubles, they would still descend to it. In our opinion, this was caused by economic factors: by that time, the criminal group had an extensive and extremely costly network infrastructure, so, in addition to employees’ salaries, it was necessary to pay for renting servers, VPN and other technical tools. Our estimates suggest that the network infrastructure alone cost the Lurk managers tens of thousands of dollars per month. Attempts to come back In addition to increasing the number of “minor” attacks, the cybercriminals were trying to solve their cash flow problem by “diversifying” the business and expanding their field of activity.

This included developing, maintaining and renting the Angler exploit pack (also known as XXX).
Initially, this was used mainly to deliver Lurk to victims’ computers.

But as the number of successful attacks started to decline, the owners began to offer smaller groups paid access to the tools. By the way, judging by what we saw on Russian underground forums for cybercriminals, the Lurk gang had an almost legendary status.

Even though many small and medium-sized groups were willing to “work” with them, they always preferred to work by themselves.
So when Lurk provided other cybercriminals with access to Angler, the exploit pack became especially popular – a “product” from the top underground authority did not need advertising.
In addition, the exploit pack was actually very effective, delivering a very high percentage of successful vulnerability exploitations.
It didn’t take long for it to become one of the key tools on the criminal2criminal market. As for extending the field of activity, the Lurk gang decided to focus on the customers of major Russian banks and the banks themselves, whereas previously they had chosen smaller targets. In the second half of 2014, we spotted familiar pseudonyms of Internet users on underground forums inviting specialists to cooperate on document fraud.

Early the following year, several Russian cities were swamped with announcements about fraudsters who used fake letters of attorney to re-issue SIM cards without their owners being aware of it. The purpose of this activity was to gain access to one-time passwords sent by the bank to the user so that they could confirm their financial transaction in the online or remote banking system.

The attackers exploited the fact that, in remote areas, mobile operators did not always carefully check the authenticity of the documents submitted and released new SIM cards at the request of cybercriminals. Lurk would infect a computer, collect its owner’s personal data, generate a fake letter of attorney with the help of “partners” from forums and then request a new SIM card from the network operator. Once the cybercriminals received a new SIM card, they immediately withdrew all the money from the victim’s account and disappeared. Although initially this scheme yielded good returns, this didn’t last long, since by then many banks had already implemented protection mechanisms to track changes in the unique SIM card number.
In addition, the SIM card-based campaign forced some members of the group and their partners out into the open and this helped law enforcement agencies to find and identify suspects. Alongside the attempts to “diversify” the business and find new cracks in the defenses of financial businesses, Lurk continued to regularly perform “minor thefts” using the proven method of auto money flow. However, the cybercriminals were already planning to earn their main money elsewise. New “specialists” In February 2015, Kaspersky Lab’s Global Research and Analysis Team (GReAT) released its research into the Carbanak campaign targeting financial institutions.

Carbanak’s key feature, which distinguished it from “classical” financial cybercriminals, was the participation of professionals in the Carbanak team, providing deep knowledge of the target bank’s IT infrastructure, its daily routine and the employees who had access to the software used to conduct financial transactions.

Before any attack, Carbanak carefully studied the target, searched for weak points and then, at a certain moment in time, committed the theft in no more than a few hours.

As it turned out, Carbanak was not the only group applying this method of attack.
In 2015, the Lurk team hired similar experts. How the Carbanak group operated. We realized this when we found incidents that resembled Carbanak in style, but did not use any of its tools.

This was Lurk.

The Lurk malware was used as a reliable “back door” to the infrastructure of the attacked organization rather than as a tool to steal money.

Although the functionality that had previously allowed for the near-automatic theft of millions no longer worked, in terms of its secrecy Lurk was still an extremely dangerous and professionally developed piece of malware. However, despite its attempts to develop new types of attacks, Lurk’s days were numbered.

Thefts continued until the spring of 2016.

But, either because of an unshakable confidence in their own impunity or because of apathy, day-by-day the cybercriminals were paying less attention to the anonymity of their actions.

They became especially careless when cashing money: according to our incident analysis, during the last stage of their activity, the cybercriminals used just a few shell companies to deposit the stolen money.

But none of that mattered any more as both we and the police had collected enough material to arrest suspected group members, which happened early in June this year. No one on the Internet knows you are a cybercriminal? My personal experience of the Lurk investigation made me think that the members of this group were convinced they would never be caught.

They had grounds to be that presumptuous: they were very thorough in concealing the traces of their illegal activity, and generally tried to plan the details of their actions with care. However, like all people, they made mistakes.

These errors accumulated over the years and eventually made it possible to put a stop to their activity.
In other words, although it is easier to hide evidence on the Internet, some traces cannot be hidden, and eventually a professional team of investigators will find a way to read and understand them. Lurk is neither the first nor the last example to prove this.

The infamous banking Trojan SpyEye was used to steal money between 2009 and 2011.
Its alleged creator was arrested 2013, and convicted in 2014. The first attacks involving the banking Trojan Carberp began in 2010; the members of the group suspected of creating and distributing this Trojan were arrested in 2012 and convicted in 2014.

The list goes on. The history of these and other cybercriminal groups spans the time when everyone (and members of the groups in particular) believed that they were invulnerable and the police could do nothing.

The results have proved them wrong. Unfortunately, Lurk is not the last group of cybercriminals attacking companies for financial gain. We know about some other groups targeting organizations in Russia and abroad.

For these reasons, we recommend that all organizations do the following: If your organization was attacked by hackers, immediately call the police and involve experts in digital forensics.

The earlier you apply to the police, the more evidence the forensics will able to collect, and the more information the law enforcement officers will have to catch the criminals. Apply strict IT security policies on terminals from which financial transactions are made and for employees working with them. Teach all employees who have access to the corporate network the rules of safe online behavior. Compliance with these rules will not completely eliminate the risk of financial attacks but will make it harder for fraudsters and significantly increase the probability of their making a mistake while trying to overcome these difficulties.

And this will help law enforcement agencies and IT security experts in their work. P.S.: why does it take so long? Law enforcement agencies and IT security experts are often accused of inactivity, allowing hackers to remain at large and evade punishment despite the enormous damage caused to the victims. The story of Lurk proves the opposite.
In addition, it gives some idea of the amount of work that has to be done to obtain enough evidence to arrest and prosecute suspects. Unfortunately, the rules of the “game” are not the same for all participants: the Lurk group used a professional approach to organizing a cybercriminal enterprise, but, for obvious reasons, did not find it necessary to abide by the law.

As we work with law enforcement, we must respect the law.

This can be a long process, primarily because of the large number of “paper” procedures and restrictions that the law imposes on the types of information we as a commercial organization can work with. Our cooperation with law enforcement in investigating the activity of this group can be described as a multi-stage data exchange. We provided the intermediate results of our work to the police officers; they studied them to understand if the results of our investigation matched the results of their research.

Then we got back our data “enriched” with the information from the law enforcement agencies. Of course, it was not all the information they could find; but it was the part which, by law, we had the right to work with.

This process was repeated many times until we finally we got a complete picture of Lurk activity. However, that was not the end of the case. A large part of our work with law enforcement agencies was devoted to “translating” the information we could get from “technical” into “legal” language.

This ensured that the results of our investigation could be described in such a way that they were clear to the judge.

This is a complicated and laborious process, but it is the only way to bring to justice the perpetrators of cybercrimes.
Wildfire ransomware has plagued victims in The Netherlands and Belgium Image: McAfee Labs Victims of the Wildfire ransomware can get their encrypted files back without paying hackers for the privilege, after the No More Ransom initiative released a free decryption tool. No More Ransom runs a web portal that provides keys for unlocking files encrypted by various strains of ransomware, including Shade, Coinvault, Rannoh, Rakhn and, most recently, Wildfire. Aimed at helping ransomware victims retrieve their data, No More Ransom is a collaborative project between Europol, the Dutch National Police, Intel Security, and Kaspersky Lab. Wildfire victims are served with a ransom note demanding payment of 1.5 Bitcoins -- the cryptocurrency favored by cybercriminals -- in exchange for unlocking the encrypted files. However, cybersecurity researchers from McAfee Labs, part of Intel Security, point out that the hackers behind Wildfire are open to negotiation, often accepting 0.5 Bitcoins as a payment. Most victims of the ransomware are located in the Netherlands and Belgium, with the malicious software spread through phishing emails aimed at Dutch speakers.

The email claims to be from a transport company and suggests that the target has missed a parcel delivery -- encouraging them to fill in a form to rearrange delivery for another date.
It's this form which drops Wildfire ransomware onto the victim's system and locks it down. A spam email used to infect victims with Wildfire. Image: McAfee Labs Researchers note that those behind Wildfire have "clearly put a lot of effort into making their spam mails look credible and very specific" - even adding the addresses of real businesses in The Netherlands - arousing suspicion that there are Dutch speaking actors involved in the ransomware campaign. Working in partnership with law enforcement agencies, cybersecurity researchers were able to examine Wildfire's control server panel, which showed that in a one month period the ransomware infected 5,309 systems and generated a revenue of 136 Bitcoins (€70,332). Researchers suggest that the malicious code -- which contains instructions not to infect Russian-speaking countries -- means Wildfire operates as part of a ransomware-as-service franchise, with software likely to be leased out by developers in Eastern Europe. Whoever is behind Wildfire, victims no longer need to pay a ransom in order to get their files back,with the decryptor tool now available to download for free from the No More Ransom site.

The tool contains 1,600 keys for Wildfire, and No More Ransom says more will be added in the near future. READ MORE ON CYBERCRIME