Try Hack Me Android Malware Analysis
@ Animesh Roy | Sunday, Jan 23, 2022 | 9 minutes read | Update at Sunday, Jan 23, 2022

OverView

Android Malware Analysislogo
Android Malware Analysis [FREE ROOM]Android Malware Analysis

Task 01: Introduction

Hi all! In this room, we are going to investigate some Android malware and learn how to pivot from the information we have to build hunting rules and find similar samples. To do this room, it is recommended to have done the following rooms (especially if you’re a beginner):

Task 02: First steps

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

You can find some of those malware programs on the Play Store (although it’s rare – Google usually takes them down), or, more often, they are shared through other means such as SMS or 3rd party websites.

Because Google Play adds some information to 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.

Our case study for this room will be a trojanized application of the secure chat application Wire.

During the next steps, we are going to use Pithus, an open-source, online, static analysis APK tool. Pithus embeds a number of tools you might have seen in previous rooms, such as MoBSF, SSdeep, or APKiD.

You will work on the following sample: https://beta.pithus.org/report/ae05bbd31820c566543addbb0ddc7b19b05be3c098d0f7aa658ab83d6f6cd5c8.

Check the report page on Pithus and answer the following questions to check you have the correct sample:

2.1 Answer the questions below

TaskQuestionAns
1What is the name of the technique used by Google Play to mark the applications uploaded to the Google Play Store?frosting
2What is the name of the package?com.wire
3What is the MD5 hash of the APK?e162504122c224d4609ade9efa9af82d
4What is the SHA256 hash of this sample?ae05bbd31820c566543addbb0ddc7b19b05be3c098d0f7aa658ab83d6f6cd5c8
5What is the size of the sample?40.68MB


Task 03: Getting into the APK

First of all, we need to understand what kind of sample this one is. For this, let’s choose the APK Analysis tab.

img

Here you can see basic information regarding the sample. In our case, we are dealing with a specific trojanized application. This means that we need to identify which version of the application is targeted.

With some quick online research, we can find that this version was released on 1 March 2021.

In the Threat Intel tab, we have a timeline of events that could tell us about the time the malware was active or is supposed to be active.

img

As we can see, the X.509 certificate was created to work from 26 April 2021, and the oldest files from the samples were identified around that time. Two months after the release of the version of the legit APK.

