How T1113 screen capture shows up in intrusions
A non-standard process reading display content during an active user session is the signal a SOC lead should treat as T1113 Screen Capture until the activity is explained. T1113 describes an adversary capturing what is shown on a victim's screen, so that the content of a logged-in session can be observed or saved without the user's knowledge. Under the Collection tactic (TA0009), which MITRE describes as the point where an adversary is trying to gather data of interest to its goal, screen capture matters because it reaches information that never sits in a file or database: open documents, dashboards, internal messages, credentials typed into a window or the contents of an administrative console. It is often used alongside other collection methods rather than alone, so a screen capture event may be the first visible sign of a wider data-gathering effort. In intrusions, the activity usually appears after an adversary already has a foothold on an endpoint or a session with enough privilege to see the desktop. Screen capture can be built into a tool the adversary brought in, invoked through a utility already present on the system, or performed by a process that a legitimate user never launched. Analysts should therefore compare the process, its parent, its user context and the timing against the user's normal work pattern, rather than relying on the capture alone. Because the same capability is used by legitimate remote support, meeting and recording software, the first decision is whether the process is sanctioned for that host and user. Mappings in this series name ATT&CK version 20.0, the Enterprise release that MITRE published on 2026-10-13. Sub-technique and detection strategy references can change between ATT&CK releases, so confirm the current identifiers in the MITRE ATT&CK technique page and the version your detection content targets before you record a coverage claim. Ask your endpoint vendor and your own engineering team which screen capture APIs and utilities are approved on each platform, since that inventory determines what counts as an exception.
Which telemetry reveals screen capture on each platform
This table maps the telemetry that can surface T1113 Screen Capture on Linux, macOS and Windows, with the open-source collector that typically gathers each source. Read each row as a question to answer in your own environment: which data component is logged, by which agent, and how deep that logging actually goes. The main takeaway is that process and module telemetry carry most of the signal, while file and command context helps explain saved captures.
| Platform | Primary telemetry (Process Creation, Module Load) | Context and open-source collector |
|---|---|---|
| Linux | Process Creation (DC0032) from auditd execve records or Sysmon-style logging, where the host is configured to capture them | Wazuh agent ships process events; Velociraptor can collect process and file artifacts on demand. Confirm audit rule coverage for display and capture utilities. |
| macOS | Process Creation (DC0032) from endpoint security or unified log events, depending on the logging profile deployed | Wazuh agent or Velociraptor artifacts can gather process and file state. Module Load visibility is typically limited; confirm what your EDR exposes. |
| Windows | Process Creation (DC0032) and Module Load events, which require Sysmon-style configuration to be logged in detail | Wazuh agent forwards Windows event channels; Velociraptor collects Sysmon events. Confirm that Module Load logging is enabled and scoped to the relevant processes. |
| Command Execution (DC0064) | Shell or scripted invocations that launch capture tools or call system screenshot interfaces | Adds intent context to Process Creation; shell history and Wazuh log collection help correlate it. Confirm which shells and interpreters are logged in your fleet. |
| File Creation (DC0039) | New image or video files written to temporary or user directories after a capture event | Explains saved captures and supports timeline work in Velociraptor. Confirm retention and whether user profile paths are monitored. |
| Log depth and retention | Event volume, sampling and retention windows differ by platform and agent version | Confirm with your agent vendor and internal logging standard how long process and module events are kept and where they are forwarded. |
Detection logic for screen capture with Sigma and Wazuh
Screen capture rarely shows up as one clean signal, so the useful detections combine process, module, file and session context. Each card below describes one detection idea, the baseline to build before alerting, and the benign software that will trigger it first.
Unexpected processes touching capture interfaces
Flag processes that open display, screen buffer or desktop duplication interfaces when the binary is not on your approved list for that host role. The question to answer is whether the caller is a known remote support, meeting or accessibility tool. Build the baseline per host group over a few weeks, because a developer workstation and a kiosk will look very different. Expect remote support agents, conferencing clients and screen readers to dominate early alerts, so tune on parent process, signing identity and install path rather than the binary name alone.
Capture libraries loaded by non-allowlisted binaries
Alert when a process loads a known screen-capture or graphics capture library that it has never loaded before on that endpoint. Pair the module name with the signing certificate and the file path, since attackers often reuse legitimate library names from unexpected locations. Start in report-only mode and promote the rule after you have reviewed the first baseline window. Recording software, game capture overlays and remote desktop agents are the usual false positive sources, so document each approved module with its owner.
Capture output written to temporary locations
Watch for image or video files appearing in temp directories, user caches or hidden folders shortly after a capture-capable process runs. The key check is the combination of a new media file and a short-lived process that did not write media before. Set the file-creation window tightly and exclude known application caches that write screenshots, such as collaboration tools and screenshot utilities. Confirm the file extensions and directories your own endpoints use before you set exclusions, and review them with the endpoint team.
Capture activity outside an interactive session
Capture requests from a service account, a scheduled task or a session with no logged-on user are rarely legitimate on workstations. Correlate capture-related process events with the session type and the logon state reported by the endpoint. Baseline which services legitimately run in non-interactive sessions, such as kiosk or digital signage software, and treat anything else as high priority. Confirm with each application owner how their software behaves when no user is logged in, because some monitoring agents run headless by design.
How to validate the T1113 detection before trusting it
This sequence proves that the T1113 Screen capture detections fire on the platforms you run, with the telemetry and alert trail you expect, before anyone relies on them in production. It also sets up a repeatable check that catches drift after rule, agent or operating system changes.
Define the emulation scenario and scope
The detection owner and the range operator agree in writing on the behavior to emulate, the Linux, macOS and Windows hosts in scope, and the accounts and time window used. The scenario describes the outcome in plain words, such as a user-context process collecting screen content and writing it to a staging location, without any command lines or tooling. The step is complete when the scenario is signed off and every host in scope has a named owner. Sign-off also states who may stop the exercise if a production-like system is affected.
Document expected telemetry for each platform
For each platform, the team lists the data components the detection depends on, such as Process Creation, Module Load and File Creation, and the fields expected in each event. Linux, macOS and Windows will not produce identical records, so the expectations must be written per platform. Confirm with your agent or log pipeline vendor which fields are collected by default and which need extra configuration. The output is a short telemetry matrix that the test results will be checked against.
Set pass criteria and record requirements
Pass criteria define what counts as a successful validation, for example that an alert is raised in the SIEM within the expected pipeline latency, that the process lineage shows the parent and child relationship in the event data, and that the alert maps to the intended ATT&CK technique. Failure criteria cover missing telemetry, misattributed hosts or alerts that fire only on unrelated activity. Define what to record for every run: timestamps in a single time standard, host identifiers, process lineage, the Wazuh or SIEM alert IDs, and the Sigma rule name and version. Ask your team to confirm the exact latency target before the exercise, since no figure is set here.
Check Sigma rule versions against the targeted ATT&CK version
Before the run, the detection engineer confirms which ATT&CK version each Sigma rule and its mapping target. ATT&CK v18 replaced technique-level detections with detection strategies and analytics, and later releases, including v19 and v20, can rename, deprecate or revoke techniques. Record the version of the rule set, the ATT&CK version used for the tag mapping and the data component IDs cited. The check is complete when the mapping is written down and any stale tag is corrected. Without this step, a passing test can still describe a technique that has changed in the framework.
Run the scenario and capture evidence
The range operator executes the agreed scenario on each in-scope host while the detection owner watches the SIEM and the raw event store. Each run is labeled with a unique test identifier so that events, alerts and notes can be matched later. Evidence is captured as it happens, not reconstructed afterward. The step closes when every planned host has produced a labeled event trail, even if some of those trails show gaps that the next step will classify.
Compare results with expectations and classify gaps
The team compares observed telemetry and alerts with the matrix from the earlier step and classifies each difference as a missing event, a missing field, a delayed alert, a wrong host attribution or a rule that did not fire. Each gap gets an owner and a fix type, such as changing the agent configuration, adjusting the rule logic or adding a data source. Results are recorded against the test identifier. The output is a signed validation record stating which platforms passed, which failed and which are blocked pending a fix.
Schedule re-runs after agent and OS updates
Validation is not a one-time event. Agent upgrades, operating system patches, changes to audit policy and rule updates can silently remove telemetry that the detection depends on. The team sets a re-run trigger tied to each of these change types and reruns the same scenario and pass criteria after each change. Ask your platform owner to confirm the change calendar and how Wazuh or your SIEM notifies the team of agent version changes. The step is complete when the trigger list is in the change process and the last validation record is linked to the current agent and rule versions.
How the detection pipeline connects endpoints to the SOC
Screen capture detection only works if endpoint telemetry reaches the SOC in a form analysts can query and trust. For T1113 Screen capture, the path usually runs from a Wazuh agent or Sysmon-equipped Windows host, through a collector or manager, into the Wazuh indexer or Security Onion's Elastic-based stack, where Sigma rules are converted to the native query language and correlated with other events before an alert appears in the analyst console. The trust boundary sits at the agent-to-manager connection, which is where an attacker with local control could tamper with, drop or flood events. Confirm with your own architecture how agents authenticate to the manager, whether the transport is encrypted, and whether a compromised endpoint can alter its own agent configuration or local log files before they ship.
Each hop in that path needs a decision. Decide which Windows, Linux and macOS event sources are forwarded for process creation, module load and file creation activity, and record the agent and Sysmon configuration versions you tested against, because a rule that matches one configuration may silently miss events from another. Pin the Sigma rule set to a named ATT&CK version so that a change in technique mapping, such as the ones shipped with the ATT&CK releases listed in the MITRE ATT&CK updates page, does not change alert coverage without review. Verify the conversion step by replaying a known sample through the pipeline and confirming the alert lands in the expected dashboard.
Log retention and access control decide whether the detection is useful after the fact. Screen capture alerts are often investigated days later, when a host has been reimaged or an analyst needs the raw process lineage, so confirm the retention period for raw endpoint events and for indexed alerts separately, and make sure the period is written into your incident response runbook. Restrict who can read, edit or delete rules and archived events, and log those administrative actions to a location the SOC team controls. Ask your implementation partner to document these settings as part of the handover, since auditors reviewing this control will usually ask for the retention configuration and the access list, not only a screenshot of a working alert.
Preventive controls that limit screen capture
Preventive controls will not stop every screen capture, but they reduce what an adversary can capture and how quickly a capture is noticed. The four ATT&CK mitigations below map to Collection techniques and address different parts of the problem: logging, user behavior, account privileges and data movement.
Audit of capture-capable activity
Audit (M1047) covers configuring the operating system and security tooling to record the events you need to spot screen capture. On Windows, Linux and macOS this means deciding which process, module and file events are logged for screen-capture utilities and for hosts that handle sensitive screens. Without those logs, the detections in this page have nothing to read. Confirm which audit settings your hosts retain and for how long. Confirm also whether ATT&CK v20.0 maps Audit to T1113 specifically or only to its parent tactic group.
User training on sensitive screens
User Training (M1017) addresses the human path to capture, such as an employee being persuaded to run a screen-recording tool or install a remote-view component. Training should cover which tools are approved, how to handle sessions that display regulated data, and how to report an unexpected prompt for screen or display access. Training is hard to measure, so pair it with a check: review whether approved recording tools are the only ones installed on privileged workstations.
Restricted account and display rights
User Account Management (M1018) limits which accounts can run capture-capable software, change display or accessibility settings, or install drivers. Standard users rarely need these rights on workstations that display privileged credentials or client records. Review group membership for local administrators and for accounts used by remote-support tools, since those accounts often hold the access an adversary would need. Ask your identity team to confirm that these rights are reviewed on a schedule.
Data loss prevention on captured output
Data Loss Prevention (M1057) focuses on what leaves the environment after capture. Image and video files written to disk or uploaded to shared storage can be flagged or blocked by content rules, endpoint controls and egress policies. This control does not stop the capture itself, so it works best alongside the audit and account controls above. Confirm with your endpoint vendor which file types and upload paths its policies can inspect in your environment.
Triage and response when a screen capture alert fires
The first decision when a screen capture alert fires is whether the activity is authorized, and that answer depends on confirming the process itself. Start by checking the binary path, its code signature and publisher, and the parent process that launched it. A screenshot utility started by the user's desktop shell is a different case from a process spawned by a script engine, a remote management agent or a process running from a temporary or user-writable directory. Next, identify the user session the process ran in: the account, whether it was interactive or a service context, the logon source, and whether the same account has other recent alerts. Confirm with the endpoint owner or the user's manager whether a screen capture tool is expected on that host. Then determine whether captured output exists. Look for new image or video files created near the alert time, and note their location, size and owner, without opening them yet. Your endpoint telemetry should show the file creation event that ties the output to the process, so use that link rather than file names, which are easy to change.
Containment should be proportionate to what you have confirmed. If the process is unexplained and the session is interactive, isolate the endpoint from the network through your endpoint detection platform or host firewall policy, and suspend the user account only after your identity team agrees, since a locked account can disrupt legitimate work and destroy context. Before terminating the process or deleting any output, preserve evidence: collect the executable, the process tree, relevant logs and the captured files into a hashed, access-controlled case folder. Record who handled each item and when. Velociraptor or a similar open-source collection tool can gather these artifacts consistently across hosts. Captured content is often sensitive. Inspect files only in a controlled environment, and check whether they show customer records, credentials, health information, source code or screens of regulated systems. If personal data is visible, or if the capture may have left the organization, involve your privacy officer and legal counsel early, because notification duties and retention rules may apply. Document the decision points so the timeline can be reconstructed later. Confirm your organization's notification obligations and evidence handling requirements with legal and privacy staff, since these vary by jurisdiction and contract.
Rehearsing T1113 detection in a private cyber range
On a Linux range, the environment is usually a set of instrumented workstations or jump hosts running a graphical session, with an agent collecting process and file telemetry and a logging pipeline feeding the SIEM. The range should match the desktop stack your organization actually uses, because screen capture behavior depends on the display server and the available utilities. Injects are scripted actions run by the exercise team under a documented change record, such as launching a screenshot utility from an unusual parent process and writing image output to a temporary directory. Expected behavior is an alert on process creation with the parent and output path visible to the analyst, followed by a triage step that checks the user, host and recent session activity. Good looks like a detection that fires within the agreed window, an analyst who can state the scope in a ticket, and a tuning note that records any false positives from legitimate screenshot tools.
- Range build: Confirm the agent version, the desktop environment and the log forwarding path match production before the exercise starts.
- Inject types: Use benign, scripted screen capture events with known parents and output locations so that results are measurable.
- Expected detection: Process Creation telemetry should surface the capture utility with its command context, parent and user.
- Response behavior: The analyst confirms the user and host, checks whether the output was written off the host, and escalates per the playbook.
- Tuning feedback: Record which legitimate tools were flagged and adjust allowlists only with a documented rationale.
Check that every inject has a recorded expected alert, a timestamp and a named owner before the session ends.
A macOS range typically uses managed endpoints enrolled in the organization's device management tooling, with an endpoint telemetry agent and a central log store. Screen capture on macOS often involves system capture utilities and permissions prompts, so the range should reflect how privacy controls are configured in production. Injects should be scripted and approved, covering both a capture event that triggers a user prompt and one that does not, so analysts learn to distinguish between them. Expected behavior is a detection on process creation with the initiating application and user context, combined with a review of recent permission changes where the telemetry supports it. Good looks like an analyst who correlates the capture with the logged-in user and the session timing, and a detection engineer who documents which signals were sufficient on their own.
- Range build: Enroll test endpoints in the same management profile as production and confirm the telemetry agent reports process events.
- Inject types: Include captures launched from user-facing applications and from background processes, with and without a visible prompt.
- Expected detection: Process Creation events should show the capturing binary, its parent and the account that ran it.
- Response behavior: The analyst verifies whether the user expected the activity, then checks for output files and outbound transfers.
- Tuning feedback: Note any approved productivity or accessibility tools that generate noise and decide whether to suppress them by signed identity or by context.
Confirm with your endpoint vendor which permission and capture events their agent records before you promise coverage for them.
A Windows range usually consists of domain-joined workstations with Sysmon or an equivalent endpoint agent, forwarding to a SIEM such as Wazuh, with network sensors in place if the exercise includes exfiltration of captured content. The range should mirror your Group Policy and application control baseline, since those controls change what runs and what is logged. Injects are scripted captures that vary by process lineage, output location and whether the image is written to disk or kept in memory, so the detection logic is tested across variants. Expected behavior is detection from process creation and module load telemetry, with the analyst pivoting to file creation events for the output. Good looks like a detection that fires on the agreed inject set, a clear record of which variants were missed, and a post-exercise review that assigns each gap to a rule update, a telemetry change or an accepted risk.
- Range build: Validate that the telemetry agent configuration, log collection and time synchronization match production before the run.
- Inject types: Cover different parent processes, output paths and load patterns, and include one variant that stays close to a legitimate workflow.
- Expected detection: Process Creation and Module Load events should appear with the capturing context, and file creation should link the output.
- Response behavior: The analyst contains the host only if the playbook criteria are met, preserves the relevant logs and records the timeline.
- Tuning feedback: Log every rule that fired on benign administrative activity and every variant that was missed, then retest after each change.
Verify the detection content against the ATT&CK version you target, since technique and detection mappings can change between releases.
Running the same T1113 scenario across roles shows whether the detection, the handoff and the decision making work end to end. The SOC analyst focuses on triage quality, the detection engineer on rule behavior and telemetry gaps, and the incident lead on scoping, communication and containment decisions. Injects are assigned by role: analysts receive alerts without context, engineers receive the raw telemetry and the rule logic, and leads receive a situation update at a scripted point. Expected behavior is that each role produces a defined artifact, such as a triage note, a tuning change request or a decision log. Good looks like clean handoffs between roles, documented assumptions, and a review that separates detection failures from process failures.
- SOC analyst: Works the alert, records the evidence reviewed and states whether the activity is expected.
- Detection engineer: Compares the rule against the telemetry, identifies missed variants and drafts a change for peer review.
- Incident lead: Decides on scope, containment and communication, and records the rationale at each step.
- Shared injects: Use one scenario across all roles so that results can be compared fairly.
- Post-exercise review: Hold a blameless review within a set window, then assign each finding an owner and a retest date.
Check that every finding from the review has a named owner, an agreed change and a retest scheduled before the team closes the exercise.
Questions detection engineers ask about T1113
How do you tell screen capture from legitimate screen sharing?
Start from the process and its context, not from the capture event alone. Screen sharing tools such as conferencing clients are expected to capture the display, so a useful baseline records which signed applications, parent processes and user accounts normally capture the screen on each host class. Alerts become useful when a capture-capable process is launched by an unexpected parent, runs from a user-writable path, runs on a server or kiosk that has no sharing use case, or starts outside a known meeting window. Confirm with each endpoint vendor which APIs and entitlements their sharing products use, because this determines which telemetry will show the difference.
Is module load telemetry reliable for screen capture on macOS?
It can help, but treat it as one signal rather than a complete record. Module load visibility depends on the endpoint agent, the macOS version and the permissions granted to the agent, so coverage should be tested on your own fleet before you write rules against it. Confirm three things with your agent vendor: which frameworks and libraries are reported, whether load events arrive with the parent process and code signing details, and how long events are retained. Pair module load data with process creation and file creation events so a missed load event does not leave the investigation blind.
How should we handle ATT&CK version changes for T1113?
Record the ATT&CK version every detection maps to, and review those mappings at each release. MITRE's update notes show that recent releases changed how detections are described, moving from detections inside technique pages to detection strategies with analytics, and that data components were revised. Store rule metadata with the technique ID, the version it was written against and the data components it depends on. When a new version is published, compare the STIX bundle for that version against your mapping, check for renamed, deprecated or revoked techniques, and re-test any rule whose data source changed. Keep a dated change log so auditors can see what changed and when.
How do we test T1113 detections without live employee data?
Test in a private cyber range that mirrors your endpoint agents, logging pipeline and SIEM rules, and generate benign activity that produces the same telemetry shape. Use dedicated test accounts, synthetic desktop content and a documented change window so the exercise is repeatable and no real screen contents are captured. Measure whether each expected event reaches the SIEM, whether the rule fires, and whether the alert carries enough context for triage. Replay the same scenario after every rule or agent change. Scope and deliverables for a range exercise are agreed in writing before work starts, and DeployOpen runs these exercises in client-controlled environments.
What should we log for forensic review of a screen capture event?
Log enough to reconstruct who captured what, from where, and whether the output left the host. The core set is:
- Process creation events with full command line, parent process, user, hash and code signing status
- Module load events for capture frameworks where the agent supports them
- File creation events for image, video or temporary output files, with their paths and sizes
- Network connection events that show uploads or transfers after the capture
- Console or session logon events that show whether the user was active at the time
Keep retention long enough for your incident response window, restrict access to these logs, and confirm with counsel and your privacy office what must be recorded about employee activity under your local rules.
Which mitigations apply to screen capture, and what do they cover?
ATT&CK maps T1113 to controls that reduce both access and exposure. User Account Management limits which accounts can run capture-capable software and reduces the blast radius of a compromised session. Audit supports the logging described above so that capture activity is recorded in the first place. User Training helps staff recognize unexpected prompts or software that asks for screen access. Confirm the current mitigation mapping for T1113 in the ATT&CK version you target, because mapping entries are reviewed between releases and control owners should verify each one against their own environment.
Can our own team run these detections, or do we need outside help?
Many teams can build and maintain screen capture detections in-house if they already run an endpoint agent, a SIEM and a repeatable test process. The skills that most often limit progress are the ones that need repeated practice: mapping telemetry coverage across macOS, Linux and Windows, writing and tuning rules, and running range exercises that produce evidence. A fixed-scope engagement can cover the initial build, testing and handover, while a retainer can cover ongoing rule updates after each ATT&CK release. Ask any provider to define deliverables, the systems they will touch and who owns the resulting rules and documentation before work starts.
How DeployOpen builds T1113 detections and range scenarios
DeployOpen works on T1113 Screen capture as a fixed-scope engagement inside the client's own environment, with detection logic, test scenarios and documentation agreed in writing before work starts. The result is a detection that the client's own team can run, validate and maintain against a named ATT&CK version.
How we scope
- Confirm which platforms in your estate are in scope for T1113, such as Linux, macOS and Windows endpoints.
- Record the telemetry you already collect, including Process Creation and Module Load, and where it is stored.
- Agree the ATT&CK version the mapping targets and the deliverables in writing before any build starts.
How we build
- Write detection logic for T1113 in open formats such as Sigma and deploy it to your Wazuh or Security Onion stack.
- Tune rules against your normal screen-capture-capable software so that legitimate use is documented and expected.
- Map each rule to the relevant ATT&CK data components and mitigations, and record known coverage gaps.
How we hand over
- Deliver a range scenario in a private cyber range that lets your analysts rehearse detection and response for T1113.
- Provide runbooks covering triage, containment and evidence collection for a suspected screen capture event.
- Document validation results, configuration and ownership so your team can operate and audit the detection.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review the T1113 mapping when ATT&CK releases rename, deprecate or revoke techniques or detection strategies.
- Confirm with your own environment and the open-source tool vendors which capabilities your version supports before relying on them.
