AN1719: Analytic 1719
From the defender view: an app registers a clipboard listener or calls ClipboardManager getters; the app is (a) foreground, (b) the default IME, or (c) abusing legacy paths. Shortly after each clipboard change, the app reads the primary clip repeatedly, optionally persists content (local file/DB) and/or exfiltrates it. We correlate: listener/clip-access → privilege/foreground confirmation → bursty reads → local write and/or network egress within a tight window.
Analyst context for executives and security teams
This analytic is about identifying Android apps that monitor or repeatedly read clipboard contents soon after clipboard changes, then potentially store or send that content elsewhere. For leaders, the business issue is not the clipboard API itself; it is that users often copy passwords, MFA codes, recovery phrases, customer data, or business text into the clipboard. If mobile visibility is weak, this behavior can become an unmeasured data-loss and identity-risk blind spot.
Executive priority
Prioritize this as a mobile security and identity-protection validation item where Android devices are used for business access. Security leaders should ask whether managed mobile devices can provide evidence of suspicious clipboard access, foreground/default input method status, local persistence, and network egress. The decision value is strongest for organizations that rely on mobile access to email, SaaS, privileged workflows, or regulated data, because clipboard misuse can undermine identity controls and create compliance-evidence gaps.
Technical view
For Android, validate whether telemetry can support the correlation described by the ATT&CK analytic: clipboard listener registration or ClipboardManager getter use, confirmation that the app is foreground or the default IME, repeated reads of the primary clip shortly after clipboard changes, and local file/database writes or network egress within a tight time window. Since no separate official detection logic is provided, SOC and detection engineering teams should treat the description as the analytic specification and test whether their mobile, EDR/MDM, application, and network data can actually reconstruct that sequence.
Likely telemetry
- Android application behavior related to clipboard listener registration and ClipboardManager getter calls
- App foreground/background state around the time of clipboard changes
- Default IME/input method status for the app involved
- Clipboard change timing and repeated primary-clip read events, where available
- Local file or database write activity by the app after clipboard reads
Detection direction
- Correlate clipboard access with app state; clipboard reads by a foreground app or default IME may be expected, while repeated bursty reads followed by storage or egress is more concerning.
- Tune detections around timing windows after clipboard changes rather than single API calls, because isolated clipboard access can be benign.
- Validate whether legacy Android paths or incomplete mobile telemetry create blind spots in clipboard access visibility.
- Review false positives from legitimate password managers, keyboards, productivity apps, and enterprise apps that intentionally process clipboard content.
- Use network and local persistence signals to increase confidence when direct clipboard telemetry is limited.
Mitigation priorities
- Establish mobile telemetry requirements first: confirm whether managed Android devices can report app identity, foreground/default IME status, clipboard-related behavior, local writes, and app network activity.
- Restrict business access from unmanaged or low-visibility Android devices where clipboard-sensitive workflows are common.
- Review and govern approved keyboards, password managers, and apps with legitimate clipboard use to reduce ambiguity during investigations.
- Use mobile application risk review and policy enforcement to limit untrusted apps that request or exhibit sensitive clipboard behavior.
- Include clipboard-related mobile evidence in incident response and compliance readiness playbooks where copied credentials, tokens, or regulated data are plausible.
Analyst notes and limits
ATT&CK supplies this as a mobile detection analytic for Android with a defender-view behavioral correlation. There are no supplied tactics, relationships, aliases, or separate official detection text. The practical value is in validating whether local telemetry can connect clipboard access, app privilege/context, repeated reads, persistence, and egress into one investigation chain.
This take is limited to the supplied ATT&CK analytic fields and external reference. It does not establish active exploitation, actor attribution, prevalence, customer exposure, or guaranteed detectability. Local Android version, device-management posture, mobile security tooling, app inventory, and privacy/logging constraints will determine whether the analytic can be implemented effectively.
Analytic 1719
From the defender view: an app registers a clipboard listener or calls ClipboardManager getters; the app is (a) foreground, (b) the default IME, or (c) abusing legacy paths. Shortly after each clipboard change, the app reads the primary clip repeatedly, optionally persists content (local file/DB) and/or exfiltrates it. We correlate: listener/clip-access → privilege/foreground confirmation → bursty reads → local write and/or network egress within a tight window.
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 | f5202937ee19… |
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 AN1719Open 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.