Category Archives: Android

Google removed nearly 600 apps from the Play Store for ad policy violation

Google announced to have removed nearly 600 Android apps in the official Play Store that were violating two ad-related policies.

Google removed from the official Play Store nearly 600 Android apps that were violating two ad-related policies, it also banned the same apps from Google AdMob and Google Ad Manager.

“As part of our ongoing efforts — along with help from newly developed technologies — today we’re announcing nearly 600 apps have been removed from the Google Play Store and banned from our ad monetization platforms, Google AdMob and Google Ad Manager, for violating our disruptive ads policy and disallowed interstitial policy.” reads the Google announcement.

The apps violated disruptive ads policy and disallowed interstitial policy that were established to prevent mobile ad frauds.

Google remarks that its policies don’t allow apps containing deceptive or disruptive ads. Ads must only be displayed within the app serving them and the tech giant considers ads served in any app as part of the app. This means that the ads shown in the developers’ apps must be compliant with all Google policies.

Below the concept of disruptive ads described by Google in its policy: 

“Ads should not be shown in a way that results in inadvertent clicks. Forcing a user to click an ad or submit personal information for advertising purposes before they can fully use an app is prohibited.” reads the policy.

“Interstitial ads may only be displayed inside of the app serving them. If your app displays interstitial ads or other ads that interfere with normal use, they must be easily dismissable without penalty.”

Many users have noticed that some apps serve ads on a mobile device when the user is not active in their app, and clearly this behavior is not allowed by Google policies.

We describe these ads as “out-of-context” because they can be displayed in full screen at an inconvenient time, for example, while the users are accessing its mobile browser of is doing a different task.

“This is an invasive maneuver that results in poor user experiences that often disrupt key device functions and this approach can lead to unintentional ad clicks that waste advertiser spend. For example, imagine being unexpectedly served a full-screen ad when you attempt to make a phone call, unlock your phone, or while using your favorite map app’s turn-by-turn navigation.” continues the announcement.

“Malicious developers continue to become more savvy in deploying and masking disruptive ads, but we’ve developed new technologies of our own to protect against this behavior”

Google revealed that it has recently developed an efficient machine-learning based approach to detect when apps show out-of-context ads, the company used this innovative technique to identify and remove the malicious apps from its Play Store.

Using machine learning, Google is now able to detect when apps display out-out-of-context ads. This method helped find the apps that have been removed from the Play Store.

“As we move forward, we will continue to invest in new technologies to detect and prevent emerging threats that can generate invalid traffic, including disruptive ads, and to find more ways to adapt and evolve our platform and ecosystem policies to ensure that users and advertisers are protected from bad behavior.” concludes the post.

Pierluigi Paganini

(SecurityAffairs – Android, Play Store)

The post Google removed nearly 600 apps from the Play Store for ad policy violation appeared first on Security Affairs.

Private photos leaked by PhotoSquared’s unsecured cloud storage

With no password required and no encryption in place, a burglar or ID thief could have seen your photos, your address and more.

Voatz Internet Voting App Is Insecure

This paper describes the flaws in the Voatz Internet voting app: "The Ballot is Busted Before the Blockchain: A Security Analysis of Voatz, the First Internet Voting Application Used in U.S. Federal Elections."

Abstract: In the 2018 midterm elections, West Virginia became the first state in the U.S. to allow select voters to cast their ballot on a mobile phone via a proprietary app called "Voatz." Although there is no public formal description of Voatz's security model, the company claims that election security and integrity are maintained through the use of a permissioned blockchain, biometrics, a mixnet, and hardware-backed key storage modules on the user's device. In this work, we present the first public security analysis of Voatz, based on a reverse engineering of their Android application and the minimal available documentation of the system. We performed a clean-room reimplementation of Voatz's server and present an analysis of the election process as visible from the app itself.

We find that Voatz has vulnerabilities that allow different kinds of adversaries to alter, stop, or expose a user's vote,including a sidechannel attack in which a completely passive network adversary can potentially recover a user's secret ballot. We additionally find that Voatz has a number of privacy issues stemming from their use of third party services for crucial app functionality. Our findings serve as a concrete illustration of the common wisdom against Internet voting,and of the importance of transparency to the legitimacy of elections.

News articles.

The company's response is a perfect illustration of why non-computer non-security companies have no idea what they're doing, and should not be trusted with any form of security.

