Notifications carry one-time codes, message previews and payment alerts, so an app that can read them can take over accounts without ever opening another app. MITRE ATT&CK for Mobile tracks this as T1517 Access Notifications, under Collection and Credential Access. ATT&CK v20 lists it for Android only. The technique covers reading notification content, dismissing notifications so the user does not see them, and triggering their action buttons. This guide explains how it works, what real malware has done with it, and the platform, policy, app design and detection controls that limit it. It is for mobile security engineers, identity teams that send codes to phones, MDM administrators and fraud teams. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- It is a credential access technique. ATT&CK lists T1517 under Credential Access because notifications often hold one-time codes sent by SMS, email or apps.
- Read, hide and act. Malware can read content, dismiss the notification so the user never sees it, and press action buttons such as Direct Reply.
- Android 15 narrows it. Untrusted apps implementing
NotificationListenerServiceno longer receive unredacted content from notifications where Android detects a one-time code. - Design codes out. ATT&CK's developer mitigation is simply not to put sensitive data in notification text; phishing-resistant authentication removes the code altogether.
- Work profiles have a dedicated control.
setPermittedCrossProfileNotificationListenerslimits which personal-side apps can read work notifications.
How the technique works
ATT&CK describes adversaries collecting data from notifications sent by the operating system or other apps, intercepting one-time codes, dismissing notifications to hide them, and triggering notification action buttons. Procedure examples show three access routes on Android:
| Route | Example in ATT&CK | What it yields | Primary control |
|---|---|---|---|
| Notification listener service | FlixOnline requested access to NotificationListenerService to manipulate notifications | All posted notifications, plus the ability to cancel them and use action buttons | Notification access is a special user grant; Android 15 OTP redaction for untrusted listeners; cross-profile listener policy |
| Accessibility service | Hornbill and Sunbird scraped notifications through accessibility abuse | Notification text shown on screen | permittedAccessibilityServices allow list; restricted settings |
| SMS receiver | Chameleon registered an SMS broadcast receiver to monitor incoming SMS | SMS content, including codes, before or alongside the notification | SMS permission scrutiny in app vetting; moving away from SMS codes |
T1517 sits next to Mobile T1513 Screen Capture and Mobile T1516 Input Injection: the same malware often reads the code from a notification, hides it, and then types it into the target app.
Real cases from ATT&CK procedure examples
ATT&CK v20 maps 14 malware families and one campaign to T1517. A representative set, as ATT&CK and its cited reports describe them:
| Software or campaign | Recorded behaviour |
|---|---|
| SharkBot | Intercepted notifications for its C2 server and took advantage of the Direct Reply feature |
| Mandrake | Captured all device notifications and hid notifications from the user |
| S.O.V.A. | Silently intercepted and manipulated notifications |
| FluBot | Accessed app notifications |
| Corona Updates | Collected messages from several messaging apps by reading notification content |
| SpyC23 | Read notifications from apps and connected wearables |
| VajraSpy | Monitored and exfiltrated notifications from messaging apps and SMS |
| Campaign C0033 (PROMETHIUM, StrongPity) | Collected message notifications from 17 applications |
The mix matters: banking trojans use the technique to steal and hide codes, while surveillanceware uses it as a cheap way to read encrypted messengers, because the notification preview is already decrypted.
Platform protections on Android
- Notification access is a special grant: a listener only works after the user enables it for that app in Settings, so app vetting should treat any request for notification access as high risk.
- Restricted settings (Android 13 and later): sensitive settings stay locked for newly installed apps until the user chooses "Allow restricted settings" on the app's info page. Google's help page uses accessibility as its example.
- OTP redaction (Android 15): Android stops untrusted apps that implement
NotificationListenerServicefrom reading unredacted content from notifications where it detects a one-time code. Trusted apps, such as companion device manager associations, are exempt. - Screen share protection (Android 15): notification content is hidden during screen sharing; if the app sets
setPublicVersion(), the public version is shown instead.
OTP redaction depends on Android detecting the code. It does not help on older Android versions, against accessibility-based reading, or for codes that are not recognised as codes, so it is a layer rather than a fix.
Prevention through policy and app design
ATT&CK lists three mitigations for T1517: M1011 User Guidance, M1012 Enterprise Policy and M1013 Application Developer Guidance.
| Owner | Control | Detail |
|---|---|---|
| MDM team | Cross-profile notification listeners | On devices with a work profile, DevicePolicyManager.setPermittedCrossProfileNotificationListeners controls which personal-profile apps can read work-profile notifications; ATT&CK notes it does not affect notifications from the personal profile |
| MDM team | Accessibility allow list | permittedAccessibilityServices in the Android Management API closes the accessibility route |
| MDM team | App sources | untrustedAppsPolicy and googlePlayProtectVerifyApps under advanced security overrides |
| App developers | Notification content | Keep sensitive data out of notification text, as ATT&CK advises; use a generic "You have a new message" with a public version for locked or shared screens |
| Identity team | Authentication method | Replace SMS and push-with-code flows with passkeys or number-matched push where possible, so there is no code to steal |
| Users | Grant scrutiny | Refuse notification access for apps that do not obviously need it, such as games or utilities |
The OWASP MASVS-PLATFORM category names one-time passwords in notifications as a leakage path that app teams should prevent. For code-based flows that must stay, the OTP security guide covers binding codes to the transaction and short lifetimes.
Detection and measurement
ATT&CK's detection strategy for T1517 (Detection of Access Notifications) correlates:
- Permission state: grant state and requested permissions from the DPC or app vetting, such as notification listener declarations or SMS receive permissions.
- Application state: managed package inventory and metadata from Android Enterprise or the EMM.
- Runtime traces from app vetting: an app reading notification content from high-value sources, such as banking, authenticator or messaging apps, while it runs in the background.
Identity and fraud telemetry adds the other half: a code used from a new device seconds after it was sent, or a user reporting that an expected code never arrived (a sign it was dismissed). Metrics:
- Number of managed devices with a non-approved app holding notification access.
- Percentage of work profiles with a cross-profile notification listener policy set.
- Share of logins and approvals still using SMS or notification-delivered codes, trended down.
- Count of "code not received" reports followed by a successful login from a new device.
- Share of your own apps' notifications that pass a review for sensitive content.
Mobile threat defence agents can surface listener and accessibility grants as risky-app findings; see the Mobile Threat Defense Buyer's Guide.
Where identity fits
T1517 is an identity attack on a phone. Any code delivered to a notification is only as safe as every app with notification access on that device. That applies to workforce MFA, customer account recovery, and machine-to-human flows such as approval prompts for privileged or CI/CD actions sent to an administrator's phone. Move privileged approvals to phishing-resistant methods and avoid putting secrets, tokens or links that grant access into notification text. See the Authenticator Apps and OTP Guide.
Response
- Assume codes are exposed: revoke sessions and refresh tokens for accounts used on the device, and review recent logins, new trusted devices and recovery changes.
- Remove the access: quarantine the device through MDM; revoke notification access and accessibility grants, or wipe.
- Preserve: record the app inventory and grants before wiping; for targeted users, use the Mobile Verification Toolkit (MVT) and the Mobile Spyware Infection Response Playbook.
- Fix the method: move affected users off code-based MFA where possible.
Framework mapping
| Framework | Reference | Relevance to T1517 |
|---|---|---|
| ATT&CK Mobile mitigations | M1011; M1012; M1013 | Grant scrutiny; cross-profile listener and accessibility policy; no sensitive data in notifications |
| NIST SP 800-53 Rev 5 | AC-19 Access Control for Mobile Devices; IA-2 Identification and Authentication (Organizational Users); CM-11 User-installed Software; SI-4 System Monitoring | Device policy, authentication strength, app installs, monitoring |
| NIST CSF 2.0 | PR.PS-01; DE.CM-09 | Configuration management; runtime monitoring |
| OWASP MASVS | MASVS-PLATFORM | One-time passwords in notifications as a leakage path |
Common failure patterns
- Codes in the preview: notifications that show the full code on the lock screen or to any listener.
- Counting on OTP redaction: it applies from Android 15, only to untrusted listeners and detected codes; older devices and accessibility-based reading are unaffected.
- No cross-profile policy: work notifications readable by any personal-profile listener.
- SMS as the privileged factor: administrators approving high-risk actions with SMS codes on devices that also run unvetted apps.
- Ignoring "code never arrived": support teams resend codes without checking whether the first was used.
Practitioner checklist
- Set a cross-profile notification listener policy on every Android work profile.
- Enforce an accessibility allow list and block unknown app sources.
- Treat notification access and SMS receive permissions as high-risk in app vetting.
- Remove codes and sensitive data from your own apps' notification text; provide public versions.
- Plan the move from SMS and notification codes to passkeys for workforce and privileged users.
- Correlate code delivery with code use from new devices in identity telemetry.
- Brief users on refusing notification access to apps that do not need it.
Standards and references
- MITRE ATT&CK: Access Notifications (Mobile T1517)
- Android Developers: Android 15 behaviour changes for all apps
- Google: Android Management API policies reference
- Google: Allow restricted settings
- OWASP: Mobile Application Security Verification Standard
- Mobile Verification Toolkit documentation
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · OTP security · Android Banking Trojans Guide · Android Enterprise Security Guide