Dok is Android banking malware that targets financial credentials and can intercept transactions on infected devices. It often relies on phishing, malicious apps or social engineering to gain access. Defenders should watch for abusive accessibility permissions, overlay prompts, SMS interception and device settings changes that indicate fraudulent control.
What Dok Is and How It Works
Dok is Android banking malware built to steal financial credentials and interfere with transactions on compromised devices. It usually enters through phishing, malicious apps, or social engineering, then blends into routine phone use so the victim keeps interacting with a hostile screen.
Because the malware runs on the endpoint a customer trusts, it can capture input, alter what the user sees, and manipulate payment flows before the user realises anything is wrong. That makes it especially dangerous in mobile banking, where a valid login and a familiar device can create a false sense of safety.
How Dok Gains Control of an Infected Device
Dok commonly relies on abusive accessibility permissions, which can give malware unusually broad visibility into what is happening on the screen and how the user is interacting with the device. Once granted, those permissions can help the malware observe app content, trigger actions, and hide its activity inside what looks like normal Android behaviour.
Other common control points include overlay prompts and device setting changes. An overlay can place a fake login or approval screen over a legitimate app, while settings changes can weaken the device’s own protections and make persistence easier.
What Dok Targets During a Banking Session
The malware is designed to harvest financial credentials and interfere with transactions at the moment they matter most. That can include capturing usernames, passwords, and other authentication material, then using that access to redirect or alter payment activity.
SMS interception is especially important because many banking flows still depend on text-message codes or alerts. If the malware can read or divert those messages, it may bypass a key warning channel and quietly complete actions the user did not intend.
How Defenders Spot and Contain Dok Activity
Defenders should look for unusual accessibility abuse, unexpected overlay behaviour, suspicious permission prompts, and device configuration changes that do not match normal user behaviour. A banking app that suddenly asks for broad device access, or a phone that begins showing repeated security or payment prompts, deserves close review.
Containment is strongest when mobile threat monitoring is paired with user verification on a separate channel. If a device shows signs of compromise, the safest assumption is that both the session and the device state may be unreliable until they are reviewed.
Risk and Threat Considerations
Dok is dangerous because it attacks the trust relationship between the user, the mobile device, and the banking app. Once the malware can control what the victim sees or approves, it can turn legitimate credentials and normal transaction flows into a fraud path.
Failure mechanism: The attacker gains device-level influence through phishing, malicious apps, or accessibility abuse, then uses that control to capture credentials, intercept messages, and manipulate transactions.
Impact: Victims can suffer account takeover, fraudulent transfers, loss of transaction integrity, and broader compromise of banking sessions or recovery channels.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Dok often enters through phishing and malicious links. |
| CIS-10 — Malware Defenses | Dok is Android malware, so anti-malware detection and response directly apply. | |
| CIS-14 — Security Awareness and Skills Training | Social engineering is a common delivery path for Dok. | |
| Recommendation — Harden user entry points to reduce malware delivery through phishing and web-based lures. Deploy mobile malware detection and response controls to identify and contain infected devices. Train users to recognize malicious app prompts, phishing lures, and suspicious permission requests. | ||
| MITRE ATT&CK | T1056 — Input Capture | Dok captures credentials and user input during banking sessions. |
| T1113 — Screen Capture | Dok can manipulate or observe on-screen banking activity through device control. | |
| T1406 — Obfuscated Files or Information | Malicious mobile apps often conceal behaviour to avoid detection. | |
| Recommendation — Map observed credential capture behaviour to input-capture techniques and alert on suspicious capture paths. Detect screen-observation and screen-manipulation activity that indicates hostile control of a session. Inspect mobile payloads for concealment patterns that mask malware capability or delivery. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dok targets credentials and session-related authentication material. |
| SI-3 — Malicious Code Protection | Dok is malicious code on the endpoint. | |
| AC-6 — Least Privilege | Dok abuses overbroad device permissions and access paths. | |
| Recommendation — Protect authenticators and rotate them quickly when credential theft or session compromise is suspected. Apply malicious code protection to detect, block, and quarantine infected Android devices. Restrict permissions and device capabilities to the minimum required for the banking use case. | ||
Practitioner Guidance
What to watch for: Treat accessibility abuse and overlay prompts as high-signal indicators, especially when they appear alongside SMS interception or unexpected changes to device settings. In mobile banking environments, those behaviours often matter more than the presence of a single suspicious app.
Governance implication: Mobile fraud controls work best when security teams define clear response thresholds for device trust, session trust, and user verification. If the device can no longer be trusted, the transaction path should not be trusted either.