RSS Security

❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayMcAfee Blogs

Roaming Mantis Amplifies Smishing Campaign with OS-Specific Android Malware

5 May 2021 at 18:17
Quel antivirus choisir ?

The Roaming Mantis smishing campaign has been impersonating a logistics company to steal SMS messages and contact lists from Asian Android users since 2018. In the second half of 2020, the campaign improved its effectiveness by adopting dynamic DNS services and spreading messages with phishing URLs that infected victims with the fake Chrome application MoqHao.

Since January 2021, however, the McAfee Mobile Research team has established that Roaming Mantis has been targeting Japanese users with a new malware called SmsSpy. The malicious code infects Android users using one of two variants depending on the version of OS used by the targeted devices. This ability to download malicious payloads based on OS versions enables the attackers to successfully infect a much broader potential landscape of Android devices.

Smishing Technique

The phishing SMS message used is similar to that of recent campaigns, yet the phishing URL contains the term “post” in its composition.

Japanese message: I brought back your luggage because you were absent. please confirm. hxxps://post[.]cioaq[.]com


Fig: Smishing message impersonating a notification from a logistics company. (Source: Twitter)

Another smishing message pretends to be a Bitcoin operator and then directs the victim to a phishing site where the user is asked to verify an unauthorized login.

Japanese message: There is a possibility of abnormal login to your [bitFlyer] account. Please verify at the following URL: hxxps://bitfiye[.]com


Fig: Smishing message impersonating a notification from a bitcoin operator. (Source: Twitter)

During our investigation, we observed the phishing website hxxps://bitfiye[.]com redirect to hxxps://post.hygvv[.]com. The redirected URL contains the word “post” as well and follows the same format as the first screenshot. In this way, the actors behind the attack attempt to expand the variation of the SMS phishing campaign by redirecting from a domain that resembles a target company and service.

Malware Download

Characteristic of the malware distribution platform, different malware is distributed depending on the Android OS version that accessed the phishing page. On Android OS 10 or later, the fake Google Play app will be downloaded. On Android 9 or earlier devices, the fake Chrome app will be downloaded.

Japanese message in the dialog: “Please update to the latest version of Chrome for better security.”

Fig: Fake Chrome application for download (Android OS 9 or less)


Japanese message in the dialog: “[Important] Please update to the latest version of Google Play for better security!”


Fig: Fake Google Play app for download (Android OS 10 or above)

Because the malicious program code needs to be changed with each major Android OS upgrade, the malware author appears to cover more devices by distributing malware that detects the OS, rather than attempting to cover a smaller set with just one type of malware

Technical Behaviors

The main purpose of this malware is to steal phone numbers and SMS messages from infected devices. After it runs, the malware pretends to be a Chrome or Google Play app that then requests the default messaging application to read the victim’s contacts and SMS messages. It pretends to be a security service by Google Play on the latest Android device. Additionally, it can also masquerade as a security service on the latest Android devices. Examples of both are seen below.

Japanese message: “At first startup, a dialog requesting permissions is displayed. If you do not accept it, the app may not be able to start, or its functions may be restricted.”


Fig: Default messaging app request by fake Chrome app


Japanese message: “Secure Internet Security. Your device is protected. Virus and Spyware protection, Anti-phishing protection and Spam mail protection are all checked.”

Fig: Default messaging app request by fake Google Play app

After hiding its icon, the malware establishes a WebSocket connection for communication with the attacker’s command and control (C2) server in the background. The default destination address is embedded in the malware code. It further has link information to update the C2 server location in the event it is needed. Thus, if no default server is detected, or if no response is received from the default server, the C2 server location will be obtained from the update link.

The MoqHao family hides C2 server locations in the user profile page of a blog service, yet some samples of this new family use a Chinese online document service to hide C2 locations. Below is an example of new C2 server locations from an online document:

Fig: C2 server location described in online document

As part of the handshake process, the malware sends the Android OS version, phone number, device model, internet connection type (4G/Wi-Fi), and unique device ID on the infected device to the C2 server.

Then it listens for commands from the C2 server. The sample we analyzed supported the commands below with the intention of stealing phone numbers in Contacts and SMS messages.

