Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T0852: Screen Capture

Adversaries may attempt to perform screen capture of devices in the control system environment. Screenshots may be taken of workstations, HMIs, or other devices that display environment-relevant process, device, reporting, alarm, or related data. These device displays may reveal information regarding the ICS process, layout, control, and related schematics. In particular, an HMI can provide a lot of important industrial process information. [1] Analysis of screen captures may provide the adversary with an understanding of intended operations and interactions between critical devices.

ICST0852TechniqueObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Screen Capture in an ICS environment matters because images from operator workstations, HMIs, or jump hosts can expose how a process is monitored and controlled. Even without changing a device, an adversary who captures screens may learn process layouts, alarms, reporting views, schematics, and operator workflows that can support later intrusion decisions or disruption planning.

Executive priority

Treat this as an operational intelligence risk for critical environments. Leaders should ask whether HMIs, engineering/operator workstations, and ICS jump hosts are monitored well enough to show when screen capture or remote viewing activity occurs, and whether incident responders can quickly determine what process information may have been exposed. Because ATT&CK notes mitigation may be limited or not effective for this technique, priority should be on visibility, access governance, and response readiness rather than assuming prevention alone will solve it.

Technical view

ATT&CK provides no platform or tactic directly on the technique and no official detection text, but relationship context identifies Workstations, HMIs, and Jump Hosts as targeted ICS assets. SOC and IR teams should validate coverage on Windows/Linux operator and engineering workstations, HMIs, and remote access jump hosts where applicable. The key defensive question is whether teams can distinguish legitimate operator screenshots, remote support, diagnostics, or reporting activity from unusual screen capture behavior on sensitive ICS assets.

Likely telemetry

  • Endpoint process and command execution telemetry from ICS workstations, HMIs, and jump hosts
  • Remote access and session logs for jump hosts and operator access paths
  • Authentication and user activity records tied to privileged, engineering, operator, or remote management accounts
  • File creation metadata for image files or screen-recording outputs on sensitive ICS systems
  • Application, HMI, or workstation audit logs where available

Detection direction

  • Review ATT&CK detection strategy DET0751, Detection of Screen Capture, and map it to local endpoint and remote-session telemetry.
  • Baseline legitimate screenshot, remote support, reporting, and maintenance workflows before alerting broadly, because these activities may be normal in operations.
  • Prioritize detection on HMIs, workstations, and jump hosts because those are the assets explicitly related to this technique.
  • Look for screen capture activity occurring outside expected maintenance windows, by unexpected users, or followed by file staging or transfer from the ICS environment.
  • Identify blind spots where HMIs or fixed operator stations lack endpoint logging, where jump-host sessions are not recorded or audited, or where image file creation is not centrally visible.

Mitigation priorities

  • Acknowledge that ATT&CK mitigation M0816 states this technique cannot be easily mitigated with preventative controls because it abuses system features.
  • Limit and review access to HMIs, workstations, and jump hosts that expose sensitive process information.
  • Harden and monitor remote management paths into ICS networks, especially jump hosts used to reach control-system devices.
  • Retain sufficient logs and session evidence so IR teams can determine what screens or process information may have been exposed.
  • Use operational procedures and least-necessary visibility to reduce unnecessary exposure of schematics, alarms, and process details on broadly accessible systems.
Analyst notes and limits

ATT&CK relationship context links this technique to APT33, ALLANITE, and the 2025 Poland Wiper Attacks campaign, but that should be used as threat-intelligence context only. It does not prove current activity in any given environment. The main defensive value is validating visibility and response procedures for screen capture activity on ICS-facing operator, engineering, and remote access systems.

The supplied ATT&CK object has no official detection text, no technique-level platforms, and no listed tactics. Detection and mitigation recommendations therefore depend on related assets, the DET0751 detection-strategy relationship, and local logging capabilities. Local architecture and operational procedures are required to determine actual exposure and feasible controls.

Official MITRE ATT&CK definition

Screen Capture

Adversaries may attempt to perform screen capture of devices in the control system environment. Screenshots may be taken of workstations, HMIs, or other devices that display environment-relevant process, device, reporting, alarm, or related data. These device displays may reveal information regarding the ICS process, layout, control, and related schematics. In particular, an HMI can provide a lot of important industrial process information. [1] Analysis of screen captures may provide the adversary with an understanding of intended operations and interactions between critical devices.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Associated objects

Groups, software, and campaigns

Group ICS

G0064: APT33

APT33 is a suspected Iranian threat group that has carried out operations since at least 2013. The group has targeted organizations across multiple industries in the United States, Saudi Arabia, and South Korea, with a particular interest in the aviation and energy sectors.[1][2]

Group ICS

G1000: ALLANITE

ALLANITE is a suspected Russian cyber espionage group, that has primarily targeted the electric utility sector within the United States and United Kingdom. The group's tactics and techniques are reportedly similar to Dragonfly, although ALLANITEs technical capabilities have not exhibited disruptive or destructive abilities. It has been suggested that the group maintains a presence in ICS for the purpose of gaining understanding of processes and to maintain persistence. [1]

Campaign ICS

C0063: 2025 Poland Wiper Attacks

2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]

Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
d9de54cd9321e9c0...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle d9de54cd9321…
Raw source

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 references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    ICS-CERT October 2017

    ICS-CERT 2017, October 21 Advanced Persistent Threat Activity Targeting Energy and Other Critical Infrastructure Sectors Retrieved. 2017/10/23

    Open source URL
  2. [2]
    mitre-attack T0852
    Open source URL
Source and licensing

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.