Advisory: ARP Poisoning — Network-Layer On-Path Interception via Unauthenticated Address Resolution
Executive Summary
ARP (Address Resolution Protocol) poisoning positions an attacker's device between two communicating parties on the same local network segment, enabling silent interception, reading, and optional modification of all traffic passing between them. The attack exploits a fundamental design characteristic of ARP: the protocol has no authentication mechanism and will accept unsolicited replies from any source. An attacker who continuously sends forged ARP replies causes both victim devices to cache the attacker's MAC address as the destination for each other's traffic. All communication flows through the attacker. Both victims observe normal network operation. This advisory documents the attack mechanics using specific network addressing, the detection approach, and the controls required to eliminate the vulnerability.
Technical Analysis — ARP Protocol Background
IPv4 networks use IP addresses for logical addressing but use MAC (hardware) addresses for physical frame delivery within a subnet. When a device needs to communicate with another device on the same subnet, it must resolve the target's IP address to its MAC address before it can construct an Ethernet frame. This resolution is performed by ARP.
Normal ARP operation: a device broadcasts an ARP request to all devices on the subnet — "Who has IP 192.168.1.1? Tell me your MAC address." The device with that IP responds directly with its MAC address. The requesting device stores this IP-to-MAC mapping in its ARP cache. Subsequent frames to that IP are delivered directly to the cached MAC address without further ARP requests.
ARP's vulnerability: the protocol accepts replies to requests it has not sent (gratuitous ARP), and it has no mechanism to verify that the replying device actually owns the claimed IP address. Any device can send an ARP reply claiming any IP-to-MAC mapping at any time, and receiving devices will update their cache accordingly.
Attack Walkthrough — Network Addresses
| Device | IP Address | Legitimate MAC | After Poisoning (victim's cache) |
|---|---|---|---|
| Victim laptop | 192.168.1.9 | …:38:d5 | — |
| Router (gateway) | 192.168.1.1 | …:BB:FE | Laptop's cache: 192.168.1.1 → EE:FF (attacker) |
| Attacker device | 192.168.1.14 | …:EE:FF | — |
Attack sequence: the attacker at 192.168.1.14 (MAC …:EE:FF) sends continuous unsolicited ARP replies to the laptop at 192.168.1.9, claiming: "I am 192.168.1.1. My MAC address is EE:FF." The laptop updates its ARP cache, associating the router's IP with the attacker's MAC. Simultaneously, the attacker sends mirror-image replies to the router, claiming: "I am 192.168.1.9. My MAC address is EE:FF." The router updates its cache for the laptop's IP.
Result: all frames from the laptop addressed to the router are now delivered to the attacker's MAC address. The attacker reads them and forwards them to the real router MAC (…:BB:FE). Responses follow the reverse path — from the router to EE:FF (attacker), then forwarded to the laptop. The attacker is silently inline on every conversation. Both the laptop and router observe the network as functioning normally.
ARP poisoning is scoped to a single subnet — ARP does not cross router boundaries. An attacker must be on the same Layer 2 network segment as the victims. This scope requirement is why network segmentation is the structural defense.
Detection Indicators
- Anomalous ARP traffic in packet capture: gratuitous (unsolicited) ARP replies arriving at high frequency from a single source; the same MAC address appearing in ARP replies for multiple different IP addresses (one attacker claiming to be many devices)
- Duplicate IP or MAC warnings from switch management interfaces or network monitoring tools
- ARP cache entries on victim devices showing the router IP mapped to a MAC address that does not match the router's actual hardware — detectable by comparing the ARP cache to known device inventory
- DHCP snooping binding table mismatches: IP addresses appearing in ARP replies that do not match the DHCP lease assignments for the corresponding MAC
Recommended Mitigations
- Dynamic ARP Inspection (DAI): A managed switch feature that maintains a trusted binding table (derived from DHCP snooping) mapping legitimate IP addresses to their assigned MAC addresses and switch ports. ARP replies that contradict the binding table are dropped silently. An attacker sending a forged ARP reply claiming "192.168.1.1 = EE:FF" when the binding table shows 192.168.1.1 belongs to BB:FE has the reply discarded before it reaches any client. DAI is the primary technical control and eliminates ARP poisoning at the switch level.
- Network segmentation: Separate workstations, servers, and guest devices into distinct VLANs. ARP does not cross subnet boundaries — a device in the workstation VLAN cannot ARP-poison a device in the server VLAN. Segmentation is both the structural mitigation for ARP attacks and the primary control for limiting lateral movement.
- 802.1X port-based authentication: Requires devices to authenticate to the network before being granted switch port access. Makes it harder to introduce an unauthorized attacker device onto the network, reducing the population of potential ARP poisoning sources.
- Static ARP entries for critical hosts: Manually configured ARP entries for routers and servers cannot be overwritten by ARP replies. Practical only for a small number of critical infrastructure devices but highly effective for those entries.
Advisory: On-Path Browser Attack — Intercept, Modification, and Credential Capture Inside the Encrypted Session
Executive Summary
The on-path browser attack (formerly called man-in-the-browser) positions malware within the victim's browser process, between the browser's application logic and the TLS encryption layer. Data is intercepted after the user types it — before it is encrypted — and after the server sends it — after it is decrypted. The attacker reads all form field data (credentials, payment information, one-time codes) and can modify transactions in transit without the user's awareness. HTTPS provides no protection against this attack because the interception occurs within the browser process itself, below the point where the padlock icon or TLS validation is meaningful. This is the attack class responsible for the class of online banking fraud in which funds are transferred without the account holder's knowledge while they are actively logged in and observe no anomaly.
Technical Analysis — Why HTTPS Does Not Protect
HTTPS (HTTP over TLS) encrypts data in transit between the browser and the server. The encryption is applied by the TLS layer, which sits between the browser application and the network stack. The on-path browser attack intercepts data at the browser application layer — above the TLS layer. The sequence:
| Layer | Normal Operation | With Browser Malware |
|---|---|---|
| Browser application | User types form data; browser formats HTTP request | Malware hooks browser APIs; reads form data as user types; optionally modifies request values |
| TLS layer | HTTP request is encrypted; encrypted data sent to server | Malware has already read/modified the data — the TLS layer encrypts the (potentially modified) request normally |
| Network | Encrypted TLS traffic in transit | Encrypted TLS traffic in transit — identical to normal; no anomaly visible to network monitoring |
| Server | Decrypts TLS; processes HTTP request; returns response | Receives encrypted request that appears identical to a legitimate user request; processes it; returns response |
| TLS layer (response) | Server response decrypted by browser | Malware intercepts decrypted response; may modify displayed content (e.g., hide injected transactions from account view) |
From the server's perspective: valid session, valid certificates, valid origin IP. The server has no way to detect browser-level compromise. From the network monitoring perspective: valid encrypted TLS traffic, no anomalies. The only observable anomaly is at the endpoint — process behavior inside the browser — and at the transaction audit level (unexpected financial transactions, account changes the user reports not initiating).
Banking Fraud Attack Pattern
The canonical on-path browser attack against online banking follows this sequence: (1) malware is delivered to the victim's endpoint via phishing or drive-by download; (2) malware installs browser hooks that activate at browser startup; (3) victim authenticates normally to their bank — the malware detects the successful login; (4) while the victim browses their account, the malware initiates a background API call to the bank's transfer endpoint using the victim's active session token; (5) the bank processes the transfer as legitimate — the session is valid; (6) the malware intercepts the account display page and removes the injected transaction from the displayed balance and transaction history; (7) the victim observes nothing anomalous during the session; (8) the fraud is discovered when the victim's next statement arrives or when the bank's fraud detection flags the transaction pattern.
Delivery and Persistence
- Delivery vectors: Phishing email with malicious attachment; compromised website drive-by download exploiting browser or plugin vulnerability; fake software update prompt; Trojan bundled with pirated software
- Persistence: Browser extension registered to load at browser startup; DLL injected into browser process memory; hook registered via browser's legitimate extension API (difficult to distinguish from legitimate extensions without behavioral analysis)
Recommended Mitigations
- Endpoint protection with browser behavior monitoring: EDR (Endpoint Detection and Response) solutions that monitor for browser-hooking patterns — DLL injection into browser processes, anomalous API hook registrations, unexpected browser extension installations — provide detection capability that network-layer controls cannot. Signature-based anti-malware is insufficient; behavioral detection is required.
- Out-of-band transaction verification: For financial applications, require a second confirmation channel for state-changing transactions (SMS, authenticator app notification, or email to a registered address). The browser malware can modify what appears in the browser, but it cannot intercept a notification sent to a separate device or account. A transfer initiated by the malware triggers a confirmation the actual user receives and did not expect — enabling immediate detection and cancellation.
- Browser and OS patching: Browser-hooking malware typically gains initial access via a known vulnerability in the browser, browser plugin, or OS. Maintaining current patch levels eliminates the delivery vector for the majority of known browser attack toolkits.
- User education: Train users to report unexpected account activity immediately. Early reporting limits financial loss and enables forensic investigation while evidence is fresh. Users should understand that the padlock icon and HTTPS do not guarantee their device is uncompromised.