Command String Description
通讯录 Send whole contact book to server
收件箱 Send all SMS messages to server
拦截短信&open Start <Delete SMS message>
拦截短信&close Stop <Delete SMS message>
发短信& Command data contains SMS message and destination number, send them via infected device

Table: Remote commands via WebSocket


We believe that the ongoing smishing campaign targeting Asian countries is using different mobile malware such as MoqHao, SpyAgent, and FakeSpy. Based on our research, the new type of malware discovered this time uses a modified infrastructure and payloads. We believe that there could be several groups in the cyber criminals and each group is developing their attack infrastructures and malware separately. Or it could be the work of another group who took advantage of previously successful cyber-attacks.

McAfee Mobile Security detects this threat as Android/SmsSpy and alerts mobile users if it is present and further protects them from any data loss. For more information about McAfee Mobile Security, visit

Appendix – IoC

C2 Servers:

  • 168[.]126[.]149[.]28:7777
  • 165[.]3[.]93[.]6:7777
  • 103[.]85[.]25[.]165:7777

Update Links:

  • r10zhzzfvj[.]
  • 0204[.]info
  • 0130one[.]info
  • 210302[.]top
  • 210302bei[.]top

Phishing Domains:

Domain Registration Date 2021-03-15 2021-03-11 2021-03-08 2021-03-04 2021-03-04 2021-02-08 2021-02-06 2021-02-05 2021-02-04 2021-02-03 2021-02-01 2021-02-01 2021-01-31 2021-01-30 2021-01-30 2021-01-30 2021-01-29 2021-01-29 2021-01-28 2021-01-27 2021-01-25 2021-01-24 2021-01-23 2021-01-22 2021-01-21 2021-01-19 2021-01-16 2021-01-15 2021-01-12 2021-01-2


Sample Hash information:

Hash Package name Fake Application
EA30098FF2DD1D097093CE705D1E4324C8DF385E7B227C1A771882CABEE18362 com.gmr.keep Chrome
29FCD54D592A67621C558A115705AD81DAFBD7B022631F25C3BAAE954DB4464B com.gmr.keep Google Play
9BEAD1455BFA9AC0E2F9ECD7EDEBFDC82A4004FCED0D338E38F094C3CE39BCBA Google Play
D33AB5EC095ED76EE984D065977893FDBCC12E9D9262FA0E5BC868BAD73ED060 com.mrc.keep Chrome
8F8C29CC4AED04CA6AB21C3C44CCA190A6023CE3273EDB566E915FE703F9E18E com.hhz.keeping Chrome
21B958E800DB511D2A0997C4C94E6F0113FC4A8C383C73617ABCF1F76B81E2FD com.hhz.keeping Google Play
7728EF0D45A337427578AAB4C205386CE8EE5A604141669652169BA2FBA23B30 com.hz.keep3 Chrome
056A2341C0051ACBF4315EC5A6EEDD1E4EAB90039A6C336CC7E8646C9873B91A com.hz.keep3 Google Play
054FA5F5AD43B6D6966CDBF4F2547EDC364DDD3D062CD029242554240A139FDB com.hz.keep2 Google Play
DD40BC920484A9AD1EEBE52FB7CD09148AA6C1E7DBC3EB55F278763BAF308B5C com.hz.keep2 Chrome
FC0AAE153726B7E0A401BD07C91B949E8480BAA0E0CD607439ED01ABA1F4EC1A com.hz.keep1 Google Play
711D7FA96DFFBAEECEF12E75CE671C86103B536004997572ECC71C1AEB73DEF6 com.hz.keep1 Chrome
FE916D1B94F89EC308A2D58B50C304F7E242D3A3BCD2D7CCC704F300F218295F com.hz.keep1 Google Play
3AA764651236DFBBADB28516E1DCB5011B1D51992CB248A9BF9487B72B920D4C com.hz.keep1 Chrome
F1456B50A236E8E42CA99A41C1C87C8ED4CC27EB79374FF530BAE91565970995 com.hz.keep Google Play
77390D07D16E6C9D179C806C83D2C196A992A9A619A773C4D49E1F1557824E00 com.hz.keep Chrome
49634208F5FB8BCFC541DA923EBC73D7670C74C525A93B147E28D535F4A07BF8 com.hz.keep Chrome
B5C45054109152F9FE76BEE6CBBF4D8931AE79079E7246AA2141F37A6A81CBA3 com.hz.keep Google Play
85E5DBEA695A28C3BA99DA628116157D53564EF9CE14F57477B5E3095EED5726 com.hz.keep Chrome
53A5DD64A639BF42E174E348FEA4517282C384DD6F840EE7DC8F655B4601D245 com.hz.keep Google Play
80B44D23B70BA3D0333E904B7DDDF7E19007EFEB98E3B158BBC33CDA6E55B7CB com.hz.keep Chrome
797CEDF6E0C5BC1C02B4F03E109449B320830F5ECE0AA6D194AD69E0FE6F3E96 com.hz.keep Chrome
691687CB16A64760227DCF6AECFE0477D5D983B638AFF2718F7E3A927EE2A82C com.hz.keep Google Play
C88C3682337F7380F59DBEE5A0ED3FA7D5779DFEA04903AAB835C959DA3DCD47 com.hz.keep Google Play


