Threat reportThreat IntelligenceTL-2026-1753
Research: Android ML Malware Detectors Collapse Without Context-Stage Analysis (PRAXIS vs. Drebin, MalScan, MsDroid, MaskDroid, LAMD, ForeDroid)
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
| Identifiers | TL-2026-1753 |
|---|---|
| Also known as | PRAXIS, From Signals to Behaviors: Evidence-Based Android Malware Detection |
| Severity | LOW |
| Affected products | Academic/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 |
| Malware | Bank Mellat-impersonating banking trojan (case study, unnamed) |
| Tools | DeepSeek-V4-Flash, DeepSeek-V4-Pro, Drebin, ForeDroid, Ghidra, LAMD, MalScan, MaskDroid, MsDroid, PRAXIS, Soot |
| MITRE ATT&CK techniques | T1406 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 |
| Motivation | FINANCIAL |
| Target sectors | finance, banking, technology, mobile-application-ecosystem |
| Target regions | Middle East, Global |
| Detection rules | 9 (1 shown free) |
| Sources | 8 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_timeMicrosoft 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, FpTimeSigma
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: highKnown 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.
- 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.
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
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
- From Signals to Behaviors: Evidence-Based Android Malware Detection (PRAXIS) arxiv.org · Research · 2026-07-25
- From Signals to Behaviors: Evidence-Based Android Malware Detection (PDF) arxiv.org · Research · 2026-07-25
- From Signals to Behaviors: Evidence-Based Android Malware Detection (HTML) arxiv.org · Research · 2026-07-25
- LAMD: Context-driven Android Malware Detection and Classification with LLMs arxiv.org · Research · 2025-02-01
- MASKDROID: Robust Android Malware Detection with Masked Graph Representations arxiv.org · Research · 2024-09-01
- ForeDroid: Scenario-Aware Analysis for Android Malware Detection and Explanation (ACM CCS 2025) dl.acm.org · Research · 2025-10-01
- MalScan: Fast Market-Wide Mobile Malware Scanning by Social-Network Centrality Analysis (ASE 2019) wu-yueming.github.io · Research · 2019-01-01
- Android malware detection collapses when the context stage comes out Help Net Security · News · 2026-07-29
Previous and next in threat intel
- NSO Group Co-Founder Shalev Hulio Held Israeli Diplomatic Passport in Panama, Raising State-Ties Questions for Pegasus Spyware Vendor Previous report
- Google AI Agents (Big Sleep, CodeMender, Gemini) Fix 1,072 Chrome Security Bugs Across Chrome 149/150, Including 13-Year-Old ANGLE Sandbox-Escape (CVE-2026-10881) Next report
Drafted by the Threadlinqs research pipeline from 8 sources; published ; last updated —.