Network Sniffing (Packet Sniffing)

ATT&CK files network sniffing under two tactics, Credential Access and Discovery, and that matches how it is used. The first goal is credentials. MITRE lists APT33 and Kimsuky using SniffPass, Sandworm Team using intercepter-NG, and the BlackEnergy sniffer module in the 2015 Ukraine power attack, where it collected credentials passing between the corporate LAN and the control systems. The second goal is a map: running services, version numbers, IP addresses, hostnames and VLAN IDs that make later lateral movement easier.

It also feeds neighboring techniques. Responder, used by APT28, poisons name resolution so hosts send hashes to the attacker, and MITRE places that and SMB relay next to sniffing because they put credentials on the wire where a capture can read them. Sniffing also supports Adversary-in-the-Middle work, where the attacker watches the traffic they have redirected.

Where it happens tells you how deep the intruder is. A capture tool on a user laptop points to an opportunist or an insider. A sniffer on a VPN gateway, load balancer or router means the attacker already has administrative control of infrastructure, and Salt Typhoon, which MITRE credits with capturing packet data between network interfaces, is the reference case. DarkVishnya went another way. Kaspersky documented it attacking banks through devices connected directly to the local network.

Sniffing tools are everyday tools. Network and application teams run Wireshark and tcpdump to chase latency and TLS problems, and captures on servers usually start with a support call. Installing Nmap or Wireshark brings the Npcap driver along, which is why a wpcap.dll load on its own is weak evidence. IDS and NDR sensors, including Zeek and Suricata hosts, run in promiscuous mode on purpose, and Docker, KVM and Linux bridges flip interfaces to promiscuous every time a container or VM starts. Cloud security teams also create traffic mirror sessions legitimately, often from infrastructure as code.

Build the allowlist around who and where, not what. List the accounts and roles that manage monitoring, the sensor hosts that should be promiscuous and the engineers allowed to capture on production servers, then alert on everything outside that list. A capture tool on a domain controller, a database server or a jump host deserves a ticket check even for approved staff, because those are the machines whose traffic is worth reading.

Because capturing is passive, response is mostly about what the attacker could read. Pull the capture file if the tool wrote one, such as the netsh trace output or a pcap in a temp folder, and open it: it shows exactly what was collected. For a cloud mirror, record the session, target and filter IDs before deleting anything, export the CloudTrail or activity log events, and examine the target. Which instance or load balancer received the copy, who owns it, and where did it send the data next?

Then scope the exposure by protocol. Rotate any credential that crossed the monitored segment in cleartext: Telnet and FTP logins, HTTP basic authentication, SNMP community strings, LDAP simple binds and, if the sniffer sat on a device that carries TACACS+, the device administration credentials. Work out how the actor got in, whether through an IAM policy that grants ec2:CreateTrafficMirrorSession, a network device login or local admin on a host, because that is the compromise you are actually investigating.

On network gear, pull the running configuration and AAA logs, diff against the last known good and check for logging changes made around the same time. If a sniffer implant turns up on a load balancer or VPN appliance, reimage from vendor media instead of cleaning in place, and assume anything that authenticated through that device while the implant ran is exposed.