Stay One Step Ahead of the Hackers by Hunting Suspicious Traffic
It is essential to understand what is normal in order to recognize what is not normal, such as a connection to port
443 with cleartext traffic. It is not possible to examine hundreds of thousands of packets per day at a workstation. Should malicious traffic traverse our hunting grounds, we should have access to a variety of enterprise products, including open-source software, that will assist us with this task and, ideally, capture a substantial amount of it. In this article, we will discuss how to identify normal network traffic when analyzing packets. The purpose of this article is to train your eye should you ever be required to inspect live or saved network traffic (
Beginning with the
Again, although we should be familiar with these protocols, we will briefly describe each one before analyzing their respective traffic.
ARP is a Layer 2 protocol that
IP uses to map
IP addresses to
ARP messages consist of a
REQUEST message and a
RESPONSE message. The message header is concluded with one of the operation codes listed below:
- Request (1)
- Reply (2)
In RFC 826, you can read more about
Some information to help differentiate between normal and suspicious ARP traffic.
Normal ARP Traffic
- ARP broadcasts are typical from clients and servers, as well as network devices at a normal rate.
ARPRequest is followed by a response, but this depends on who initiated the request. A network device may send numerous
ARPbroadcasts for a variety of reasons.
- Legitimate gratuitous
Suspicious ARP Traffic
- In a short amount of time, tens, hundreds, or even thousands of
ARPbroadcast messages are sent.
- Two identical MAC addresses with distinct IP addresses exist in a network.
ARPpackets sent by an attacker.
An attacker can manipulate the
ARP cache tables of other hosts by sending unnecessary
ARP replies. Gratuitous ARP replies are
ARP Reply messages that were not requested.
Thus, an attacker can send an
ARP Reply without waiting for a host to send an
ARP cache table may then contain fictitious data, and the attacker may send
ARP replies every
30 seconds or so to prevent the poisoned entry from expiring.
Below is a snapshot of 2 packets: 1 ARP Request & 1 ARP Reply:
To view the
MAC Address for both the source and the destination, we can make the following Wireshark adjustment:
View -> Name Resolution -> Physical Address Resolution
This image depicts an ARP Request packet:
The request (1) in the highlighted line indicates that this is an
ARP Request. The device at
10.54.15.100 requires the
MAC address for
10.54.15.68 in order to initiate communication with it. If the device at
10.54.15.100 already knew the
10.54.15.100 MAC address, it would be contained in its
ARP table (
ARP -a from command line):
This packet contains the response to the preceding packet:
This packet contains the
ARP Reply. We can quickly determine based on the Opcode (2). Within this packet, the Sender
MAC address contains the
MAC address of the device located at
MAC address will be added to
The preceding packets were generated by a virtual machine.
The following packet reflects an
ARP Request with a broadcast address as the destination within a network.
Using Wireshark, we will now examine an example of suspicious
Remember the following guidelines regarding normal and suspect ARP traffic:
Normal: ARP broadcasts from clients and servers, as well as network devices at a reasonable rate, are normal.
Suspicious: Tens, hundreds, or even thousands of ARP broadcast messages within a brief time frame.
Here is an image of a packet capture.
It displays seven ARP Request packets that were broadcast. According to physical address name resolution within Wireshark, the source device appears to be a Cisco device that is monitoring the status of various network devices.
PCAP from Wireshark Sample Captures page
How would we determine whether or not this is suspicious traffic? How do we know it’s not an issue with the Cisco device’s configuration or its normal behavior? Is Cisco equipment even present on the network?
Depending on your answers to these and other questions, you will determine whether further investigation is necessary. In this case, we will assume it is typical.
How about this traffic? Would it be considered suspicious or normal?
Clearly, this is suspicious traffic.
Even without knowing what legitimate device on your network could have that MAC address, we can tell something is amiss based on the rate and volume of
ARP Requests. Beginning with packet 15,
IP addresses increase by one and the time between packets is relatively short, indicating a scan.
Organizations may prohibit pinging machines within the network, but this does not impede the reconnaissance phase. An attacker may use alternative methods, such as an
ARP scan, to obtain the desired information, a map of the internal network.
If your organization does not implement USB Lockdown procedures, it is very simple to insert a USB drive and launch a variety of tools, such as penetration testing operating systems.
To return to the
MAC address, it is quite simple to change the
MAC address of a host to make it appear to be a legitimate device, so we cannot rely on it either.
In order to know when to investigate and when to ignore
ARP traffic, it is necessary to recall the fundamental behavior of
ARP from both the client and network device perspectives.
ARP can also be employed for nefarious purposes via techniques such as ARP Poisoning (Person-In-The-Middle Attacks).
Refer to the Wireshark Display Filter Reference for ARP for additional information on filtering ARP traffic.
ICMP (Internet Control Message Protocol) provides information about various network nodes. It is commonly employed during troubleshooting.
ICMP is utilized by utilities such as
Here you can learn more about ICMP.
This packet capture demonstrates Echo (Ping) requests and responses:
Below are the packet details for packet 4, the Echo (Ping) Request packet:
Type 8 &
Code 0 both indicate that this packet is an echo request.
Data represents a random text string.
Below we see packet details for the Echo (Ping) Reply packet, packet 5:
Type 0 and
Code 0 indicate that this is an echo reply.
Data should be the same string of random characters as the echo request. If so, the
ping utility returns a success message to the command line.
The data field of an
ICMP can serve as a covert channel or even an exfil channel. Large
ICMP packet sizes should be a warning sign. Additionally, keep an eye out for uncommon types/codes within
ICMP packets that are followed by a request, such as a Timestamp request.
The Wireshark Display Filter Reference for ICMP can be consulted for additional information on techniques for filtering ICMP traffic.
Want to learn practical Threat Hunting tactics and strategies? Enrol in MTH - Certified Threat Hunter Certification.