THE LATEST ANDROID OVERLAY MALWARE SPREADING VIA SMS PHISHING IN EUROPE

In April 2016, while investigating a Smishing campaign dubbed RuMMS that involved the targeting of Android users in Russia, we also noticed three similar Smishing campaigns reportedly spreading inDenmark (February 2016), in Italy (February 2016), and in both Denmark and Italy (April 2016).

Unlike the RuMMS campaign, these three campaigns in Europe used view overlay techniques (the sametechnique we described being used by SlemBunk malware) to present nearly identical credential input UIs as seen in benign apps, subsequently tricking unwary users into providing their banking credentials.

Figure 1 shows the process of how these overlay malware spread via Smishing and infect Android users.

Figure 1. Overview

Threat actors typically first setup the command and control (C2) servers and malware hosting sites, then put the malware apps on the hosting sites and send victims SMS messages with an embedded link that leads to the malware app. After landing on the user’s device, the malware launches a process to monitor which app is running in the foreground on the compromised device. When the user launches a benign app into the foreground that the malware is programmed to target (such as a banking app), the malware overlays a phishing view on top of the benign app. The unwary user, assuming that they are using the benign app, will enter the required account credentials, which are then sent to remote C2 servers controlled by threat actors.

Through our close monitoring of overlay malware spreading via Smishing messages, we recently observed that these types of attacks did not stop despite publicity from security researchers. Instead, our systematic study revealed some interesting and simultaneously worrying findings:

• From February 2016 to June 2016, we observed 55 malicious binaries used in a series of Smishing campaigns targeting different countries in Europe. All the malware samples use the same view overlay technique to phish banking credentials, and all share the same C2 communication protocol. Besides the three publicly disclosed campaigns in Denmark and Italy, we observed the same threats targeting Germany in March 2016 and Austria from April 2016 to May 2016. In June 2016, we still see new samples emerging and being used to target users in Denmark; a few other European countries could be impacted as well.
• The key functions of these samples have been the same; however, over time, we noticed that the samples keep evolving in a few different directions. For example, later campaigns usually targeted more benign apps than earlier campaigns, focusing on messaging apps, for example, as opposed to banking apps. Also, the malicious apps used in later campaigns are often harder to analyze becauseobfuscation techniques were adopted to evade detection. In addition, some new functionality was added; in particular, we noticed that more recent samples leveraged reflection to bypass the SMS writing restriction enforced by the App Ops service (introduced in Android 4.3). All of this suggests that threat actors are actively improving their code.
• Unlike the RuMMS campaign, which mainly used shared hosting services to distribute the malware, the Europe Smishing campaigns show more diversity in the associated infrastructure, including the use of self-registered domains, compromised websites, and URL shortening services. Since February 2016, we observed that 27 Bit.ly links have been used. In June 2016, we noticed that another three URL shorteners, including tr.im, jar.mar and is.gd, were adopted in the latest campaign. This suggests that threat actors are trying to diversify the URL shorteners to avoid detection.
• In total, we identified 12 C2 servers hosted in five different countries that were involved in these campaigns. Among them, the IP address 85.93.5.109 has been used by 24 malicious apps in two campaigns and 85.93.5.139 has been used by eight malicious apps. We also observed that four C2 servers are within the same 85.93.5.0/24 network segment. All this suggests that the threat actors have control over considerable network resources.
• URL shortening services usually provide link analytics services, which enables us to collect data on how many users (from which countries) clicked particular short links and when it happened. Using these services, we found there have been at least 161,349 clicks on the 30 short links redirecting to the overlay malware, each of which can lead to the infection of one Android device. The date information indicated that most of the clicks occurred in the first few days after the links were created.

Five Europe Smishing Campaigns

From February 2016 to April 2016, security researchers reported on three campaigns involving Android overlay malware being distributed via SMS phishing messages. As described in the reports, those campaigns started with SMS phishing messages being sent to a user’s phone. An example SMS message in the latest campaign is shown in Figure 1. The message roughly translates to, “We could not deliver your order. Please check your shipping information here hxxp://bit[.]ly/1ZfcNeV”. Users in Denmark and Italy were reported to be the primary targets of these three campaigns.

