Investigating an Attempted Intrusion

by OptikNerve

This information was provided and written by OptikNerve. This text file is for a server administrator to be able to determine whether or not there is an attempted break-in or intruder, and what the appropriate steps are.

Conducting the Investigation

Appropriate policies should be put in place to cover privacy issues and security incident handling before beginning an investigation. If you are intending to prosecute, or press charges against the intruder, then steps must be taken to protect the evidence that you have collected.

When activity occurs that you think could be intruders, there are 4 steps you can take to see if this is an attempted break-in or not:

Log additional traffic between the source and the destination.

Log all traffic from the source.

Identify the system(s).

Log all the contents of packets form the source.

Following all four of the previous steps, you should make a determination as to wheather this is a attempted break-in or not.

Step 1: Identifing the System(s)

The first step that you would need to take to identify an attempted break-in would be to identify the the system(s) that the user(s) are using. With RealSecure, this could be as easy as just resolving the user's IP address and converting it into a hostname. If you configured the RealSecure console to use DNS, then click on the resolve host name button that is on the display screen. In rare occasions the host name cannot be found. If the DNS look-up fails, then try converting the IP address into a host name other ways (nslookup, dnsquery etc..).

You can use ARIN (www.arin.net) to convert IP addresses into host names, and NetSol (www.networksolutions.com) to lookup the address owner's contact/technical information.

If you cannot retrieve the user's information, it doesn't mean that he or she is attempted or has broken into your system. Successful identification of the host name or IP address doesn't prove that the activity is not an attempted break-in.

The source of this suspicious attack or traffic, may not be the best source of an attempted break-in. Denial of Service attacks (or DoS) attempts usually have spoofed addresses and unauthorized access attempts or probes may come from another system the user has already penatrated (someways like a Proxy).

Step 2: Traffic between source and destination

Seeing an event such as an IP violation or an overflow attack, might not provide the complete evidence of traffic between the destination and the source. It's also important to understand the context of the activity. A good example of this would be the Sendmail WIZ signature. RealSecure has an event that will identify an attempt to exploit the WIZ command in Sendmail. This event identifies any instance of WIZ in a mail message. If the WIZ occurs in the body of the e-mail/message, then it is clearly not an attempted intrusion.

Using RealSecure, a connection event is added to the policy for all traffic between the source and the "suspicious activity" and the destination (see table 01).

These logs will first give you an idea of what traffic is occuring between the source and destination. If the WIZ packet is the only traffic between the two systems, this tells you that it was most likely an attempted break-in. If you find a lot of SMPT/mail traffic between the two systems, you're most likely looking at normal mail traffic.

Step3: Logging traffic from the source

Assuming that the data collected in Step 2 was really unable to determine if the attempted break-in or attack was legitimate or not, you should begin collecting traffic from the source. The data collected might be somewhat limited, but that is expected. If the "attack" is comming from a remote network, you will only be able to view the traffic comming to your system. If the attack is local, you should be able to collect all traffic from the machine and be able to get a better view point on what is really happening or going on. To begin to collect all the traffic from the source, add your connection event (see table 02), to your RealSecure policy.

The connection event is likely to produce information that isn't at any value to the investigation that you are conducting. If you can view the traffic objectively, then this log will be of use to you to give you a good picture of the interactions that sre going on between the source and your system. You must look at the types and the ammount of each type of traffic without the preconception of an attack. Try to understand the traffic or activity that you are seeing. Is it mail traffic? Is it ping traffic? Is it web traffic? Does the traffic probe or come from the suspicious intruder on your system?

Hopefully at this point in time, you have collected the following information:

The name of the source system.

The type and frequency of traffic exchanged between or from the source and your system.

The type and frequency of traffic exchanged between or from the source and destination.

This information will give you a good idea as to the nature of this attack or attempt, but once again, this may not be enough information to prove that this is, or is not an attempted attack.

Step 4: Log packets from the source

The last thing you need to do is to log the contents of packets from the source. To be able to do this, modify your RealSecure policy as shown in table 03 above.

Logging the data raw and viewing their session, you can gather a completed record of the contents of the packets. Using ViewSession allows you to view the contents of packets without waiting for the database to be uploaded to the console. Logging the data raw allows you to create a permanent record.

There should be 2 connection events in the policy, one for every direction of traffic. This allows you to capture both ends of the connection. Try to limit the traffic capture to just one single port for each pair(s) of connection events, thus, letting you view the imformation more easily. If there are multiple targeted ports, then just add additional connection events.

After you have captured the data, trye and exime it. The information you just collected combined with all the other information and logs, should provide the answer to: Does the information that you have collected indicate that an attack is or was being made? If for some reason, you still cannot answer that question, do your best to find someone with past or present knowledge of protocol under investigation.

Examples

The examples that you are about to see will illustrate how these steps have been used in past (real) investigations. The IP and host names have been changed for privacy reasons.

Table 04: Medium-risk event: While installing RealSecure, this information became avialible when suspicious activity occured.

Event Risk Level Source Add Source Port Dest Address Dest Port Proto Info
IP Protocol Violation Medium 10.10.2.20 80 192.102.2.1 1009 TCP Flags=21

Table 05: RealSecure connection events example: Four policies were added to the log between the source & destination.

