The Network Access/Link Layer

Link Layer Analysis Lab – Overview and Setup

This set of exercises focuses on analyzing network activity at the Link Layer.

Lab Setup

For this lab, I used Wireshark to analyze a file called link.pcap.

Exercise 1 – Analyzing the First Record

1. In the first record, what is 192.168.11.11 trying to find?

To answer this, I examined the first packet in the link.pcap file.

We can see that this an ARP request going from mac address aa:00:04:00:0a:04 (which is the mac address associated with the IP address 192.168.11.11) to the mac address ff:ff:ff:ff:ff:ff (the broadcast address). It is looking for the mac address associated with the IP address 192.168.11.1

2. What is the Ethernet destination address in the ARP request? Why is the request sent to this address?

While examining the ARP request in the packet capture, I checked the Ethernet II header to find the destination MAC address. In an ARP request, this address is typically set to the broadcast address ff:ff:ff:ff:ff:ff.

This is done because the sender doesn’t yet know the MAC address of the target IP and needs to ask all devices on the local network if they are the owner of that IP address. Broadcasting ensures that the request reaches every host on the subnet.

3. What is the hexadecimal Ethernet II Type for an ARP request?

It is 0x0806

4. What is the Target MAC address of the ARP request? Why do you suppose this address is used?

When analyzing the ARP request in Wireshark, I checked the Target MAC address field in the ARP header. This field was set to 00:00:00:00:00:00.

This makes sense because the sender is trying to discover the MAC address of the target IP—they don’t know it yet. The all-zero MAC address is used as a placeholder to indicate that this information is currently unknown and is the whole reason the ARP request is being broadcast.

5. Examine record 2. What type of ARP is this?

In record 2 of the capture, I analyzed the ARP packet details in Wireshark. Based on the fields, I could tell this was an ARP reply. Unlike an ARP request, which is broadcast to ask for a MAC address, the ARP reply is a direct response from the device that owns the IP address, providing its MAC address to the requester.

This completes the ARP resolution process, allowing the devices to communicate at the Ethernet level.

6. What is the Sender MAC address of 192.168.11.1?

To answer this, I looked at the ARP reply packet in the capture where 192.168.11.1 is listed as the sender. In the ARP header, the Sender MAC address field contains the hardware address associated with that IP (00:0c:29:03:23:19). This is the MAC address the device is announcing to the network, and it’s what other hosts will use to communicate at the Ethernet layer.

7. What is the MAC address of the intended recipient of this ARP message?

To determine the intended recipient’s MAC address, I examined the Target MAC address field in the ARP reply. This field shows the hardware address (aa:00:04:00:0a:04) of the device that originally sent the ARP request.

Exercise 2 – Interpreting Linked ARP Activity

Examine records 3, 4, and 5, which are all associated with each other. What do you think is happening?

After examining records 3, 4, and 5, it became clear that something suspicious was occurring with the ARP replies.

In record 3, host 192.168.11.4 sends an ARP request asking for the MAC address of 192.168.11.111.
In record 4, a legitimate response comes from 192.168.11.111, returning its correct MAC address.
However, in record 5, a second ARP reply is sent—also claiming to be from 192.168.11.111, but with a different MAC address.

This is a red flag. The presence of two conflicting ARP replies suggests that someone is attempting to poison the ARP cache of the original requester (192.168.11.4). The attacker is trying to trick it into associating the IP address 192.168.11.111 with the attacker’s MAC address, effectively redirecting traffic meant for the legitimate host.

This is a classic example of ARP spoofing, a technique used in man-in-the-middle (MITM) attacks to intercept or manipulate traffic. The warning in Wireshark also highlights this as a duplicate IP address issue, which further confirms the attempt to mislead the network.

Exercise 3 – Analyzing Suspicious MAC-to-IP Associations

In this exercise, I reviewed packets 6 through 55, which represent a small sample of many similar records captured during an attack simulation using the macof tool. The focus was on analyzing the Ethernet headers at the link layer.

1. What is the source MAC address of records 6, 7, and 8?
I checked each record and found that all three packets had different source MAC addresses:

• Record 6: 67:aa:17:2f:ba:02

• Record 7: ac:1d:9d:2e:7c:71

• Record 8: c6:58:a2:5e:02:49

2. What is the source IP address in records 6–55?
All of these packets used the same source IP address: 10.10.10.5.

3. What is wrong with these MAC address-to-IP address associations? What does this indicate?
This behavior is highly abnormal. Multiple packets are using different MAC addresses while claiming the same IP address. This inconsistency suggests that the traffic is spoofed, which is a hallmark of a MAC flooding attack. Tools like macof generate thousands of fake MAC/IP combinations to overflow the switch’s MAC address table, potentially forcing it into fail-open mode, where it floods traffic to all ports—opening the door to packet sniffing by an attacker.