AN1665: Analytic 1665
An application is granted or maintains notification listener access, observes notification content from other applications (including sensitive sources such as SMS/email/2FA apps), processes or stores notification payloads, and optionally suppresses or programmatically interacts with notifications (dismiss/action triggers) without corresponding foreground user interaction. Detection correlates special access permission state + notification event interception + application background state + downstream data use (local write or network transmission).
Analyst context for executives and security teams
This Android detection analytic focuses on apps that have notification listener access and use it to observe notification content from other applications, including potentially sensitive sources such as SMS, email, or two-factor authentication apps. For security leaders, the practical issue is not just the permission itself; it is whether the organization can tell when an app with special notification access is running in the background, reading notification payloads, storing them, transmitting them, or interacting with notifications without visible user action.
Executive priority
Prioritize this as a mobile identity and data-exposure control question. Notification content can carry business-sensitive messages, authentication prompts, and one-time codes, so unmanaged or poorly monitored Android devices may create blind spots for account protection, incident scoping, and compliance evidence. Leaders should ask whether mobile device governance, app review, and SOC telemetry can identify which Android apps hold notification listener access and whether that access is consistent with business need.
Technical view
For SOC, mobile security, and IR teams, validation should center on correlating four evidence points described by the analytic: Android notification listener permission state, notification interception activity, application background state, and downstream handling of notification payloads such as local writes or network transmission. Because no official detection logic is provided, teams should treat this as a detection design requirement rather than a ready rule. Benign apps may legitimately use notification listener access, so triage should consider app purpose, foreground user interaction, enterprise approval status, and whether notification data is stored or sent externally.
Likely telemetry
- Android app special access / notification listener permission state
- Mobile device management or endpoint inventory showing installed applications and granted permissions
- Notification listener or notification event access records where available
- Application foreground/background state
- Local file or database writes by the application involving notification-derived content where available
Detection direction
- Inventory Android applications with notification listener access and compare them against approved business use cases.
- Correlate permission state with evidence of notification content access, especially while the app is in the background.
- Look for downstream handling of notification payloads, including local storage or network transmission, rather than alerting on permission alone.
- Tune for expected accessibility, automation, productivity, or enterprise management apps to reduce false positives.
- Investigate cases where notifications are dismissed or acted on programmatically without corresponding foreground user interaction, if telemetry is available.
Mitigation priorities
- Restrict notification listener access to applications with a documented business need on managed Android devices.
- Use mobile device management or equivalent governance to inventory installed apps, permissions, and special access settings.
- Review and approve applications that can access sensitive notification sources such as SMS, email, or authentication apps.
- Minimize sensitive content displayed in notifications where operationally feasible.
- Include notification listener access checks in mobile incident response and compliance evidence collection.
Analyst notes and limits
This take is based on ATT&CK mobile analytic AN1665 for Android. The object provides a behavioral description but no official detection text, no tactics, and no relationship context. The strongest defensive value is in turning the described correlation points into mobile telemetry requirements and governance checks.
No active exploitation, adversary attribution, specific malware, impact outcome, or production-ready detection logic is supplied in the official fields. Local Android management capabilities, device ownership model, app inventory quality, and available mobile telemetry will determine whether this behavior can be detected or only assessed through configuration review.
Analytic 1665
An application is granted or maintains notification listener access, observes notification content from other applications (including sensitive sources such as SMS/email/2FA apps), processes or stores notification payloads, and optionally suppresses or programmatically interacts with notifications (dismiss/action triggers) without corresponding foreground user interaction. Detection correlates special access permission state + notification event interception + application background state + downstream data use (local write or network transmission).
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 631fb0d2584c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1665Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.