Our recent investigation revealed that these activities keep developing, with other European countries, including Germany and Austria, being impacted as well. We group these activities into five campaigns, as shown in Table 1.

Table 1. Overview of the five Europe Smishing campaigns ordered in the beginning dates

(*: First publicized by FireEye researchers)

Shortened links were commonly used in the five campaigns. In total, we identified 30 short links. Some URL shorteners provide analytics, through which anyone can see how many people clicked the link and the countries those clicks came from. For example, Figure 2 shows that there were 135 clicks from Germany on one of the Whats-Germany samples, and 1,633 clicks from Austria on one of the Post-Austria samples.

Figure 2. Analytics pages on one Whats-Germany sample and one post-Austria sample

Code Evolution

In the aforementioned Smishing campaigns, we observed that the malware code has been evolving over time. The malware author(s) seems to be working diligently to improve the code by adding new target apps, obfuscating the code to evade detection, and trying to bypass App Ops restrictions.

Adding New Target Apps

All five campaigns attempt to steal credentials from various targeted apps. When the malicious app is started, a background service is triggered to periodically monitor the apps running in the foreground. When the service detects that the foreground app is one of its targeted apps, it overlays a carefully designed phishing view on top of the target app.

Analysis of the malware code shows that this task is executed by a method in the main service, namedinitInjTask in most cases. Figure 3 shows the code of initInjTask in one of the earliest samples of the MPay-Denmark campaign, in which only a localized app named MobilePay was targeted.

Figure 3. MobileBank class to be started to overlay app named “dk.danskebank.mobilepay”

(code extracted from app with a MD5 of 49dac3b35afb2e8d3605c72d0d83f631)

Figure 4 shows the code of initInjTask in one Whats-Italy sample, in which the target was changed to a more widely used app: WhatsApp Messenger.

Figure 4. Cards class to be started to overlay app named “com.whatsapp”

(code extracted from app with a MD5 of 97c2d04aa0f3c3b446fc228c1dbc4837)

Figure 5 shows the code of initInjTask in one Whats-Germany sample, in which two apps – WhatsApp and the Google Play Store – were targeted.

Figure 5. Cards class to be started to overlay apps WhatsApp and Play Store

(code extracted from app with a MD5 of 9e9d9a3717eed4d558a3f5eddb260901)

Figure 6 shows the code of initInjTask in one Post-Austria sample (in this case, the malicious app was obfuscated; the code was extracted from the dropped jar file). In total, eight worldwide popular apps – including Uber and Tencent’s WeChat – were on its radar.

Figure 6. cqkwjqjtoz class to be started to overlay apps 8 popular apps

(code extracted from app with a MD5 of d70296d3dc4937dedd44f93bb3b74034)

The code examples demonstrate changes in the malware over time. Early samples targeted single apps (a localized banking app and WhatsApp) while later samples included a broader range of apps, suggesting that the threat actors continue to both improve their malware and broaden their targeting, presumably for greater financial gain.

Code Obfuscation

In earlier campaigns, including MPay-Denmark, Whats-Italy and Whats-Germany, most of the malicious apps were not obfuscated and experienced reverse engineers can work readily with the disassembled code.

Figure 7 shows the manifest file and code structures for these earlier samples. With these two pieces of information, we see that three receivers are registered for various purposes: to handle incoming SMS messages; to request device-admin privileges; and to start the app at booting time and handle two application-specific events. There are also two services designed to be running in the background and four activities meant to interact with users. With this basic information at hand, adept malware analysts can readily figure out the role played by each part of the code and further understand how these pieces work together to achieve the malware’s goal.

Figure 7. Code structure and manifest file of earlier un-obfuscated code

Since April 2016, we observed that all the samples in our dataset had adopted obfuscation techniques. With the obfuscation, the manifest file became harder to read and the code structure looked totally different.

