Incident response

Network traffic analysis for IR: Address resolution protocol (ARP) with Wireshark

Howard Poston
November 13, 2019 by
Howard Poston

The Address Resolution Protocol (ARP) was first defined in RFC 826. As the name suggests, it is designed to resolve IP addresses into a form usable by other systems within a subnet.

Network addressing works at a couple of different layers of the OSI model. At Layer 2, computers have a hardware or MAC address. At Layer 3, they have an IP address. Most high-level addressing uses IP addresses; however, network hardware needs the MAC address to send a packet to the appropriate machine within a subnet.

Learn Incident Response

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

ARP is designed to bridge the gap between the two address layers. It is a simple call-and-response protocol. The machine wanting to send a packet to another machine sends out a request packet asking which computer has a certain IP address, and the corresponding computer sends out a reply that provides their MAC address.

One important feature of ARP is that it is a stateless protocol. Once a computer has sent out an ARP request, it forgets about it. As a result, any computer receiving an ARP reply updates their ARP lookup table with the information contained within that packet. No verification is performed to ensure that the information is correct (since there is no way to do so).

This design has its pros and cons. ARP is a bit more efficient, since every system in a network doesn’t have to individually make ARP requests. Instead, everyone along the route of the ARP reply can benefit from a single reply.

However, the stateless nature of ARP and lack of verification leave it open to abuse. A computer will trust an ARP reply and update their cache accordingly, even if they didn’t ask for that information. The lack of verification also means that ARP replies can be spoofed by an attacker.

ARP in Wireshark

ARP packets can easily be found in a Wireshark capture. As shown in the image below, packets that are not actively highlighted have a unique yellow-brown color in a capture. ARP packets can also be filtered from traffic using the arp filter.

The structure of an ARP session is quite simple. The computer wishing to initiate a session with another computer sends out an ARP request asking for the owner of a certain IP address. The system with that IP address then sends out an ARP reply claiming their IP address and providing their MAC address.

As shown in the images above, the structure of an ARP request and reply is simple and identical. An ARP packet runs directly on top of the Ethernet protocol (or other base-level protocols) and includes information about its hardware type, protocol type and so on. ARP opcodes are 1 for a request and 2 for a reply. 

The meat of the ARP packet states the IP and MAC address of the sender (populated in both packets) and the IP and MAC address of the recipient (where the recipient’s MAC is set to all zeros in the request packet).

ARP analysis for incident response

ARP is a simple networking protocol, but it is an important one. ARP requests are how a subnet maps IP addresses to the MAC addresses of the machines using them. An attacker can take advantage of this functionality in a couple of different ways.

There are two main ways in which ARP can be used maliciously. ARP poisoning attacks can be used to set up a man-in-the-middle (MitM) attack, and ARP scanning can be used to enumerate the IP addresses actively in use within a network and the MAC addresses of the machines using them.

ARP poisoning

The most well-known malicious use of ARP is ARP poisoning. ARP is a stateless protocol, meaning that a computer does not record that it has made a request for a given IP address after the request is sent. Instead, when an ARP reply is received, a computer updates its ARP cache with the new information, regardless of whether or not that information was requested.

An attacker can take advantage of this functionality to perform a man-in-the-middle (MitM) attack. If an attacker sends an unsolicited ARP reply with fake information to a system, they can force that system to send all future traffic to the attacker.

These attacks can be detected in Wireshark by looking for ARP replies without associated requests. However, not all unsolicited replies are malicious. Some systems will send a gratuitous ARP reply when they enter or change their IP/MAC address on a network to prepopulate the ARP tables on that subnet with that networking information.

ARP request storms

ARP requests storms are a component of ARP poisoning attacks. Dynamic ARP caches will only store ARP information for a short period of time if they are not actively in use. In order to ensure that their malicious ARP information is used by a computer, an attacker will flood a system with ARP requests in order to keep the information in the cache.

The definition of an ARP request storm is flexible, since it only requires that the attacker send more ARP requests than the set threshold on the system. In Wireshark, look for a large number of requests for the same IP address from the same computer to detect this. The initial unsolicited ARP request may also be visible in the logs before the ARP request storm began.

ARP scans

ARP can also be used for scanning a network to identify IP addresses in use. By sending ARP requests for all of the IP addresses on a subnet, an attacker can determine the MAC address associated with each of these.

ARP scans can be detected in Wireshark if a machine is sending out a large number of ARP requests. Since this approach is used during scanning, it will include IP addresses that are not actively in use, so this can be used as a detection mechanism.

Learn Incident Response

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Sources

Howard Poston
Howard Poston

Howard Poston is a copywriter, author, and course developer with experience in cybersecurity and blockchain security, cryptography, and malware analysis. He has an MS in Cyber Operations, a decade of experience in cybersecurity, and over five years of experience as a freelance consultant providing training and content creation for cyber and blockchain security. He is also the creator of over a dozen cybersecurity courses, has authored two books, and has spoken at numerous cybersecurity conferences. He can be reached by email at howard@howardposton.com or via his website at https://www.howardposton.com.