Skip to navigation

Threat reportThreat IntelligenceTL-2026-1753

Research: Android ML Malware Detectors Collapse Without Context-Stage Analysis (PRAXIS vs. Drebin, MalScan, MsDroid, MaskDroid, LAMD, ForeDroid)

lowMONITORING

Researchers from Singapore Management University and Nankai University show that six widely used Android malware detectors — Drebin, MalScan, MsDroid, MaskDroid, LAMD, and ForeDroid — misclassify high-permission benign apps at over 50% (80% for the LLM-based LAMD) once context-aware judgment is removed, on a 270-app privileged-benign test set.

Key facts

IdentifiersTL-2026-1753
Also known asPRAXIS, From Signals to Behaviors: Evidence-Based Android Malware Detection
SeverityLOW
Affected productsAcademic/open research (SVM manifest-feature detector) Drebin Android malware detector; Academic/open research (call-graph centrality detector) MalScan Android malware detector; Academic/open research (call-graph subgraph GNN detector) MsDroid Android malware detector; Academic/open research (graph neural network detector) MaskDroid Android malware detector; Academic/open research (LLM-based detector) LAMD Android malware detector; Academic/open research (scenario-aware OCSVM detector) ForeDroid Android malware detector
MalwareBank Mellat-impersonating banking trojan (case study, unnamed)
ToolsDeepSeek-V4-Flash, DeepSeek-V4-Pro, Drebin, ForeDroid, Ghidra, LAMD, MalScan, MaskDroid, MsDroid, PRAXIS, Soot
MITRE ATT&CK techniquesT1406 Obfuscated Files or Information, T1417 Input Capture, T1426 System Information Discovery, T1437 Application Layer Protocol, T1444 Masquerade as Legitimate Application, T1476 Deliver Malicious App via Other Means, T1533 Data from Local System, T1541 Foreground Persistence, T1575 Native API, T1624 Event Triggered Execution, T1630 Indicator Removal on Host, T1636 Protected User Data and 3 more in the attack flow
MotivationFINANCIAL
Target sectorsfinance, banking, technology, mobile-application-ecosystem
Target regionsMiddle East, Global
Detection rules9 (1 shown free)
Sources8 cited sources

Detection coverage

As of 2026-07-29, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1753 across Splunk SPL, Microsoft KQL and Sigma, covering 26 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: SMS PDU Parse Chained with Android-ID Fingerprint Read (SPL)

Detects an Android app invoking SMS PDU-parsing APIs (SmsMessage.createFromPdu / getMessageBody / getOriginatingAddress) within 30 seconds of reading the device's Android ID via Settings$Secure.getString. This fused capture-then-fingerprint sequence matches the PRAXIS Bank Mellat case study's post-exploitation behavior — the app captures the OTP/SMS content and a device identifier back-to-back before bundling them for exfiltration, alongside a fake 'Hamrah Bank' login screen harvesting card/password input.

  • Languages: Splunk SPL, Microsoft KQL, Sigma
  • ATT&CK: T1412, T1417, T1426, T1636, T1533
  • Data sources: Mobile Threat Defense (MTD) runtime API-invocation telemetry (Zimperium zIPS, Lookout MES), Android application sandbox/EDR behavioral logs forwarded to SIEM, Mobile app reputation/allowlist lookup (known_banking_app)
  • Severity: high
  • Confidence: high

Splunk SPL

index=mobile_threat_defense sourcetype="mtd:runtime_behavior_events"
| search api_call IN ("SmsMessage.createFromPdu", "SmsMessage.getMessageBody", "SmsMessage.getOriginatingAddress")
| rename _time as sms_time
| join type=inner device_id, app_package [
    search index=mobile_threat_defense sourcetype="mtd:runtime_behavior_events" api_call="Settings$Secure.getString" setting_key="android_id"
    | rename _time as fp_time
    | fields device_id app_package fp_time
  ]
| where fp_time>=sms_time AND (fp_time-sms_time)<=30
| lookup mobile_app_reputation app_package OUTPUT known_banking_app
| where isnull(known_banking_app) OR known_banking_app=0
| table sms_time, fp_time, device_id, app_package, api_call, sms_body_preview
| sort -sms_time

Microsoft KQL

