The Latest Android Overlay Malware Spreading via SMS Phishing in Europe[html]
Introduction
In April 2016, while investigating a Smishing campaign dubbed href="https://www.fireeye.com/blog/threat-research/2016/04/rumms-android-malware.html">RuMMS
that involved the targeting of Android users in Russia, we also
noticed three similar Smishing campaigns reportedly spreading in href="http://b0n1.blogspot.com/2016/02/recent-mazarbot-targeting-mobilepay-can.html">Denmark
(February 2016), in href="http://b0n1.blogspot.com/2016/02/android-mazarbot-stealing-credit-card.html">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 href="https://www.fireeye.com/blog/threat-research/2015/12/slembunk_an_evolvin.html">technique
we described being used by href="https://www.fireeye.com/blog/threat-research/2016/01/slembunk-part-two.html">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 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.
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, 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 href="http://mobilepay.dk/da-dk/Pages/The-story-in-English.aspx">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 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
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.
