Beginner guide - How to handle a potentially malicious mobile app

On a daily basis, we encounter potentially malicious applications in various forms. They can appear as seemingly harmless apps we intend to download from Google Play (although it’s rare – Google usually takes them down), or they may be disguised as links or APK files shared within chat groups, especially if we are human rights defenders operating in a high-surveillance environment. Additionally, these malicious applications can be found on compromised devices.

In this guide, we will explore how to deal with applications, primarily focusing on Android applications, that raise suspicion of being potentially malicious.

Some Android malware masquerade as a normal application. Those files are called APKs (Android Application Package), and the very large majority of your Android applications are APKs.

Note

Because Google Play adds some information to most of the APKs when they are uploaded to the Play Store, it is possible to check for applications that come from it. This modification is called frosting. When you find an APK that is not frosted, you’d need to be extra careful with it. There are chances it is malicious.

In the next steps we will analyze a sample of a potentially malicious app and look for different indicators that can help us recognize a malicious app.

Get the sample to be analyzed

First of all you need to get the sample for checking it. Malicious applications are commonly delivered through different types of channel:

  • a link in a phishing email
  • a link on chat groups
  • a link on shady website
  • on Google Play Store
  • on alternative application stores

In some cases, the sample will have to be retrieved from a potentially compromised device. To do so, you can use MVT to download the APK file from an Android phone.

If the application you want to analyze is available on Google Play Store, you can use apkeep to download it. Apkeep can be downloaded from GitHub.

For this guide we will use an example sample that has been investigated before (fake Wire app) and available on Pithus. You can open and review the sample here.

To download the sample, follow this link. You will get a ZIP archive protected by a password containing the sample APK. The password is infected.

Compute the sample hash

After getting the sample you’ll need to securely store it, compute its SHA256 hash and only work on copies of the original file. This hash uniquely identify the sample file based on its content. The SHA256 of two slightly different files will be totally different. SHA256 does not tell anything about how different the 2 files are. SHA256 (and other hashing functions) can be applied on any type of file.

It is advised to only work on copies of the original file and refrain from modifying it directly. A mobile application is essentially a zip archive that can be opened and unzipped. To initiate the reverse engineering process, you will need to open and modify a sample of the application. However, it is essential to ensure that you are working solely with copies of the original file. To accomplish this, store the original file, which you have received, in a designated folder on your computer. Alongside the file, store basic information about it, such as its SHA256 hash and package name. When you wish to perform in-depth analysis, create a duplicate of the file and commence working on this copy. Always remember to refrain from modifying the original file directly to preserve its integrity.

Get the sample hash from Pithus

If you open the Pithus report, you see in the Fingerprints workspace a section File sums specifying 3 different types of hash (MD5, SHA1 and SHA256).

SHA256 in Pithus
SHA256 in Pithus

Compute the sample hash locally

You can compute the SHA256 of the sample directly on your computer with the following command line, replace <my.apk> by the path to the sample file:

The SHA256 of the sample we use in this guide is: ae05bbd31820c566543addbb0ddc7b19b05be3c098d0f7aa658ab83d6f6cd5c8

Note

When conducting reverse engineering on a mobile application, it is crucial to maintain the integrity of the original file. Always mention the sample hash (SHA256) in your report.

Identify the type of sample

APK or XAPK for Android: a file with the .apk file extension is an Android Package file that’s used to distribute applications on Google’s Android operating system. APK files are saved in the ZIP format and are typically downloaded directly to Android devices, usually via the Google Play Store, but can also be found on other websites.

IPA for iOS: a file with the .ipa file extension is an iPhone application archive file which stores an iPhone app. It is usually encrypted with Apple’s FairPlay DRM technology. Each .ipa file is compressed with a binary for the ARM architecture and can only be installed on an iPhone, iPod Touch, or iPad.

Note

Depending on your internal guidelines, you would have to digitally sign the sample with your PGP key for example.

Retrieve basic information

Use tools to extract information that will help you identify the binary and its potential origin and behavior such as:

Jadx: is a software you can install on your computer to decompile Android application producing Java source code from Android Dex and APK files.

Androguard: is a software you can install on your computer to do reverse engineering and pentesting for Android applications.

Pithus: is an free and open-source online service that statically analyze Android applications.

VirusTotal: is an online service that analyzes suspicious files and URLs to detect types of malware and malicious content using antivirus engines and website scanners.

Note

Depending on your internal guidelines, and depending on the confidentiality of the case you’re investigating, it would be not allowed to share the sample (or even the sample hash) with third-party services like VirusTotal.

For this guide we will use two main tools to retrieve basic information for the example sample, Pithus and Jadx for exercising both options of analysis with online third party service and static offline analysis.

With Pithus (online)

Application and package names

The application name is the name that will be displayed under the application icon on your phone. The package name is the technical name (identifier) of this application, the information that Android will be using to uniquely identify the application.

Get both application and package names from Pithus
Get both application and package names from Pithus

Signing certificate information

