MITRE ATT&CK T1040 Network Sniffing Guide

Any credential, token or service account password that crosses a network in cleartext can be collected by an attacker who controls one interface, one switch port, one cloud mirroring session or one router CLI on the path. MITRE ATT&CK tracks this as T1040 Network Sniffing, a technique in both the Credential Access (TA0006) and Discovery (TA0007) tactics, on IaaS, Linux, macOS, Network Devices and Windows. This guide is the defender view: where sniffing happens today (endpoints, cloud traffic mirroring and network device packet capture), the signals that reveal it, the controls that make captured traffic worthless, and how to respond. It is written for detection engineers, network and cloud security teams, and identity teams responsible for machine credentials. For the network monitoring you run yourself, see the Network Monitoring and Packet Capture Guide; for network security architecture, see ISO/IEC 27033.

Key takeaways

Sniffing is passive, so detect the setup, not the listening. You will rarely see a packet being read; you can see promiscuous mode, capture tools starting, new mirroring sessions and capture commands on routers.
Cloud mirroring is the modern span port. ATT&CK names AWS Traffic Mirroring, Google Cloud Packet Mirroring and Azure virtual network TAP as ways to copy VM traffic, and notes that traffic behind TLS-terminating load balancers is often cleartext.
Network devices can capture too. Router and switch features such as Cisco Embedded Packet Capture (monitor capture) turn a compromised admin session into a sniffing point.
Encryption is the control that matters most. If every protocol carrying credentials is encrypted and authenticated, sniffing yields metadata, not secrets.
Machine credentials are the soft target. Legacy service protocols, SNMP community strings, basic-auth API calls and internal HTTP between services often carry non-human credentials in the clear long after human logins moved to TLS.

How the technique works

ATT&CK v20 (technique version 1.7) describes adversaries passively capturing traffic to collect information, including authentication material. The technique has no sub-techniques, but the description covers four distinct collection points, each with its own preconditions and telemetry.

Collection point	How it is done (per ATT&CK)	Attacker precondition	Best telemetry
Host interface	Placing a network interface into promiscuous mode, or using capture libraries on a compromised host	Local admin or root, or a user with capture rights (for example membership of a capture group)	Process creation, driver or service install, interface flag changes
Switch span port	Using span ports to capture a larger amount of data	Admin access to the switch, or physical access to a port already spanned	Device configuration change logs, AAA command accounting
Cloud traffic mirroring	AWS Traffic Mirroring, Google Cloud Packet Mirroring, Azure virtual network TAP copying VM traffic to a target the attacker controls	A cloud identity allowed to create mirroring sessions, policies or TAP configurations	Cloud control plane audit logs
Network device CLI	Capture commands such as `monitor capture` through T1059.008 Network Device CLI	A privileged device account, often from stolen or default credentials	Syslog, TACACS+ command accounting

ATT&CK links sniffing to T1557.001 Name Resolution Poisoning and SMB Relay, which redirects traffic to the attacker so it can be captured, and to T1557 Adversary-in-the-Middle. The difference matters for detection: AiTM changes the traffic path and leaves active traces, while pure sniffing only copies traffic. For the active side, see MITRE ATT&CK T1557 Adversary-in-the-Middle and LLMNR and NBT-NS Poisoning. Beyond credentials, ATT&CK notes that sniffing reveals running services, version numbers, IP addresses, hostnames and VLAN IDs used to plan lateral movement, which is why it also sits in Discovery.

The cloud mirroring path in detail

Cloud traffic mirroring deserves its own section because it needs no foothold on the victim VM at all: a cloud identity with the right permissions can copy traffic from a production instance to a collector it controls. ATT&CK adds that the adversary can then move the captured data out with T1537 Transfer Data to Cloud Account. Each provider's feature is a legitimate monitoring tool; treat creating it as a privileged action.

Providers are listed alphabetically.

Provider and feature	Building blocks (from provider docs)	Permission to control	What to alert on
AWS Traffic Mirroring	A session ties one source (an elastic network interface), one filter and one target. Targets are another instance's network interface, a Network Load Balancer with a UDP listener, or a Gateway Load Balancer with a UDP listener. Mirrored packets are VXLAN-encapsulated. Source and target can be in peered VPCs or VPCs joined by a transit gateway.	`ec2:CreateTrafficMirrorSession`, which AWS shows restricted by resource to a named traffic mirror target, plus the filter and network interface resources	CloudTrail `CreateTrafficMirrorSession` and `ModifyTrafficMirrorTarget` (the events in the ATT&CK analytic), especially to a target in another VPC or account
Azure virtual network TAP	A TAP configuration on a VM network interface streams traffic to a destination IP (a VM network interface or internal load balancer) in the same or a peered virtual network. One TAP resource can aggregate traffic across subscriptions, including cross-tenant. As of November 2026 Microsoft lists the feature as public preview in selected regions.	Network Contributor, or a custom role with `Microsoft.Network/virtualNetworkTaps/` and `Microsoft.Network/tapConfigurations/`	Activity log writes on `virtualNetworkTaps` and `tapConfigurations`; any cross-tenant destination
Google Cloud Packet Mirroring	A policy names mirrored sources (by subnet, network tag or instance name) and a collector: an instance group behind an internal passthrough Network Load Balancer. By default all IPv4 traffic, headers and payloads, is mirrored. Mirroring a subnet covers future instances too. Google now recommends Network Security Integration Packet Mirroring for new deployments.	`compute.packetMirroringAdmin` on the mirrored sources and `compute.packetMirroringUser` in the collector's project	Admin Activity audit log entries creating or updating packet mirroring policies; subnet-wide policies

