Before we start, it’s important to understand the basics of the ARP protocol.

In a local network, devices do not communicate using IP addresses alone. Actual data transmission at the network level relies on physical (MAC) addresses.
The Address Resolution Protocol (ARP) is responsible for resolving an IP address to its corresponding MAC address so that devices can communicate with each other within the same local network.

for example, when a system wants to communicate with the internet, it must first communicate with the default gateway.
Before starting this communication, the system checks its ARP cache to see whether the MAC address of the gateway is already known.
If the gateway’s MAC address is not present in the ARP cache, the system sends an ARP broadcast request to the entire local network to discover the MAC address of the corresponding device.
In this process, the destination MAC address of the broadcast frame is always set to ff:ff:ff:ff:ff:ff, ensuring that all devices on the local network receive the request.

Focusing on ARP requests, we use the arp.opcode == 1 filter to list all ARP request packets.

An ARP request contains the sender’s IP address and MAC address, along with the target IP address. The target MAC address is unknown at this stage and is set to all zeros, as the purpose of the ARP request is to discover it.

As the next step, we look for the ARP response.

If nothing appears suspicious at first glance, how can we detect an ARP poisoning attack? What abnormalities should we look for in ARP packets, and how can these abnormalities be identified?

Before hunting attacks, we must know normal ARP behavior:

• ARP requests are broadcast
• ARP replies are unicast
• One IP usually maps to one MAC address
• ARP replies usually follow an ARP request
• ARP traffic volume is low and periodic

Anything that breaks these assumptions is suspicious.

Here i am using TSHRK for better understand and better view .
First, we examine ARP requests and replies using tshark, as this provides a clearer understanding of how ARP works.

In this tshark command, arp.src.proto_ipv4 represents the IP address of the sender generating the ARP packet, while arp.dst.proto_ipv4 represents the target IP address for which the MAC address is being requested or announced.

Here, we can clearly observe ARP requests and replies, which helps us understand how the ARP protocol works. Next, we focus on identifying abnormalities by filtering ARP reply packets along with their associated IP and MAC addresses.

At this point, we are very close to identifying the issue.

As discussed earlier, a MAC address is a unique identifier, and under normal circumstances, each IP address should be associated with a unique MAC address within the same network.
However, in this case, we observe that three different IP addresses are mapped to the same MAC address (08:00:27:9b:8b:bd). This behavior is abnormal and strongly indicates the presence of ARP poisoning on the network.

From the above tshark command,
arp.src.proto_ipv4 represents the IP address claimed by the sender of an ARP packet, while arp.src.hw_mac represents the MAC address making that claim. Analyzing these fields together helps identify abnormal IP-to-MAC mappings indicative of ARP poisoning.

Another way to confirm ARP poisoning is by using Wireshark’s built-in analysis features.

Open the PCAP file in Wireshark, apply the arp display filter, and then navigate to Analyze → Expert Information.
In the Expert Information window, Wireshark may raise a “Duplicate IP address configured” warning. When this warning is expanded, it reveals that multiple IP addresses are associated with the same MAC address, which is a strong indicator of ARP spoofing or poisoning.

In this analysis, we started by understanding normal ARP behavior and gradually moved toward identifying abnormalities within ARP packets. By examining unsolicited ARP replies and detecting multiple IP addresses mapped to a single MAC address, we were able to confirm the presence of an ARP poisoning attack.

This investigation demonstrates that ARP poisoning often blends into otherwise normal-looking network traffic and cannot be detected by looking at a single packet in isolation. Instead, recognizing patterns and inconsistencies over time is critical.

Since ARP lacks built-in authentication, it remains a viable attack vector in many environments, particularly on public or unsecured networks. For defenders, continuous monitoring of ARP traffic and enforcing network-level protections are essential steps toward mitigating these attacks.