The post Roaming Mantis Amplifies Smishing Campaign with OS-Specific Android Malware appeared first on McAfee Blogs.

Multi-tricks HiddenAds Malware

4 March 2020 at 05:01

Thousands of HiddenAds Trojan Apps Masquerade as Google Play Apps

The McAfee mobile research team has recently discovered a new variant of the HiddenAds Trojan. HiddenAds Trojan is an adware app used to display advertising and collect user data for marketing. The goal of such apps is to generate revenue by redirecting users to advertisements. There are usually two way to make money with adware; the display of advertising to a user’s computer and a per-click payment made if a user clicks on the ad.

Although it can be used for spreading and displaying advertising in an affiliate marketing program, adware can also be used to spread malware in an affiliate fraud program. Most adware programs will abuse a legitimate application to trick the user and increase the number of installations. In our analysis we focus on two fake versions of popular Android apps:

  • FaceApp: an app used to modify photos with machine learning.
  • Call of Duty: a famous game adapted for Android.

We notice that these applications are very popular and are usually downloaded by young people. Additionally, both apps are using the in app-purchase business model. These two elements are interesting because they increase the chance that people will search for free versions and have potentially low concerns regarding security. We also noticed several other HiddenAds variants masquerading as genuine apps, such as Spotify or other well-known games.

Globally, we observed more than 30,000 samples related to this HiddenAds campaign.

Figure 1. Multi-tricks HiddenAds campaign

Analyzed samples are not available on the Google Play Store; the delivery of the latest variants is mostly from untrusted parts of the internet that propose APK file downloads. YouTube channels have also been spotted with malicious links to download the fake apps.

These variants of HiddenAds use some other interesting technologies to trick users and thwart the analysis of malware researchers. In this blogpost, we will deep dive into the analysis of a fake FaceApp application.

Distribution Channel

These malware samples masquerade as popular applications so, when a user wants to find the apps from an unknown source, they could be infected by malware. For example, “Call of Duty” is a popular game, with many people searching for the mobile version online. If they are unfortunate, they may find the result shown below:

Figure 2. Distribution channel

In the video, the author provides download links. If we click the link to download the file, we receive “Call of Duty_1.0.4.apk” (as seen in Table 1). If we install this sample on our devices, we will be infected by this malware. Additionally, we spotted this malware on other untrusted sources.

Trick Techniques

  1. Application name trick.

As a user, we recognize an app by its name and icon. As a researcher, the package name is an identification of an application. This variant uses popular application names, icons and package names on the Google Play store, to trick users into thinking they are genuine applications.

Table 1: Basic Information of some threat samples.

We search for the application name on Google Play and click the search result to view its details.

Figure 3. FaceApp information on Google Play.

This is a very popular application with in-app purchases. If victims want to find a free cracked version from alternative sources, they may end up with our analysis sample. The application name, icon and version number of the Google Play app and the fake app are very similar. The file size, however, is very different so we should keep that very firmly in mind.

  1. Icon trick.

Normally, users expect the icons seen before and after installation to be the same. In this sample, they are different. The sample defines two icons in the AndroidManifest.xml file; the label of activity is “Settings”.

Figure 4.1. Two icons are defined in AndroidManifest.xml

