A tremendous amount of traffic passes through a network. For the most part most this traffic is expected, but what if it is not? How can we identify abnormalities? The topic for this article is how to identify that a network scan has occurred, specifically TCP Scan.
There are a wide variety of scans that can occur. The trick to identifying types of scans is pattern recognition. If I suspect a scan, there are steps I can take in Wireshark to confirm my suspicions.
Before we go hunting for a TCP scan, let's first take a look at how a TCP scan works. Take a look at the picture below.
Here we have a scan occurring from the left machine to the right machine. This scenario sees a successful scan of an OPEN port.
1. SYN + 80 (packet) sent to target
2. port 80 is open and a SYN,ACK(packet) is sent to first machine
2. first machine sends another packet with ACK flag set. (effectively completing the 3 way handshake)
4. Having successfully connected first machine closes connection with an additional packet with RST,ACK flags set.
5. Rinse and repeat through all specified ports on target machine
The TCP Scan is unique in that is actually completes the 3 way handshake. The pattern we see in the picture above is what we look for in Wireshark.
Identify Scanning Machine
There are a few ways to do this, I tend to start with two methods.
1. Drive By: With no filters I quickly scroll through all the packets too see if anything jumps out at me.
- Things to look for would be large groupings of ARP packets. Large groupings of RST ACK packets. Also it can be useful to filter on ARP packets. Filtering on ARP shows you all the ARPS and can be a method for differentiating if a scan has a lower timing interval. (T1....T5)
2. Statistics>Endpoints.
I like to look at Endpoints in a capture. With this functionality you can quickly see which hosts on the network are generating the most traffic(packets)
Scanning Machine Found
In the picture above we see a grouping of ARP packets. Two important things are learned in this picture. First the destination host addresses are going up sequentially, a good sign that a scan is occurring. Also the "Tell 192.168.1.73" is telling us that 1.73 wants to know who each of these hosts are. A very VERY good sign that 1.73 is the scanning machine.
Navigating to Statistics>Endpoints confirms this for us.
We can see in this image that a ton of packets are involving 1.73!
With our Capture in hand, I want to dig deeper to see what is happening with 1.73
I start with the filter:
ip.src==192.168.1.73
Which will show me all the source packets created by the specified IP. Right away we can see a lot of SYN packets from 1.73 that are targeting other hosts on the network.
I do a drive-by on this filter till something jumps out. I want to see ACK packets.
Only a few packets down the filter I am presented with an ACK packet followed by 2 RST,ACK.
The pattern closely resembles a TCP Connect Scan, but I am missing the SYN,ACK coming from 1.69.
The above filter looks for any packet (source or destination) involving 1.73 and 1.69 with the addition of the packet must have port 554.
It works perfectly, because we are presented with 7 packets that show the relationship between 1.73 and 1.69!
Let's take a look at the sequence here.
- SYN from 1.73 to 1.69 on port 554
- SYN, ACK from 1.69 to 1.73 on original port 59570
-ACK from 1.73 to 1.69 on port 554 (The three way handshake is complete)
-RST,ACK from 1.73 to 1.69 on port 554 (abruptly closing the connection)
This pattern perfectly matches what we know a TCP Connect scan to look like!
While I have isolated a single open port conversation, if we modify our filter we can see that this pattern repeats its self over and over. Further confirming that a TCP Connect Scan occurred on the network.
If you enjoyed this article I have actually documented it all in a video on YouTube as well. All likes and subs are greatly appreciated! Thanks!
