---
{
  "title": "System Network Configuration Discovery",
  "summary": "Network configuration discovery learns addresses, routes, interfaces, and related settings that describe a host's connectivity.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1016"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1016: System Network Configuration Discovery",
      "url": "https://attack.mitre.org/techniques/T1016"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Network configuration discovery learns addresses, routes, interfaces, and related settings that describe a host's connectivity. This can guide later movement or communications.


## An investigation example

An unusual process collects interface and route information just before contacting several internal services.

## Evidence to examine

Review the discovery process, interface state, logged network connections, and subsequent destination selection.

## A common analytical pitfall

Network troubleshooting commonly queries the same information; a command name alone is insufficient attribution.

## Response considerations

Investigate the sequence and responsible identity, then assess whether the discovered paths enabled unauthorized access.


## Configuration explains the host's network position

Interface addresses, routes, resolver settings, and related configuration can reveal how a host connects to its environment. This differs from listing current connections or actively probing remote services. An intruder may use the information to choose a reachable path, but the same details are essential to routine troubleshooting and device management.

Configuration can change over time through DHCP, VPN use, roaming, or administration. A collection made after the incident may not reproduce the state available earlier. Preserve the observation time and source. A private address or route does not by itself identify the person using the host or prove that a destination was contacted.

## A fictional VPN context

An academy's laptop runs an unfamiliar process that queries interface and routing information after joining a VPN. Later events show attempts to reach an internal service. Analysts compare the process ancestry, VPN session, network policy, and destination activity. They keep the configuration query distinct from the later connection attempt.

A failed route or query can also matter because it may explain why subsequent behavior stops. Investigate what the process could learn without assuming it had a complete network map. Endpoint records, central VPN logs, and configuration history may provide complementary views with different retention and accuracy.

## Read a fictional configuration

Use a prepared table with a local interface, VPN interface, default route, and DNS resolver. Explain which path would plausibly be used for a specified destination and what information is still needed. Then write an observation about a process querying the table without claiming it transferred data. This develops network context while preserving the boundary between discovery and actual communication.

Resolver and route settings are configuration claims, not guarantees that traffic followed a particular path successfully. Policy, connectivity failures, and application-specific behavior can affect the actual result. Correlate the configuration with observed traffic when the investigative question concerns communication rather than what the process learned about its environment.

## Related concepts

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