T0888: Remote System Information Discovery
An adversary may attempt to get detailed information about remote systems and their peripherals, such as make/model, role, and configuration. Adversaries may use information from Remote System Information Discovery to aid in targeting and shaping follow-on behaviors. For example, the system's operational role and model information can dictate whether it is a relevant target for the adversary's operational objectives. In addition, the system's configuration may be used to scope subsequent technique usage.
Requests for system information are typically implemented using automation and management protocols and are often automatically requested by vendor software during normal operation. This information may be used to tailor management actions, such as program download and system or module firmware. An adversary may leverage this same information by issuing calls directly to the system's API.
Analyst context for executives and security teams
Remote System Information Discovery matters because it helps an adversary determine which ICS systems are worth targeting and how to tailor later actions. In an industrial environment, make/model, role, firmware/module configuration, and peripheral details can separate harmless reconnaissance from preparation for actions against HMIs, PLCs, RTUs, safety controllers, gateways, firewalls, jump hosts, and other operational assets.
Executive priority
Treat this as an ICS situational-awareness and resilience issue, not just a scan. Leaders should ask whether the organization can distinguish normal vendor/management discovery from unusual requests, whether critical asset roles and configurations are baselined, and whether remote access paths such as VPN servers and jump hosts are monitored well enough to support incident decisions. The technique is associated in ATT&CK with multiple ICS-focused software entries and one campaign, so it is useful for prioritizing OT visibility, segmentation evidence, and incident response readiness without assuming current exposure.
Technical view
ATT&CK does not provide a technique-level platform or detection text for T0888, but the description points to requests over automation and management protocols, vendor software behavior, and direct calls to system APIs. SOC and OT teams should validate monitoring around the targeted asset classes: workstations, HMIs, PLCs, RTUs, IEDs, historians, control/application servers, data gateways, safety controllers, VPN servers, jump hosts, field I/O, switches, firewalls, DCS controllers, and PACs. Detection engineering should focus on deviations from expected engineering workstation, vendor software, management server, and control server discovery patterns.
Likely telemetry
- ICS network traffic showing automation or management protocol requests for device identity, role, model, module, firmware, or configuration details
- Asset inventory and configuration baselines for controllers, servers, network devices, and safety-related systems
- Engineering workstation, HMI, control server, historian, and application server logs where they record device browsing or management actions
- Device API, controller audit, or management interface logs where supported by the asset
- Firewall, switch, VPN server, jump host, and data gateway flow/session logs showing which systems initiate discovery and which assets respond
Detection direction
- Use the related ATT&CK detection strategy DET0787 as the starting point, but validate it against local OT protocols, asset roles, and maintenance workflows because the official technique record does not include detection logic.
- Baseline normal vendor software and engineering workstation discovery behavior; the ATT&CK description notes that similar requests are often legitimate and automatic during normal operation.
- Prioritize alerts when discovery originates from unusual hosts, remote access paths, business-network-adjacent systems, or accounts not normally used for engineering or management.
- Correlate discovery with follow-on activity against the same asset, such as configuration access, program download, firmware-related actions, or other management operations, rather than treating every information request as malicious.
- Watch for blind spots on embedded controllers, safety devices, gateways, switches, and firewalls where endpoint logging may be limited and network telemetry may be the primary evidence source.
Mitigation priorities
- Apply the related mitigation M0814 where practical: use static network configurations for hosts and devices when possible to reduce dependence on dynamic discovery/addressing that can be manipulated.
- Maintain authoritative OT asset inventories with expected role, model, configuration, and management paths so discovery anomalies can be judged quickly during an incident.
- Restrict which workstations, jump hosts, VPN paths, and management servers can query operational assets, especially controllers and safety-related devices.
- Segment and monitor management traffic between corporate, remote access, and ICS zones; ensure firewall and gateway policy evidence is available for audits and investigations.
- Account for operational constraints: ATT&CK notes that static configuration may not always be usable because of device limitations or network complexity.
Analyst notes and limits
Relationship context is broad: T0888 targets many ICS asset types and is used by ATT&CK software entries including Backdoor.Oldrea, Stuxnet, Industroyer, and INCONTROLLER, plus campaign C0063. Use those relationships to inform threat modeling and detection test cases, but do not infer that any specific environment is affected without local telemetry and asset evidence.
The supplied ATT&CK object has no tactic, platform, aliases, or official detection text. Telemetry and control recommendations therefore rely on the official description and supplied relationships, especially DET0787 and M0814, and must be adapted to the organization’s actual ICS architecture, vendor tooling, protocols, and logging capability.
Remote System Information Discovery
An adversary may attempt to get detailed information about remote systems and their peripherals, such as make/model, role, and configuration. Adversaries may use information from Remote System Information Discovery to aid in targeting and shaping follow-on behaviors. For example, the system's operational role and model information can dictate whether it is a relevant target for the adversary's operational objectives. In addition, the system's configuration may be used to scope subsequent technique usage.
Requests for system information are typically implemented using automation and management protocols and are often automatically requested by vendor software during normal operation. This information may be used to tailor management actions, such as program download and system or module firmware. An adversary may leverage this same information by issuing calls directly to the system's API.
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.
Groups, software, and campaigns
S0093: Backdoor.Oldrea
Backdoor.Oldrea is a modular backdoor that used by Dragonfly against energy companies since at least 2013. Backdoor.Oldrea was distributed via supply chain compromise, and included specialized modules to enumerate and map ICS-specific systems, processes, and protocols.[1][2][3]
S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
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]
S1072: Industroyer2
Industroyer2 is a compiled and static piece of malware that has the ability to communicate over the IEC-104 protocol. It is similar to the IEC-104 module found in Industroyer. Security researchers assess that Industroyer2 was designed to cause impact to high-voltage electrical substations. The initial Industroyer2 sample was compiled on 03/23/2022 and scheduled to execute on 04/08/2022, however it was discovered before deploying, resulting in no impact.[1]
S1045: INCONTROLLER
INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]
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]
All related ATT&CK context
Mitigation direction
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.1 | Current bundle | 299017514a2a… |
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]
mitre-attack T0888Open 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.