10 min to read
Reading and Interpreting Cached ARP tables
Passive Network Discovery through understanding ARP protocol data in memory
Introduction to ARP Tables:
Computers already keep track of other devices they encounter on the same network - at least on a temporary basis. We only need to tap into this tracking to passively expose the observed local network devices.
The ARP (Address Resolution Protocol) was established in RFC 826 in 1982 and is a staple networking protocol. The purpose of ARP is to allow hosts to communicate with other devices on the same network by converting between Logical addresses and Physical addresses.
If we compare ARP’s role against the OSI (Open Systems Interconnection) model, ARP acts as a translator between the Network layer and Data Link layer.
In practise this means a device uses ARP to create a map of observed IPv4 addresses against corresponding MAC (Media Access Control) addresses. This address map is cached in RAM (Random Access Memory) as an “ARP Table”.
Note: The ARP table should be distinguished from other addressing maps such as MAC Address tables found on switches, and concepts like DHCP (Dynamic Host Configuration Protocol) and DNS (Domain Name System).
Passive ARP Discovery:
On Windows and Linux the ARP protocol is supported by an ARP utility. Which means the ARP table in memory is accesible with simple terminal commands.
We can use this fact to learn about other local devices without generating any new or unusual traffic on the host network.
On Windows:
In command prompt we can use arp -a, where the -a flag indicates
Displays current ARP entries by interrogating the current protocol data. […] If more than one network interface uses ARP, entries for each ARP table are displayed.
So if the host has more than one network interface, e.g. WLAN (Wireless Local-Area Network) and LAN (Local-Area Network), then the device entries will be listed by the interface on which they were encountered.
On Linux:
In a terminal we can also use arp -a. Where -a means
display (all) hosts in alternative (BSD) style
Although, the alternatives arp -e and arp -n provide a formated table which may be easier to read. Where -e means
display (all) hosts in default (Linux) style
If the ARP utility is not installed, it can be installed as part of the net-tools package
sudo apt-get install net-tools.
However, to keep an LotL (Live-off-the-Land) approach and avoid installing anything new, the ARP table can also be read directly from the /proc file system cat /proc/net/arp.
On WSL (Windows Subsystem for Linux):
You may need to specificy the executable of the utility you want to run by appending .exe, i.e. arp.exe.
However, the steps and outputs should the same seen on Windows.
Active ARP Discovery:
The ARP protocol can also be used to actively scan for devices on the network by crafting and sending out ARP request packets to enumerated IP addresses. However, this is beyond the functions of ARP utility.
ARP sweeps are best performed by tools with these dedicated functions, such as arp-scan or the arp_sweep module in Metasploit the pentatration testing framework. Active discovery using ARP will not be covered in this post.
Understanding the ARP Table:
To maximise the utility of the ARP table the data needs to be supplemented with more context.
Adding context to MAC Addresses
The most useful information in the ARP table is the association of IP addresses with a respective MAC address. The MAC address itself is a useful piece of information. The first three octets of a MAC address contains the device’s OUI (Organizationally Unique Identifier).
A lookup of the OUI reveals an associated vendor or manufacturer, which is helpful in profiling the device in the ARP table entry.
Here are some online resources to conduct OUI lookups:
- MacVendor’s MAC Address Lookup Tool
- WireShark’s OUI Lookup Tool
- WireShark’s Manufacturer Database
- IEEE’s OUI Standards List
Adding Context to Network Interfaces
On Windows the interfaces are usually identified by their IPv4 Address. To detail more information about the active interfaces, various Windows utilities are available, such as ipconfig,
as well as netsh interface ip show address,
or wmic nicconfig where IPEnabled='true' get IPAddress, Description
With this additional information the interfaces can be identified with a descriptive name in addition to their IP address.
In WSL specificy the executable of the utility you want to run by appending .exe, i.e. ipconfig.exe, netsh.exe, wmnic.exe.
Putting Together a Picture of the Local Network
By combining the ARP data in memory, OUI lookup information, and descriptive interface names, a picture of the local network starts coming together. A network analysis can be drawn simply by using information that was gathered passively and keeping a LotL (Living-off-the-Land) approach.
To illustrate the power of this passive discovery method I’ve included the approach as part of a Network Device Discovery Python Script on Github.
Limitations of the ARP Table:
To successfully use ARP for passive network examination it is important to remember the limitations of the ARP protocol, in particular that ARP data is short-lived. Overall, it will be advantageous to read the ARP table at different points in time to yield a better picture of the network.
An IPv4 Protocol
As a protocol from the 1980’s, ARP only generates ARP entries for devices with an observed IPv4 address and will not track devices which are IPv6 only. The IPv6 supplement to ARP is the NDP (Neighbour Discovery Protocol).
Local Context:
The ARP table only keeps track of devices on the same local network, and will not provide any information on devices from external networks.
Transient Table Entries:
Per specifications of the ARP protocol, individual entries added to the ARP table are set to expire before they are eventually deleted.
Which means the state of the ARP table will only be reflective of what was observed on the network in the last few minutes. The exact TTL (Time-to-Live) for entries is implemented differently per operating system.
On Windows:
An ARP entry goes stale after 15-45 seconds according to Microsoft’s Description of Address Resolution Protocol (ARP) caching behavior.
the “Reachable Time” value is somewhere between 15 seconds (30 × 0.5 seconds) and 45 seconds (30 × 1.5 seconds). If an entry is not used for a time between 15 to 45 seconds, it changes to the “Stale” state.
At which point the host needs to reissue an ARP request if it wants to reach the destination again.
On Linux:
The state progression of ARP entries is affected by various factors, but for illustrative purposes the state can be observed with the command ip neighbour show.
Cached Table:
Given the transient nature of ARP data, the ARP table is only stored in RAM. The ARP table will typically not survive a reboot, and the ARP table may be empty if the host was only recently booted or connected to the network.
Spoofed ARP Entries:
ARP entries are generated dynamically based on collected responses to ARP requests broadcast on the network. This mechanism simply records the observed responses with no verification. This means the ARP table is vulnerable to including spoofed information from malicious responses to the ARP request-response sequence.
Manual ARP Entries:
It is also possible for entries to be added manually to the ARP table, on Linux we can see this with arp -e, where the Flags Mask indicates the type of ARP entry.
| Flags Mask | Meaning |
|---|---|
| C | Cached entry: dynamically learned from the ARP request and response sequence. |
| M | PerManent entry: manually added to the ARP table, static entry which will not time-out. |
| P | Published entry: manually added to the ARP table, instructs the host to respond to ARP requests for this address with the entry information. |
Depending on your objectives it may be important to consider the nature of the ARP entry.
Spoofed MAC Addresses
Although not a direct limitation of the ARP protocol, MAC addresses can be spoofed and may end up in ARP table entries. The ARP protocol will simply take the self-reported MAC address from devices responding to ARP requests.
ARP Security Concerns:
The limitations of the ARP protocol reveal a glaring security concern - the ARP table is not an infalliable source of information. The ARP table combines manual entries with information self-reported from other network devices. The lack of information verification mechanisms leads directly to the possibility of ARP based attacks:
| Attack | Description |
|---|---|
| ARP Poisoning | Corrupting or injecting malicious IP-to-MAC mappings in the ARP table. |
| ARP Spoofing | Impersonating another machine’s MAC address in an ARP mapping. |
| ARP MITM (Man-in-the-Middle) | Using ARP poisoning/spoofing to intercept network traffic. |
| ARP DoS (Denial of Service) | Using ARP poisoning/spoofing to map sufficient IP addresses to a single MAC address to overwhelm the target. |
Although these attacks will not be covered in detail in this post, penetration testing frameworks like Metasploit will have modules to perform ARP poisoning or other ARP based attacks.
Conclusion
With a select overview of the ARP protocol, this post illustrates just how much network information can be gathered by passively probing ARP data in memory.
Passive network discovery is a useful skill for pentesting, and reading ARP tables can be another tool in initial reconnaissance. Further, understanding how ARP data generation can be exploited allows for the tactical use of ARP as an attack vector.
On the defensive side, knowing how to interpret ARP tables can be useful for keeping tabs on local networks. Understanding the sources and limitations of ARP entries makes it easier to recognise ARP based attacks.
Which ever side you’re on, try out the instructions in this post. Reading and interpreting ARP data in memory does not require any special tools or installations. The ARP table is already there, you just need to take a peek.
Comments