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.
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 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
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.
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.
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.
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.
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 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
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.
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.
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.
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.
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.
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.
Table 3. C2 Server Relevant Information
In particular, IP address 220.127.116.11 has been used by 24 malicious apps in the PostDanmark and post-Austria campaigns. IP address 18.104.22.168 has been used by eight malicious apps in the PostDanmark campaign. Note that the first four C2 servers are within the same 22.214.171.124/24 network segment. In total, we found 38 malicious samples contacting these four C2 servers from March 2016 to June 2016.
While monitoring the registration records for these self-registered domains, we found something interesting: in March 2016, a single email address (l[REDACTED]email@example.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.
Table 4. Domains registered by the suspected threat actor (l[REDACTED]firstname.lastname@example.org)
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.
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.