let SmsApiCalls = DeviceEvents
| where Timestamp > ago(24h)
| where ActionType == "AndroidApiInvocation"
| extend ApiCall = tostring(parse_json(AdditionalFields).apiCall)
| where ApiCall in ("SmsMessage.createFromPdu", "SmsMessage.getMessageBody", "SmsMessage.getOriginatingAddress")
| project DeviceId, FileName, SmsTime = Timestamp;
let FingerprintCalls = DeviceEvents
| where Timestamp > ago(24h)
| where ActionType == "AndroidApiInvocation"
| extend ApiCall = tostring(parse_json(AdditionalFields).apiCall), SettingKey = tostring(parse_json(AdditionalFields).settingKey)
| where ApiCall == "Settings$Secure.getString" and SettingKey == "android_id"
| project DeviceId, FileName, FpTime = Timestamp;
SmsApiCalls
| join kind=inner (FingerprintCalls) on DeviceId, FileName
| where FpTime >= SmsTime and datetime_diff('second', FpTime, SmsTime) <= 30
| join kind=inner (DeviceInfo | where DeviceType == "Android") on DeviceId
| project DeviceId, DeviceName, FileName, SmsTime, FpTime

Sigma

title: Android App Chains SMS PDU Parsing with Android-ID Fingerprint Collection
id: 8f1a1c02-9b7e-4f2a-8f1c-tl17530a02
status: experimental
description: Detects an Android app invoking SMS PDU-parsing APIs (SmsMessage.createFromPdu / getMessageBody / getOriginatingAddress) within 30 seconds of reading the device Android ID via Settings$Secure.getString, matching the PRAXIS Bank Mellat case study's fused SMS-capture-plus-device-fingerprint behavior used to build an exfiltration payload.
references:
    - https://arxiv.org/abs/2607.23272
author: Threadlinqs Team
date: 2026/07/29
tags:
    - attack.credential-access
    - attack.t1412
    - attack.t1417
    - attack.discovery
    - attack.t1426
    - attack.collection
    - attack.t1636
    - attack.t1533
logsource:
    category: application
    product: android
    service: mtd_telemetry
detection:
    selection_sms_parse:
        ApiCall:
            - 'SmsMessage.createFromPdu'
            - 'SmsMessage.getMessageBody'
            - 'SmsMessage.getOriginatingAddress'
    selection_fingerprint:
        ApiCall: 'Settings$Secure.getString'
        SettingKey: 'android_id'
    timeframe: 30s
    condition: selection_sms_parse and selection_fingerprint
falsepositives:
    - Legitimate banking/2FA autofill apps or carrier SMS-verification SDKs that read the Android ID for device-binding fraud checks in the same session as SMS OTP autofill
level: high

Known false positives:

  • Legitimate banking or 2FA-autofill apps that intentionally read SMS OTP content and the device Android ID in the same session for device-binding fraud prevention — tune with the mobile_app_reputation / known_banking_app lookup

Tuning notes: Populate the mobile_app_reputation lookup (known_banking_app) with vetted, store-verified banking/2FA app package names to suppress expected fused SMS+fingerprint behavior; widen or narrow the 30-second correlation window based on observed benign-app API call spacing in the environment.

8 more detection rules (Splunk SPL, Microsoft KQL, Sigma) · unlock with TL Creds. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • Android App Install — Minimal SMS/Internet Permissions with Priority-999 SMS Receiver (KQL) · unlock with TL Creds
  • SMS PDU Parse Chained with Android-ID Fingerprint Read (KQL) · unlock with TL Creds
  • SMS/Device-ID Exfil POST Followed by ACTION_DELETE Self-Uninstall (KQL) · unlock with TL Creds
  • Android App Install — Minimal SMS/Internet Permissions with Priority-999 SMS Receiver (Sigma) · unlock with TL Creds
  • SMS PDU Parse Chained with Android-ID Fingerprint Read (Sigma) · unlock with TL Creds
  • SMS/Device-ID Exfil POST Followed by ACTION_DELETE Self-Uninstall (Sigma) · unlock with TL Creds
  • Android App Install — Minimal SMS/Internet Permissions with Priority-999 SMS Receiver (SPL) · unlock with TL Creds
  • SMS/Device-ID Exfil POST Followed by ACTION_DELETE Self-Uninstall (SPL) · unlock with TL Creds

Indicators of compromise

As of 2026-07-29, Threadlinqs Intelligence tracks 26 indicators of compromise for TL-2026-1753.

26 indicators of compromise · unlock with TL Creds. Compare plans

Technical analysis

Their proposed three-stage detector, PRAXIS (Hypothesize → Confirm → Judge), cuts the false-positive rate to 13.0% by adding an LLM-driven context stage that separates legitimate broad-permission behavior from malicious intent, illustrated with a Bank Mellat-impersonating banking-trojan case study.

