DET0907: Detection of Port Scan
DET0907 is a detection strategy for identifying port scanning in ICS environments. Even though the ATT&CK object provides no detailed detection logic or pl...
Analyst context for executives and security teams
DET0907 is a detection strategy for identifying port scanning in ICS environments. Even though the ATT&CK object provides no detailed detection logic or platform scope, the related technique matters because port scans can help an adversary discover live hosts, open services, operating systems, and network layout before later discovery, lateral movement, or exploitation decisions. For security leaders, the value is not just “can we alert on scans,” but whether industrial network monitoring can distinguish expected engineering or asset-management activity from unusual enumeration that could precede operational disruption.
Executive priority
Treat this as a coverage-validation item for industrial network visibility and incident readiness. Leaders should ask whether SOC and OT/ICS teams have evidence of network enumeration across critical segments, whether scanning activity is authorized and documented, and whether alerts can be investigated without disrupting operations. This also supports audit and resilience discussions: organizations should be able to show how they monitor for reconnaissance against systems, devices, or networks that support operational continuity.
Technical view
Because the official detection text and platforms are not specified, defenders should derive implementation from local ICS architecture and the related ATT&CK technique T0846.001 Port Scan. Validate that monitoring can identify one source probing many ports, many hosts, or service/OS-discovery-like patterns across ICS network zones. Tune detections against known legitimate sources such as vulnerability scanners, inventory tools, engineering workstations, and network management systems. IR teams should ensure scan findings can be pivoted into source, destination, time window, affected segment, and follow-on activity relevant to Discovery, Lateral Movement, or exploitation decision-making.
Likely telemetry
- Network flow records showing source/destination IPs, ports, protocols, timestamps, and connection outcomes
- Firewall, router, switch, or IDS/IPS logs at ICS network boundaries and internal segmentation points
- Passive network monitoring or industrial network security telemetry that can show host and service enumeration patterns
- Asset inventory or change-management records identifying authorized scanners, engineering systems, and expected management activity
- SOC case data linking scan alerts to subsequent discovery, lateral movement, or exploitation-related events when present
Detection direction
- Validate visibility at the network segments where critical systems, devices, or control networks communicate; lack of platform detail means local architecture determines coverage.
- Tune for scanning patterns rather than single connection attempts, including one-to-many host probes, many-port probes, and repeated failed or unusual connection attempts.
- Maintain allowlists or context for approved vulnerability management, inventory, engineering, and network management activity to reduce false positives.
- Investigate whether port scan alerts are followed by additional discovery, lateral movement, or exploitation-related behavior, as the related technique states scan results may inform those decisions.
- Watch for blind spots in east-west ICS traffic, unmanaged network segments, encrypted or tunneled traffic visibility gaps, and logs that are not retained long enough for incident reconstruction.
Mitigation priorities
- Establish an authorized-scanning policy for ICS environments, including approved sources, windows, scope, and operational safeguards.
- Prioritize network segmentation and monitoring at boundaries between enterprise, DMZ, and control network zones where local architecture supports it.
- Ensure asset inventory and service baselines are current so unexpected open services or new scan targets can be assessed quickly.
- Integrate detection triage with incident response playbooks that identify scan source, intent, authorization status, affected assets, and any follow-on activity.
- Use findings from recurring scans or scan detections to inform vulnerability management and exposure reduction without assuming all scanning is malicious.
Analyst notes and limits
The ATT&CK object is a detection strategy in the ICS domain and is linked to T0846.001 Port Scan. The official object does not provide a description, detection analytics, platforms, tactics, or data sources, so this take focuses on conservative, relationship-supported defensive validation and operational questions.
Coverage, alert fidelity, and risk depend on the organization’s ICS network design, monitoring placement, logging quality, and authorized scanning practices. The supplied fields do not support claims about specific platforms, active exploitation, adversary attribution, or guaranteed detection outcomes.
Detection of Port Scan
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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.
All related ATT&CK context
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 | 5160e7099ea8… |
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 DET0907Open 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.