APK Malware Analysis: A Static Triage Worksheet

Create a case record

Use only files you are authorized to analyze. Store the original read-only and record its hash, source and collection time. Work inside a disposable analysis environment, keep tools updated and avoid opening extracted files with unrelated applications.

Artifact: sample.apk
SHA-256: <full hash>
Package/version: <extracted metadata>
Signing certificate: <fingerprint>
Observed indicators: <evidence and location>
Unresolved questions: <runtime tests needed>

This notebook prevents findings from different builds being mixed together during an investigation.

Inspect in layers

Start with the manifest: exported components, permissions, SDK levels and debug flags. Then inspect native libraries, DEX structure, assets and embedded endpoints. Use Android's package analysis tools to establish facts before relying on a decompiler's reconstructed source.

An accessibility service plus network access is not automatically malicious. Ask whether the application actually declares such a service, how it is presented to the user, and whether the capability fits the claimed function.

Separate capability from execution

Obfuscated names and unusual packaging can complicate inspection but are not proof of wrongdoing. Similarly, unobfuscated code is not proof of transparency or safety.

Escalate with controlled experiments

The OWASP testing guide provides a framework for selecting runtime tests. Use isolated devices, test accounts and approved endpoints. Record the action triggering the behavior and preserve logs with timestamps. Avoid production credentials and unrestricted network access for suspicious samples.

Report uncertainty usefully

A valuable report names the affected hash, evidence location, expected behavior and unanswered questions. APKLint's suspicious-behavior scanner can organize static indicators, but its output is a lead for review rather than a malware-family attribution or a guarantee of complete coverage.