Network troubleshooting finds a hacker behind the scenes

Commercial password theft is pervasive! Recently, I helped my friends with lan troubleshooting, but no one thought of a commercial hacker. For the sake of identification, the author will restore this extraordinary network troubleshooting process.

A friend is responsible for the company's HR and finance, and is also responsible for IT management. This is a well-known architectural design company in China. The company's network scale is small. 152 hosts are divided into five subnets, each of which is connected to a vswitch by the HUB. In addition to an online video system, a file server is deployed separately as a subnet to facilitate data sharing and exchange, the company's external Internet demand is not very big, connect to the Internet through the router. (Figure 1)

　　

One day, the network of the unit suddenly experienced a serious blockage. The data between hosts was frequently interrupted and the collaborative Office could not work normally, and the online video system often fell offline. In addition, both uploading and downloading files from the file server are exceptionally slow and sometimes interrupted due to timeout. The host can connect to the Internet, but the network speed is slow. It takes a long time to open a webpage. Network faults are so embarrassing that a friend is not a full-time IT administrator and cannot help me at the moment.

First, I use the ping command on a host to test the connectivity of the Gateway. Enter the command "ping 192.168.2.1-n 1000" to send 1000 Ping packets to test the gateway. The test results show that the gateway can be pinged, but the packet loss is very serious. 1000 of the 720 packets are lost, the packet loss rate is 72%, and the packet loss lasts for a long time. Run the arp-a command to find that the gateway IP address and the gateway MAC address point correctly. Through the above test, the network settings errors and ARP spoofing are basically ruled out.

For ease of analysis, I decided to use Sniffer in the LAN for packet capture analysis. Therefore, the image on the core switch uses Sniffer to monitor the entire intranet (five subnets. First, go to the "dashboard" and find that the network utilization rate reaches 97%, which is abnormal. The author judges that the network size and daily service network utilization of this unit should be between 20% and 30%, and there should be a large network surplus. In this way, we can conclude that the root cause of packet loss is that abnormal traffic occupies a large amount of network bandwidth. Where are these abnormal traffic sources? (Figure 2)

　　

Switching to matrix, we found that hosts with MAC 57.87%-06-e6-98-84-b7 account for of the total network traffic. Initially, the target is locked on the host, and then switched to "hosttable" (host list) for further analysis. From this version, no large number of broadcast packets are found, therefore, the impact of broadcast storms is completely ruled out. Find 00-0A-E6-98-84-B7 and analyze the host. It is found that the network activity of the host is very suspicious, and only 700 packets are sent to the host, the outgoing packets have hundreds of thousands of packets in just over 10 minutes. This is extremely abnormal. What is the host doing? (Figure 3)

　　

In order to confirm the network activity of the 00-0A-E6-98-84-B7 host, I analyze the packet capture on the switch. After data packets are decoded, the host copies data to a host with an IP address of 60.164.82.185 over the UDP protocol. Why is this IP address so familiar? Isn't it a local IP address? In addition, it is also found that the host is frequently connected to the file server. Based on the network segment and MAC address, the host is isolated by disconnecting the network on the switch, and the entire network is immediately restored to normal and packet loss troubleshooting.

At this point, we found the cause of the packet loss through layer-by-layer troubleshooting. What causes a large volume of data on the host to be copied? The author restored the network connection of the host. After detection and analysis, it was found that the host was planted with Trojans by hackers, and then remotely controlled to copy files to the remote host through port 8888. In addition, the host is downloading a large number of files from the file server. It is estimated that attackers are using this host to steal information from the folder server. The host was originally installed with anti-virus software but was not reported as a virus. It should have been handled by an attacker. Manually clear the trojan and connect the host to the network without packet loss.

The host may recall using a USB flash drive trojan because a customer had asked him to copy the project plan to his USB flash drive before leaving work yesterday. Shortly after work on the next day, the company's network experienced serious congestion. It must have been that the use of the USB flash drive was in progress. Afterwards, the company queried the records of the IP address through the Telecommunications Department. That's right. On that day, another local architectural design company connected to the Internet through the IP address. Therefore, the company identified the network fault as a commercial theft event.

Conclusion: It is indeed unexpected and deeply thought-provoking to find a hacker in network troubleshooting. Network security is always broken through the weakest link, and terminals are the last line of defense for network security.