Skip to content

03-02: Exercises

Question

While monitoring a LAN, you capture the following ARP replies over a short 10-second window. All hosts are on 192.168.1.0/24, and the legitimate gateway is known in advance to be at 192.168.1.1 with MAC GG:GG:GG:GG:GG:GG.

Time ARP Reply: "IP is at MAC" Sent By (Source MAC) Solicited by a prior request?
T+0s 192.168.1.1 is at GG:GG:GG:GG:GG:GG GG:GG:GG:GG:GG:GG Yes — Host C asked
T+2s 192.168.1.30 is at CC:CC:CC:CC:CC:CC CC:CC:CC:CC:CC:CC Yes — Host A asked
T+5s 192.168.1.1 is at EE:EE:EE:EE:EE:EE EE:EE:EE:EE:EE:EE No — unsolicited (gratuitous)
T+6s 192.168.1.20 is at BB:BB:BB:BB:BB:BB BB:BB:BB:BB:BB:BB Yes — Host A asked
  1. Which entry indicates a possible ARP spoofing attack, and why?
  2. What should a defender do next?

Solution

Step 1: Establish the baseline of "normal" ARP behavior

Legitimate ARP replies typically share these traits:

  • They are sent in response to a request (someone asked "who has this IP?").
  • The MAC address returned for a given IP is consistent over time (a host's NIC doesn't normally change).
  • The reply's source MAC matches the MAC claimed inside the ARP payload.

Compare each row against this baseline:

Time Entry Solicited? MAC matches known value? Verdict
T+0s 192.168.1.1 → GG:GG:GG:GG:GG:GG Yes Yes (matches known gateway MAC) Normal
T+2s 192.168.1.30 → CC:CC:CC:CC:CC:CC Yes Consistent with host's own claim Normal
T+5s 192.168.1.1 → EE:EE:EE:EE:EE:EE No (gratuitous) No — gateway should be GG:GG:GG:GG:GG:GG Suspicious
T+6s 192.168.1.20 → BB:BB:BB:BB:BB:BB Yes Consistent with host's own claim Normal

Step 2: Identify the spoofed entry

The T+5s entry is the red flag:

  • It claims the gateway's IP (192.168.1.1) — a high-value target, since intercepting gateway traffic lets an attacker see/manipulate most of the host's outbound traffic (classic man-in-the-middle setup).
  • It is unsolicited — no host issued a corresponding ARP request just before it. Legitimate replies almost always follow a request; an uninvited ("gratuitous") reply is a common ARP-spoofing technique because it lets an attacker overwrite victims' caches without waiting to be asked.
  • It maps 192.168.1.1 to a different MAC address (EE:EE:EE:EE:EE:EE) than the one already known to belong to the real gateway (GG:GG:GG:GG:GG:GG). A single IP suddenly resolving to two different MAC addresses within seconds, with no legitimate explanation (like a NIC replacement or DHCP failover), is the textbook signature of ARP cache poisoning / ARP spoofing.

👉 (1) The T+5s reply is spoofed: it is an unsolicited (gratuitous) ARP reply claiming the gateway's IP with a MAC address that doesn't match the known-good gateway MAC.

Step 3: What a defender should do next

  1. Isolate the suspicious source. Identify which switch port / physical device owns EE:EE:EE:EE:EE:EE and disconnect or quarantine it.
  2. Flush affected ARP caches on hosts that may have accepted the poisoned entry, forcing fresh ARP resolution against the legitimate gateway.
  3. Correlate with switch logs / DHCP snooping tables to confirm which MAC-to-port binding is legitimate (the switch's own bindings are a reliable source of truth).
  4. Enable protections going forward: Dynamic ARP Inspection (DAI) on managed switches, static ARP entries for critical devices (like the gateway) on sensitive hosts, or an ARP-monitoring tool (e.g., arpwatch) that alerts on IP-to-MAC changes.
  5. Investigate the offending host for malware or a rogue device (ARP spoofing tools like arpspoof/ettercap are often run from a compromised machine on the LAN).

Final Answer

  • The T+5s entry (192.168.1.1 → EE:EE:EE:EE:EE:EE) indicates ARP spoofing: it is a gratuitous/unsolicited reply, and it changes the MAC address bound to the gateway's IP without any corresponding request or legitimate cause.
  • Next steps: flush poisoned ARP caches, trace and isolate the rogue MAC's switch port, verify bindings via DHCP snooping/switch tables, and deploy Dynamic ARP Inspection or static ARP entries to prevent recurrence.