In this case study, we dive into how to troubleshoot ARP spoofing attack that caused severe network congestion and intermittent connectivity within a large power company’s network. Discover how network analysis tools helped diagnose the issue and restore stable communication across VLANs.
What is an ARP Spoofing Attack?
Fault location: A power company.
Fault phenomenon: The network is severely congested, and Internet access by internal hosts and even communication between internal hosts are intermittent.
A detailed description of the fault: The network suddenly experienced communication interruption. Some VLANs could not access the Internet, and access to other VLANs was also interrupted. A ping packet test was performed in the computer room. It was found that the ping packet response time from the central switch to the host in the VLAN was long, and intermittent packet loss occurred. The packet loss between VLANs was even more serious.
Steps to Troubleshoot ARP Spoofing Attack
Preliminary Analysis to Troubleshoot ARP Spoofing Attack
The initial judgment is that the cause of the problem may be:
Switch ARP table update problem.
Broadcast or routing loop failure.
Human or virus attack.
Further information needed:
Network topology and normal working conditions.
Switch ARP table information and switch load status.
The original data packet is transmitted in the network.
Specific Analysis to Troubleshoot ARP Spoofing Attack
First, we learned from the network administrator that there are about 450 hosts in the network, and also obtained a simple topology diagram of the network, as shown in Figure 1.
As shown in Figure 1, the network is divided into 6 VLANs, namely 10.230.201.0/24, 10.230.202.0/24, 10.230.203.0/24, 10.230.204.0/24, 10.230.205.0/24, and 10.230.206.0/24. VLANs 201 to 205 are used for a department respectively, and VLAN 206 is a dedicated network segment for servers. Each VLAN is connected to the central switch (Passport 8010) at the same time, and the central switch is connected to the firewall, which is connected to the Internet and provincial units.
After getting a general understanding of the network topology, we logged into the central switch in HyperTerminal mode and found that the switch was under heavy load. We immediately cleared the switch ARP table and restarted it, but the fault still existed. So we decided to capture packets on the network for analysis.
Configure port mirroring on the central switch (Passport 8010) (specific configuration information is omitted), and connect the laptop installed with the Colai network analysis system to the mirroring port of the central switch. After installation, the network topology diagram is shown in Figure 2.
Since the Cole Network Analysis System can capture and analyze data across VLANs, the network topology did not change after the laptop with the Cole Network Analysis System installed was connected to the central switch.
Open the Colai network analysis system on the laptop, capture data packets for about 1 minute (after stopping the capture, it was found that the exact time was 53 seconds), then stop capturing and analyze the captured data communications.
By locating the node browser to the local network segment under the physical endpoint, we found a host with a MAC address of 00:00:E8:40:44:99, which has a total of 40 IP addresses, as shown in Figure 3.
We know that under normal circumstances, if there are multiple IP addresses under one MAC address, there can only be one of the following situations: gateway, proxy server, and manual binding of multiple IP addresses. After consulting the network administrator, we learned that the machines in this network segment are only bound to one MAC address, and there is no proxy server. At the same time, this MAC is not a gateway MAC address. Therefore, we suspect that the host may be subject to a spoofing attack.
Right-click the 00:00:E8:40:44:99 node in Figure 3, select the "Locate Browser Node (L)" command in the pop-up menu, and locate the node browser to 00:00:E8:40:44:99. Check the protocol view and find that the node actively initiated 22613 ARP reply packets, while there were only 2 ARP request packets, as shown in Figure 4.
From the data packet in Figure 4, we can know that 00:00:E8:40:44:99 actively sends ARP reply packets to other hosts in the network, telling the other hosts that it is a host with a certain IP, and this IP is constantly changing. Therefore, it can be concluded that the machine with MAC address 00:00:E8:40:44:99 is performing ARP spoofing.
At the same time, the corresponding prompt information is also given in the ARP diagnosis event area of the diagnosis view, as shown in Figure 5.
After the above analysis, we determined that there was an ARP spoofing attack at 00:00:E8:40:44:99. The network administrator immediately began to search for the host. Since they had previously made a statistical table of IP and MAC addresses, they found the machine easily. After unplugging the network cable of the host on the Layer 2 switch, the network quickly returned to normal, and the speed of internal access and external access (including Internet and provincial network units) between VLANs returned to normal.
In addition, as shown in Figure 3, the traffic occupied by the three machines 00:02:B0:BC:68:D2, 00:0B:DB:4B:46:81, and 00:11:25:8D:7D:C1 is relatively large. After checking the specific traffic of these machines, it is found that 00:02:B0:BC:68:D2 and 00:0B:DB:4B:46:81 are copying data with each other, and the IP address corresponding to 00:11:25:8D:7D:C1 is 10.230.204.1, which is the gateway of the 10.230.204.0/24 network segment. It is normal to occupy a relatively large amount of traffic. Therefore, it is basically determined that the source of the intermittent network is the 00:00:E8:40:44:99 host found earlier.
After finding the fault point and helping the network return to normal, we left the scene because of other things and did not investigate the specific situation of 00:00:E8:40:44:99.
In the afternoon, I received a call from the network administrator of the Electricity Bureau, who informed me that when they found the host with MAC address 00:00:E8:40:44:99, the user was only using WORD to edit documents and did not attack manually. Then I installed antivirus software and checked the host, and found several viruses. After the virus was checked, the host was connected to the network again, and the network communication was still normal. It was concluded that the cause of the network failure was that the host with MAC address 00:00:E8:40:44:99 was infected with a worm virus, which automatically carried out ARP spoofing attacks, resulting in intermittent network access.
Conclusion
In medium and large networks, it can be complex and challenging to troubleshoot ARP spoofing attacks, along with other network faults, without the assistance of professional network analysis tools. For instance, in this scenario, if data packets are not captured, even examining the traffic on the switch may not reveal the fault point easily, as the traffic associated with 00:00:E8:40:44:99 is not particularly large.
While you troubleshoot ARP spoofing attack issues, it’s important to note that with a data packet capture time of only 53 seconds, some hosts in the network might remain undetected (these hosts are not currently active and will not send or receive corresponding data packets, hence they cannot be identified). Therefore, for efficient enterprise network operations, network managers should employ dedicated network analysis tools to conduct long-term and effective monitoring and analysis. This approach will help eliminate potential network failures and security threats to the greatest extent.