A Growing Number of Android Malware Families Believed to Have a Common
Origin: A Study Based on Binary Code
Introduction
On Feb. 19, IBM XForce researchers released an intelligence report
[ href="https://securityintelligence.com/android-malware-about-to-get-worse-gm-bot-source-code-leaked/">1]
stating that the source code for GM Bot was leaked to a crimeware
forum in December 2015. GM Bot is a sophisticated Android malware
family that emerged in the Russian-speaking cybercrime underground in
late 2014. IBM also claimed that several Android malware families
recently described in the security community were actually variants of
GM Bot, including Bankosy[ href="http://www.symantec.com/connect/blogs/androidbankosy-all-ears-voice-call-based-2fa">2],
MazarBot[3],
and the SlemBunk malware recently described by FireEye[ href="https://www.fireeye.com/blog/threat-research/2015/12/slembunk_an_evolvin.html">4,
5].
Security vendors may differ in their definition of a malware
“variant.” The term may refer to anything from almost identical code
with slight modifications, to code that has superficial similarities
(such as similar network traffic) yet is otherwise very different.
Using IBM’s reporting, we compared their GM Bot samples to SlemBunk.
Based on the disassembled code of these two families, we agree that
there are enough code similarities to indicate that GM Bot shares a
common origin with SlemBunk. Interestingly, our research led us to
identify an earlier malware family named SimpleLocker – the first
known file-encryption ransomware on Android [ href="http://www.welivesecurity.com/2014/06/04/simplocker/">6] –
that also shares a common origin with these banking trojan families.
GM Bot and SlemBunk
Our analysis showed that the four GM Bot samples referenced by IBM
researchers all share the same major components as SlemBunk. Figure 1
of our earlier report [ href="https://www.fireeye.com/blog/threat-research/2015/12/slembunk_an_evolvin.html">4]
is reproduced here, which shows the major components of SlemBunk and
its corresponding class names:
ServiceStarter: An Android receiver that will be
invoked once an app is launched or the device boots up. Its
functionality is to start the monitoring
service, MainService, in the background.
MainService: An Android service that runs in the
background and monitors all running processes on the device. It
prompts the user with an overlay view that resembles the legitimate
app when that app is launched. This monitoring service also
communicates with a remote host by sending the initial device data
and notifying of device status and app preferences.
MessageReceiver: An Android receiver that handles
incoming text messages. In addition to the functionality of
intercepting the authentication code from the bank, this component
also acts as the bot client for remote command and control
(C2).
MyDeviceAdminReceiver: A receiver that requests
administrator access to the Android device the first time the app is
launched. This makes the app more difficult to remove.
Customized UI views: Activity classes that present fake login
pages that mimic those of the real banking apps or social apps to
phish for banking or social account credentials.
Figure 1. Major components of SlemBunk malware family
The first three GM Bot samples have the same package name as our
SlemBunk sample. In addition, the GM Bot samples have five of the same
major components, including the same component names, as the SlemBunk
sample in Figure 1.
The fourth GM Bot sample has a different initial package name, but
unpacks the real payload at runtime. The unpacked payload has the same
major components as the SlemBunk sample, with a few minor changes on
the class names: MessageReceiver replaced with
buziabuzia, and MyDeviceAdminReceiver replaced with MDRA.
Figure 2. Code Structure Comparison between GM
Bot and SlemBunk
Figure 2 shows the code structure similarity between one GM Bot
sample and one SlemBunk sample (SHA256
9425fca578661392f3b12e1f1d83b8307bfb94340ae797c2f121d365852a775e and
SHA256
e072a7a8d8e5a562342121408493937ecdedf6f357b1687e6da257f40d0c6b27 for
GM Bot and SlemBunk, respectively). From this figure, we can see that
the five major components we discussed in our previous post [ href="https://www.fireeye.com/blog/threat-research/2015/12/slembunk_an_evolvin.html">4]
are also present in GM Bot sample. Other common classes include:
Main, the launching activity of both samples.
MyApplication, the application class that starts before
any other activities of both samples.
SDCardServiceStarter, another receiver that monitors
the status of MainService and restarts it when it dies.
Among all the above components and classes, MainService is
the most critical one. It is started by class Main at the
launching time, keeps working in the background to monitor the top
running process, and overlays a phishing view when a victim app (e.g.,
some mobile banking app) is recognized. To keep MainService
running continuously, malware authors added two receivers –
ServiceStarter and SDCardServiceStarter – to check its
status when particular system events are received. Both GM Bot and
SlemBunk samples share the same architecture. Figure 3 shows the major
code of class SDCardServiceStarter to demonstrate how GM Bot
and SlemBunk use the same mechanism to keep MainService running.
Figure 3. Method onReceive of
SDCardServiceStarter for GM Bot and SlemBunk
From this figure, we can see that GM Bot and SlemBunk use almost
identical code to keep MainService running. Note that both
samples check the country in system locale and avoid starting
MainService when they find the country is Russia. The only
difference is that GM Bot applies renaming obfuscation to some
classes, methods and fields. For example, static variable
“MainService;->a” in GM Bot has the same role as static variable
“MainService;->isRunning” in SlemBunk. Malware authors commonly use
this trick to make their code harder to understand. However this won’t
change the fact that the underlying codes share the same origin.
Figure 4 shows the core code of class MainService to
demonstrate that GM Bot and SlemBunk actually have the same logic for
main service. In Android, when a service is started its
onCreate method will be called. In method onCreate of
both samples, a static variable is first set to true. In GM Bot, this
variable is named “a”, while in SlemBunk it is named “isRunning”. Then
both will move forward to read an app particular preference. Note that
the preferences in both samples have the same name: “AppPrefs”. The
last tasks of these two main services are also the same. Specifically,
in order to check whether any victim apps are running, a runnable
thread is scheduled. If a victim app is running, a phishing view is
overlaid on top of that of the victim app. The only difference here is
also on the naming of the runnable thread. Class “d” in GM Bot and
class “MainService$2” in SlemBunk are employed respectively to conduct
the same credential phishing task.
Figure 4. Class MainService for GM Bot
and SlemBunk
In summary, our investigation into the binary code similarities
supports IBM’s assertion that GM Bot and SlemBunk share the same origin.
SimpleLocker and SlemBunk
IBM noted that GM Bot emerged in late 2014 in the Russian-speaking
cybercrime underground. In our research, we noticed that an earlier
piece of Android malware named SimpleLocker also has a code structure
similar to SlemBunk and GM Bot. However, SimpleLocker has a different
financial incentive: to demand a ransom from the victim. After landing
on an Android device, SimpleLocker scans the device for certain file
types, encrypts them, and then demands a ransom from the user in order
to decrypt the files. Before SimpleLocker’s emergence, there were
other types of Android ransomware that would lock the screen; however,
SimpleLocker is believed to be the first file-encryption ransomware on Android.
The earliest report on SimpleLocker we identified was published by
ESET in June 2014 [ href="http://www.welivesecurity.com/2014/06/04/simplocker/">6].
However, we found an earlier sample in our malware database from May
2014 (SHA256
edff7bb1d351eafbe2b4af1242d11faf7262b87dfc619e977d2af482453b16cb). The
compile date of this app was May 20, 2014. We compared this
SimpleLocker sample to one of our SlemBunk samples (SHA256
f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96)
using the same methods used to compare GM Bot and SlemBunk.
Figure 5 shows the code structure comparison between these two
samples. Note that this SimpleLocker variant also has the major
components ServiceStarter and MainService, both used by
SlemBunk. However, the purpose of the main service here is not to
monitor running apps and provide phishing UIs to steal banking
credentials. Instead, SimpleLocker’s main service component scans the
device for victim files and calls the file encryption class to encrypt
files and demand a ransom. The major differences in the SimpleLocker
code are shown in the red boxes: AesCrypt and FileEncryptor. Other
common classes include:
Main, the launching activity of both samples.
SDCardServiceStarter, another receiver that monitors
the status of MainService and restarts it when it dies.
Tor and OnionKit, third-party libraries for
private communication.
TorSender, HttpSender and Utils,
supporting classes to provide code for CnC communication and for
collecting device information.
Figure 5. Code structure comparison between
SimpleLocker and SlemBunk samples
Finally, we located another SimpleLocker sample (SHA256
304efc1f0b5b8c6c711c03a13d5d8b90755cec00cac1218a7a4a22b091ffb30b) from
July 2014, about two months after the first SimpleLocker sample. This
new sample did not use Tor for private communications, but shared four
of the five major components as the SlemBunk sample (SHA256:
f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96).
Figure 6 shows the code structure comparison between these two samples.
Figure 6. Code structure comparison between
SimpleLocker and SlemBunk variants
As we can see in Figure 6, the new SimpleLocker sample used a
packaging mechanism similar to SlemBunk, putting HttpSender and
Utils into a sub-package named “utils”. It also added two other
major components that were originally only seen in SlemBunk:
MessageReceiver and MyDeviceAdminReceiver. In total,
this SimpleLocker variant shares four out of five major components
with SlemBunk.
Figure 7 shows the major code of MessageReceiver in the
previous samples to demonstrate that SimpleLocker and SlemBunk use
basically the same process and logic to communicate with the CnC
server. First, class MessageReceiver registers itself to handle
incoming short messages, whose arrival will trigger its method
onReceive. As seen from the figure, the main logics here are
basically the same for SimpleLocker and SlemBunk. They first read the
value of a particular key from app preferences. Note that the names
for the key and shared preference are the same for these two different
malware families: key is named “CHECKING_NUMBER_DONE” and preference
named “AppPrefs”. The following steps call method
retrieveMessage to retrieve the short messages, and then
forward the control flow to class SmsProcessor. The only
difference here is that SimpleLocker adds one extra method named
processControlCommand to forward control flow.
Class SmsProcessor defines the CnC commands supported by the
malware families. Looking into class SmsProcessor, we
identified more evidence that SimpleLocker and SlemBunk are of the
same origin. First, the CnC commands supported by SimpleLocker are
actually a subset of those supported by SlemBunk. In SimpleLocker, CnC
commands include "intercept_sms_start",
"intercept_sms_stop", "control_number" and
"send_sms", all of which are also present in SlemBunk
sample. What is more, in both SimpleLocker and SlemBunk there is a
common prefix “#” before the actual CnC command. This kind of
peculiarity is a good indicator that SimpleLocker and SlemBunk share a
common origin.
Figure 7. Class MessageReceiver for
SimpleLocker and SlemBunk variants
The task of class MyDeviceAdminReceiver is to request device
administrator privilege, which makes these malware families harder to
remove. SimpleLocker and SlemBunk are also highly similar in this
respect, supporting the same set of device admin relevant functionalities.
At this point, we can see that these variants of SimpleLocker and
SlemBunk share four out of five major components and share the same
supporting utilities. The only difference is in the final payload,
with SlemBunk phishing for banking credentials while SimpleLocker
encrypts certain files and demands ransom. This leads us to believe
that SimpleLocker came from the same original code base as SlemBunk.
Conclusion
Our analysis confirms that several Android malware families share a
common origin, and that the first known file-encrypting ransomware for
Android – SimpleLocker – is based on the same code as several banking
trojans. Additional research may identify other related malware families.
Individual developers in the cybercrime underground have been
proficient in writing and customizing malware. As we have shown,
malware with specific and varied purposes can be built on a large base
of shared code used for common functions such as gaining
administrative privileges, starting and restarting services, and CnC
communications. This is apparent simply from looking at known samples
related to GM Bot – from SimpleLocker that is used for encryption and
ransomware, to SlemBunk that is used as a banking Trojan and for
credential theft, to the full-featured MazarBot backdoor.
With the leak of the GM Bot source code, the number of customized
Android malware families based on this code will certainly increase.
Binary code-based study, one of FireEye Labs’ major research tools,
can help us better characterize and track malware families and their
relationships, even without direct access to the source code.
Fortunately, the similarities across these malware families make them
easier to identify, ensuring that FireEye customers are well protected.
References:
[1]. href="https://securityintelligence.com/android-malware-about-to-get-worse-gm-bot-source-code-leaked/">Android
Malware About to Get Worse: GM Bot Source Code Leaked
[2].
href="http://www.symantec.com/connect/blogs/androidbankosy-all-ears-voice-call-based-2fa">Android.Bankosy:
All ears on voice call-based 2FA
[3]. href="https://www.csis.dk/en/csis/news/4819/">MazarBOT: Top class
Android datastealer
[4]. href="https://www.fireeye.com/blog/threat-research/2015/12/slembunk_an_evolvin.html">SLEMBUNK:
AN EVOLVING ANDROID TROJAN FAMILY TARGETING USERS OF WORLDWIDE
BANKING APPS
[5]. href="https://www.fireeye.com/blog/threat-research/2016/01/slembunk-part-two.html">SLEMBUNK
PART II: PROLONGED ATTACK CHAIN AND BETTER-ORGANIZED
CAMPAIGN
[6]. href="http://www.welivesecurity.com/2014/06/04/simplocker/">ESET
Analyzes Simplocker – First Android File-Encrypting, TOR-enabled Ransomware
Source:
A Growing Number of Android Malware Families Believed to Have a Common
Origin: A Study Based on Binary Code
