New Android Marcher Variant Posing as Adobe Flash Player Update


Marcher is sophisticated banking malware that steals users’ financial information, such as online banking credentials and credit card details. We have observed Marcher evolving over time, using new tricks and payload delivery mechanisms. As we reported about previous encounters with this malware here, here, and here, the authors are using new techniques to spread infections, such as pornographic lures and the hype around new games.

In a recent wave, we are seeing the malware payloads disguised as Adobe Flash player. Upon opening the dropper URL, the user will be prompted by a message saying the device’s Flash Player is out of date, and the malware “Adobe_Flash_2016.apk” will be dropped on the user’s device. The malware will also guide the user to disable security and allow third-party apps to install, as shown in the screen below.

Fig 1: Payload delivery

We saw multiple payloads being served where ads were the initial source of infection.  

Fig 2: New Android Marcher wave

Upon installation, the malware quickly hides and removes its icon from the phone menu.

Following infection, the malware will register the infected device to its Command & Control (C&C) server. Along with the device’s meta information, the installed apps list is sent to the C&C server as shown below.

Fig 3: C&C communication

After a few sleep cycles, the malware waits for the user to open an app from its targeted list. We found that this variant is capable of targeting over 40 financial apps. When the user opens any of the targeted apps, the malware will quickly overlay a fake login page, which lures the victim into supplying user credentials. Some of the overlay pages are shown below.

Fig 4: Fake login pages
Unlike Marcher malware we’ve seen in the past, this variant maintains a JavaScript Object Notation (JSON) file that lists each targeted app and its fake login page hosting URL. This list is hardcoded in the malware payload. A screen capture is shown below.

Fig 5: Targeted apps list with the associated URLs that serve the overlay pages

The following is a list of financial apps targeted by the new Marcher variant:

  • org.morgbigorg.nonem
  • com.suntrust.mobilebanking
  • com.htsu.hsbcpersonalbanking
  • com.regions.mobbanking
  • com.clairmail.fth
  • com.tdbank
  • com.huntington.m
  • com.citizensbank.androidapp
  • com.usbank.mobilebanking
  • com.sovereign.santander
  • com.fi9293.godough
  • com.facebook.katana
  • com.moneybookers.skrillpayments

Unlike other Marcher malware, this variant is highly obfuscated, which explains the low antivirus (AV) detection rate. The VirusTotal screen capture below shows that less than 20 percent of AV scanners detected the new variant (at the time of the scan).

VT: 11/59 (at the time of analysis)

Fig 6: VT detection


Fig 7: Obfuscated code
The overlay (fake) login pages for the financial apps are hosted remotely, allowing the author to update them as needed. In the sample C&C communication shown below, the user on the infected device tries to launch the Commonwealth Bank of Australia app; it gets intercepted by the Marcher Trojan, which loads an overlay login page from a remote location.

Fig 8: Serving fake page in server response

If the user falls for the fake login page and enters his or her banking credentials, the Marcher Trojan relays the information to the C&C server, as shown in the screenshot below.

Fig 9: Credential harvesting


We have been seeing regular infection attempts for this Marcher variant in the past month. The frequent changes in the Marcher family indicate that the malware remains an active and prevalent threat to Android devices.

To avoid being a victim of such malware, be sure to download apps only from trusted app stores, such as Google Play. By unchecking the “Unknown Sources” option under the “Security” settings of your device, you can prevent inadvertent downloads from questionable sources.

Zscaler ThreatLabZ is actively monitoring Android Marcher and its variants to ensure that Zscaler customers are protected.

Indicators of compromise (IOCs):

Dropper URLs


from Zscaler Research

Report Reveals In-App Purchase Scams in the App Store

An investigation into App Store developer pay-outs has uncovered a scamming trend in which apps advertising fake services are making thousands of dollars a month from in-app purchases.

In a Medium article titled How to Make $80,000 Per Month on the Apple App Store, Johnny Lin describes how he discovered the trend, which works by manipulating search ads to promote dubious apps in the App Store and then preys on unsuspecting users via the in-app purchase mechanism.