Google Play Protect prevented 1.9 billion malware installs from Third-party stores in 2019

Google Play Protect now scans over 100 billion applications on Android devices every day, these amazing figures were disclosed by Google.

In May 2017, Google introduced a security defense system called Google Play Protect to protect the devices running its mobile OS.

Google aims at monitoring the behavior of the apps and the detection of the malicious ones once they have been installed on Android devices.

Google Play Protect

Google Play Protect implements a machine learning and app usage analysis to identify any malicious activity on the mobile device, it is integrated into the Google Play Store app, this means that its usage is transparent to the end-user that doesn’t need to install or enable it on hid device.

Play Protect implements the following features:

  • App scanning
  • Anti-Theft Measures
  • Browser Protection

The security service also monitors the mobile apps that have been installed by users from third-party stores.

Now Google shared some data related to the activity of its protection system in 2019 when Google Play Protect prevented 1.9 billion malware installs from Third-party stores. The figures represent an increase compared to 1.6 billion, reported in the last two years ([2017], [2018]), they demonstrate the huge effort spent by the company to protect its users.

The data suggest that a growing number of Android users are attempting to install tainted apps from third-party app stores.

Google revealed that in 2019 it managed to block 790,000 violating app submissions before they were published in the official Play Store. 

“Google Play Protect scans over 100B apps everyday, providing users with information about potential security issues and actions they can take to keep their devices safe and secure.” reads the Google announcement. “Last year, Google Play Protect also prevented more than 1.9B malware installs from non-Google Play sources.”

Google reported that after the introduction of a new policy in 2018 to stop apps from unnecessarily accessing privacy-sensitive SMS and Call Log data, it has observed a 98% decrease in apps accessing such type of data.

Similarly to the SMS and Call Log policy, Google also enacted a policy to better protect families in May 2019, this resulted in the removal of tens of thousands of apps from the official Play Store, improving the security of the Android users.

“Our commitment in building the world’s safest and most helpful app platform will continue in 2020” concludes Google “and we will continue to invest in the key app safety areas mentioned in last year’s blog post:

  • Strengthening app safety policies to protect user privacy
  • Faster detection of bad actors and blocking repeat offenders
  • Detecting and removing apps with harmful content and behaviors”

Pierluigi Paganini

(SecurityAffairs – Google Play, malware)

The post Google Play Protect prevented 1.9 billion malware installs from Third-party stores in 2019 appeared first on Security Affairs.

Google Foiled Over 1.9B Malware Installs from Non-Play Sources in 2019

Google revealed that it blocked more than 1.9 billion installations of Android malware from non-Play Store sources over the course of 2019. On 11 February, Google revealed on the Android Developers Blog that it had succeeded in scanning billions of potential malware installations by creating a revamped Play Protect experience in 2019. This built-in malware […]… Read More

The post Google Foiled Over 1.9B Malware Installs from Non-Play Sources in 2019 appeared first on The State of Security.

Mac threats are growing faster than their Windows counterparts

Mac threats growing faster than their Windows counterparts for the first time ever, with nearly twice as many Mac threats detected per endpoint as Windows threats, according to Malwarebytes. In addition, cybercriminals continue to focus on business targets with a diversification of threat types and attack strategies in 2019. Emotet and TrickBot were back in 2019 Trojan-turned-botnets Emotet and TrickBot made a return in 2019 to target organizations alongside new ransomware families, such as Ryuk, … More

The post Mac threats are growing faster than their Windows counterparts appeared first on Help Net Security.

Critical Android Bluetooth flaw CVE-2020-0022 could be exploited without user interaction

Google addressed a critical vulnerability in its Android OS that affects the Bluetooth subsystem and could be exploited without user interaction.

Google has addressed a critical flaw in Android OS that affects the Bluetooth subsystem and could be exploited without user interaction.

The vulnerability tracked as CVE-2020-0022 is a remote code execution flaw that could allow attackers to execute code on the device with the elevated privileges of the Bluetooth daemon when the wireless module is active. The critical vulnerability impact Android Oreo (8.0 and 8.1) and Pie (9), while it is not exploitable on Android 10 for technical reasons and only trigger a DoS condition of the Bluetooth daemon.

“The most severe vulnerability in this section could enable a remote attacker using a specially crafted transmission to execute arbitrary code within the context of a privileged process.” reads the security bulletin published by Android.

