AN1808: Analytic 1808
The defender correlates Android camera access by an app identity with app and device context showing that the capture is inconsistent with expected user-driven recording behavior. The strongest Android evidence is camera resource access followed by sustained capture duration, video or image artifact creation, buffer or cache growth, and optional outbound transfer, especially when the app is backgrounded, operating as a foreground service without visible user initiation, active while the device is locked, or capturing without recent user interaction. The detection is strengthened when the app is unmanaged, recently granted camera access, or not approved to record video.
Analyst context for executives and security teams
AN1808 is a mobile detection analytic for identifying Android apps that may be using the camera in ways that do not match normal, user-driven recording behavior. Its business value is in validating whether the organization can spot unauthorized or unexpected camera capture on managed or monitored Android devices, especially where mobile devices are used in sensitive meetings, operational environments, regulated workflows, or executive travel.
Executive priority
Leaders should treat this as a privacy, compliance, and operational trust control validation rather than a generic malware alert. The key decision is whether Android camera access is visible enough to distinguish approved recording from suspicious capture, such as activity while the device is locked, backgrounded, recently permissioned, or unmanaged. This can inform mobile device management policy, app approval processes, incident response readiness, and evidence for privacy/security governance.
Technical view
For SOC, mobile security, and IR teams, the analytic depends on correlating Android camera resource access with app identity, device state, user interaction, permission history, and artifact or data movement signals. Validate whether telemetry can show sustained camera use, image/video artifact creation, buffer or cache growth, foreground service behavior, locked-screen activity, recent camera permission grants, and whether the app is approved or managed. Because no ATT&CK tactic or relationship context is supplied, teams should use this as a detection engineering validation item rather than infer a specific adversary campaign or technique chain.
Likely telemetry
- Android app identity and package metadata
- Camera resource access events
- Camera permission grant history
- Foreground/background app state
- Foreground service state and user-visible initiation context
Detection direction
- Correlate camera access with context rather than alerting on camera use alone, since legitimate apps may record video or images.
- Prioritize higher-confidence cases where camera access is sustained and paired with artifact creation, cache growth, locked-device activity, background operation, or no recent user interaction.
- Tune separately for approved recording apps versus unmanaged, newly installed, or recently permissioned apps.
- Validate whether Android telemetry preserves enough timing detail to connect camera access, user interaction, device state, and file/cache changes.
- Treat outbound transfer as strengthening context, not a required condition, because the official description lists it as optional.
Mitigation priorities
- Review and enforce Android camera permission governance for managed devices and approved apps.
- Restrict or monitor unmanaged apps that request camera access, especially shortly after installation or permission changes.
- Use mobile management policy to maintain an inventory of apps approved to record video or capture images.
- Ensure incident response playbooks include preservation of mobile app, permission, file artifact, and device-state evidence.
- For sensitive business areas, define policy expectations for camera use on Android devices and align monitoring to those expectations.
Analyst notes and limits
This object is a detection analytic, not a technique, and the supplied fields contain no tactic, relationship, attribution, or active exploitation context. The useful defensive takeaway is the correlation model: camera access becomes materially suspicious when combined with app/device context that contradicts expected user-driven recording.
Official detection text is not provided, and no relationships are supplied. Local Android telemetry availability, MDM coverage, app inventory quality, and privacy/legal constraints will determine whether this analytic can be implemented effectively.
Analytic 1808
The defender correlates Android camera access by an app identity with app and device context showing that the capture is inconsistent with expected user-driven recording behavior. The strongest Android evidence is camera resource access followed by sustained capture duration, video or image artifact creation, buffer or cache growth, and optional outbound transfer, especially when the app is backgrounded, operating as a foreground service without visible user initiation, active while the device is locked, or capturing without recent user interaction. The detection is strengthened when the app is unmanaged, recently granted camera access, or not approved to record video.
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 | 7e07dcc746ea… |
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 AN1808Open 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.