Example 1 · ARP Poisoning Walkthrough — Specific IPs and MACs
A complete walkthrough of an ARP poisoning on-path attack using specific addresses from the course material.
Network configuration:
- Laptop: IP 192.168.1.9, MAC ending in 38:d5
- Router (default gateway): IP 192.168.1.1, MAC ending in BB:FE
- Attacker device: IP 192.168.1.14, MAC ending in EE:FF
- All three devices on the same /24 subnet
Normal state (before attack):
The laptop's ARP cache contains a legitimate entry: 192.168.1.1 → BB:FE. When the laptop needs to send packets to the internet, it encapsulates them in frames addressed to MAC BB:FE (the router). The switch delivers them to the router. All traffic flows normally.
Phase 1 — Poisoning the laptop:
The attacker's device at 192.168.1.14 (MAC EE:FF) sends an unsolicited ARP reply to the laptop. The frame says: "I am 192.168.1.1. My MAC address is EE:FF." The laptop received no ARP request — the attacker sent this reply without being asked. Because ARP has no authentication and caches accept unsolicited updates, the laptop overwrites its cache entry:
Before: 192.168.1.1 → BB:FE
After: 192.168.1.1 → EE:FF
From this point, all traffic the laptop sends to 192.168.1.1 (the internet gateway) will be delivered to the attacker's device at MAC EE:FF.
Phase 2 — Poisoning the router:
Simultaneously, the attacker sends a mirror-image unsolicited ARP reply to the router: "I am 192.168.1.9. My MAC address is EE:FF." The router updates its ARP cache:
Before: 192.168.1.9 → 38:d5
After: 192.168.1.9 → EE:FF
All traffic the router sends destined for the laptop (192.168.1.9) will now be delivered to the attacker at MAC EE:FF.
Phase 3 — Traffic interception and relay:
The attacker's device now sits between the laptop and the router. When the laptop sends an HTTP request:
- Laptop → attacker (frame addressed to EE:FF) — attacker reads the request
- Attacker → router (frame addressed to BB:FE) — attacker forwards the request
- Router → attacker (frame addressed to EE:FF, since router thinks EE:FF is the laptop) — attacker reads the response
- Attacker → laptop (frame addressed to 38:d5) — attacker forwards the response
Both the laptop and the router experience normal network communication. Neither sees any error. The attacker reads every byte of traffic in both directions.
Phase 4 — Cache maintenance:
ARP cache entries expire (typically within minutes). The attacker sends repeated poisoned ARP replies to both devices continuously, ensuring both caches stay corrupted with EE:FF and the on-path position is maintained as long as the attack is running.
Example 2 · On-Path Browser Attack — Banking Scenario
How a browser-resident on-path attack captures credentials and executes unauthorized transactions while remaining completely invisible to the victim.
Setup: The victim received a phishing email appearing to be a software update notification. They downloaded and ran the attachment. It installed a browser-hooking Trojan that patches itself into the browser's extension API and payment processing hooks. The victim has no idea.
Day 1 — Waiting: The malware sits dormant. It monitors every page the browser visits. The victim checks news sites, email, social media — nothing of interest to the malware. The victim has no awareness that anything is wrong.
Day 3 — Banking login detected: The victim navigates to their bank's website. The browser connects via HTTPS to the legitimate banking domain — the certificate is valid, the padlock appears, the URL is correct. The victim types their username and password and clicks Login.
Intercept point (outbound): Before the login credentials are encrypted by TLS and sent to the server, the malware intercepts them in plaintext — username and password captured. The malware allows the login to proceed normally. The server authenticates the user and issues a session token.
Intercept point (inbound): The server's response — containing the session token embedded in cookies — arrives encrypted via HTTPS. TLS decrypts it for the browser. Before the browser processes the response, the malware intercepts the decrypted response and captures the session token.
Malicious background transaction: The malware now has a valid session token for an authenticated banking session. It silently issues an HTTP request in the background — a fund transfer request, using the same API the banking site's own interface uses, with the real session token attached. The request looks identical to a request the legitimate user would make. The bank's server processes it as authentic.
Victim perspective: The victim is looking at their account summary page. The page loaded normally. The padlock is present. The balance shown may already reflect the transfer, or may be cached and not yet updated. The victim has no indication anything happened.
What detection would look like: Network monitoring shows only clean HTTPS traffic to the legitimate banking domain. Firewall logs are clean. The server logs show a legitimate, authenticated session from the victim's IP address making a valid API call. The only anomaly is the transaction itself — a transfer the user didn't explicitly initiate. Out-of-band transaction confirmation (SMS alert) would have notified the user. Endpoint protection software watching for browser API hooking might have flagged the malware at install time.
Example 3 · Detecting ARP Poisoning
How to identify an active ARP poisoning attack and what the evidence looks like.
Method 1 — Check the ARP cache:
On Windows: arp -a
On Linux/Mac: arp -n
Look for duplicate MAC addresses — if two different IP addresses map to the same MAC address, one of them may be a poisoned entry. In the attack example: if both 192.168.1.1 and 192.168.1.14 show MAC EE:FF, the gateway entry (192.168.1.1) has been poisoned to point at the attacker's MAC.
Method 2 — Packet capture (Wireshark):
Apply the Wireshark filter: arp
Look for: (1) Gratuitous ARP replies arriving without a corresponding ARP broadcast — unsolicited replies are the poisoning mechanism; (2) ARP replies that contradict each other — if you see the router's MAC change from BB:FE to EE:FF in the ARP traffic, the change is the attack in progress; (3) Abnormally high volume of ARP traffic — repeated poisoning to maintain cache corruption produces more ARP traffic than normal operation.
Method 3 — Dynamic ARP Inspection alerts:
Managed switches with DAI enabled will log and drop ARP packets that conflict with the DHCP snooping binding table. Switch logs showing "DAI: ARP packet dropped" with a specific source MAC and IP is direct evidence of an ARP poisoning attempt in progress.
Exam Scenario 1 · Identifying the Attack Type
Scenario: A financial analyst reports that her browser is showing unauthorized transactions on her bank account, but she has no memory of initiating them. The bank's security team confirms the transactions were made using valid session tokens from her IP address. The analyst's network traffic was captured and analyzed — it shows only legitimate HTTPS connections to the bank's domain; all certificates were valid; no anomalous network activity is present. Her workstation ran a full antivirus scan two weeks ago and was clean at that time.
Question: What attack best explains this scenario, and why does the evidence pattern fit it?
Answer: This is an on-path browser attack. The evidence pattern fits because: (1) the transactions used valid session tokens from the victim's own IP — consistent with malware operating locally inside the victim's browser, not a remote attacker using a different source; (2) the HTTPS traffic shows no anomalies — browser-resident malware doesn't affect the network layer; the encrypted tunnel to the bank's server is legitimate; (3) the antivirus scan was two weeks ago — malware installed after the scan would not have been detected. The attack bypasses HTTPS because it intercepts inside the browser, before the encryption layer processes outbound requests and after it decrypts inbound responses. Network-layer analysis will never find this attack — endpoint investigation of the victim's device is required.
Exam Scenario 2 · ARP Poisoning Response
Scenario: An IT administrator runs arp -a on a workstation in a corporate office and notices that the MAC address associated with the default gateway (192.168.1.1) matches the MAC address of another workstation on the network, not the router. Running the same check on three other workstations reveals the same pattern — all four workstations have the same wrong MAC address for the gateway.
Question: What attack is indicated, and what immediate steps should be taken?
Answer: The pattern indicates an ARP poisoning (ARP spoofing) attack. All four workstations have been poisoned with the same false MAC address for the gateway. The matching MAC belongs to another workstation — likely the attacker's device, which has been sending gratuitous ARP replies to all devices on the subnet.
Immediate steps: (1) Identify the device with the suspect MAC address — look it up in the DHCP server's lease table or the switch's MAC address table to find which switch port it's on; (2) Isolate that port on the managed switch to stop ongoing poisoning; (3) Flush the ARP caches on affected workstations (arp -d * on Windows, ip -s neigh flush all on Linux) so they re-learn the correct gateway MAC; (4) Review packet captures for what traffic was intercepted; (5) Enable Dynamic ARP Inspection on the switches to prevent recurrence.
Exam Scenario 3 · On-Path vs. On-Path Browser Classification
Scenario: Two employees report security incidents. Employee A is working remotely from a hotel. He accesses his company's VPN and then browses the intranet. Later he discovers his VPN credentials were stolen, but his personal laptop shows no signs of malware. Employee B is using a corporate workstation in the office. She has experienced repeated unknown charges on her banking account accessed only from that workstation. Network traffic analysis of the office segment shows no anomalous ARP traffic. Endpoint analysis of her workstation finds an unrecognized browser extension.
Question: Classify each incident.
Answer: Employee A: likely a traditional on-path (network-layer) attack. In a hotel environment, the attacker may have compromised the hotel's network infrastructure or positioned a device on the shared hotel Wi-Fi to perform ARP poisoning or SSL stripping against his unencrypted pre-VPN traffic. No malware on the device is consistent with a network-based attack. Employee B: on-path browser attack. No anomalous ARP traffic (no network-layer attack) but an unrecognized browser extension — consistent with browser-hooking malware delivered as a fake extension or installed by a dropper. The attack stays inside the browser and is invisible to network monitoring. Removal of the extension and endpoint security analysis are the response actions.