Day: February 19, 2016

We recently discovered 22 Android apps that belong to a new Trojan family we’re calling “Xbot”. This Trojan, which is still under development and regularly updated, is already capable of multiple malicious behaviors. It tries to steal victims’ banking credentials and credit card information via phishing pages crafted to mimic Google Play’s payment interface as well as the login pages of 7 different banks’ apps. It can also remotely lock infected Android devices, encrypt the user’s files in external storage (e.g., SD card), and then ask for a U.S. $100 PayPal cash card as ransom. In addition, Xbot will steal all SMS messages and contact information, intercept certain SMS messages, and parse SMS messages for mTANs (Mobile Transaction Authentication Number) from banks.

So far the malware doesn’t appear to be widespread, and some markers in its code and faked app interfaces indicate, at least for now, it mainly appears to target Android users in Russia and Australia. Of note, of the seven bank apps it is seen to imitate, six of them belong to some of the most popular banks in Australia. However, Xbot was implemented in a flexible architecture that could be easily extended to target more Android apps. Given we also observed the author making regular updates and improvements, this malware could soon threaten Android users around the world.

Xbot primarily uses is a popular attack technique called “activity hijacking” by abusing some features in Android. The apps Xbot is mimicking are not themselves being exploited. Starting with Android 5.0, Google adopted a protection mechanism to mitigate this attack but other attack approaches used by Xbot are still affecting all versions of Android.

Xbot’s Evolution and Spreading

We believe Xbot is a successor to the Android Trojan Aulrin that was first discovered in 2014. Xbot and Aulrin have very similar code structures and behaviors, and some resource files in Aulrin are also in Xbot samples. The main difference between them is that Xbot implements its behaviors using JavaScript through Mozilla’s Rhino framework, while Aulrin used Lua and .NET framework. The earliest sample of Xbot we found was compiled in May 2015 and while comparing Xbot to Aulrin, it seemed to us the author re-wrote Aulrin using a different language and framework. The author has also progressively made Xbot more complex; the most recent versions use Dexguard, a legitimate tool intended to protect Android apps by making them difficult to reverse engineer or be tampered with.

We are not clear how Xbot spreads in the wild. However, using VirusTotal we found samples that were hosted on the below URLs over the past several months:

• hxxp://market155[.]ru/Install.apk
• hxxp://illuminatework[.]ru/Install.apk
• hxxp://yetiathome15[.]ru/Install.apk
• hxxp://leeroywork3[.]co/install.apk
• hxxp://morning3[.]ru/install.apk

There are several things that imply the developer of Xbot could be of Russian origin. The earlier versions of Xbot displayed a fake notification in Russian for Google Play phishing, there are Russian comments in its JavaScript code, and the domains we’ve uncovered were registered via a Russian registrar. Xbot will also intercept SMS messages from a specific bank in Russia and parse them for bank account information, which it will exfiltrate if found. While later versions use English instead of Russian for the notification, the language was not changed elsewhere.

Figure 1. Xbot’s JavaScript code commented in Russian.

Phishing for Credit Cards and Bank Accounts

After being installed on an Android device, Xbot will start communicating with its C2 server. When certain commands are received it will launch phishing attacks at users of Google Play and certain Australian bank apps. We observed three different phishing approaches and one use of activity hijacking. The four approaches with their commands are shown in Figure 2.

Figure 2. Xbot’s phishing commands.

If the C2 command is “cc_notify”, Xbot will display a fake system notification to the victim with the Google Play logo and the text “Add payment method” in either Russian or English (Figure 3). This imitates an actual popup the official Google Play app will show a user that has registered for the service but not yet provided a credit card. However, Xbot will display this whenever it receives the command, regardless of whether the Google Play app already has a credit card tied to it.

Figure 3. Code to display the fake notification in Russian or English.

If a victim clicks the fake notification, Xbot connects to its C2 server to download a webpage and display it with WebView. The page looks like Google Play’s actual interface for credit card information (Figure 4). Its user interaction procedures are also almost exactly the same as the legitimate version. All information input into this page will be uploaded to its C2 server (Figure 5). The information it asks for includes:

• credit card number
• expiration date
• CVV number
• card holder’s name
• card holder’s billing address
• card holder’s phone number
• VBV (Verified by Visa) or McSec (MasterCard SecureCode) number

Figure 4. Fake Google Play payment pages.

Figure 5. JavaScript code for uploading credit card information.

If the C2 command is “cc_dialog”, the fake notification step will be skipped and the fake Google Play webpage will be directly displayed to victims.

If the C2 command is “enable_inject”, Xbot will begin to monitor currently running apps via the getRunningTasks() API in Android. If the app running in the foreground is Google Play or one of several Australian bank apps (which is specified by the C2 server via the “add_inject” command), and immediately popup another interface on the top of running app (Figure 6). This is a classic attack technique called “activity hijacking”. Note that Android 5.0 implemented a security enhancement to keep apps from getting running app information through the getRunningTasks() API. So this attack won’t be effective on devices running Android 5.0 or later.

Figure 6. Code for hijacking Google Play and banking apps.

In the activity hijacking attack scenario, the faked app interfaces are also webpages downloaded from a C2 and displayed by WebView. So far we’ve found 7 different faked interfaces. We identified 6 of them – they’re imitating apps for some of the most popular banks in Australia. The interfaces are very similar to these banks’ official apps’ login interfaces. If a victim fills out the form, the bank account number, password, and security tokens will be sent to C2 server (Figure 8).

It’s worth noting that, since Xbot’s C2 server can remotely decide which faked app webpage to display, it would be easy to expand this attack to more apps without even having to update the code.

Figure 7. Example of an Xbot banking app phishing interface.

Figure 8. JavaScript code for uploading bank login information.

Locking, Encrypting, and Ransoming

After being installed, Xbot asks the user to authorize it as a device administrator. Then, if the C2 server sends the command “killon”, it will change the phone to silent mode, reset the password to “1811blabla”, then toggle the device screen to activate the new password.

Figure 9. Code to change the device password.

If the C2 command is “enable_locker”, Xbot will display a ransom webpage claiming to be Cryptolocker, still using WebView, from either “hxxp://23[.]227.163.110/locker.php” or another address specified by the C2 server. When we analyzing the sample, the webpage came from its C2 server, as seen in Figure 10:

Figure 10. Xbot ransom page.

Xbot will also start the onBackPressed(), onDestroy() and onPause() callback methods to prevent the user from exiting. Xbot will also encrypt the victim’s files in external storage (Figure 11). Currently, the encryption algorithm is pretty simple: just XOR each byte in all files by the fixed integer number 50.

Figure 11. Code to encrypt files in external storage.

According to the ransom webpage, the victim has to purchase a U.S. $100 PayPal My Cash Card from http://www.paypal-cash[.]com, and input the card number within 5 days. The webpage also says it’s impossible to decrypt the files by yourself, which is obviously not true for existing samples.

It should be noted that since the ransom page comes from a remote server, the attacker can update it to change the payment method and/or the amount of money at any time.

Information Stealing

Xbot has some additional capabilities. It will collect all contacts’ names and phone numbers and upload them to its C2 server, as well as all new SMS messages. In some samples, Xbot will also intercept and parse specific SMS messages. It parses all SMS messages sent by a specific premium rate SMS short number in an attempt to collect the victim’s account and confirmation numbers from a bank in Russia, and then uploads the information to its C2 server.

Figure 12. Code to steal SMS messages from a bank in Russia.

Conclusion

While Android users running version 5.0 or later are so far protected from some of Xbot’s malicious behaviors, all users are vulnerable to at least some of its capabilities. As the author appears to be putting considerable time and effort into making this Trojan more complex and harder to detect, it’s likely that its ability to infect users and remain hidden will only grow, and that the attacker will expand its target base to other regions around the world. We’ll continue to watch and report on this threat as the attacker introduces new versions. We also want to re-emphasize that the banking apps imitated by Xbot are not themselves being exploited.

