This chapter covers man-in-the-middle (MITM) attacks, a critical threat where an attacker secretly intercepts and relays communications between two parties. Understanding MITM is essential for the Security+ SY0-701 exam, as it falls under Objective 2.3 (Threats, Vulnerabilities, and Mitigations). We will dissect the mechanics of various MITM techniques, explore real-world examples, and discuss defenses such as encryption and certificate validation. By the end, you will be able to identify MITM scenarios and select appropriate countermeasures for the exam.
Jump to a section
Imagine you run a small business and rely on the postal service to send and receive sensitive contracts. Normally, you mail a letter, and the postal worker delivers it to the recipient. Now, suppose a malicious postal worker intercepts your letter before delivery. They open it, read the contract, alter the terms, reseal it, and then deliver the modified letter to the recipient. The recipient responds, and the same worker intercepts that reply, modifies it, and sends it back to you. You and the recipient believe you are communicating directly, but in reality, the postal worker is in the middle, reading, modifying, and forwarding every message. This is exactly how a man-in-the-middle (MITM) attack works. The attacker positions themselves between two communicating parties, intercepting and potentially altering traffic without either party's knowledge. Just as you would not know your contract was changed unless you compared notes with the recipient, in a MITM attack, the victims remain unaware because the attacker maintains the illusion of a direct connection. The key mechanism is the attacker's ability to intercept and relay messages, which in networking requires techniques like ARP spoofing, DNS spoofing, or rogue access points to insert themselves into the communication path.
What is a Man-in-the-Middle Attack?
A man-in-the-middle (MITM) attack occurs when an attacker secretly intercepts and potentially alters communication between two parties who believe they are directly communicating with each other. The attacker can eavesdrop, steal sensitive data like login credentials or financial information, or inject malicious content. MITM attacks exploit the lack of proper authentication or encryption in network communications.
How MITM Attacks Work Mechanically
The attack typically follows these steps: 1. Interception: The attacker inserts themselves into the communication path. This can be done through: - ARP Spoofing: On a local network, the attacker sends forged ARP (Address Resolution Protocol) messages to associate their MAC address with the IP address of a legitimate device (e.g., the default gateway). This causes traffic intended for the gateway to be sent to the attacker instead. - DNS Spoofing: The attacker corrupts the DNS cache or responds to DNS queries with a forged IP address, redirecting the victim to a malicious server. - Rogue Access Point: The attacker sets up a fake Wi-Fi access point with a legitimate-looking SSID, tricking users into connecting. The attacker then acts as a proxy between the victim and the internet. - Evil Twin: Similar to rogue AP, but specifically mimics a legitimate access point. 2. Decryption: If the communication is encrypted (e.g., HTTPS), the attacker must establish separate TLS sessions with the victim and the target server. The victim connects to the attacker's server (thinking it's the real server), and the attacker connects to the real server. The attacker then decrypts traffic from the victim, re-encrypts it, and forwards it to the server (and vice versa). This requires the victim to accept a forged certificate, often achieved through social engineering or by compromising a trusted CA. 3. Interception and Modification: The attacker can read, modify, or inject data into the communication stream. For example, they could alter a bank transfer destination or inject malware into a download. 4. Relay: The attacker forwards the (possibly modified) traffic to the intended recipient, maintaining the illusion of a direct connection.
Key Components and Variants
ARP Spoofing (ARP Poisoning): Targets local Ethernet networks. The attacker sends gratuitous ARP replies to associate their MAC with the gateway's IP. Tools like arpspoof (part of dsniff) or ettercap automate this.
DNS Spoofing: Also known as DNS cache poisoning. Attackers exploit vulnerabilities in DNS servers or use tools like dnsspoof to redirect traffic.
SSL Stripping: The attacker downgrades a secure HTTPS connection to HTTP by intercepting the initial request and responding with an HTTP redirect or by stripping the 'S' from HTTPS links. This allows them to view plaintext traffic. Tools like sslstrip by Moxie Marlinspike are classic examples.
Session Hijacking: After intercepting traffic, the attacker can steal session cookies and impersonate the victim on web applications.
Man-in-the-Browser (MitB): A trojan infects the browser and modifies web pages or transactions in real-time, often used in banking fraud (e.g., Zeus trojan).
MITM via Proxy: Attackers use rogue proxy servers to intercept traffic, often combined with DNS spoofing.
How Attackers Exploit MITM
Attackers typically target unencrypted or weakly authenticated communications. Common scenarios: - Public Wi-Fi: Attackers set up rogue access points in coffee shops or airports. Users connect without verifying the network's legitimacy. - Local Network: In a compromised network, ARP spoofing can redirect all traffic through the attacker's machine. - SSL/TLS Certificate Issues: If users ignore certificate warnings (e.g., clicking "Proceed anyway"), the attacker can present a self-signed certificate. - Weak Cipher Suites: If the server supports weak ciphers (e.g., RC4), the attacker can decrypt traffic after capturing it.
Defenses and Mitigations
Encryption with Strong Authentication: Use TLS with valid certificates from trusted CAs. Never ignore certificate warnings. HSTS (HTTP Strict Transport Security) forces HTTPS connections.
Certificate Pinning: Applications can pin the expected certificate or public key to prevent forged certificates.
Mutual Authentication: Both parties authenticate each other, e.g., mutual TLS (mTLS).
Network Security: Use switched networks (not hubs) to limit ARP spoofing. Enable port security and dynamic ARP inspection on switches.
VPN: A VPN encrypts all traffic between the client and the VPN server, making MITM difficult even on untrusted networks.
DNS Security: Use DNSSEC to validate DNS responses and prevent spoofing.
Intrusion Detection/Prevention: Monitor for ARP spoofing (e.g., multiple MAC addresses for one IP) or rogue access points.
User Awareness: Train users to verify HTTPS and avoid clicking through certificate warnings.
Real Command/Tool Examples
ARP Spoofing with arpspoof:
arpspoof -i eth0 -t 192.168.1.100 192.168.1.1This tells the victim (192.168.1.100) that the attacker is the gateway (192.168.1.1).
SSLstrip:
sslstrip -l 8080Listens on port 8080 and strips HTTPS from HTTP connections.
Wireshark Detection: Look for duplicate IP addresses with different MACs in ARP packets.
Bettercap: A modern framework for MITM attacks:
bettercap -eval "set arp.spoof.targets 192.168.1.100; arp.spoof on"Standards and References
RFC 826 (ARP)
RFC 5246 (TLS 1.2)
RFC 8446 (TLS 1.3)
CVE-2008-0166 (Debian OpenSSL vulnerability, weak keys)
CVE-2014-3566 (POODLE attack on SSL 3.0)
Victim connects to network
The victim connects to a public Wi-Fi network, such as a rogue access point set up by the attacker. The attacker's device acts as the access point, assigning the victim an IP address via DHCP. The victim has no reason to suspect the network is malicious, as the SSID might be familiar (e.g., 'Free Airport WiFi'). At this point, the attacker controls the network layer and can see all traffic to and from the victim. The victim's device may show a strong signal and internet connectivity, but all data passes through the attacker's machine. Tools like Wireshark on the attacker's side can capture packets immediately.
Attacker intercepts traffic
Once the victim is connected, the attacker begins intercepting traffic. If the network uses a switched infrastructure, the attacker may need to perform ARP spoofing to redirect traffic. Using a tool like `arpspoof`, the attacker sends forged ARP replies to the victim, associating the attacker's MAC address with the default gateway's IP. The victim's ARP cache is poisoned, so all outbound traffic intended for the gateway is sent to the attacker. The attacker then forwards the traffic to the real gateway after inspecting it. This interception is transparent to the victim; they still have internet access, but the attacker sees all unencrypted traffic.
Attacker performs SSL stripping
The victim attempts to visit a secure website (e.g., https://www.bank.com). The attacker's tool, such as `sslstrip`, intercepts the initial HTTPS request. Instead of forwarding it to the server, the attacker responds with an HTTP redirect (e.g., 302 Found) to an HTTP version of the site or strips the 'S' from links. The victim's browser may not notice the downgrade if it doesn't enforce HSTS. The victim then communicates with the attacker over HTTP, while the attacker establishes a separate HTTPS session with the real server. The attacker can now read all data in plaintext, including login credentials. The victim sees a padlock icon? No, it's gone or shows a warning that may be ignored.
Attacker captures credentials
The victim enters their username and password on the HTTP page (which looks identical to the real site). The attacker captures these credentials from the plaintext HTTP POST request. Tools like `tcpdump` or `Wireshark` can display the data. For example, a packet capture might show: `POST /login HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded ... username=jdoe&password=secret123`. The attacker logs these credentials and can now use them to access the victim's bank account. The victim may see a successful login page (the attacker forwards the response after logging in on their behalf), so the attack goes unnoticed.
Attacker maintains persistence
The attacker may continue to monitor the victim's session, intercepting further communications such as transaction confirmations or password changes. They can modify data in transit, e.g., change the recipient account number in a wire transfer. To avoid detection, the attacker ensures that the victim's experience remains normal. The attacker's machine must have sufficient resources to handle the traffic and avoid latency spikes. If the attacker is using ARP spoofing, they must continue sending periodic ARP replies to keep the poisoning active. Tools like `ettercap` can automate this. The attack ends when the victim disconnects or the attacker is detected (e.g., by network monitoring tools that flag duplicate IP addresses).
Scenario 1: Coffee Shop Rogue AP A security analyst at a financial institution receives an alert from the SIEM about multiple failed login attempts from an unusual IP range. The analyst investigates and finds that a customer's account was accessed from a public Wi-Fi network at a coffee shop. The analyst reviews the customer's browsing history and discovers that the customer used a network named 'CoffeeShop_Free' which was actually a rogue access point. The attacker performed SSL stripping and captured the customer's credentials. The analyst recommends implementing HSTS on the bank's website and educating customers to use a VPN on public Wi-Fi. A common mistake is to blame the customer, but the root cause is the lack of encryption enforcement.
Scenario 2: Internal ARP Spoofing A network engineer notices intermittent connectivity issues on the corporate LAN. Using Wireshark, they observe multiple ARP replies for the same IP address (the default gateway) with different MAC addresses. This indicates ARP spoofing. The engineer immediately disables the switch port where the attacker is connected and implements Dynamic ARP Inspection (DAI) on the switches. They also review logs to identify the compromised device. A common mistake is to assume the issue is a network loop or switch failure, leading to wasted troubleshooting time. Proper detection requires looking for ARP anomalies.
Scenario 3: SSL Stripping in a Man-in-the-Browser Attack A SOC analyst at a bank detects unusual transaction patterns where a user's session appears to originate from the same IP but the transaction details are modified. The user's computer is infected with a MitB trojan that intercepts HTTPS traffic using a local proxy. The trojan modifies the transaction amount and recipient before forwarding to the bank's server. The analyst uses endpoint detection tools to identify the malicious process and removes it. The bank implements mutual TLS and transaction signing to prevent such attacks. A common mistake is to attribute the fraud to a server-side vulnerability, but the issue is client-side compromise.
1. Exactly What SY0-701 Tests on This Objective Objective 2.3 covers threats, vulnerabilities, and mitigations. For MITM, the exam expects you to:
Identify MITM attack types: ARP spoofing, DNS spoofing, SSL stripping, evil twin, rogue AP, session hijacking.
Recognize scenarios: public Wi-Fi, internal network poisoning, certificate warnings.
Select appropriate mitigations: encryption (TLS), certificate validation, HSTS, VPN, DNSSEC, port security, DAI, user training.
Understand the attack mechanism: how interception, decryption, and relaying work.
2. Common Wrong Answers and Why - 'Use a hub instead of a switch': Candidates think hubs broadcast traffic, making MITM easier, but the question asks for mitigation. Hubs actually make MITM trivial, so they are not a security measure. - 'Disable SSL/TLS': Some think disabling encryption stops MITM, but encryption prevents eavesdropping. Disabling it makes MITM easier. - 'Use a firewall': Firewalls block ports but don't prevent MITM on allowed traffic. They are not a direct mitigation. - 'Implement MAC filtering': MAC filtering can be bypassed by spoofing and is not effective against ARP spoofing.
3. Specific Terms, Values, and Acronyms - ARP (Address Resolution Protocol) - DNS (Domain Name System) - SSL/TLS - HSTS (HTTP Strict Transport Security) - DNSSEC - Evil Twin - Rogue Access Point - Port 443 (HTTPS), Port 80 (HTTP) - Cipher suite - Certificate Authority (CA)
4. Common Trick Questions - 'Which attack involves intercepting traffic on a local network by sending forged ARP messages?' The answer is ARP spoofing, not DNS spoofing. - 'Which technology prevents SSL stripping?' HSTS (forces HTTPS), not just SSL/TLS. - 'What is the best defense against MITM on public Wi-Fi?' A VPN (encrypts all traffic), not just using HTTPS.
5. Decision Rule for Eliminating Wrong Answers On scenario questions, first identify the attack type (e.g., if the scenario mentions a fake Wi-Fi network, it's an evil twin or rogue AP). Then, for mitigation, choose options that enforce encryption or authentication. Eliminate answers that weaken security (e.g., disable encryption) or are not specific to MITM (e.g., antivirus). If the question says 'prevent', choose a proactive measure like HSTS or VPN; if 'detect', choose monitoring tools like Wireshark or IDS.
MITM attacks involve interception, decryption, and relay of communications.
ARP spoofing poisons the ARP cache to redirect traffic on a local network.
DNS spoofing redirects domain requests to malicious IPs.
SSL stripping downgrades HTTPS to HTTP to capture plaintext credentials.
Evil twin and rogue AP attacks trick users into connecting to fake Wi-Fi.
HSTS forces browsers to use HTTPS, preventing SSL stripping on supported sites.
VPNs encrypt all traffic, protecting against MITM on untrusted networks.
DNSSEC validates DNS responses to prevent spoofing.
Never ignore certificate warnings; they may indicate a MITM attack.
Dynamic ARP Inspection (DAI) on switches prevents ARP spoofing.
These come up on the exam all the time. Here's how to tell them apart.
ARP Spoofing
Operates at Layer 2 (Data Link)
Targets IP-to-MAC mapping
Requires local network access
Common tools: arpspoof, ettercap
Mitigation: Dynamic ARP Inspection
DNS Spoofing
Operates at Layer 3/7 (Network/Application)
Targets domain-to-IP mapping
Can be done remotely via DNS server compromise
Common tools: dnsspoof, ettercap
Mitigation: DNSSEC
Mistake
MITM attacks only happen on public Wi-Fi.
Correct
MITM can occur on any network, including corporate LANs via ARP spoofing, or even on the internet via DNS spoofing or compromised routers.
Mistake
HTTPS always prevents MITM attacks.
Correct
HTTPS prevents eavesdropping if properly implemented with valid certificates and HSTS. However, SSL stripping can downgrade HTTPS to HTTP, and users can be tricked into accepting forged certificates.
Mistake
A switch is immune to MITM because it only sends traffic to the correct port.
Correct
Switches are vulnerable to ARP spoofing, which poisons the switch's CAM table or the victim's ARP cache, redirecting traffic to the attacker.
Mistake
DNS spoofing only affects DNS servers.
Correct
DNS spoofing can target clients directly via rogue DHCP or ARP poisoning, redirecting them to malicious sites without compromising the DNS server.
Mistake
Using a VPN makes you invulnerable to MITM.
Correct
A VPN encrypts traffic between client and VPN server, but if the VPN server itself is compromised or the client connects to a rogue VPN, MITM is still possible. Also, VPN does not protect against MitB attacks.
ARP spoofing operates at Layer 2, mapping IP addresses to MAC addresses on a local network. DNS spoofing operates at Layer 3/7, mapping domain names to IP addresses, and can be performed remotely. Both redirect traffic to the attacker, but ARP spoofing requires local access, while DNS spoofing can target any user querying a compromised DNS server.
SSL stripping is a MITM technique where the attacker intercepts an HTTPS request and responds with an HTTP redirect or modifies links to use HTTP. The victim's browser then communicates over unencrypted HTTP, while the attacker maintains an HTTPS connection with the real server. The attacker can read all plaintext data. Tools like sslstrip automate this. HSTS prevents this by forcing browsers to always use HTTPS.
Yes, a VPN encrypts all traffic between the client and the VPN server, making it difficult for an attacker to intercept or modify data. However, if the VPN server is compromised or the client connects to a rogue VPN, the attack can still succeed. Additionally, a VPN does not protect against man-in-the-browser attacks where the malware runs on the client itself.
An evil twin is a rogue Wi-Fi access point that mimics a legitimate network's SSID. When users connect, the attacker can intercept all traffic. Unlike a rogue AP, the evil twin specifically impersonates a known network (e.g., 'Starbucks_WiFi'). Defenses include using a VPN and verifying network authenticity with the provider.
You can detect ARP spoofing by monitoring ARP traffic with tools like Wireshark. Look for multiple ARP replies with the same IP address but different MAC addresses, or gratuitous ARP replies from unexpected hosts. Network switches can be configured with Dynamic ARP Inspection (DAI) to validate ARP packets against a trusted database.
Certificates are used to authenticate the identity of a server in TLS. In a MITM attack, the attacker presents a forged certificate to the victim. If the victim accepts the certificate (e.g., by ignoring a warning), the attacker can decrypt and re-encrypt traffic. Proper certificate validation and pinning prevent this.
HTTPS alone is not sufficient because attackers can use SSL stripping or present forged certificates. Additional measures like HSTS, certificate pinning, and user education are necessary. On public Wi-Fi, a VPN provides an extra layer of protection.
You've just covered Man-in-the-Middle Attacks — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?