How T1125 video capture shows up in a SOC queue
The SOC lead's question is simple: is a camera being used by something that should not be using it? T1125 Video Capture is the ATT&CK technique in which an adversary collects video from an attached or networked camera. It sits under the Collection tactic (TA0009), whose ATT&CK definition is that the adversary is trying to gather data of interest to their goal. In ATT&CK Enterprise version 20.0, the technique is detected mainly through process, file and access telemetry, so the first triage step is to ask which process touched the camera and whether that process has a legitimate reason to do so.
At a high level, an adversary gains a view of a physical space or a user's workstation without the user knowing. That visual material can reveal people, documents on screens, meeting content or building layout, which makes it useful for reconnaissance of a target and for collection ahead of exfiltration. In intrusions, the activity tends to appear after an attacker already has a foothold on the endpoint or on a device with a camera, so it is usually one step in a longer chain rather than a standalone alert. Analysts should therefore look at the surrounding activity on the same host, including earlier execution and any unusual outbound traffic.
Decisions to make before an incident occurs include which endpoint classes are expected to use cameras (for example, approved conferencing applications), which systems should never access a camera, and who owns the approval list. Confirm with your endpoint and platform teams how camera device access is logged on each operating system you run, since the available signals differ between Linux, macOS and Windows. Map your queue to the ATT&CK version you target, because releases can rename or restructure detection content, and review the technique page on the MITRE ATT&CK site before writing rules.
Telemetry sources that reveal video capture
This table maps each Process Creation, File Creation and File Access signal to what it reveals about T1125 Video capture on Linux, macOS and Windows, with the open-source collector that gathers it. Command Execution and Network Traffic Content appear as context sources that help correlate endpoint events. Confirm per-platform coverage in your own environment and against the ATT&CK version you target.
| Telemetry source | Linux | macOS | Windows |
|---|---|---|---|
| Process Creation (DC0032) | Capture utilities or unexpected interpreters starting; auditd execution records collected by the Wazuh agent | New processes starting while the camera indicator is active; endpoint agent process events and unified log | Process creation events for unknown binaries before camera access; Sysmon Event ID 1 forwarded by Wazuh |
| File Creation (DC0039) | New recordings or image files written to staging paths; auditd file watch rules and Wazuh file integrity monitoring | New video or image files written to user or temp folders; Wazuh file integrity monitoring or Velociraptor file artifacts | New media files under user profile or temp paths; Sysmon Event ID 11 forwarded by Wazuh or Velociraptor artifacts |
| File Access (DC0055) | Reads of video device nodes by processes outside an approved list; auditd watch rules on device paths | Reads and changes to the privacy permission database that governs camera access; unified log and Velociraptor artifacts | Access to webcam consent store entries and device interfaces; audit events, Sysmon, or Velociraptor registry artifacts |
| Command Execution (DC0064), context | Shell commands that launch capture tools; useful for linking process and file events to a user session | Scripted commands that start media tools; useful for tying camera access to a launching script | Command line and script block activity that starts capture code; correlate in Wazuh with Sysmon events |
| Network Traffic Content (DC0085), context | Outbound transfers of media files to unfamiliar hosts; collected by network sensors such as Zeek or Suricata | Outbound transfers of media files after capture; collected by network sensors such as Zeek or Suricata | Outbound transfers of media files after capture; collected by network sensors such as Zeek or Suricata |
| Coverage to confirm | Which video device paths, audit rules and distributions your fleet exposes | Which macOS versions and endpoint agents expose the permission and process events you need | Which Sysmon configuration, audit policy and Velociraptor artifacts run on each device group |
Detection ideas for T1125 that SOC teams can tune
T1125 Video capture rarely shows up as one clear event, so these ideas combine process, file and camera-access signals. Tune each one against a baseline of approved conferencing, browser and remote support activity before it pages anyone. Name the ATT&CK version in every rule, for example Enterprise ATT&CK 20.0.
Unexpected processes opening the camera
Alert when a process that is not an approved conferencing or camera application opens a camera device interface. On Linux, watch for processes opening video device nodes. On Windows and macOS, correlate process creation with camera-in-use indicators. Tune by allowlisting signed application paths and known parent processes, and start with the workstation fleet before expanding to servers. Check the parent process and user session for each hit, since a camera opened from a service account or a headless session deserves faster review.
New video files in user directories
Flag creation of video container files in user profile, temp and download directories by processes that do not normally write media. The logic relies on File Creation telemetry, filtered by file extension and writing process. Tune the extension list to the formats your business actually uses, and exclude known recording folders for meeting software and screen recording utilities. Review writes from command-line interpreters or unsigned binaries first, because those are the cases that rarely have a benign explanation.
Camera access outside application context
Correlate camera access with the foreground application and the logged-on user. A camera session with no matching meeting window, no calendar entry in common tooling, or a locked or idle desktop is worth a look. This logic depends on endpoint telemetry that records device usage, so confirm which fields your EDR or Wazuh agents expose before writing the rule. Tune the window of acceptable idle time per role, and document how helpdesk remote sessions appear so they do not generate repeated alerts.
Benign sources to suppress
Most T1125 false positives come from a short list of sources: video conferencing applications, browsers that request camera permission for web meetings, and IT remote support tools that stream the desktop. Build suppressions by application signature, install path and parent process rather than by username alone. Record each suppression with an owner and a review date, so the allowlist stays explainable during an audit. Keep remote support tool exceptions narrowly scoped to approved tools and approved technician groups.
Writing Sigma rules with ATT&CK version
Express each detection as a Sigma rule so the logic can move between SIEM backends without rewriting the search. Each rule should carry the ATT&CK technique and sub-technique tags it targets and state the ATT&CK version it was written against. ATT&CK releases can rename, deprecate or revoke techniques, so re-check the mappings when a new version is published. The ATT&CK updates page lists the release notes to review. Keep a version field in each rule's metadata so reviewers know which mapping they are reading.
How telemetry flows from endpoint to alert
For T1125 Video capture, detection depends on a chain of four stages: an endpoint agent records the event, a collector receives and stores it, normalization maps it into common fields, and a rule evaluates it and produces an alert for triage. The events that matter most for this technique come from Process Creation (DC0032), File Creation (DC0039) and File Access (DC0055), so the first design decision is confirming that your endpoint agents actually emit these three sources on every platform in scope, Linux, macOS and Windows. Process Creation shows which binary opened or attempted to use a camera device, File Creation shows where recordings or frames were written, and File Access shows reads of stored captures. Each of these depends on operating system auditing or agent configuration that is often off by default, so verify it on a test host before relying on the rule.
Normalization is where many detections quietly fail. A Windows event, a Linux audit record and a macOS unified log entry describe the same action in different shapes, and the rule must match fields that exist after normalization in your SIEM. Wazuh can collect agent events, decode them and apply its own rule set, and Security Onion provides a collection and analysis stack that can ingest and query the same events. Velociraptor fits differently: it is used for targeted hunting and artifact collection on endpoints when an alert needs confirmation, not as the continuous pipeline. Confirm which of these tools is the system of record for each source, and document the field mappings your analysts will query. Retention matters here because a capture file may be written and deleted within minutes, so the window in which the raw event is still searchable determines whether an investigation can reconstruct what happened.
Two prerequisites sit underneath the whole chain. Time synchronization must be consistent across endpoints, collectors and the SIEM, because correlating a camera access event with a file write and a network upload depends on reliable timestamps. Retention must be set long enough for triage and hunting cycles, and the retention period should be written down and tested by restoring a sample of events. Ask your team to confirm the clock source on each host class, the retention period for the three data sources, and whether the alert queue has an owner who can act on a video capture alert outside business hours.
How to validate that a T1125 detection fires
This sequence proves, in a private cyber range, that the T1125 Video Capture detections fire on the telemetry they depend on and that the team can explain every alert. It produces a dated record of each simulated camera-related action, the telemetry that arrived, the rules that fired and the tuning decisions taken.
Agree the emulation scope in writing
The detection owner, the range operator and the endpoint owners agree which operating systems, test accounts and camera-related activities are in scope, and which are out of scope. The agreement names the ATT&CK version the rules target, the test hosts and the rollback steps if a host behaves unexpectedly. Done means a signed scope note exists and every test host is listed with its owner. If the scope is not written, the run does not start.
Prepare isolated test endpoints and baselines
The range team builds test endpoints on Linux, macOS and Windows that mirror the production logging configuration, including process, file and driver telemetry where the platform supports it. They capture a baseline of normal camera-related activity, such as video conferencing applications opening the device, so that expected noise is known before any simulation. Done means each endpoint forwards its logs to the test SIEM and the baseline is saved with a timestamp. Confirm the logging coverage on each platform with the vendor or the platform documentation.
Run a documented benign simulation
The operator runs a pre-approved, benign simulation that represents camera-related activity on the test endpoints, following a written procedure that records start and stop times, the host, the user and the activity label. The simulation uses only sanctioned test applications and does not include any capability for real capture outside the range. Done means the procedure log shows each activity with a unique run identifier. Any deviation from the written procedure is logged as an incident for the scope owner.
Record which telemetry arrived and when
After each activity, the analyst checks the SIEM for the expected process creation, file creation, file access and other data components that the T1125 detection strategies reference. The analyst compares the event timestamps with the simulation log to measure ingestion delay and to spot any missing event categories. Done means a telemetry table lists, for each activity, which data components arrived, the host, the user and the time difference. Missing telemetry is treated as a finding, not as a pass.
Measure whether each rule fired
The analyst checks whether each rule mapped to T1125 generated an alert for each simulated activity, and whether the alert contains the host, user, process and file context needed for triage. The result is recorded as fired, not fired, or fired with missing context, along with the rule identifier and the ATT&CK version it targets. Done means every activity has a verdict and every missed activity has a recorded reason, such as a logging gap or a rule condition that did not match.
Log tuning changes and retest
The detection owner reviews the misses and false positives, adjusts rule logic or exclusions for known legitimate applications, and records each change with a reason and an author. The same simulation is rerun on the same endpoints to confirm the change works and does not hide the activity it was meant to detect. Done means a change log exists with before and after results, and the retest record is linked to the original run identifier.
Retain the validation record for review
The team stores the scope note, the simulation log, the telemetry table, the alert verdicts and the change log together, keyed to the run identifier and the ATT&CK version. The record is reviewed by the detection owner and the compliance lead so that it can support internal reviews or external assessments. Done means the package can be retrieved by run identifier and every rule ID in it matches the current rule repository. Confirm retention periods with your own governance policy.
Preventive controls that reduce T1125 exposure
ATT&CK maps several mitigations to Collection techniques, and four of them bear directly on unauthorized camera use. Each one shrinks a different part of the attack path: who can reach a camera, how users notice misuse, what records exist afterward, and how a stolen login is limited. Confirm each mapping against the ATT&CK version you target before you cite it in an audit file.
Audit (M1047) for camera use
Audit mitigations ask you to define which system events must be recorded and reviewed. For T1125 Video capture, that means logging which processes open a camera device, which accounts run them, and when. Without those records, a suspicious capture session on an endpoint leaves little to investigate. Ask your team to confirm exactly which audit policies and retention settings the mapping assumes in the ATT&CK version you use, and whether your endpoint platform can capture camera-access events at all.
User training (M1017) for camera prompts
User Training covers how staff recognize and report unexpected behavior on their devices, such as a camera light turning on without a video call or an unfamiliar application requesting camera access. Staff are often the first to notice a capture that automated rules miss. Training should name the specific signs your environment cares about and give a clear reporting path. Confirm the training content matches the mitigation text in the version you target.
User account management (M1018) for camera rights
User Account Management limits which accounts exist, what they can do, and when they are removed. For camera misuse, the question is who holds rights to install software, grant device permissions, or manage privacy settings on shared endpoints. Review these privileges on a schedule and remove accounts that no longer need them. Ask your administrators to document how camera permissions are granted through your device management policy.
Multi-factor authentication (M1032) where it applies
Multi-factor Authentication makes a stolen password less useful to an attacker who wants remote access to a device or to a management console that controls camera policy. It does not stop a capture that already runs under a logged-in user on an endpoint, so treat it as a limit on account misuse rather than a camera control. Apply it to remote access, administrative consoles and cloud device management first. Confirm with your identity team which of these paths is actually covered.
What to do when a camera collection alert fires
When a T1125 Video capture alert fires, the first decision is whether the activity is an approved business use or an unauthorized capture. Confirm the process that opened the camera device, the user session it ran under, and the host it ran on. Check whether the same user or host is expected to use video conferencing, a kiosk, or a monitoring application at that time, and whether the executable, its signer and its install path match the software inventory your IT team maintains. Ask the owner of the device or the endpoint management team to confirm whether the workstation was in a meeting room, a secured area or a remote-work setting. Record what you confirm in the case notes before you change anything on the host, because later steps depend on an accurate starting picture.
Preserve endpoint evidence before containment changes the host state. Capture the process tree, the file creation and file access events that accompanied the camera activity, and any new files written to user-writable locations shortly before or after the alert. If your endpoint platform supports live response or a forensic collection tool such as Velociraptor, follow your incident response runbook for its collection scope and chain of custody, and confirm with your forensic lead which artifacts are required. Isolate the host from the network only when the triage shows unapproved capture and the risk of further collection outweighs the operational impact of losing that workstation. Document who authorized isolation and when it was applied.
Escalate early to the owners who decide whether obligations are triggered. Involve legal counsel to determine whether recorded images or audio could contain personal data, regulated information or material covered by a contractual confidentiality clause. Ask the privacy office to assess whether notification duties or internal reporting timelines apply in the jurisdictions where the affected people sit. Bring in human resources only where the activity points to an identified employee and your policy process requires it. Keep IT, the security operations team and legal aligned on a single case record, so that the question of whether data was captured is answered from evidence rather than assumption.
Rehearsing T1125 detection in a private cyber range
The Linux range is built from isolated virtual hosts with the agent, audit and file telemetry you plan to run in production. Benign scripted activity stands in for the technique: a service account process opens a camera device node and writes a short media file to a staging path, mimicking the behavior described for T1125 without using any real capture tooling. The blue team receives an inject in the form of a ticket noting unusual activity on a developer workstation, and must work from the telemetry alone.
- Range setup: Isolated hosts with Wazuh agents or an equivalent collector, audit rules that cover device access and file creation in user and temp paths, and forwarding to a Security Onion or Wazuh indexer instance.
- Injects: A scripted scenario with a timed start, an unexpected process name, and a file written to an unusual directory, so the analyst must connect the events.
- Good detection: An alert reaches the analysts within the time the exercise plan sets, with the host, user, process lineage and file path present in the alert.
- Good response: Triage follows the written playbook, the analyst isolates the host through the agreed control, and preserves the staged file for review.
- Check: Confirm that device access telemetry is actually collected on your distribution and kernel version, since audit coverage varies.
The macOS range uses managed test devices or virtual machines enrolled with the same endpoint tooling as production, with privacy-related permissions logged where the platform exposes them. Benign scripted activity simulates a user-level application initiating camera or microphone access at an unusual hour, then writing output to an application support directory. Because macOS telemetry depends heavily on the endpoint agent and unified logging configuration, the range must prove what is visible before the exercise starts.
- Range setup: Isolated test Macs with the endpoint agent, unified log collection and file event monitoring configured to match production policy.
- Injects: A ticket describing a user report of an indicator light on a shared workstation, followed by a process event that the analyst must attribute.
- Good detection: The analyst sees the process, its signing information and the file write in one investigation view, and the alert fires within the agreed window.
- Good response: The analyst determines whether the application is approved, collects the artifact, and follows the documented path for user notification.
- Check: Confirm with your vendor which privacy-permission events and file events the agent reports on your macOS release, because this varies by version.
The Windows range uses domain-joined virtual machines with Sysmon or an equivalent telemetry configuration, forwarded to the SIEM. Benign scripted activity runs a standard user process that loads a media capture module and writes a file to a user profile location, which exercises the Process Creation, File Creation and File Access data components the detection depends on. Defenders receive an inject describing a help desk call about an unexpected prompt, and must determine whether the activity is legitimate.
- Range setup: Domain-joined hosts, Sysmon with a documented configuration, Windows event forwarding or Wazuh agents, and a time source synchronized across all hosts.
- Injects: A scripted process start with a parent that does not match the user's normal applications, followed by a file write in a profile folder.
- Good detection: A Sigma-derived or native rule fires within the agreed time, and the alert includes the parent process, command context, file path and account name.
- Good response: The analyst reviews the process tree, checks the account's recent logons, and follows the playbook for containment and user communication.
- Check: Confirm which module load and file access events your Sysmon configuration actually records, since default configurations often omit them.
Questions SOC leads and detection engineers ask about T1125
How do we separate legitimate video conferencing from video capture?
Start with the process and the output, not the camera access event alone. Conferencing applications open the camera routinely, so a camera access event by itself is a weak signal. Alert on camera use by processes outside an approved application list, on binaries that are unsigned or run from unexpected paths, and on parent processes such as scripts or remote shells. Recording output written to unusual locations shortly after camera access is a stronger indicator. Build a baseline of normal camera use per device group over a period your team agrees on, then enrich alerts with the user, the host role and whether a meeting was scheduled. For example, in an illustrative finance workstation fleet, the approved conferencing client may be the only expected camera user.
How do we handle false positives from endpoint security tools?
Endpoint agents, privacy tools and some security products access cameras or write temporary media for their own features, so they will trigger naive rules. Build exclusions on the signed binary path and publisher, not on the process name, because names are easy to change. Route each exclusion through change control with a named owner and a review date that your team sets. Recheck exclusions after agent upgrades, since a new version can change file paths or behavior. Track the false positive rate per rule so tuning decisions rest on evidence, and keep a record of what was excluded and why for auditors and future engineers.
How often should we re-validate T1125 rules after an ATT&CK release?
Re-validate whenever a release changes the technique, its sub-techniques, its data components or its detection guidance, and check each release for those changes. MITRE's notes show that ATT&CK v18, released October 28, 2025, replaced detections in technique pages with detection strategies and analytics and updated data components. Later releases followed on April 28, 2026 and October 13, 2026. Record the ATT&CK version each rule targets in its metadata, compare the new technique content with your mapping, and rerun your cyber range tests after any change that affects your telemetry. Consult the ATT&CK updates page as part of your release review.
How do we test video capture detection without disrupting users?
Test in a private cyber range with dedicated test identities and disposable endpoint images, not on production devices or employee cameras. Your team can describe the behavior to simulate, schedule it in a window agreed with the business, and tell the affected service desk and privacy office in advance. Confirm that the alert pipeline can handle the volume of test events without delaying other alerts. Afterwards, record which events fired, which were missed and which needed tuning. If any pilot must touch production endpoints, obtain written approval from the data owner and the privacy office first.
Which telemetry do we need before writing a T1125 rule?
The data components most relevant to this technique in ATT&CK are Process Creation, File Creation and File Access, so confirm that each one is collected on Linux, macOS and Windows endpoints. Check whether your agent, such as Wazuh with Sysmon on Windows or your EDR, records process lineage, camera device access and file writes with enough context to correlate them. Confirm in writing with each vendor which events their agent emits on each operating system and version you run. Gaps in any platform should be documented as known limitations so the rule's coverage is stated accurately.
Can our own team build and run these detections, or do we need outside help?
Many teams can build and run these detections if they have detection engineering skills and the telemetry described above. Where the gaps are in platform integration, rule testing, or cyber range rehearsal, DeployOpen can help. Its work covers planning, implementing, hardening and documenting self-hosted open-source platforms inside your environment, running security testing, building private cyber ranges and delivering training. Engagements are typically fixed-scope, with scope and deliverables agreed in writing before work starts, and ongoing support is available as a retainer. Confirm in the written scope who owns the rules, runbooks and test evidence after handover.
What should the response look like when a T1125 alert fires?
Triage first: confirm which process accessed the camera, whether it is on the approved list, and whether the user had a meeting scheduled. If the activity is unauthorized, isolate the endpoint according to your playbook and preserve the process, file and log artifacts before cleanup. Check for related collection behavior such as audio capture or screen capture, and look at what happened to any recordings, including whether they were staged or sent elsewhere. Document each step, decide whether privacy or legal teams need to be involved, and feed the outcome back into tuning and the cyber range scenarios so the next alert is handled faster.
How DeployOpen builds T1125 detections and range exercises
DeployOpen treats T1125 Video capture as a written, fixed-scope detection engagement inside your own environment. We agree which platforms, telemetry sources and ATT&CK version the detections target, then build, test and document them in your open-source stack, and validate them in a private cyber range before handover.
How we scope
- Confirm which operating systems, endpoints and camera-facing applications fall within T1125 Video capture coverage.
- Record which telemetry is available today, such as Process Creation, File Creation and File Access, and what must be enabled.
- Name the Enterprise ATT&CK version the detection mappings target, so later releases can be compared cleanly.
How we build
- Write detection logic in Sigma and translate it to the SIEM or data platform you run, such as Wazuh or Security Onion.
- Map each rule to the relevant ATT&CK detection strategy and data components, and record known gaps and false positive sources.
- Tune thresholds and allowlists against your own baseline of legitimate camera and conferencing software.
How we hand over
- Deliver rule files, configuration changes and a validation report that shows which test cases each detection passed.
- Provide a range exercise runbook covering how the detection is rehearsed in a private cyber range and what the analyst should see.
- Document response steps, owners and escalation paths in a form your SOC can maintain after the engagement ends.
How we support
- Review detections when ATT&CK releases rename, deprecate or revoke techniques that the rules depend on.
- Rerun validation and range exercises after platform upgrades, endpoint agent changes or new camera-capable software rollouts.
- Ongoing support, upgrades and continuous testing are available as a retainer, priced separately from the fixed-scope work.
