Lab Setup<\/strong><\/p>\n\n\n\n For this lab, I used Wireshark to analyze a file called 1. In the first record, what is 192.168.11.11 trying to find?<\/strong><\/p>\n\n\n\n To answer this, I examined the first packet in the 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<\/p>\n\n\n\n 2. What is the Ethernet destination address in the ARP request? Why is the request sent to this address?<\/strong><\/p>\n\n\n\n While examining the ARP request in the packet capture, I checked the Ethernet II<\/strong> header to find the destination MAC address<\/strong>. In an ARP request, this address is typically set to the broadcast address<\/strong> This is done because the sender doesn\u2019t yet know the MAC address of the target IP and needs to ask all devices on the local network<\/strong> if they are the owner of that IP address. Broadcasting ensures that the request reaches every host on the subnet.<\/p>\n\n\n\n 3. What is the hexadecimal Ethernet II Type for an ARP request?<\/strong><\/p>\n\n\n\n It is 0x0806<\/p>\n\n\n\n 4. What is the Target MAC address of the ARP request? Why do you suppose this address is used?<\/strong><\/p>\n\n\n\n When analyzing the ARP request in Wireshark, I checked the Target MAC address<\/strong> field in the ARP header. This field was set to 00:00:00:00:00:00<\/strong>.<\/p>\n\n\n\n This makes sense because the sender is trying to discover the MAC address of the target IP\u2014they don\u2019t 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.<\/p>\n\n\n\n 5. Examine record 2. What type of ARP is this?<\/strong><\/p>\n\n\n\n In record 2<\/strong> of the capture, I analyzed the ARP packet details in Wireshark. Based on the fields, I could tell this was an ARP reply<\/strong>. Unlike an ARP request, which is broadcast to ask for a MAC address, the ARP reply is a direct response<\/strong> from the device that owns the IP address, providing its MAC address to the requester.<\/p>\n\n\n\n This completes the ARP resolution process, allowing the devices to communicate at the Ethernet level.<\/p>\n\n\n\n 6. What is the Sender MAC address of 192.168.11.1?<\/strong><\/p>\n\n\n\n To answer this, I looked at the ARP reply packet in the capture where 192.168.11.1<\/strong> is listed as the sender. In the ARP header, the Sender MAC address<\/strong> 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.<\/p>\n\n\n\n 7. What is the MAC address of the intended recipient of this ARP message?<\/strong><\/p>\n\n\n\n To determine the intended recipient’s MAC address, I examined the Target MAC address<\/strong> 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.<\/p>\n\n\n\n Examine records 3, 4, and 5, which are all associated with each other. What do you think is happening?<\/strong><\/p>\n\n\n\n After examining records 3, 4, and 5<\/strong>, it became clear that something suspicious was occurring with the ARP replies.<\/p>\n\n\n\n In record 3<\/strong>, host 192.168.11.4<\/strong> sends an ARP request asking for the MAC address of 192.168.11.111<\/strong>. This is a red flag. The presence of two conflicting ARP replies suggests that someone is attempting to poison the ARP cache<\/strong> of the original requester (192.168.11.4<\/strong>). The attacker is trying to trick it into associating the IP address 192.168.11.111<\/strong> with the attacker\u2019s MAC address<\/strong>, effectively redirecting traffic meant for the legitimate host.<\/p>\n\n\n\n This is a classic example of ARP spoofing<\/strong>, a technique used in man-in-the-middle (MITM) attacks<\/strong> to intercept or manipulate traffic. The warning in Wireshark also highlights this as a duplicate IP address<\/strong> issue, which further confirms the attempt to mislead the network.<\/p>\n\n\n\n In this exercise, I reviewed packets 6 through 55<\/strong>, which represent a small sample of many similar records captured during an attack simulation using the macof<\/strong> tool. The focus was on analyzing the Ethernet headers<\/strong> at the link layer.<\/p>\n\n\n\n 1. What is the source MAC address of records 6, 7, and 8?<\/strong> 2. What is the source IP address in records 6\u201355?<\/strong> 3. What is wrong with these MAC address-to-IP address associations? What does this indicate?<\/strong> Link Layer Analysis Lab \u2013 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 \u2013 Analyzing the First Record 1. In the first record, what is 192.168.11.11 trying to find? To answer […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[8,6],"class_list":["post-75","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-link-layer","tag-wireshark"],"_links":{"self":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/75","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=75"}],"version-history":[{"count":4,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/75\/revisions"}],"predecessor-version":[{"id":89,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/75\/revisions\/89"}],"wp:attachment":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=75"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=75"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=75"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}link.pcap<\/code>.<\/p>\n\n\n\nExercise 1 \u2013 Analyzing the First Record<\/h3>\n\n\n\n
link.pcap<\/code> file. <\/p>\n\n\n\n![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-14-1024x481.png\")
<\/figure>\n\n\n\nff:ff:ff:ff:ff:ff<\/code>.<\/p>\n\n\n\n![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-15-1024x89.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-16.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-17-1024x614.png\")
<\/figure>\n\n\n\nExercise 2 \u2013 Interpreting Linked ARP Activity<\/h3>\n\n\n\n
![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-18.png\")
<\/figure>\n\n\n\n
In record 4<\/strong>, a legitimate response comes from 192.168.11.111<\/strong>, returning its correct MAC address.
However, in record 5<\/strong>, a second ARP reply is sent\u2014also claiming to be from 192.168.11.111<\/strong>, but with a different MAC address<\/strong>.<\/p>\n\n\n\n![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-19.png\")
<\/figure>\n\n\n\nExercise 3 \u2013 Analyzing Suspicious MAC-to-IP Associations<\/h3>\n\n\n\n
I checked each record and found that all three packets had different source MAC addresses<\/strong>:<\/p>\n\n\n\n\n
67:aa:17:2f:ba:02<\/code><\/li>\n<\/ul>\n\n\n\n![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-20.png\")
<\/figure>\n\n\n\n\n
ac:1d:9d:2e:7c:71<\/code><\/li>\n<\/ul>\n\n\n\n![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-21.png\")
<\/figure>\n\n\n\n\n
c6:58:a2:5e:02:49<\/code><\/li>\n<\/ul>\n\n\n\n![\"\"](\"https:\/\/epbrtcybersecurityportfolio.xyz\/wp-content\/uploads\/2025\/06\/image-22.png\")
<\/figure>\n\n\n\n
All of these packets used the same source IP address: 10.10.10.5<\/code>.<\/p>\n\n\n\n
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<\/strong>, which is a hallmark of a MAC flooding attack<\/strong>. Tools like macof<\/code> generate thousands of fake MAC\/IP combinations to overflow the switch\u2019s MAC address table, potentially forcing it into fail-open mode<\/strong>, where it floods traffic to all ports\u2014opening the door to packet sniffing<\/strong> by an attacker.<\/p>\n","protected":false},"excerpt":{"rendered":"