Event Action Source IP Destination IP Protocol Source Port Destination Port
SUS_TCP Notify, Log 10.10.2.20 192.102.2.1 TCP ANY ANY
SUS_TCP Notify, Log 192.102.2.1 10.10.2.20 TCP ANY ANY
SUS_UDP Notify, Log 10.10.2.20 192.102.2.1 UPD ANY ANY
SUS_UDP Notify, Log 192.102.2.1 10.10.2.20 UDP ANY ANY

Table 06: High-risk event: While installing RealSecure, this information became avialible when suspicious activity occured.

Event Risk Level Source Add Source Post Dest Address Dest Port Protocol
Qmail Buffer Overflow High 172.39.2.1 123 192.102.3.1 25 TCP

Example 1: IP protocol violation

An IP protocol violation is when a packet that has a strange combination of TCP flags, and thats how RealSecure will trigger the event; so then we began our investigation. See table 04 for more details.

From the information that is provided, you can see that the source port implies the Web traffic, and that the source of the undefined traffic is a Web server (or httpd). The problem is that a new network reconnaisssance technique is to use the packets with multiple flags to identify the Operating System of the systems that are on the network.

Step 1

Next we began to try and find out the host name for the source, in which it was a host in Germany:

someone.somewhere.gr
Then, the destination was resolved as a client system:
name.our.url.org

The host name of the source didn't immediatly imply that it was a Web server (or httpd). Since there was no evidence that this was badly formatted Web traffic, we continued the investigation.

Step 2

To identify traffic that is passing between the source and destination, we added four rules to RealSecure (see table 05). We then decided to capture the UDP and TCP traffic between the two systems. If it were true, reconnaissance probe, we figured we'd only see misconfigured packets, but instead the results showed much more. They showed the Web traffic between 2 systems, so clearly, the origional destination was a Web server being accessed by a client browser. At this point, we were determined that we had sufficient evidance to indentify the event as a misconfigured server or a protocol stack producing badly formatted packets. Thus, meaning that steps 3 and 4 were totally unecassary.

Example 2: Qmail Buffer Overflow

We recieved this High-Risk event that was defined or indicated as a Qmail Buffer Overflow. See table 06 for a diagraph.

From the information that was gathered, you can see that the destination port is the SMPT or mail port. This implies that there is an attack against your mail server or mail daemon. Since the system wasn't running Qmail at the time, so we decided to look into this attack a little further.

Step 1

We then attempted to resolve the host names that were involved. The source would resolve and of course we already knew the destination's was the system's firewall. We then went to ARIN and Network Solutions told us that the source was a client system on an ISP (Internet Service Provider). We then of course continued the investigation.

Step 2

We identified the traffic passing from the source and destination by adding our policies that are shown in table 07. The only traffic that was logged, was mail traffic. We began to believe that this was just "normal" or legit mail traffic except with exceptionally long lines of data. We still didn't have any proof that was worth the while, so we had to continue the investigation.

Step 3

We then decided to modify the rules to collect all the traffic from the suspicious source to our network or system (see table 08).

The change we made provided nothing we didn't know already, or nothing useful. The source of the suspicious activity was only making connections to the out-going mail port or firewall on port 25.

Table 07: RealSecure connection events example: Four rules were added to the log activity between the source and destination.

Event Name Action Source IP Dest IP Protocol Source Port Destination Port
SUS_TCP Notify, Log 172.39.2.1 192.102.3.1 TCP ANY ANY
SUS_TCP Notify, Log 192.102.3.1 172.39.2.1 TCP ANY ANY
SUS_UDP Notify, Log 172.39.2.1 192.102.3.1 UDP ANY ANY
SUS_UDP Notify, Log 192.102.3.1 172.39.2.1 UDP ANY ANY

Table 08: RealSecure connection events example: These events were added to log all activity from the source

Event Name Action Source IP Dest IP Protocol Source Port Destination Port
SUS_TCP Notify, Log 172.39.2.1 ANY TCP ANY ANY
SUS_UDP Notify, Log 172.39.2.1 ANY UDP ANY ANY

Table 09: RealSecure connection events example: This change was made last to gather packet contents, which makes the final decision

Event Name Action Source IP Dest IP Protocol Source Port Destination Port
SUS_TCP Notify, Log, Log Raw, View Session 172.39.2.1 192.102.3.1 TCP ANY 25
SUS_TCP Notify, Log, Log Raw, View Session 192.102.3.1 TCP 25 ANY

Step 4

In order to make the final decision as to wheather this was an attempted break in or just normal traffic, we began to gather the packet contents that were causing the Security Event to trigger. We added then added the Log Raw and View Session to the Qmail Buffer Overflow signature, thus, the suspicious activity continued. Then we were able to gather serveral attack packets, and when we viewed the session, there were very long lines of data with a single repeating patteren which was "&pmca".

We believed that this was a case of a very long message line at that point. However, to make the final determination, we made one last rule change that can be viewed at table 09 above.

Soon after making the rule change, we gathered several connections that also set off the Qmail Buffer Overflow Security Event. We inspected the sessions and determined that it was in fact an e-mail message, and not an attack. The messages were still suspicious as they were chain letters with BADLY formatted MIME encapsulation, but it was not an attempted break-in or intrusion.

Conclusion

ntrusion Detection systems today, provide strong and many capabilities to detect suspicious activity and attempted break-ins. By fallowing the four steps that I have provided, one, should be able to determine the true nature of the activity and take the approproate steps torward what the attacker is doing.