Category: Mobile Security

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.

Sep 12 2017

Android Click-Fraud App Repurposed as DDoS Botnet

The McAfee Mobile Research Team tracks the behavior of Android click-fraud apps. We have detected multiple implementations, including recent examples on Google Play in 2016 and Clicker.BN last month. These threats are characterized by a common behavior: They appear innocuous but in the background they perform HTTP requests (simulating clicks) on paid “advertainment” to make money for a specific developer.

This behavior means that a URL is permanently requested via HTTP. Hypothetically, if the target and frequency of that request were modified, we could classify it as a DDoS attack. After all, the app uses the same main malware functionality and botnet infrastructure. From ad fraud to DDoS is only one step—and that is what some variants of Clicker.BN have taken. We have now seen click-fraud Android Trojans repurposed to perform DDoS attacks.

Most of the control servers of this Android/Clicker botnet—aka WireX—were taken down in late August.

The apps that perform click-fraud and those that launch DDoS attacks have much in common: the technique to configure headers from the control server, the domains axclick[.]store and ww[56]8[.]ybosrcqo.us (which have been taken down though others remain active), how they keep control server parameters updated in the local cache, and how the target server performs each HTTP request without loading cache data. They are share methods of obfuscation, packing strategies, and methodology for publishing on Google Play.

The apps do have differences, however. The control server subdomain and GET methods vary, as well as the delimiters used to split the received parameters and the order and data of received parameters:

  • Click-fraud components receive:
    • Target URL
    • JavaScript function (to simulate mouse-over clicks)
    • User agent
    • Google Play package
  • DDoS components receive:
    • Target URL
    • User agent
    • HTTP referrer (same as target URL in our tests)

The DDoS variants put the traffic generation in a loop to fully complete each HTTP request many times:

DDoS authors increased the frequency of the HTTP requests to 100 per minute. (Click-fraud implementations send a request each 55 seconds using same code structure.)

Other DDoS variants perform a UDP flood attack on the target, based on data received from the control server (host and port) and implemented as follows:

The previous thread (C1343a) is executed 50 times by the following method (m7240a), which is invoked after loading the parameters from the control server. These are refreshed every 50, 55, or 60 seconds (depending on the variant).

All variants of this threat use an uncommon method to receive and parse parameters from the control server: They arrive inside the title tag of an HTML file, and vary based on a key string used to parse the parameters. We discussed this in our analysis of Clicker.BN.

We mentioned some other curiosities in our Clicker.BN post. The delimiter strings look a bit like anagrams: “WireX” comes from the string “snewxwri.” Early Clicker.BN variants used the delimiter “eindoejy,” which could represent “I enjoyed” or “die enjoy.” More delimiters are present in other variants of this threat.

 

Click fraud in 2017 could cost US$16 billion, according to one source. DDoS attacks have their own underground market. Moving from one mobile threat to another is not new. We have seen Android ransomware switch to banking Trojans (in 2016) and premium SMS Trojans move to wireless application protocol billing.

Malware authors pursue profits with different strategies, taking advantage of already developed infrastructure. In this case, Android/Clicker.BN created a mobile botnet and distributed the infecting vector on Google Play, repackaging the threat to look like a clean app and widely distributing it across the globe. The authors modified this malware only a little bit to launch the massive DDoS attack known as WireX.

McAfee Mobile Security detects this threat as Android/Clicker.BN!Gen and prevents its execution. To further protect yourself against malicious apps, use only legitimate app stores, and pay attention to suspicious traits such as nonsense names, missing descriptions, and poor user reviews. Also, verify that the app’s request for permissions are related to its functionality. Be wary when apps request device administration API access, which is usually requested only by security apps, antimalware, mobile device management, or corporate email clients. Most apps and games will never ask for device admin rights.

The post Android Click-Fraud App Repurposed as DDoS Botnet appeared first on McAfee Blogs.