A July 2026 paper, "From Signals to Behaviors: Evidence-Based Android Malware Detection" (Shiwen Song, Yiheng Xiong, Sen Chen, Xiaofei Xie; Singapore Management University and Nankai University; arXiv:2607.23272), argues that Android malware detection should be behavior-oriented rather than signal-oriented: recover an app's candidate malicious behaviors, confirm them with code evidence, and only then judge intent using app context. The authors benchmark their proposed three-stage detector, PRAXIS, against six/seven baselines representing the dominant paradigms in academic Android malware detection: Drebin (extracts static manifest/code features into a binary feature vector and trains an SVM classifier, NDSS 2014), MalScan (constructs function call graphs and represents each APK using centrality-based features of sensitive APIs, trains a k-nearest-neighbor classifier, ASE 2019), MsDroid (extracts sensitive-API call-subgraphs and trains a graph-neural-network classifier), MaskDroid (improves GNN robustness through masked graph representation learning plus contrastive learning, ASE 2024), LAMD (LLM-based detector that summarizes backward slices taken around sensitive APIs, IEEE S&P Workshops 2025), and ForeDroid (flags sensitive-API call chains that deviate from a benign reference distribution using a one-class SVM/OCSVM, ACM CCS 2025).

The central finding directly relevant to SOC detection-engineering confidence: on a purpose-built 270-app 'privileged-benign' test set (benign apps spanning 49 Google Play categories, each declaring at least nine dangerous permissions), most baseline detectors flag over half of these legitimate high-permission apps as malicious (Drebin 65.2% FPR, MsDroid 75.2% FPR), and the LLM-based LAMD detector alone misflags roughly 80% of them. An ablation of PRAXIS's own context-judgment stage reproduces this collapse directly: with the context/Judge stage removed, PRAXIS's malware-recall failure rate (false-negative rate) explodes from 11.7% to 95.3% on time-shifted evaluation data, because behavioral evidence alone — without an app-context judgment step — cannot separate a legitimately broad-permission app (or a genuinely malicious behavior hidden among benign-looking code) from an actual attack. Restoring the context stage as PRAXIS's third pipeline phase drives the full-pipeline privileged-benign false-positive rate down to 13.0% and lifts overall detection F1 to 87.4% (best of all baselines: Drebin 68.8%, MaskDroid 63.8%, MalScan 55.7%, LAMD 55.0%, ForeDroid 53.5%, MsDroid 52.6%), outperforming the prior baselines by 18.6-34.8 percentage points on the paper's fine-grained benchmarks. On the balanced time-shift set specifically, PRAXIS reaches 92.2% F1 (FNR 11.7%, FPR 3.3%) versus Drebin's 82.6% F1 (FNR 27.3%, FPR 3.3%) and MaskDroid's 74.1% F1 (FNR 31.3%, FPR 16.7%); on the diverse-family malware-only set, PRAXIS's FNR (20.9%) beats MaskDroid (22.7%) and LAMD (26.9%); on fine-grained behavior identification, PRAXIS scores 87.3% F1 versus ProMal's 30.8% and ForeDroid's 13.9%.

PRAXIS's pipeline has three explicit stages: (1) Hypothesize — extract manifest permissions/components, sensitive API calls and implicit intents via the Soot static-analysis framework, and native-library function names via Ghidra, then prompt an LLM (DeepSeek-V4-Pro for reasoning, DeepSeek-V4-Flash for corpus summarization) to generate candidate malicious-behavior hypotheses; (2) Confirm — casts each hypothesis as an entry, a source, and an effect, retrieves candidate functions for each role, and keeps only the triples whose entry/source/effect chains actually reach one another across call chains, inter-component transitions, and shared fields (grounding the hypothesis in code evidence rather than surface signal); (3) Judge — contextualizes confirmed behaviors using triggering conditions (background vs. user-initiated execution) and overall app purpose/UI-text alignment to decide whether behavior is malicious or legitimate. Evaluation used a training corpus of 30,000 apps (10,000/year, 2021-2023) and a validation corpus of 7,500 apps (2,500/year, 2021-2023), sourced from AndroZoo/MalwareBazaar/GPMalware, plus three held-out test sets totaling 1,033 apps: a time-shift set (100 malware + 100 benign per year, 2024-2026, for concept-drift testing), a diverse-family set (163 malware samples spanning 163 distinct families, 2015-2026), and the 270-app privileged-benign set. GPMalware's malware corpus is organized into 8 payload categories that the paper further decomposes into 50 fine-grained behavior types (not individually enumerated in the available source material) used to score behavior-identification F1.

