This chapter is from the book
This chapter is from the book
This chapter is from the book
Netbus Scan
In the next incident, we examine a scan to destination port 12345, which is typically associated with the netbus Trojan that affects Windows hosts. This particular scan was launched against a Class B subnet so that it set off all kinds of alarms. The network that was scanned had some high-numbered port access open through the packet-filtering devices.
The following records provide a very brief excerpt of the detected traffic. This scan attempted connections to more than 65,000 IPs in the target network. It is important to note that this traffic was collected on a sensor located behind (inside) the packet-filtering device. This is the traffic that actually got inside the network. Scans happen! In fact, they happen all the time on this particular network. It's not that this network is any more inviting than others; it is just a fact of life that scanning is inevitable and frequent. Knowing this, you cannot get too worked up when you see scans. However, this is inside the packet-filtering device making it more than a curiosity, as we will later see. Here are the records:
bigscan.net.1737 > 192.168.7.0.12345: S 2299794832:2299794832(0) win 32120 <mss
1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1739 > 192.168.7.2.12345: S 2299202490:2299202490(0) win 32120 <mss
1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1741 > 192.168.7.4.12345: S 2293163750:2293163750(0) win 32120 <mss
1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1743 > 192.168.7.6.12345: S 2298524651:2298524651(0) win 32120 <mss
1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1745 > 192.168.7.8.12345: S 2297131917:2297131917(0) win 32120 <mss
1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1747 > 192.168.7.10.12345: S 2291750743:2291750743(0) win 32120 <mss
1380,sackOK,timestamp 120377100[|tcp]> (DF) bigscan.net.1749 > 192.168.7.12.12345: S 2287868521:2287868521(0) win 32120 <mss
1380,sackOK,timestamp 120377100[|tcp]> (DF
We see the scanning host bigscan.net methodically moving through the 192.168.7 subnet with a unique scan search pattern of looking at the .0 address and even final octets thereafter.
Netbus Hijinks
Netbus is a tool that allows remote access and control of a Windows host. After a host is compromised, it behooves the attacker to have a means of future access to the host. Netbus is one of many backdoor Trojans that can be run to provide stealthy access. It predates another, more familiar backdoor Trojan, Back Orifice. Both Netbus and Back Orifice have user-friendly GUI interfaces to easily control the remote compromised host.
Not All That Runs on Port 12345 Is Malicious
The OfficeScan virus eradication package for the corporate enterprise listens on TCP port 12345 on the desktop host. The enterprise software accommodates central virus reporting, automatic update (apparently via port 12345 on the updated host), and remote management for ease of use to assist in monitoring and configuration.
If you ever see a host that listens on TCP port 12345, it is possible that it might be a helpful rather than harmful process. Given the range of possible listening ports 1 through 65535, I'd much prefer to see the white hats (good guys) select listening ports that don't share commonly used hacker ports.
Let's go for the jugular and see if there is any need to further investigate this scan. We want to examine the hosts in the internal network and see if they responded to the scan. The TCPdump filter to examine this would look for traffic from the internal network of 192.168 with a source port of 12345 and a TCP flag pair of SYN and ACK. This means that we have a listening host, which can be potentially very dangerous. Our filter could have used the IP number of the scanning host instead of or in conjunction with the internal subnet address.
The TCPdump command used to extract response records associated with the scan reads from the binary file of collected records for the site, and identifies this scan as one that involved the internal 192.168 subnet and port 12345. The TCPdump command is further refined by using a filter that looks at the 13th byte offset of the TCP header, where the TCP flag byte is located, and looks for the ACK flag and the SYN flag set simultaneously. Here is the TCPdump command and the output generated from it:
tcpdump -r tcpdumpfile 'net 192.168 and port 12345 and tcp[13] = 0x12' mynet.edu.12345 > bigscan.net.3698: S 2633608519:2633608519(0) ack 2346088305 win
49152 <mss 1380,nop,nop,timestamp 2662730[|tcp]> (DF)
The good news is that only one host responded. The bad news is that one host responded! When it was discovered that there was a responding host, this incident was escalated to the highest priority because we believed we had a host offering the netbus Trojan, a natural conclusion. The scan and subsequent discovery that there was a responding host occurred by 7:00 a.m., meaning that most of the staff had not yet arrived at work. In the interim, the network group was contacted and told to disallow any inbound or outbound traffic to or from the responding host by blocking it at the packet-filtering device. Also, the local computer incident response team was mobilized to scan the host for vulnerabilities and track down the owner.
After some superficial probing, the incident response team discovered that the host was a Silicon Graphics, Inc. (SGI) running an older version of Irix (SGI's version of UNIX). As a veteran of incident response teams, I remembered that older versions of Irix used to come configured with an account of lp (line printer) with no password. Tragically, a telnet connection to the host allowed me access to the host, using the lp account and no password. This discovery pretty much ruled out that this was a netbus problem because the responding host ran a version of UNIX, but we did have a rogue port answering and a host that had little, if any, security.
Concurrently, the search for the host's system administrators continued. Ownership records were dated and the host had been tossed from administrator to administrator as people moved in and out of the organization and assignments changed. This particular host had a rich history of neglect because the user-administrators were scientists or engineers who were never really trained in administration, let alone security. This is a common paradigm of neglect because many research departments do not have the budget to hire trained administrators. The users are usually overburdened workers who just need to keep the host running.
The system administrators of the SGI hosts finally arrived at work. As suspected, they had no idea what was listening on port 12345. It was also quite apparent that they and their users had little concern or appreciation for security. We told them it was necessary to disconnect the host from the network and begin backups for forensic purposes. An argument ensued when one of the users became indignant about needing to have the host up and accessible on the network. The leader of the incident response team politely told him that he had two options: first, to cooperate and willingly cede control, or second, to have the network connection unceremoniously severed by wire cutters. It seems the light bulb went on at that point, and they agreed to cooperate.
When we finally got access to the system, we wanted to make sure that the host was listening on port 12345. The process of making backups on this host was long and cumbersome, so we didn't want to make them do anything unnecessary. At the same time, we didn't want to ruin any forensic evidence by poking around too much. Only one command was attempted—the netstat –a command to make sure that port 12345 was running.
Can you see the flaw of executing the netstat command? In hindsight, it seems this was really not such a wise move. Had the netstat command reported that port 12345 was not listening, this would have been extremely suspicious and more indicative of a Trojaned or rootkit netstat program running on the host that was altered to not report that port 12345 was listening. But, this was not the case; port 12345 was listening.
System backups were started to preserve any forensic evidence in case some kind of prosecution ever had to be done. Finally, when the backups were completed, we had an opportunity to examine the system. We didn't want to disturb it in any way prior to the backups.
A very handy command in this situation is the fuser command. This is not available for all UNIX operating systems, but it is available on Irix and Linux:
[root@irix]# fuser 12345/tcp 12345/tcp: 490
The command was issued to find the process number associated with port 12345 on TCP. By looking at the netstat output, you don't know the process that is running the service on port 12345. The fuser command returns the process number of the software running on that port.
Next, you have to find what that particular process number is running. That can be done using the ps command and then examining the output for the process number, in this case 490:
[root@irix]# ps -ef | grep 490 root 490 483 0 Sep19 ? 00:02:17 /usr/local/bin/license_manager
You see that there is a license manager running. When this appeared on the console with the system administrator watching, he remarked that he had recently installed a license manager. He had no idea what port it listened on. The mystery was solved! This was the best possible resolution considering the alternatives. But, give me a break—what reputable license manager software maker would use a default listening port of 12345?
Before this host was allowed back on the network, it was cleaned up with the assistance of a savvy UNIX administrator. An initial vulnerability scan of the host produced about twenty pages of high- and medium-range security problems. It was scanned again after the changes and upgrades to make sure that no known vulnerabilities existed.
Other Commands to Display Programs Associated with Ports
The UNIX command lsof can be used, as well, to list information about files opened by processes. This comes with many UNIX operating systems, but can be downloaded and added if it is not available. To find the process ID associated with the service listening on port 901 using lsof, execute the following:
lsof -i TCP:901 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME inetd 387 root 9u IPv4 369 TCP *:swat (LISTEN)
You see that port 901 is associated with the inetd process. This is the Internet daemon that starts most of the listening services. Some additional information is displayed in the last column; port 901 is associated with Samba Web Administration Tool (swat). You should find this started in the file /etc/inetd.conf:
grep swat /etc/inetd.conf swat stream tcp nowait.400 root /usr/sbin/swat swat
A Windows tool known as fport (available with a tool search on http://www.securityfocus.com) can be used to associate processes with ports on which they run. Here is a sample output from running fport on a Windows 2000 host:
FPort v1.31 - TCP/IP Process to Port Mapper Copyright 2000 by Foundstone, Inc. http://www.foundstone.com Securing the dot com world Pid Process Port Proto Path 384 svchost -> 135 TCP C:\WINNT\system32\svchost.exe 8 System -> 445 TCP 496 MSTask -> 1025 TCP C:\WINNT\system32\MSTask.exe 8 System -> 1027 TCP 1692 SshClient -> 3705 TCP C:\Program Files\SSH Communications Security\SSH
Secure Shell\SshClient.exe 1892 OUTLOOK -> 4040 TCP C:\Program Files\Microsoft Office\Office\OUTLOOK.EXE 384 svchost -> 135 UDP C:\WINNT\system32\svchost.exe 8 System -> 445 UDP 220 services -> 1026 UDP C:\WINNT\system32\services.exe 916 iexplore -> 1341 UDP C:\Program Files\Internet Explorer\iexplore.exe 1892 OUTLOOK -> 4024 UDP C:\Program Files\Microsoft Office\Office\OUTLOOK.EXE
Although this turned out to be a non-incident in terms of intrusions, it does illustrate a very noteworthy point. It is extremely helpful to be able to do a quick assessment of potential reconnaissance or potential damage from scan activity of your network. Most NIDS report about scans, notifying you that they have occurred. But, the more relevant knowledge is this: did any host respond to the scans? That is where TCPdump recorded activity is once again invaluable.