The flaw was reported to Google by Jan Ruge from the Technische Universität Darmstadt, Secure Mobile Networking Lab.

The risk of exploitation of such kind of vulnerabilities is that they could be used to implement a ‘wormable‘ behavior in mobile malware that could rapidly spread from one infected device to another device that is in its proximity and reachable via Bluetooth.

The issue could be exploited only if the attacker knows the Bluetooth MAC address of the target, but this is quite easy to retrieve.

“On Android 8.0 to 9.0, a remote attacker within proximity can silently execute arbitrary code with the privileges of the Bluetooth daemon as long as Bluetooth is enabled.” the researcher wrote on a blog post on the site of IT security consultant ERNW. “No user interaction is required and only the Bluetooth MAC address of the target devices has to be known. For some devices, the Bluetooth MAC address can be deduced from the WiFi MAC address. This vulnerability can lead to theft of personal data and could potentially be used to spread malware (Short-Distance Worm).”

To mitigate the flaw, Ruge recommends disabling Bluetooth and enable it only “if strictly necessary.” If you need to activate Bluetooth, it is recommended to set the device non-discoverable for pairing with other devices.

Android users should apply the latest security patches as soon as possible.

Pierluigi Paganini

(SecurityAffairs – Android, hacking)


The post Critical Android Bluetooth flaw CVE-2020-0022 could be exploited without user interaction appeared first on Security Affairs.

93% of attempted mobile transactions in 2019 were fraudulent

93 percent of total mobile transactions in 20 countries were blocked as fraudulent in 2019 according to a report on the state of malware and mobile ad fraud released by Upstream. The number of malicious apps discovered in 2019 rose to 98,000, up from 63K in 2018. These 98,000 malicious apps had infected 43 million Android devices. Android is the most vulnerable OS With Android devices now accounting for an estimate 75-85% of all smartphone … More

The post 93% of attempted mobile transactions in 2019 were fraudulent appeared first on Help Net Security.

Hundreds of million users installed Android fleeceware apps from Google Play

Security experts from Sophos discovered 25 Android apps on the official Google Play that were involved in financial fraud, 600 million affected.

Security researchers from Sophos discovered a set of so-called fleeceware apps that have been installed by more than 600 million Android users.

Fleeceware apps are malicious applications uploaded to the official Google Play Store that were involved in fraudulent activities, these apps offer a short free trial period and if users don’t cancel the “subscription” they charge an excessive amount of money to the Android users.

“The total number of installations of these apps, as reported on Google’s own Play pages, is high: nearly 600 million in total, across fewer than 25 apps; A few of the apps on the store appear to have been installed on 100 million+ devices, which would rival some of the top, legitimate app publishers on Google Play.” reads the analysis published by Sophos.

“We have good reason to believe that the install count may have, in some cases, been manipulated. But some of the apps, including a popular keyboard app that allegedly transmits the full text of whatever its users type back to China, may legitimately have that many downloads.”

Experts warn of the business model behind the Fleeceware apps that can pose significant risks to the Android users,

In September Sophos published a first report that was warning of this phenomenon, the company discovered a first set of 24 Android apps that were charging huge fees (between $100 and $240 per year) for several generic apps (i.e. QR/barcode readers).

Now Sophos discovered a new set of Android “fleeceware” apps that attempt to monetize with this fraudulent behavior. have continued to abuse the app trial mechanism to impose charges to users after they uninstalled an app.

The fleeceware apps have a high install count, some of them have tens millions of installs, a circumstance that suggests that threat actors behind these apps may have used third-party pay-per-install services to increase the number of installed apps

“Some of these apps are very unprofessional looking. Based on past experience, it may have been the case that these app developers could have used a paid service to bloat their install counts and forge a large number of four- and five-star reviews.” continues the report. “You can identify some of these falsified user review clusters if you scrutinize the recent 5 star reviews; one-to-three word, five star reviews have a propensity to be “sockpuppet” reviews.”

Sophos has published a list of the apps classified as fleeceware.

Pierluigi Paganini

(SecurityAffairs – fleeceware apps, fraud)

The post Hundreds of million users installed Android fleeceware apps from Google Play appeared first on Security Affairs.

Apps are sharing more of your data with ad industry than you may think

