Network Sniffing is ATT&CK T1040. It maps to two tactics, Credential Access and Discovery, and applies to IaaS, Linux, macOS, Network Devices and Windows.
Sniffing means listening to traffic that was not meant for you. If the traffic is unencrypted, whatever is in it is readable, including passwords. Even if it is encrypted, the metadata still tells an attacker about your network.
How attackers use it
MITRE explains that adversaries may passively sniff network traffic to capture information about an environment, including authentication material that passes over the network. They may place a network interface into promiscuous mode to access data in transit, or use span ports to capture more. Credentials sent over an insecure, unencrypted protocol are an obvious target. Name resolution poisoning and SMB relay can also be used to capture credentials to websites, proxies and internal systems by redirecting traffic to the attacker.
Sniffing also reveals configuration details such as running services, version numbers, IP addresses, hostnames and VLAN IDs. That feeds lateral movement and stealth activity later. Adversaries may also sniff during adversary-in-the-middle activity.
In the cloud, MITRE says adversaries may use traffic mirroring services to sniff network traffic from virtual machines. It names AWS Traffic Mirroring, GCP Packet Mirroring and Azure vTap as examples that let a user define which instances to collect from and where to send the collected traffic. Often much of that traffic will be in cleartext because of TLS termination at the load balancer.
Procedure examples on the page include a network sniffer module used to collect credentials moving between a LAN and industrial control systems, the open source tool Responder used for NetBIOS name service poisoning, Wi-Fi interception by close-access teams, and packet capture used for data collection on network devices.
Click through it at your own pace, or open it full screen.
How to detect it
The MITRE detection strategy has an analytic for each environment:
- Windows: suspicious execution of network monitoring tools such as Wireshark, tshark or Microsoft Message Analyzer, driver loading that indicates promiscuous mode, and a non-admin user escalating privileges to access network interfaces for capture.
- Linux: interface mode changes to promiscuous combined with the running of sniffing tools such as tcpdump, tshark or custom pcap libraries. Also abnormal interface configurations and sniffing from non-root sessions.
- macOS: capture tools turned on through packet capture commands, or AppleScript that triggers tcpdump. Unified logs and process lineage help identify suspicious use of pfctl, tcpdump or libpcap.
- IaaS: creation of traffic mirroring sessions, such as AWS VPC Traffic Mirroring or Azure vTap, that send traffic from critical assets to other instances.
- Network devices: capture commands such as monitor capture or debug packet, or unauthorized command line access followed by logging configuration changes.
For cloud accounts, the audit log of the provider is the data source: who created or modified a mirror session, a mirror target or a mirror filter, and from where. For endpoints, process creation and driver load events. For switches, configuration change logs and checks for new span or mirror configuration.
How to reduce the risk
MITRE lists four mitigations:
- User account management. In cloud environments, do not grant permissions to create or modify traffic mirrors unless they are explicitly required.
- Multi-factor authentication. Use it wherever possible, so that a captured password is not enough.
- Encrypt sensitive information. Encrypt wired and wireless traffic as appropriate. Use best practice for authentication protocols such as Kerberos, and protect web traffic that may carry credentials with TLS.
- Network segmentation. Deny direct access to broadcasts and multicast sniffing, and prevent attacks such as name resolution poisoning and SMB relay.
Encryption is the control that changes the outcome. If the traffic is protected, a sniffer gets far less.
Check your own environment
Linux, list interfaces and see whether any is in promiscuous mode. Look for the PROMISC flag:
ip -d link show | grep -i promisc
Linux, look for capture tools that are running right now:
ps -eo pid,user,args | grep -E 'tcpdump|tshark|dumpcap' | grep -v grep
Windows PowerShell, look for capture tools in running processes:
Get-Process | Where-Object { $_.ProcessName -match 'wireshark|tshark|dumpcap|windump' }
AWS CLI, list traffic mirror sessions in a region (read-only), and check each has an owner:
aws ec2 describe-traffic-mirror-sessions
Then check the policy side:
- Which roles and users can create traffic mirror sessions?
- Which of your internal protocols still run in cleartext?
- Is multi-factor authentication turned on for the accounts whose passwords would cross the network?
Quick check
Why does terminating TLS at a load balancer matter for cloud sniffing?
MITRE notes that traffic mirrored inside the cloud is often cleartext because TLS is terminated at the load balancer. A mirror session can therefore capture readable data.
Name two mitigations MITRE lists for network sniffing.
Any two of: restrict who can create or modify traffic mirrors, use multi-factor authentication, encrypt sensitive traffic, and segment the network.
