How can security teams detect Drinik?

What Drinik leaves behind on an Android device

Drinik is best detected as a mobile banking trojan, not as a single signature. Security teams should look for the pattern of an app that behaves differently from the legitimate banking or payment app it imitates: overlay prompts, deceptive login screens, and collection of credentials or verification data. The strongest indicators usually appear when user interaction, permissions, and network activity do not line up with the expected app flow.

Because Android banking malware often blends into normal device usage, the practical question is whether the device is showing behavior that should not be possible for the stated app purpose. That includes accessibility abuse, SMS interception, and persistence that keeps the malware present after the initial phishing or dropper stage has finished.

For broader mobile-malware triage patterns, the Mobile Malware Guide is useful because it ties overlay abuse, accessibility abuse, and OTP theft to the kinds of symptoms defenders actually see on Android endpoints.

What to inspect first when you suspect Drinik

Start with the app inventory on the device. Look for newly installed or sideloaded apps that request more access than their stated function requires, especially accessibility services, SMS access, notification access, device admin capability, or the ability to draw over other apps. Those permissions matter because Drinik-style malware depends on them to read, suppress, or mimic authentication steps.

Then review whether the banking or payment experience matches the expected app journey. If a user is suddenly prompted for identity verification, card data, or login details in a screen that does not match the normal application, treat it as a likely overlay or phishing flow rather than a harmless UI issue. The same applies when prompts appear outside the legitimate app, or when login pages are shown after the app should already be authenticated.

Network review is the other fast filter. Unknown domains, unusual IPs, and repeated connections to infrastructure that the legitimate banking app does not use can indicate exfiltration, command activity, or staged retrieval of additional payloads. For analyst workflow and detection mapping, MITRE ATT&CK Enterprise Matrix helps structure what you are seeing into collection, credential access, and persistence behavior.

How to confirm Drinik activity without overcalling normal app problems

Confirmation depends on correlation, not one symptom. A permission request alone is not enough, and a suspicious network connection alone is not enough. The case becomes stronger when suspicious permissions, deceptive prompts, and abnormal outbound activity appear together on the same device, especially if the user reports repeated interference with banking or verification flows.

Investigators should also check whether the device shows signs of credential interception or session manipulation. If a user enters valid details but the app responds with unusual reauthentication, failed second-factor prompts, or unexpected redirect behavior, that may indicate the malware is trying to capture authentication material in real time. Review whether SMS-based verification is being intercepted, forwarded, or hidden from the user, because that is a common path for mobile banking theft.

For teams that want a control-oriented view of how to validate device and account behavior, NIST Cybersecurity Framework 2.0 is a useful backbone for organizing detection, response, and recovery around an endpoint compromise investigation.

Risk and Threat Considerations

Drinik matters because the visible symptom is often not the real damage. Once a trojan can overlay trusted apps and intercept authentication, the attack can shift from simple phishing to account takeover, payment fraud, and recovery delay. The risk is highest when the device is used for banking, payment approval, or identity verification, because the malware can exploit user trust in ordinary-looking prompts.

Failure mechanism: The malware abuses Android permissions and user interaction boundaries to capture secrets, suppress legitimate prompts, and route the victim into a counterfeit verification path.

Impact: This can expose credentials, one-time codes, payment authorizations, and session access, which can lead to fraudulent transactions or broader compromise of linked accounts.

Practitioner Guidance

What to prioritise: Triage devices where banking, payment, or identity prompts deviate from the expected app flow before treating the case as a routine app support issue. The highest-value signal is the combination of suspicious permissions and user-reported prompt mismatch.

What to verify: Confirm whether the suspected app has accessibility, SMS, overlay, or device-admin capability, and verify whether any outbound connections map to infrastructure the legitimate app would not normally use. If both are present, treat the device as compromised until proven otherwise.

Practitioner takeaway: Drinik detection is strongest when you correlate device permissions, UI deception, and unusual network behavior, because any one signal alone can be ambiguous, but the full pattern usually is not.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?