In the APK Analysis tab, we can find the main activity for this application (if you need to refresh your memory on activities, check out the Android developer’s documentation. The main activity is an important point in your analysis. Indeed, when you look into the APK, you might want to start from there, so it’s important to identify it in the early stages of your work.

img

After having identified a potentially malicious activity, let’s browse the Manifest and look for actions that are triggered by this activity. You will find that information in the APK Analysis tab.

Now moving on to the Behavior Analysis tab, where we will gather some general information on how the APK is behaving. The first part of the tab looks into the permissions that the APK will be requesting. This is a good indicator to identify what kind of resources will be used.

img

This APK is requesting an extensive amount of permissions. This might not be entirely suspicious, depending on what this application is doing. In this case, the trojanized application is supposed to act as a chat application so requesting contacts or camera access are not surprising. Nonetheless, one must be wary of what kind of requests are made.

Later on, on the same page on Pithus, we scroll to the Threat Analysis section. The analysis there is based on a tool called Quark. With these tools, it is possible to identify a number of “crimes” (as they call them) to map the behaviour of Android malware.

img

For our sample, we have a number of crimes identified. Check the questions related to this theme before moving on.

Moving on to identify classes that have behaviors we would want to look at. Scroll down to the Behavior Analysis. Here we can see the name of the classes that have the identified behaviors, which will give us valuable pivot points when analyzing the APK.

img

Now we’ll check out how the Network Analysis tab. Here you will see a number of domains that have been identified and are queried by the APK. Here you will see a number of domains that have been identified and are queried by the APK. Considering that we work on a high-profile case here, it is less likely we’ll easily discover clues. Indeed more advanced malware will obfuscate the domain or IP it communicates to avoid detection.

img

3 Answer the questions below

3.1 Which version of the application is targeted?

ref : https://beta.pithus.org/report/ae05bbd31820c566543addbb0ddc7b19b05be3c098d0f7aa658ab83d6f6cd5c8

img

3.2 Check all the activities. There is one standing out. Which one is it?

img

3.3 How many activities in the Manifest analysis are linked to the activity that we have identified?

img

3.4 What is the first crime identified?

Load external class

img

3.5 There is a crime that should attract your attention. It is something that shouldn’t happen with a non-malicious chat app. What crime is it?

Hide the current app's icon

img

3.6 How many classes have a TCP connection and are identified as being part of our malicious activity?

5

img

3.7 Which one of the classes having a TCP connection is probably not malicous?

okio/Okio.java


Task 04: Hunting

Now that we have a general idea of the sample, let’s continue our research to see if we can find other samples that are identical or similar to the first sample.

Hunting for other samples is an important step in malware analysis. Now that we have a general idea of the sample, let’s continue our research to see if we can find other samples that are identical or similar to the first sample.

Finding new samples might start to give you an understanding of the type of victims being targeted and the Tactics, Techniques, and Procedures (TTPs) malicious actor/s are using.

Without further ado, let’s get into it! Pithus offers different tools to run hunts. Let’s check what we have based on the current sample.

Search by similarity

In the Fingerprints tab, scroll down to the SSdeep and Dexofuzzy results.

img

By clicking on the little magnifying glass, we can start to look for similar samples. At the time this room was created, there are no results from this search.

Search by identified names

In the Threat Intel tab, scroll down to Move Popular AV Detection. Sometimes, samples are quite unique, and they are not so easily detected. However, Anti-Virus companies might use their knowledge to identify specific patterns in samples. Thanks to this, we can look for samples for a specific name of malware or group.

img

Check the questions before moving on.

Based on the threat names, we could gain an idea of who the threat actor might be based on pre-existing research or the type of sample that we are analyzing. Take some time to research “Finspy” to get acquainted with this actor.

Search by Yara rules

For the moment, Yara searches are only available for registered users. If you have a Github account, you can use it to connect yourself to Pithus. After that, you will see “My Hunting” in the top bar.

img

In this section, you will be able to add your own Yara rules to look for other samples. Pithus allows you also to retroactively search for older samples. Pithus also allows you also to create private or public Yara rules. In the case of public rules, anyone using the platform will have access to any public rules.

img

img

Important: Pithus only supports vanilla Yara for the moment. If you try to use modules, it will not work.

You might have already noticed that our samples have Yara matches if you look into the Threat Intelligence section.

img

The rules used are public and can be found on this Github page.

Keep in mind when writing Yara rules for APKs, you can always specify the APK’s magic bytes: uint32(0) == 0x04034b50, so your rule will only look into APK files. This is not important when using Pithus but might be good to know if you use your rules on VirusTotal or other platforms.

4 Answer the questions below

4.1 In the section for search by identified names. Click on the magnifying glass icon to search for “finspy” samples.

N/A

4.2 What do you notice that will identify our sample as having similarities with the other search results?

org.xmlpush.v3

ref: https://beta.pithus.org/?q=threat_name:*finspy*


Task 05: Hunting 2

Let’s look for the “search feature” that Pithus offers!

On the home page of Pithus, there is a query field available.

img

Clicking the ? icon brings up more information for some features described below.

Here are some tricks:

  • You can list all samples available in Pithus with this search: * (Note that not all samples will be shown at once.)
  • You can combine searches and look for all files that have a rating on VirusTotal with: * and vt > 0
  • Sometimes, searches will yield a low amount of results. You can expand the search with * — For example: threat_name:*finspy*

5 Answer the questions below

5.1 Find the sha256 hash of our previous sample and run a query using the hash. What is the query you used?

sha256:ae05bbd31820c566543addbb0ddc7b19b05be3c098d0f7aa658ab83d6f6cd5c8

5.2 What query would you use to find the non malicious class that we identified previously?

java_classes:okio/okio


Conclusion

Now let’s recap what we’ve explored in this room

Firstly, we worked on a trojanized application of Wire that is linked to the threat actor Finspy. At the time this room was created, little public information is available as to where this trojanized application has been used and how many victims have been affected. Nonetheless, we’ve gathered preliminary knowledge of the application’s behavior that could speed up a future in-depth code analysis. We have identified network communication classes that could serve as useful pivot points should you continue analyzing this sample on your own.

Then, we looked into how to find similar APKs based on our analysis and what was fingerprinted from the sample. As we were able to see, it was possible to gather other implants uploaded on Pithus that matched our first APK. Gathering other samples is an important step in your analysis. With more samples, we might be able to better understand the techniques, tactics and procedures of the group and/or the malware. This might answer questions as “Why was that application trojanized?” or “Who are the victims of this malware?”.

Finally, we played with some search features of Pithus, which will allow you to look for more samples based on atomic indicators of compromises.

It’s time for our journey to come to an end. We hope that you enjoyed this walk-through and remember that Pithus is an open-source tool.


© 2010 - 2024 Classroom

Reading Stuffs

Social Links

YOU CAN REUSE MY CONTENT