---
{
  "title": "Network Sniffing",
  "summary": "Network sniffing captures traffic visible to an interface or monitoring point.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1040"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1040: Network Sniffing",
      "url": "https://attack.mitre.org/techniques/T1040"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Network sniffing captures traffic visible to an interface or monitoring point. It can reveal metadata and, where protections fail, sensitive content or authentication material.


## An investigation example

A suspicious process opens capture capabilities on a host that normally does not perform network diagnostics.

## Evidence to examine

Review capture processes, interface configuration, output files, and the network segments actually visible from that host.

## A common analytical pitfall

A capture tool installed on a system does not prove capture occurred or that encrypted payloads were readable.

## Response considerations

Preserve capture artifacts and assess exposure based on actual visibility and protocol protection rather than theoretical access alone.


## A capture sees traffic available at its collection point

Network sniffing collects communication visible to an interface or monitoring path. It may support troubleshooting and authorized investigation, or it may be misused to gather information. What is visible depends on topology, switching, capture placement, encryption, and permissions. Access to one workstation does not automatically expose every packet across an organization's network.

Encrypted transport can hide payload content while leaving selected metadata observable. Conversely, some protocols or environments may expose sensitive content. Avoid both extremes: a capture is neither necessarily useless because encryption exists nor a complete view of all user activity. Describe the actual fields and conversations the evidence contains.

## A fictional unexpected capture process

An academy identifies a packet-capture process on a workstation without an approved troubleshooting request. Investigators examine process origin, interface access, output files, account context, and later file or network activity. The presence of capture software is a lead, while evidence of collected content and export supports more specific impact claims.

Approved administrators may use the same tools, so compare activity with documented work and normal management paths. Preserve relevant files under appropriate controls because they can contain unrelated private information. If a capture file is absent, do not assume no collection occurred; retention, memory-only processing, and telemetry gaps may limit the conclusion.

## Define an authorized observation

For a training network you own, write a capture scope with a purpose, interface, duration, sensitive-data handling rule, and stop condition. Alternatively, use a prepared sample. Explain what the observation point can and cannot see. Then identify the additional evidence needed to claim that a specific credential or document was obtained.

This distinction also improves incident reporting. An observed capture process, a saved packet file, sensitive content in that file, and transfer to another destination are separate facts. Connect them only where evidence supports the relationship, rather than treating the first observation as proof of every later stage.

## Related concepts

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