Today Palo Alto Networks and Honeywell announced a collaboration to offer and develop joint Industrial Cybersecurity Solutions. This is huge for both companies but even better for our joint customers. Here are some reasons our existing and potential end users will benefit from this exciting news.
Access to the Entire Platform, Solution Roadmap – Honeywell, a Palo Alto Networks NextWave partner, is now offering the entire Palo Alto Networks platform (Next-Generation Firewall, Threat Intelligence Cloud, Traps Advanced Endpoint Protection) to the global industrial automation community. Coming out of the gate, we have a next-generation Level 3.5 solution that will bring industrial IT-OT perimeter security to the modern posture needed to effectively address the rising ICS threat landscape. Using the Next-Generation Firewall, the solution will give our end users unprecedented Layer-7 visibility and “zero-trust” network segmentation at the very granular application-user-content level. It will also offer indispensable Threat Prevention capabilities needed to combat both known and unknown threats. As technology partners we are also working closely to develop a technology integration roadmap for industrial cybersecurity use-cases across the different layers of the Purdue Model including Level 3 and below. We look forward to sharing more on our upcoming solution development as things progress.
Better Time to Market and Operational Support – Organizations can certainly develop their own industrial cybersecurity architectures, but why not take advantage of the proven reference architectures from Honeywell and Palo Alto Networks? As a systems integrator partner, Honeywell will make sure that the Palo Alto Networks-based solutions are deployed and maintained properly, backed by our world class customer support. In addition, the joint solution makes Honeywell’s managed industrial cybersecurity services available to customers. This is huge for those companies lacking the dedicated staff to fully benefit from real-time security monitoring and analytics.
Leadership and Vision – Here you have two industry leaders and innovators attacking the problem from two different perspectives. Honeywell’s roots are in industrial automation and hence they have a keen eye for reliability and safety when it comes to deploying cybersecurity. Palo Alto Networks has been about next-generation cybersecurity from day one offering a very powerful yet flexible platform that can be used in a range of environments including industrial applications. We see the different baselines of viewpoints as a great thing. Overlay the two perspectives together and you get the best Industrial Control Systems (ICS) cybersecurity solution that the industry has to offer. As leaders in our fields, we are committed to continue delivering solutions that can be deployed in such a way that not only addresses the growing ICS cybersecurity requirements but also accommodates the unique uptime and safety considerations.
Apple’s official iOS App Store is well known for its strict code review of any app submitted by a developer. This mandatory policy has become one of the most important mechanisms in the iOS security ecosystem to ensure the privacy and security of iOS users. But we recently identified an app that demonstrated new ways of successfully evading Apple’s code review. This post discusses our findings and potential security risks to iOS device users.
The app we identified is named “开心日常英语 (Happy Daily English),” and it has since been removed by Apple from the App Store. This app was a complex, fully functional third party App Store client for iOS users in mainland China. We also discovered enterprise signed versions of this application elsewhere in the wild. We had not identified any malicious functionality in this app, and as such we classified it as Riskware and have named it ZergHelper.
Figure 1: “Happy Daily English” available in the App Store
ZergHelper presents several security risks, include the following:
It provides installation of modified versions of iOS apps whose security can’t be ensured..
It abuses enterprises certificate and personal certificates to sign and distribute apps, which may include code that hasn’t been reviewed, or abuse private APIs.
It asks user to input an Apple ID while it also shares some Apple IDs to users. It will log in to an Apple server using these IDs to perform many operations in background.
Its author is trying to extend its capabilities via dynamic updating of its code, which could further bypass iOS security restrictions.
It uses some novel techniques that are sensitive and risky – techniques that could be used by other malware to attack the iOS ecosystem.
ZergHelper appears to have gotten by Apple’s app review process by performing different behaviors for users from different physical locations on earth. For users outside of China, it would act as what it claimed: an English studying app. However, when accessing the app from China, its real features would appear.
The app was made available in the App Store on October 30, 2015. However, nobody appeared to have noticed ZergHelper’s hidden functionality until February 19, 2016, when a user created a post in V2EX (a Chinese developer forum) to discuss it. We shared our findings with Apple on February 19, and Apple removed the app from the App Store later that day.
ZergHelper’s main functionality appeared to be to provide another App Store that includes pirated and cracked iOS apps and games. The app was developed by a company in China that named its main product “XY Helper”. ZergHelper was the non-jailbroken and “official App Store” version of this product.
In addition to its abuse of enterprise certificates, this riskware used some new and novel approaches to install apps on non-jailbroken devices. It re-implemented a tiny version of Apple’s iTunes client for Windows to login, purchase and download apps. It also implemented some functionalities of Apple’s Xcode IDE to automatically generate free personal development certificates from Apple’s server to sign apps in the iOS devices – which means the attacker has analyzed Apple’s proprietary protocols and abused the new developer program introduced eight months ago. ZergHelper also shares some valid Apple IDs with users so that they don’t need to use their own IDs.
ZergHelper’s code is complex and it’s still unclear whether it would steal account information and send it back to server or not. The app did send some device information automatically to a server for statistic tracking. The authors appeared to be trying to use the programming language Lua to make the app more extensible. Specifically, ZergHelper’s use of the framework means its code could be remotely updated without Apple’s further review.
We also identified over 50 ZergHelper apps that are signed by enterprise certificates. These apps were spread by authors in different channels.
ZergHelper’s Spreading and Functionality
ZergHelper was designed to be installed in this way: if an iOS user accessed XY Helper’s official website from China, the top advertisement banner would prompt a page saying that you could go to App Store to install their product “XY Apple Helper” (left of Figure 2). By clicking the button, the official App Store is automatically opened and the “Happy Daily English” app’s page is shown (right of Figure 2).
The original “Happy Daily English” app is open-sourced and hosted on OSChina as a project named “HappyEnglishSentences8k”. ZergHelper authors compiled it and embedded their own risky code. There appear to have been at least three people jointly developing it using the usernames of “xi”, “zhang” and “zhangzq”. The project’s internal name was XYFactory and the app’s internal name was “AppStore_4.0.1”.
Figure 2: Official website guides user to download ZergHelper from App Store
If you were to browse the app using the desktop browser or by iTunes client on any platform, the app’s name would be shown as “开心日常英语 (Happy Daily English)”. However, once it was installed on an iPhone or iPad, the name became “XY助手 (XY Helper)” with the same logo, just like the value of CFBundleDisplayName in the app’s Info.plist file (Figure 3). Our analysis suggests the authors inputted a different name when submitting the app to Apple through web form and Apple’s review process didn’t identify that inconsistency.
Figure 3: The app’s name is inconsistent with iTunes page
When the app launched, it would connect to the URL interface[.]xyzs.com immediately, and take different reactions based on result of the HTTP request (Figure 4). The webpage was configured to return a 404-not-found error if the access comes from an IP address outside of mainland China. In this situation, the app would only display an English study interface (left of Figure 5) – no other functionality was provided to users in these regions.
Figure 4: The app provices different functionality based on HTTP request result
Figure 5: Different interfaces will be showed for users from different locations
We don’t know where the App Store reviewers are located. If they are not located in mainland China, this method could trick them into seeing a legitimate app. Even if they’re in China, the author could just shut down that webpage during the review period so that reviewer could not see the actual functionality through an analysis of its behavior.
For users in China, the different user interfaces would appear (right of Figure 5). Then the app will guide to install two configuration profiles that it claims are for “resolving stability issues” but will actually install a device enrollment challenge and a web clip (Figure 6). These profiles were signed with a certificate of “xyzs.com” which was issued by Go Daddy Secure Certificate Authority on December 2, 2015. Note that the device enrollment challenge is used to enroll the device to related MDM (Mobile Device Management) system.
Figure 6: The app asks to install two profiles signed by certificate issued by GoDaddy
The app provided functionality of directly installing plenty of iOS apps and games to the device. It has pages for hot apps, hot games, top grossing apps, etc., just like the official App Store (Figure 7). The only difference is, all apps or games provided by ZergHelper are free, which means, they are likely pirated versions of the legitimate apps.
Figure 7: Main user interfaces
In the settings tab, for devices using pre-9.0 versions of iOS, a user could also input an Apple ID and password. The password would be remembered by the app. There’s another button used for “I don’t have an Apple ID. I would like to receive one for free” (Figure 8). We have not identified where these Apple IDs came from.
Figure 8: “I don’t have an Apple ID. I would like to receive one for free”
Novel Approach to Act as 3rd-party App Store on Non-jailbroken Devices
ZergHelper used unique ways to build a third-party App Store for non-jailbroken iOS devices. Each of them could be used to spread pirated or cracked iOS apps. Two of them are new methods of getting past App Store review that we haven’t previously observed.
Fake as Tiny iTunes Client
ZergHelper implemented the protocols between the iTunes client for PC and Apple’s App Store servers. To be more specific, these functionalities have been implemented in the app:
Log into the App Store, cache authentication data, and log out of the account
Click the term of service
Get an app’s information
Purchase an app (Figure 9)
Download the purchased app
When communicating with Apple’s server, ZergHelper used a User Agent like this:
iTunes/12.0.1 (Windows; Microsoft Windows 7 x64 Business Edition iTunes/12.0.1 (Windows; Microsoft Windows 7 x64 Business Edition
Hence the app is trying to act as an iTunes 12.0.1 client running on Windows 7 system.
Figure 9: Code to purchase an app by simulating the iTunes protocol
We’re still not very clear in which ways ZergHelper used these functionalities. It’s possible that they were used for the Apple ID given by users, or by the “free” Apple ID provided by the app itself.
Simulate Xcode to Apply Personal Development Certificate
The most surprising approach to installing apps on non-jailbroken devices is how ZergHelper abused free personal development certificates.
Previously, Apple only offered iOS development certificates for registered developers who paid an annual fee. This kind of certificate is necessary for anyone to sign an app and then run it on a physical device. From June 2015, Apple began to provide a new program that allows anyone with an Apple ID to receive a certificate for free. The functionality is embedded into Xcode since its 7.0 version and so far Xcode is the only official way to use this feature.
However, ZergHelper could have acted as Xcode to receive a valid personal development certificate from Apple’s authentication servers, too. Apple doesn’t disclose how this process works and how Xcode is implemented. Therefore, we think someone has reverse-engineered Xcode in detail to analyze this part of code so that they can implement exactly the same behaviors with Xcode – in effect, successfully cheating Apple’s server.
Figure 10: Login to Apple’s server
Figure 11: Fetch development certificate
Using the development certificate, ZergHelper could sign other iOS apps on iOS devices and then install them. There are limits on the number of iOS devices that can be authorized to use each certificate. Previously, people worried about whether the free certificates would be abused by someone to install pirated apps, but this technique shows abuse in a wide-ranging and automated way.
In the same week that we were analyzing ZergHelper, we observed someone selling source code that:
Automatically registers for Apple IDs by reversing protocols in phone and in PC
Offers app DRM authentication from PC for “helper utilities”
Automatically generates a personal development certificate by an Apple ID
The information was posted on a famous security forum in China in February 19, and was then deleted on February 20.
Figure 12: The deleted post of selling related source code (screenshot)
Authorize Pirated Apps from PC
For some pirated apps downloaded from ZergHelper’s server, the app asks the user to connect the iPhone or iPad to a PC for “authentication” with the help of the XY Helper’s Windows version. We have not reverse-engineered the Windows client. As far as we know, the purpose behind this is to implement the Windows client like an iTunes and to trick the iOS device into believing an iOS app has been authorized through the PC. (This attack technique has been in use with some tools for years.)
Abusing Enterprise Certificates
ZergHelper also abused enterprise certificates in a manner similar to other previously identified iOS malware, including WireLurker, YiSpecter and TinyV. In the app, these kinds of apps are tagged with “install in a second.” ZergHelper used the itms-service protocol for these apps’ installation. Compared with previous malware, the main difference in ZergHelper is that it would not only download itms-service plist file from C2 server, but it could also open a local port to install some apps onsite. This feature may have been designed for apps signed by personal certificates.
Figure 13: Enterprise signed apps’s PLIST files were hosted either on remote server or the local device
More ZergHelper Samples in the Wild
Apple’s App Store was just one “channel” through which ZergHelper was distributed. The authors also developed other versions that are all signed by different enterprise certificates. These versions were distributed through different channels and could be installed to non-jailbroken devices. For example, when you access XY Helper’s website, you could choose to install it from the App Store or directly from their server.
We found over 50 ZergHelper samples signed by nine different enterprise certificates. In their “xyChannelId.plist” files, the author specified 32 different channel IDs and 33 different channel names.
Figure 14: One of enterprise certificates being used to sign ZergHelper
Potential Security Risks
Apple’s Code Review
Previously there have been some malware (e.g., FindAndCall) or Proof-of-Concept apps (e.g.,Jekyll) that successfully made it into the official App Store. The most recent cases areXcodeGhost and InstaAgent. Compared with those, ZergHelper has more user interfaces and more significantly suspicious code characteristics. Apple typically doesn’t disclose any technical details regarding how its reviewers check apps to confirm they are not malicious. But ZergHelper demonstrates new techniques that can evade Apple reviewer scrutiny.
Enterprise Certificate
Since WireLurker, there have been more malware or evasive applications installed on iOS by abusing enterprise certificate. The biggest risk around this issue is the combination of enterprise certificate and private APIs. YiSpecter and Youmi have abused private APIs to collect private information on iOS. ZergHelper took another step to automatically generate development certificates for free. This is of concern because the abuse of these certificates may be the first step toward future attacks.
Apple ID
In the underground market for iOS tools, Apple IDs have become more and more important. In recent months, we’ve seen malware designed to steal Apple IDs (e.g., KeyRaider), take money from them (e.g., AppBuyer) and share them (e.g., YiSpecter). Some attackers ransom the stolen Apple IDs or phish for them. ZergHelper’s functionality also relied on valid Apple IDs. We’re still not certain whether ZergHelper could send stolen Apple IDs back to its server or not. Note that ZergHelper would provide free Apple IDs to its users, and we do not know from where these IDs originated. Use of Apple IDs only continues to grow, especially when we consider the amount of private data stored in iCloud and on iPhones and iPads.
Code Dynamic Loading
Apple requires every single update to an app in the App Store to be reviewed again before publishing. For ZergHelper, re-review increases the possibility of exposure. The authors appear to have tried to resolve this problem by using a scripting language.
ZergHelper used an open source project called wax, “a framework that lets you write native iPhone apps in Lua.” In the app, there’s a XYLib.lua file that only contains two functions so far. This Lua plugin will be loaded and executed when the app first launches. Through the wax library, this script could invoke many methods in the Objective-C runtime.
Figure 15: Lua plugin in ZergHelper
Apple disallows iOS app from dynamically loading new code or dynamically updating themselves. This is an important and useful security mechanism to mitigate the risk of some kinds of vulnerabilities and some malware. However, frameworks or SDKs like wax provide another way to bypass the restriction.
Dynamic code loading is a classic method used by malware to hide an author’s true intentions. In the last few years popular iOS SDKs that provide JavaScript, Lua or other script languages’ interface to Objective-C runtime have emerged. Considering how easy it is to write code in these languages, and how hard it is to analyze or to detect them, we think this approach may be adopted by more malware or PUAs in every popular platform (for example, the Android Trojan Xbot we recently revealed used JavaScript to implement part of its core functionality.)
Mitigation
We reported the issue to Apple on February 19 and Apple removed the app from the App Store on February 20.
For iOS users that have installed “开心日常英语” from App Store, or found “XY助手” in your devices, we suggest you uninstall it. We also suggest that users check profiles in their iOS devices (by Settings -> General -> Profiles & Device Management). If there’s any profile from “xyzs.com”, you should delete it immediately.
Acknowledgements
We greatly appreciate “i_82” for his help during the analysis. We also would like to thank the author of Surge for creating such awesome tool that greatly helped our analysis of ZergHelper. Last, we thank Ryan Olson and Chad Berndtson from Palo Alto Networks for assistance in developing this report.
The proliferation of data analytics in the world of internal audit has been a boon to some companies and a disappointment to others. Companies using analytics effectively are auditing with fewer resources and getting better coverage; reducing fraud, waste and abuse by the millions; and providing executives the ability to make smarter, data-driven business decisions.
But far too often, audit functions are launching data analytics that sputter, flame out and waste precious resources, and most immature data analytics programs are stumbling over the same few hurdles. Here are the five main hurdles and how to clear them.
Get Executive Buy-In From the Start
Data analytics is a disruptive technology, particularly for internal audit functions, and switching to data-driven decision making can be jarring for executives accustomed to basing decisions on intuition and business acumen alone. Preventing new data analytics initiatives from being stymied early on requires investment, agreement and evangelists at the top of the organization.
To win the hearts and minds of your executives, cherry pick a few analytics projects that promise a high return on investment through cost recovery or an increase in internal audit efficiencies. Audits of financial processes like T&E reporting or accounts payable often yield big returns from easy-to-access data. Demonstrate the value of a modest investment in analytics, and get your executives on board.
Plan for the Data Overload
With the quantities of data collected in most corporate environments today, sifting through all of them can be a headache. But byfront-loading your time—spending more time planning, identifying requirements and cleansing data—you can drastically improve the likelihood of a successful project and reduce the time spent on downstream analysis and review.
A key objective during the planning phase should be to identify all possible data streams that could impact the result of your planned analytic. Document those data streams, where they are stored, who the owners are, what related data might be relevant and what permissions will be needed to access them. By investing in an accurate inventory of the relevant data upfront, you can launch the project with confidence and avoid unexpected roadblocks or delays during the project.
Build a Data Analytics Team that Works
A recent Sunera survey of Fortune 50 to Fortune 2000 companies highlighted two key success factors for companies building internal analytics teams. First, companies with mature internal audit data analytics programs typically have resources dedicated specifically to data analytics. Second, program maturity correlates with the size of the data analytics team in relation to the overall internal audit function. A mature program often requires an investment of 10-15 percent of the overall internal audit budget. But with salaries skyrocketing and a high demand, it can be hard to snag the right professionals for your data analytics teams.
Using a strategic approach, you can build a skills-based team that fits the needs of your organization. Start by targeting individuals who have skills across a few key areas like business analysis, project management and data analysis. From there, look to add roles like IT specialist and data hygienist. These resources ensure you have the infrastructure support to scale your analytics programs. And finally, when you are ready for your data analytics program to really take off, consider adding individuals with graphic design skills for visual analytics and predictive analytics capabilities.
Fight Back Against Dirty Data
More than 25 percent of critical data in Fortune 1000 companies are “dirty,” meaning they are inaccurate, incomplete or duplicated. Dirty data can plague your data analytics initiative at any stage, derailing your budget, generating misleading results and potentially causing project failure.
The best (and only) way to fix the dirty data problem is through better institutional data governance. Proper data governance means clearly communicated objectives, processes and metrics; data quality controls and issue resolution processes; clear and documented data conventions; well-understood roles and responsibilities for analytics resources; and data governance training. Developing a robust system of data governance is worth the investment to ensure that quality data are available to your team.
Make Data Accessible With Visual Analytics
What good is data analytics if executives do not understand the results? That is the central question driving the spread of visual analytics platforms through audit functions nationwide. Visual analytics allows for meaningful exploration through analytic results, giving executives the ability to discover cost-saving or efficiency-improving trends, opportunities and relationships in the data.
Visual analytics gives executives and auditors a powerful tool to ensure that data deliver strategic and significant value to the organization. As you undertake each data analytics project, consider how the output can be visualized to communicate data in the language of your executives, speaking directly to the business challenge at the heart of the analytics initiative. With proper planning and a modest investment in tools and expertise, your organization can provide a far greater level of insight to executives making critical business decisions.
Cliff Stephens is a director in Sunera’s Data Analytics practice where he develops analytics to improve clients’ internal audit functions and provide value to executives. Before joining Sunera, Cliff created and led the Internal Audit Data Analytics team at Home Depot. To read Cliff’s full white paper on this topic, please visit https://sunera.com/data-analytics-pitfalls/.
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.
