Video Capture (T1125) is a collection technique. MITRE lists Linux, macOS and Windows.
A camera sees the room, the whiteboard and whatever is held up to it. Control over the camera is a privacy issue and a corporate espionage issue.
How attackers use it
MITRE describes using a computer's peripheral devices, such as integrated cameras and webcams, or applications such as video call services, to capture video. Images may also be taken, possibly at set intervals, in place of video files. Malware or scripts use an OS or application API, and the files may be written to disk and exfiltrated later.
MITRE separates this from screen capture: the source is a camera or video application, not the desktop. It also notes that on macOS some malware samples record the webcam, naming FruitFly and Proton.
How to detect it
MITRE's strategy is a behavior chain, platform aware. Analytics describe:
- Windows: a non-standard process, or script host, loading camera or capture libraries such as avicap32.dll, mf.dll or ksproxy.ax, opening the Camera Frame Server or a device, writing .mp4, .avi or .yuv files to unusual places, and optionally sending data out soon after.
- Linux: a process opening /dev/video* through V4L2, running ioctl and read loops, writing large or continuous video files, or quickly connecting out.
- macOS: a non-whitelisted process receiving the camera entitlement (kTCCServiceCamera), opening AppleCamera or AVFoundation handles, writing .mov or .mp4 files to unusual places, or beaconing soon after.
Telemetry to use includes image load events, file creation, and on macOS the TCC logs.
How to reduce the risk
MITRE lists no formal mitigation. General practice:
- Control camera permission through device management and review which apps hold it.
- Use application control to stop unknown binaries.
- Alert on camera device access by processes that are not conferencing tools.
Check your own environment
# Linux: list video capture devices (read-only)
ls -l /dev/video*
# Linux: show which processes currently have a video device open (needs lsof; run with sudo for all users)
sudo lsof /dev/video0
On macOS, review apps under System Settings, Privacy and Security, Camera. On Windows, review Settings, Privacy and security, Camera.
Why the file trail matters
MITRE notes that recordings or images may be written to disk and sent out later. That gives you two places to look even when the capture itself is invisible.
On disk, watch for video or image files in temp folders, hidden directories or user profile folders, created by a process that is not a conferencing or recording tool. Size and cadence help: a steady stream of small image files at fixed intervals is consistent with the interval capture MITRE describes, while one large file suggests a recording.
On the network, look for an outbound transfer soon after those files appear, from the same process or its child. Tying file creation events to network events by process ID is the simplest way to join the two halves of the story.
Finally, keep the endpoint's permission records. On macOS, the TCC database and logs show which applications were granted camera access and when. A new entry for an unfamiliar application is worth a conversation with the user.
Quick check
How does this differ from screen capture?
It uses cameras or video applications rather than capturing the desktop.
Which Linux device path appears in MITRE's analytic?
/dev/video*, accessed through V4L2.
Sources
- MITRE ATT&CK, Video Capture (T1125)
