S1054: Drinik
Drinik is an evolving Android banking trojan that was observed targeting customers of around 27 banks in India in August 2021. Initially seen as an SMS stealer in 2016, Drinik resurfaced as a banking trojan with more advanced capabilities included in subsequent versions between September 2021 and August 2022.[1]
Analyst context for executives and security teams
Drinik matters because it represents Android mobile banking malware with credential, SMS, call, screen, local data, persistence, hiding, and exfiltration behaviors mapped in ATT&CK. For leaders, the practical issue is not just one malware family: it is whether mobile devices used by customers, employees, or privileged users can expose banking, identity, and communications data without enough visibility for the SOC or incident responders to act.
Executive priority
Prioritize Drinik as a mobile fraud and identity-risk validation case. The ATT&CK record ties it to Android and to banking-trojan behavior observed against customers of around 27 banks in India in 2021, with later versions adding more advanced capabilities. Security leaders should ask whether mobile threat monitoring, device policy, incident intake, and fraud/identity response processes can handle malware that captures input, SMS messages, call data, screens, and local data while hiding its presence and communicating over application-layer protocols.
Technical view
SOC and IR teams should treat this object as an Android-focused behavioral coverage test. ATT&CK provides no official detection text, so validation should be built from the linked behaviors: obfuscated files or information, keylogging, GUI input capture, application-layer protocol communications, screen capture, local data collection, foreground persistence, SMS control, call control, launcher-icon suppression, disabling or modifying tools, call log and SMS message collection, and exfiltration over C2. Coverage should be assessed at the device, application, permission, network, and user-reporting layers, especially where Android permissions or user consent gates are involved.
Likely telemetry
- Android application inventory, install source, package metadata, and icon/launcher visibility state
- Requested and granted Android permissions for SMS, phone calls, accessibility-like input capture, screen capture, foreground services, and local storage access
- Events showing use of SMS content providers, SMS send/receive behavior, and default SMS handler changes
- Call log access, call initiation, answering, forwarding, or blocking behavior where collected
- Foreground service activity and user consent prompts related to screen capture or sensor access
Detection direction
- Because MITRE provides no official detection guidance for S1054, start by confirming what Android telemetry is actually collected and retained before writing detections.
- Look for combinations of suspicious behaviors rather than single permissions: hidden launcher icon, sensitive SMS/call permissions, foreground service use, screen capture prompts, input capture, obfuscated payloads, and network communications together are more meaningful than any one signal alone.
- Tune carefully for false positives from legitimate mobile banking, accessibility, messaging, security, and device-management apps that may request sensitive permissions or run foreground services.
- Validate whether mobile security tooling can detect or report attempts to disable or modify security tools, device administrator abuse, rooted-device conditions, and suppression of application icons.
- Correlate device-side events with network evidence for application-layer C2 and exfiltration over the same channel, recognizing that encrypted or common protocols may limit content inspection.
Mitigation priorities
- Establish mobile application governance for Android devices, including approved app sources, app inventory review, and removal workflows for untrusted or suspicious apps.
- Limit and monitor high-risk permissions such as SMS, phone, screen capture, accessibility/input capture, local storage access, and device administrator capabilities where business requirements allow.
- Use MDM or mobile security controls to flag hidden apps, risky permission combinations, rooted or tampered devices, and attempts to interfere with security tooling.
- Prepare mobile incident response playbooks for credential exposure, SMS compromise, call/SMS manipulation, and potential exfiltration from Android devices.
- Educate users to treat unexpected banking, tax, credential, SMS, phone, keyboard, accessibility, or screen-capture prompts as reportable security events.
Analyst notes and limits
This take is based only on the ATT&CK S1054 software object, its external reference to Cyble, and the listed ATT&CK relationships. The strongest defensive value is using Drinik as a practical Android mobile threat coverage scenario across identity, fraud, SOC monitoring, and incident response.
ATT&CK does not provide tactics, aliases, labels, or official detection text for this object in the supplied fields. The relationship descriptions describe possible behaviors used by Drinik but do not by themselves prove local exposure or current activity in any environment. Local device telemetry, mobile security tooling, app inventories, and incident evidence are required to assess actual risk or coverage.
Drinik
Drinik is an evolving Android banking trojan that was observed targeting customers of around 27 banks in India in August 2021. Initially seen as an SMS stealer in 2016, Drinik resurfaced as a banking trojan with more advanced capabilities included in subsequent versions between September 2021 and August 2022.[1]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1582 | SMS Control | Drinik can steal incoming SMS messages and send SMS messages from compromised devices. Citationcyble_drinik_1022 |
| Mobile | T1629.003 | Disable or Modify Tools Sub-technique | Drinik can use Accessibility Services to disable Google Play Protect.Citationcyble_drinik_1022 |
| Mobile | T1646 | Exfiltration Over C2 Channel | Drinik can send stolen data back to the C2 server.Citationcyble_drinik_1022 |
| Mobile | T1616 | Call Control | Drinik can use the Android `CallScreeningService` to silently block incoming calls.Citationcyble_drinik_1022 |
| Mobile | T1417.001 | Keylogging Sub-technique | Drinik can use keylogging to steal user banking credentials.Citationcyble_drinik_1022 |
| Mobile | T1513 | Screen Capture | Drinik can record the screen via the `MediaProjection` library to harvest user credentials, including biometric PINs.Citationcyble_drinik_1022 |
| Mobile | T1417.002 | GUI Input Capture Sub-technique | Drinik can use overlays to steal user banking credentials entered into legitimate sites.Citationcyble_drinik_1022 |
| Mobile | T1541 | Foreground Persistence | Drinik has C2 commands that can move the malware in and out of the foreground. Citationcyble_drinik_1022 |
| Mobile | T1636.002 | Call Log Sub-technique | Drinik can request the `READ_CALL_LOG` permission.Citationcyble_drinik_1022 |
| Mobile | T1636.004 | SMS Messages Sub-technique | Drinik can collect user SMS messages.Citationcyble_drinik_1022 |
| Mobile | T1406 | Obfuscated Files or Information | Drinik has used custom encryption to hide strings, potentially to evade antivirus products.Citationcyble_drinik_1022 |
| Mobile | T1533 | Data from Local System | Drinik can request the `READ_EXTERNAL_STORAGE` and `WRITE_EXTERNAL_STORAGE` Android permissions.Citationcyble_drinik_1022 |
| Mobile | T1437 | Application Layer Protocol | Drinik has code to use Firebase Cloud Messaging for receiving C2 instructions.Citationcyble_drinik_1022 |
| Mobile | T1628.001 | Suppress Application Icon Sub-technique | Drinik can hide its application icon.Citationcyble_drinik_1022 |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 03baab84c784… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
cyble_drinik_1022
Cyble. (2022, October 27). Drinik Malware Returns With Advanced Capabilities Targeting Indian Taxpayers. Retrieved November 17, 2024.
Open source URL -
[2]
mitre-attack S1054Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.