I scrolled down the list in the Productivity category and saw apps from well-known companies like Dropbox, Evernote, and Microsoft. That was to be expected. But what’s this? The #10 Top Grossing Productivity app (as of June 7th, 2017) was an app called "Mobile protection :Clean & Security VPN".

Given the terrible title of this app (inconsistent capitalization, misplaced colon, and grammatically nonsensical "Clean & Security VPN?"), I was sure this was a bug in the rankings algorithm. So I check Sensor Tower for an estimate of the app’s revenue, which showed… $80,000 per month?? That couldn’t possibly be right. Now I was really curious.

To learn how this could be, Lin installed and ran the app, and was soon prompted to start a "free trial" for an "anti-virus scanner" (iOS does not need anti-virus software thanks to Apple’s sandboxing rules for individual apps). Tapping on the trial offer then threw up a Touch ID authentication prompt containing the text "You will pay $99.99 for a 7-day subscription starting Jun 9, 2017".

Lin was one touch away from paying $400 a month for a non-existent service offered by a scammer.

It suddenly made a lot of sense how this app generates $80,000 a month. At $400/month per subscriber, it only needs to scam 200 people to make $80,000/month, or $960,000 a year. Of that amount, Apple takes 30%, or $288,000 — from just this one app.

Lin went on to explain how dishonorable developers are able to take advantage of Apple’s App Store search ads product because there’s no filtering or approval process involved. Not only that, ads look almost indistinguishable from real results in the store, while some ads take up the entire search result’s first page.

Lin dug deeper and found several other similar apps making money off the same scam, suggesting a wider disturbing trend, with scam apps regularly showing up in the App Store’s top grossing lists.

It’s unclear at this point how these apps managed to make it onto the App Store in the first place given Apple’s usually stringent approval process, or whether changes to the search ads system in iOS 11 will prevent this immoral practice from occurring. We’ll be sure to update this article if we hear more from Apple.

In the meantime, users should report scam apps when they see them and inform less savvy friends of this scamming trend until something is done to eradicated it.

Discuss this article in our forums

from MacRumors : Mac News and Rumors

Ta-ta, security: Bungling Tata devs leaked banks’ code on public GitHub repo, says IT bloke

Staff at Indian outsourcing biz Tata uploaded a huge trove of financial institutions’ source code and internal documents to a public GitHub repository, an IT expert has claimed.

Jason Coulls, CTO of food safety testing company Tellspec and a former banking software developer, said he stumbled upon the collection of sensitive files after they were inadvertently leaked by a Tata developer in Kolkata, India. In the archive he found development notes, raw source, internal reports on web banking code development plans, and records of telephone calls with outsourcing partners.

The documents related to programming work Tata was carrying out for six big Canadian banks, two well-known American financial organizations, a multinational Japanese bank, and a multibillion dollar financial software company. The data is a boon for rival organizations developing similar features, as well as criminals who could exploit any weaknesses in the designs to potentially steal millions.

“The good news is that none of it was banking customers’ data, it was mainly auxiliary data,” Coulls told The Register late last week.

“But there was still a lot of useful stuff there – not just for hackers but for the firm’s competitors. The first bank that gets in to look at it gets to see what everyone else is doing. There was a monumental common sense failure.”


More than enough information to cause serious mischief … A screenshot of some of the leaked data, redacted for security reasons

When alerted to the leak, you’d expect the affected businesses to react quickly, however that was not the case, according to our man. Coulls, a Brit now based in Toronto, Canada, said he was rebuffed or ignored when he went to the Canadian banks.

By contrast, the American financial institutions were very receptive, we’re told, and responded immediately. The offending archive was taken down in short order from GitHub. Tata did not respond to requests from The Register for comment. The names of the affected clients have been withheld, for now, for security reasons.

What’s up with Canada, eh?

Coulls told The Reg that his experience with the intransigence of Canadian banks is no surprise – he has been on their backs about lax security for years and has seen little improvement.

“There is a massive cultural difference between Canada and the US,” he explained. “Canadians don’t want to pay for security info and I don’t work for free. But in the US I’ve had companies put someone on a plane on the same day for a meet-up in Toronto and they were buying me Guinness and discussing the issue with me that night.”

