Nov 20 2017

Lazarus Cybercrime Group Moves to Mobile Platform

When it comes to describing cyberattacks, the word sophisticated is used a lot. Whether to explain yet another “advanced” campaign by a threat actor group hoping to steal information or disrupt computer systems, it seems the precursor to any analysis is to call it sophisticated. Yet the modus operandi for many of these groups is to begin an attack with a simple email, which for some time has been one of the most effective malware delivery mechanisms.

The McAfee Mobile Research team has identified a new threat—Android malware that poses as a legitimate app available from Google Play and targets South Korean users—that suggests a deviation from the traditional playbook. An analysis of campaign code, infrastructure, and tactics and procedures suggests the Lazarus group is responsible, as they evolve their attack tactics to now operate within the mobile platform. And although the debate regarding attribution of attacks will always rage, documenting evolving tactics by threat actor groups allows organizations and consumers to adapt their defenses accordingly.

Evolving Attack Tactics

Leveraging email as the entry vector allows attackers to be very specific about whom they wish to target, often described as the spear phishing. Developing a malicious application does not provide the same level of granularity. However, in this instance the attackers developed malware that poses as a legitimate APK, advertising itself as means for reading the Bible in Korean. Leveraging the mobile platform as the attack vector is potentially significant—particularly as South Korea has a significant mobile population that is “in a race to be first with 5G,” according to a Forbes article. Typically when a mobile platform is mentioned, we think about our mobile phones. However, in this case, we know South Korea has an increasing use of tablets, replacing traditional laptops. How well secured are tablets and how are they monitored?

Evolving attacks onto the mobile platform are likely to continue, and this appears to be the first example of the Lazarus group using mobile. Such a change, therefore, is significant, demonstrating that criminals are keeping up with platform popularity. Indeed, according to the International Telecommunication Union, the global number of mobile subscriptions worldwide now exceeds the global population, which suggests that such a tactic is only likely to increase as our dependency on mobile platforms grows.

Source: International Telecommunication Union.

Keeping Safe

Understanding the evolving tactics by nefarious actors is imperative. It is critical that we adopt simple security measures to counter these new tactics. This malware is detected as “Android/Backdoor” by McAfee Mobile Security. Always keep your mobile security application updated to the latest version. And never install applications from unverified sources.

The post Lazarus Cybercrime Group Moves to Mobile Platform appeared first on McAfee Blogs.

Nov 20 2017

Android Malware Appears Linked to Lazarus Cybercrime Group

The McAfee Mobile Research team recently examined a new threat, Android malware that contains a backdoor file in the executable and linkable format (ELF). The ELF file is similar to several executables that have been reported to belong to the Lazarus cybercrime group. (For more on Lazarus, read this post from our Advanced Threat Research Team.)

The malware poses as a legitimate APK, available from Google Play, for reading the Bible in Korean. The legit app has been installed more than 1,300 times. The malware has never appeared on Google Play, and we do not know how the repackaged APK is spread in the wild.

Figure 1: Description of the legitimate app on Google Play.

Figure 2: An overview of the malware’s operation.

 

Comparing Certificates

The repackaged APK has been signed by a different certificate from the legitimate APK. We can see the differences in the following two screen captures:

Figure 3: The certificate of the malicious, repackaged APK.

Figure 4: The certificate of the legitimate APK.

Once the malicious APK installs its code, it attempts to execute the backdoor ELF from “assets/while.” If the ELF successfully executes, it turns the device into a bot.

Figure 5. The main function for executing the backdoor ELF.

 

Analyzing the Backdoor

Once the backdoor ELF starts, it turns into a zombie process to protect itself. It remains as a zombie even if the parent process terminates, as long as the “dex” execute() method has been implemented successfully.

Figure 6. The malware turns itself into a zombie process.

The malware contains a list of IP addresses of control servers. The list is encoded and written to the file /data/system/dnscd.db.

The preceding table lists information for each of the IP addresses. None of these is available now.

Figure 7. The flow of writing the encoded control server IPs to a file.

The IP address array is encoded by a simple routine when it is loaded into memory from the read-only data section; that encoded data is written to the file /data/system/dnscd.db. The decoded file is then loaded into memory to select an IP address to connect to.

One of control servers is selected randomly immediately before the backdoor process attempts to connect to its address. The attempt is performed repeatedly to successfully connect with one of the control servers.

Figure 8. The malware creates a socket and connects to a randomly selected control server.

