Eavesarp : Analyze ARP Requests To Identify Intercommunicating Hosts

Eavesarp a reconnaissance tool that analyzes ARP requests to identify hosts that are likely communicating with one another, which is useful in those dreaded situations where LLMNR/NBNS aren’t in use for name resolution.


This is only gon’ work on Kali or other Debian-based Linux distributions

eavesarp requires Python3.7 and Scapy. After installing Python, run the following to install Scapy:

python3.7 -m pip install -r requirements.txt


Capturing ARP Requests


  • It requires root privileges to sniff from the interface and craft ARP packets.
  • Captured output is automatically written to disk under the name eavesarp.db to prevent having to recapture ARP requests.

Passive Execution

The most basic form of execution is:

sudo ./eavesarp.py capture -i eth1

This will initialize eavesarp such that ARP requests will be captured, analyzed, and relevant output will be presented to the user in a table. Use --help for additional information on non-standard arguments. Note that the stale column indicates [UNCONFIRMED] when an ARP request originating from a target (as a sender) has not yet been observed when running in this mode. Enable ARP resolution via the -ar flag to determine if a given target address has gone stale.

Also Read – TweetShell : Multi-Thread Twitter BruteForcer In Shell Script

Active Execution (ARP Resolution, DNS Resolution)

Enable ARP and DNS resolution by including the -ar and -dr flags. Keep in mind that this makes the tool non-passive, but the advantage is that DNS records, MAC addresses, and a confirmation of SNACs status is returned.

sudo ./eavesarp.py capture -i eth1 -ar -dr –blacklist

We can clearly see from the output below which senders are affected by one or more SNACs and the affected addresses. The final column indicates if a potential MITM opportunity is present. eavesarp checks to see if the FWD address of the PTR resolved for a given sender is different.

If so, it may be an indicator that the intended target has moved to the new FWD address. Applying an alias to the interface of our attacking host may allow us to forward the traffic to the intended target and capture information in transit.

Analyzing PCAP Files and SQLite Databases (generated by eavesarp)

Itcan accept SQLite databases and PCAP files for analysis. It will output the extracted values to a new database file for further analysis. See the --help flag for more information on this process, however basic execution is demonstrated below.

sudo ./eavesarp.py analyze -sfs eavesarp.db -cp disable –blacklist –csv-output-file eavesarp_analysis.db

SNAC    Sender         Target            ARP#  Stale    Sender PTR      Target PTR        MITM
------  -------------  --------------  ------  -------  --------------  ----------------  ---------------------------------------------
True      21  True     iron.aa.local.  syslog.aa.local.  T-IP: != PTR-FWD:
True       17  True     crux.aa.local.
                    15  True
                     1                           w10.aa.local.         1           w10.aa.local.   crux.aa.local.
- Writing csv output to eavesarp_analysis.db

…and the CSV output looks like…

21,,74:d4:35:1a:b5:fb,,[STALE TARGET],True,iron.aa.local.,syslog.aa.local.,,T-IP: != PTR-FWD:,True
17,,b8:27:eb:a9:5c:8f,,[STALE TARGET],True,crux.aa.local.,,,False,True
15,,b8:27:eb:a9:5c:8f,,[STALE TARGET],True,crux.aa.local.,,,False,True