Malware RSS Feed

Thank you, CanSecWest16!

Malware Alerts - 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?

Malware Alerts - 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

Malware Alerts - 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!

Unique Passwords

SANS Tip of the Day - Tue, 03/15/2016 - 01:00
Make sure each of your accounts has a separate, unique password. Can't remember all of your passwords/passphrases? Consider using a password manager to securely store all of them for you.

Back up Your Files

SANS Tip of the Day - Fri, 03/11/2016 - 00:00
Eventually, we all have an accident or get hacked. And when we do, backups are often the only way to recover. Backups are cheap and easy; make sure you are backing up all of your personal information (such as family photos) on a regular basis.

PlugX malware: A good hacker is an apologetic hacker

Malware Alerts - 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.

Email Auto-Complete

SANS Tip of the Day - Thu, 03/10/2016 - 00:00
Be careful with email auto-complete. This is an email feature that automatically completes a name for you when you begin typing it in the TO field. However, your email client can easily complete the wrong name for you. If you are emailing anything sensitive, always be sure to check the TO field a second time before hitting the send button.

Go With Passphrases

SANS Tip of the Day - Wed, 03/09/2016 - 00:00
Passphrases are the strongest type of passwords and the easiest to remember. Simply use an entire sentence for your password, such as "What time is coffee?" By using spaces and punctuation, you create a long password that is hard to guess but easy to remember.

Microsoft Security Updates March 2016

Malware Alerts - 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.

Secure Your Home Wi-Fi Router

SANS Tip of the Day - Mon, 03/07/2016 - 00:00
The most effective steps you can take to secure your wireless network at home is to change the default admin password, enable WPA2 encryption and use a strong password for your wireless network.

Amazon used as bait

Malware Alerts - 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.

Anti-Virus

SANS Tip of the Day - Fri, 03/04/2016 - 00:00
Make sure you have anti-virus software installed on your computer and that it is automatically updating. However, keep in mind that no anti-virus can catch all malware; your computer can still be infected. That is why it's so important you use common sense and be wary of any messages that seem odd or suspicious.

First step in cross-platform Trojan bankers from Brazil done

Malware Alerts - 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

Malware Alerts - 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!

Malware Alerts - 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

Malware Alerts - 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

Malware Alerts - 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.

Don't Login on Untrusted Computers

SANS Tip of the Day - Tue, 03/01/2016 - 00:00
A password is only as secure as the computer or network it is used on. As such, never log in to a sensitive account from a public computer, such as computers in a cyber cafe, hotel lobby or conference hall. Bad guys target public computers such as these and infect them on purpose. The moment you type your password on an infected computer, these cyber criminals can harvest your passwords. If you have no choice but to use a public computer, change your password at the next available opportunity you have access to a trusted computer.

ATMZombie: banking trojan in Israeli waters

Malware Alerts - 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

Malware Alerts - 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.