AN1764: Analytic 1764
The defender correlates Android screen-capture-capable behavior from an app identity with runtime context showing that foreground content from another app is being captured outside expected user-driven workflows. The strongest Android evidence is MediaProjection-like capture initiation, accessibility-assisted observation of foreground UI content, or privileged screencap or screenrecord behavior, followed by screenshot or video artifact creation, buffer growth, or outbound transfer. The detection is strengthened when the capturing app is backgrounded, operates as a foreground service without clear user-driven recording intent, captures while another sensitive app is foregrounded, runs with accessibility or elevated access inconsistent with its role, or performs capture without recent user interaction.
Analyst context for executives and security teams
This analytic matters because unauthorized or poorly governed Android screen capture can expose sensitive business workflows, credentials, messages, approvals, or customer data shown in another app. For leaders, the practical question is not just whether screen recording exists, but whether the organization can distinguish expected user-driven capture from background, accessibility-assisted, privileged, or suspicious capture behavior.
Executive priority
Prioritize this where Android devices handle sensitive apps, regulated data, identity workflows, executive communications, or operational processes. The decision value is in validating whether mobile security monitoring can produce evidence that an app captured foreground content outside an expected workflow, especially when another sensitive app was active. This supports incident response scoping, compliance evidence, mobile risk management, and control decisions around accessibility permissions, foreground services, and elevated device access.
Technical view
For Android, defenders should validate whether telemetry can correlate an app identity with screen-capture-capable behavior and runtime context. Key context includes MediaProjection-like capture initiation, accessibility-assisted observation of foreground UI content, privileged screencap or screenrecord behavior, screenshot or video artifact creation, buffer growth, outbound transfer, app foreground/background state, foreground service use, recent user interaction, and whether another sensitive app was foregrounded during capture. ATT&CK provides no separate detection logic field and no relationship context for this object, so local implementation must define expected workflows and sensitive-app context.
Likely telemetry
- Android app identity and package metadata
- MediaProjection-like screen capture initiation events where available
- Accessibility service enablement and accessibility-assisted UI observation indicators
- Privileged screencap or screenrecord command/activity evidence where available
- Screenshot or video artifact creation metadata
Detection direction
- Correlate capture-capable behavior with app identity, foreground/background state, recent user interaction, and the foreground app being captured.
- Tune for cases where the capturing app is backgrounded, runs as a foreground service without clear user-driven recording intent, or captures while another sensitive app is foregrounded.
- Review apps with accessibility or elevated access that is inconsistent with their business role.
- Look for capture artifact creation followed by buffer growth or outbound transfer as strengthening context, not as standalone proof of misuse.
- Account for benign screen recording, conferencing, support, testing, accessibility, and device management workflows to reduce false positives.
Mitigation priorities
- Define approved Android screen recording, remote support, accessibility, and device management use cases before tuning detections.
- Restrict or review accessibility and elevated access for apps whose roles do not require them.
- Apply mobile device and application governance to limit unapproved apps on devices that access sensitive workflows.
- Prioritize monitoring around sensitive business, identity, financial, messaging, and operational apps where screen content exposure would create material risk.
- Ensure incident response playbooks can collect app identity, permissions, foreground-app context, artifacts, and outbound transfer evidence from Android devices.
Analyst notes and limits
This is a mobile ATT&CK detection analytic for Android, external ID AN1764, tied to DET0668. The supplied object provides a strong behavioral description but no official detection text, tactics, or relationships. Treat this as guidance for validating Android mobile telemetry and control coverage rather than as a ready-to-run detection rule.
No relationships, tactic mapping, aliases, labels, or official detection logic were supplied. The analytic does not by itself prove malicious activity; local baselines, approved workflows, device management coverage, and available Android telemetry determine practical detection quality.
Analytic 1764
The defender correlates Android screen-capture-capable behavior from an app identity with runtime context showing that foreground content from another app is being captured outside expected user-driven workflows. The strongest Android evidence is MediaProjection-like capture initiation, accessibility-assisted observation of foreground UI content, or privileged screencap or screenrecord behavior, followed by screenshot or video artifact creation, buffer growth, or outbound transfer. The detection is strengthened when the capturing app is backgrounded, operates as a foreground service without clear user-driven recording intent, captures while another sensitive app is foregrounded, runs with accessibility or elevated access inconsistent with its role, or performs capture without recent user interaction.
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 | ac388a0f9d3c… |
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 AN1764Open 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.