Network Attacks — MITM, Sniffing, ARP Poisoning, DNS Hijacking

Every packet that crosses a network trusts the infrastructure beneath it. ARP tables assume other devices are honest. DNS answers assume resolvers haven't been poisoned. BGP routes assume peers announce their own prefixes. TCP sessions assume nobody is watching the sequence numbers. These assumptions are decades old, designed for a cooperative academic network — and attackers have been exploiting them ever since.

This module goes to the wire. You'll understand exactly how a Man-in-the-Middle attack positions itself between two hosts, how ARP poisoning works at the Ethernet frame level, how DNS and BGP hijacking redirect entire networks, and what the capture looks like in Wireshark when it happens. By the end, you'll know how to detect these attacks and what controls actually stop them.

The Anatomy of a Man-in-the-Middle Attack

A Man-in-the-Middle (MITM) attack is not a single technique — it is a position that an attacker achieves. Once positioned between two communicating parties (Alice and Bob), the attacker can read, modify, drop, or replay every message in transit. Neither Alice nor Bob knows they are not talking directly to each other.

The attacker needs two things: a mechanism to intercept traffic (ARP poisoning, rogue Wi-Fi, DNS hijacking) and optionally a mechanism to terminate and re-originate the connection (SSL stripping, sslsplit). Without the second step, encrypted traffic remains unreadable even when intercepted.

MITM position (conceptual):

  Alice ──────────→ Attacker ──────────→ Bob
         ←──────────         ←──────────

  Alice thinks she's talking to Bob.
  Bob thinks he's talking to Alice.
  Attacker sees all plaintext, can modify in transit.

Classic MITM variants:
  Passive:  Capture only — sniff credentials, session tokens
  Active:   Modify content — inject malicious JS, change amounts
  Relay:    Forward everything unchanged — stay invisible
  Drop:     Selectively block packets — cause partial failures

The most common MITM setup on a local network uses ARP poisoning to intercept. On the internet, BGP hijacking, DNS hijacking, or SSL stripping serve the same purpose at larger scale. Each technique exploits a different trust assumption baked into internet protocols.

ARP Poisoning — Hijacking the Local Network

The Address Resolution Protocol (ARP) maps IP addresses to MAC addresses within a LAN segment. When Alice (192.168.1.10) wants to send a packet to the gateway (192.168.1.1), she broadcasts: "Who has 192.168.1.1? Tell 192.168.1.10." The gateway replies with its MAC address. Alice caches this in her ARP table.

The critical weakness: ARP has no authentication. Any host can send an unsolicited ARP reply claiming any IP-to-MAC mapping, and most operating systems will accept and cache it without question. This is called a Gratuitous ARP.

Normal ARP exchange:

  Alice (192.168.1.10)  →  BROADCAST: "Who has 192.168.1.1?"
  Gateway (192.168.1.1) →  UNICAST:   "192.168.1.1 is at aa:bb:cc:dd:ee:ff"
  Alice caches:  192.168.1.1 → aa:bb:cc:dd:ee:ff