Once connected with a control server, the malware begins to fill the buffer using a callback beacon. Figure 9 shows a part of the message-generating code. Several fields of the packet are hardcoded, particularly the bytes at offsets 0, 4, and 5. After we realized that the message only pretended to use the SSL handshake protocol, we understood the meaning of the hardcoded bytes. The byte at offset 0 is the handshake type; offsets 4 and 5 are the SSL version of the handshake layer, a part of transport layer security.

Figure 9. A part of the function for generating a callback beacon.

Figure 10. Transferring data to be used as the callback beacon to the control server.

After the message is generated, it sends the following packet (Figure 11) to the control server as a callback beacon. There is a randomly selected well-known domain in the packet where the server name indicator field is placed as a field of extension data. We suspect this is an evasion technique to avoid detection by security solutions looking for suspicious behaviors.

Figure 11. A captured packet from the callback beacon.

Figure 12. The list of legitimate (well-known) domains in the binary.

After sending the callback beacon, the malware assigns global variables that contain device information which is transferred to the control server once it receives the command code 0x5249. Figure 13 shows the jump table for implementing commands and its pseudo code.

Figure 13. The jump table for implementing commands from the control server and the structure for receiving data.

The functions are described in the following table. Command code and arguments arrive as structured data from the control server, as shown in Figure 13. The command code and arguments are assigned, respectively, to the CMD and DATA member variables of the received data structure.

After performing commands received from the control server, the malware returns the results to the control server using the codes in Figures 14 and 15. Before transferring the results, the return code and data are stored in a structure described in the following pseudo code.

Figures 14 and 15. The codes and data structure returned to the control server.

 

Similarities to Lazarus Malware

In Figure 16, the function on the left is from the backdoor ELF we have analyzed. On the right, we see procedures found in several executables used by the Lazarus Group in various attacks.

Figure 16. Similar functions to the executable used in the Sony Pictures attack.

Both functions look very similar. And the hexadecimal seeds for generating a key for encryption and decryption are the same. Both functions are also used to generate a message encryption and decryption key between the victim and control server. Figure 17 shows the functions of both the backdoor ELF and an executable recently used by the Lazarus Group. The function connects to the control server, and generates a disguised SSL ClientHello packet. Then the generated packet is sent to the control server as callback beacon.

Figure 17. The functions to establish a connection to the control server (ELF on the left).

The function in Figure 18 generates a disguised ClientHello packet to use as a callback beacon.

Figure 18. Generating the disguised ClientHello packet (ELF on the left).

Both backdoors use same protocol, as we confirmed when analyzing the function for receiving a message from the control server. Figure 19 shows the protocol for transferring a message between the backdoor and the control server.

Figure 19. The receive message function included in the checking protocol (ELF on the left).

To transfer a message from the source, the malware first sends a five-byte message to the destination. The message contains information on the size of the next packet, a hardcoded value, and the type of message. The hardcoded value is 0x0301 and the type of message can be between 0x14–0x17. The message type can also be used to check the validation of the received packet. The following is pseudo code from the receive function:

Figure 20. The five-byte packet sent before the source sends its primary message.

Figure 21. Pseudo code from the receive message function.

 

Conclusion

The security industry keeps an eye on the Lazarus Group, and McAfee Mobile Security researchers actively monitor for mobile threats by Lazarus and other actors. We compared our findings with the threat intelligence research of our Advanced Threat Research team, which studies several groups and their techniques. Due to the reuse of recent campaign infrastructure, code similarities, and functions such as the fake transport layer security, these tactics match many we have observed from the Lazarus Group.

We do not know if this is Lazarus’ first activity on a mobile platform. But based on the code similarities we can say it with high confidence that the Lazarus Group is now operating in the mobile world.

 

McAfee Mobile Security detects this malware as “Android/Backdoor.” Always keep your mobile security application updated to the latest version. And never install applications from unverified sources. This habit will reduce the risk of infection by malware.

The post Android Malware Appears Linked to Lazarus Cybercrime Group appeared first on McAfee Blogs.

Nov 14 2017

New Android Malware Found in 144 GooglePlay Apps

McAfee’s Mobile Research team has found a new Android malware in 144 “Trojanized” applications on Google Play. We named this threat Grabos because we found this string in several elements of the code, including variable and method names. Grabos was initially found in the Android application “Aristotle Music audio player 2017,” which claimed to be a free audio player on Google Play:

Figure 1. Trojanized music app in Google Play.

