In this post, an ARP Spoofing tool was created. However, creating the tool is one thing, ensuring it works as expected is another. In this post we take a look at validating that the tool works.
First thing to note is that the tool needs "admin" level privileges to work.
Additionally, while we are "listening" for a specific request, we will run tcpdump and or wireshark to assist with our validation.
Let's load "arpSpoof.py"
When "arpSpoof.py" is executed without "appropriate" arguments it brings up the "usage" screen.
To ensure you can capture the ARP request let's add an interface, an IP to listen for and a MAC address to spoof.
./arpSpoof.py eth0 192.168.0.91 AA:BB:CC:DD:EE:FF
eth0 - is the interface we will listen on
192.168.0.91 - IP for which the ARP is being requested for
AA:BB:CC:DD:EE:FF - The MAC address we would like to assign for 192.168.0.91
Testing from Windows 10
Before we attempt to verify that it works, let's see what we have in the ARP cache and results from "ping"
From the above, we see there is no entry in the ARP cache and when we try to ping, it states "Destination host unreachable".
Continuing with the arguments which were earlier used above, we can now execute our command
which will allow the tool to listen for the ARP request.
Now that we are "listening". Let's send a "ping" which will force an ARP request.
From above we see that our "ping" results in "Request timed out" as opposed to the previous message "Destination host unreachable". Additionally, we see that we have managed to provide the MAC address of "aa-bb-cc-dd-ee-ff" for host "192.168.0.1" and that this information has been successfully added to the Windows 10 computer ARP cache.
there can be many reasons why it states "Request timed out" and not an
actual "ping" reply. One of these could be a firewall. However, the
objective of this post is not to verify all of that but to show how we
can spoof the ARP reply and poison the ARP cache of the requesting host.
Taking a look at the packet in Wireshark, we see the following:
Above we see 1 request for "192.168.0.1" being asked for by "192.168.0.30". We then see our 3 responses claiming that "192.168.0.1" is at "aa:bb:cc:dd:ee:ff".
Additionally, we can verify this is our response by taking a look at the data which was sent in the ARP reply.
Hope you enjoyed!