Security teams detect Fakecalls by watching for Android malware that intercepts or imitates phone calls, especially on devices used for banking or identity checks. Look for suspicious call-screen overlays, abnormal phone permissions, and calls that appear connected but do not behave normally. Isolate the device, remove the app, and verify any captured credentials or codes.
What Fakecalls infections tend to look like in practice
Fakecalls is a mobile banking trojan pattern, so detection usually starts with behaviour, not a single signature. Security teams should treat the malware as suspicious when an Android device shows call-handling tricks, permission abuse, or a banking app that behaves normally in the foreground but differently during a phone call or verification flow. A practical baseline is to compare the phone’s behaviour against a known-good device used for the same service.
One useful indicator is call interception or imitation. If the device shows a call screen that seems connected but the audio path, timing, or UI transitions do not match a genuine carrier call, that is a strong clue. Another is overlay activity around banking or identity checks, where the malware can place a fake screen on top of the legitimate app to steal codes, PINs, or responses.
Teams should also watch for abnormal Android permissions, especially anything that allows call control, accessibility abuse, notification reading, overlay display, or device administration. Those permissions are not proof on their own, but they become meaningful when paired with unusual app origin, sideloading, or a user report that a phone call or verification step “looked right” but failed in a subtle way.
How to confirm a suspected Fakecalls device
Confirmation is usually a combination of endpoint inspection and user-context validation. Start by isolating the handset from enterprise and banking workflows, then review installed apps, recent installs, and any app that requested broad access but does not obviously need it. If possible, compare the device against your mobile threat tooling or mobile device management telemetry to see whether the same app has unusual launch, permission, or UI behaviour across multiple devices.
For investigation depth, focus on whether the device is actually manipulating the call path or just using a look-alike screen. Try to reproduce the behaviour in a controlled way: does the call appear connected, then fail to route normally, or does it prompt the user in a way that does not match the bank or telecom process? If the malware captured one-time codes or login material, treat that as a credential exposure event rather than only a malware event.
The most reliable evidence is usually behavioural plus corroborating artefacts, such as suspicious overlay permissions, a suspicious APK source, device administration changes, or repeated anomalies during authentication and support calls. For broader mobile-malware hunting patterns and Android-specific abuse techniques, the Mobile Malware Guide is the most directly relevant reference in the NHIMG corpus.
Containment, recovery, and what to verify after cleanup
Once a device is suspected, contain it first and clean it second. Remove the malicious app only after the handset is removed from any trusted workflow, because the immediate risk is not just persistence, it is continued interception of calls, codes, and identity checks. If the device was used for banking, treat any captured password, OTP, passcode, or support verification as potentially exposed and verify whether those credentials are still valid elsewhere.
Recovery should include a targeted review of recent account activity, including banking app sessions, password resets, MFA changes, and any support interactions that could have been socially engineered using the fake call channel. If the same phone number, device, or app has been used for high-value approvals, it is reasonable to assume the attacker may have tried to extend access beyond the original infection window.
On the defensive side, teams should preserve enough evidence to explain how the app entered the device in the first place, then use that finding to harden future controls. That usually means tightening app allowlisting, reducing sideloading tolerance, and making sure users know that a genuine bank or help-desk call will not require them to approve unusual prompts or install a companion app mid-conversation. For mobile attacker behaviour, the MITRE ATT&CK Enterprise Matrix is useful for mapping call interception, credential access, and follow-on abuse to a broader detection strategy.
Risk and Threat Considerations
Fakecalls is dangerous because it attacks trust at the exact moment users are asked to prove identity or authorise a transaction. The main risk is not only theft of credentials, but the ability to shape what the victim sees and hears during a call, which can defeat normal suspicion and make fraudulent verification feel routine.
Failure mechanism: The malware abuses Android permissions and UI deception to intercept phone-based trust flows, then uses that position to capture one-time codes, passwords, or account recovery details before the user realises the interaction is fraudulent.
Impact: A compromised device can enable account takeover, fraudulent approvals, and secondary compromise of any service that still relies on phone-call verification or voice-based support workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1110 — Brute Force | Fakecalls targets authentication flows and code capture during login and verification. |
| Recommendation — Correlate call-time anomalies with credential access and authentication abuse techniques. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Detecting Fakecalls depends on mobile malware detection and containment controls. |
| Recommendation — Apply malware defenses to identify, isolate, and remove malicious Android apps. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Fakecalls detection depends on monitoring suspicious software and device behaviour. |
| Recommendation — Monitor mobile devices for unauthorized apps, overlays, and abnormal call behaviour. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Fakecalls is Android malware, so malware protection and detection controls apply directly. |
| Recommendation — Deploy malicious code protection to detect and contain infected mobile devices. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Fakecalls can steal OTPs and credentials through fake call and overlay flows. |
| Recommendation — Treat captured codes and credentials as leaked secrets and rotate them promptly. | ||
Practitioner Guidance
What to verify: Do not treat “removed the app” as the end state. Verify whether the exposed account still has active sessions, whether MFA or recovery methods changed during the infection window, and whether any other device or browser session could now be trusted by the attacker.
Decision rule: If the malware touched a device used for banking, customer identity verification, or recovery flows, prioritise credential and session review before reinstating the handset. If the infection was confined to a low-value personal device with no sensitive authentication use, cleanup can be narrower, but still confirm no sensitive codes were entered during the compromise period.
Practitioner takeaway: Fakecalls is best handled as a trust-path compromise, not just a mobile malware cleanup, because the real security question is whether the attacker captured or redirected the user’s proof of identity during the call.