AN1883: Analytic 1883
Monitor executed commands and arguments that may attempt to take screen captures of the desktop to gather information over the course of an operation. Monitoring for screen capture behavior will depend on the method used to obtain data from the operating system and write output files. Detection methods could include collecting information from unusual processes using API calls used to obtain image data, and monitoring for image files written to disk, such as CopyFromScreen, xwd, or screencapture.[1][2] The data may need to be correlated with other events to identify malicious activity, depending on the legitimacy of this behavior within a given network environment.
Analyst context for executives and security teams
This analytic is about spotting attempts to capture desktop screenshots during an operation. For security leaders, the value is not just “detect screenshots”; it is understanding whether sensitive operational, engineering, administrative, or user-session information could be silently collected from endpoints or workstations. In an ICS context, screen capture can expose process views, operator actions, diagrams, credentials shown on screen, or incident response activity, so coverage depends heavily on endpoint visibility and knowledge of what legitimate screen capture looks like in the environment.
Executive priority
Prioritize this as a validation question for endpoint monitoring and incident readiness: can the organization distinguish approved screen capture activity from unusual command, API, or file-write behavior? This matters for operational resilience and compliance evidence because screenshot collection may indicate reconnaissance or information gathering before broader action. Leaders should ask which critical workstations or administrative systems have telemetry for executed commands, process behavior, API usage where available, and image-file creation, and whether SOC playbooks require correlation before escalation.
Technical view
MITRE describes monitoring executed commands and arguments that may attempt to take screen captures, with detection depending on how the operating system data is obtained and written to files. SOC and detection teams should validate whether they can observe unusual processes invoking screen-capture-related methods or tools referenced by MITRE, including CopyFromScreen, xwd, or screencapture, and whether image files written to disk can be tied back to parent processes, users, hosts, and command context. Because no platform, tactic, or relationship context is supplied, detections should be environment-tuned rather than assumed portable.
Likely telemetry
- Executed command and command-line argument logs
- Process creation and parent-child process context
- Endpoint telemetry for unusual processes accessing screen image data APIs where available
- File creation telemetry for image files written to disk
- User, host, and session context to determine whether screen capture is expected
Detection direction
- Baseline legitimate screen capture use, such as support tools, documentation workflows, training, or approved administrative utilities, before alerting broadly.
- Correlate screenshot-related commands, API usage, or image file creation with process lineage, user role, host criticality, and timing to reduce false positives.
- Pay special attention to unusual or rarely seen processes producing image files or using screen capture methods.
- Validate visibility on critical ICS operator, engineering, and administrative workstations if they are in scope for monitoring.
- Treat the absence of an official ATT&CK detection field, platforms, tactics, and relationships as a signal that local telemetry validation is required before operationalizing this analytic.
Mitigation priorities
- Define where screen capture is legitimate and document approved tools and users.
- Ensure endpoint logging captures command execution, process ancestry, and file creation on systems where screenshot collection would create material risk.
- Apply least-privilege and administrative access controls so unauthorized users or processes have less opportunity to collect sensitive screen content.
- Tune SOC triage guidance to require context: user role, host function, parent process, destination path, and nearby suspicious activity.
- Use incident response procedures to preserve relevant process, command, and file evidence when suspicious screen capture behavior is observed.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic in the ICS ATT&CK domain. It provides a description and references to CopyFromScreen .NET and a malware analysis article, but no official detection section, platforms, tactics, mitigations, or relationships. The most defensible use is as a coverage-validation prompt for screenshot-related telemetry and correlation logic, not as a complete detection rule.
This take is limited to the supplied STIX fields, external references, and absence of relationships. It does not establish specific affected platforms, active exploitation, adversary attribution, impact, or guaranteed detection coverage. Local endpoint architecture, approved screen capture workflows, and available telemetry determine how actionable this analytic is.
Analytic 1883
Monitor executed commands and arguments that may attempt to take screen captures of the desktop to gather information over the course of an operation. Monitoring for screen capture behavior will depend on the method used to obtain data from the operating system and write output files. Detection methods could include collecting information from unusual processes using API calls used to obtain image data, and monitoring for image files written to disk, such as CopyFromScreen, xwd, or screencapture.[1][2] The data may need to be correlated with other events to identify malicious activity, depending on the legitimacy of this behavior within a given network environment.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 3f78ae7f77c3… |
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]
CopyFromScreen .NET
Microsoft. (n.d.). Graphics.CopyFromScreen Method. Retrieved March 24, 2020.
Open source URL -
[2]
Antiquated Mac Malware
Thomas Reed. (2017, January 18). New Mac backdoor using antiquated code. Retrieved July 5, 2017.
Open source URL -
[3]
mitre-attack AN1883Open 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.