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

T0829: Loss of View

Adversaries may cause a sustained or permanent loss of view where the ICS equipment will require local, hands-on operator intervention; for instance, a restart or manual operation. By causing a sustained reporting or visibility loss, the adversary can effectively hide the present state of operations. This loss of view can occur without affecting the physical processes themselves. [1] [2] [3]

ICST0829TechniqueObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Loss of View is an ICS impact behavior where operators lose sustained visibility into equipment or process state, potentially requiring local hands-on intervention such as restart or manual operation. The business issue is not just a monitoring outage: decision-makers may be forced to run, stop, or recover physical operations without trusted remote visibility, which can affect safety, service continuity, and incident response confidence.

Executive priority

Prioritize this as an operational resilience and crisis-management scenario for industrial environments. Leaders should ask whether critical sites can continue safe operations when normal ICS visibility is unavailable, whether alternate communications and local operating procedures are tested, and whether recovery evidence exists for audits and incident reviews. The ATT&CK relationships to ICS campaigns and malware show this behavior is relevant to real-world industrial incident analysis, but local exposure depends on the organization’s architecture and telemetry.

Technical view

SOC, OT security, and incident response teams should validate how they would recognize and respond to sustained loss of reporting or visibility without assuming the physical process has stopped. ATT&CK provides no official detection text or platform list for this technique, but it does identify a related detection strategy, DET0763 Detection of Loss of View. Defensive validation should focus on loss of HMI, historian, engineering workstation, controller, sensor, or communications visibility; discrepancies between expected and observed process data; and whether operators have an independent way to confirm the actual process state. Relationship context includes mitigations for out-of-band communications, redundancy of service, and hardened recoverable backups/gold images.

Likely telemetry

  • ICS network communication availability and integrity indicators between operator stations, HMIs, servers, controllers, and field equipment
  • HMI, historian, control server, and I/O server health/status logs where available
  • Controller or device communication status, alarms, and stale-data indicators
  • Operator alarm/event records showing loss of view, communications failure, or manual/local intervention
  • Backup, configuration, and recovery records for key systems supporting view or availability

Detection direction

  • Validate DET0763-aligned monitoring for sustained visibility loss, not only device compromise or process disruption.
  • Alert on stale, missing, or inconsistent process reporting where the system continues to appear operational but trusted visibility is degraded.
  • Tune detections to distinguish planned maintenance, network outages, device failure, and cyber-driven visibility loss; false positives are likely without maintenance and operations context.
  • Correlate cyber telemetry with operator reports and physical/field confirmation because ATT&CK notes loss of view can occur without directly affecting the physical process.
  • Review relationship-driven context from associated campaigns/software for detection engineering hypotheses, but do not assume the same tooling or platform applies unless present locally.

Mitigation priorities

  • Establish and test out-of-band communications channels for control-room, field, and incident-response coordination during communications failures or data integrity concerns.
  • Prioritize redundancy for critical ICS devices and services that support operator visibility, including backup devices or hot-standby capabilities where appropriate.
  • Maintain hardened, separated backups and exercised recovery plans, including gold-copy images and configurations for systems whose loss affects control, view, or availability.
  • Document manual/local operating procedures for sites where sustained visibility loss would require hands-on intervention.
  • Use exercises to prove that operators, SOC, and incident responders can decide safely when normal ICS visibility is unavailable.
Analyst notes and limits

This take is based on ATT&CK technique T0829 Loss of View in the ICS domain, external references cited by MITRE, and supplied relationships. ATT&CK links this technique to DET0763, mitigations M0810, M0811, and M0953, and multiple campaigns/software entries, which supports treating it as a practical OT resilience scenario rather than a purely technical alert condition.

The official object provides no ATT&CK tactics, platforms, aliases, labels, or detection text. Specific detections, affected assets, severity, and response playbooks must be validated against the local ICS architecture, operator procedures, network design, and available telemetry.

Official MITRE ATT&CK definition

Loss of View

Adversaries may cause a sustained or permanent loss of view where the ICS equipment will require local, hands-on operator intervention; for instance, a restart or manual operation. By causing a sustained reporting or visibility loss, the adversary can effectively hide the present state of operations. This loss of view can occur without affecting the physical processes themselves. [1] [2] [3]

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

Malware ICS

S0607: KillDisk

KillDisk is a disk-wiping tool designed to overwrite files with random data to render the OS unbootable. It was first observed as a component of BlackEnergy malware during cyber attacks against Ukraine in 2015. KillDisk has since evolved into stand-alone malware used by a variety of threat actors against additional targets in Europe and Latin America; in 2016 a ransomware component was also incorporated into some KillDisk variants.[1][2][3][4]

LinuxWindows
Malware ICS

S1157: Fuxnet

Fuxnet is malware designed to impact the industrial network infrastructure managing control system sensors for utility operations in Moscow. Fuxnet is linked to an entity referred to as the Blackjack hacking group, which is assessed to be linked to Ukrainian intelligence services.[1]

Input/Output ServerControl Server
Malware ICS

S0372: LockerGoga

LockerGoga is ransomware that was first reported in January 2019, and has been tied to various attacks on European companies, including industrial and manufacturing firms.[1][2]

Windows
Malware ICS

S0604: Industroyer

Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]

Windows
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]

Campaign ICS

C0031: Unitronics Defacement Campaign

The Unitronics Defacement Campaign was a collection of intrusions across multiple sectors by the CyberAv3ngers, where threat actors engaged in a seemingly opportunistic and global targeting and defacement of Unitronics Vision Series Programmable Logic Controller (PLC) with Human-Machine Interface (HMI). The sectors that these PLCs can be commonly found in are water and wastewater, energy, food and beverage manufacturing, and healthcare. The most notable feature of this attack was the defacement of the PLCs' HMIs.[1][2]

Campaign ICS

C0041: FrostyGoop Incident

FrostyGoop Incident took place in January 2024 against a municipal district heating company in Ukraine. Following initial access via likely exploitation of external facing services, FrostyGoop was used to manipulate ENCO control systems via legitimate Modbus commands to impact the delivery of heating services to Ukrainian civilians.[1][2]

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
7a060518a2b124e9...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 7a060518a2b1…
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]
    Corero

    Corero Industrial Control System (ICS) Security Retrieved. 2019/11/04

    Open source URL
  2. [2]
    Michael J. Assante and Robert M. Lee

    Michael J. Assante and Robert M. Lee SANS Industrial Control System (ICS) Security; The Industrial Control System Cyber Kill Chain Retrieved 2024/11/25

    Open source URL
  3. [3]
    Tyson Macaulay

    Tyson Macaulay Michael J. Assante and Robert M. Lee Corero Industrial Control System (ICS) Security Retrieved. 2019/11/04 The Industrial Control System Cyber Kill Chain Retrieved. 2019/11/04 RIoT Control: Understanding and Managing Risks and the Internet of Things Retrieved. 2019/11/04

    Open source URL
  4. [4]
    mitre-attack T0829
    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.