ARP – the address resolution protocol – is responsible for translating IP addresses into MAC addresses. If your system wants to reach a server on the internet that has the IP address 1.2.3.4, the packets will not go through the wire directly to that one server, but they will have to jump over your router and most likely several intermediaries until they reach the target. While the destination IP of your packet – 1.2.3.4 – remains the same (OSI layer 3), the MAC address that indicates each upcoming hop is changing with each hop (OSI layer 2).

When your system starts sending the packet, the first MAC address will be the one of your router / switch. Your system will know the IP address of that router, because it is saved as gateway address in your system’s network configuration. However, to know the MAC address of that gateway, it will send out an ARP request, asking for the MAC of the gateway IP.

The problem from a security point of view is that ARP is not encrypted. Moreover, gratuitous ARP packets are allowed. This means, anybody in the network can just come and say: “Hello, I’m the gateway, my MAC address is so and so”. The system that receives this information will happily take it for granted, even if it did not ask for the information in the first place. From that point on, all traffic that was destined for the gateway will be sent to the attacker, because the attacked system thinks that the known gateway IP address resolves to the MAC address of the attacker.

Faking ARP packets by sending a wrong combination of IP address and MAC address is called ARP spoofing, the process of messing up the attacked system’s ARP table where it stores that information for a few seconds is then called ARP poisoning.

OK, you might have known all this already.

But: Did you know that you can easily detect ARP spoofing using Wireshark?

Let’s have a look at the screenshot below:

In this example I ran Metasploit in my test environment to perform an ARP poisoning attack against another lab system. Starting up the ARP module in Metasploit is really straightforward. In a terminal on your Kali Linux, type:

sudo msfconsole
use auxiliary/spoof/arp/arp_poisoning

Metasploit will do all the dirty work for us, we just have to provide three details to make the attack work:

1. IP address of the target system that we want to attack
2. IP address of the gateway
3. IP address of our own system

What Metasploit will then do is just send out a continuous stream that tells the target system that the MAC address of the gateway is “XYZ”, where XYZ is actually the MAC address of our own system.

To populate the necessary information in Metasploit, type:

set DHOSTS *IP address of the attacked system*
set SHOSTS *IP address of the gateway*
set LOCALSIP *IP address of our own system's relevant interface*

If you made a mistake, e.g. mixed up DHOSTS and SHOSTS, you can just repeat the command and Metasploit will overwrite the information. For a last check prior to the attack, type:

show options

This will list all parameters as you provided them to the ARP module. To finally run the attack, just execute:

exploit

When you now have a look at Wireshark, you will see a steady stream of ARP packets that are telling the target system that the gateway’s MAC address is the *MAC address of our own system*.

Let’s have another look at the screenshot above.

In the part in Wireshark where I drew a red box, you can see that the ARP packets state:

192.100.200.1 (the gateway IP) is at *MAC address of our own system*

At this point, the target system will have updated it’s ARP table with that fake information and start to send all packets to us instead of the gateway. If the traffic is unencrypted, we can read along.

Then I pressed Ctrl-C in Metasploit to stop the attack. This is where I drew the purple box on the left in Metasploit. As you can see, Metasploit says that it is RE-ARPing the victims. What this means is that it will send some more ARP packets, but this time with the correct MAC address of the gateway. If we did not do this, the attacked system would continue sending to us even after the attack. At some point – usually after 15-60 seconds, the victim’s OS will automatically flag entries in the MAC table as stale and update them by sending out an ARP request. Only then will the victim get again true information about the gateway’s real MAC address.

OK, but in the title you wrote that we can detect such attacks?

That’s true! In a “normal” network, ARP poisoning would be very easy to perform. But there are some countermeasures that you can take:

1. Work with static ARP entries. This means, you manually tell your system not only the IP address of the gateway, but also the corresponding MAC address. It can then simply ignore all information that is flowing in via ARP packets which could be stating anything else. Microsoft recommends a solution which would need to be performed after every system reboot. Apparently, there are more permanent methods – so permanent that you might have trouble getting rid of the static entry later on. For personal use this can be a good solution. On the other hand, striving to handle static ARP entries in large company networks with thousands of mobile workstations is a rather unrealistic endeavour.
2. Use Dynamic ARP inspection if it is supported by your switch or router.
3. Use Wireshark for ad-hoc detection

So, you waited long enough – here are the details for the third point, detection with Wireshark.

If you ran Wireshark while the ARP attack was running, then Wireshark will be clever enough to realize that there are contradicting ARP packets. Sometimes a packet says that the gateway IP has *Real MAC address of the gateway*, but then some packets say *MAC address of your computer*.

This finding will not be advertised prominently, but you can find a note under Analyze > Expert Information:

As you can see in the first screenshot of this post, Wireshark will notice that there is a “Duplicate IP address configured”. As the wording implies, this can simply mean that one or more of the systems in your network are not using DHCP, but static IPs and that two or more of them are now using the same IP address. This would then result in conflicting ARP packets.

On the other hand, if you are using DHCP or if you know that you properly set up your network without duplicate IP addresses, then this note is a strong indicator that a spoofing attack is going on.

By the way, to perform easy tests with several systems in one VM, I can highly recommend the well-written Wireshark for Security Professionals which comes along with a neat lab environment.