Investigating Android malware with Pithus

5 min readJul 13, 2021

Pithus is a web front-end for several other tools: APKiD, MobSF, Quark, Androguard etc. I decided to try it against a random recent malware, and see how useful it could be to me. I selected a sample of the day (July 13, 2021) on VirusTotal. Note that, initially, I had no idea what this malware is. Actually, it turned out to be from the same family of another sample I analyzed one year ago, but I didn’t know that when I picked it up.

sha256:6af959da4e5188801ecc41f14372c30501f157e51f6decb72919bd41e3105fc8

What I found out (only using Pithus)

Dexofuzzy finds 2 other similar samples. As it is quite rare to find similar samples, so I guess this sample is from a well-known malicious family. Actually, the feeling is confirmed if you click on “APK Analysis > APK details > Package > Find similar samples”

“My” sample is the first one, at the top. A similar sample is “Aarogya Setu”. Most probably, my malicious sample is an Android/SpyNote.

From control flow analysis, I see class C10 of the malware reads SMS on the smartphone.

Quite typical: C10 is a receiver. It probably receives SMS_RECEIVED intents. Then, it reads the SMS (createFromPdu) and also retrieves the sender’s phone number (getDisplayOriginatingAddress).

It lists installed applications. I guess it will leak the list, but from Pithus only, it is difficult to know. [solution: yes, it sends it to the remote server]
It takes a screenshot. Actually, with the control flow, we see the malware executes a command. But which command? We are lucky, the command is shown in C7

Screen capture will be stored in /sdcard/rootSU.png.

It records audio, probably listening to our conversation / surroundings. [solution: yes, sent to remote server]

It abuses Accessibility Services. From Pithus alone, I don’t exactly know what it is doing, but for sure, it is located in C1. I’ll have to look into that class. [solution: yes, it logs keystrokes]

Wish list

In “Fingerprints > APKiD”, tell me which part of the code implements those Anti VM features APKiD detects.

Actually, in this case, APKiD is wrong. This is not for Anti VM, but the information is being leaked by the malware

In “Threat Intel > Virus Total”, I’d like an intelligent computation of names anti-virus engines use for this sample. Something like “5 AV detect this as ~SpyNote, 1 as DebugKey” (make sure to remove dummy names like Agent).
In “APK Analysis > Receivers”, tell me which intent/actions/filters apply to the receiver. For instance, I would have known when C10 reads SMS.

Android manifest shows the intent for receiver C10.

Also, in “APK Analysis”, tell me who is the main activity! I can’t believe it’s not there! Every tool knows that (androguard, JEB, MobSF, Quark, DroidLysis…)! This gives the analyst a chance to locate malicious code.

The main activity is C7. In this particular case, the malware is simple and contains only malicious code, so C7 is malicious.

In Control Flow Analysis, I’d like link to code to show me source code that I can parse, not images. Also I’d like key lines to be highlighted. MobSF does that.
There are many features which are useless for malware analysis. For example, for a malware, we don’t care about “Broadcast Receiver (com.android.tester.C10) is not Protected” ! Same for “The application use no DRBG functionality for its cryptographic operations”. Perhaps create a “Malware analysis” mode vs a “App security” mode?
In “Behaviour analysis > Permission analysis”, telling me which part of the code is using this or that feature would be much more interesting than telling me android.permission.CAMERA allows the app to take pictures 😏
Some malicious behaviour were not detected and are missing. For example, the sample reads smartphone contacts, reads the call log, retrieves email addresses, sets the ring mode, vibrates, gets battery info, GZips leaked data, uses device administrator mode…

DroidLysis detects several other suspicious behaviours!

In “Behaviour analysis > Threat analysis”, tell me where in the code Quark locates the behaviour.

Option -d in Quark lets me know C3 implements code to hide the app’s icon.

For similarities, it’s nice to know which samples are similar, but we don’t know what’s similar with them. For that, I suggest use of the new radar chart in Quark which compares malware per labels (kudos to @ciastron !).

quark -C options creates a clickable radar chart. In this case, all 3 samples overlap exactly, which is why you only see the top color (green) here. You can disable the sample by clicking on its label and inspect underneath.

Very important: this did not show on this easy sample, but rule out code from 3rd party SDKs (e.g. android.support, okhttp, crashlytics …) because it generates tons of False Positives (alarms on code which is not strictly speaking malicious). When will tools (Quark, MobSF, …) start integrating this (modestly) great feature of DroidLysis?

DroidLysis detects the sample uses android/support/v7. Actually, this is nearly in every app, so it is *really* useful to rule this out from behaviour alarms!

Detect when a sample is packed. Even better, unpack automatically and analyze the payload. That would be awesome.
In this particular case, Pithus (or its underlying tools) completely missed network communication (Network analysis tab is empty). This is probably a bug? In reality, the sample opens a socket towards pendia.duckdns.org on port 64890. The messages are gzipped.

References:

— Cryptax

Investigating Android malware with Pithus

What I found out (only using Pithus)

Wish list

References:

Written by @cryptax