TCP and HTTP packets decoding using Wireshark

November 10, 2023 0 Comments

In this lab, I am going to analyse the following pcap file:

I am going to start doing some passive fingerprinting of the two systems communicating in this pcap file. Looking at the IP header, I can see that the TTL for the first system is 49 which makes me believe that this system is a Linux system that is 16 hops away from the network I am sniffing. The second system has a TTL of 64 so this system is probably also a Linux system sitting on the local network that I am sniffing. So I have identified a local system and another system that is out on the internet.

If I look at the first 5 packets, I can see two systems going through the TCP handshake to establish a communication channel. Once the TCP handshake is done, the first system (with MAC address 00:50:8b:ea:20:ab and IP address 148.78.247.10) sends an HTTP get request to the second system (with MAC address 00:b0:d0:20:7d:e3 and IP address 12.33.247.4) that then sends an ACK packet that acknowledges receiving the request.

If I use the “follow TCP stream option” I can look at this Get Request header and I notice three interesting details:

  1. the referer field indicates a value of 12.33.247.4 which is the IP adress of our second system sitting on our local network that our first system is trying to reach. Normally, the referer field identifies the address of the web page  from which the resource has been requested. But here it’s got the IP Address of the system it is trying to talk to. The Referer field should not be used when I navigate around on the same website. If I click one page and then click on another page, there’s no referer field that will end up getting encoded in because I did not come from an outside third party. So this referer field is bogus that should not be happening.
  2. the X-Forwarded-For field is telling me that the source IP Address that I am seeing is not the source IP Address that is running the web client or whatever software is connecting to this server. Their IP Addresses is 148.62.64.147.168 and they are relaying through the IP Address of system 1. They are bouncing through a proxy to get to the local network that I am sniffing on. Now, maybe it’s legitimate. I might want to do some lookups on that IP address space and see if both of those are part of the same organization. In which case, this may be perfectly legitimate. But anytime I see people bouncing through things to get to me and they are generating suspicious traffic patterns, I always get a little bit nervous because it may look like they are trying to hide their tracks.
  3. Someone external to our environment is trying to access a file named “startstop.html” which is located in the Administrator Directory. It does not sound like a web page. In most organizations, a directory named “Administrator” should of course only be accessed by admins and not by external systems.

So at this point of the analysis my best guess is that if I do some lookups on that, I am probably going to find out that it is associated with some form of an attack meaning that someone is coming to our website and they are looking to see if I run this page that is known to be vulnerable?

Now what the server returned was a “404 not found” which indicates that this server is not vulnerable to this attack.

After the deeper analysis of these first 5 packets, I know a system came in from the Internet bouncing through a proxy to talk to a web server. I know that it sent a get request that looks highly suspicious. It probably was not a regular web browser because the data fields don’t Jive with what a web browser would encode the referer field. There should be no referer.

Looking at packets 6 and 7, things get even more interesting. There is a third and new Mac address (00:50:ba:8f:e0:0c) that jumps into the session, sends a RST, ACK packet to both sides of the connection and then disappears and goes away.

This third Mac address has to be generating traffic on the local network where we are sniffing because if it was any place else I would not be seeing a TTL of 255 (which the starting TTL for most network gears). It would have to be something lower.

Why did this happen ? Why were those resets issued ? What did that ?

Looking at the IP ids, it confirms what I suspected that it did not come from either endpoints because the IP ids do not sync with what the endpoints were doing just prior or even just after:

We have the same IP ids for both packet 6 and 7 (0xb0f2) while system 1 (the one out on the internet) ids were being incremented (0x2a6b for the first packet then we are missing some IP ids and then packet 3 and 4 ids are incremented by one (0x2a95 and 0x2a96). This system is definitely using sequential ids and therefore there is no reason for this to go from 0x2a96 to 0xb0f2. The same thing can be observed with the local system. It is also using sequential ids going from 3743 on the 5th packets to 3744, 3745, 3746 etc… on the packets following the 6th packet and 7th packet.

Whatever this third device device is, it used the same IP ids talking to both systems. That is not a normal communication thing to do.

At this point, my hypothesis is that this device with the third Mac address is something sitting on the local network watching traffic going by and when it sees a known attack pattern it then tries to intervene by killing the sessions thus defeating the attack from being able to take place. My best guess is that this third device is a network based intrusion prevention system. This system probably has a signature that says: “if you see administrator/startsstop.html kill that session from taking place”.

It jumped in and it tried to reset the session. It worked from the perspective of the system out on the Internet as we do not see this system after the IPS intervened. It didn’t work when it sent the RST ACK to the web server because the web server kept trying to respond after that (packets 8 to 17):

Why did our internal system continue to try to communicate after that event took place. I know the IPS used the same IP ids. Did it try and reuse any other pieces of information. I am going to take a look at Wireshark “statistics” option and select “Flow Graph”:

I then select “TCP flow”:

The transmission highlighted in blue has an issue with its sequence and acknowledgment number. The last ACK packet that was sent from the local web server to the non local system had a sequence number of 1 and an acknowledgment number of 222 therefore I expect this highlighted packet to have a sequence number of 223 and an acknowledgment number of 1 but instead I see a sequence number of 1 and an acknowledgment number of 222! This is wrong and does not respect normal TCP number and acknowledgment number incrementation.

So what happened? My best guess is that the IPS created the packet that needed to go to the client to reset the connection and stop this attack and then it swapped the IP addresses, swapped the port numbers and printed that same packet out on the wire and sent it to the server. Because the sequence numbers were incorrect, the server looked at that and said: “These are out of bounds. This is not the sequence number I expected. I expected to see one from you next, and you didn’t send me that.” The network-based intrusion prevention system reset the client but did not reset the server. This could actually be a problem because how long is that server going to continue to do that for ? It could do this for quite some time because this connection was in an established state. As far as that server is concerned, it is going to keep trying to reconnect again because it did not see a valid RST or FIN ACK packet coming from the client yet. So it is going to try its best to recover that session and depending upon the OS, this might go on for minutes, hours, days.

Leave a Reply

Your email address will not be published. Required fields are marked *