Investigating Android malware with Pithus
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.
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”
- From control flow analysis, I see class
C10of the malware reads SMS on the smartphone.
- 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
- 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]
- In “Fingerprints > APKiD”, tell me which part of the code implements those Anti VM features APKiD detects.
- 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
- 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.
- 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.CAMERAallows 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…
- In “Behaviour analysis > Threat analysis”, tell me where in the code Quark locates the behaviour.
- 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 !).
- 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?
- 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.orgon port 64890. The messages are gzipped.