DET0320: Detection of System Network Connections Discovery Across Platforms
This detection strategy is about recognizing when a system is being queried to reveal its active network connections. That behavior matters because connect...
Analyst context for executives and security teams
This detection strategy is about recognizing when a system is being queried to reveal its active network connections. That behavior matters because connection discovery can help an intruder understand what systems, services, cloud networks, or virtual networks are reachable from a compromised host before deciding where to move next. The ATT&CK object itself is sparse, so the practical value is in validating whether SOC teams can see this discovery behavior across the related environments: ESXi, IaaS, Linux, and macOS.
Executive priority
Treat this as a visibility and response-readiness question: can the organization prove it can observe suspicious network-connection discovery on systems that support critical operations or cloud workloads? Leaders should ask whether endpoint, cloud, and infrastructure logging is sufficient to reconstruct discovery activity during an incident, and whether alerting distinguishes legitimate administration from unusual enumeration.
Technical view
DET0320 detects ATT&CK technique T1049, System Network Connections Discovery, under the Discovery tactic. Because MITRE did not provide official detection logic for this detection strategy, defenders should validate coverage using local telemetry for commands, processes, API activity, and network-related queries that enumerate connections on ESXi, IaaS, Linux, and macOS where those platforms are in scope. Detection engineering should focus on unusual connection-listing activity by unexpected users, processes, hosts, or cloud identities, especially shortly after initial access or privilege changes when that context is available.
Likely telemetry
- Endpoint process execution and command-line telemetry from Linux and macOS systems
- Administrative shell history or audit logs where available
- ESXi host management and administrative activity logs
- Cloud/IaaS control-plane logs related to virtual network, VPC, interface, route, or connection enumeration
- Network flow or connection metadata to corroborate what the system was communicating with
Detection direction
- Confirm whether current telemetry can show who or what enumerated network connections, from which host or cloud context, and when.
- Tune detections around abnormal use of connection-discovery utilities, APIs, or administrative interfaces rather than alerting on all legitimate operations.
- Correlate discovery activity with recent authentication, privilege escalation, remote access, or other suspicious events to reduce false positives.
- Pay attention to blind spots in infrastructure and cloud environments, especially ESXi and IaaS assets that may not have the same endpoint telemetry as standard workstations.
- Document gaps explicitly because the ATT&CK detection strategy provides no official detection text or analytic detail.
Mitigation priorities
- Prioritize logging and retention for endpoint, cloud, and virtualization management activity before relying on detections.
- Restrict administrative access to systems and cloud network inventory functions using least privilege and monitored roles.
- Baseline expected administrative connection-discovery behavior for operations teams to support alert tuning.
- Ensure incident response playbooks include review of network-connection discovery as a potential precursor to further discovery or movement.
- Use compliance and audit evidence to show that critical platforms have sufficient activity logging and identity attribution.
Analyst notes and limits
The strongest relationship-driven context is that this detection strategy detects T1049, System Network Connections Discovery. The related technique covers adversary attempts to list network connections from compromised or remote systems and includes cloud network mapping concepts such as Virtual Private Clouds or Virtual Networks. Since no official detection text is supplied, local environment baselines and telemetry validation are essential.
The ATT&CK detection strategy has no official description, no official detection guidance, and no platforms or tactics specified on the object itself. Platform and tactic context comes only from the related T1049 technique. This take does not assert active exploitation, actor attribution, or guaranteed detection coverage.
Detection of System Network Connections Discovery Across Platforms
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1049 | System Network Connections Discovery | This object detects System Network Connections Discovery. |
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 | c86bf415eb4e… |
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 DET0320Open 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.