How do attackers use Rotexy?

How Rotexy turns an Android phone into a fraud channel

Rotexy is not just trying to read data in the background. Its value to attackers comes from turning a trusted phone into a live interception point for banking flows, so the victim keeps using the app while the malware watches the session, captures sensitive inputs and interferes with message-based verification. That makes the infection stage only the start of the abuse chain.

Android banking trojans often combine social engineering with device abuse because no single trick is enough on its own. Rotexy follows that pattern by blending fake prompts, permission abuse and interface deception, which lets attackers stay close to the victim’s normal behaviour while extracting the information needed to complete fraud.

For defenders, the practical question is not only whether the device is infected, but whether the malware can still influence user actions after installation. Signs such as accessibility abuse, overlay behaviour and suspicious SMS handling often matter more than the original lure because they indicate the malware is actively shaping what the user sees and approves.

How phishing, overlays and SMS abuse work together

Rotexy typically starts with a lure that persuades the user to install or open a malicious app. Once present, it can present fake overlays that mimic a bank login or security prompt, then collect whatever the victim types into those fields. That is effective because the attacker does not need to break the bank’s real login screen if the user is tricked into entering the same data into a convincing copy.

SMS abuse is especially important because many banking flows still rely on one-time codes delivered to the phone. If the malware can read, intercept or influence SMS handling, it can help an attacker capture or forward verification data in near real time. In practice, the combination of stolen credentials and stolen one-time codes is what makes account takeover and fraudulent transactions much more likely.

The mobile attack path also depends on permission abuse. Rotexy’s success often hinges on getting the victim to grant access that seems harmless in isolation, such as accessibility-related permissions or SMS-related permissions, but which becomes dangerous once the malware can read the screen, suppress prompts or monitor messages. The abuse is not only technical, it is behavioural.

Because the technique depends on user interaction, the window for detection is often short. If defenders can identify the app soon after installation, they may still stop the malware before it completes credential capture or fraudulent payment setup. If not, the attacker may already have enough data to continue off-device.

What to watch for after infection is suspected

Once Rotexy is suspected on a device, the key issue is whether the phone has been used to authenticate, approve payments or receive verification codes since installation. That is the point at which a mobile malware event becomes an account-security event, because the device may have exposed both credentials and transaction authorisation data.

Watch for unusual SMS behaviour, unexpected accessibility service activity, unexplained overlay prompts and app requests that do not fit the app’s stated purpose. A trojan like this often leaves clues in how the device behaves, not just in what files it drops, so user reports about strange prompts or messages should be treated as operational evidence rather than noise.

Suspicious behaviour after installation should also be taken as a signal to review the affected banking sessions, reset relevant credentials and inspect for unauthorised transactions. The malware’s objective is usually not just surveillance, but monetisation, so any confirmed compromise should be treated as a fraud investigation as well as a malware cleanup.

Risk and Threat Considerations

Rotexy is dangerous because it sits between the user and the banking app, which means it can manipulate trust at the exact moment credentials and one-time codes are being entered. The main risk is not simply device compromise, but a full fraud path where stolen secrets and session data are combined to authorise transactions the victim did not intend.

Failure mechanism: The malware abuses overlays, accessibility access and SMS handling to capture or relay authentication material while making the user believe they are interacting with a legitimate banking flow.

Impact: Attackers can obtain credentials, bypass message-based verification, and execute fraudulent transactions with a much higher chance of success than with phishing alone.

Practitioner Guidance

What to verify: Confirm whether the device installed the malicious app, whether accessibility or SMS permissions were granted, and whether any banking sessions, transfers or OTP events occurred after installation. If those conditions line up, treat the case as potential account compromise rather than a simple mobile cleanup.

Decision rule: If the device handled banking authentication after infection, prioritise account protection and fraud containment first, then device remediation. If no financial apps or verification flows were used, the response can focus more narrowly on containment and endpoint cleanup.

Practitioner takeaway: With mobile banking trojans, the decisive question is whether the phone was used as an authentication relay, because that is what turns malware from an endpoint problem into an active fraud event.

Related resources from NHI Mgmt Group

• Why do passwords remain dangerous when attackers use AI to find vulnerabilities?
• How should security teams reduce fraud when attackers use deepfakes and synthetic identities?
• How should security teams handle exposed cloud keys before attackers use them?
• How should organisations reduce business email compromise risk when attackers use generative AI?