The paper's sole detailed malware case study is a banking trojan that impersonates Iran's Bank Mellat: the app labels itself 'Hamrah Bank' ('Mobile Bank' in Persian) and renders a Flutter-based fake login screen (card number, password, password-recovery flow) with no real Bank Mellat backend connection or transaction logic. Its manifest declares exactly three permissions — RECEIVE_SMS, READ_SMS, INTERNET — and registers an exported broadcast receiver (component `io.flutter.plugins.Receiver`) on `android.provider.Telephony.SMS_RECEIVED` with intent-filter priority 999 to intercept incoming SMS (e.g., banking OTPs/2FA codes) ahead of the user's default SMS app. It parses the intercepted PDU data via `SmsMessage.createFromPdu`, extracts the message body and sender via `getMessageBody`/`getOriginatingAddress`, additionally fingerprints the device by reading the Android ID through `Settings$Secure.getString`, and bundles this data into a payload exfiltrated through a Kotlin coroutine/lambda terminating in an `HttpURLConnection` write to a remote endpoint. The SMS-interception logic runs as a long-running background service without user awareness (silent collection), and the paper references app-uninstallation behavior driven through the Android Intent mechanism with action `ACTION_DELETE`, consistent with an indicator-removal / self-uninstall step in the same entry-source-effect behavior model. On evasion, the paper notes generically (without evaluating an adversarial attack against PRAXIS itself) that "a malicious app can drop conspicuous permissions, obfuscate its APIs, and mimic a benign one ... but it cannot drop the harmful behavior itself" — the design rationale for behavior-oriented rather than signal-oriented detection. No CVE, malware-family name, sample hash, or C2 domain/IP is disclosed in the available source material — this is illustrative research/methodology reporting, not an active-campaign advisory, and no exploit or PoC is being distributed.

Relevance to detection engineering: this paper is a direct, evidence-based warning against trusting single-signal (manifest/permission/call-graph/LLM) Android malware verdicts for automated blocking, especially against high-permission legitimate apps (banking, MDM, accessibility, communication apps commonly carry 9+ dangerous permissions). Threat hunters and mobile app-vetting pipelines relying on Drebin-, MalScan-, MsDroid-, MaskDroid-, LAMD-, or ForeDroid-style tooling should expect elevated false-positive rates on high-permission benign software unless a context-aware judgment stage (human or automated) is added, and should treat this benchmark as a tuning reference for detection-confidence thresholds. The Bank Mellat case study's concrete API-level behaviors (exported SMS_RECEIVED receiver at priority 999, PDU parsing, Android ID fingerprinting, HttpURLConnection exfiltration, ACTION_DELETE self-removal) are directly usable as hunting signatures for SOC teams building or tuning Android malware/behavioral-analysis detections.

MITRE ATT&CK techniques by tactic:

defense-evasion

T1406 Obfuscated Files or Information; T1575 Native API; T1630 Indicator Removal on Host

collection

T1417 Input Capture; T1636.004 SMS Messages

Discovery

T1426 System Information Discovery

command-and-control

T1437 Application Layer Protocol

initial-access

T1444 Masquerade as Legitimate Application; T1476 Deliver Malicious App via Other Means; T1660 Phishing

Collection

T1533 Data from Local System; T1636 Protected User Data

Persistence

T1541 Foreground Persistence; T1624 Event Triggered Execution

Exfiltration

T1646 Exfiltration Over C2 Channel

Remediation

Patches

  • Not applicable — this is a detection-methodology weakness identified in academic/open research detectors, not a vendor software vulnerability; no vendor patch exists.

Immediate actions

  • Do not act on a single ML/LLM-based Android malware detector's raw verdict for automated blocking of high-permission apps (banking, MDM, accessibility, communications); require human or context-based triage before quarantine or app-store rejection actions.
  • For any mobile app-vetting or threat-hunting pipeline built on Drebin-, MalScan-, MsDroid-, MaskDroid-, LAMD-, or ForeDroid-style detection logic, benchmark current false-positive rates against the paper's 270-app privileged-benign methodology (≥9 dangerous permissions, 49 Google Play categories) before trusting alert volume or auto-block thresholds.
  • Hunt for the Bank Mellat case-study's concrete indicators as a behavioral signature template: apps declaring only RECEIVE_SMS/READ_SMS/INTERNET with an exported SMS_RECEIVED broadcast receiver at intent-filter priority ≥999, PDU parsing via SmsMessage.createFromPdu, Android-ID exfiltration via Settings$Secure.getString, and background HttpURLConnection posts.