Figure 8 presents one sample in the PostDanmark campaign. The code structure on the left shows that there are five classes named “a”, “b”, “c”, “d” and “mrtbeig” with a same package name of “com.atrdectn.ioitsrc”. At the right side, the manifest file shows there are four receivers, seven services and four activities declared, with a different package name of “com.lpygioep.tjzcverotl”. So where is the code of these declared classes? What are the purposes of these classes named at left? Here the code is much more complex to analyze.

Figure 8. Code structure and manifest file of later obfuscated code

Deeper investigation showed that these classes defined on the left side compose the real payload and overlay the phishing view on top of the eight popular benign apps. Their code is in fact hidden in the asset file named mptxip.dat, which was encoded in a special manner beforehand.

The classes at the left side are actually unpacking code to decode the asset file, to load the real payload at runtime, and leverage reflection to execute the malicious code in the payload. This process is usually much more complex, and involves a round of static analysis first to understand what is in the code, then dynamic analysis to recover the real payload, and then both analyses to understand the real payload. Antivirus vendors often have difficulty identifying such threats. As of June 8, 2016, only 6 out of 54 anti-virus tools labeled these samples as malicious.

Bypassing App Ops Restriction

Android uses app permissions to restrict the set of sensitive actions a particular app can take. With earlier versions of the Android operating system, when an app is installed, the user is prompted to agree to the permissions the app requests. If the user declines, then the app isn’t installed – it is an all or nothing situation. App Ops is a service framework introduced in Android 4.3 that allows the permissions of individual apps to be changed at runtime. With App Ops, users can disallow some permission requests at runtime. Interestingly, we observed that, starting from the Whats-Italy campaign, the overlay malware began to adopt some code to bypass these runtime restrictions.

Figure 10 shows a code snippet in the class MainService, called by the launcher activity at app start time. It checks whether the build version of the device is 19 (Android 4.4) and whether the WRITE_SMS ops are disabled. If both conditions are true, the malware will call the method setWriteEnabled of classSmsWriteOpUtil (at line 93) to re-enable the permission of writing SMS.

Figure 9. Code to check and re-enable the permission of writing SMS

Figure 10 shows the major code of SmsWriteOpUtil to re-enable the SMS writing permission. At line 60, a handle to the system service App Ops is fetched. At line 61, reflection is used to get access to the particular class. At line 64 and 65, the reflection methods getMethod and invoke are used to call a method named setMode. These API methods are usually designed for use by other framework code or pre-installed apps. However, in this case threat actors use reflection to bypass the App Ops restriction.

Figure 10. Code using reflection to call App Ops service and to enable writing SMS

Hosting Sites

To execute Smishing campaigns, threat actors first have to determine where to host their malware. Shared hosting services were used heavily in the RuMMS campaign, but the threat actors in these five campaigns varied it up a bit by using self-registered domains, URL shorteners, and compromised websites.

Self-Registered Domains

In our investigation, we noticed that some of the URL domains were registered a few days before malware was hosted on the sites. Also, we found no other services were provided on these domains. These facts lead us to believe that those sites were registered specifically for the Smishing campaigns.

To lure victim users to clicks these links, the domain names were often carefully crafted for a particular campaign. For example, in the earlier MPay-Denmark campaign, threat actors used the Danish postal service provider as a theme and the Smishing messages came as: “You received an MMS from XXX. Follow hxxp://mms4you[.]us/mms.apk to view the message.” Thus, many of the domains included the words “mms” and/or “you”, such as mmsforyou.pw, mmsservice.pw and mmstildig.net (“til dig” is “for you” in Danish).

In the later PostDanmark campaign, the Smishing messages came as: “Your package is available for pick up. Follow hxxp://postdanmark[.]org/post.apk to see all the information on your package:” Thus, many URL domains had the words “post” and/or “danmark” present, such as postdanmark.net, postdanmark.online,postdanmark.menu and postdanmarks.com. Note that the official website for Post Danmark is “www.postdanmark.dk”, so all these phishing URLs were actually mimicking the official website for Post Danmark.

Shortened URLs

