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

What does accessibility access actually let a malicious Android app observe?

Accessibility services are designed to help users interact with the device, but in the hands of malware they can expose a great deal of live UI state. That includes text on screen, control labels, focus changes, button presses, and the structure of active app windows. Notification access adds a second stream of sensitive context, because alerts often contain verification codes, account activity, delivery prompts, and security messages.

That combination matters because the app does not need to break encryption or defeat the operating system outright. It can simply watch what the user sees and infer when a banking app, payment screen, or messaging app is active. From there, the malware can decide when to steal information, when to hide itself, and when to present a convincing fake overlay.

Mobile app security testing guidance is relevant here because overlay abuse, runtime abuse, and UI tampering are all observable behaviours in a realistic Android assessment.

How do attackers turn those permissions into account theft?

The usual pattern is staged and opportunistic. First, the malware waits for high-value activity such as a login, a payment confirmation, or a one-time code. Then it can read notification content, capture credentials typed into apps, and present overlays that imitate the legitimate app or a system prompt. That is why the direct permission abuse so often ends in credential harvesting rather than simple spying.

In mobile banking and delivery-themed lures, the attacker often relies on trust. A fake screen can ask for card details, PINs, recovery codes, or an immediate re-authentication step, while the real app remains in the background. The malware may also suppress or dismiss legitimate notifications so the victim sees only the attacker’s prompt. The practical effect is session theft plus user deception, not just passive monitoring.

OAuth Token Theft Incident Playbook is useful for the response pattern once stolen sessions, tokens, or app grants are suspected, even though the initial foothold started on mobile.

Consent Phishing and Illicit OAuth Grants Guide also maps well to the trust abuse pattern, because the same social-engineering logic often appears when a malicious app or prompt is trying to obtain durable access.

Why this permission pair creates a full-compromise path

The dangerous part is not either permission alone, but the way they combine. Accessibility gives the app interaction authority inside the device, while notification access gives it a real-time feed of the user’s inbound security signals. Together they can support interception, timing, impersonation, and persistence. That is enough to move from a single malicious install to a broader compromise of accounts, messages, and payment flows.

Once a user is conditioned to accept the attacker’s prompts, the malware can keep going even after the initial campaign window closes. It may re-open itself after updates, wait for new notification content, or present another fake screen when the victim launches a financial app. In practice, this is how a seemingly ordinary Android permission grant becomes a durable control point over the victim’s sessions and decisions.

Mobile app security testing guidance helps teams verify whether a suspicious app is using overlay, input capture, or runtime manipulation techniques that would explain unexpected user-interface behaviour.

Risk and Threat Considerations

These permissions create a high-trust foothold because they let malware observe both human interaction and sensitive system messages. The main risk is not just data exposure, but the attacker’s ability to steer the victim into giving up fresh credentials, approving transactions, or accepting false recovery steps while the real app remains available.

Failure mechanism: The app abuses accessibility events and notification content to time overlays, capture secrets, and impersonate trusted app screens or system prompts.

Impact: Stolen credentials, fraudulent transactions, account takeover, and follow-on abuse of any session or token the victim exposes after the install.

Practitioner Guidance

What to verify: If a suspicious Android app was granted accessibility and notification access, verify whether it also requested overlay, SMS, device admin, or battery exemption privileges. Those combinations often indicate a campaign built for persistence and user deception rather than a benign accessibility use case.

What practitioners underestimate: Notification content can be enough to make the attack work even when the malware never breaks app encryption or roots the device. From a response perspective, that means suspicious app removal alone is not enough if the same credentials, recovery channels, or financial account sessions remain valid elsewhere.

Practitioner takeaway: Treat accessibility plus notification access as a live interaction channel into the victim’s device, and assume any exposed credential, code, or session may already have been used or copied.

Related resources from NHI Mgmt Group

• What happens when an Android app can combine overlay access with accessibility permissions?
• What happens when users grant a malicious OAuth app access to GitHub repositories and workflows?
• What happens when a malicious OAuth app gets access to trusted business systems?
• What happens when users grant a malicious verified OAuth app access to their accounts?