Coulls, who authored a takedown on Canadian banking software entitled “Not my monkeys, not my circus!”, said his research has shown nine out of 25 Canadian Schedule I banks are vulnerable to phishing attacks.

One bank’s app “vomits out huge chunks of data – 40MB pushed out to the browser with each transaction,” he said. Very few mobile banking apps make the effort to safeguard their communications either, he said.

Canuck commercial finance house bank Scotiabank is a particular target of Coulls’ ire. The bank’s app doesn’t always use HTTPS for connections, dropping to HTTP, we’re told.

“Right now there are at least a million people walking around with insecure banking apps and it’s only a matter of time before there’s a massive issue,” he said. “It’s not a happy situation; I laugh about it because if you don’t you’d cry.” ®

from The Register – Security

Keeping you safe with Google Play Protect

Whether you’re checking email for work, playing Pokémon Go with your kids or watching your favorite movie, confidence in the security of your device and data is important. And since day one, Android has been built with security in mind. As we’ve grown, so have our security services, which constantly protect the 2 billion active Android devices globally.

We know you want to be confident that your Android devices are safe and secure, which is why we are doubling down on our commitment to security. Today we introduced Google Play Protect—Google’s comprehensive security services for Android, providing powerful new protections and greater visibility into your device security. Play Protect is built into every device with Google Play, is always updating, and automatically takes action to keep your data and device safe, so you don’t have to lift a finger.

Google Play Protect

Peace of mind in the palm of your hand

With more than 50 billion apps scanned every day, our machine learning systems are always on the lookout for new risks, identifying potentially harmful apps and keeping them off your device or removing them. All Google Play apps go through a rigorous security analysis even before they’re published on the Play Store—and Play Protect warns you about bad apps that are downloaded from other sources too. Play Protect watches out for any app that might step out of line on your device, keeping you and every other Android user safe.


Control within reach, even when your device isn’t

One of the biggest security risks you’re likely to face is simply losing your phone. To help in these times of need, we’re launching Find My Device as part of Google Play Protect. With Find My Device you can locate, ring, lock and erase your Android devices—phones, tablets, and even watches. This feature is built in and enabled on all devices; visit or check out the app.

Over the coming weeks we’ll be rolling out these new features to your device. To learn more about Google Play Protect, check out our website or give Find My Device a spin.

from Android

Android Encryption Demystified

Share List

How many Android handsets are encrypted, and how much protection does Android encryption actually provide? With Android Nougat accounting for roughly 7% of the market, the chance of not being adequately protected is still high for an average Android user.

Android Central published an article titled More Android phones are using encryption and lock screen security than ever before. The author, Andrew Martonik, says: “For devices running Android Nougat, roughly 80% of users are running them fully encrypted. At the same time, about 70% of Nougat devices are using a secure lock screen of some form.”

This information is available directly from Google who shared some security metrics at Google I/O 2017.

“That 80% encryption number isn’t amazingly surprising when you remember that Nougat has full-device encryption turned on by default”, continues Andrew Martonik, “but that number also includes devices that were upgraded from Marshmallow, which didn’t have default encryption. Devices running on Marshmallow have a device encryption rate of just 25%, though, so this is a massive improvement. And the best part about Google’s insistence on default encryption is that eventually older devices will be replaced by those running Nougat or later out of the box, meaning this encryption rate could get very close to 100%.”

So how many Android handsets out there are actually encrypted? Assuming that 0.25 (25%) of Android 6 handsets use encryption, and 0.8 (80%) of Android 7 phones are encrypted, it will be possible to calculate the number of encrypted handsets out of the total number of Android devices.

Let’s have a look at the current Android version distribution chart:

  • Android 5.1.1 and earlier versions: ~62% market share
  • Android 6: 31 (31% market share) * 0.25 = 0.078
  • Android 7: 0.07 (7% market share) * 0.80 = 0.056

Google does not specify how many Android 5.x handsets are encrypted, but we assume that this number is very low since there were no requirements to encrypt such devices out of the box. While we don’t know for sure, Ars Technica had an excellent write-up on those older versions of Android “Why are so few Android phones encrypted, and should you encrypt yours?” Back then, their conclusion was that encryption in Android was too much of a performance hit to be voluntarily enabled by an average user.

