BiTree
  • Search For Lessons
  • Curriculum
  • Pricing
  • For Educators
  • Become a Tutor
  • About
  • Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
BiTree

Live coding lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Search For Lessons
  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Become a Tutor
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 BiTree. All rights reserved.
Curriculum/Cybersecurity/Networking and Protocol Security/ARP Spoofing and Poisoning
50 minIntermediate

ARP Spoofing and Poisoning

After this lesson, you will be able to: Explain why ARP is inherently insecure, how ARP poisoning routes a victim's traffic through an attacker, what that position enables, the defenses, and demonstrate it in an isolated lab.

ARP has no authentication, so any host can claim any IP. This lesson explains ARP poisoning, what an on-path attacker can then do (read traffic, attempt SSL stripping, inject content), the defenses (dynamic ARP inspection, static entries, HTTPS, VPNs), and a Kali-vs-container lab using arpspoof.

Prerequisites:Wireshark: Reading Network Traffic

💡 Authorization first

Run this only in an isolated lab you control (Kali plus a victim container on a private Docker network, or two VMs on a host-only network). ARP poisoning a network you do not own is illegal interception. Never point these tools at a real LAN.

Why ARP is insecure by design

ARP maps IP addresses to MAC addresses on a local segment, and it trusts whatever it is told. There is no authentication: any host can broadcast a 'gratuitous ARP' claiming 'IP 192.168.1.1 is at my MAC,' and other hosts will update their ARP tables. ARP was designed in a more trusting era for a local, physically secured network. That trust is the vulnerability.

How ARP poisoning works

The attacker sends forged ARP replies to two parties at once: it tells the victim 'the gateway is at the attacker's MAC,' and tells the gateway 'the victim is at the attacker's MAC.' Now both send their traffic to the attacker, who forwards it on (so nothing breaks) while reading and possibly modifying it. The attacker is now on the path: a man in the middle at Layer 2.

What the on-path position enables, and its limits

From on-path, an attacker can read any unencrypted traffic, attempt SSL stripping (downgrading HTTPS links to HTTP before TLS is established), and inject content into unencrypted responses. The crucial limit: properly deployed HTTPS with HSTS defeats reading and SSL stripping, because the browser refuses to use plain HTTP for the domain and validates the certificate. On-path is powerful against plaintext and weak against well-configured TLS.

Lab: ARP poisoning in an isolated Docker network

Kali as attacker, a victim container, an isolated bridge network.

  1. 1

    1. Create an isolated Docker network and run Kali plus a victim container on it.

  2. 2

    2. On Kali, enable IP forwarding so traffic still flows: sysctl -w net.ipv4.ip_forward=1.

  3. 3

    3. Poison both directions with arpspoof (dsniff package):

  4. 4

    arpspoof -i eth0 -t <victim_ip> <gateway_ip>

  5. 5

    arpspoof -i eth0 -t <gateway_ip> <victim_ip>

  6. 6

    4. From the victim, generate plain HTTP traffic; capture it on Kali with Wireshark and observe you can read it.

  7. 7

    5. Now serve the same content over HTTPS with HSTS and observe the content is unreadable. The defense is visible.

Defenses

Dynamic ARP Inspection on managed switches validates ARP replies against a trusted DHCP-snooping table and drops forged ones. Static ARP entries for critical hosts (gateway, servers) prevent their mappings being overwritten. HTTPS everywhere with HSTS makes the captured traffic useless. VPNs encrypt the whole tunnel so a local attacker sees only ciphertext. Port security and network segmentation reduce who can even attempt it.

Quick Check

After ARP-poisoning a victim, the attacker still cannot read the victim's banking session. Why?

Pick the best reason.

Common mistakes only experienced testers catch

Forgetting to enable IP forwarding, which drops the victim offline and tips them off. Poisoning only one direction, so you see half the conversation. Expecting to read HTTPS (you cannot without breaking TLS, which throws certificate warnings). Running it on a real network and committing a crime. Believing ARP poisoning is obsolete; it still works on flat, unmanaged LANs, which is why segmentation and HTTPS matter.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Wireshark: Reading Network Traffic
Back to Networking and Protocol Security
Man-in-the-Middle Attacks→