At the time Aristotle Music was discovered, the application had a very good rating. According to Google Play, the application was installed between one and five million times and had a recent comment from a user saying that the application was detected as malware:

Figure 2. User reporting the application Aristotle Music being detected as malware.

Grabos on Google Play

McAfee Mobile Research notified Google about Grabos in September and confirmed that Google promptly removed the reported application. After further research, we found another 143 applications (see complete list at the end of this post); all have been removed from Google Play. Six were removed after we reported the first to Google:

Figure 3. Additional Grabos Trojanized apps formerly on Google Play.

At the time of writing this post, 34 applications still had their webpages available in cache, so we were able to obtain additional information such as the approximate number of installs, last updated date, and rating. Most of these apps were last updated in August and October. They had an average rating of 4.4, and between 4.2 million and 17.4 million users downloaded these apps from Google Play:

Figure 4. Malicious apps details from Google Play.

Grabos likely evaded Google Play security measures because the injected code is protected with a commercial obfuscator, making it very difficult to statically analyze without executing the application. Even dynamic analysis to stop its execution is difficult without knowing what the app is checking. However, once we unpacked the code, we proceeded with our analysis.

“Fake” vs. “real” apps

We found Grabos injected in file explorer and music player applications, some of them open source. Every time that the app is opened, it checks if any of the following settings is not true to decide whether to launch the “fake” (legitimate functionality) or “real” (injected packed code) app:

  • isOnline: Checks if the device has Internet connectivity
  • getIsBlacklisted: Checks if the Android debug bridge (adb) and development settings are enabled or if the device is in an emulator. If the latter is the case, the device is blacklisted and the “fake” app is launched.
  • getIsForcedBlacklisted: Flag set by the control server.

The code also has a test mode that allows the execution of the “real” app in case it is running in an emulator or has adb and development settings enabled. These checks detect if the app is currently being dynamically analyzed and prevent the execution of the hidden code if necessary.

In case the app is not being analyzed or is in test mode, the “real” app launches. This hidden music downloader searches for a specific song on YouTube. Once the song is selected, it can be downloaded in MP3 or MP4 format to be played offline.

Figure 5. “Fake” vs “real” app flow. “BL” stands for “blacklisted.”

At this point, the application seems to be just a music downloader hidden in a Trojanized app that checks for dynamic analysis to avoid being removed from Google Play due to its downloading of copyrighted music. In the background, however, more is happening.

Communicating with the Control Server

In addition to the “fake” and “real” app functionality, Grabos is also present in the AndroidManifest as a receiver that executes every time there is a connectivity change or when the app is installed:

Figure 6. Grabos receiver in the AndroidManifest.

If the receiver is executed due to a connectivity change, the execution ends if the device is offline or if fewer than five seconds have passed since the last connection. If more than five seconds have already passed, the method “updateRemoteSettingsSynchronousTask” executes. This method collects and encrypts (Base64 plus Advanced Encryption Standard) the following data from the infected device:

  • Device information:
    • android_version
    • build_model
    • install_referrer
    • network_country
    • sim_country
    • carrier_name
    • language_code
    • country_code
    • time_timezone
  • Device location: Grabos uses free IP geolocation API services to obtain IP address information such as city, country code, ISP, organization, region, and ZIP code.
  • Device configuration:
    • is_emulator
    • is_rooted
    • is_adb_enabled
    • is_dev_settings_enabled
    • allow_mock_location
    • allow_non_market (unknown sources enabled/disabled)
    • is_vpn_connected
    • dp checks (additional root, debug, and emulator checks provided by the commercial obfuscator)
  • Installed Grabos app information: version_code, package_name, and install_time
  • Specific apps installed: Grabos reports if any app in a predefined list is currently installed on the infected device (more on this later).

All the information is encrypted and submitted to a control server. The remote server responds with encrypted data that contains parameters required to download music (URLs, API keys, user agents, client_id, etc.) to show advertainments (nativead_id, interstitial_id, banner_id, etc.) and display customized notifications such as asking the user to rate the app in Google Play:

Figure 7. “Rate this app” parameters provided by the control server.

The rating pop-up appears the first time the app is opened. If the button “Rate 5 Stars” is clicked, the app opens in Google Play so the user can rate the app there.

Figure 8. Rating pop-up.

In a similar way, the remote server also provides parameters to ask the user to share the app with friends and promising faster download speeds:

Figure 9. “Share the app” parameters provided by the control server.