Apps like Grindr, Tinder and Happn are (over-)sharing data about sexuality, religion, and location with a shadowy network of data brokers. And it's not just dating apps that are doing it...

PHA Family Highlights: Bread (and Friends)




“So..good..”
“very beautiful”
Later, 1 star reviews from real users start appearing with comments like:
“Deception”
“The app is not honest …”

SUMMARY

Sheer volume appears to be the preferred approach for Bread developers. At different times, we have seen three or more active variants using different approaches or targeting different carriers. Within each variant, the malicious code present in each sample may look nearly identical with only one evasion technique changed. Sample 1 may use AES-encrypted strings with reflection, while Sample 2 (submitted on the same day) will use the same code but with plaintext strings.
At peak times of activity, we have seen up to 23 different apps from this family submitted to Play in one day. At other times, Bread appears to abandon hope of making a variant successful and we see a gap of a week or longer before the next variant. This family showcases the amount of resources that malware authors now have to expend. Google Play Protect is constantly updating detection engines and warning users of malicious apps installed on their device.

SELECTED SAMPLES

Package Name SHA-256 Digest
com.rabbit.artcamera 18c277c7953983f45f2fe6ab4c7d872b2794c256604e43500045cb2b2084103f
org.horoscope.astrology.predict 6f1a1dbeb5b28c80ddc51b77a83c7a27b045309c4f1bff48aaff7d79dfd4eb26
com.theforest.rotatemarswallpaper 4e78a26832a0d471922eb61231bc498463337fed8874db5f70b17dd06dcb9f09
com.jspany.temp 0ce78efa764ce1e7fb92c4de351ec1113f3e2ca4b2932feef46d7d62d6ae87f5
com.hua.ru.quan 780936deb27be5dceea20a5489014236796a74cc967a12e36cb56d9b8df9bc86
com.rongnea.udonood 8b2271938c524dd1064e74717b82e48b778e49e26b5ac2dae8856555b5489131
com.mbv.a.wp 01611e16f573da2c9dbc7acdd445d84bae71fecf2927753e341d8a5652b89a68
com.pho.nec.sg b4822eeb71c83e4aab5ddfecfb58459e5c5e10d382a2364da1c42621f58e119b

3 Google Play Store Apps Exploit Android Zero-Day Used by NSO Group

Watch out! If you have any of the below-mentioned file managers and photography apps installed on your Android phone—even if downloaded from the official Google Store store⁠—you have been hacked and being tracked. These newly detected malicious Android apps are Camero, FileCrypt, and callCam that are believed to be linked to Sidewinder APT, a sophisticated hacking group specialized in cyber

Expanding bug bounties on Google Play

Posted by Adam Bacchus, Sebastian Porst, and Patrick Mutchler — Android Security & Privacy

[Cross-posted from the Android Developers Blog]

We’re constantly looking for ways to further improve the security and privacy of our products, and the ecosystems they support. At Google, we understand the strength of open platforms and ecosystems, and that the best ideas don’t always come from within. It is for this reason that we offer a broad range of vulnerability reward programs, encouraging the community to help us improve security for everyone. Today, we’re expanding on those efforts with some big changes to Google Play Security Reward Program (GPSRP), as well as the launch of the new Developer Data Protection Reward Program (DDPRP).

Google Play Security Reward Program Scope Increases

We are increasing the scope of GPSRP to include all apps in Google Play with 100 million or more installs. These apps are now eligible for rewards, even if the app developers don’t have their own vulnerability disclosure or bug bounty program. In these scenarios, Google helps responsibly disclose identified vulnerabilities to the affected app developer. This opens the door for security researchers to help hundreds of organizations identify and fix vulnerabilities in their apps. If the developers already have their own programs, researchers can collect rewards directly from them on top of the rewards from Google. We encourage app developers to start their own vulnerability disclosure or bug bounty program to work directly with the security researcher community.

Vulnerability data from GPSRP helps Google create automated checks that scan all apps available in Google Play for similar vulnerabilities. Affected app developers are notified through the Play Console as part of the App Security Improvement (ASI) program, which provides information on the vulnerability and how to fix it. Over its lifetime, ASI has helped more than 300,000 developers fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users until the issue is fixed.

To date, GPSRP has paid out over $265,000 in bounties. Recent scope and reward increases have resulted in $75,500 in rewards across July & August alone. With these changes, we anticipate even further engagement from the security research community to bolster the success of the program.