Customers of Palo Alto Networks are protected with our WildFire, URL filtering, and IPS services. An AutoFocus tag has also been created to identify this family and its variants. Customers can also refer to IPS signature (13997) for details about Xbot C2 traffic information.

Acknowledgments

We greatly appreciate the help from Rongbo Shao, Yi Ren, Bowen Jiao, Michael Scott, Jen Miller-Osborn, Chad Berndtson, Chris Clark, and Ryan Olson from Palo Alto Networks in working on the analysis and coverage of Xbot family.

IOCs

Sample hashes

• dfda8e52df5ba1852d518220363f81a06f51910397627df6cdde98d15948de65
• e905d9d4bc59104cfd3fc50c167e0d8b20e4bd40628ad01b701a515dd4311449
• f2cfbc2f836f3065d5706b9f49f55bbd9c1dae2073a606c8ee01e4bbd223f29f
• 029758783d2f9d8fd368392a6b7fdf5aa76931f85d6458125b6e8e1cadcdc9b4
• 1264c25d67d41f52102573d3c528bcddda42129df5052881f7e98b4a90f61f23
• 20bf4c9d0a84ac0f711ccf34110f526f2b216ae74c2a96de3d90e771e9de2ad4
• 33230c13dcc066e05daded0641f0af21d624119a5bb8c131ca6d2e21cd8edc1a
• 4b5ef7c8150e764cc0782eab7ca7349c02c78fceb1036ce3064d35037913f5b6
• 7e939552f5b97a1f58c2202e1ab368f355d35137057ae04e7639fc9c4771af7e
• 93172b122577979ca41c3be75786fdeefa4b80a6c3df7d821dfecefca1aa6b05
• a22b55aaf5d35e9bbc48914b92a76de1c707aaa2a5f93f50a2885b0ca4f15f01
• d082ec8619e176467ce8b8a62c2d2866d611d426dd413634f6f5f5926c451850
• a94cac6df6866df41abde7d4ecf155e684207eedafc06243a21a598a4b658729
• 58af00ef7a70d1e4da8e73edcb974f6ab90a62fbdc747f6ec4b021c03665366a
• 7e47aaa8a1dda7a413aa38a622ac7d70cc2add1137fdaa7ccbf0ae3d9b38b335
• d1e5b88d48ae5e6bf1a79dfefa32432b7f14342c2d78b3e5406b93ffef37da03
• c2354b1d1401e31607c770c6e5b4b26dd0374c19cc54fc5db071e5a5af624ecc
• 12f75b8f58e1a0d88a222f79b2ad3b7f04fd833acb096bb30f28294635b53637
• 1b84e7154efd88ece8d6d79afe5dd7f4cda737b07222405067295091e4693d1b
• 616b13d0a668fd904a60f7e6e18b19476614991c27ef5ed7b86066b28952befc
• 2e2173420c0ec220b831f1c705173c193536277112a9716b6f1ead6f2cad3c9e
• 595fa0c6b7aa64c455682e2f19d174fe4e72899650e63ab75f63d04d1c538c00

C2 Servers and Malicious URLs

• melon25[.]ru
• 81[.]94.205.226:8021
• 104[.]219.250.16:8022
• hxxp://52[.]24.219.3/action.php
• hxxp://192[.]227.137.154/request.php
• hxxp://23[.]227.163.110/locker.php
• hxxp://market155[.]ru/Install.apk
• hxxp://illuminatework[.]ru/Install.apk
• hxxp://yetiathome15[.]ru/Install.apk
• hxxp://leeroywork3[.]co/install.apk
• hxxp://morning3[.]ru/install.apk

Cong Zheng, Claud Xiao and Zhi Xu

[Palo Alto Networks Blog]

As the speed and volume of threats today shows no abatement, there is much discussion that the only way to keep pace is through automation and self-learning. Although the answer sounds simple, the tough part is figuring out how we achieve this.