So, considering the above statistics, we can tell that 13.4% of Android devices (Android 6 and 7) are definitely encrypted, plus an unknown number of Android 5.x handsets whose users may have enabled the optional encryption.

What exactly does that mean for the mobile forensic specialist? One can still chip-off an Android handset even if it runs the latest version of Android, and still get a good chance of being able to extract information.

Why Most Marshmallow Phones Don’t Use Encryption

Since Android 6.0 Marshmallow, Google requires manufacturers to enforce encryption in all new devices. This requirement only applies to devices shipped with Android 6.0 from the factory. In other words, if you received Android 6 as an OTA update, there will be no forced encryption for you (but you’ll be able to encrypt your phone from the settings). As an example, LG G Flex 2 was released with Android 5.0 and received the Marshmallow update a year and a half later. As a result, LG G Flex 2 does not have encryption enforced. On the other hand, Samsung Galaxy S7 was released with Android 6 on board, and it has forced encryption out of the box.

Similar logic applies to Android 7 handsets, although there are significantly more devices running Nougat that were updated from Android 6 (and thus already encrypted) rather than getting an update from Android 5.x (and not receiving forced encryption as a result).

The Types of Encryption in Android

We all know how Apple’s iOS encryption works. Full-disk block-level encryption with unique encryption keys for each data block, and an extra encryption layer for the Keychain (a system-wide secure storage database that keeps the most sensitive information such as Web forms and passwords, credit card information, authentication tokens etc.) The full-disk encryption in iOS protects the data securely. The user must authenticate with a passcode (if enabled) every time the device reboots in order to decrypt the data partition; the decryption key is not stored anywhere in the device, and is instead calculated dynamically based on information stored in the Secure Enclave as well as the passcode itself.

Android does not offer anything that can approach iOS in terms of encryption. Instead, Android employs a straightforward block-level encryption of the data partition. Pre-Lollipop devices were using the old insecure encryption scheme that was relatively easy to break. Since Android 5.0, Google switched to new full-disk encryption that became significantly more secure.

By default, the decryption key is stored in the hardware-backed storage using Trusted Execution Environment’s (TEE) signing capability (such as in a TrustZone). The data partition is decrypted with that key automatically once the device reboots. While this may sound lame (what’s the purpose of encryption anyway if the data can be decrypted without user interaction?), bear in mind that extracting the decryption key via chip-off or any other low-level method is not possible, so if you do a chip-off you won’t get the decryption key and won’t be able to decrypt the data.

Users who require additional security can activate boot-level protection by setting the requirement of typing a passcode or password in order to allow the device to continue booting. In this case, the encryption key is created dynamically based on user input as well as device data. There is no official data about the number of users who enabled this feature. Our guess is it is not a lot.

Android 7 introduced a new file-based encryption scheme. Little is known about it other than official information. Very few handsets implement this encryption scheme (mostly Nexus and Pixel devices); there is no obvious way to enable it. Users who manage to enable file-based encryption must perform a factory data reset. All this means that file-level encryption is rare as hen’s teeth. We haven’t seen any mentions of file-based encryption in Android O.

Extracting Data from Unencrypted Android Devices

The obvious way to extract information from an unencrypted but locked Android handset would be via the chip-off process. However, there are easier methods available for many devices.

The majority of Android handsets using a Qualcomm SoC have one or more emergency programming (EDL) modes such as 9006 and 9008. The different modes (as well as the different implementations of the lower-level 9008 mode) may allow for either mounting the phone’s eMMC/UFS partitions directly or accessing the storage in low level using the phone’s regular micro USB or USB Type C port. In order to make use of the 9006, experts only need a Qualcomm driver and experience in switching the device to that mode. The 9008 is more difficult as it requires specialized drivers and programmer code; it may also require a special service cable (“deep flash cable”) in order to switch the device into that mode.