Introducing the Developer Data Protection Reward Program

Today, we are also launching the Developer Data Protection Reward Program. DDPRP is a bounty program, in collaboration with HackerOne, meant to identify and mitigate data abuse issues in Android apps, OAuth projects, and Chrome extensions. It recognizes the contributions of individuals who help report apps that are violating Google Play, Google API, or Google Chrome Web Store Extensions program policies.

The program aims to reward anyone who can provide verifiably and unambiguous evidence of data abuse, in a similar model as Google’s other vulnerability reward programs. In particular, the program aims to identify situations where user data is being used or sold unexpectedly, or repurposed in an illegitimate way without user consent. If data abuse is identified related to an app or Chrome extension, that app or extension will accordingly be removed from Google Play or Google Chrome Web Store. In the case of an app developer abusing access to Gmail restricted scopes, their API access will be removed. While no reward table or maximum reward is listed at this time, depending on impact, a single report could net as large as a $50,000 bounty.

As 2019 continues, we look forward to seeing what researchers find next. Thank you to the entire community for contributing to keeping our platforms and ecosystems safe. Happy bug hunting!

A Growing Number of Android Malware Families Believed to Have a Common Origin: A Study Based on Binary Code

Introduction

On Feb. 19, IBM XForce researchers released an intelligence report [1] stating that the source code for GM Bot was leaked to a crimeware forum in December 2015. GM Bot is a sophisticated Android malware family that emerged in the Russian-speaking cybercrime underground in late 2014. IBM also claimed that several Android malware families recently described in the security community were actually variants of GM Bot, including Bankosy[2], MazarBot[3], and the SlemBunk malware recently described by FireEye[4, 5].

Security vendors may differ in their definition of a malware “variant.” The term may refer to anything from almost identical code with slight modifications, to code that has superficial similarities (such as similar network traffic) yet is otherwise very different.

Using IBM’s reporting, we compared their GM Bot samples to SlemBunk. Based on the disassembled code of these two families, we agree that there are enough code similarities to indicate that GM Bot shares a common origin with SlemBunk. Interestingly, our research led us to identify an earlier malware family named SimpleLocker – the first known file-encryption ransomware on Android [6] – that also shares a common origin with these banking trojan families.

GM Bot and SlemBunk

Our analysis showed that the four GM Bot samples referenced by IBM researchers all share the same major components as SlemBunk. Figure 1 of our earlier report [4] is reproduced here, which shows the major components of SlemBunk and its corresponding class names:

  • ServiceStarter: An Android receiver that will be invoked once an app is launched or the device boots up. Its functionality is to start the monitoring service, MainService, in the background.
  • MainService: An Android service that runs in the background and monitors all running processes on the device. It prompts the user with an overlay view that resembles the legitimate app when that app is launched. This monitoring service also communicates with a remote host by sending the initial device data and notifying of device status and app preferences.
  • MessageReceiver: An Android receiver that handles incoming text messages. In addition to the functionality of intercepting the authentication code from the bank, this component also acts as the bot client for remote command and control (C2).
  • MyDeviceAdminReceiver: A receiver that requests administrator access to the Android device the first time the app is launched. This makes the app more difficult to remove.
  • Customized UI views: Activity classes that present fake login pages that mimic those of the real banking apps or social apps to phish for banking or social account credentials.

Figure 1. Major components of SlemBunk malware family

The first three GM Bot samples have the same package name as our SlemBunk sample. In addition, the GM Bot samples have five of the same major components, including the same component names, as the SlemBunk sample in Figure 1.

The fourth GM Bot sample has a different initial package name, but unpacks the real payload at runtime. The unpacked payload has the same major components as the SlemBunk sample, with a few minor changes on the class names: MessageReceiver replaced with buziabuzia, and MyDeviceAdminReceiver replaced with MDRA.

Figure 2. Code Structure Comparison between GM Bot and SlemBunk

Figure 2 shows the code structure similarity between one GM Bot sample and one SlemBunk sample (SHA256 9425fca578661392f3b12e1f1d83b8307bfb94340ae797c2f121d365852a775e and SHA256 e072a7a8d8e5a562342121408493937ecdedf6f357b1687e6da257f40d0c6b27 for GM Bot and SlemBunk, respectively). From this figure, we can see that the five major components we discussed in our previous post [4] are also present in GM Bot sample. Other common classes include:

  • Main, the launching activity of both samples.
  • MyApplication, the application class that starts before any other activities of both samples.
  • SDCardServiceStarter, another receiver that monitors the status of MainService and restarts it when it dies.

