Blog

  • Snort Writing Rules 1

    Objectives
    This lab is the first in a series aimed at guiding you through writing effective rules for IDS/IPS tools such as Snort and Suricata.

    Details
    You’ll be using the packet capture file located at /sec503/Exercises/Day3/01_exploit.pcap. The goal is to write a signature that correctly detects the exploit within the capture, which simulates a system compromise using a fictional CVE. Treat the capture as an example of traffic generated by a proof-of-concept exploit targeting a LamanServer service on a local network.

    CVE-2026-0503
    Description
    This CVE relates to a buffer overflow in the Novak Enterprises LamanServer application. The vulnerability allows remote code execution and is triggered through traffic to TCP port 50503. Although a proof-of-concept exploit exists, there are no known instances of real-world exploitation.

    The vulnerability occurs in the command parser, which only becomes accessible after the server receives a HELO command.

    Exercise 1

    Description: Write a rule that successfully detects the exploit in the file named 01_exploit.pcap by using one or more content options.

    1) When developing rules for Snort (or similar IDS/IPS tools), it is best practice to use a custom copy of the configuration file. While it might seem easier to work with a minimal configuration specific to your testing environment, doing so may cause you to miss critical updates or necessary settings for a rule to function properly in a production environment.

    First, we are going to validate the configuration file located in the etc directory:

    2) Write a basic alert rule that includes only a rule header and leaves the rule options section empty. Test this rule using the 01_exploit.pcap file. Make sure the rule displays alerts in the console and saves any logs to the /sec503/Exercises/Day3/logs directory. The rule should trigger an alert for every packet in the capture file.

    Let’s first open the local.rules file:

    There’s already a rule in place from the previous lab. Using an editor, I am going to comment out this rule by adding a # at the beginning of the line It’s a good idea to keep the rule commented for reference.

    To create a new rule header, I have to start by choosing the action the rule should perform. Possible actions include:

    • alert: generate an alert
    • pass: allow traffic through without further inspection
    • log: log packets but don’t raise an alert
    • sdrop: silently drop the packet (IPS only)
    • drop: drop and log the packet (IPS only)
    • reject: block the packet, log it, and send a TCP RST to reset the connection
    • activate: enable a related dynamic rule if this rule matches
    • dynamic: define a rule that can only be triggered by an activate rule

    Next, the rule header must include the protocol, source IP, source port, direction, destination IP, and destination port. Supported protocols are:

    • ip
    • tcp
    • udp
    • icmp

    Following the header, the rule must include the options section. This goes right after the destination port and must be enclosed in parentheses. In this case no options are needed, therefore I can use empty parentheses. I am going a very simple rule that generates an alert everytime a packet travelling over IP is encountered in the file:

    Let’s now see the results generated by this alert:

    3) Incorporating Metadata in Custom Snort Rules

    When creating a custom Snort rule, it’s important to include metadata to ensure clarity, traceability, and effective alerting. For this rule, I assigned a signature ID (SID) of 1000000 and set the revision number to 1. I also defined a custom alert message to be displayed when the rule is triggered.

    Metadata should reflect key contextual information. According to best practices:

    The reference field links the rule to external documentation, such as CVEs or BugTraq entries. When supported, these references can be automatically converted into URLs for easier follow-up.

    The rev field indicates the rule’s revision number. Each time a rule is updated, this number should be incremented. This helps avoid confusion caused by stale or outdated rules and streamlines troubleshooting.

    The sid (signature ID) is a mandatory unique identifier for each rule. IDs under 1,000,000 are typically reserved, so custom rules should use higher values to prevent conflicts.

    The msg field contains the message that will be displayed when the rule is triggered. This should clearly describe the nature of the alert.

    4) Analyzing Packet Content for Reliable Signature Matching

    As part of the analysis of 01_exploit.pcap, the objective is to identify specific content within the packets that could serve as a reliable signature for rule creation. The ideal content should be distinct enough that it won’t appear in regular network traffic, helping to minimize false positives.

    Effective matching content is typically a string that is at least four bytes long—longer is better to improve match reliability. If shorter strings must be used, they should be supplemented by longer, more unique strings to ensure accurate detection.

    Snort prioritizes locating the longest matching string, particularly one found at a known offset or near the beginning of the packet payload. Understanding how Snort evaluates packet data in this way is key to crafting precise and effective intrusion detection rules.

    I am going to use tcpdump to look at the first 10 packets payload in this file:

    I am going to use the payload in the 9th packet as a signature for my Alert. We have 3 strings that can be used as content for this signature: a series of Xs followed by PH/bin and 2/sh. Using this payload in the options’ content section, we write the below alert:

    Let’s make sure that the alert wroks as intended:

  • Running Snort

    Purpose
    This lab is an introduction to Snort and its output. It focuses on helping a new user get comfortable with the tool.

    Exercise 1

    1)Start by exploring Snort’s available command-line options. Run the following command to view help information and understand what parameters are available:

      2)Which command-line option should you use to specify a particular configuration file when running Snort?

      Going through the above list of available parameters, we find the below option

      Exercise 2

      1)Which Snort command-line option can be used to check the current configuration and generate a report?

          2)Launch Snort using the correct option to validate the configuration and generate a report, pointing to the snort.lua configuration file located in /sec503/Exercises/Day3/snort/.

          Using the 2 questions above, we can easily answer this question:

          3) After running Snort, you’ll see a stream of initialization messages. Does the snort.lua configuration file pass validation?

          4) How many rules did Snort confirm it loaded?

          5) Run Snort again with the -T option to test the configuration, but this time use snort-broken.lua as the config file. Add the -q option to reduce clutter by hiding the usual startup messages—this will make the error message easier to spot.

          6) In which file is the error located? What is the specific error message?

          The error is located in file called local.rules. Two variables are undefined in this file.

          7) Use the diff command to compare the contents of snort.lua and snort-broken.lua. What differences do you observe?

          The main difference is that snort.lua defines two variables that are commented out in snort-broken.lua. Specifically, HOME_NET is set to the 10.121.0.0/16 network, while EXTERNAL_NET is defined as any network not included in HOME_NET (using the exclamation mark ! for negation). These variables help Snort distinguish between IP addresses inside the monitored network and those outside of it. In snort-broken.lua, these variable definitions are disabled using comment markers (--), so they aren’t loaded. Snort 3 requires that both HOME_NET and EXTERNAL_NET be properly set.

          Exercise 3

          This task is about running Snort in IDS mode. You’ll be using a configuration file and analyzing traffic from a packet capture file instead of live network data. For this, use the file named sample.pcap, located in the /sec503/Exercises/Day3 folder.

          1) The goal is to run Snort using the snort.lua configuration file and see alerts on your console. To make this work, you’ll need to use a few options that haven’t been covered yet.

          To accomplish this task, I ran snort with the below options:

          2) Looking at the alert output, you’ll notice that after the GID, SID, and revision number, there’s a message, followed by a priority level. After that, it shows the protocol, the source IP address and port, and then the destination IP address and port (shown with the arrow symbol “->”). What are the values for the protocol, source IP and port, and destination IP and port?

          The protocol is TCP. The source IP address is 10.121.70.151. The source port is 21 (FTP). The destination IP address is 10.234.125.254 and the destination port is 2217.

          Exercise 4
          Task: Run Snort in IDS mode and make sure logging is enabled.

          1) In the previous exercise, you saw that Snort does not show alerts by default unless it’s specifically told to. Figure out how to configure Snort so it logs fast alerts to a file. The alerts should be saved in the logs directory, located in the current folder or at /sec503/Exercises/Day3/snort/logs.

          Wed can use the -l option to log a given file to a desired directory:

            The file was correctly saved in the chosen directory:

            2) Look at the content of this file

            This is the same content as what we saw in the console output above.

            3) Review the available logger plugins again and identify one that supports both event and packet logging.

            The --help-plugins option provides detailed information about the different plugins that are available. Looking at the list, the unified2 plugin appears to be a good choice. This plugin can be run with the -A option:

              After the unified2 log file has been created, it can be read using tools such as u2spewfoo and u2boat. Running u2spewfoo on the file will display the alert and a packet dump showing what triggered it.

            1. Wireshark part III

              Exercise 1

              Description: Extract the web object image from wireshark3.pcap and view it. According to the extracted image, what did Snort save?

              Exercise 2

              Description: Carve and decode the base64-encoded message from the SMTP exchange between 10.10.10.10 and 10.10.10.25. What does it say?

              First, we apply a filter to capture all the packets involved in this exchange:

              Then, we can right-click on any of these packets so that we can follow the TCP stream for this conversation:

              We can then save this stream as ‘raw’:

              Using notepad, I can now edit the file I just saved.

              I have to delete all lines above and below the single base64-encoded line and delete all blank lines.

              I can now decode the resulting base64-encoded carved file. There are many online base64 decoders available. I can also use built-in tools on most operating systems.

              For Windows, I am going to use the built-in certutil command-line tool. The certutil command with the –decode option takes in a base64 file and outputs the decoded file. The format is:

              The encoded message says: You rock big time!

            2. UDP-ICMP

              This lab focused on analyzing packet behavior related to UDP and ICMP. It was designed to help understand how certain traffic patterns can trigger ICMP error messages and under what conditions those messages should or shouldn’t appear.

              Exercise 1 – Investigating ICMP Echo Requests

              Task:
              The first six records in the capture are grouped in pairs. Each pair includes one packet that would normally trigger an ICMP error, followed by a response or lack of one. According to RFC 1122 and the ICMP protocol, the goal is to determine whether these ICMP errors should be generated, and if not, why.

              Records 1 and 2:

              We see an echo request sent to the address 255.255.255.255 (the broadcast address) and a destination unreachable (Host unreachable) response sent from 192.168.11.1. An echo request sent to the broadcast address should not generate an ICMP error message and it would be an open door for DDOS attacks or broadcast storm to happen.

              Records 3 and 4:

              Record 3 has a More Fragment flag set and a fragment offset of 32 in its IP header which means it is part of fragment train. We are missing the fragment with offset 0 (which would be the first fragment for this given train) and the rest of the fragments located before and after offset 32. Without these missing fragments, the receiving host would not be able to reassemble these records. The ICMP message received in record 4, “TTL exceeded”, should only be sent if the fragment with offset 0 was received which is not the case here. In normal traffic condition, this message would not be generated.

              Records 5 and 6:

              in Record 5 we see 192.168.11.65 sending an ICMP message Type 3 code 1: Destination Unreachable (Host Unreachable) to 192.168.11.1. Normally, this type of message is sent as a response to packet sent to a host that cannot be reached but in this case it is not a response. Record 6 is also an ICMP error message for Host Unreachable. An ICMP error message should never be sent as a response to another ICMP error message otherwise this would generate an endless loop.

              Exercise 2 – ICMP Echo Request Activity (Packets 12–35)


              Analyze packets 12 through 35 in the capture file to determine the nature of the observed activity and identify the likely operating system generating the ICMP echo requests.

              We see sets of 3 Echo Requests being sent from 192.168.11.48 to 68.85.138.249. The first set of 3 has a TTL of 1 and then this TTL gets incremented by 1 every set. These records get an ICMP error message TTL exceeded up until record 31 where the response is an echo reply. This tells us that the host is located 4 hops away from the sender and we can map all the routers passed along the way. The behavior observed corresponds to a Windows tracert using ICMP to identify all the routers along the path from 192.168.11.46 to 68.85.138.249. The tracert command on non-Windows systems typically uses UDP packets instead of ICMP.

              What are the intermediate routers that appear along the path?

              We can easily find this data by looking at the IP addresses sending these ICMP error messages:

              • 192.168.11.1 (records 13, 15 , 17)
              • 192.168.1.1 (records 19, 21, 23)
              • 69.250.56.1 (records 25, 27, 29)

              Exercise 3 – Find the packet number that caused an ICMP error.

              a) Identify the packet that triggered the ICMP error message “time to live exceeded (fragment reassembly timeout)” in record 11.

              Looking at the ICMP portion of record 11, we can find an embedded IP packet that represents part of the original offending packet. Filtering on a unique field in this embedded IP packet like the checksum, we can find the related packet:

              Record 7 is the offending packet:

              b) Identify the packet number that triggered the ICMP error message “port unreachable” in record 36.

              We apply the same type of filtering that was used in the previous question to record 36:

              Record 8 is the packet that generated the ICMP error message in record 36.

              Exercise 4ICMP echo requests and replies found in records 37–46 are all related. What is this activity?

              Each reply receives several echo requests from what appears to be the same IP address. Why is there an imbalance. One echo request should only be answered by one echo reply. We also see a lot of data being carried in both these echo requests and replies packets:

              This mismatch between echo requests and replies and the amount/type of data caried by these ICMP packets are one of the telltale signs of an ICMP tunnel. This is an example of ptunnel that uses ICMP as a tunnel for other protocols, in this case SSH.

            3. TCP

              Lab 2.3 – TCP Packet Analysis

              This lab focused on deepening my understanding of core TCP concepts through packet inspection.

              Exercise 1 – Verifying TCP Protocol Checksum

              Task: Examine the embedded TCP checksum in the packet with:

              • Destination IP: 192.168.2.109
              • Source Port: 2056

              The checksum is equal to 0x0000 which is not a valid checksum:

              Wireshark also flagged this field as incorrect and highlighted the discrepancy in red. This malformed TCP checksum indicates a corrupted or deliberately crafted packet. It will be dropped by any compliant receiving host, as TCP checksums are used to verify the integrity of the header and data.

              Exercise 2 – Suspicious Use of TCP Sequence Numbers

              Objective:
              Investigate two TCP packets with a source port of 4545 and identify what’s unusual about their sequence numbers and behavior.

              We see that both packets have the same sequence number (76148922):

              Both of these packets have the same source and destination address. These packets are trying to establish a connection with a web server (the SYN flag is set). We also notice that both packets have a TCP payload of 12 bytes which is very unusual and suspicious for a TCP packet with a SYN flag set.

              This pattern strongly suggests evasive or malicious behavior, possibly an attempt to:

              • Bypass intrusion detection systems (IDS) by fragmenting or duplicating payload delivery
              • Confuse TCP reassembly logic on different hosts
              • Test how different stacks handle duplicate sequence numbers

              Additionally, the TCP flag settings are unusual for carrying payloads, potentially indicating deliberate manipulation of protocol norms.

              Exercise 3 – Comparing SYN Retries vs. Different Connection Attempts

              Objective:
              Analyze two sets of TCP traffic to determine which is a case of SYN retries (retransmissions) and which represents multiple separate connection attempts.

              Details:

              The activity involves:

              • 10.254.1.8 → port 21
              • 10.114.187.126 → port 143

              To examine the traffic, I used the following tcpdump filter:

              For this first set of activity, we notice that the source port and the sequence number stay the same for all the packets. For the second set of activity, we see that a different source port is used for each retransmission and a different sequence number is generated for each retransmission:

              This first set of connections clearly represents SYN retries:

              • The source port (3655) and TCP sequence number (1216633961) remained the same across all packets, which is a strong indicator of retransmissions rather than new connection attempts.
              • The timing pattern between packets followed a doubling back-off pattern (e.g., 3s, 6s, 12s), which is typical of TCP’s retransmission algorithm when no SYN-ACK is received.

              In contrast, the second set of packets:

              • Had varying source ports and different initial sequence numbers
              • Showed non-uniform timestamps, more consistent with multiple, unique connection attempts

              Conclusion:

              • Set 1 is clearly retries to a non-responsive host
              • Set 2 is a sequence of independent SYN connections, possibly part of a port scan or host enumeration

              Exercise 4 – Detecting Crafted TCP Fields

              Objective:
              Analyze a TCP connection from source 192.0.2.1 to destination 10.10.10.1 and identify at least three anomalies or indicators of packet crafting.

              Analysis & Findings:

              1. The source and Destination port are 0. These are not used in normal traffic.
              2. The FIN, RST, SYN, PSH, ACK and URG flags are all set which abnormal.
              3. One of the TCP options in the packet declared an Maximum Segment Size of 0, which is invalid. The MSS value indicates the maximum amount of TCP payload a sender is willing to receive, and setting it to zero would effectively prevent any data transfer.

              Exercise 5 – Detecting Spoofed SYN/ACK Traffic

              Scenario:
              We observed a large number of SYN/ACK packets coming from source IP 68.178.232.100 and supposedly going to 10.10.10.x hosts. However, our outbound monitoring sensor shows no evidence that the 10.10.10.x hosts ever sent SYNs—which is a red flag.

              A SYN/ACK is sent in response to a SYN packet. If we have no evidence of 10.10.10.x hosts sending SYNs then these addresses might have been spoofed by an attacker.

              Further investigation reveals that the attacker likely crafted the SYN packets with some very clear anomalies.

              1. DoS via spoofed connections:
                It appears the attacker was attempting a denial-of-service (DoS) attack against 68.178.232.100 by flooding port 80 with fake TCP connection attempts. By using spoofed source IP addresses (such as those in the 10.10.10.x range), the attacker tries to mask their identity and avoid detection or filtering.
              2. Identical source ports (port 1024):
                All of the supposed client packets used source port 1024. In legitimate TCP traffic, source ports are typically randomized. The repeated use of the same source port across multiple packets targeting the same destination is highly suspicious and suggests intentional packet crafting.
              3. Identical initial sequence numbers:
                Each spoofed SYN packet used the same initial sequence number: 462297438. Real TCP connections use randomized sequence numbers to ensure connection uniqueness and prevent certain types of attacks. The use of the same sequence number repeatedly is another sign of fabricated traffic.

              Exercise 6 – Investigating an Unusual Packet in a TCP Session

              Objective:
              Analyze the full TCP session between 192.168.1.105 (source port 18655) and 192.168.1.103. The task was to identify what’s strange about the fourth packet, as well as why the connection continues afterward.

              I noticed that the packet was indeed a reset (RST), but it had an invalid TCP checksum. This is important because receiving hosts are designed to silently discard packets with bad checksums.

              If a device like an intrusion detection or prevention system (IDS/IPS) doesn’t validate TCP checksums, it might mistakenly interpret the packet as a legitimate RST. It would then stop tracking the session, assuming the connection is closed. This means it would miss any traffic that follows.

              However, the receiving host in this case ignores the bad RST due to the invalid checksum and continues the session. It goes on to receive and acknowledge two additional segments, which contain a suspicious payload. When reassembled, that payload includes:

              GET /EVILSTUFF HTTP/1.1\r\n\r\n

              This is clearly crafted content with malicious intent. The goal here seems to be evasion—bypassing systems that don’t check checksums properly. The attacker uses a fake RST to throw off monitoring tools, while the target system ignores the bad packet and accepts the real payload.

            4. Writing tcpdump filters

              This lab focused on building familiarity with tcpdump filters, particularly for identifying specific traffic based on TCP flags. The lab also introduced the use of TCP flags, which play a key role in identifying different types of TCP traffic (e.g., SYN, ACK, FIN).

              Exercise 1 – Identifying TCP Connection Attempts with tcpdump

              Objective:
              Use tcpdump to examine records from the file int-server.pcap and identify initial TCP connection attempts from clients to servers. The goal is to isolate packets where only the SYN bit is set—this indicates the start of a TCP handshake.

              Steps Taken:

              1. Command Setup:
                To simplify the output, I used the -n (no DNS resolution) and -t (no timestamp) flags
              2. Filtering on TCP Flags:
              3. TCP control flags are located at byte offset 13 in the TCP header (tcp[13]). For SYN-only packets (i.e., no ACK or other bits set), we need to match exactly the binary value 00000010, which is 0x02 in hex.
              4. tcpdump Filter Expression:
              5. The appropriate filter to match only SYN packets is:

              We see attempted connections from the clients to ports 25(SMTP), 445(SMB), 4444(default port used by Metasploit), 999, 80(HTTP) and 53(DNS).

              Exercise 2 – Filtering for TCP SYN-ACK Responses

              Objective:
              Use tcpdump to identify packets from the int-server.pcap file where a server responds to a connection request—i.e., where both the SYN and ACK flags are set. This indicates the server is listening and willing to establish a connection.

              Understanding TCP Flags:

              • The TCP flags byte is at offset 13 (tcp[13])
              • ACK = 0x10
              • SYN = 0x02
              • Therefore, SYN-ACK = 0x12 (00010010 in binary)

              tcpdump Filter Used:

              The server ports that responded are 25, 445 and 4444.

              Exercise 3 – Filtering for TCP Session Termination (RST or FIN)

              Objective:
              Use tcpdump to identify packets from the int-server.pcap file that contain termination flags, specifically the RST or FIN flags. These flags signal that a TCP session is being closed—either gracefully (FIN) or abruptly (RST).

              Flag Values:

              • FIN = 0x01
              • RST = 0x04

              Unlike previous filters that matched exact values, this task required detecting whether either of the two termination flags is present, regardless of other flags that might also be set.

              Using a Mask Byte:

              The correct approach is to apply a mask byte that preserves only the FIN and RST bits:

              • Binary: 00000101
              • Hex: 0x05

              The filter will check if either of these bits is present using a bitwise AND mask.

              tcpdump Filter Used:

              We see 7 records with either or both the FIN and RESET flags set.

              Exercise 4 – Filtering for TCP Packets with Both PSH and ACK Flags on Port 143 (IMAP)

              Objective:
              Use tcpdump to extract the first five packets from int-server.pcap that meet all the following criteria:

              • Destination port is TCP 143 (IMAP)
              • Both the PUSH and ACK flags are set
              • Other flags may be present as well

              TCP Flags Reference:

              • ACK = 0x10 (bit 4)
              • PSH = 0x08 (bit 3)
                Combined, they yield a value of 0x18 (00011000 in binary)

              To isolate packets where both these bits are set (regardless of other flags), I used a bitmask to mask all other bits:

              • Mask: 0x18
              • Value: 0x18

              tcpdump Filter Used:

            5. Wireshark Display Filters

              Wireshark Display Filters Lab – Overview and Setup

              This lab focused on becoming more familiar with using Wireshark display filters to isolate specific types of traffic.

              Exercise 1 – Filtering DNS Queries for a Specific Domain

              Task: Find the packet record number(s) where a DNS query name contains the string glenhighland.

              There are many ways to solve this. One way is to filter the packets in Wireshark for DNS query name using the filter ‘dns.qry.name’ and then looking for the glenhighland string in the filtered packets using the Edit/Find Packet menu. Packets 101 and 102 contains this string.

              Exercise 2 – Finding ARP Request Records

              Task: Find all ARP request records. How many are there, and what filter did you use?

              To complete this task, I used a Wireshark display filter that isolates ARP request packets specifically. First, I reviewed the structure of an ARP packet by looking at one in the packet list which Wireshark identified as a request under the Address Resolution Protocol section.

              I then right clicked on the Opcode line and applied this same filter to the packet list.

              The arp.opcode==1 gets applied, and 16 packets get displayed (it is shown at the bottom right corner of the wireshark screen).

              Exercise 3 – Identifying ICMP Echo Replies with Undersized IP Payloads

              Task: Find the record numbers of any ICMP echo reply (type 0) frames that required zero-padding due to being smaller than the minimum acceptable Ethernet II length.

              To solve this, I first recalled that the minimum Ethernet II frame size is 64 bytes, and that the Ethernet header (14 bytes) plus trailer (4 bytes) leave at least 46 bytes required for the IP payload. Therefore, any IP datagram smaller than 46 bytes would be too short and must be padded to meet Ethernet’s minimum.

              I used the Wireshark Display Filter Expression dialog to build a compound filter that would identify:

              • ICMP echo replies (type 0)
              • IP datagrams with a Total Length < 46

              To do this:

              1. I opened Analyze > Display Filter Expression
              2. Selected the field ip.len
              3. Chose the less than (<) relation
              4. Entered the value 46
              5. Added icmp.type == 0 to narrow it to echo replies

              We identified 3 packets using these combined filters.

              Exercise 4 – Isolating and Exporting DNS over UDP Traffic

              Task: Find all records where the UDP protocol is carrying DNS traffic. How many are there? Save those packets to a new file named dns.pcapng.

              To complete this, I used this display filter in Wireshark:

              This filter shows all packets where DNS communication is occurring over UDP (14 packets are displayed).

              Once filtered, I saved the displayed packets to a new capture file:

              1. Went to File > Export Specified Packets.
              2. Entered the filename: dns.pcapng.
              3. Selected All packets and Displayed (to export only the filtered results).
              4. Clicked Save.
            6. Fragmentation

              IP Fragmentation Lab – Overview and Setup

              This lab focused on exploring the behavior and structure of IP fragmentation. The exercises require close analysis of fragmented IP packets using either Wireshark or tcpdump.

              Exercise 1 – Analyzing the First Two IP Fragments

              Look at the first two records. They are related fragments and are the only ones associated with this pair of fragments. What do you think happens when they are sent?

              After identifying the first two packets as related IP fragments, I needed to confirm whether the full set of fragments was present. I used the following tcpdump command to examine fragmentation details more closely:

              Both packets showed more fragments flag set (flags [+]), but neither was marked as the last fragment (with offset and MF flag = 0). This means that the packet reassembly could not be completed, as at least one fragment was missing from the set.

              To see how the system reacts to this failed reassembly, I looked for an ICMP error message that might be triggered by this condition. I ran:

              Sure enough, shortly after the two fragment packets, I found an ICMP “Time Exceeded – Fragment Reassembly Time Exceeded” message. This type of ICMP error is sent when the receiver cannot finish reassembling a fragmented IP packet within the allowed time window.

              The error response appeared in record 14, indicating the network’s handling of incomplete fragmentation and how it alerts the sender when reassembly fails.

              Why didn’t records 3 and 4 (a different pair of related fragments) generate the same type of ICMP error message?

              To answer this, I examined the fragmentation details of records 3 and 4. Although they represent another pair of related fragments, neither one has a fragment offset of 0. The packet corresponding to the third record has an offset of 1480. This is important because only the first fragment (offset 0) contains the protocol field, which identifies the embedded protocol (like ICMP, TCP, etc.).

              Without that first fragment, the receiving system can’t determine what protocol the original datagram was using. As a result, it doesn’t send an ICMP “Fragment Reassembly Time Exceeded” message, since it lacks the context needed to generate one.

              Exercise 2 – Identifying Fragment Overlap and Suspicious Packet Behavior

              In this exercise, I analyzed packets 5, 6, and 7, which appeared to be related fragments. At first glance, they looked like they might belong to a single fragmented IP packet, but something unusual stood out.

              Fragment Overlap Issue
              Packets 5 and 6 both have a fragment offset of 0, meaning they are both marked as the first fragment. However, they have different total lengths, which would cause them to overlap if processed together. Packet 7 appears to be the final fragment in this set, but it overlaps with packet 6 based on its offset and length.

              This kind of fragment overlap can be interpreted differently depending on the operating system, making it a potential tactic for evasion or exploitation. Some systems may discard the entire packet, while others may accept whichever version arrives first or last.

              Suspicious IP Options
              I also noticed that all three packets contained IP options, which are uncommon in typical traffic and can signal malicious activity. Specifically, the packets include type 131 IP options, which are often used to route packets through specific network paths. This could be an attempt to bypass firewalls, intrusion detection systems, or route traffic through an attacker-controlled device.

              Exercise 3 – Spotting Crafted Fragment Sets

              What makes you believe that the set of fragments in records 8–13 (IP ID 31026) have been crafted? Identify five abnormal traits.

              Upon analyzing these packets, it became clear that these fragments were likely intentionally crafted rather than the result of legitimate fragmentation. I identified several suspicious traits that support this conclusion:

              1. The second packet does not have a More Fragment flag which would indicate that this is the last packet of this fragment train when in fact there are more packets that are part of this train following this packet.
              2. The second to last packet does not have the same payload size a nd total length size as the fragments before him. All fragments should be the exact same size outside of the last fragment.
              3. The 4th and 5th fragments are overlapping (they have the same offset of 24).
              4. All the packets have payloads of size 8 and 16 bytes and total length of 28 and 36 bytes. There should be no MTU that small and causing fragmentation to occur.
              5. There is a fragment missing before the last fragment. We go from offset 24 to offset 48 while the payload size is only of 8 bytes. We should have a fragment with an offset 32 that is missing.

              Exercise 4 – Filtering for ICMP Echo Request Fragments

              In this exercise, I used a tcpdump filter to try and identify all fragments related to ICMP echo requests (type 8). The command provided was:

              Why don’t we see all the fragments associated with the echo requests ?

              Only fragments with an offset of 0 include the ICMP header (which contains the type field). Subsequent fragments—those with a non-zero offset—contain only payload data, not the protocol header. As a result, the filter doesn’t match those fragments, because the ICMP type field isn’t present in their portion of the packet.

              To capture all fragments of a given ICMP echo request, I would need to filter by IP ID (the identifier field) rather than by protocol fields. That’s because all fragments of a packet share the same IP ID, allowing me to track the complete set regardless of whether they include the ICMP header.

            7. IPv4

              Lab 1.4 – IPv4 Packet Analysis

              This lab focused on examining network traffic at the IPv4 layer, with an emphasis on identifying abnormal or suspicious behavior within the packet capture.

              Lab Setup

              For this exercise, I used the capture file called ipv4.pcap.

              Once downloaded, I opened the file in Wireshark and began my analysis.

              Exercise 1 – Analyzing the First IPv4 Packet

              a) What version of IP is the first packet?

              We can find this either by looking at the Ethernet header or the IP header. Looking at the IP Header, the IP version is located in the higher-order nibble of the 0 byte offset. We can see there that this is an IPv4 packet.

              b) What is the IP Time To Live value, in decimal, in this packet?

              To answer this, I examined the IPv4 header of the first packet in the ipv4.pcap file. I specifically looked at the Time To Live (TTL) field, which determines how many hops (routers) the packet can pass through before being discarded.

              The TTL field is located 8 bytes into the IP header, but Wireshark conveniently displays this value directly in the decoded packet details. In this case, the TTL value was 64, which is a common default for Linux-based systems.

              This value can also give clues about the operating system or network behavior based on how far the packet has traveled.

              c) What is the source IP address, in hexadecimal, in the first packet?

              To find the source IP address in hexadecimal, I examined the IPv4 header in the first packet of the ipv4.pcap capture. The source IP address is located between bytes 12 and 15 from the start of the IP header.

              Wireshark makes this easy by displaying both the decimal and hexadecimal representations. For the first packet, the source IP is 192.168.11.65 in decimal, which corresponds to 0xc0 0xa8 0x0b 0x41 in hexadecimal.

              d) What is the destination IP address, in hexadecimal, in the first packet?

              To find the destination IP address in hexadecimal, I examined the IPv4 header of the first packet in the ipv4.pcap file. According to the IP header structure, the destination IP is stored between bytes 16 and 19 from the start of the IP header.

              Wireshark clearly shows this value in both hexadecimal and decimal. In this case, the destination IP is 192.168.1.1, which corresponds to the hexadecimal representation 0xc0 0xa8 0x01 0x01.

              Exercise 2 – Identifying Abnormalities in the IPv4 Header

              In this exercise, I examined the second packet in the ipv4.pcap capture and identified two key problems with its IP header.

              Problem 1: Invalid IP Version
              The first issue is that the IP header lists version 8, which is not a valid or supported IP version. Only versions 4 and 6 are in use today. Because of this, Wireshark marks the packet in red and does not attempt to decode it further.

              Problem 2: Invalid Header Checksum
              After inspecting the raw packet bytes, I found another issue in bytes 10 and 11, which represent the IP header checksum. The value was 0x0000, which is invalid and indicates the packet may have been corrupted or crafted improperly.

              Impact
              Both of these abnormalities would cause the packet to be dropped immediately by the first router or system it attempts to pass through. This exercise helped me understand how malformed packets are detected and discarded at the network layer.

              Exercise 3 – Hex Analysis Using tcpdump

              In this part of the lab, I used the tcpdump command-line tool to inspect raw packet data and answer questions related to the third packet in the ipv4.pcap capture.

              To extract the first few packets in hexadecimal format, I ran:

              a) What version of IP is this packet? What is the header length if the packet ?

              By looking at the raw hexadecimal output of the third packet, I found it starts with the byte 0x45. This first byte breaks down into two nibbles:

              • 4 → IP version
              • 5 → header length

              So, the version number of this packet is IPv4, as indicated by the high-order nibble of the first byte.

              The header length field is in units of double word so it has to be multiplied by 4 to be converted to a length of 20 bytes.

              b) What is the embedded protocol in this packet, according to the IP header?

              To determine the embedded protocol, I examined byte offset 9 in the IP header of the third packet. This byte indicates which protocol is encapsulated within the IPv4 packet.

              Using the tcpdump output, I located the value at this offset. For this packet, the value was 0x01, which corresponds to ICMP (Internet Control Message Protocol).

              Exercise 4 – Calculating ICMP Header and Data Length

              In this task, I analyzed the fourth packet in the ipv4.pcap file to determine how many bytes were used by the ICMP header and data, following the IPv4 header.

              To do this, I used two values from the IP header:

              • Total Length: 68 bytes (it is found in the 3rd byte offset of the IP Header // it has a hexadecimal value of 0x44)
              • Header Length: 20 bytes (which is shown as a value of 5 in the header, multiplied by 4)

              By subtracting the IP header length from the total IP datagram size:
              68 - 20 = 48 bytes

              So, the ICMP header and data together occupy 48 bytes in this packet.

            8. 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.