The control server also sends the parameter “is_forced_blacklisted,” which manually blacklists the device if the value is “true”—to prevent the execution of the hidden app.

Mysterious functionality

In addition to reporting an infected device’s location and configuration, Grabos checks if specific social and Google apps are installed using the method isPackageInstalled and the app package name. Depending whether an app is currently installed, the corresponding value is set to true or false and that information is encrypted and reported to the control server:

Figure 10. Social and Google apps reported to the control server.

We reported this finding to Google, who are investigating. At this point we do not know the purpose of this app reporting. However, we believe this information could be very useful to malware authors because Grabos has implemented several mechanisms to trick users into installing applications provided by the remote server. Let’s look into those functions.

Custom Push Notifications and Additional Apps

After the initial settings are obtained from the remote server, the AsyncTask ShowNotificationIfNeeded is executed to check if the parameters n_title, n_description, and n_package were provided by the control server. If that is the case, Grabos checks if the app is available on Google Play (if “pack” is a name and not a URL) or on a remote server (if “pack” starts with HTTP).

If the application is not installed and is available, Grabos gathers additional parameters (for example, icon and bigicon) from the remote server response to create a custom notification and trick the user into installing the app:

Figure 11. Parameters provided by the control server to create a custom notification.

Grabos also checks if the remote server provided the following parameters:

  • interstitial_letang_options: provides values to delay and repeat the display of an activity (initial_delay and min_interval)
  • interstitial_letang: includes the following remote commands:
    • admob: executes method “showAdmobInterstitial”
    • nothing
    • grabos_direct

If the command is grabos_direct, Grabos gets the title, package, and max_times_shown values in the parameter grabos_direct_interstitial to open the app in Google Play or trigger a download:

Figure 12. Downloading an APK from a URL or open app on Google Play.

Both the notification and the interstitial_letang methods, to trick the user into downloading or installing apps, are executed in the background every time there is a connectivity change. However, Grabos also implements another app delivery method when the music downloader executes. This method, ShowGrabosIfNeeded, is very similar to interstitial_letang in that it checks if the required parameters are present and the app is available as well as checking if the app should be opened without the user’s consent:

Figure 13. Grabos checking whether the installed app should be opened.

As soon as Grabos confirms that the device is online, the app is available either on Google Play or a remote server, and the package is not installed, the malware gets the following parameters from the remote server response to create an AlertDialog and trick the user into downloading another app:

Figure 14. Grabos parameters to create an AlertDialog.

Flying Under the Radar: Evading Analysis

In addition to the multiple efforts to detect if the app is being dynamically analyzed (emulator, adb, development settings) and the encryption of the injected code, Grabos updates its remote settings every 24 hours (unless it is in test mode). This restriction can be easily bypassed by changing the date and time of the device used to analyze the app. However, recent versions of Grabos include checks to detect if the automatic date and time and time zone are enabled:

Figure 15. Grabos checks if automatic date and time and time zone are enabled.

The status of this setting is reported to the control server in the fields time_is_auto and time_timezone_is_auto. Although this check is not used in the Grabos code, the information could be used to determine if the app is being dynamically analyzed and decide if an additional payload should be delivered.

The URLs used as control servers indicate that Grabos tries to masquerade its network traffic as legitimate. At first sight the URLs appear to belong to familiar adware companies; the names are identical. However, instead of finishing with .com, Grabos uses domains such as .link and .click, which are not registered by the company.

Finally, Grabos defines an additional mechanism, currently not implemented, to blacklist or whitelist a specific device. For example, the device could be blacklisted or whitelisted in a future version depending on the country code or configured language of the infected device:

Figure 16. Blacklist and whitelist functions based on language and country code.

Grabos also defines (but does not implement) methods to blacklist a device based on IP address:

Figure 17. Blacklist functions based on IP address information.

Conclusion

During our analysis of this threat, the control servers always provided empty parameters for the custom notifications to trick users into installing applications. Taking into account the functionality to display ads and the high number of downloads, we believe the main purpose of Grabos is to make money by promoting the installation of apps.

Grabos gained popularity on Google Play because it allowed users to download music for free while constantly asking them to rate the app. However, users were not aware of the hidden functionality that comes with those apps, exposing them to custom notifications to download and install additional apps and open them without their consent.