ARP poisoning attack:

  Attacker sends to Alice:
    "192.168.1.1 is at 11:22:33:44:55:66"  (attacker's MAC)

  Attacker sends to Gateway:
    "192.168.1.10 is at 11:22:33:44:55:66" (attacker's MAC)

  Result:
    Alice → Gateway traffic now flows:
    Alice → Attacker → Gateway → Alice (invisible relay)

  Attacker's ARP table manipulation:
    Alice's ARP:   192.168.1.1 → 11:22:33:44:55:66  ← poisoned
    Gateway ARP:   192.168.1.10 → 11:22:33:44:55:66 ← poisoned

The attacker must keep sending these spoofed ARP replies because ARP cache entries expire (typically 10-20 minutes). Tools like arpspoof (part of dsniff) and Ettercap automate this continuously. The attacker also enables IP forwarding on their machine so that intercepted packets are actually delivered to the destination — otherwise the connection breaks and the victim notices.

# Tool: arpspoof (for authorised lab use only)
# Poison Alice's ARP cache (tell Alice that gateway is at our MAC)
arpspoof -i eth0 -t 192.168.1.10 192.168.1.1

# Simultaneously poison gateway's ARP cache
arpspoof -i eth0 -t 192.168.1.1 192.168.1.10

# Enable IP forwarding so packets actually reach their destination
echo 1 > /proc/sys/net/ipv4/ip_forward

# Now all Alice↔Gateway traffic flows through us
# Capture with tcpdump or Wireshark on eth0

Detection in Wireshark:
  Filter: arp.duplicate-address-detected
  or:     arp.opcode == 2 && arp.src.hw_mac != expected_mac

Detection via arp -a (victim machine):
  $ arp -a
  gateway (192.168.1.1) at 11:22:33:44:55:66 [ether]
  ← if gateway's real MAC is aa:bb:cc:dd:ee:ff, this is poisoned

Packet Sniffing — What Wireshark Sees

Once positioned in the traffic path, an attacker captures packets with a packet analyser (sniffer). Wireshark is the standard tool. Understanding what it sees — and what it can't — is essential for both offense and defense.

What a sniffer captures in plaintext (no TLS):
  - HTTP: full URLs, headers, body, cookies, form submissions
  - FTP: username + password in clear
  - Telnet: every keystroke including passwords
  - SMTP/POP3/IMAP (without STARTTLS): email body + creds
  - DNS: all queries and responses (domain lookups)

What remains opaque with TLS:
  - The encrypted payload (HTTPS body, data)
  - Session cookies and auth tokens (inside TLS)

What TLS doesn't hide:
  - IP source/destination (visible in IP header)
  - Port numbers
  - Packet sizes and timing (traffic analysis)
  - SNI (Server Name Indication) — the hostname you're visiting
    (now hidden with Encrypted Client Hello / ECH in TLS 1.3+)

Useful Wireshark display filters:
  http                         # all HTTP traffic
  http.request.method == POST  # form submissions
  dns                          # all DNS queries/responses
  tcp.port == 443              # HTTPS traffic
  ip.addr == 192.168.1.50      # traffic to/from one host
  frame contains "password"    # literal string search

Network interfaces operate in promiscuous mode during sniffing — the NIC accepts all frames on the wire, not just those addressed to its MAC. On a switched network (which is almost everything today), you normally only see broadcast traffic and your own unicast traffic. ARP poisoning solves this by routing traffic through you, making promiscuous mode effective for targeted captures.

# tcpdump — command-line capture for servers/headless systems
# Capture all traffic on eth0, save to file
tcpdump -i eth0 -w capture.pcap

# Capture only HTTP (port 80) traffic
tcpdump -i eth0 port 80 -w http.pcap

# Capture traffic to/from a specific host
tcpdump -i eth0 host 192.168.1.50

# Read a saved capture file
tcpdump -r capture.pcap

# Decode packet payloads as ASCII (-A) or hex+ASCII (-X)
tcpdump -i eth0 -A port 80

# Analysis workflow for incident response:
1. tcpdump -r capture.pcap -nn | head -100     # quick overview
2. Open in Wireshark for GUI analysis
3. Statistics > Protocol Hierarchy               # what protocols are present?
4. Statistics > Conversations                    # who talked to whom?
5. Follow TCP Stream                             # reassemble full conversations

SSL Stripping — Downgrading HTTPS to HTTP

TLS encryption protects intercepted traffic — but only if the connection is actually using TLS. SSL stripping, developed by Moxie Marlinspike in 2009, exploits the moment before TLS is established. When a user types "amazon.com" (without https://), the browser initially sends a plaintext HTTP request. The attacker intercepts this, makes their own HTTPS connection to the real server, then serves the victim a plain HTTP page. The victim's browser shows a padlock-less connection and many users don't notice.

SSL Stripping flow:

  Victim's browser:  HTTP GET http://amazon.com/
                     ↓
  Attacker:          Receives plaintext HTTP request
                     Makes HTTPS connection to real amazon.com
                     Receives HTTPS response
                     Rewrites all "https://" links → "http://"
                     Serves modified HTTP response to victim
                     ↓
  Victim sees:       Page looks normal but browser bar shows http://
                     No padlock. All form submissions in plaintext.

Defence — HSTS (HTTP Strict Transport Security):
  Server sends header:
    Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

  Browser remembers: "Only ever use HTTPS for this domain"
  HSTS preload list: browser ships with ~100K domains hard-coded as HTTPS-only

  SSL stripping fails against HSTS-preloaded domains because the browser
  refuses to send the initial HTTP request at all.

HSTS preloading is the definitive defence against SSL stripping. Major sites (google.com, facebook.com, amazon.com) are all on the preload list. As a developer, you should submit your domain to hstspreload.org once you're committed to full HTTPS deployment.

DNS Hijacking — Redirecting at the Name Layer

While ARP poisoning works at Layer 2 within a LAN, DNS hijacking works at Layer 7 and can affect victims at any scale — from a single device to an entire country's internet traffic. DNS hijacking redirects DNS queries so that a legitimate domain name resolves to an attacker-controlled IP address.

The Kaminsky attack (2008) was the most significant DNS vulnerability discovered before DNSSEC became widespread. Dan Kaminsky found that an attacker could flood a recursive resolver with forged DNS responses (guessing the transaction ID), poisoning its cache with a malicious NS record that redirected an entire domain. The fix was source port randomisation — making the attacker guess both the 16-bit transaction ID and the 16-bit source port, expanding the brute-force space from 65,536 to 4 billion combinations.

DNS cache poisoning (Kaminsky attack concept):

Target: Poison resolver's cache for example.com

Attacker races to respond to resolver's upstream query:
  1. Trigger resolver to look up random.example.com
  2. Flood with forged responses:
     Transaction ID: 0001, Answer: example.com NS → evil.ns.
     Transaction ID: 0002, Answer: example.com NS → evil.ns.
     Transaction ID: 0003, Answer: example.com NS → evil.ns.
     ... (65536 attempts — 50% success in ~few seconds on old resolvers)
  3. First correct guess poisons cache for TTL duration
  4. All users using this resolver now resolve example.com via evil.ns

Defences:
  - DNSSEC: Authoritative server signs records with private key
             Resolver verifies signature — forged responses rejected
  - DNS-over-HTTPS (DoH) / DNS-over-TLS (DoT): Encrypt DNS transport
  - Source port randomisation: Already standard since Kaminsky disclosure
  - 0x20 encoding: Mix case in queries (exAmple.com) — forged responses
                   must match exactly, harder to predict

BGP Hijacking — Rerouting the Internet

Border Gateway Protocol (BGP) is how internet routers exchange routing information — which IP prefixes are reachable via which autonomous systems (ASes). There are ~75,000 autonomous systems on the internet, each announcing their IP address ranges. BGP assumes every peer is honest. It has no cryptographic authentication of route announcements.

A BGP hijack happens when an attacker (or misconfigured router) announces a more-specific prefix for someone else's IP space. Because BGP prefers the most-specific prefix, traffic destined for the victim's IPs gets routed to the attacker's network instead.

BGP hijacking concept:

Legitimate: Amazon AS16509 announces 54.0.0.0/8 (owns this range)
            All internet traffic to 54.x.x.x routes to Amazon

Hijack:     Attacker AS99999 announces 54.239.0.0/16
            More-specific prefix — BGP prefers it
            Traffic to 54.239.x.x now goes to attacker

Real incident — MyEtherWallet (April 2018):
  - Amazon Route53 DNS servers are on specific IP ranges
  - Attackers hijacked Route53 DNS server IPs via BGP
  - All MyEtherWallet DNS queries went to attacker's DNS server
  - Attacker returned their own IP for myetherwallet.com
  - Victims landed on phishing site with invalid TLS cert
  - Users who clicked through lost ~$152,000 in cryptocurrency

  Duration: ~2 hours before detected and withdrawn
  Affected: ~1,300 Ethereum transactions

Defence — RPKI (Resource Public Key Infrastructure):
  - Each IP prefix owner signs a Route Origin Authorization (ROA)
  - ROA states: "Only AS16509 may announce 54.0.0.0/8"
  - Routers with RPKI validation reject unauthorized announcements
  - Adoption: ~50% of global prefixes covered (growing)

Detection:
  - BGPmon.net: Real-time BGP hijacking alerts
  - RIPE NCC RIS: Route collector network with historical data
  - Prefix hijack detection: Unexpected new origin AS in BGP table

TCP-Level Attacks — SYN Floods and Session Hijacking

TCP's handshake and state machine expose two classic attack surfaces: the SYN flood exhausts server connection state, and TCP session hijacking exploits predictable or known sequence numbers to inject data into an established connection.

TCP 3-way handshake:
  Client → Server: SYN (seq=100)
  Server → Client: SYN-ACK (seq=200, ack=101)
  Client → Server: ACK (ack=201)
  ← Connection established ←

SYN flood attack:
  Attacker sends thousands of SYN packets (spoofed source IPs)
  Server allocates state for each half-open connection (SYN_RCVD)
  Server sends SYN-ACK to spoofed IPs — never gets ACK back
  Half-open connections fill the backlog queue
  Legitimate connections are dropped: connection timed out

SYN flood defence — SYN Cookies:
  Server does NOT allocate state on receiving SYN
  Server encodes session info into the sequence number of SYN-ACK
  If client sends ACK with correct sequence number → legitimate
  Only then does server allocate connection state
  Cost: server state only for completed handshakes
  Enable: sysctl net.ipv4.tcp_syncookies=1 (Linux)

TCP session hijacking:
  Requires: MITM position + ability to observe sequence numbers

  1. Attacker observes Alice ↔ Server connection
     Learns current seq/ack numbers from captured packets
  2. Attacker sends forged TCP segment to Server:
     Source IP: Alice's IP
     Seq number: correct next expected value
     ACK number: correct value
     Data: malicious payload (e.g., rm -rf /tmp/*)
  3. Server accepts the packet as if from Alice
  4. Alice receives unexpected ACK, connection desynchronises

  Defence: TLS encrypts payload AND authenticates source — forged
           segment payload is rejected by TLS record layer

Modern operating systems generate cryptographically random initial sequence numbers (ISNs), which makes blind TCP session hijacking (without a MITM position) extremely difficult. But if an attacker already has a MITM position and can observe the sequence numbers in plaintext, the sequence randomness doesn't help — which is why the fundamental defence is TLS, not TCP-level mitigations.

Network Reconnaissance — nmap, Wireshark, tcpdump

Before an attacker launches network attacks, they map the target network. The three most important tools are nmap (host discovery and port scanning), Wireshark (packet capture and analysis), and tcpdump (command-line capture). Defenders use the same tools for network inventory and incident response.

# nmap — network mapper
# Host discovery (find live hosts on subnet)
nmap -sn 192.168.1.0/24

# Port scan (top 1000 ports)
nmap -sV 192.168.1.10

# Full port scan with OS detection and service versions
nmap -sV -sC -O -p- 192.168.1.10

# Stealthy SYN scan (doesn't complete handshake)
nmap -sS 192.168.1.10

# UDP scan (slower — common for DNS/SNMP discovery)
nmap -sU -p 53,161 192.168.1.10

# Aggressive scan with scripts
nmap -A 192.168.1.10

# Output to all formats (grepable, XML, normal)
nmap -oA scan_results 192.168.1.0/24

# nmap scan types and what they tell you:
#  -sS  SYN scan:    open (SYN-ACK), closed (RST), filtered (no response)
#  -sV  Version:     banner grab to identify service and version
#  -sC  Scripts:     run default NSE scripts (vuln checks, info gathering)
#  -O   OS detect:   fingerprint OS from TCP/IP stack behaviour

# Interpreting nmap output:
PORT     STATE    SERVICE  VERSION
22/tcp   open     ssh      OpenSSH 8.9p1 Ubuntu
80/tcp   open     http     nginx 1.22.0
443/tcp  open     ssl/http nginx 1.22.0
3306/tcp filtered mysql
8080/tcp closed   http-proxy

# open:     Service is listening, connection accepted
# filtered: Firewall dropping packets (no response)
# closed:   Port reachable but no service listening

# Common ports to check:
21   FTP (often anonymous login)
22   SSH (brute force target)
23   Telnet (plaintext, should not exist)
25   SMTP (relay open?)
53   DNS (zone transfer possible?)
80   HTTP (application enumeration)
443  HTTPS
445  SMB (EternalBlue, ransomware spread)
3306 MySQL (exposed to internet?)
3389 RDP (BlueKeep, brute force)
5985 WinRM (lateral movement)
6379 Redis (often no auth)
9200 Elasticsearch (often no auth)

Rogue Access Point and Evil Twin Attacks

Wireless networks add an entirely new interception surface. A rogue access point is an unauthorised Wi-Fi AP plugged into a corporate network — it gives attackers a wireless entry point into the wired LAN. An evil twin is a Wi-Fi AP that impersonates a legitimate network by using the same SSID (and optionally the same BSSID), tricking clients into connecting to the attacker instead.

Evil twin attack flow:

1. Reconnaissance
   Attacker discovers target SSID: "CoffeeShop_WiFi"
   Notes the BSSID (MAC): aa:bb:cc:dd:ee:ff
   Notes the channel: 6

2. Create evil twin AP
   Set up hostapd with SSID "CoffeeShop_WiFi"
   Optionally spoof BSSID to match legitimate AP
   Broadcast on same or adjacent channel with higher power

3. Deauthentication attack (force clients to reconnect)
   Send spoofed 802.11 deauth frames to clients on legitimate AP
   Clients disconnect and scan for same SSID
   Evil twin AP is loudest — clients connect to attacker

4. Capture credentials
   If captive portal: clients log in → harvest credentials
   If WPA2: capture 4-way handshake → offline crack
   If open network: MITM all traffic

WPA2 handshake capture:
  airmon-ng start wlan0           # enable monitor mode
  airodump-ng wlan0mon            # scan for networks
  airodump-ng -c 6 --bssid aa:bb:cc:dd:ee:ff -w capture wlan0mon
  aireplay-ng --deauth 10 -a aa:bb:cc:dd:ee:ff wlan0mon
  # When client reconnects, WPA2 4-way handshake is captured
  # Offline crack: hashcat -m 22000 capture.hc22000 wordlist.txt

Defence:
  - 802.1X (WPA3-Enterprise): Mutual authentication — clients verify AP cert
  - Wi-Fi deauth protection: 802.11w (Management Frame Protection)
  - Corporate: Wireless IDS (detect rogue APs and deauth floods)
  - Always use VPN on untrusted Wi-Fi (tunnel encrypts everything)

Detection and Defence — Layered Network Security

Network attacks require a layered defence. No single control stops all attack variants. The goal is to make each attack either impossible (cryptographic controls) or detectable (monitoring controls) before significant damage occurs.

# Dynamic ARP Inspection (DAI) — Cisco switch config
ip dhcp snooping                     # Enable DHCP snooping (builds IP-MAC table)
ip dhcp snooping vlan 10             # On VLAN 10

interface GigabitEthernet0/1         # Uplink to router
 ip dhcp snooping trust              # Trust this port (allow all ARP)

interface GigabitEthernet0/2         # Client port
 ip arp inspection limit rate 100    # Max 100 ARP packets/second
 ! Untrusted by default — DAI validates against DHCP snooping table

# Network Segmentation — limit blast radius
# If ARP poisoning succeeds on VLAN 10, attacker can only
# MITM traffic within VLAN 10. Cross-VLAN traffic goes
# through a router/firewall where ARP doesn't apply.

# Zero Trust Network Access (ZTNA):
# Assume network is hostile. Authenticate every connection.
# Mutual TLS (mTLS) — both sides present certificates
# Software-defined perimeter — no implicit trust by network location

Workplace Scenario — MITM Detected on Corporate Wi-Fi

A financial services firm's SOC receives an alert from their network anomaly detection system: a workstation on the trading floor (192.168.50.45) is sending ARP replies at 800 packets/second. Normal hosts send fewer than 10 ARP packets per minute.

Incident timeline:

09:14 — Alert: ARP flood from 192.168.50.45 (MAC: de:ad:be:ef:00:01)
         "Possible ARP cache poisoning attack detected"

09:15 — SOC analyst checks Wireshark capture from network TAP:
         Frame 4412: 192.168.50.45 tells 192.168.50.12:
           "192.168.50.1 (default gateway) is at de:ad:be:ef:00:01"
         Frame 4413: 192.168.50.45 tells 192.168.50.1:
           "192.168.50.12 is at de:ad:be:ef:00:01"
         → Bidirectional ARP poisoning confirmed

09:16 — Check what's on 192.168.50.45:
         DHCP lease: "TRADING-WS-07" (Windows workstation)
         Asset DB: Assigned to trader John D., desk 4-C

09:17 — Was the machine compromised, or is this a rogue device?
         MAC de:ad:be:ef:00:01 is NOT in DHCP snooping table
         DHCP snooping table shows TRADING-WS-07 has MAC 08:00:27:1a:2b:3c
         → Different MAC — rogue device plugged into desk 4-C's port

09:18 — Check switch port:
         Switch port GigE2/0/47 shows TWO MACs (port-security violation)
         08:00:27:1a:2b:3c (legitimate WS)
         de:ad:be:ef:00:01 (attacker device)

09:19 — Physical investigation: Security camera footage shows
         unknown laptop plugged into network jack under desk 4-C at 08:52

09:20 — Remediation:
         Shutdown port GigE2/0/47 (isolates rogue device)
         Enable port-security max-mac-addresses 1 on all access ports
         Review: was any plaintext traffic captured during 09:00–09:19?
         Check: HTTP traffic in 19-minute window for credential exposure

The attacker had physical access — a 19-minute window between plugging in the rogue laptop and detection. The key defences that limited the damage: DHCP snooping identified the MAC mismatch, DAI generated the ARP flood alert, and most internal traffic used TLS so credential exposure was limited to legacy HTTP endpoints.

Interview Questions

Error Library — Common Mistakes

In Module 11, you go inside the malware. How ransomware encrypts files and why paying doesn't guarantee recovery. How rootkits hide from the operating system at ring-0. How Remote Access Trojans (RATs) establish C2 channels, how worms self-replicate across networks, and how modern EDR tools detect each family based on behavioral signatures rather than file hashes.