Most malicious Android apps don't rely on novel exploits - they rely on obfuscation, social engineering, and just enough functionality to look legitimate until they get the permissions they want. When you're triaging a suspicious APK, the goal isn't to be clever; it's to be systematic.
1. Start static, before anything runs
Before installing or executing anything, I unpack the APK and look at it as a static artifact. APKTool decodes resources and the manifest, while JADX converts the compiled bytecode back into readable Java/Kotlin-like source. At this stage I'm looking for:
- Permissions requested in the manifest that don't match the app's stated purpose (SMS, accessibility services, overlay permissions are common red flags).
- Hardcoded URLs, IPs, or domains - often base64-encoded or split across string concatenations to dodge simple string searches.
- Native libraries or heavily obfuscated classes that suggest the "real" logic is hidden away from the decompiled Java.
2. Cross-check before going deeper
A quick hash lookup on VirusTotal tells you whether the sample is already known, and to whom. Even a handful of detections from reputable engines is enough to prioritize a sample and start narrowing down its likely family and behavior before doing the slower manual work.
3. Watch obfuscation patterns, not just code
Most samples aren't hiding via exotic packers - they use a small set of repeatable tricks: string encryption resolved only at runtime, reflection to call sensitive APIs indirectly, and renamed classes/methods that strip out anything meaningful. Once you've seen the pattern a few times, you stop trying to read every obfuscated string and instead look for where it gets decrypted, since that's usually a single chokepoint in the code.
4. Move to dynamic analysis carefully
Static analysis only gets you so far when code is encrypted or loaded dynamically. That's where Frida comes in - hooking specific methods (decryption routines, network calls, permission checks) at runtime to see what they actually do, without having to fully reverse-engineer the obfuscation by hand. This is always done in an isolated environment, never on a daily-driver device.
5. Document network indicators
Whatever the payload does - exfiltrating contacts, intercepting SMS for OTP theft, or pulling a second-stage payload - it eventually has to talk to something. Capturing and documenting those network indicators (domains, endpoints, request patterns) is often the most reusable output of an analysis, since it's what other defenders can act on immediately.
The point of this workflow isn't to fully reverse every line of an app - it's to get to "what does this app actually do, and what indicators can I hand off" as efficiently as possible.
None of this requires exotic tooling. JADX, APKTool, Frida, Nmap, and VirusTotal cover the vast majority of what you need to triage a suspicious Android sample - the skill is in the workflow, not the tool list.