T1113: Screen Capture
Adversaries may attempt to take screen captures of the desktop to gather information over the course of an operation. Screen capturing functionality may be included as a feature of a remote access tool used in post-compromise operations. Taking a screenshot is also typically possible through native utilities or API calls, such as CopyFromScreen, xwd, or screencapture.CitationCopyFromScreen .NETCitationAntiquated Mac Malware
Security context for executives and security teams
Screen Capture (T1113) matters because it turns a compromised workstation into a source of visible business information: open emails, documents, chats, dashboards, credentials displayed on screen, and operational views. MITRE places it in Collection across Windows, macOS, and Linux, and notes it can be performed through RAT features, native utilities, or API calls. For leaders, this is a reminder that post-compromise monitoring must cover what an intruder can observe, not only what files they steal.
Executive priority
Prioritize this technique where users handle sensitive data, privileged administration, financial operations, regulated records, or operational/critical infrastructure dashboards. ATT&CK relationships link this behavior to many groups and to a campaign involving Polish energy infrastructure, so the business question is whether endpoint monitoring, remote access governance, and incident response playbooks can identify suspicious screen collection before it supports espionage, fraud, or operational decision compromise.
Technical view
Validate coverage on Windows, macOS, and Linux for screenshot activity initiated by unusual processes, RAT-like tooling, command-line utilities, and API-based capture patterns. MITRE provides no official detection text for T1113, but the related detection strategy DET0346 is explicitly named “Detect Screen Capture via Commands and API Calls,” which points detection engineers toward process, command, and API-level evidence. IR teams should treat screen capture findings as collection-stage activity and pivot to nearby remote access, persistence, credential exposure, and exfiltration evidence.
Likely telemetry
- Endpoint process creation and command-line telemetry for screenshot utilities such as xwd and screencapture where applicable
- Windows endpoint telemetry that can expose use of screen capture APIs such as CopyFromScreen or suspicious .NET-based capture behavior
- EDR or host activity showing RAT/backdoor processes invoking screen capture functions
- File creation or modification telemetry for newly generated image files in unusual locations
- User session context, interactive logon state, desktop access, and remote access session records
Detection direction
- Baseline legitimate screenshot and remote support behavior to reduce false positives from help desk tools, collaboration software, QA/testing tools, and user-initiated captures.
- Tune for unusual parent-child process relationships, unexpected capture utilities, non-interactive contexts, or screen capture by processes not normally associated with user productivity or administration.
- Correlate screen capture activity with other post-compromise signals, especially RAT execution, remote access, credential access opportunities, and outbound transfer of image files.
- Confirm coverage parity across Linux, macOS, and Windows; native utility monitoring often differs by operating system.
- Use the ATT&CK relationship to DET0346 as a starting point, but do not assume coverage because MITRE’s official detection field for this technique is not provided.
Mitigation priorities
- No specific official ATT&CK mitigation text was supplied for this object, so control work should start with visibility and governance validation rather than assuming a single preventive fix.
- Restrict and monitor remote access tools and administrative utilities that can expose desktop content, especially on sensitive user and administrator workstations.
- Harden endpoint monitoring to capture process, command-line, file creation, and relevant API-level signals where feasible.
- Reduce unnecessary exposure of sensitive data on shared workstations and privileged sessions through least privilege, session controls, and operational procedures.
- Ensure incident response playbooks treat suspected screen capture as potential sensitive information exposure and include scoping for what was visible during the compromised session.
Additional notes and limits
The relationship set is broad, including multiple espionage and financially motivated groups, software such as TinyZBot, PlugX, and BISCUIT, and a campaign involving energy infrastructure. That breadth makes T1113 useful for threat-informed control validation, but local risk depends on which users, applications, and operational displays are accessible from compromised endpoints.
This take is based only on the supplied ATT&CK STIX fields, references, and relationships. MITRE did not provide official detection guidance in the object fields, and no official mitigations were supplied here. Local telemetry, approved remote support workflows, operating system logging depth, and EDR capability determine whether this behavior can be reliably detected.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Screen Capture
Adversaries may attempt to take screen captures of the desktop to gather information over the course of an operation. Screen capturing functionality may be included as a feature of a remote access tool used in post-compromise operations. Taking a screenshot is also typically possible through native utilities or API calls, such as CopyFromScreen, xwd, or screencapture.CitationCopyFromScreen .NETCitationAntiquated Mac Malware
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.
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.
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.