Among all the above components and classes, MainService is the most critical one. It is started by class Main at the launching time, keeps working in the background to monitor the top running process, and overlays a phishing view when a victim app (e.g., some mobile banking app) is recognized. To keep MainService running continuously, malware authors added two receivers – ServiceStarter and SDCardServiceStarter – to check its status when particular system events are received. Both GM Bot and SlemBunk samples share the same architecture. Figure 3 shows the major code of class SDCardServiceStarter to demonstrate how GM Bot and SlemBunk use the same mechanism to keep MainService running.

Figure 3. Method onReceive of SDCardServiceStarter for GM Bot and SlemBunk

From this figure, we can see that GM Bot and SlemBunk use almost identical code to keep MainService running. Note that both samples check the country in system locale and avoid starting MainService when they find the country is Russia. The only difference is that GM Bot applies renaming obfuscation to some classes, methods and fields. For example, static variable “MainService;->a” in GM Bot has the same role as static variable “MainService;->isRunning” in SlemBunk. Malware authors commonly use this trick to make their code harder to understand. However this won’t change the fact that the underlying codes share the same origin.

Figure 4 shows the core code of class MainService to demonstrate that GM Bot and SlemBunk actually have the same logic for main service. In Android, when a service is started its onCreate method will be called. In method onCreate of both samples, a static variable is first set to true. In GM Bot, this variable is named “a”, while in SlemBunk it is named “isRunning”. Then both will move forward to read an app particular preference. Note that the preferences in both samples have the same name: “AppPrefs”. The last tasks of these two main services are also the same. Specifically, in order to check whether any victim apps are running, a runnable thread is scheduled. If a victim app is running, a phishing view is overlaid on top of that of the victim app. The only difference here is also on the naming of the runnable thread. Class “d” in GM Bot and class “MainService$2” in SlemBunk are employed respectively to conduct the same credential phishing task.

Figure 4. Class MainService for GM Bot and SlemBunk

In summary, our investigation into the binary code similarities supports IBM’s assertion that GM Bot and SlemBunk share the same origin.

SimpleLocker and SlemBunk

IBM noted that GM Bot emerged in late 2014 in the Russian-speaking cybercrime underground. In our research, we noticed that an earlier piece of Android malware named SimpleLocker also has a code structure similar to SlemBunk and GM Bot. However, SimpleLocker has a different financial incentive: to demand a ransom from the victim. After landing on an Android device, SimpleLocker scans the device for certain file types, encrypts them, and then demands a ransom from the user in order to decrypt the files. Before SimpleLocker’s emergence, there were other types of Android ransomware that would lock the screen; however, SimpleLocker is believed to be the first file-encryption ransomware on Android.

The earliest report on SimpleLocker we identified was published by ESET in June 2014 [6]. However, we found an earlier sample in our malware database from May 2014 (SHA256 edff7bb1d351eafbe2b4af1242d11faf7262b87dfc619e977d2af482453b16cb). The compile date of this app was May 20, 2014. We compared this SimpleLocker sample to one of our SlemBunk samples (SHA256 f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96) using the same methods used to compare GM Bot and SlemBunk.

Figure 5 shows the code structure comparison between these two samples. Note that this SimpleLocker variant also has the major components ServiceStarter and MainService, both used by SlemBunk. However, the purpose of the main service here is not to monitor running apps and provide phishing UIs to steal banking credentials. Instead, SimpleLocker’s main service component scans the device for victim files and calls the file encryption class to encrypt files and demand a ransom. The major differences in the SimpleLocker code are shown in the red boxes: AesCrypt and FileEncryptor. Other common classes include:

  • Main, the launching activity of both samples.
  • SDCardServiceStarter, another receiver that monitors the status of MainService and restarts it when it dies.
  • Tor and OnionKit, third-party libraries for private communication.
  • TorSender, HttpSender and Utils, supporting classes to provide code for CnC communication and for collecting device information.

Figure 5. Code structure comparison between SimpleLocker and SlemBunk samples

