What happens when a malicious Android app is granted accessibility and notification access?

Those permissions can give the app broad visibility into what appears on screen and what arrives in notifications, which is enough to support message interception, credential harvesting, and user deception. In a banking or delivery-lure scenario, the malware can overlay fake screens, steal card data, and coordinate with command-and-control servers. That turns a simple install into a full compromise.

Why Accessibility and Notification Access Are So Powerful on Android

Those two permissions are powerful because they let an app observe and influence the user experience far beyond what most apps can see. Accessibility services can read UI content, react to screen changes, and perform actions on the user’s behalf, while notification access exposes incoming alerts, previews, and app activity that may include sensitive prompts or one-time codes.

On their own, neither permission guarantees compromise, but together they create a high-value control plane for surveillance and interaction. A malicious app can watch for banking prompts, payment flows, login screens, and delivery messages, then use that context to decide when to steal data, suppress warnings, or guide the user toward a fraudulent action.

Because these permissions are granted at the operating-system level, the risk is not limited to the app’s visible interface. The app may be able to infer what the user is doing across other apps, which makes it especially effective for credential theft, account takeover, and social engineering that feels local and legitimate rather than obviously malicious.

How Malicious Apps Turn Those Permissions into Fraud

The most common abuse pattern is observation plus intervention. The app monitors sensitive screens or notifications, then overlays a fake login, payment, or verification prompt when the victim reaches a target application. If the user enters data into the fake interface, the malware captures it and can relay it immediately to an attacker-controlled backend.

Notification access is particularly useful because it can reveal messages that other apps rely on for trust or verification, including codes, transaction alerts, and delivery updates. Accessibility access can then be used to read text from the screen, press buttons, dismiss prompts, or keep the victim in a loop long enough to finish the theft before they notice anything unusual.

In practice, this means the app is not merely “watching” the device, it is participating in the session. That participation can be enough to downgrade a user’s ability to spot a fake screen, approve a transfer, or recognise that a message is being intercepted in real time.

What a Compromised Permission Pair Usually Looks Like in Practice

The compromise often starts as a benign-looking lure, such as a utility, loan, shopping, or delivery app that requests special access after installation. Once granted, the malware can wait quietly until it detects a valuable target, then switch to credential harvesting, card capture, or silent manipulation of the user flow.

The practical warning sign is not just the presence of the permissions, but their combination with broad screen-reading behaviour, aggressive overlay use, or repeated attempts to keep accessibility enabled. When those patterns appear together, the app is usually trying to build persistence around the user interface rather than provide a legitimate assistive function.

For incident response, the key question is whether the app had enough visibility to observe secrets or enough interaction capability to alter the session. If the answer is yes, then the exposure should be treated as more than a simple app uninstall; credentials, payment instruments, and related accounts may need review or rotation.

Risk and Threat Considerations

The risk is that a single overgranted Android app can become a durable interception layer for messages, on-screen content, and user actions. That creates a direct path from device compromise to financial fraud, account takeover, and deceptive user interaction.

Failure mechanism: The app abuses accessibility to read interface content and act on the user’s behalf, while notification access reveals sensitive alerts and one-time prompts that help the malware time its fraud.

Impact: Attackers can harvest credentials, capture payment data, suppress warnings, and run convincing overlays that turn one installation into an end-to-end compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1113 — Screen Capture	Accessibility abuse can expose on-screen content for credential theft and fraud.
	T1027 — Obfuscated Files or Information	Malicious Android apps often hide behavior to survive permission scrutiny and analysis.
	T1555 — Credentials from Password Stores	The abuse path often ends in stealing credentials and session material from the user flow.
Recommendation — Map suspicious screen-reading behavior to T1113 and hunt for UI capture patterns. Inspect apps that conceal payloads or code paths for obfuscation indicators. Treat harvested credentials as potential T1555 outcomes and rotate exposed secrets.
CIS Controls v8	CIS-6 — Access Control Management	The question centers on overgranted access that expands device and account exposure.
	CIS-13 — Network Monitoring and Defense	Malicious apps commonly coordinate stolen data with remote command-and-control infrastructure.
Recommendation — Review and restrict apps with accessibility and notification permissions. Monitor for suspicious outbound connections from apps with sensitive permissions.
OWASP ASVS	V6 — Authentication	The abuse path targets login flows, codes, and user authentication prompts.
	V8 — Authorization	Permission abuse changes what the app can do on behalf of the user in other apps.
Recommendation — Harden authentication flows against UI deception and code interception. Limit privileged actions to explicitly justified and reviewable use cases.

Practitioner Guidance

What to verify: Treat any app that requests accessibility or notification access as high scrutiny unless the business function clearly depends on it. Verify whether the requested capability matches a legitimate assistive use case, and look for secondary signals such as overlay prompts, repeated permission nudges, or instructions to disable device protections.

Escalation / exception: If a user has already granted both permissions to an untrusted or recently installed app, assume the device may have been used to observe sensitive data. Prioritise credential resets, payment review, and account session invalidation before trusting the device again.

Practitioner takeaway: The dangerous part is not just visibility, but the combination of observation and on-device action, which lets malware copy, time, and shape the user journey in real time.