Mobile Malware · Inside a Malicious App · Lesson 1 of 5

Red Flags in the Manifest

Triage a suspicious APK by comparing what it claims to do with what it asks for.

What the app says vs what it asks for

When a security analyst gets a suspicious app, the first look usually happens without running it. That's called static analysis: examining the APK's files, manifest, code and resources while the app sits still. It's safe, quick and tells you a lot. The first fast pass is called triage, the same word hospitals use for deciding who needs attention first. The goal isn't a full answer. It's deciding whether this app deserves a closer look.

You saw in The Manifest that every Android app has to declare its permissions in AndroidManifest.xml. That makes the manifest the natural place to start. The core question is simple: does what the app asks for fit what it claims to be?

Take a PDF scanner. It needs the camera to photograph pages, and it probably uses the internet for cloud saving or ads. Both fit. Now picture the same scanner asking for these:

• REQUEST_INSTALL_PACKAGES, which lets an app ask to install other apps. Google Play only allows it when installing packages is part of an app's core purpose, like a file manager or a browser. A scanner has no reason to install apps, and this is a classic sign of a dropper, an app that fetches and installs a second, malicious app.
• BIND_ACCESSIBILITY_SERVICE, the key to an accessibility service that can read the screen and tap for you. Banking trojans lean on it heavily.
• RECEIVE_SMS, which lets an app read incoming texts, including one-time login codes. Google Play limits it mostly to default texting and phone apps.
• SYSTEM_ALERT_WINDOW, which lets an app draw on top of other apps. That's how fake login overlays appear over a real bank app.

None of these is proof on its own. A screen reader legitimately needs accessibility. What matters is the mismatch, and how many red flags stack up together.

On the simulated phone, open the triage report for PDF Scanner Pro (com.pdfscan.pro.free). Tap each item, mark it Red flag or Normal, and read the feedback.

Signers, strings and suspicious files

Permissions are only part of the report. Three other places often give a malicious app away.

The signer. Every APK is signed, and the certificate tells you something about who built it. When a developer tests an app on their own computer, Android Studio signs it automatically with a debug certificate created by the build tools, usually with the name CN=Android Debug. Google's documentation calls it insecure by design, and Google Play doesn't accept apps signed with it. A real company shipping a real product signs with its own release key. So a debug signer on an app that's being passed around to the public suggests something rushed, homemade, or not meant to be traced.

Strings. A string is a piece of text stored in the app: messages, file names, web addresses. Analysts pull out every readable string and scan them. A web address pointing to a file like plugin.apk on an unfamiliar server is a strong hint that the app plans to download another app later. Analysts write such addresses with brackets, like example[.]com, so nobody clicks them by accident. That habit is called defanging.

File layout. An app's code normally lives in classes.dex. If that file is tiny but there's a large asset file full of random-looking bytes, such as data.bin, the visible code may only be a wrapper. The real code could be hidden, encrypted, and unpacked when the app runs. You'll look at this more closely in the next module.

This isn't a made-up pattern. In August 2025, Zscaler ThreatLabz described Anatsa banking trojan droppers on Google Play posing as document readers. The decoy looked useful, then fetched its malicious payload disguised as an update. Zscaler reported the apps to Google.

A good triage note lists each finding and why it matters, then gives an overall call: likely benign, needs more work, or likely malicious.