Considering that Grabos also reports the presence of specific social and Google apps on infected devices, cybercriminals could use that information to deliver additional apps by tricking users into installing them using any of the notification methods implemented in the code. Although during our analysis the remote servers did not deliver the required parameters to trigger custom notifications, the devices remain exposed to the download of additional Android apps.

 

McAfee Mobile Security detects this threat as Android/Grabos. To protect yourselves from threats like this on Google Play, employ security software on your mobile devices, check user reviews, and avoid installing suspicious apps with screenshots or functionality that do not correspond to the name of the app.

We would like to thank Sebastian Porst and Jason Woloz from Google’s Android Security for their helpful contributions on this research.

List of Grabos Package Names

  • picklieapps.player
  • musicaplayer.stonetemples
  • mp3musicplayer.playmusicmp3
  • densebutter.musicplayer
  • airplaneapps.soundmeter
  • dinosaursr.musicplayer
  • tenuousllc.humneate
  • astropie.musicplayer
  • chargeshoes.videoplayer
  • callsaver.doubtful
  • unfestenedsail.freeapp
  • extendmilk.freeplayer
  • excellentlossapps.playermusic
  • AliciaTech.free
  • mp3player.musicplayer.freelocalmusicplayer
  • freemusicplayer.freemusicplayer.free
  • afromusicplayer.fremediaplayer
  • info_astro.glider_player
  • illfatednotice.humdrum
  • headybowl.musicplayer
  • musicgratisplayerfree.free
  • naturityllc.mp3player
  • anothertube.music.player
  • startdancingapps.callrecorder
  • social.video.saver.pro
  • gratis.video.downloader.hd
  • sportingapps.copyleft_music.player
  • auto_call_recorder.freeapp
  • freenewsreader.rssfeed
  • music.video.player
  • curatorinc.ringtone.search
  • mp3musicplayer.local_files_player
  • copyleft.stream.musica.player
  • mp3.music.player
  • nobodybeats.musicplayer
  • file.manager.pronessbest
  • ark.music.mp3.player
  • air.browser.free
  • aneeoboapps.playlistmanager
  • local_music_player.free_mp3_player
  • greenlinellc.voicechanger
  • free.playlist.creator.tube
  • toporganizer.fileorganizer
  • thumb.webbrowse
  • aspirator.ringtones.player
  • freevideoplayer.musicplayer
  • vimfast.videodl
  • whimsical.piano.free
  • truckneat.freeapp
  • crowdedarmy.volume.controller
  • arnold_legal.mp3.musica
  • descent.shutterfly
  • thankyou.arrowplayer
  • pocahantasapps.musicplayer
  • astroplayer.freee
  • couchpotato.musica.play_stream
  • abstractly.musica.player
  • matsumoto.mp3player
  • musicequalizer.freeequalizer
  • lifesbad.fileexplorer
  • videolunch.free
  • copyleft.cc.mp3.music
  • ark.music.mp3.player
  • musik.mp3.music
  • streamerplayer.stream_videos
  • voicerecorder.recordvoice
  • snip.browser
  • checkrein.musicapp
  • mp3musicplayer.freemusicplayer.playmusic
  • jadedprogram.mp3player
  • preoral.freeborn
  • voice.changer.freeappsapp
  • streamplay.stream.player
  • localmp3music.freeplayer
  • drummachine.machinedrums
  • coloringbook.freetrynow
  • videodownloader.social_video_download
  • ElephantApps.FileManager
  • scaricare.app.musica
  • quicksearch.tube.player
  • rooseveltisland.mp3player
  • mindprogram.musicf
  • freeborn.sdkintegration
  • koseapps.tubemusica
  • baixar.videos.gratis
  • adeptly.forgoneapp
  • musicas.gratis.player
  • miniaturef.swanky
  • insta.mp3.music.streamer
  • anchor.musicplayer
  • repeate.mp3musicplayer
  • FeisalLLC.MusicPlayer
  • shelfshare.freeapp
  • simple.streamer.player
  • streamplayer.freearnold
  • freeturkish.video.downloader
  • cowherd.freeapp
  • localmp3musicplayer.local_player
  • scaricare.apps.musica
  • silymove.freeapp
  • pinkphone.funfreetube
  • tissuepaper.freemusic
  • chopsuey.musicplayer
  • branchnotice.musicplayer
  • fradcip.MasterApp
  • music.player.mp3.ares
  • social.video.downloader.for_fb
  • frobenius.time.tube
  • spelldoom.comeup
  • bailymusic.player
  • sportifco.musicplayer
  • topsaver.video.downloader
  • coupleweeks.modcium
  • unbecomingllc.videodownloader
  • video.for_fb.downloader.saver
  • macdrop.apptool
  • callsaver.recorderfreeapp
  • arnie_legal.mp3.musica
  • kikiapps.freeplayer
  • pintaapps.expensetracker
  • marble.musicequalizer
  • artproject.searcher
  • UnitTest.FreeApp
  • exudedplayer.freemusicplayer
  • blackballed.player
  • mp3player.decisiveapps
  • rusticd.musicplayer
  • byunhyeong.jungfree
  • voicelessapps.mp3musicplayer
  • localmp3player.freeplayer
  • kinokunya.free
  • socialvideo.downloader_vim
  • viastore.video.saver_for_fb
  • disarmbit.reache
  • crackerbalancellc.mp3converter
  • vaskollc.jpfree
  • freemusicplayer.musicplayfreetoolpalyer
  • combustionapps.musique
  • arnold.mp3.musica
  • purpleheadphones.audioplayer
  • unscalableapps.free
  • freefile.organizerfree
  • free.mp3.stream_cc_music
  • mp3uncle.musiccamera

