Category: Mobile Security

Jan 11 2018

North Korean Defectors and Journalists Targeted Using Social Networks and KakaoTalk

Recently, South Korean media wrote about North Korean refugees and journalists being targeted by unknown actors using KakaoTalk (a popular chat app in South Korea) and other social network services (such as Facebook) to send links to install malware on victims’ devices. This method shows that attackers are always looking for different ways to deliver malware.

The McAfee Mobile Research Team has acquired malicious APK files that were used in the targeted attacks. According to the articles, Google-shortened URLs were used to spread malware. We analyzed those statistics.

There are two versions of the dropper malware: “북한기도” (Pray for North Korea) and “BloodAssistant” (a health care app). In both cases, most clicks originated in South Korea and the most common browser and operating system combination was Chrome and Windows. (Android was the second most common.) The referrers diagram of BloodAssistant shows Facebook was used in 12% of cases to send the link to its targets.

In the case of the journalist who was targeted, the attacker sent a shortened link showing a thumbnail of another story written by the journalist, according to the news article. The link directs to ihoodtec[.]com/upload/newslist[.]php (now offline), which seems to be used for redirecting to links in other domains. This shortened URL was clicked by someone with an account at mail[.]police[.]go[.]kr, suggesting the shortened URL was also sent via email to the police address.

The number of clicks might not be meaningful because it can include access from malware researchers, but what is meaningful is that malware-download links were spread using different platforms: Facebook, KakaoTalk, email, etc.

Analysis

Dropper

All the malicious APK files (including additional variants) dropped the Trojan on the victim’s device. Although the apps look different, the dropper mechanism is identical. The following screens show the execution of the dropper files.

Figure 1: Screenshots of droppers.

When the dropper APK executes, it first checks whether the device is already infected. If not infected, it phishes the victim to turn on the accessibility permission. If the victim clicks the pop-up window, the view changes to the accessibility settings menu so the app can acquire the permission.

When the accessibility service starts, it overlays the window (by playing a video, for example) to hide the process of turning on required settings and dropping and installing the Trojan. The overlay is removed after the Trojan is installed. The following diagram explains the flow after executing the dropper malware.

Figure 2: Execution flow of the dropper.

Trojan

The dropped Trojan uses popular cloud services Dropbox and Yandex as a control server to upload data and receive commands. The following diagram explains the execution flow of the Trojan. The names of broadcast receivers and services (with some misspellings) may vary between samples but the execution is the same.

Figure 3: Execution flow of the Trojan.

When the dropped Trojan is installed, it saves device information in a temporary folder and uploads it to the cloud. It then downloads a file containing commands and other data to control the infected device. (We’ll explain the format of the downloaded file in the next section.) Most of the malicious behaviors—such as saving SMS, contact information, etc.—are implemented inside a separate dex file “core,” which is downloaded from the control server. This dex file is referenced in many places in the malware. The malicious functionality can be extended, as we’ll explain in the following section.

Command file structure

The command file has its own format. The following diagram explains the types of values. Offset designators are used to retrieve each value when parsing the file. The next table explains each value.

Figure 4: Command file format.

Figure 5: Command file values.

The handler for command code received from the cloud (CMD value) is implemented as a separate dex file and is downloaded either before or after the malware parses the command file. This mechanism allows the attacker to easily extend its malicious functionality without needing to update the whole malware.

Our analysis shows that only some of the commands are implemented now and uploaded to the cloud control server. Note Command 12 captures KakaoTalk chat logs.

Figure 6: Implemented commands.

Variants

We have found variants of the APKs that news articles initially reported on Google Drive. (The APKs on Google Drive are marked as malware and cannot be downloaded.) Some variants use different cloud services as their control servers while others drop the separate call-recording app “com.toh.callrecord” (assets/bbb). The following graph shows the relationships among variants and dropped files.

Figure 7: Relationships among variants.

The Actors

Initial malicious APKs we found were uploaded to Google Drive by the same account, and we found a connected social network account. By following activities of this account, we conclude with high confidence that this account was used to send shortened URLs to victims to get them to download malicious APK files.

The group behind this campaign is certainly familiar with South Korean culture, TV shows, drama, and the language because the account names associated with the cloud services are from Korean drama and TV shows, including the following:

Figure 8: Cloud service accounts.

We found the use of an interesting word, “피형” (“blood type”), which is not used in South Korea but is used in North Korea. (“혈액형” is the word for blood type in South Korea.) We also found a North Korean IP address in test log files of some Android devices that are connected to accounts used to spread the malware. However, Wi-Fi was on so we cannot exclude the possibility that the IP address is private.

By looking at the list of deleted folders in the cloud, we found one with the name “sun Team Folder,” possibly the name of the actors. This group has been active since 2016, according to the cloud storage creation date.

Figure 9: Deleted folder in the cloud.

Conclusion

This malware campaign is highly targeted, using social network services and KakaoTalk to directly approach targets and implant spyware. We cannot confirm who is behind this campaign, and the possible actor Sun Team is not related to any previously known cybercrime groups. The actors are familiar with South Korea and appear to want to spy on North Korean defectors, and on groups and individuals who help defectors.

McAfee Mobile Security detects this malware as Android/HiddenApp.BP. Always keep your mobile security application updated to the latest version, and never install applications from unverified sources. We recommend installing KakaoTalk only from Google Play. These habits will reduce the risk of infection by malware.

The post North Korean Defectors and Journalists Targeted Using Social Networks and KakaoTalk appeared first on McAfee Blogs.

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.