---
{
  "title": "System Network Connections Discovery",
  "summary": "Network connection discovery queries existing connections to learn which systems and services communicate.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1049"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1049: System Network Connections Discovery",
      "url": "https://attack.mitre.org/techniques/T1049"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Network connection discovery queries existing connections to learn which systems and services communicate. It can reveal useful destinations without an active scan.


## An investigation example

An unknown process lists active connections and shortly afterward contacts a database host seen in the results.

## Evidence to examine

Connect the query process, observed connection information, and subsequent network or credential use.

## A common analytical pitfall

Routine troubleshooting gathers the same information; enumeration becomes meaningful through the broader sequence.

## Response considerations

Identify whether discovered connections led to unauthorized access and preserve host network context before it changes.


## Existing connections reveal relationships

Inspecting current connections can show which endpoints and services a host is communicating with. This differs from actively probing other systems for services. The observation may expose business dependencies, management paths, or potential next targets, but a connection table is only a view of state at a particular time. Short-lived connections can disappear before collection.

Local and remote addresses, ports, protocol, state, and process association provide useful context where available. Shared gateways and proxies can obscure the ultimate destination. A port number alone does not identify the application with certainty, and a listed connection does not reveal its full content. Avoid overstating what the table demonstrates.

## A fictional relationship search

An academy sees an unfamiliar process enumerating connections shortly before attempting access to a file service. Investigators correlate the query with endpoint ancestry, network records, and the later authentication attempt. An administrator troubleshooting connectivity might perform a similar query, so approved support activity remains an important comparison.

Evidence from the query itself may be limited to process execution, while detailed connection state may come from another sensor. Record which source supports each fact. If a live collection occurs later, do not assume its table exactly matches what was visible to the process during the incident. State changes are central to interpreting this evidence.

## Interpret a snapshot

Use a fictional connection table with a browser, an updater, and a file-service connection. Explain what relationships are visible and which questions remain unanswered. Then add a process-execution event showing a connection query. Write a cautious finding that distinguishes enumeration from a new outbound connection or a successful attempt to access another system.

Connection ownership can be transient. Process identifiers may be reused after a process exits, so correlate the identifier with time and other process context rather than matching a number from unrelated snapshots. This detail can prevent attributing a network relationship to the wrong executable during a later review.

## Related concepts

- [[digital-forensics]]
- [[incident-timeline]]
- [[logs-and-telemetry]]
- [[command-and-scripting-interpreter]]