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.