System Network Connections Discovery is ATT&CK T1049. It belongs to the Discovery tactic and applies to ESXi, IaaS, Linux, macOS, Network Devices and Windows.
An attacker who has landed on a host wants to know what it is connected to and who else is connected to it. The answer shows servers, administrators and routes worth following.
How attackers use it
MITRE describes the goal as getting a list of network connections to or from the compromised system, or from remote systems by querying over the network. In a cloud environment, an adversary may map virtual private clouds or virtual networks to see which systems and services are connected. The actions are likely the same kinds of discovery, with results that may include details about the cloud network. Adversaries on network devices may do similar discovery.
The commands MITRE names are familiar to any administrator:
- Windows: netstat, net use and net session with the Net utility.
- macOS and Linux: netstat and lsof to list current connections, and who with the all flag and w to show who is logged in, similar to net session.
- Network devices: built-in features and the device command line, for example show ip sockets and show tcp brief.
- ESXi: a command to list active network connections.
Procedure examples reflect how ordinary this is. Several actors ran netstat with flags to show all connections, one used the net use command, one tool enumerates current connections, and in two campaigns an adversary used an AI coding assistant to map internal network architecture and access relationships.
Click through it at your own pace, or open it full screen.
How to detect it
The MITRE detection strategy is a set of analytics per environment:
- Windows: use of commands or binaries such as netstat, or PowerShell Get-NetTCPConnection, plus WMI or API calls that list local or remote connections.
- Linux: netstat, ss, lsof or custom shell scripts that list current connections, often paired with privilege escalation or staging.
- macOS: shell enumeration of active connections with netstat or lsof, or AppleScript-based system discovery.
- ESXi: shell or API use of the esxcli network connection list command, or netstat.
- Network devices: interactive or automated use of CLI commands such as show ip sockets or show tcp brief, or SNMP queries for active sessions.
- Cloud: enumeration of cloud network interfaces, VPCs, subnets or peer connections using CLI tools or SDKs.
The honest caveat is that administrators run these same commands every day. Alone, a single netstat is not a finding. It becomes one in context: a service account, a web server process or an unusual parent running it, a burst of discovery commands in one session, or discovery that sits next to credential access or staging. So log process creation with command line and parent, and use this technique as a supporting signal that raises the priority of other alerts on the same host.
For cloud, the audit log is the data source: calls that describe network interfaces, subnets and peering connections from a principal that does not usually make them.
How to reduce the risk
MITRE's page for this technique lists no dedicated mitigations, since the commands are native and legitimate. The practical defenses are the ones that limit what discovery can achieve and make it visible:
- Least privilege on cloud roles, so that a stolen identity cannot describe the whole network.
- Segmentation, so that the connection list of one host reveals little about the rest.
- Command line process logging, so that discovery commands are recorded with their parent process.
- Restricting remote shell access and the accounts that can use it.
Check your own environment
See what your own hosts would reveal. Linux, list current connections with their processes:
sudo ss -tunap
macOS and Linux, the lsof equivalent:
sudo lsof -i -nP
Windows PowerShell, list TCP connections with the owning process:
Get-NetTCPConnection | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess
Read the output as an attacker would. Does it show the address of your domain controller, your database or your admin jump host? Would that be a problem for a compromised web server? Then ask whether your logs would have recorded that the command was run, by which account and from which parent process.
Quick check
Why is a single netstat command a weak detection by itself?
Administrators run it routinely. It is useful as context, combined with who ran it, what launched it and what else happened on the host.
Name two native commands MITRE lists for listing connections on Windows.
netstat, and net use or net session through the Net utility.