Workarounds

  • Route apps flagged by manifest-, permission-, or call-graph-only detectors (i.e., no context-judgment stage) that declare ≥9 dangerous permissions into manual analyst review rather than automated block/allow decisions.

Longer-term hardening

  • Evaluate adopting a context-aware, evidence-then-judge detection architecture (Hypothesize → Confirm → Judge, as demonstrated by PRAXIS) for mobile threat-hunting and app-vetting pipelines to reduce both false positives on legitimate broad-permission apps and false negatives on time-shifted/novel malware.
  • Track PRAXIS (arXiv:2607.23272) and successor benchmarks as a reference dataset for tuning in-house mobile-detector confidence thresholds and for concept-drift (time-shift) regression testing of detection models.

Affected and fixed versions

  • Academic/open research (SVM manifest-feature detector) — Drebin Android malware detector
    Vulnerable versions: baseline configuration (manifest + API feature SVM, no context stage)
    Fixed in: N/A — superseded in this benchmark by context-aware architectures (e.g., PRAXIS)
  • Academic/open research (call-graph centrality detector) — MalScan Android malware detector
    Vulnerable versions: baseline configuration (sensitive-API call-graph centrality + KNN classifier, no context stage)
    Fixed in: N/A — superseded in this benchmark by context-aware architectures (e.g., PRAXIS)
  • Academic/open research (call-graph subgraph GNN detector) — MsDroid Android malware detector
    Vulnerable versions: baseline configuration (sensitive-API call-subgraph GNN classifier, no context stage)
    Fixed in: N/A — superseded in this benchmark by context-aware architectures (e.g., PRAXIS)
  • Academic/open research (graph neural network detector) — MaskDroid Android malware detector
    Vulnerable versions: baseline configuration (masked-graph GNN + contrastive learning, no context stage)
    Fixed in: N/A — superseded in this benchmark by context-aware architectures (e.g., PRAXIS)
  • Academic/open research (LLM-based detector) — LAMD Android malware detector
    Vulnerable versions: baseline configuration (backward-slice summarization around sensitive APIs, context extraction present but distinct judgment approach)
    Fixed in: N/A — superseded in this benchmark by PRAXIS's Hypothesize-Confirm-Judge pipeline
  • Academic/open research (scenario-aware OCSVM detector) — ForeDroid Android malware detector
    Vulnerable versions: baseline configuration (one-class SVM deviation from benign API-chain distribution, no PRAXIS-style judge stage)
    Fixed in: N/A — superseded in this benchmark by context-aware architectures (e.g., PRAXIS)

Timeline

  • Drebin, the SVM-over-manifest/API-feature Android malware detector later used as a PRAXIS baseline, originally published (NDSS 2014).
  • MalScan, a sensitive-API call-graph centrality-based Android malware detector using a k-nearest-neighbor classifier, published at ASE 2019; later used as a PRAXIS baseline.
  • PRAXIS training corpus (30,000 apps, 10,000/year) and validation corpus (7,500 apps, 2,500/year), sourced from AndroZoo, MalwareBazaar, and GPMalware, close their 2021-2023 collection window.
  • MaskDroid, a masked graph-neural-network Android malware detector with contrastive learning for adversarial robustness, accepted at IEEE/ACM ASE 2024; later used as a PRAXIS baseline.
  • LAMD, an LLM-based Android malware detector that summarizes backward slices around sensitive APIs, accepted at IEEE Symposium on Security and Privacy Workshops 2025; later used as a PRAXIS baseline and shown to misflag ~80% of the 270-app privileged-benign set without a context stage.
  • ForeDroid, a scenario-aware Android malware detector flagging sensitive-API call chains via one-class SVM deviation from a benign reference distribution, published at ACM CCS 2025; later used as a PRAXIS baseline.
  • PRAXIS time-shift evaluation window (100 malware + 100 benign apps per year, 2024-2026, 1,033 apps total across all three held-out test sets) used to measure concept-drift/false-negative-rate collapse begins its most recent annual slice.
  • "From Signals to Behaviors: Evidence-Based Android Malware Detection" (PRAXIS), by Song, Xiong, Chen, and Xie (Singapore Management University / Nankai University), submitted to arXiv as 2607.23272.
  • TL-Intel Harness HUNT phase ingests the Help Net Security article as a low-severity, monitoring-status threat-intel item for detection-engineering relevance.
  • Help Net Security publishes summary reporting on the PRAXIS research, describing the context-stage collapse findings and the Bank Mellat-impersonating case study.

Sources cited

Previous and next in threat intel

Drafted by the Threadlinqs research pipeline from 8 sources; published ; last updated —.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level

Latest Threats