How do attackers use Drinik?

How Drinik Turns Banking Apps Into a Control Point

Drinik works by turning the mobile banking experience itself into the attack surface. The malware does not need a complex exploit chain when it can sit between the user and the app, observe credentials as they are entered, and use overlay screens to capture sensitive details at the moment they are typed. That makes the app session, not just the device, the thing defenders need to think about.

The practical significance is that Drinik’s value comes from abusing legitimate Android capabilities, especially accessibility services and SMS access, so the malware can read, alter, or mask activity without immediately looking like a classic Trojan. The result is a blended abuse pattern: credential theft, OTP interception, and user deception in one workflow.

Which Abuses Make Drinik Effective?

Drinik is effective because it chains several low-friction techniques together. Accessibility abuse lets it observe screen content and user actions, while overlay screens can mimic banking prompts and harvest login details or one-time passwords. SMS permissions allow it to intercept challenge codes or send messages, and notification hiding helps reduce the chance that the victim notices suspicious activity in time.

That combination matters because each technique reinforces the others. Even if a user becomes wary of a fake prompt, the malware can still reach the message channel or conceal alerts. Even if SMS interception is limited, overlay-based credential capture can still provide enough access for account takeover.

What Defenders Should Watch in Android Banking Intrusions

Defensive analysis should focus on behavior, not just the malware family name. Suspicious accessibility service enablement, unexplained overlay prompts, unusual SMS permission use, and message activity that does not fit the app’s normal function are all useful signals. On managed devices, the most useful evidence is often the sequence of events, who granted what permission, when the overlay appeared, and whether banking app activity diverged from ordinary user behavior.

Once those signals appear together, the issue is usually no longer limited to a single malicious app. It becomes a question of whether credentials, OTPs, or banking sessions were exposed long enough for an attacker to act. That is why response should include checking for unauthorized transfers, session anomalies, and any additional suspicious apps that may have enabled persistence.

Risk and Threat Considerations

Drinik’s threat is not only credential theft, it is the collapse of trust in the mobile banking workflow. When a trojan can see user input, intercept verification messages, and hide its own activity, the attacker can move from access collection to account abuse with little friction.

Failure mechanism: The malware abuses legitimate Android permissions and UI paths to sit inside the trust boundary of the banking session, then captures or relays authentication material before the user realises the session is compromised.

Impact: Attackers can take over accounts, approve transactions, suppress warnings, and extend the compromise if banking credentials or active sessions remain valid after the initial infection.

Practitioner Guidance

What to verify: Confirm whether the affected device granted accessibility access, SMS access, or overlay permission to any app that does not need it for a clearly stated business purpose. If those permissions were granted shortly before banking activity changed, treat the event as more than a nuisance infection.

What to prioritise: Revoke suspicious app permissions first, then force re-authentication for the banking account and review recent transactions, session history, and notification settings. If a banking OTP or login credential may have been exposed, assume the attacker had enough information to attempt follow-on access even if you have not yet seen a transfer.

Practitioner takeaway: With Drinik, the key question is not whether the app looked malicious at install time, it is whether it obtained enough UI and messaging access to silently observe and manipulate a banking session before defenders noticed.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?