A small screen size makes shortened URLs perfect for mobile devices. Threat actors seem to understand this, and will leverage it for their own gain. While monitoring these five Smishing campaigns in Europe, we observed shortened URLs being used frequently. In total, we observed four different URL shorteners were used at least once, including bit.ly, tr.im, is.gd and jar.ma.

Of the four, bit.ly has been the most commonly used URL shortener. In total, we identified 27 bit.ly links were used from February 2016 to June 2016. The other three URL shorteners were not observed until June 2016, and only one was used for each service. Diversifying URL shorteners suggests that the threat actors are trying to avoid detection.

Compromised Websites

It is costly to use self-registered domains to host malware. More capable threat actors might choose to use compromised websites for the same purpose. Despite the risk of the victim site detecting the compromise and removing the malware, this method can be effective: the compromise is often not noticed until some time later, and the number of victim clicks is usually highest at the start of a campaign and decays a few days after the malware goes online.

While monitoring the five Smishing campaigns, we observed compromised websites were used frequently. For example, the analytics page for the shortened URL hxxps://bitly[.]com/1qRey7a+ shows that on April 13, 2016, website kgiexport.com was hosting an Android app with the file named post.apk.

How Many Clicks?

Two of the four URL shorteners, bit.ly and tr.im, provide analytics pages for each short URL created. Figure 2 showed analytics pages provided by bit.ly. Figure 13 shows a screenshot of the analytics page provided by tr.im. From these pages, we can collect data on how many people clicked the shortened URL at particular dates, and also the countries these clicks came from.

Figure 11. Analytics page provided by tr.im

Table 2 shows relevant information on the 28 short URLs we monitored.

Table 2. Click counts on each short URL

In total, the 28 short links were clicked 161,349 times. Of these clicks, 130,636 were from the PostDanmark campaign, which shows that phishing messages claiming to be from the post office can be effective. We also noticed the number of clicks decayed a few days after these short links were created. For example, there were 96,631 clicks (67.06%) on the first day after short links were created, and there were 30,749 clicks (21.33%) on the second day after short links were created. These clicks come primarily from two countries: Denmark (88.66%) and Austria (5.30%). A handful of other countries might be impacted as well, including Germany, Luxembourg, Spain, Sweden, Norway, United Kingdom, Netherlands, Italy, Greece, and Turkey.

C2 Server

All of the malicious apps we analyzed contacted a hard-coded C2 server for sending device relevant information and getting back instructions. The URL used is in the form of https://$C2.$SERVER.$IP/?action=command. In total, we found 12 C2 servers hosted in five different countries were involved in these campaigns. Table 3 shows relevant information for each C2 server used in these campaigns.

Table 3. C2 Server Relevant Information

In particular, IP address 85.93.5.109 has been used by 24 malicious apps in the PostDanmark and post-Austria campaigns. IP address 85.93.5.139 has been used by eight malicious apps in the PostDanmarkcampaign. Note that the first four C2 servers are within the same 85.93.5.0/24 network segment. In total, we found 38 malicious samples contacting these four C2 servers from March 2016 to June 2016.

Part of Something Bigger?

While monitoring the registration records for these self-registered domains, we found something interesting: in March 2016, a single email address (l[REDACTED]a@gmail.com) registered three domains, includingpostdanmark.org, postdanmark.menu and mmstildig.info, for two of the five campaigns. Using reverse lookup, we found another four similar domains were also registered by the same email address in March 2016. Table 4 shows the relevant information for these domains.

Table 4. Domains registered by the suspected threat actor (l[REDACTED]a@gmail.com)

The first three domains were used to host overlay malware for the MPay-Denmark and PostDanmark campaigns. We found no evidence that the latter four domains were used for similar campaigns, but the same registrant email address and the similar naming convention implies that they may have been created for a similar purpose.

Conclusion

Smishing (SMS phishing) offers a unique vector to infect mobile users. The latest Smishing campaigns spreading in Europe show that Smishing is still a popular means for threat actors to distribute their malware. In addition, threat actors have been using diversified host schemes and different C2 servers, and have been continuously refining their malicious code to keep infecting more users and evade detection.

Source:https://www.fireeye.com