T0846.001: Port Scan
Adversaries may perform a port scan on a system, device, or network to identify live hosts, enumerate open ports and running services, identify operating systems, and map out the network.[1] The results of a port scan may inform adversary Discovery, Lateral Movement, and vulnerability exploitation decisions (Exploitation for Evasion, Exploitation for Privilege Escalation, Exploitation of Remote Services).
Some common tools for executing a port scan include `nmap`, `netcat`, and the Advanced Port Scanner.
Analyst context for executives and security teams
Port scanning in ICS matters because it is often the reconnaissance that turns an unknown network into an actionable target list. Even when it does not directly disrupt operations, it can reveal HMIs, PLCs, RTUs, historians, control servers, gateways, VPN servers, jump hosts, firewalls, routers, and switches that could guide later discovery, lateral movement, or remote-service exploitation decisions. For executives, the key issue is whether the organization can distinguish approved engineering or asset-discovery activity from unexpected probing across operational technology networks.
Executive priority
Treat this as an OT visibility and segmentation validation issue. Leaders should ask whether critical control-system segments expose only required services, whether remote access paths such as VPN servers and jump hosts are monitored, and whether SOC/IR teams can rapidly tell who scanned what, from where, and whether the activity crossed business-to-ICS boundaries. This behavior is also useful audit evidence: network segmentation, boundary monitoring, and approved scanning/change-control records can demonstrate that discovery activity is governed rather than unmanaged.
Technical view
ATT&CK does not provide detection text for T0846.001, but it links a detection strategy, DET0907 Detection of Port Scan. SOC and detection teams should validate network-centric analytics for one source contacting many hosts or many ports, especially across ICS boundaries or against sensitive assets such as HMIs, PLCs, RTUs, IEDs, safety controllers, control servers, historians, data gateways, firewalls, switches, routers, VPN servers, and jump hosts. Triage should separate authorized tools and maintenance activity from unexpected use of common scanning utilities such as nmap, netcat, or Advanced Port Scanner. Relationship context also shows this sub-technique under Remote System Discovery and notes that scan results may inform Discovery, Lateral Movement, and exploitation decisions.
Likely telemetry
- Network flow records showing source, destination, port, protocol, timing, and connection success or failure
- Firewall, router, switch, VPN server, and jump host connection logs at ICS and enterprise/ICS boundaries
- Network IDS/IPS alerts or packet metadata for high fan-out host or port probing
- OT network monitoring or passive asset-inventory observations of new service enumeration patterns
- Endpoint/process telemetry on Windows or Linux workstations, servers, jump hosts, or engineering systems where available, especially execution of scanning tools
Detection direction
- Validate DET0907-style port-scan detection against local ICS network baselines rather than enterprise defaults alone.
- Tune for ICS context: low-volume or slow scans against embedded controllers may be more material than noisy enterprise-style scans.
- Prioritize alerts where scanning crosses segmentation boundaries, originates from remote access infrastructure, or targets safety, control, or field-device assets.
- Include false-positive handling for approved asset inventory, vulnerability assessment, commissioning, vendor support, and troubleshooting activity.
- Correlate scan activity with later authentication attempts, remote service access, discovery activity, or exploitation-related alerts to support incident scoping.
Mitigation priorities
- Apply Network Segmentation (M0930) so critical systems, functions, and resources are isolated and only required systems and services are reachable.
- Use Network Intrusion Prevention (M0931) at network boundaries where appropriate, with OT-safe configuration so blocking does not disrupt real-time control or safety communications.
- Use Static Network Configuration (M0814) where possible, while recognizing ATT&CK notes this may be constrained by device capabilities or operational network requirements.
- Maintain an approved scanning and maintenance process so defenders can quickly identify unauthorized discovery activity.
- Review exposed services on targeted ICS asset classes and reduce unnecessary access paths, especially between enterprise networks and process control systems.
Analyst notes and limits
This object is an ICS ATT&CK sub-technique of Remote System Discovery. ATT&CK relationships show it targets a broad set of ICS assets and is used by Industroyer and the 2025 Poland Wiper Attacks campaign, but those relationships should be used as context, not as evidence of current activity in any specific environment. The most defensible defensive focus is network visibility, segmentation enforcement, approved-scan governance, and OT-aware alert triage.
The supplied ATT&CK fields do not specify tactics, platforms for the technique itself, or official detection logic. Detection and telemetry recommendations therefore require local validation against available network, endpoint, and OT monitoring data. Asset criticality, normal engineering workflows, and allowable scan behavior must be determined from the local environment.
Port Scan
Adversaries may perform a port scan on a system, device, or network to identify live hosts, enumerate open ports and running services, identify operating systems, and map out the network.[1] The results of a port scan may inform adversary Discovery, Lateral Movement, and vulnerability exploitation decisions (Exploitation for Evasion, Exploitation for Privilege Escalation, Exploitation of Remote Services).
Some common tools for executing a port scan include `nmap`, `netcat`, and the Advanced Port Scanner.
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0846 | Remote System Discovery | This object subtechnique of Remote System Discovery. |
Groups, software, and campaigns
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]
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]
S1006: PLC-Blaster
PLC-Blaster is a piece of proof-of-concept malware that runs on Siemens S7 PLCs. This worm locates other Siemens S7 PLCs on the network and attempts to infect them. Once this worm has infected its target and attempted to infect other devices on the network, the worm can then run one of many modules. [1] [2]
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.0 | Current bundle | b607cce6ab06… |
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]
NIST SP 800-82r3
Keith Stouffer. (2023, September). Guide to Operational Technology (OT) Security. Retrieved April 22, 2026.
Open source URL -
[2]
mitre-attack T0846.001Open 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.