Before we install the sample, we see it in File Explorer, showing the first icon (tv_icon.png). At the system installation view, we see the first icon too. Once we click the “Done” button, the sample is installed onto the device and the system shows the second icon (but_invertc.png).

                Figure 4.2. Icons before/during/after installation

This is the icon trick. Users are surprised after they install the sample as they cannot find the expected icon on their devices; they maybe think something went wrong during installation and the application failed to install. In reality, the application has already been installed; it is next to the system “Settings” application icon. When a user goes to launch the system “Settings” application, they have the possibility to click the fake icon instead, launching the malicious application.

  1. Launcher trick.

Once a victim clicks the fake “Settings” icon, the malicious app launches, as does the next stage of the trick.

Figure 5. Hidden icon after clicking “ok” button

The sample shows this alert dialog immediately; it does not perform country available checking. This is a deceptive message, to make victims believe that the icon is hidden because “Application is unavailable in your country”. In fact, the application is still running in the background. It is not unavailable in a given country, it is just unavailable for victims.

Obfuscation Technique

Above are the ways the app is used to defraud victims. Now, we look at the anti-analysis techniques of this sample. At the start of the application, it invokes a function MultiDex.install. MultiDex is a popular and valid Android module which is used to support multi DEX files. When we investigate this function, we are curious why a popular Android module invokes a function in a specific application module.

Figure 6. The malicious code in the “MultiDex.install” function

The question prompts us to do more analysis. Finally, we find that this is the malicious code entrance. It mainly does 2 things here:

  • Decrypt so library
    The decrypted function is very obfuscated, not only obfuscating the variable name such that it makes no sense, but also splitting a simple function into lots of sub-functions, each of which inserts lots of nonsense code, designed to thwart analysis.
  • Fortunately, we can understand the code and get the decryption process.

Figure 7.1. Splits into lots of sub-functions

Figure 7.2. One sub-function, lots of code is nonsense

Reading data from resource/string.xml file according to CPU type (Figure 8.2):

  • If CPU is arm64, read x1 value.
  • If CPU is armeabi, read x0 value.
  • Other CPUs are not supported.

Figure 8.1. Read data from resource string.xml file

The data has 2 parts, the first part is the header of the ELF file, the second part is an index of array.

  • From the index (“a58ax”) in the last step, we find base64 encoding data from the arrays.xml file.
  • Use base64 and XOR operation to decode the array and generate native code library.

Figure 8.2. Base64 encoding data in the file resources.arsc/res/values/arrays.xml

 3) Load so library to extract the DEX payload and, finally, the malicious code invokes system.load to load the so library and calls a native function.

Figure 9. Load so library and call a native function

In the native function, it will extract and decrypt the file assets/geocalc_lite.dat and restore the DEX payload to path /data/data/

DEX Payload Analysis

The DEX Payload is used for showing advertisements. The advertisement data comes from the server. Once the payload gets the data, it will show it on the device. From the code analysis, we see there are dozens of advertisement types (Figure 12.2). The payload, which is very complex, will load and show the data in different ways for each type.

  • Default Setting Parameters
    The DEX payload defines a base64 encoding string in code; we get lots of default setting parameters after decoding it:

Figure 10.1. Default setting parameters (Encoding)


Figure 10.2. Default setting parameters (Decoding)

This is a json object; it is very complex and below is the usage of some parameters:

  • metricsApiKey: The API Key of Yandex Metrica SDK.
  • installFrequencySeconds : This is used to control the frequency of ‘install’ request. The value decides the minimum time interval of sending ‘install’ requests (see the Request & Response section) which, in this instance, is 1000 seconds(16 minutes 40 seconds). The install request can only be triggered by the application launcher. However many times we restart the application, it only sends one request in 1000 seconds.
  • overappStartDelaySeconds : This is designed to control the delay of http requests. It is intended to execute malicious payloads after 30000 seconds (5 hours 20 minutes) from the first launch. But in the current version, this value is the same as ‘installFrequencySeconds’ and is used to control install frequency. The smaller value of ‘overappStartDelaySeconds’ and ‘installFrequencySeconds’ is used as the minimum time interval of sending install requests.
  • bundles_*(b,c,l,n): It looks like these are used for determining whether to show advertisements in these packages or not.

