A company's internal network is under serious attacks. The IDS at every Department are throwing various alerts of unknown network attacks. You are called to find out what's going on, explain what type of attacks are being conducted and how it may be possible to mitigate them.
The network engineers at each department installed a packet capturing device and presented you with the captured files.
We can tell from the first look at the peak of the file, without any in-depth analysis, that something is not right. We have many IP packets that are not carrying any content, and most of them don't belong to the network segment we sniffed the data from.
This suggests that someone is crafting those packets and sending them on the network to cause the switch to throw its cam table and work as a hub.
We can safely assume we are dealing with Mac flooding here.
Let's examine the protocol hierarchy in this PCAP file.
Everything may seem normal at first glance; however, we know from our study that internet disconnection on a network can be caused by an attacker conducting ARP poisoning attacks.
Let's filter out the traffic, display only the ARP packets and scroll down to view the ARP replies to verify that hypotheses.
Here is the first ARP reply which has the router's IP address.
The reply claims that the router's physical address is 00:50:56:eb:f7:91. Let's look at more replies.
Down there, something defiantly doesn't look right.
There is one device that keeps sending gracious ARP replies, telling that the default gateway MAC address is 00:0c:29:20:bc:14 (which is different from the one we saw earlier) even though no one sent a request about it.
This looks very much like poisoning attacks where the attacker keeps sending spoofed ARP replies, telling everyone that he or she is the default gateway.
The good thing about this is that the MAC address that is being populated by those ARP frames is supposed to be the MAC address of the attacker.
Let's filter the traffic looking for frames that holds that MAC address.
This is interesting; we can see the ARP answers we saw earlier in addition to an ACK segment coming from 192.168.153.154 which contains the suspect's MAC address we got earlier.
This attack may be stopped by implementing dynamic ARP inspection feature in the network.
The client's description mentioned that the web server is not functioning well. Most of the attacks that cause web servers to slow down or denial of service rely on sending too many requests.
To get an overview of the packets going to our web server let's use Wireshark filters to display packets that are destined to our web server on port 80.
ip.addr==192.168.153.154 and tcp.dstport==80
We can see that our server is receiving many (maybe too many) SYN segments on port 80. This may suggest that this is a SYN flooding attack.
One way to tell if those SYN request are coming from real users or not is to view the rest of the communication.
We can see that the supposed clients are terminating the connection right after sending the SYN.
Another way is to perform reverse DNS on those IP addresses. We can also ping those IP addresses and compare the TTL and the TCP window size values from their reply with the values we have on the request we received.
However, since this seems to be a blind DOS attack, it may be hard to determine the attacker's IP address based on the traffic alone.
This is an APIPA IP address which a client assigns to itself when it is unable to reach the DHCP within the network.
It seems that there is no need to filter out DHCP packets to verify whether the DHCP is active on that Network or not because the number of DHCP discover packets is enormous. See Statistics > DHCP (BOOTP) Statistics
We can see that DHCP offer messages are going on that Network.
This rules out the possibility of a problem in the connection between the clients and the DHCP and makes us believe that someone is performing a DHCP starvation attack.
Unfortunately, we may not be able to determine the source of the attack by analyzing the PCAP file alone. However, we can stop it by enabling DHCP messages rate limiting on the switch's port.
Since we have doubts, let's start with examining the protocol hierarchy of the file capture. See Statistics > Protocol Hierarchy
We can see that there are many seemingly normal protocols running. However, down on the bottom of the TCP application, alongside HTTP and HTTPS we notice that there is an unknown protocol running under the name Data.
The name or tag data suggests that Wireshark couldn't recognize the protocol used for the connection.
Let's filter the traffic looking for those packets by typing the word data in the filter box.
We are now left with a few ICMP messages and unknown TCP messages carrying data. The data section of the ICMP packet doesn't seem to be carrying anything interesting.
So, let's follow the stream of the other connection we found (the unknown protocol in the TCP)
From the output, we can see that someone has connected to the 192.168.153.154 machine on port 6666 to a remote shell, created a new user named Manager and added it to the Administrators group.