The post New Android Malware Found in 144 GooglePlay Apps appeared first on McAfee Blogs.

Nov 01 2017

Pirate Versions of Popular Apps Infiltrate Google Play via Virtualization

The McAfee Mobile Research team recently found pirated applications of popular apps distributed on the Google Play store. A pirated app is one distributed usually outside of the official store as a free version of a legitimate app. Paid legitimate applications are leading targets of pirated versions. In this case, however, we found pirated copies being distributed on the official market.

The four pirated apps we found are developed by AE-funStudios, which offers versions of the common tool and games Flashlight, Race Car, Gun Shoot, and Chess. The download numbers of these apps are between 10,000–100,000. We contacted Google about these pirated apps; they were promptly removed from the Google Play store.

How do we know these apps are pirated versions? Let’s look at their structure. The following screenshot shows the pirated version of Chess, com.chess.chessfree.chessboard.chessgame.free.

In this app, we find the file ttttt in the assets folder. The file has no extension, but the format is APK, and in this case is the legitimate app Chess Free from a different developer. The bogus filename is already suspicious.

The pirate app attempts to create a virtual space using the class VirtualCore, installing the legitimate app in the virtualization space, and running it after it launches.

The component com.lody.virtual is a piece of virtualization technology. The virtualization component VirtualApp is published on github as open source. Thus the component itself is not malicious. It is a similar technology to Instant App, introduced from Android 8.0 Oreo that provides a framework for running an application in a virtual space without installation. The component creates a virtual memory space in a local process, and loads and executes an APK file in the memory space.

The pirated app makes the legitimate app in the assets folder behave like a part of the application by using the virtualization component, without installing the legitimate app on the device. Using this framework, the malware author can generate a new Trojan without repackaging (disassembling an app, inserting malware code, and rebuilding it as new package).

However, the virtualization technique is not the perfect framework for all Android apps. Those with diversion protection and complex structures will not run in a virtual space. By applying app protection technology against repackaging, for example, we believe that the risk of a legitimate application being abused will become very low.

Let’s consider the intent of the pirated app’s author. In the following screenshot, it appears the author intends to earn income from mobile app advertisements. From our investigation, however, the current versions of these pirated apps have no mechanisms to display advertisements or to intercept the communications of the related legitimate apps to gain the revenue. Perhaps this feature is under development for future updates.

Another scenario is that the developer of the pirated apps might plan to sell the developer account to a criminal organization because, as one website points out, popular accounts such as those on Facebook and Instagram are traded at high prices in the black market just like banking accounts and personal identity information. The developer account could also be used for malware and spyware distribution. Each application affected by these four pirated apps is very popular, with the number of users between 1 million to 50 million. The pirated versions offer the same functionality as the legitimate apps to attract and retain users looking for original applications.

McAfee Mobile Security detects these pirated apps as Android/PUP.Pirates.C and protects user devices as well as the legitimate developers’ rights. To further protect yourself against pirated apps, download only recommended and popular apps on official app stores, and pay attention to suspicious traits such as odd app titles, user-unfriendly descriptions, low-quality screenshots, and poor user reviews. Also, verify that an app’s request for permissions is related to its functionality.

 

The post Pirate Versions of Popular Apps Infiltrate Google Play via Virtualization appeared first on McAfee Blogs.