Most attackers look at the broad dossier of attack techniques today and, like any playbook, take some of what has been done before and try to sprinkle in a hint of their personalization to make it unique.  In today’s world this is no longer about simply creating a bad binary object and emailing it around with a smart, socially engineered subject line.

Take, as an example, Cryptowall v3.0. Ransomware is a simple concept; but, to succeed at that, attackers have had to leverage multiple campaigns with over 4,000 iterations of the attack binary using multiple exploits, including exploit tools such as the Angler exploit kit, compromising large numbers of public WordPress sites and building a complex array of over 800 command and control sites, just to name some of the aspects of the overall attack.  Once compromised, payments could hop through up to 80 bitcoin wallets before reaching their final destination. Why is all of this so important? The more we can map out attackers, the better we can find and block future iterations of their attacks.

In the physical world, criminals typically look just like every other person; and, today, with over 7 billion people on the planet, finding them can seem like an impossible task. Over the years, law enforcement experts have built techniques to uniquely identify criminal, such as photofits and, now, DNA. Such techniques not only uniquely identify criminals but also help link them to the crimes they have committed.

The same concepts apply in cyber, but today under a less mature guise. We rely on tools to identify unique characteristics much like looking for eye or hair color. The challenge being, when you look at any such characteristics in isolation, such as looking for a bad email characteristics or a certain hair color, the level of false alerts can be unreal. The once unique binary is like a face with makeup, so many different permutations are quickly achieved. As such we need to look at all the attributes and try to see the whole face of the attack – better still, the DNA of the attack. If we can do this, we can start to see existing attacks more accurately, allowing us to automate. The more we can automate the quicker we can detect. And, if we can gather the whole DNA, we can start to identify new attacks as they happen by their genetic links.

Going back to CryptoWall, when v4 came out, it had some enhancements. Of course the email messages delivering it changed, as did the binary, requiring many traditional approaches to need an update. However, most of the underlying infrastructure stayed the same. In the sci-fi film Jurassic Park, they filled in the DNA gaps to rebuild dinosaurs. Here we have the ability to make fiction into fact by mapping out the whole attack lifecycle (the DNA of the attack), which includes all of the indicators aligned to it (rather than just the indicators we see as compromising the victim), we can better detect and block not just the current attack but all future instances, forcing the attack to effectively create a whole new dinosaur. Effectively, we use the broader attack architecture DNA to fill in the gaps created by the dynamic components, such as the changing binary and delivery wrapping.

Why don’t we all do this today? DNA analysis happens in one lab; most security solutions simply look for an element of the attack. Much like the criminal photofit, they look at maybe the eyes or the nose or the hair — perhaps all three. But they typically don’t see the whole face, and they certainly don’t gather the entire DNA. It’s like having a bunch of labs looking at different atoms trying to join together the strands, which was not historically their goal. Their goal was to block the attack, not understand what makes the attack function in the broader sense.

To identify the DNA, we need to be able to join the right elements together. This means analyzing and correlating these characteristics; looking at the known and mapping against the unknown, we need to pull this into a single point of analysis so we can see the big picture. To achieve this at a vendor level, you need solutions that were nativity designed to talk the same language; otherwise they are not comparing like for like.

No vendor spans all the security requirements today. This is why protocols such as STIX, TAXII and Cybox have been developed to allow multiple vendors to collaborate in a virtual common lab, such as the Cyber Threat Alliance, acting as the interpreter to automatically exchange big data through a common translation structure to support better mapping of the attack DNA. Through this approach, the Cyber Threat Alliance worked collaboratively to uncover CryptoWall 3.

There are many ways of trying to keep pace with today’s threats; each has its own advantages and disadvantages. The challenge, however, is that most are still looking to improve the identification of a characteristic. To better spot the criminal among the billions of faces, we need to leverage every aspect we can to make them stand out as unique and at the same time identify commonality. What’s more important is that, with big data tools and common frames of reference, we can then look for these attributes to find their future faces. At the end of the day, you can easily change individual aspects of your appearance, but it’s extremely hard to change your DNA.

Greg Day

[Palo Alto Networks Blog]