2005-07-11
Article continued from Page 2
The port that your local hosts are scanning for is significant as well. A machine scanning out to the Internet on port 445 (Windows CIFS) or 6667 (IRC) should raise a red flag and cause you to investigate it as if it were compromised. Port 445, SMB CIFS, is a common port being scanned for on the Internet due to the number of vulnerabilities associated with it. IRC is typically used as a communications mechanim for compromised machines, more commonly known as botnets. However, a machine scanning out on ports 6881 (BitTorrent) or 6346 (GNUTella) would be an indication that the host is running a P2P networking application, which commonly scans the Internet looking for other P2P enabled hosts. The policy within your organization should dictate if this is acceptable behavior or not.
The busiest host pairs table is the final report. It lists which hosts had the largest single transfers between them. It's a good idea to take a look at this list and make certain that the transfers seem normal or not. Normal behavior would be someone downloading a Linux ISO image, whereas less normal behavior could be someone downloading pirated media from an already compromised host.
Going back to the main IPAudit page, you will notice even more reports that you can run. The client/server report can be useful for monitoring who is running the following services on your network:
- HTTP Servers
- Mail Servers
- SSH Servers
- Telnet Servers
- HTTPS Servers
I typically check these reports on a weekly basis to get an idea of who is running what server services on the network. A red flag could be a user workstation that ends up in the top ten SMTP servers listing. This could indicate that the host has been infected and is being used to distribute SPAM. The listing of HTTP servers is useful to see not only who may be running legitimate web servers on your network, but it can also be an indication of anyone tunneling other protocols with HTTP and running it over port 80 or 443 TCP. Since IPAudit only looks at IP and transport layer information, it will not distinguish between actual HTTP traffic and tunneled traffic (which can actually be good in this case).
The traffic type, weekly, and monthly reports all contain summary information about your network. They should be checked weekly to get an overview of what networking protocols are in use, and which hosts transmit and receive the most data. Host reports contain much of the same information as the weekly and monthly reports, except on a per host basis.
The log searching feature is an excellent way to find certain traffic types using multiple criteria, as shown below in Figure 7.
Figure 7. Searching IPAudit's logs.
You can adjust your query to a specific time period, right down to the minute. The IP address can either be a host on the local network or the external network/Internet. The local port is relative to the local address space you specified in the IPAudit-Web configuration file, as is the remote port. The next two fields, Max Lines Displayed and Print Increment tell IPAudit how to print out the query. It is best to start with a low number for the line displayed the first time you run a query, just in case there are thousands of results which could take some time. The session size is a particularly useful field when trying to determine traffic type. Sometimes you want to distinguish between actual data transfers and just portscanning. By playing around with the values in these fields you can do just that (for example, suppose you want to know who actually connected to the MySQL server, not who scanned it). The protocol drop down menu allows you to choose between TCP, UDP, and ICMP. IPAudit tries to keep track of state by indicating whom the first talker was in the connection.
Overall, IPAudit has many useful features and many ways in which to look at your network traffic. The next section will go into more detail on how to use it to detect compromise machines on your network.
Detecting compromised hosts
Similar to an IDS, IPAudit is a historical account of your network traffic. If an exploit comes flying into your network and is picked up by your IDS, it happily logs it. When you go to check the logs you can see this event, including the full packet, and you may say, "Yup, that was an exploit alright, I wonder if it was successful?" IPAudit works in much the same way, except you can use it to detect all behavior exhibited by the potential compromised host after the exploit was launched. Here is an example:
snort: [1:2123:3] ATTACK-RESPONSES Microsoft cmd.exe banner [Classification: Successful Administrator Privilege Gain] [Priority: 1]: {TCP} 192.168.1.223:31337 -> 192.168.1.45:32768
The above Snort alerts indicate that 192.168.1.237 is trying to exploit 192.168.1.223 using a very common exploit that takes advantage of the MS03-026 RPC vulnerability (See the full Snort rule documentation). We then see a very obvious backdoor attempt, most likely a simple Netcat command such as "nc.exe -l -p31337 -e cmd.exe".
Using IPAudit, let's examine the victim host's traffic. I would first go to the IPAudit searchable host feature, enter the timeframe I want to look at, then the IP address. It produces a report as shown in Figure 8.
Figure 8. Search results for a certain timeframe and IP address.
The above data indicated that the host is portscanning for port 445. First, we see that the same source port is used to connect to multiple different destination hosts. In normal TCP communications, a different source port would be used when connecting to a different host. Second, we see many attempts to port 445 on a class B network, with little data being transferred. Also, if we look at the column labeled "First Talker" it indicates that the host on the local network initiated the connection. The "Last Talker" column is blank, telling us that 192.168.1.223 sent out the packets, but received no responses. These are all telltale signs of portscanning.
What if you want to see what happened in addition to the portscanning? If someone did in fact compromise this host then they most likely uploaded some sort of rootkit or IRC bot. Let's take the IP address of the machine that opened the backdoor on our victim host and see what other machines it connected to that day, as shown in Figure 9.
Figure 9. Search showing potentially compromised IP connecting to other machines.
Here we see it connecting to our known victim host and transferring data on port 4000, among others.
After further analysis we see a similar transfer to another host on our network, 192.168.111.69, as shown in Figure 10.
Figure 10. Similar traffic shown with another machine.
The backdoor port is different, but the host is in fact compromised in the same way as 192.168.1.223. This can be verified in the IDS logs:
Using IPAudit we can then continue to map the scope of the compromise. This includes all machines that have become compromised, which servers attacked them, which servers are controlling them via backdoors, and which IRC servers they logged into. We do this by modifying our search criteria to map connections between all hosts involved.
The incident described above was based on a real incident, but was also recreated in a lab. The real incident involved a dozen compromised computers, two IRC servers, an attacking host, and a remote shell host. It was all mapped using IPAudit and correlated with Snort.