The parameter “domains” is an important one; it defines the remote server candidate list. Payload selects a random one as the remote server; if the selected one is unavailable, it will switch to the next one.

Request & Response

There are 3 types of requests in the payload, with different requests having different trigger conditions. We can only capture 2 types of requests:

Figure 11.1. Request & response capture

  1. ‘install’ Request
    During application launch, if the trigger conditions are satisfied, the payload will send an ‘install’ request to the remote server. This request has a file named “type” whose value is “install”.

Figure 11.2. Install request

The client filed is a json object too; it contains the versionName and sdkEdition information, both of which show that this payload is very new.

Figure 11.3  VersionName and sdkEdition definition

The responses from the remote server are often an empty json which increases the difficulty of our analysis. We continued testing for a few days and captured a non-empty response.

Figure 11.4. Response data

The remote server settings cover the default settings:

  • Enabled: Advertisement enabled flag, including below ‘b/request’ request. The default is False, and True is set from a remote server response.
    • 7 new domains in response: ‘’, ‘’, ‘’, ‘’, ‘’, ‘’ and ‘’
    • 7 default domains: “”,””,””,””,””, “” and “”

There are 7 new servers and 7 default servers, a total 14 servers, and we can ping all of them; they are alive.

2. ‘b/request’ request

This is a core request. There is a field named ‘type’ and its value is ‘b/request’ in this request.

Figure 12.1   b/request request

The library registers lots of event filters/observers and, when these events happen, the trigger conditions are satisfied, causing the library to send appropriate requests to the remote server.

Table 2: Event monitoring

Banner Type is used to identify the banner and Spot is used to identify the spotting of events.

Figure 12.2. Banner Type & Spot Type

 The response data is as below. It has 3 main functionalities:

  • ‘sdkUpdate’ data: Used to load updated versions of the SDK file.
  • ‘banners’ data: Used to show banner advertisements.
  • ‘mediatorSDKs’ data: Used to post mediatorSDKs requests on victims’ devices.

Figure 12.3. ‘b/request’ Response

  • Banner data

We mentioned that we captured a response of ‘b/request’ in Figure 11.1. The response contains one banner data, the fields of banner data are as below after decoding.

Figure 12.4. Banner data and ‘html’ field content

                ‘html’ is the most important field – payload content is loaded in a WebView by invoking the loadDataWithBaseURL API. According to the html, WebView will load the page from the first URL, hxxp:// This is a redirect URL that will redirect to different URLs each time we open it.  In our test, it redirects to a gambling website.

Figure 12.5. Redirect to a gambling website

  • mediatorSdks data: mediatorSdks data is a json array. Each item definition is as below. We cannot capture this type of data from the remote server as we do not know the real value of each field. According to our analysis, “tracking” is a URL list. Each URL will be executed on the device and the executed result sent to the remote server.

Figure 12.6. mediatorSdks item definition

3) Mediator Stat requests: After the Tracking URL executes, it will execute /sdk/stat/mediator_* requests to the remote server which just reports the execute results. There are 4 types of mediator requests, one is for reporting failure status, the other 3 types are for reporting success status. There are 3 types of success status; we guess that there are 3 types of Tracking URL in mediatorSdks data (Figure 12.6). Each type of Tracking URL uses each mediator stat request to report status.

Figure 12.7. 4 types of mediator stat request


This is a traditional Hidden Icon Ads malware; it hides the application’s icon first, then shows advertisements from the DEX payload. But it applies lots of technology to implement its purpose, to trick users into believing it is a normal application, to stymie the detection of security tools. The DEX payload is a very complex SDK – more than 14 candidates of remote servers are found, lots of event monitoring and remote trigger control, all of which mean this is a well-designed malware. Once victims are infected with this malware they are unlikely to realize it and, even if they do, they may not be able to locate and remove it.

McAfee Mobile Security detects this threat as Android/HiddenAds. To protect yourselves from this and similar threats, employ the McAfee Mobile Security application on your mobile devices and do not install apps from unknown sources.

For more information about McAfee Mobile Security, visit








The post Multi-tricks HiddenAds Malware appeared first on McAfee Blogs.