Android Malware Analysis

---

Android malware analysis with Pithus (static and hunting)

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):

• Android Hacking101

• Mobile Malware Analysis

• Yara

If you're good to go, answer the next question, and we're good to go!

Answer the questions below

I am ready!

Completed

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:

Answer the questions below

What is the name of the technique used by Google Play to mark the applications uploaded to the Google Play Store?

Frosting

What is the name of the package?

com.wire

What is the MD5 hash of the APK?

e162504122c224d4609ade9efa9af82d

What is the SHA256 hash of this sample?

ae05bbd31820c566543addbb0ddc7b19b05be3c098d0f7aa658ab83d6f6cd5c8

What is the size of the sample?

unit without spaces; XX.XXYB

40.68MB

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.

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.

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.

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.

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.

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.

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.

Take some time to review the network page and the clues that we have gathered so far and move on to the next section: hunting!

Answer the questions below

Which version of the application is targeted?

3.65.979

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

org.xmlpush.v3.StartVersion

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

3

What is the first crime identified?

Load external class

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?

it has to do with how the user will find the app on the menu

Hide the current app's icon

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

5

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

Okio is a Java library that provides a set of APIs for working with various types of input and output streams, including byte streams, character streams, and file systems. The library is designed to be fast, efficient, and easy to use, and provides a number of features for working with data streams, such as buffering, compression, and encryption.

The Okio library is built on top of Java's InputStream and OutputStream classes, and provides a higher-level API for working with these types of streams. It also includes support for working with other data sources, such as files, sockets, and in-memory data structures.

Some of the key features of the Okio library include:

-   Efficient buffering of data streams, which can help improve performance when reading or writing large amounts of data
-   Support for various data encodings and compression formats, including UTF-8, UTF-16, GZIP, and ZLIB
-   Built-in support for encrypting and decrypting data streams using various encryption algorithms
-   A flexible API that allows developers to easily work with different types of data streams and file systems, regardless of the underlying platform or operating system

Overall, the Okio library is a powerful and versatile tool for working with data streams in Java, and is widely used in a variety of software applications and libraries.

okio/Okio.java

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.

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 Most Popular AV Detections. 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.

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.

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.

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.

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.

Answer the questions below

The "magic bytes" of a file refer to a specific sequence of bytes that appear at the beginning of the file and are used to identify the type of file. In the case of APK files, the magic bytes are the same as the local file header signature in the ZIP file format, which is "0x04034b50". By specifying this value in a Yara rule, the rule will only apply to files that have this specific value as the first four bytes of their content.

In other words, if you are writing a Yara rule to detect malware in APK files, you can use the magic bytes of the APK file as a filter to ensure that the rule only applies to APK files and not to other types of files. This can help to reduce false positives and improve the accuracy of the rule.

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

Completed

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

org.xmlpush.v3

Hunting 2

Let's look for the "search feature" that Pithus offers!

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

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*

Answer the questions below

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

ae05bbd31820c566543addbb0ddc7b19b05be3c098d0f7aa658ab83d6f6cd5c8

or

sha256:ae05bbd31820c566543addbb0ddc7b19b05be3c098d0f7aa658ab83d6f6cd5c8

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

Remember, you are looking for a class not a file. Hint 2: the one having a TCP connection.

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.

Answer the questions below

I'm done with this room!

Completed

https://azeria-labs.com/the-process-of-mastering-a-skill/

[[Intro To Pwntools]]