LG smartphones feature their own software maintenance mode; a few forensic tools can make use of it to easily pull information from the flash drive. Samsung Exynos-based phones also have service modes that some forensic tools can exploit. MediaTek is known for its two-way emergency download mode that works on the majority of MTK-based phones. All this allows experts extracting information from Android devices relatively easily. With no encryption, it’s almost too easy to access data in Android devices.

More information:

from Advanced Password Cracking – Insight

Mobile Menace Monday: Ransomware targets Tencent users

Early this April, an increase of infection rates by a variant of ransomware known as Android/Ransom.SLocker.fh was seen.

Ransomware targets Tencent users

An especially relevant trait of SLocker.fh is its use of Tenpay to send payment to the criminals. Tenpay is an integrated payment platform by Tencent — China’s largest Internet service portals. Thus, it is no surprise that SLocker.fh originates from China.

In order to pay, users must have a QQ ID to send payment; which is provided.  Since Tencent’s most popular platform is QQ Instant Messenger, the criminals are probably targeting these users the most.

Various iterations to fool users

Like many Android ransomware apps, SLocker.fh masquerades as various legitimate apps to fool users into accepting escalated rights. Users who accept the escalated rights will have their device forced to reboot.  After reboot, users will have their device locked with overlaying screen with instructions to pay.

Click to view slideshow.
Click to view slideshow.

Stay protected

Because Android ransomware is on the rise, users should be extra cautious. You can protect yourself by being cautious of giving superuser and/or device administrator rights to any app that asks for it. If the app looks shady like the two example above, this is especially true.

So you’re infected with ransomware

A good anti-malware scanner like Malwarebytes Anti-Malware Mobile can remove the ransomware, but only BEFORE escalated rights are granted. Afterward, it becomes a bit harder. For how to remove such infections, refer to blog post “Difficulty removing Koler Trojan or other ransomware on Android?

As always, stay safe out there.

The post Mobile Menace Monday: Ransomware targets Tencent users appeared first on Malwarebytes Labs.

from Malwarebytes Labs

FalseGuide misleads users on GooglePlay

Is someone trying to build a botnet on Google Play?

Check Point mobile threat researchers detected a new strain of malware on Google Play, Google’s official app store. The malware, dubbed “FalseGuide,” was hidden in more than 40 guide apps for games, the oldest of which was uploaded to Google Play on February 14, 2017. Several of the apps managed to reach more than 50,000 installs, and the total number of infected devices is estimated to reach up to 600,000 devices. Check Point notified Google about the malware, and it was swiftly removed from the app store. At the beginning of April, two new malicious apps were uploaded to Google Play containing this malware, and Check Point notified Google once again.

Similar to previous malware found on Google Play, such as Viking Horde and DressCode,

FalseGuide creates a silent botnet out of the infected devices for adware purposes. A botnet is a group of devices controlled by hackers without the knowledge of their owners. The bots are used for various reasons based on the distributed computing capabilities of all the devices.

FalseGuide requests an unusual permission on installation – device admin permission. The malware uses the admin permission to avoid being deleted by the user, an action which normally suggests a malicious intention. The malware then registers itself to a Firebase Cloud Messaging topic which has the same name as the app. Once subscribed to the topic, FalseGuide can receive messages containing links to additional modules and download them to the infected device. After a long wait, we were able to receive such a module and determine that the botnet is used to display illegitimate pop-up ads out of context, using a background service that starts running once the device is booted. Depending on the attackers’ objectives, these modules can contain highly malicious code intended to root the device, conduct a DDoS attack, or even penetrate private networks.

FalseGuide masquerades as guiding apps for games for two major reasons. First, guiding apps are very popular, monetizing on the success of the original gaming apps. Second, guiding apps require very little development and feature implementation. For malware developers this is a good way to reach a widespread audience with minimal effort. The malicious apps were submitted under the names of two fake developers – Sergei Vernik and Nikolai Zalupkin, suggesting a Russian connection, while the second is clearly (to a Russian speaker) a made up name.

Mobile botnets are a growing trend since early last year, growing in both sophistication and reach. This type of malware manages to infiltrate Google Play due to the non-malicious nature of the first component, which only downloads the actual harmful code. Users shouldn’t rely on the app stores for their protection, and implement additional security measures on their mobile device, just as they use similar solutions on their PCs.

