DET0695: Detection of Video Capture
This detection strategy is about finding mobile device camera abuse associated with ATT&CK technique T1512, Video Capture. The business issue is not just p...
Analyst context for executives and security teams
This detection strategy is about finding mobile device camera abuse associated with ATT&CK technique T1512, Video Capture. The business issue is not just privacy: unauthorized video or image capture can expose sensitive conversations, facilities, regulated information, customer data, or operational environments. Because the ATT&CK detection object itself has no official detection text, teams should treat this as a validation prompt: confirm whether mobile security monitoring can show camera access, media file creation, and later movement or exfiltration on Android and iOS devices where those platforms are in scope.
Executive priority
Prioritize this where mobile devices enter sensitive meetings, restricted areas, production environments, executive spaces, or regulated workflows. Leaders should ask whether mobile device controls, incident response playbooks, and audit evidence can answer: which apps can access cameras, when camera access occurred, whether media was stored, and whether files left the device. This is especially relevant for privacy, insider-risk investigation support, mobile fleet governance, and cyber-physical exposure in environments where cameras can reveal facilities or operations.
Technical view
ATT&CK provides this as DET0695, a detection strategy for T1512 Video Capture in the mobile domain. The related technique states that adversaries may use device cameras through operating-system APIs, capture video or images, write media to disk, and exfiltrate files later. Because the detection strategy has no official detection procedure, SOC and mobile security teams should validate coverage around camera permission grants, camera API usage where observable, app behavior involving video/image file creation, and follow-on file access or network transfer. Treat Android and iOS differences carefully, since telemetry depth and permission visibility vary by operating system, management posture, and enrolled-device policy.
Likely telemetry
- Mobile device management or enterprise mobility inventory showing installed apps and camera permission state
- Mobile OS privacy or permission events where available, including camera access indicators or permission changes
- Mobile threat defense or endpoint telemetry for suspicious app behavior involving camera use
- File-system or application container evidence of newly created image or video files where collection is supported
- Network telemetry or mobile security logs showing possible later transfer of captured media
Detection direction
- Validate whether camera permission grants and changes are logged for managed mobile devices, not merely configured in policy.
- Correlate camera access or permission use with unexpected apps, unusual timing, sensitive locations or meetings, and subsequent media file creation or transfer.
- Tune carefully for false positives: legitimate camera use by conferencing, scanning, authentication, and productivity apps is common.
- Look for relationship-driven context: T1512 may involve capture first and exfiltration later, so detection should not stop at camera access alone.
- Identify blind spots on unmanaged or personally owned devices, devices without mobile threat telemetry, and OS configurations that limit app-level visibility.
Mitigation priorities
- Start with governance: define where mobile cameras are allowed, restricted, or prohibited based on business sensitivity and physical environment risk.
- Use mobile device management policies to limit camera access or app installation where appropriate and supported.
- Review app permission baselines, especially for apps that do not have a clear business need for camera access.
- Ensure incident response procedures can preserve and review mobile permission, app, media-file, and network evidence within legal and privacy constraints.
- Strengthen user awareness and reporting paths for unexpected camera indicators, suspicious apps, or privacy prompts.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy record with no official description, no official detection text, and no tactics or platforms specified on the detection object itself. The practical content comes from its relationship to T1512 Video Capture, whose related platforms are Android and iOS and whose description covers camera API use, media creation, and later exfiltration.
This take does not assert active exploitation, attribution, impact, or existing detection coverage. Local conclusions require environment-specific evidence about managed mobile scope, OS versions, privacy settings, MDM/MTD visibility, BYOD policy, and incident response collection authority.
Detection of Video Capture
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1512 | Video Capture | This object detects Video Capture. |
All related ATT&CK context
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.0 | Current bundle | 1f707cd3ac38… |
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 DET0695Open 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.