Two provider details shape detection. Google states that VPC Flow Logs do not log mirrored packets, so the copy is invisible in flow data and only the control plane shows it. Google also states mirrored traffic is encrypted only if the application encrypts it, which is the ATT&CK point about TLS terminated at the load balancer: traffic from the balancer to the backend is often plain HTTP carrying session cookies, bearer tokens and API keys.

Where non-human identities fit

Human sign-ins mostly moved to TLS and phishing-resistant MFA years ago. Machine traffic often did not. The credentials most likely to still cross internal networks in the clear are non-human:

Service-to-service HTTP: bearer tokens and API keys in headers between microservices, or between a load balancer and its backends. Mutual TLS or a service mesh closes this; see the mTLS Guide.
Network management protocols: SNMPv1 and v2c community strings, Telnet and unencrypted TACACS+ or RADIUS traffic between devices and servers. See the SNMP Security Guide.
Legacy Windows authentication: NTLM challenge-response captured from the wire can be cracked offline or relayed. See the NTLM Deprecation and Elimination Guide.
Database and directory binds: application service accounts binding to LDAP on port 389 without signing or StartTLS, or connecting to databases without TLS.
The mirroring identity itself: the cloud role or service principal that can create mirror sessions is a high-value NHI. Scope it like any privileged credential.

Our recommendation at NHI Mgmt Group: treat any secret seen in a capture as compromised and rotate it, then fix the transport. Rotating without encrypting just hands the attacker the next secret.

Detection

ATT&CK detection strategy DET0314 (Detection Strategy for Network Sniffing Across Platforms) gives one analytic per platform. The table turns them into rules you can build, with the tuning values ATT&CK marks as environment-specific.

Platform	Signal	Log source	Tune for
Windows	Capture tools starting (Wireshark, tshark and similar); a capture driver installed as a service	Security event 4688 (process creation), System event 7045 (service installed); EDR process telemetry	Approved tools list, approved admin hosts
Linux	Interface flag changed to PROMISC; tcpdump, tshark or custom pcap processes, especially from non-root or unexpected sessions	auditd execve and ioctl records; kernel messages about promiscuous mode; interface state from `ip link`	Interfaces that legitimately run promiscuous (IDS sensors, bridges)
macOS	tcpdump or libpcap use, access to BPF devices, unified log messages mentioning promiscuous	Unified log, osquery process events, Endpoint Security process events	Developer and network admin machines
IaaS	New mirroring session, policy or TAP, or a changed target	AWS CloudTrail, Azure Activity Log, Google Cloud Admin Activity audit logs	Known monitoring collectors and the identities that deploy them
Network devices	Capture commands such as `monitor capture` or debug packet commands; admin login followed by logging changes	Syslog, AAA command accounting	Change windows, named network engineers

