We Ran 10 Real Android Malware Samples Through Droidwatch — Here's What Static Analysis Caught

Published 2026-06-07 by the Droidwatch Security Research team

Most "how good is your scanner" posts use one cherry-picked sample. We wanted
something more honest, so we did the opposite: we grabbed 10 real Android
malware samples off the top of a public research corpus — no curation, just
the first ten files in alphabetical order — and pushed every one of them through
Droidwatch's static pipeline. No dynamic sandbox, no manual triage, no
hints. Just the verdict the platform produces on upload.

This post is the raw result: the scores, the recurring signals, the MITRE
ATT&CK Mobile coverage, and the two samples that are more interesting than the
headline number suggests.

Reproducibility & safety. Samples come from a public Android malware
corpus (collected Feb 2021) and are referenced by SHA-256 so anyone can match
them. Droidwatch's static pipeline never executes the APK — it unzips,
parses the manifest and DEX, decompiles with JADX, and runs the rule + YARA +
ML engines. Nothing here ran on a device.

The headline

Ten uploads, ten flagged. That's the easy part — anything labelled "malware
sample" should trip a scanner. The useful question is why each one tripped,
and whether the reasons hold up.

Per-sample results

A few of these names are worth a second look — GO SMS Pro and VidMate are
real, widely-installed apps that have shipped versions with serious security
problems (GO SMS Pro's unauthenticated media-link exposure; VidMate's
aggressive ad-fraud and subscription-fraud SDKs). Droidwatch doesn't care
whether an app is "famous" — it scores the bytecode in front of it.

What actually gave them away

Family labels are nice for headlines, but verdicts come from behavioural
signals. These are the findings that recurred across the ten samples (counts
are number of samples, out of 10):

• 6× — No signing certificate / broken signature. Repackaged or tampered
  builds frequently strip or break the v1/v2 signature.
• 3× — SMS read + send capability (OTP-theft pattern). The classic banking /
  2FA-interception combination: read incoming SMS and send/forward it.
• 3× — VirusTotal corroboration. Where a VT key was available, 3 samples came
  back confirmed malicious and 3 more suspicious / low-detection — useful
  precisely because the low-detection ones are what a multi-AV lookup alone would
  miss.
• 2× — Ransomware behavioural pattern + cryptocurrency ransom strings. Lock-screen
  / encryption routines paired with embedded BTC-style payment addresses.
• 2× — Overlay attack capability. SYSTEM_ALERT_WINDOW + TYPE_APPLICATION_OVERLAY
  API references — the building block for fake-login screens.
• 2× — Dynamic code loading (DexClassLoader). Second-stage payloads fetched
  or decrypted at runtime — the dropper pattern that defeats naïve static scans.
• 2× — Weak cryptography (DES/RC4/Blowfish) and weak hashes (MD5/SHA-1).
• 1× — Click-fraud API pattern (simulated touch events) and 1× binary-obfuscated
  manifest (anti-analysis).

None of these is conclusive on its own — a legitimate SMS-backup app reads SMS,
a legitimate launcher draws overlays. The verdict comes from the weighted
combination, which is why the scores cluster in the 65–74 band rather than
maxing out: the rule engine is adding up corroborating signals, not pattern-
matching a single string.

MITRE ATT&CK Mobile coverage

Every finding is mapped to ATT&CK for Mobile. Aggregated across the ten samples,
the technique frequency reads like a textbook mobile-malware kill chain:

Ten out of ten talk to a web back-end; nine out of ten obfuscate something. That
combination — C2 + obfuscation — is the single most reliable static tell for
"this isn't a normal app."

One YARA family rule also fired: Joker / Bread matched on one sample, the
SMS/premium-billing fraud family that has repeatedly slipped past Play Protect.

The interesting one: "Coronavirus Help" (High Risk, not Malicious)

Nine samples scored Malicious; one — a 5.9 MB App-Inventor build called
Coronavirus Help (14475b04ba91…) — landed at High Risk (49). That's the
verdict engine doing its job, not failing it.

This sample is a MIT App Inventor app: its real logic lives in a runtime
interpreter, so there's far less native bytecode for the static analyzers to
chew on. What Droidwatch can see — exported components without permissions,
weak crypto, suspicious manifest posture — is enough to push it well past
benign, but not enough to assert Malicious with high confidence on static
evidence alone. A "High Risk, needs a human / dynamic run" verdict is the honest
answer there, and it's exactly the kind of case the dynamic sandbox (Android)
exists to resolve.

Per-sample deep dives

Each sample gets its own full walkthrough — the analyzers that ran, every top
finding, the score breakdown and the MITRE ATT&CK mapping:

• Deep-Dive #1: 极游市场 (cn.ggg.market) — Malicious 74
• Deep-Dive #2: Installer (google.Jk7H.PwcD) — Malicious 65
• Deep-Dive #3: hidden-manifest sample — Malicious 65
• Deep-Dive #4: SMS Watcher Lite — Malicious 66
• Deep-Dive #5: NissanGo Theme — Malicious 65
• Deep-Dive #6: Coronavirus Help — High Risk 49
• Deep-Dive #7: Media Player — Malicious 65
• Deep-Dive #8: Parse Error (tampered manifest) — Malicious 65
• Deep-Dive #9: GO SMS Pro — Malicious 68
• Deep-Dive #10: VidMate — Malicious 71

Run it yourself

Every number above came from the default static pipeline — the same one behind
the free anonymous upload:

# Upload + analyze any APK via the REST API
curl -s -X POST https://droidwatch.app/api/upload \
  -H "X-Upload-Consent: 1" \
  -F "[email protected]" | jq -r .upload_id
# → then POST /api/analyze with that upload_id, poll /api/jobs/<id>,
#   and read the report (verdict, MITRE mapping, STIX 2.1) when done.

Or just drag an APK (or iOS .ipa) onto the homepage. Static analysis is free,
needs no account, and returns the full report — verdict, MITRE ATT&CK Mobile
mapping, YARA hits and a STIX 2.1 bundle for your SIEM — in about a minute.

Caveats, stated plainly: this was static-only analysis; the dynamic Frida
sandbox (Android) was not used. Family attribution is intentionally
conservative — Droidwatch would rather under-name a family than mislabel a
legitimate app. VirusTotal enrichment ran only where an API key was configured.
Samples are from a public 2021 corpus and may not reflect the current threat
landscape; the point of the exercise is the process, not a benchmark claim.