Man-in-the-Middle

What It Is and Why Encryption Alone Does Not Stop It

• A Man-in-the-Middle (MITM) attack occurs when an adversary positions themselves between two communicating parties, intercepting and potentially altering the traffic without either party knowing.
• MITRE ATT&CK maps MITM to T1557 (Adversary-in-the-Middle) with sub-techniques T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay) and T1557.002 (ARP Cache Poisoning).
• The core concept: Alice thinks she is talking directly to Bob. In reality, she is talking to the attacker, and the attacker is talking to Bob.

MITM Sub-Techniques — How Each One Works

ARP Cache Poisoning (T1557.002)

The most common MITM technique on local networks.

How it works:

1. Attacker sends forged ARP packets to the target host, claiming that the attacker’s MAC address corresponds to the gateway IP
2. Target’s ARP cache is updated: 192.168.1.1 → AttackerMAC
3. All traffic from the target to the internet now goes through the attacker
4. Attacker forwards traffic to the real gateway silently — neither side knows the interception is happening

Tools: Ettercap, Bettercap, Cain & Abel — also used in insider threat scenarios

Detection indicators:

• Dual MAC entries in the ARP table — one IP address mapped to two different MAC addresses
• ARP table entries for the gateway that do not match the known gateway MAC
• A host sending ARP replies without first receiving ARP requests (gratuitous ARP from unknown hosts)
• Rapidly changing MAC:IP mappings in ARP cache over a short period

PowerShell — check for ARP cache poisoning:

# Compare ARP table entries against known-good gateway MAC
arp -a | findstr "192.168.1.1"
# Expected: 192.168.1.1 xx-xx-xx-xx-xx-xx (single entry only)
# Suspicious: multiple IPs sharing the same MAC, or gateway MAC unknown

SPL query — detect ARP anomalies from network flow:

index=network sourcetype=arp
| stats values(MAC) as MACAddresses, dc(MAC) as UniqueMACs by IP
| where UniqueMACs > 1
| eval alert = "HIGH — ARP cache poisoning: IP " . IP . " resolves to " . UniqueMACs . " MAC addresses"
| table IP, MACAddresses, UniqueMACs, alert

LLMNR/NBT-NS Poisoning (T1557.001)

How it works:

1. A user mistypes a hostname — fileservre instead of fileserver
2. Windows falls back to LLMNR (Link-Local Multicast Name Resolution) or NBT-NS (NetBIOS Name Service) to resolve the name
3. The attacker’s machine responds to the multicast query, claiming to be fileservre
4. The user’s machine connects to the attacker, who then captures the credentials (typically NTLMv2 hash via SMB)

Detection indicators:

• Multiple LLMNR or NBT-NS responses from a single IP for different queried names
• The responder IP is not a DNS server
• Failed name resolution (Event ID 9001, 9002 — DNS client events) followed by NTLM authentication to an unexpected IP

SPL query — detect LLMNR responder behavior (a common precursor to credential theft in hybrid clouds):

index=windows sourcetype=dnsserver
| search EventCode IN (9001, 9002) (DNS resolution failure)
| eval time_window = bin(_time, 60)
| join type=inner time_window, ClientIP [search index=network sourcetype=smb_auth (NTLM authentication events)
| stats values(DestinationIP) as SMB_IPs by time_window, SourceIP]
| search SMB_IPs NOT IN (known_dns_servers)
| eval alert = "HIGH — possible LLMNR poisoning: DNS failure followed by SMB auth to non-DNS server"

SSL/TLS Stripping (Relevant to API Attacks)

How it works:

1. Attacker intercepts the initial HTTP connection before it upgrades to HTTPS
2. Attacker strips the Upgrade-Insecure-Requests header and Strict-Transport-Security header
3. Victim continues using HTTP to the attacker’s proxy
4. Attacker proxies traffic to the real server over HTTPS — but the victim’s traffic is plaintext

Detection indicators:

• Users report “This connection is not secure” warnings for sites they normally use over HTTPS
• Inconsistent HTTPS enforcement — a site that normally redirects to HTTPS suddenly stays on HTTP
• Missing HSTS header on a normally HSTS-enabled site

Evil Twin (Rogue Access Point)

How it works:

1. Attacker sets up a Wi-Fi access point with the same SSID as a legitimate network
2. Victim’s device connects to the rogue AP (stronger signal or no authentication required)
3. All victim traffic passes through the attacker’s device

Detection indicators:

• Two access points with the same SSID but different BSSID (MAC) visible
• Access point with the same SSID on a different channel than the legitimate AP
• Deauthentication frames (Wi-Fi disconnection packets) observed — attacker may be deauthing clients from the legitimate AP to force them to reconnect through the rogue AP

Detection Workflow — MITM Investigation

Step 1: Confirm the Attack Vector

Step 2: Check the Attacker’s Position

In a L2 MITM attack (ARP poisoning, evil twin), the attacker must be on the same local network segment. Check:

• Are any new or unexpected devices on the network?
• Are any devices running packet capture or MITM tools (Ettercap, Wireshark in promiscuous mode)?
• Check DHCP logs — were any new MAC addresses issued IPs recently?

Step 3: Isolate the Affected Host

Step 4: Determine Disposition

Prevention

Related

• Wireless Attacks — detection and response for T1600 techniques
• Network Security Basics — detection and response for T1040, T1046 techniques
• Snort and Suricata — detection and response for T1040 techniques
• Wireshark — detection and response for T1040 techniques

Sources

• MITRE ATT&CK T1557
• CrowdStrike MITM Attacks
• CISA Securing Network Infrastructure
• OWASP — MITM Attacks
• SANS — ARP Poisoning Detection