Device-side captures are short-lived: on Cisco IOS and IOS XE, Embedded Packet Capture runs from exec mode, holds packets in DRAM, is not saved to the configuration and is lost on reload, and buffers can be exported as PCAP to a remote server (Cisco's example uses TFTP). Configuration backups will not show it; only command accounting will. An export to an unfamiliar file transfer host is a strong follow-on signal. The Network Device Syslog and Configuration Change Detection Guide covers the logging pipeline.

On the network side, flag cleartext credential protocols wherever they appear: Telnet (23), FTP (21), HTTP basic authentication, LDAP simple binds on 389 and SNMPv1 or v2c (161). Protocol metadata tools such as Zeek log these without full capture. This does not detect the sniffer, but it measures what a sniffer would get.

Response when sniffing is found

Preserve: capture the process tree, interface state and any pcap files on the host; export the cloud audit events and the mirror session, policy or TAP definition before deleting it; pull device command accounting.
Contain: remove the mirror session or TAP, kill the capture process, disable the cloud identity or device account used, and isolate any collector instance the attacker controlled.
Scope: list every source interface or subnet mirrored and the time window, then identify which protocols on those paths carried credentials in cleartext.
Rotate: rotate every secret that could have crossed those paths during the window, starting with service account passwords, API keys and SNMP communities.
Fix the transport: encrypt the protocols that leaked, so the same collection would yield nothing next time.

Prevention

ATT&CK maps four mitigations to T1040. Each is listed with the concrete work behind it.

Mitigation	ATT&CK guidance	Concrete controls
M1041 Encrypt Sensitive Information	Encrypt wired and wireless traffic; use strong authentication protocols such as Kerberos; protect web traffic carrying credentials with TLS	TLS to the backend, not only to the load balancer; LDAPS or LDAP signing; SNMPv3 authPriv; SSH instead of Telnet; disable NTLM where possible; MACsec on high-value links (see MACsec)
M1018 User Account Management	Do not grant permission to create or modify traffic mirrors unless explicitly required	Remove broad network roles; restrict mirror actions to a named monitoring role; deny them by organisation policy outside the monitoring account
M1030 Network Segmentation	Deny direct access to broadcasts and multicast sniffing, and prevent name resolution poisoning	Private VLANs, port security, 802.1X on access ports (see 802.1X and EAP-TLS Enterprise Wi-Fi Guide), disable LLMNR and NBT-NS
M1032 Multi-factor Authentication	Use MFA wherever possible	Phishing-resistant MFA so a sniffed password alone is not enough; short-lived tokens for machines so a sniffed token expires quickly

Restrict capture rights on hosts too: limit who can install capture drivers on Windows, keep capture capabilities on Linux to named admin groups, and keep packet capture tools off servers that do not need them. Lock down device AAA so only a small group can run capture or debug commands; see the Network Device Management Plane Hardening Guide.

Implementation sequence

The phases and timings below are NHI Mgmt Group recommendations; adjust them to your estate.

Measure exposure first (weeks 1 to 2): run protocol metadata collection on core segments and list every cleartext credential protocol and the identities using it. This is your baseline and your priority list.
Lock down mirroring (weeks 2 to 4): inventory existing mirror sessions, packet mirroring policies and TAPs; remove unknown ones; restrict create rights to one monitoring role; alert on every create or modify event.
Turn on host analytics in alert-only mode (weeks 3 to 6): deploy the Windows, Linux and macOS rules, tune out approved IDS sensors and admin workstations, then raise severity.
Enable device command accounting (weeks 4 to 8): send TACACS+ accounting and syslog to the SIEM and alert on capture and debug commands outside change windows.
Encrypt by priority (ongoing): start with protocols carrying privileged or machine credentials. Test each change in a pilot segment; keep the old listener available for a fixed rollback window, then remove it.
Rotate and verify: rotate credentials that were sent in cleartext, then confirm with fresh metadata that they no longer appear.

Decision guidance

Small organisations: skip host sniffing analytics at first. Focus on encryption (no Telnet, FTP, SNMPv2c or plain LDAP) and on alerting for cloud mirroring creation, which is cheap and high signal.
Large or regulated estates: add host and device analytics, and run mirroring only from a dedicated monitoring account with its own guardrails.
TLS termination choice: terminating at the load balancer and sending plain HTTP to backends is simpler but leaves tokens readable to anyone who can mirror backend traffic. Re-encrypt to the backend where the traffic carries credentials.
Your own monitoring: your IDS and capture platform is itself a sniffer full of credentials. Restrict and log access to stored captures as you would a secrets store.

Measuring progress

Number of distinct cleartext credential flows observed per week (target: falling to zero for privileged and machine accounts).
Percentage of mirror sessions, policies and TAPs with a named owner and change record (target: 100%).
Number of identities able to create mirroring resources (target: one role per cloud).
Percentage of network devices sending command accounting to the SIEM.
Mean time to triage a promiscuous mode or capture tool alert.

Common failure patterns

Encrypting the edge only: TLS ends at the load balancer and tokens travel in the clear inside the VPC, exactly the case ATT&CK describes for mirrored cloud traffic.
Relying on flow logs: Google states mirrored packets are not in VPC Flow Logs; mirroring is only visible in audit logs.
Broad network admin roles: network contributor style roles quietly include mirroring rights, so many identities can sniff without anyone noticing.
No command accounting on devices: device captures leave nothing in the saved configuration, so configuration diffing misses them.
Rotating without fixing the protocol: the new secret is captured the same way.
Unprotected capture archives: stored pcaps from your own tools become the easiest place to harvest credentials.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK	T1040; TA0006, TA0007; mitigations M1041, M1018, M1030, M1032; detection strategy DET0314	Technique, tactics and defender guidance
NIST SP 800-53 Rev 5	SC-8 and SC-8(1) Transmission Confidentiality and Integrity, Cryptographic Protection	Encrypt credentials in transit
NIST SP 800-53 Rev 5	AC-6 Least Privilege; CM-7 Least Functionality	Limit mirroring rights and capture tools
NIST SP 800-53 Rev 5	SI-4 System Monitoring; AU-12 Audit Record Generation	Host, cloud and device telemetry
NIST CSF 2.0	PR.DS-02; DE.CM-01	Data in transit protected; networks monitored

Practitioner checklist

List every cleartext credential protocol on your networks and the accounts using it.
Inventory and own every cloud mirror session, packet mirroring policy and virtual network TAP.
Restrict mirroring create and modify rights to one monitoring role per cloud.
Alert on mirroring control plane events, especially cross-account or cross-tenant targets.
Detect promiscuous mode and capture tools on Windows, Linux and macOS, with an approved list.
Send device command accounting to the SIEM and alert on capture and debug commands.
Re-encrypt from load balancers to backends where traffic carries tokens or keys.
After any finding, rotate exposed machine credentials and fix the transport.

MITRE ATT&CK T1040 Network Sniffing: Detecting and Preventing Credential Theft