Fakecalls

How Fakecalls Works

Fakecalls is Android malware that masquerades as an incoming or outgoing phone call, creating a convincing decoy while the malicious app carries out activity the user should not notice. That deception matters because it turns the phone’s call experience into cover for fraud, interception, or other hidden actions.

The core trick is not the call itself, but the trust users place in a normal-looking dialler event. By manipulating call-related behaviour, the malware can make suspicious activity look routine, which lowers the chance that the user interrupts it or realises another app is involved.

Why This Malware Is Effective

Fakecalls succeeds because mobile users are trained to trust system-level call alerts and call UI transitions. When malware can imitate those signals, it can borrow the authority of a familiar system function and hide in plain sight.

That style of deception is especially dangerous on Android, where malicious apps may request permissions that let them observe calls, draw over other apps, or interfere with user interactions. The result is a blend of social engineering and technical abuse: the screen shows one story while the device performs another.

NHIMG’s Mobile Malware Guide is the best broader reference for how Android malware families use overlay tactics, accessibility abuse, and user evasion to stay effective.

Detection and Exposure Clues

Defenders should treat unexpected dialler activity as a strong warning sign, especially when it appears alongside unusual permission requests or inconsistent call behaviour. If a device shows call screens that do not match the user’s actions, the malware may be manipulating the phone’s telephony workflow rather than merely displaying a harmless popup.

Exposure often comes from a combination of mobile malware delivery and user trust. A malicious app can appear to be a legitimate utility, then use system permissions or interface abuse to stage the fake call behaviour. That means exposure review should focus on installed apps, permission drift, and whether any app is able to interact with calling features in a way that is unnecessary for its stated purpose.

For a broader threat-model view of mobile attack techniques, the MITRE ATT&CK Enterprise Matrix helps defenders map abuse patterns to detection logic, while the NIST SP 800-53 Rev 5 Security and Privacy Controls provides control coverage for monitoring, access restrictions, and system integrity.

How Defenders Should Respond

When Fakecalls is suspected, the practical response is to isolate the device, review recently installed apps, and assess whether call-related permissions or accessibility features were granted without a clear business need. The key question is whether another app has gained enough control to impersonate or manipulate the phone’s call experience.

Because the malware can be used to mask fraud or interception, responders should also consider the identity impact of a compromise. If call handling, communications, or authentication workflows were exposed, any associated credentials, tokens, or sessions that may have been observed or abused should be reviewed and rotated where appropriate.

Use NIST Cybersecurity Framework 2.0 for a broader detect-and-respond structure, and consult the OWASP API Security Top 10 only where mobile apps or backend services are being abused through exposed interfaces or broken access decisions.

Risk and Threat Considerations

Fakecalls is risky because it turns a trusted phone function into a cover mechanism for malicious activity. The deception can hide fraud, suppress user suspicion, and delay response long enough for the attacker to complete theft, surveillance, or manipulation.

Failure mechanism: The malware abuses the user’s expectation that call events are benign and visible, then overlays or imitates call-related behaviour to conceal what another app is doing underneath.

Impact: This can enable stealthy fraud, interception of sensitive interactions, and delayed detection of a compromised device, especially when the user assumes the call screen is genuine.