“The wings moved so rapidly that they were scarcely visible and remaining stationary the little bird darted its beak into the wild flowers making an extraordinary buzzing noise with its wings. Those I have met frequent shaded forests and may there be seen chasing away the rival butterfly.”
Charles Darwin – June 1832, Botafogo Bay, Brazil.
There’s a whole lot of buzz right now about HummingBad., and for really good reasons. In February of 2016, Check Point mobile threat researchers discovered and named HummingBad. By March, this Android based malware was found to be the sixth most common type of malware attack worldwide. Just 4 months later, upwards of 85 Million Android devices are suspected to be infected by a growing number of variants.
HummingBad, like many other examples of mobile malware, spread prolifically in the wild before being identified and named. The taxonomy took long enough that the malware got an impressive head start. Because of how it operates, that edge was more than enough for it to spread widely during that time period. This is sophisticated mobile malware. It establishes a persistent root on the Android device, installs additional fraudulent applications, engages in activities that generate false ad revenues, and can include the installation of a key-logger used to steal user credentials and the ability to bypass encrypted email containers used by enterprises. And there’s more great news. It includes command and control capability which would allow botnet capabilities using infected phones. Mobile malware has grown up.
Being the curious sort, I flew on over to Contagio Mobile where malware researcher and blogger Mila Parkour hosts a collection of mobile malware samples, threats, observations, and analyses. I was looking for a sample to pull apart and poke through. Imagine my surprise to find 590 specimens, collected since July 2nd. Nice job Mila! This HummingBad is no rare bird.
Dissecting HummingBad (or any Android Malware)
There are a lot of great overviews out there about what HummingBad does. Checkpoint has done a great job of breaking down the code, enumerating its activities, and identifying the cyber crime gang, “Yingmob,” behind it. But how do they figure all that great stuff out?
I thought that it might be useful for those who don’t do malware analysis to learn a little about how to find out what Android malware is doing. Malware analysis is a whole sub-field of forensics and network security. There are lots of folks whose job it is to dissect malware every day. Folks like Lenny Zeltser, Malware Jake, Anuj Soni and Josh Wright. Their expertise is impressive. This work involves a great deal of deciphering and reverse engineering of code written by someone else. I’ve learned a lot from these guys because there’s a lot of malware out there, and sometimes you just need to look at things for yourself.
Malware Analysis Basics
There are two basic methods of malware analysis, Static Malware Analysis and Dynamic Malware Analysis.
The goal of Static Analysis is to analyze the behavior of malware to see how it interacts with the digital environment it lives in. This is taking a look at the malware without running the actual code. For Android devices, static analysis includes identifying what permissions the app leverages, what sites it contacts, its file name, hashes values, file type, file size and recognition by antivirus detection tools. We look at those indicators and behaviors to determine whether or not the code is acting maliciously and what it’s trying to achieve for the coder. We can accomplish a lot without actually running the software. For additional general information about mobile malware, check out the presentation I did for the NIST Mobile Forensics Workshop.
Bird Anatomy diagram from nusavifauna.wordpress.com/bird-morphology-underparts/
Dynamic Analysis looks directly at the programming source code using decompilers and debuggers to convert the code to its binary or assembly form. It also includes actually running the software in a virtualized environment in order to monitor and document its behavior. From this type of analysis, we learn how the app is built and how it works. This is a controlled field study in our virtual machine.
A combination of these two techniques gives us a more full picture of the malware’s actions. Part lab dissection, part field study.
HummingBad in the Sandbox
Malware sandboxes can often perform both a static and dynamic analysis of code for us. They’re quick, easy to use, generally free, and easily available. There are online sandboxes and sandboxes such as cuckoo that are designed to be used in controlled environments. Most sandbox sites will recognize mobile apps and perform analysis for us on those files. There are sites specific to mobile malware as well.
I submitted two samples of HummingBad .apk files (Android application files) to VirusTotal, and both were quickly identified as likely malicious.
VirusTotal’s Angel vs. Devil scale makes detecting evil seem easy.
VirusTotal allows you to view a good deal of information about the files within just a few minutes, based upon static and dynamic analysis of the files. The screenshot below shows the app’s required permissions, and we can see quickly that HummingBad is very invasive.
Screenshot of required permissions for HummingBad Sample as identified by VirusTotal.
A look at the application certificate information shows that the certificate was issued in China. In fact, the certificate information for both samples of HummingBad I looked at were identical. Interesting strings can be reviewed to quickly identify IP addresses and ad sites the malware reaches out to.
VirusTotal shows the Application Certificate and interesting strings, along with other useful information about the HummingBad sample.
This is quick and easy malware analysis. Upload the file and it is processed automatically at the other end. Remember though, anyone can use this sort of site. Uploading a file sample could tip off the malware developer that their software has been identified and classified as bad. Also, you don’t always know who is running the sandbox or who you are submitting samples to.
Manual Android Malware Analysis
We can also perform manual analysis of mobile malware samples in a controlled environment. When working with malware virtual machines, emulated phones allow us to launch malicious code with less chance of bad consequences. Full VM environments like Santoku exist that contain the tool sets you need to do this work – for free! There’s no cost to start experimenting and learning, and there’s a whole lot of knowledge to be gained. There are also a variety of less expansive (and also free) tools that we can use for manual analysis. One fairly easy combination of tools that works really well is dex2jar and jd-gui.
When an application file is created, a program (in this case malware) for Android is compiled, and then all of its parts are packaged into one .apk file. This .apk file contains all of the programming code (.dex files), resources, assets, certificates, and the manifest file. Simply unzip the .apk package file to view its contents.
HummingBad sample unzipped.
Using dex2jar, we can then convert the classes.dex file to .jar format and open the resulting .jar file using jd-gui. Jd-gui allows us to browse through the application’s programming classes.
Virtualizing Mobile Malware
We can do some additional interesting research by virtualizing the Android mobile malware that we’re working with (or any app for that matter). We can install either the full Android Studio bundle, or just the SDK if you want to simplify things. Cheeky4N6monkey wrote a nice walk through of installing virtualized apps on his blog.
We can then create and launch one or more Android phone emulators and install the specific app or apps we want to study. Using Android Device Monitor within Android Studio, Wireshark or another method, the activity of the app as it runs on the virtualized is logged.
HummingBad sample viewed in SDK Studio
Virtual Galaxy Nexus
I opened my captive HummingBad app specimens in Android Studio, which provides a nice interface for viewing the app’s code. Then I created a virtualized Nexus One (API 23) device and ran the malware in the emulated phone.
It is really great fun, running an app on a virtual phone in a virtual machine on a host. And if just for that reason, even if you don’t have another, you should try it.
All Together Now
The combination of static and dynamic malware analysis combined with virtualization and monitoring of suspect apps can provide a great deal of information about what the app is doing. These clues act as pivot points for research into how the malware is being used as well as how it might be used in the future.
This is a basic overview of a few useful tools and methods for Android Malware analysis. There is a whole lot more to this topic. Mobile Malware is growing in sophistication as well as the ways it is used by cyber criminals. It can affect anyone. In a Bring Your Own Device world, having the resources and knowledge to gain a deeper understanding of mobile malware is extremely important.