Investigating an Attempted Intrusion

.--. .--. .--. .---. : .--': .--': .; :: .; : `. `. `. `. : :: .' _`, : _`, :: :: :: :.`. `.__.'`.__.':_;:_;:_;:_;

This information was provided and written by OptikNerve. This text file is for a server administrator to be able to determain wheather or not there is an attempted break-in or intruder, and what the approproate 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.

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 fallowing 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.

Table 01: RealSecure connection event example: Added to the policy to log attacker's activity. (see step 2)

Event Name	Action	Source IP	Destination IP	Protocol	Source Port	Destination Port
SUS_ACT	Notify, Log	Source of activity	Destination of activity	UDP, TCP, and/or ICMP	ANY	ANY

Table 02: RealSecure connection event example: Added to log all traffic from the attacker's source. (see step 3)

Event Name	Action	Source IP	Destination IP	Protocol	Source Port	Destination Port
SUB_SRC	Notify, Log	Source of activity	ANY	UDMP, TCP, and/or ICMP	ANY	ANY

Table 03: RealSecure connection event example: Added to log packet payloads. (see step 4)

Event Name	Action	Source IP	Destination IP	Protocol	Source Port	Destination Port
SUB_ACT	Notify, Log, Log Raw, View Session	Source of activity	Destination of activity	UDP or TCP	ANY	Port where the traffic is
SUS_ACT	Notify, Log, Log Raw, View Session	Destination of activity	Source of activity	UDP or TCP	Port where the traffic is	ANY

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 Address	Source Port	Destination Address	Destination Port	Protocol	Information
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 Name	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 Address	Source Post	Destination Address	Destination 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

name.our.url.org

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.