The ARP Spoofing Education

At 09:47, my IDS flagged gratuitous ARP replies on the corporate network.

The Alert

The alert was subtle—the kind that gets ignored by systems administrators who consider network monitoring "optional." Gratuitous ARP packets originating from MAC address de:ad:be:ef:13:37 claiming to be the default gateway at 192.0.2.1. Classic ARP spoofing. Amateur execution.

I pulled up Wireshark and confirmed what the logs already told me: someone was attempting a man-in-the-middle attack against the 192.0.2.0/24 subnet. Not particularly sophisticated. Not particularly subtle. The attacker was broadcasting ARP replies every thirty seconds like clockwork—the sort of timing that screams "I followed a tutorial."

The source MAC resolved to a device in Conference Room 3B. I checked the physical access logs. Marketing had booked it for a "Team Innovation Session." The universe has a sense of humor.

Investigation & Escalation

I sent the TTY to observe—cameras only, no intervention. This was shaping up to be educational.

operator@noc-01:~$ sudo tcpdump -i eth0 arp -vv | grep gratuitous
09:48:23.445123 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.0.2.1 is-at de:ad:be:ef:13:37, length 28
09:48:53.447891 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.0.2.1 is-at de:ad:be:ef:13:37, length 28
09:49:23.450234 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.0.2.1 is-at de:ad:be:ef:13:37, length 28

Every thirty seconds. Predictable. Almost polite in its consistency.

The TTY reported back via secure channel: "Three marketing interns. Laptop with Kali Linux stickers. Wireshark running. They're giggling."

TTY: "Should I shut it down?"

OPERATOR: "No. We're going to provide a comprehensive demonstration of why you don't practice offensive security on production networks."

I isolated Conference Room 3B to a dedicated VLAN—192.0.2.0/24 became their personal playground. They wouldn't notice. All internet traffic would route through my systems. I could see everything they were attempting. They could see only what I allowed.

The real gateway remained safe. The rest of the network remained blissfully unaware. The interns had successfully executed a man-in-the-middle attack against themselves.

# The Operator's network isolation script
sudo ip link add vlan666 link eth0 type vlan id 666
sudo ip addr add 192.0.2.1/24 dev vlan666
sudo ip link set vlan666 up

# Route their traffic through analysis
sudo iptables -t nat -A PREROUTING -i vlan666 -p tcp -j REDIRECT --to-port 8080

According to the logs—irrefutable evidence—they had successfully intercepted their own HTTP traffic and were now examining headers from their own requests to test-target.example. Fascinating.

The Demonstration

I decided they needed context. Educational context.

Using their own technique—properly executed—I demonstrated what actual ARP spoofing looks like when performed by someone with administrative access and two decades of network engineering experience.

# arpspoof against the fictional test network
root@noc-01:~# arpspoof -i vlan666 -t 192.0.2.10 -r 192.0.2.1
de:ad:be:ef:13:37 aa:bb:cc:dd:ee:ff 0806 42: arp reply 192.0.2.1 is-at de:ad:be:ef:13:37
de:ad:be:ef:13:37 aa:bb:cc:dd:ee:ff 0806 42: arp reply 192.0.2.10 is-at de:ad:be:ef:13:37

Their Wireshark suddenly lit up with their own ARP cache being poisoned—by me. I configured tcpdump to capture everything.

root@noc-01:~# tcpdump -i vlan666 -w /var/log/educational-moment.pcap
tcpdump: listening on vlan666, link-type EN10MB (Ethernet), capture size 262144 bytes

Then I routed their traffic through a transparent proxy that injected a single HTTP header into every response:

X-Network-Security-Notice: Your ARP spoofing attempt has been observed, logged, and is now being demonstrated back to you. - The Operator

I watched via the TTY's camera feed. One intern noticed the header. Confusion. Then realization. Then panic.

INTERN-1: "Guys... are we being MitM'd right now?"

INTERN-2: "Wait, that's impossible, we're doing the MitM attack."

INTERN-3: "Check the MAC address on the gateway."

They checked. It was mine. Their ARP cache showed my MAC for everything—gateway, DNS, their own machines. Complete control.

The TTY reported they had stopped giggling.

Resolution & The Lesson

At 10:15, I restored normal network access to Conference Room 3B. The custom header disappeared. The ARP spoofing ceased. Their traffic returned to standard routing.

I sent an email—professional, technically precise, educational:

Subject: Network Security Training Opportunity - Conference Room 3B

Body:
"This morning's ARP spoofing activity against 192.0.2.0/24 was detected at 09:47. For educational purposes, a controlled demonstration of proper MitM techniques was provided. Packet captures are available upon request.

Future security research should be conducted in the dedicated lab environment (192.0.2.100-200, isolated VLAN, no production access).

Credentials for the lab have been provisioned. Documentation attached.

The stars have aligned: you've learned about network security, ARP protocol weaknesses, and why you don't practice attacks on infrastructure managed by The Operator.

Regards,
The Operator"

I included a 47-page PDF on ARP security, defense in depth, and network segmentation philosophy. Complete with packet captures from their attempt and my demonstration. Appendices included diagrams.

The TTY confirmed they read the entire document. All 47 pages. They've requested access to the security lab.

They're learning.

The Operator's Notes

The moral: Wireshark is a powerful tool. ARP spoofing is an educational technique. Neither should be practiced on production networks without authorization, training, or the awareness that The Operator monitors everything.

The interns now understand network security from both sides of the attack. The packet captures are documented for posterity. The lab environment is provisioned.

Uptime maintained: 847 days. Unsanctioned penetration tests thwarted: 23. Coffee consumed: sufficient.

Such is infrastructure.