Finally, we located another SimpleLocker sample (SHA256 304efc1f0b5b8c6c711c03a13d5d8b90755cec00cac1218a7a4a22b091ffb30b) from July 2014, about two months after the first SimpleLocker sample. This new sample did not use Tor for private communications, but shared four of the five major components as the SlemBunk sample (SHA256: f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96). Figure 6 shows the code structure comparison between these two samples.

Figure 6. Code structure comparison between SimpleLocker and SlemBunk variants

As we can see in Figure 6, the new SimpleLocker sample used a packaging mechanism similar to SlemBunk, putting HttpSender and Utils into a sub-package named “utils”. It also added two other major components that were originally only seen in SlemBunk: MessageReceiver and MyDeviceAdminReceiver. In total, this SimpleLocker variant shares four out of five major components with SlemBunk.

Figure 7 shows the major code of MessageReceiver in the previous samples to demonstrate that SimpleLocker and SlemBunk use basically the same process and logic to communicate with the CnC server. First, class MessageReceiver registers itself to handle incoming short messages, whose arrival will trigger its method onReceive. As seen from the figure, the main logics here are basically the same for SimpleLocker and SlemBunk. They first read the value of a particular key from app preferences. Note that the names for the key and shared preference are the same for these two different malware families: key is named “CHECKING_NUMBER_DONE” and preference named “AppPrefs”.  The following steps call method retrieveMessage to retrieve the short messages, and then forward the control flow to class SmsProcessor. The only difference here is that SimpleLocker adds one extra method named processControlCommand to forward control flow.

Class SmsProcessor defines the CnC commands supported by the malware families. Looking into class SmsProcessor, we identified more evidence that SimpleLocker and SlemBunk are of the same origin. First, the CnC commands supported by SimpleLocker are actually a subset of those supported by SlemBunk. In SimpleLocker, CnC commands include "intercept_sms_start", "intercept_sms_stop", "control_number" and "send_sms", all of which are also present in SlemBunk sample. What is more, in both SimpleLocker and SlemBunk there is a common prefix “#” before the actual CnC command. This kind of peculiarity is a good indicator that SimpleLocker and SlemBunk share a common origin.

Figure 7. Class MessageReceiver for SimpleLocker and SlemBunk variants

The task of class MyDeviceAdminReceiver is to request device administrator privilege, which makes these malware families harder to remove. SimpleLocker and SlemBunk are also highly similar in this respect, supporting the same set of device admin relevant functionalities.

At this point, we can see that these variants of SimpleLocker and SlemBunk share four out of five major components and share the same supporting utilities. The only difference is in the final payload, with SlemBunk phishing for banking credentials while SimpleLocker encrypts certain files and demands ransom. This leads us to believe that SimpleLocker came from the same original code base as SlemBunk.

Conclusion

Our analysis confirms that several Android malware families share a common origin, and that the first known file-encrypting ransomware for Android – SimpleLocker – is based on the same code as several banking trojans. Additional research may identify other related malware families.

Individual developers in the cybercrime underground have been proficient in writing and customizing malware. As we have shown, malware with specific and varied purposes can be built on a large base of shared code used for common functions such as gaining administrative privileges, starting and restarting services, and CnC communications. This is apparent simply from looking at known samples related to GM Bot – from SimpleLocker that is used for encryption and ransomware, to SlemBunk that is used as a banking Trojan and for credential theft, to the full-featured MazarBot backdoor.

With the leak of the GM Bot source code, the number of customized Android malware families based on this code will certainly increase. Binary code-based study, one of FireEye Labs’ major research tools, can help us better characterize and track malware families and their relationships, even without direct access to the source code. Fortunately, the similarities across these malware families make them easier to identify, ensuring that FireEye customers are well protected.

References:

[1]. Android Malware About to Get Worse: GM Bot Source Code Leaked
[2]. Android.Bankosy: All ears on voice call-based 2FA
[3]. MazarBOT: Top class Android datastealer
[4]. SLEMBUNK: AN EVOLVING ANDROID TROJAN FAMILY TARGETING USERS OF WORLDWIDE BANKING APPS
[5]. SLEMBUNK PART II: PROLONGED ATTACK CHAIN AND BETTER-ORGANIZED CAMPAIGN
[6]. ESET Analyzes Simplocker – First Android File-Encrypting, TOR-enabled Ransomware