Appendix 1 – list of malicious apps found on Google Play

Package name App name Date Min Max
free.oosapp.infofifamobile Guide or FIFA Mobile 21.2.17 50000 100000
info.artapp.guidelegonexoknights Guide for LEGO Nexo Knights 15.2.17 10000 50000
free.oosapp.inforollingsky Guide for Rolling sky 20.2.17 5000 10000
info.artapp.guidelegocitymycity Guide for LEGO City My City 14.2.17 10000 50000
free.oosapp.infoterraria Guide for Terraria 20.2.17 10000 50000
free.oosapp.infoworldoftanksblitz Справочник для World of Tanks 20.2.17
info.artapp.guidezombietsunami Руководство для Zombie Tsunami 15.2.17
info.artapp.guidedriftzone Руководство для Drift Zone 2 22.2.17 1 5
info.artapp.guidemobilelegendsbangbang Руководство для Mobile Legends 22.2.17 1 5
info.artapp.guideinjusticegodsamongus Руководство для Injustice Gods 22.2.17 1 5
info.artapp.guideninjagoshadowofronin Руководство для Injustice Gods 22.2.17 1 5
info.artapp.guideasphaltairborne Руководство для Asphalt 8 22.2.17 1 5
free.oosapp.infocriminalcase Справочник для Criminal Case 21.2.17 1 5
free.oosapp.infonbalivemobile Справочник для NBA LIVE Mobile 21.2.17 1 5
free.oosapp.infohayday Справочник для NBA LIVE Mobile 21.2.17 1 5
free.oosapp.infosubwaysurfers Справочник для Subway Surfers 21.2.17 1 5
free.oosapp.infozombietsunami Справочник для Zombie Tsunami 21.2.17 1 5
free.oosapp.infogtasanandreas Справочник для Zombie Tsunami 20.2.17 1 5
info.artapp.guideterraria Руководство для Terraria 18.2.17 1 5
info.artapp.guidehayday Руководство для Hay Day 18.2.17 5 10
info.artapp.guideworldoftanksblitz Руководство для World of Tanks 18.2.17 1 5 Guide for Pokemon GO 1.3.17 50000 100000
guide.tipsamazingspiderman.infopro Guide Amazing Spider-Man 2 2.3.17 1000 5000 ProGuide LEGO Marvel Superhero 1.3.17 1000 5000
guide.tipsdreamleaguesoccer.infopro Guide Dream League Soccer 2.3.17 10000 50000 LEGUIDE LEGO City Undercover 27.2.17 10000 50000 Руководство для FNAF 2 1.3.17 1 5 Руководство для Roblox 1.3.17 1 5
guide.tipsfnaftwo.infopro Guide For FNAF 2 8.3.17 1000 5000
guide.tipsgreattheautovipcity.infopro Инструцкция The Auto Vip City 3.3.17 1 5 Руководство для Super Mario 28.2.17 Руководство Great The Auto 4 28.2.17 Руководство для Cadillacs 1.3.17 Руководство для Spider-Man 2 28.2.17
guide.tipssupermario.infopro Инструкция к Super Mario 2.3.17
guide.tipslegofriends.infopro Интсрукция к LEGO Friends 3.3.17 1 5
guide.tipsgreattheautofive.infopro Инструкция к Great The Auto 5 2.3.17 1 5
guide.tipsgreattheautofour.infopro Инструкция к Great The Auto 4 8.3.17 1 5
guide.tipscadillacs.infopro Guide for Cadillacs 3.3.17 5000 10000
guide.tipsroblox.infopro Guide for Roblox 3.3.17 10 50 Руководство для League Soccer 28.2.17 1 5 LEGUIDE LEGO City My City 27.2.17 5000 10000
com.megaguide.rollingsky.tricks Guide for Rolling Sky 11.4.17 500 1000
com.megaguide.legoninjagotournament.tricks Guide for Ninjago Tournament 6.4.17 50000 100000
 Total   218535 596160



Appendix 2 – list of SHA256 hashes:










































































The post FalseGuide misleads users on GooglePlay appeared first on Check Point Blog.

from Check Point Blog