LeakerLocker: Mobile Ransomware Acts Without Encryption
We recently found on Google Play a type of mobile ransomware that does not encrypt files. This malware extorts a payment to prevent the attacker from spreading a victim’s private information. LeakerLocker claims to have made an unauthorized backup of a phone’s sensitive information that could be leaked to a user’s contacts unless it receives “a modest ransom.”
The McAfee Mobile Malware Research team has identified this ransomware as Android/Ransom.LeakerLocker.A!Pkg. We reported it to Google, which says it is investigating.
Two applications on Google Play carry this threat. “Wallpapers Blur HD” has been downloaded between 5,000 and 10,000 times. It was last updated on April 7. From reviews, we can see that one user complains why a wallpaper app requests irrelevant permissions such as calls, reading and sending SMS, access to contacts, etc.
The second malicious app is “Booster & Cleaner Pro,” last updated on June 28. It has been downloaded between 1,000 and 5,000 times. Its rating is 4.5, much higher than Wallpaper’s 3.6. This rating, however, is not a safety indicator because fake reviews are very common in fraudulent apps.
Both Trojans offer apparently normal functions, but they hide a malicious payload.
Let’s examine “Booster & Cleaner Pro” to see what happens with this hidden payload.
At first execution, the malware displays typical functions of Android boosters. Due to the nature of this kind of application, users could be more willing to allow access to almost any permission.
After the boot is complete, the receiver com.robocleansoft.boostvsclean.receivers.BoorReceiver initiates AlarmManager, which along with other conditions starts the malicious activity com.robocleansoft.boostvsclean.AdActivity and locks the device’s screen.
LeakerLocker locks the home screen and accesses private information in the background thanks to its victims granting permissions at installation time. It does not use an exploit or low-level tricks but it can remotely load .dex code from its control server so the functionality can be unpredictable, extended, or deactivated to avoid detection in certain environments.
At this point the information has not been transmitted by the code in the original app, but a transfer could occur if the control server provides another .dex file.
When a victim inputs a credit card number and clicks “Pay,” the code send a request to the payment URL with the card number as a parameter. If the payment succeeds, it shows the information “our [sic] personal data has been deleted from our servers and your privacy is secured.” If not successful, it shows “No payment has been made yet. Your privacy is in danger.” The payment URL comes from server; the attacker can set different destination card numbers on the server.
We advise users of infected devices to not pay the ransom: Doing so contributes to the proliferation of this malicious business, which will lead to more attacks. Also, there is no guarantee that the information will be released or used to blackmail victims again.