T0840: Network Connection Enumeration
Adversaries may perform network connection enumeration to discover information about device communication patterns. If an adversary can inspect the state of a network connection with tools, such as Netstat[1], in conjunction with System Firmware, then they can determine the role of certain devices on the network [2]. The adversary can also use Network Sniffing to watch network traffic for details about the source, destination, protocol, and content.
Analyst context for executives and security teams
Network Connection Enumeration matters in ICS because it helps an adversary understand which devices talk to each other, what roles they may play, and which paths connect operations technology assets. For executives and security leaders, the concern is not the enumeration tool itself; it is that normal system features can reveal the structure of control environments, including workstations, HMIs, PLCs, RTUs, data historians, control servers, gateways, VPN servers, jump hosts, switches, and firewalls.
Executive priority
Treat this as an OT visibility and resilience question: can the organization prove it knows expected communication patterns across critical ICS assets, and can the SOC recognize when a workstation, HMI, jump host, server, or embedded device is being used to map them? Because ATT&CK identifies mitigation as limited or not easily preventative, priority should shift toward asset inventory quality, network segmentation evidence, monitoring coverage, and incident response playbooks for suspicious discovery activity in operational networks.
Technical view
ATT&CK provides no official detection text and no technique-level platforms or tactics for T0840, but the relationships show broad ICS asset relevance and a detection strategy relationship, DET0770. SOC and OT defenders should validate whether they can observe host-based connection inspection behavior where supported, such as Windows or Linux workstations, HMIs, servers, VPN servers, and jump hosts, and network-based observation of source, destination, protocol, and content patterns across ICS segments. Detection should focus on deviations from known engineering, operations, and maintenance activity rather than assuming enumeration commands are always malicious.
Likely telemetry
- Host process execution and command-line telemetry on Windows/Linux ICS workstations, HMIs, application servers, control servers, jump hosts, VPN servers, and historians where available
- Network flow records showing source, destination, ports, protocols, and session timing between ICS assets
- Packet capture or deep protocol inspection where safely deployed in OT monitoring zones
- Firewall, switch, data gateway, VPN server, and jump host logs for connection attempts and cross-segment access
- Asset inventory and baseline communication maps for PLCs, RTUs, IEDs, PACs, DCS controllers, safety controllers, and servers
Detection direction
- Map expected device-to-device communication first; enumeration is most meaningful when it reveals unusual source systems, destinations, or timing against that baseline.
- Prioritize monitoring on assets that bridge trust zones, including jump hosts, VPN servers, data gateways, firewalls, historians, application servers, and control servers.
- Tune detections to account for legitimate engineering, diagnostic, maintenance, and troubleshooting activity that may also inspect network connections.
- Where host telemetry is not feasible on embedded ICS assets, compensate with passive network monitoring and boundary-device logs.
- Use relationship context from Industroyer, EKANS, and the listed campaign as a reminder that connection enumeration can appear in destructive or disruptive ICS intrusion chains, without assuming those threats are present locally.
Mitigation priorities
- Accept that ATT&CK identifies preventative mitigation as limited or not effective because the behavior abuses normal system features.
- Reduce decision risk by maintaining current asset inventories and approved communication matrices for critical ICS environments.
- Limit who can access OT workstations, jump hosts, VPN servers, servers, and diagnostic tools that can inspect connection state.
- Segment ICS networks and enforce boundary policies so enumeration from one asset exposes as little of the environment as possible.
- Preserve logs and network evidence needed for incident response before changing configurations in operational environments.
Analyst notes and limits
This technique is especially material in ICS because communication relationships often reveal operational roles. The supplied ATT&CK relationships identify many target asset classes and show use by Industroyer, EKANS, and the 2025 Poland Wiper Attacks campaign, but the object does not provide technique-level platforms, tactics, or official detection logic. Local baselines and OT architecture knowledge are therefore essential.
This take uses only the supplied ATT&CK/STIX fields and relationships. ATT&CK does not provide official detection text for T0840, and the technique itself lists no platforms or tactics. Recommendations are defensive validation directions, not claims of existing coverage, active exploitation, or customer exposure.
Network Connection Enumeration
Adversaries may perform network connection enumeration to discover information about device communication patterns. If an adversary can inspect the state of a network connection with tools, such as Netstat[1], in conjunction with System Firmware, then they can determine the role of certain devices on the network [2]. The adversary can also use Network Sniffing to watch network traffic for details about the source, destination, protocol, and content.
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
S0605: EKANS
EKANS is ransomware variant written in Golang that first appeared in mid-December 2019 and has been used against multiple sectors, including energy, healthcare, and automotive manufacturing, which in some cases resulted in significant operational disruptions. EKANS has used a hard-coded kill-list of processes, including some associated with common ICS software platforms (e.g., GE Proficy, Honeywell HMIWeb, etc), similar to those defined in MegaCortex.[1][2]
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]
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.2 | Current bundle | 90900d564e73… |
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]
Netstat
Wikipedia. (n.d.). Netstat. Retrieved May 23, 2022.
Open source URL -
[2]
MITRE
MITRE System Network Connections Discovery Retrieved. 2018/05/31
Open source URL -
[3]
mitre-attack T0840Open 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.