Introduction

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 in Denmark (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 same technique 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.

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 because obfuscation 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.

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, named initInjTask 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.

(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.

(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.

(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.

(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.

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.

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 class SmsWriteOpUtil (at line 93) to 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.

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.

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

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 http://$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.

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 PostDanmark campaign. 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, including postdanmark.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.

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.

To protect against these threats, FireEye suggests that users not install apps from outside official app stores, and take caution before clicking any links where the origin is unclear.

To detect and defend against such attacks, we advise our customers to deploy our mobile security solution, FireEye MTP/MSM. This helps our clients gain visibility into threats in their user base, and also enables them to proactively hunt down devices that have been compromised. In addition, we advise our customers with NX appliances to ensure that Wi-Fi traffic is scanned by NX appliances to extend coverage to include mobile devices.

Appendix: Samples

df53b59e354462cd0e704b7b21a750f7
6eb92667ebbbcb2c7ddf6230462222fd
3841abcef2b1b37aa7e2d47c535ca80e
265d37013e1ea39b868515cce157dfeb
49dac3b35afb2e8d3605c72d0d83f631
ffe98d97e7d827aa19abb968a528f3fe
f4b8d64af0a53472901b50621f19d6bf
e1d79608b649c22004ad7cc1cd049528
ef5c9b15755719597481c501f6b603ce
6a300ded487671ef39388b8d28927a83
d33b718737de5aa685672a2004e0fa3c
d83d833092a4fa5ecc436d4246c2f7ce
97c2d04aa0f3c3b446fc228c1dbc4837
82b1006a5f45a6d2baf69544414ada81
9e9d9a3717eed4d558a3f5eddb260901
82d89319fabd998328cc6d4efc4db863
228a4b723bf3d8adc53a69dd0f36c746
e911df33f1d156b3309a4ac220c52070
2b90fca41272bec8b8ffefbb2456c001
40449a2ec48c3e630b2eb8c8089828cf
8d0a03981daa93210e184e7fff02883c
fbdde37d41d12f21c049c570c9bda3de
a18818cb3fb6f189560991cef6d1f929
bf7b72dbb2a9155dabc4eda31d273b92
9762441d52bdec725eff6f2f65e721e9
dba6b4bbf61e054fb978acaf70c3d849
93922ee5fbd149f31b0161deca76df77
035d1f3b7fb532a33de7a8445f9fa325
3f2017a5acb3e57801e2771341287001
06e74df867e9cb5c1bafc98165c6c248
20f4cd2baa09e0bd5e12dab50c0898cd
af7a8d32865e8caf51a99c52834d4422
82d89319fabd998328cc6d4efc4db863
bee3746684b072867a5b202bfc5527dd
a18818cb3fb6f189560991cef6d1f929
8959513f65bcca6f16faef59ad2d152f
cfa92cbcb0674429cc9ce216cc008902
d73d54f6f86c58030477cc9a96eedb85
2f4d81ef1b10bf72d0dba0fdf354527f
701d57504444344b8d5e79bcabcd3dca
fcb4ef63f1d8a3a044ac6f8a7c262546
05131969af2ae6cbfddf789512f02aa2
6e93a7f7911b3e9b522be4b8f950cca4
542f8f77e101d4e8e5d1ef34a3f0df1c
d0a6ba40e05047dc2cff12935c4cf4fb
23988abad7c7b2ecdda23ae7194b7a0d
2c055d7b5199604cd5cf3441073b36b3
a72aa534973eeaf0782a246d502107a3
f1c8a3337cbd56e01e478774f5d55278
da222d4b7993a62665b9eaef10c1846f
152f626eb92676f940ada4b7077acf16
7a99b60349703aed3ab28f498320f247
1b9e1cd2c7f8e227b2ae5fb5bc735536
d84ff5a7e7c0c33dcfa237299869bc34
d70296d3dc4937dedd44f93bb3b74034
88b23b6a5c1b72aeff2fc42e05c173a7
036258e2c51e21c140b5838ce9bfb4f8