The certificate plays a crucial role in distinguishing between the original application and potentially suspicious ones. Once you have obtained the application name and package name (as mentioned in the previous section), you can search for it on the Google Play Store and compare the signing certificate fingerprints. It’s important to remember that the digital signature of Android applications cannot be faked. Two applications can have the same name, the same package name and have been signed with two different certificates.

Signing certificate of the malicious sample
Signing certificate of the malicious sample
Signing certificate of the genuine Wire application
Signing certificate of the genuine Wire application

Google Play frosting information

To check if the sample was frosted by Google Play Store (Android only), refers to the Frosting information in the Pithus report.

Frosting flag of the malicious sample
Frosting flag of the malicious sample
Frosting flag of the genuine Wire application
Frosting flag of the genuine Wire application

Requested permissions

Permissions can serve as an important indicator to determine whether an application is malicious or not. By reviewing the permissions requested, we can evaluate if they align with the legitimate purpose and functionality of the application. Take the example of the fake Wire application, which requests excessive permissions unrelated to its intended use as a communication application. This discrepancy raises suspicions about the application’s integrity. If our assessment (and gut feeling) says that these are not legitimate permissions and there’s something shady with them, then it’s worth investigating.

Requested permissions by the malicious sample
Requested permissions by the malicious sample

With jadx (offline)

First, you have to install jadx on your computer.To do so, follow the documentation available on GitHub. If you are using Windows, we suggest to download the file named jadx-gui-[version]-with-jre-win.zip from the releases page, decompress the downloaded ZIP archive and double-click on the .bat file to launch jadx.

Jadx main view
Jadx main view

Once launched, select and open your sample file. After a few seconds or minutes depending on the size of the APK, jadx will display the content of the Android application as a tree on the left part of the screen.

Our sample opened with jadx
Our sample opened with jadx

Application and package names

To get both application name and package name, double-click open the AndroidManifest.xml file listed in the tree. It will open it and show you its content in a human-readable way. To get the package name, look at the field package in the AndroidManifest.xml file.

Package name in jadx
Package name in jadx

To get the application name, look at the field android:label of the element application in the AndroidManifest.xml file.

Application name in jadx
Application name in jadx

Signing certificate information

To get the signing certificate information, double-click on APK signature listed at the bottom of the tree and look at the entry SHA-256 Fingerprint.

Signing certificate information in jadx
Signing certificate information in jadx

Requested permissions

To get the list of requested permissions, open the AndroidManifest.xml file and look at uses-permissions elements in it.

Requested permissions in jadx
Requested permissions in jadx

The same thing we did with Pithus, here we can also review the permissions and assess if these are legitimate permissions for the app’s purpose. If our assessment (and gut feeling) says that these are not legitimate permissions and there’s something shady with them, then it’s worth investigating.

Check if the sample is malicious

If you have an anti-virus software installed on your computer (Windows comes with Windows Defender by default), you can use it analyze the sample and know if it is detected as malicious. If you have Windows Defender, right-click on the sample file and choose “Scan with Windows Defender”, please refer the your anti-virus documentation otherwise.

If permitted by your internal guidelines, you can search for the SHA256 of the sample on multiple online services such as VirusTotal. To search for our sample on VirusTotal, click on “Search” and paste the SHA256 of the sample.

Search for a SHA256 on VirusTotal
Search for a SHA256 on VirusTotal
VirusTotal report for our sample
VirusTotal report for our sample

Reminder

If your sample is not detected as malicious does not mean that it is not malicious - it can be a false-negative. It only means that no already known threat or malware has been detected. In some cases, non-malicious samples are detected as malicious even if they are not - false-positives exist too!

Static and dynamic analysis

What we just did with jadx was basic static analysis. This form of analysis is locally conducted analysis of source code without executing the application and without sharing information with third-party services like Pithus and VirusTotal. Static analysis is helpful mainly when we’re not allowed to share the sample or any information around it with external services, and when it’s risky to execute the application on our devices.

Static analysis is conducted with various tools to decompile the binary, such as jadx (the tool we used), and other tools like radare2, rizin, and jeb. You can also use tools such as droidlysis to conduct automatic offline static analysis.

In contrast, dynamic analysis involves executing the application on a device (virtual or real). That means the binary code will run on the device, and this carries the risk of infecting the device with potential malware from the app we want to analyze. This analysis can disclose your location, your organization, and other identifiable information about you and your work. Therefore, it is preferable to work offline if possible to minimize the exfiltrated information.

If the case you are working on is not too sensitive and if your internal guidelines allow it, you can upload your sample on VirusTotal to get basic static and dynamic analyses.

Static and dynamic analysis are vital for investigating potentially malicious apps; however, they can be tricky, frustrating, and, in some cases, risky for beginner readers to conduct. So, if you have conducted static analysis and feel that a deeper investigation needs to be done, or if you want to conduct dynamic analysis but feel under-skilled and inexperienced for it, you can always ask for help and consult experts in analyzing and investigating potentially malicious apps. This will ensure thorough and trusted results.

Going further

To go further, check out our other guide How to statically analyze a potentially malicious Android app.

To learn more about Pithus, you can train yourself on TryHackMe.

You can also learn from: