On-Path Attacks — Concepts

On-Path Attack vs. On-Path Browser Attack — Side-by-Side

Property	On-Path Attack (ARP Poisoning)	On-Path Browser Attack
Attack Location	Network — attacker device on the same subnet	Local — malware on the victim's own device
Mechanism	ARP cache poisoning redirects traffic through attacker's device	Browser-hooking malware intercepts before/after encryption
Scope	All traffic between two network devices on the same subnet	All browser activity on the infected device
HTTPS Bypassed?	Not directly — HTTPS content is still encrypted; attacker sees ciphertext unless they also strip TLS	Yes — malware intercepts before TLS encryption and after decryption; plaintext is exposed
Victim Awareness	None — traffic still reaches intended destination	None — browser shows legitimate site; padlock is present
Attacker Location Required	Same subnet as victims	Anywhere — malware delivered remotely
Detection Method	ARP cache inspection, anomalous ARP traffic in packet capture	Endpoint security; behavioral analysis of browser process
Primary Mitigation	Dynamic ARP Inspection (DAI), network segmentation	Endpoint protection, patching, out-of-band transaction verification

Normal ARP Operation — Step by Step

1. Laptop needs to reach the router — Laptop (IP: 192.168.1.9, MAC: …38:d5) wants to send traffic to the router at 192.168.1.1; checks ARP cache; no entry found

2. ARP broadcast — Laptop broadcasts ARP request to entire subnet: "Who has IP 192.168.1.1? Tell me your MAC address." All devices on the subnet receive this frame

3. Router responds — Router (IP: 192.168.1.1, MAC: …BB:FE) recognizes its own IP; sends unicast ARP reply directly to the laptop: "I am 192.168.1.1, my MAC is BB:FE"

4. ARP cache update — Laptop stores the mapping in its ARP cache: 192.168.1.1 → BB:FE; subsequent traffic to 192.168.1.1 uses MAC BB:FE without broadcasting again

5. Communication proceeds — Laptop frames are addressed to MAC BB:FE; switch delivers them to the router; router processes them and replies; traffic flows normally

ARP Poisoning Attack — Step by Step

1. Attacker joins the subnet — Attacker device (IP: 192.168.1.14, MAC: …EE:FF) connects to the same local subnet as the target laptop and router; no special access required

2. Send forged ARP reply to laptop — Attacker sends unsolicited ARP reply to the laptop: "I am 192.168.1.1, my MAC is EE:FF." No ARP request was made — the attacker initiates this unprompted. The laptop receives it and updates its ARP cache: 192.168.1.1 → EE:FF (overwrites BB:FE)

3. Send forged ARP reply to router — Attacker simultaneously sends unsolicited ARP reply to the router: "I am 192.168.1.9, my MAC is EE:FF." Router updates its ARP cache: 192.168.1.9 → EE:FF (overwrites 38:d5)

4. Traffic redirected through attacker — Laptop sends traffic to "the router" — looks up 192.168.1.1, gets EE:FF, delivers frames to attacker. Router sends traffic to "the laptop" — looks up 192.168.1.9, gets EE:FF, delivers frames to attacker

5. Attacker relays traffic — Attacker reads all intercepted traffic, then forwards it to the real destination using the real MAC addresses; both endpoints receive their traffic normally and neither detects the interception

6. Continuous poisoning — ARP cache entries expire; attacker repeatedly sends poisoned ARP replies to keep both caches updated with the false MAC address and maintain the on-path position indefinitely

ARP — Why No Authentication

ARP was designed in the early 1980s when networks were small, trusted environments. The protocol has no provision for verifying that an ARP reply actually comes from the device that legitimately holds the IP address claimed. Any device can send an ARP reply claiming any IP. Receiving devices have no mechanism to check the claim's authenticity — they simply update their caches with whatever they receive.

This is a protocol design limitation, not a bug or misconfiguration. ARP poisoning attacks have been known for decades and remain viable on networks that haven't deployed switch-level controls like Dynamic ARP Inspection. The fundamental ARP protocol itself has never been modified to add authentication — the fix is implemented at the switch layer, not in the protocol.

Subnet boundary constraint: ARP only operates within a single Layer 2 network segment (subnet). ARP frames are not routed — they cannot cross router boundaries. An attacker must be physically on the same subnet as both victims. This is why network segmentation is a critical defense.

On-Path Browser Attack — How It Bypasses HTTPS

1. Malware delivery — Victim installs browser-hooking malware via phishing email, drive-by download, or fake software update; malware integrates into the browser at the API level

2. Intercept point — before encryption — Browser application formats a request (login credentials, bank transfer); before it reaches the TLS layer for encryption, the malware intercepts it in plaintext

3. Normal HTTPS flow continues — Malware allows the traffic to proceed; TLS encrypts it normally; the server receives a legitimate HTTPS request; certificate is valid; everything looks normal from the network perspective

4. Intercept point — after decryption — Server's HTTPS response arrives; TLS decrypts it; before the browser renders it to the user, the malware intercepts the plaintext response

5. Malicious action — Malware waits for banking login success; captures session token; silently initiates a background transaction (fund transfer) using the active session; victim's browser shows normal account page

6. Invisible to network monitoring — The attack is entirely local to the victim's device; packet captures, network security tools, and firewall logs show only legitimate HTTPS traffic; the attack is undetectable from the network layer

Why HTTPS Doesn't Stop On-Path Browser Attacks

HTTPS (TLS) creates an encrypted tunnel between the browser and the server. This protects data in transit — an attacker intercepting network traffic sees only ciphertext. But HTTPS operates at the TLS layer, between the browser and the network.

An on-path browser attack installs itself between the browser's application logic and the TLS layer — above the encryption. The malware sees all data before it enters the encrypted tunnel (outbound) and after it exits the tunnel (inbound). From the browser's perspective, it's communicating with the legitimate server over a legitimate HTTPS connection. From the server's perspective, it's receiving legitimate requests from the legitimate user. The padlock icon is accurate — the connection is encrypted. But the malware is reading the plaintext on both sides of the encryption.

Exam tip: "HTTPS prevents all on-path attacks" is false. HTTPS prevents network-layer interception of data in transit. It does not prevent on-path browser attacks, which operate inside the victim's own device before encryption is applied.

Defense Stack

Control	Attack Addressed	How
Dynamic ARP Inspection (DAI)	ARP poisoning	Switch validates ARP replies against the DHCP snooping binding table; drops spoofed ARP entries; attacker's poisoned ARP replies never reach victims' caches
DHCP Snooping	ARP poisoning (supports DAI)	Builds the trusted IP-to-MAC-to-port binding table that DAI uses for validation; also prevents rogue DHCP servers
Network Segmentation / VLANs	ARP poisoning	ARP operates within a subnet boundary; separating devices into different VLANs prevents an attacker on one segment from poisoning devices on another
Static ARP Entries	ARP poisoning	Manually configured ARP mappings for critical devices (routers, servers) cannot be overwritten by received ARP replies; prevents poisoning of those specific entries
802.1X Port Authentication	ARP poisoning	Ensures only authenticated devices can connect to network ports; prevents attacker from connecting a rogue device to the network
HTTPS / TLS	Network-layer on-path attacks	Encrypts data in transit; a network-level on-path attacker sees ciphertext rather than plaintext; does not stop on-path browser attacks
Endpoint Protection Software	On-path browser attacks	Detects and removes browser-hooking malware before it can intercept sessions; behavioral analysis identifies API-hooking patterns
Patching / Updates	On-path browser attacks	Most browser malware exploits known, patched vulnerabilities; keeping browsers and OS current closes the delivery vector
Out-of-Band Transaction Verification	On-path browser attacks	SMS or separate app confirmation for financial transactions; browser malware can't intercept a confirmation sent to a separate device

ARP Poisoning — Subnet Boundary Limitation

Scenario	ARP Poisoning Possible?	Why
Attacker on same /24 subnet as victim	Yes	ARP operates within the subnet; attacker can send ARP replies to all devices on the segment
Attacker on a different VLAN	No	VLANs are separate Layer 2 domains; ARP frames don't cross VLAN boundaries
Attacker on a different subnet, separated by a router	No	Routers do not forward ARP frames; ARP is scoped to one network segment
Attacker connected to same physical switch, same VLAN	Yes	Same Layer 2 domain; ARP frames reach all ports in the VLAN
Attacker connected via VPN to the internal network	Depends	If the VPN gives the attacker an IP on the target subnet without Layer 2 isolation, ARP may be reachable; properly implemented VPN gateways segment Layer 2

On-Path Attack Concepts