This article, a discussion of the characteristics of abnormal Internet Protocol (IP) packets, is the first in a series of tutorials that are intended to educate intrusion detection system administrators about IP. As the use of network intrusion detection systems becomes more widespread, system administrators must learn how to use them effectively. Unfortunately, many admins do not have a thorough knowledge of IP. So even though an IDS may produce alerts about particular scans and attacks, an admin may not understand what the alerts mean.

IP protocol standards are defined in the RFC (Request for Comments) documents, which are available at http://www.ietf.org/rfc.html. For the sake of this article, we define abnormal packets as those which violate those standards. Abnormal packets may be generated through benign means, such as a malfunctioning router, but they are usually specially crafted by attackers. The abnormality is often introduced into the packet purposely so that the packet may avoid being blocked by a firewall or intrusion detection system. In other cases, abnormal packets are used to attempt to crash systems. A great place to see real examples of abnormal packets is the SANS Institute's Global Incident Analysis Center.

There are many different types of IP protocols. You are probably familiar with at least three of them: the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP) and the Internet Control Message Protocol (ICMP). There are dozens of other IP protocols; examples that you may know include routing protocols such as IGRP, EIGRP and OSPF. Each IP protocol type has its own value, called an Internet Protocol number. These are important to know because some systems log packets by the IP number, not the corresponding abbreviation. In this article, we will review some characteristics of the most commonly seen types, which are type 1 (ICMP), type 6 (TCP) and type 17 (UDP). A list of all of the IP numbers is available at ftp://ftp.isi.edu/in-notes/iana/assignmen...rotocol-numbers.

RFC 791 described a four bit field that was to be used to identify the underlying internetworking protocol of a packet. The Internet Protocol that we are familiar with is version number 4. The new version of IP, which will be deployed in the coming years, is version number 6. Normally, you should never see any packet with a version number other than 4, but you may occasionally come across one. If you see a packet with a version other than 4, you can be pretty sure that it is crafted. For more information, visit http://www.isi.edu/in-notes/iana/assignmen...version-numbers.

Certain IP addresses have been specially designated by the Internet Assigned Numbers Authority (IANA) as reserved for internal network use only, not for Internet use.

The reserved address ranges are:
10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255 and 192.168.0.0 - 192.168.255.255.

(Read RFC 1918, "Address Allocation for Private Internets", at http://www.isi.edu/in-notes/rfc1918.txt for more information.) Although these addresses should never be seen over the Internet, they are. Sometimes this is caused by equipment which has been misconfigured; for example, a firewall may accidentally be allowing internal address to "leak" onto the Internet. Also, computers that unsuccessfully attempt to get a valid IP address through DHCP typically are assigned addresses on the 169.254 subnet. Another reason for seeing these addresses on the Internet is that attackers are creating crafted packets with false IP addresses. This technique is better known as IP spoofing.

The main reason for performing IP spoofing is to make it harder for an attack to be traced back to its real IP address. Attackers may use addresses in the reserved address ranges listed above; more commonly, they use regular addresses which belong to someone else. So if your system is attacked, you may trace it back to an innocent third party. Another type of IP spoofing attack, called a Land attack, uses packets with the source and destination address set to the same value. Packets should always have different source and destination addresses, so your network devices should reject any packet where those values are the same.

In order to protect your network from IP spoofing generated by attackers on the Internet or on your own network, you should only permit incoming packets with a source address outside your network's range, and outgoing packets with a source address in your network's range. Also, packets that have a source or destination address in one of the ranges previously mentioned should not be permitted through Internet-based devices.

TCP is a connection-oriented protocol; it uses various flags to indicate that a connection is being started or ended, or that the data carries a high priority. Many attacks are based on altering the TCP flags. Certain illegal combinations of TCP flags may be able to help packets avoid detection by firewalls or intrusion detection systems; other illegal combinations may be used to crash operating systems.

The functional specification for TCP is defined in RFC 793. This RFC and others define how systems should respond to legitimate packets, but they don't explain how systems should handle illegal combinations of flags. Consequently, different operating systems respond differently to illegal flag combinations. Attackers can exploit this to determine what operating system a device is using.

SYN (Synchronization) - Initiate a TCP connection.
ACK (Acknowledgment) - Indicates that the value in the acknowledgment number field is valid.
FIN (Finish) - Gracefully end a TCP connection.
RST (Reset) - Immediately end a TCP connection.
PSH (Push) - Tells the receiver to pass on the data as soon as possible.
URG (Urgent) - Indicates that the urgent pointer is valid; often caused by an interrupt.
Before reviewing abnormal flag combinations, let's look at the normal ones:

SYN, SYN ACK, and ACK are used during the three-way handshake which establishes a TCP connection.
Except for the initial SYN packet, every packet in a connection must have the ACK bit set.
FIN ACK and ACK are used during the graceful teardown of an existing connection. PSH FIN ACK may also be seen at the beginning of a graceful teardown.
RST or RST ACK can be used to immediately terminate an existing connection.
Packets during the "conversation" portion of the connection (after the three-way handshake but before the teardown or termination) contain just an ACK by default. Optionally, they may also contain PSH and/or URG.
Packets with any other flag combination can be classified as abnormal. Here are some of the most commonly occurring ones:

SYN FIN is probably the best known illegal combination. Remember that SYN is used to start a connection, while FIN is used to end an existing connection. It is nonsensical to perform both actions at the same time. Many scanning tools use SYN FIN packets, because many intrusion detection systems did not catch these in the past, although most do so now. You can safely assume that any SYN FIN packets you see are malicious.
SYN FIN PSH, SYN FIN RST, SYN FIN RST PSH, and other variants on SYN FIN also exist. These packets may be used by attackers who are aware that intrusion detection systems may be looking for packets with just the SYN and FIN bits set, not additional bits set. Again, these are clearly malicious.
Packets should never contain just a FIN flag. FIN packets are frequently used for port scans, network mapping and other stealth activities.
Some packets have absolutely no flags set at all; these are referred to as "null" packets. It is illegal to have a packet with no flags set.
Besides the six flag bits described here, TCP packets have two additional bits which are reserved for future use. These are commonly referred to as the "reserved bits". Any packet which has either or both of the reserved bits activated is almost certainly crafted.

Packets should never have a source or destination port set to 0.
The acknowledgment number should never be set to 0 when the ACK flag is set.
A SYN only packet, which should only occur when a new connection is being initiated, should not contain any data.
Packets should not use a destination address that is a broadcast address, usually ending in .0 or .255. (You may not be familiar with .0 as a broadcast address; it was an older style of broadcast.) Broadcasts are normally not performed using TCP.

Many of the tools used by attackers to scan and probe your networks are based on the use of abnormal TCP packets. A large percentage of alerts detected by intrusion detection systems involve these types of packets, so it is critical to be able to identify them and understand their purpose. By configuring your intrusion detection system to alert on all abnormal TCP packets, you may catch malicious activity that you were not previously seeing.

Unlike TCP, UDP is a connectionless protocol. UDP does not have the flag and reserved bits that TCP does. However, both TCP and UDP rely on source and destination ports. Like TCP, packets, UDP packets should never have a source or destination port set to 0. UDP packets can also be fragmented maliciously; see the "Fragmentation" section below for more information on this technique.

ICMP is used to pass an error message between two hosts or a host and a network device such as a router. Since UDP and IP are connectionless protocols, they rely on ICMP to transmit error messages on their behalf. To avoid potential error message loops, responses are never sent to ICMP error messages. ICMP has no port numbers; it uses ICMP message types and codes instead. Another noteworthy characteristic of ICMP is that it supports broadcast traffic. Since ICMP packets are not very complicated, there are not that many ways that they can be made abnormal.

One type of ICMP message that is used maliciously is a redirect. ICMP redirect messages are intended to be sent from a router to a host, in order to inform that host that a different router is more optimal than it is when contacting a particular destination address. Some attacks such as WinFreeze use false ICMP redirect messages to attempt to convince a host to use itself as the optimal router. Obviously, any packet which tells a device to route everything to itself should be considered highly abnormal.

Most ICMP packets are composed of a small header and payload; for example, most ICMP echo request packets have an 8-byte header and a 56-byte payload. ICMP packets that are significantly larger than normal should be considered suspicious. Also, some ICMP types, such as echo requests, should not be carrying any data. Some malicious applications, including various distributed denial of service programs and tunneling programs, use ICMP packets as "containers" that hide other traffic. So an ICMP echo reply might actually contain a completely different IP protocol within its data, for example. If you monitor your systems for large ICMP packets or for packets of specific ICMP types that should not contain data but do, you should be able to detect this type of traffic.

When an IP packet is too large to be transmitted as one entity, it must be split into two or more smaller pieces that can be sent across networks. Each piece of a packet is referred to as a fragment. Fragmentation occurs for all of the protocols we are discussing - TCP, UDP and ICMP - although it occurs most frequently for TCP. However, attackers can create artificially fragmented packets. In some cases, this is done in order to attempt to crash systems; in other cases, it is done to circumvent firewall rules or avoid intrusion detection systems. Some firewalls and intrusion detection systems do not perform packet reassembly, so they can only consider the properties of each individual fragment.

One type of malicious fragmentation involves fragments that have illegal offsets. An offset value indicates where a fragment's data should be placed in a reassembled packet. The first fragment appears to be normal, except that it is usually very small. The second fragment has a data offset value which is less than the length of the data in the first packet. So if the first fragment had 24 bytes of data, the second fragment might claim to have an offset of 20 bytes. This would mean that the data in the second fragment would overwrite the last four bytes of the data from the first fragment. If the fragmented packet was TCP, then the first fragment would contain the TCP header. The purpose of the offset value of the second fragment would be to overwrite part of the first packet's TCP header, such as the destination port number, when the packet is reassembled at the destination. So an attacker could send a fragmented packet through your firewall to your web server on port 80, but when the web server reassembles the fragments, the final packet could actually go to a completely different port.

The same type of attack can be used to crash systems. In some older operating systems, when the receiving host attempts to rebuild such a packet, it calculates a negative length for the second fragment. This value is passed to a function which should do a copy from memory. Unfortunately, the memory copy cannot handle a negative number, so it thinks that the small negative number is actually an enormous positive number.

A second type of attack involving fragments is known as the tiny fragment attack. Two TCP fragments are created. The first fragment is so small that it does not even include the full TCP header, particularly the destination port number. The second fragment contains the remainder of the TCP header, including the port number. Some firewalls and intrusion detection systems may let one or both fragments pass through, particularly if they do not perform packet reassembly.

Another type of attack involves sending a fragmented, abnormally large packet. The attacker hopes that when the receiving host receives the fragments, it will crash while attempting to reassemble the packet, since the whole packet has an illegal length. (In case you are not aware, packets have minimum and maximum lengths.) The best-known example of this attack type is the infamous Ping of Death attack. It creates an ICMP echo request packet which is larger than the maximum packet size of 65,535 bytes.

Some attacks use packets that are not illegal but are extremely suspicious. For example, suppose that you receive a fragmented TCP packet that only has the SYN flag set. Since a SYN-only packet is not allowed to carry any data, it should not be large enough to require fragmentation. If you encounter such a packet, treat it with great suspicion.

So how can you protect your network against fragmentation attacks? As mentioned previously, you should implement firewalls and intrusion detection systems that can perform packet reassembly. You should also configure your intrusion detection system to alert on any extremely small fragments other than the final fragment in a packet. Under normal circumstances, you should not be seeing small initial fragments; these are normally malicious in nature. Also, remember to keep your systems current with all patches and updates.

Anyone who is involved with intrusion detection should have a solid knowledge of what normal and abnormal IP traffic is. It is not uncommon for the administrator of an intrusion detection system to get great alerts from the IDS but not understand what they really mean. Hopefully, by studying more about IP and thinking about the concepts presented in this article, you can better interpret alerts and analyze what is really happening on your network.

Karen Kent Frederick is a senior security engineer for NFR Security. Karen has a B.S. in Computer Science and is completing her Master's thesis in intrusion detection through the University of Idaho's Engineering Outreach program. She holds several certifications, including Microsoft Certified Systems Engineer + Internet, Check Point Certified Security Administrator, and GIAC Certified Intrusion Analyst. Karen is one of the authors and editors of "Intrusion Signatures and Analysis", a book on intrusion detection that will be published in January 2001.

The FBI, CERT, and your ISP will help you if you are under attack, but they will not secure your network. This leaves you with two security options- in-house security or a managed security solution. In either case, you need to have an incident response team. This team should include senior technical staff who can help formulate a plan of action, and should have access to senior management who can authorize the action. Time can be a critical factor in a denial of service attack. The more time it takes to figure out who is capable of making decisions, the longer you will cut off. One key role of this team is to have a contact person to coordinate with other organizations (e.g. CERT, below) during the incident.

Put together an Emergency Response Plan, and identify a team who will be responsible for implementing it. Ensure that the team has senior management contact, and the necessary technical skills. The ISS X-Force offers a great deal of technical information useful for technical staff education at http://xforce.iss.net/. If these skills are not available in-house, consider outsourcing this from a company offering Emergency Response Services. ISS' Emergency Response Services (ERS) are specifically geared to help companies build and improve upon incident preparedness. This is achieved through quarterly on site workshops with customers. This service then helps ISS' Emergency Response Team be more effective with its 24x7 service in the event that the client comes under attack. The Emergency Response Plan should include an escalation policy, and you should educate your organization on this policy.

When dealing with distributed denial of service attacks, there is no way for you to be able to stop them at your network. These attacks end up being a war of bandwidth and the attacker is likely to win that battle because of the distributed components. This is not to say that there is no way to stop them or that there is nothing for you to do. There are several hardware/software solutions that you can implement that will minimize the effect of these attacks and offer you some protection. These solutions can also prevent you from becoming an unwilling component of a DDOS attack (which will also affect bandwidth and network performance.)

A Firewall is your first line of defense. It defines legal connections, helps prevent intrusion (which would be required to plant agent or zombie programs on your network,) and is capable of keeping detailed logs on suspicious activity. Firewalls are not a final solution. A skilled attacker or someone who has downloaded good tools can easily get past the best firewalls if vulnerabilities exist on your network. You can think of a firewall as defining the doors and windows on a house. If vulnerabilities exist on your network, the cracker need only knock on the door and someone will let him or her in from the inside. Just because you have a firewall in place doesn't mean that someone hasn't planted zombies in your network- finding those zombies is best left to scanners and watching for intrusion is best left to IDS software.

During an attack, the firewall will take the brunt of the attack and will mean the difference between no Internet connection and an entirely locked up network. Any firewall with the proper rule base can recognize all of the flooding attacks used by these distributed tools and drop the packets before they penetrate into the network. Most commercial firewalls can also be set to notify you that the attack is underway. The most important feature in this type of attack may be the firewall's ability to log this suspicious traffic. The more information that you are able to give your ISP about the traffic you are seeing, the faster they will be able to filter out the traffic before it gets to your network. This information will also help the FBI track down the attacker and the zombie machines making life easier for everyone.

When it comes to DDOS, the value of scanning programs is two fold. First of all, products like our Internet Scanner, System Scanner, and Database Scanner will scan your network for vulnerabilities and tell you how to fix them (give you links to patches, tell you step-by-step how to configure OS settings or software, etc.) These vulnerabilities are what the attacker exploits in order to plant the DDOS agents. If the vulnerabilities are corrected, the attacker is unable to gain a foot hold on your network. Secondly, Internet Scanner can scan your network for existing back doors and DDOS agents so that you will be able to remove them.

A good IDS is your best friend when it comes to security. I will once again use the analogy of a house. If a firewall defines the doors and windows on a house, an Intrusion Detection System (IDS) is like an alarm system. An IDS does not look for vulnerabilities on a network; it churns thru all of the packets that go to a network segment or a host and looks for anyone trying to scan your network or exploit a vulnerability (whether the particular vulnerability exists on your network or not.) An IDS acts as a watchdog that looks for signs of trouble and can be set to automatically respond to any signs of danger.

In order for an attacker to place agents on your network, he or she must first penetrate your network and then root one or more of your machines (rooting a machine means gaining root or administrator access to a machine by elicit means.) This is not an instantaneous process and requires several stages in order to accomplish this goal. First, the intruder has to scan your firewall and see what is open. Then an exploit must be run in order to gain access into your network. At this point he or she would have to establish a connection to an internal machine (probably the one that let him in) and transfer the source code or binaries to the machine. After installing the software, the attacker would probably scan the network for other vulnerable machines and repeat the process. If a good IDS was on this network, the attacker never would have gotten past the initial scan. The most powerful and widely used IDS on the market is our very own RealSecure. In addition to being able to detect a master trying to talk to an existing agent, RS network sensors (or engines) are able to detect and respond to more exploit attempts than any other IDS. Our responses range from logging (see above for the importance of this,) notification (real time display, email, paging), reconfiguring your firewall on the fly, killing connections, and user defined responses.

During a DDOS attack, the immediate notification of everyone on the response team can result in a speedier recovery of Internet access. The ability to reconfigure the firewall will help prevent these packets from slowing down your internal network. Firing kills for SYNfloods will free up some of your resources and take some strain off of your firewall and logging will assist your ISP and the FBI in stopping the attack.

The easiest way to spot a DOS attack is to have it reported by an IDS or Firewall. It will show up as any of the following: SYNflood, PingFlood, UDP bomb, or SMURF. Since you should assume that the source IP field is most likely spoofed, the MAC address is how you tell if it is distributed. If you are seeing multiple attacks from varying MAC addresses, chances are it is a DDOS attack.

Contact Law Enforcement authorities to inform them of the incident, such as the FBI. You may not be the only organization under attack, and they may be able to provide technical assistance or contacts to help your response efforts. You can help the law enforcement efforts by collecting system log information from target systems. These logs may be important evidence that law enforcement needs to take action; it is critical that this information be collected and protected before it is accidentally (or deliberately) erased.
 
Monitor important systems during the attack using intrusion detection software or services. This can help mitigate the attack, by discovering actions that can be taken (e.g. installing security patches, expanding RAM to help the OS to maintain performance during Denial-Of-Service attacks). It can also help detect signs that this attack is more than a nuisance - for example, that a Denial-Of-Service attack is a diversion intended to distract your attention from an actual takeover of your systems. In particular, if other organizations are under particular attack, check any of your systems that might be similar for signs of that attack as well.

Smurf is a simple attack based on IP spoofing and broadcasts. A single packet (such as an ICMP Echo Request) is sent as a directed broadcast to a subnet on the Internet. All the machines on that subnet respond to this broadcast. By spoofing the source IP address of the packet, all the responses will get sent to the spoofed IP address. Thus, a hacker can often flood a victim with hundreds of responses for every request the hacker sends out.
There is not much the victim can do, because the incoming link is being overloaded. However, the victim does known the subnet number of the amplifier, and should contact the owner to tell them to turn off amplification (i.e. enable filtering of ICMP Echoes).

IRC servers are the primary victim to smurf attacks. Script-kiddies run programs that scan the Internet looking for "amplifiers" (i.e. subnets that will respond). They compile lists of these amplifiers and exchange them with their friends. Thus, when a victim is flooded with responses, they will appear to come from all over the Internet.

On IRCs, hackers will use bots (automated programs) that connect to IRC servers and gather a victim's IP address. The bots then send the forged packets to the amplifiers to inundate the victim.

The owner of the amplifier is also a victim in this attack. They can easily defend against the attack by filtering the incoming broadcasts.

The hacker is able to saturate the links and gateways leading to the inundated victim, thus no firewall can really protect the victim. The only real defense is to trace back to the amplifiers and contact those system administrators.

The attack is named "smurf" after a popular program that generates the attack.

Fraggle, a variant uses UDP instead of ICMP. In this case, the ports echo, chargen, daytime, qotd are used to trigger responses. These ports are also susceptible to pingpong attack, and should be turned off.

A type of network security breach in which a network connected to the Internet is swamped with replies to ICMP echo (PING) requests. A smurf attacker sends PING requests to an Internet broadcast address. These are special addresses that broadcast all received messages to the hosts connected to the subnet. Each broadcast address can support up to 255 hosts, so a single PING request can be multiplied 255 times. The return address of the request itself is spoofed to be the address of the attacker's victim. All the hosts receiving the PING request reply to this victim's address instead of the real sender's address. A single attacker sending hundreds or thousands of these PING messages per second can fill the victim's T-1 (or even T-3) line with ping replies, bring the entire Internet service to its knees.
Smurfing falls under the general category of Denial of Service attacks -- security attacks that don't try to steal information, but instead attempt to disable a computer or network.

http://www.webopedia.com/TERM/S/smurf.html

1) Here is a slow host sweep for the telnet port.  The scan program used random destination
address in addition to being a slow sweep to hide it from an intrusion detection system.
The hacker was probably looking for a Unix box or network box (router/switch) to try brute
force login attempts.

Jan 10 10:01:03 10.10.10.1:2532 -> 192.168.1.5:23 SYN **S*****
Jan 10 10:05:04 10.10.10.1:2573 -> 192.168.1.100:23 SYN **S*****
Jan 10 10:12:08 10.10.10.1:2640 -> 192.168.1.25:23 SYN **S*****
Jan 10 10:32:08 10.10.10.1:2681 -> 192.168.1.220:23 SYN **S*****
Jan 10 10:41:10 10.10.10.1:2801 -> 192.168.1.17:23 SYN **S*****
Jan 10 11:23:13 10.10.10.1:2950 -> 192.168.1.21:23 SYN **S*****
Jan 10 11:43:04 10.10.10.1:3051 -> 192.168.1.140:23 SYN **S*****
Jan 10 11:52:18 10.10.10.1:3162 -> 192.168.1.111:23 SYN **S*****
Jan 10 12:04:18 10.10.10.1:3263 -> 192.168.1.74:23 SYN **S*****
Jan 10 12:09:20 10.10.10.1:3566 -> 192.168.1.55:23 SYN **S*****
Jan 10 12:38:05 10.10.10.1:4080 -> 192.168.1.252:23 SYN **S*****

-----------------------------------------------------------------------

2) Here's a high udp scan.  This looks like a crafted packet since the port number of the source
is the same.  The scan could have been looking for a listening high port for a trojan horse
application.

Sep 15 12:06:19 10.10.10.1:14962 -> 192.168.1.22:24118 UDP
Sep 15 12:06:19 10.10.10.1:14962 -> 192.168.1.22:24119 UDP
Sep 15 12:06:19 10.10.10.1:14962 -> 192.168.1.22:24120 UDP
Sep 15 12:06:19 10.10.10.1:14962 -> 192.168.1.22:24121 UDP
Sep 15 12:06:19 10.10.10.1:14962 -> 192.168.1.22:24122 UDP
Sep 15 12:06:19 10.10.10.1:14962 -> 192.168.1.22:24123 UDP
Sep 15 12:06:20 10.10.10.1:14962 -> 192.168.1.22:24124 UDP
Sep 15 12:06:20 10.10.10.1:14962 -> 192.168.1.22:24125 UDP
Sep 15 12:06:20 10.10.10.1:14962 -> 192.168.1.22:24126 UDP
Sep 15 12:06:20 10.10.10.1:14962 -> 192.168.1.22:24127 UDP


-----------------------------------------------------------------------

3) Here an attacker spoofs the 10.10.10.1 network and tries to echo packets from the character
generator port of several machines.  The attacker either guesses that the x.x.x.1 address is
the routers addresses or has already done some surveillance to determine this information.

Aug 3 04:28:17 10.10.10.1:7 -> 192.168.1.1:19 UDP
Aug 3 04:28:17 10.10.10.1:7 -> 192.168.2.1:19 UDP
Aug 3 04:28:17 10.10.10.1:7 -> 192.168.3.1:19 UDP
Aug 3 04:28:17 10.10.10.1:7 -> 192.168.4.1:19 UDP
Aug 3 04:28:17 10.10.10.1:7 -> 192.168.5.1:19 UDP
Aug 3 04:28:17 10.10.10.1:7 -> 192.168.6.1:19 UDP
Aug 3 04:28:17 10.10.10.1:7 -> 192.168.7.1:19 UDP
Aug 3 04:28:17 10.10.10.1:7 -> 192.168.8.1:19 UDP
Aug 3 04:28:17 10.10.10.1:7 -> 192.168.9.1:19 UDP


-----------------------------------------------------------------------

4) Here's a Land attack that was scripted to go down a class C network.  You can tell that they
were scripted by the fast speed in which the packets were sent out.

Jan 7 10:01:03 192.168.1.1:139 -> 192.168.1.1:23 SYN **S*****
Jan 7 10:01:03 192.168.1.2:139 -> 192.168.1.2:23 SYN **S*****
Jan 7 10:01:03 192.168.1.3:139 -> 192.168.1.3:23 SYN **S*****

-----------------------------------------------------------------------

5) Here's a scripted surveillance scan for Cisco devices.  They're using port 1999 the
identification port where they can sniff the packets coming back and look into the data portion
for Cisco. 

Aug 13 15:21:38 10.10.10.1:2344 -> 192.168.1.1:1999 SYN **S*****
Aug 13 15:21:38 10.10.10.1:2344 -> 192.168.1.2:1999 SYN **S*****
Aug 13 15:21:38 10.10.10.1:2344 -> 192.168.1.3:1999 SYN **S*****
Aug 13 15:21:38 10.10.10.1:2344 -> 192.168.1.4:1999 SYN **S*****
Aug 13 15:21:39 10.10.10.1:2344 -> 192.168.1.5:1999 SYN **S*****
Aug 13 15:21:39 10.10.10.1:2344 -> 192.168.1.6:1999 SYN **S*****

----------------------------------------------------------------------

6) Here's someone looking for the default Back Orifice port 31337 UDP. 
Either they have planted the trojan horse on this machine or they are scanning this machine
for the program.

Dec 23 05:00:07 10.10.10.1:2732 -> 192.168.1.1:31337 UDP

----------------------------------------------------------------------

7) Here's a single anamolous packet.  The SYN and FIN bits were both set.  This could have been
a crafted packet to try to confuse a tcp/ip stack resulting in a DOS attack.  They might have
been targeting a particular machine that they have already discovered since this was the only
packet to come in at like this. 

10.10.10.1:2145 > 192.168.1.1:3242: SF 3832587:3832587(0) win 512

----------------------------------------------------------------------

8) Here's an icmp request that fragmented the packet.  The problem with this one is the offset of
the second packet overlaps the second one.

10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10947:1024@0+)
10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10947:1024@128)

-----------------------------------------------------------------------

9) Here's a Microsoft scan for port 137,138,and 139.  This has to be a scripted program because
of the speed of the scan.  In addition to just looking for a microsoft device the hacker is also
looking for particular ports that are open.

Dec 27 03:12:52 10.10.10.1:8362 -> 192.168.1.1:137 SYN **S*****
Dec 27 03:12:53 10.10.10.1:8362 -> 192.168.1.1:138 SYN **S*****
Dec 27 03:12:53 10.10.10.1:8362 -> 192.168.1.1:139 SYN **S*****
Dec 27 03:12:53 10.10.10.1:8362 -> 192.168.1.2:137 SYN **S*****
Dec 27 03:12:53 10.10.10.1:8362 -> 192.168.1.2:138 SYN **S*****
Dec 27 03:12:53 10.10.10.1:8362 -> 192.168.1.2:139 SYN **S*****
Dec 27 03:12:53 10.10.10.1:8362 -> 192.168.1.3:137 SYN **S*****
Dec 27 03:12:54 10.10.10.1:8362 -> 192.168.1.3:138 SYN **S*****
Dec 27 03:12:54 10.10.10.1:8362 -> 192.168.1.3:139 SYN **S*****

-----------------------------------------------------------------------

10)Here's a fragment attack.  Fragment packets kept coming in but no final fragment packet
arrives. The hacker is trying to overload the machine with outstanding fragment packets.  This
will eat up the memory of the machine as it waits for the transaction to timeout.

10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10947:1024@0+)
10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10947:1024@1024+)
10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10948:372@2309+)
10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10949:64@2743+)
10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10962:312@3475+)
10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10982:128@841+)
10.10.10.1 > 192.168.1.1 icmp: echo request (frag 10991:450@582+)

For approximately the last year, SHADOW analysts have been detecting a new class of network traffic. Although the probes and attacks embedded within this traffic consist mostly of known exploits, subsequent analysis reveals that multiple IP addresses are working together toward a common goal. Therefore, we have coined the phrase "coordinated attacks" to describe the activity that has been observed.

Indications of these concerted efforts appear in network traffic logs as multiple external IP addresses targeting a single address of the protected network. Similarly, a coordinated attack can also look as though multiple attackers are working together to execute a distributed scan on many internal addresses or services. It is believed that probes of this nature have been developed in an attempt to elude the scan detection code present in many intrusion detection systems.

In most of the cases observed, the number of cooperating IP addresses is rather small; four or five is common. However, as many as fifteen different coactive, scanning hosts have been uncovered by SHADOW analysts. Due to their distributed nature, these attacks were well below the threshold for a structured attack in terms of targeting, lethality and scope.

"We distinguish two fundamental types of threat. The unstructured threat is random and relatively limited. It consists of adversaries with limited funds and organization and short-term goals. While it poses a threat to system operations, national security is not targeted. This is the most obvious threat today. The structured threat is considerably more methodical and well-supported. While the unstructured threat is the most obvious threat today, for national security purposes we are concerned primarily with the structured threat, since that poses the most significant risk."
Air Force Lt. Gen. Kenneth A Minihan, director of the National Security Agency - brief to the Senate Government Affairs Committee, June 24 1998.



What is a structured attack? Interviews with premier intrusion detection researchers revealed that they consider structured attacks to be on the order of thousands of related exploits, probes, viruses, scans, denials of service, and ruses over a short period of time. Even though this definition doesn’t accurately describe the patterns discussed earlier, we cannot call this activity unstructured. It definitely has structure!

This paper will examine various coordinated attacks and probes, including coordinated traceroutes, NetBIOS scans, Reset scans, SFRP scans and coordinated DNS server exploit attempts. Some of these probes are certainly the work of multiple computers working together; others appear to be fraudulent or decoy mechanisms.


2. Coordinated traceroutes

Coordinated traceroutes serve as a reminder that sites are always vulnerable, even if their firewalls are impenetrable. Information gleaned from this technique can be used to direct a denial of service attack against a site’s external connectivity, effectively isolating the facility. Detection of coordinated traceroutes is simple; look for about five traceroutes within two seconds of one another, often with similar names.

Figure 1 shows an example of this activity. Here, five different sources, each from a different backbone network, are shown probing the same target. Most often, the target is a DNS server, or DNS serving firewall, and packet arrival is usually within tenths or hundredths of seconds of each other.


12:29:30.01 proberA.39964 > target.33500: udp 12 [ttl 1]
12:29:30.13 proberA.39964 > target.33501: udp 12 [ttl 1]
12:29:30.25 proberA.39964 > target.33502: udp 12 [ttl 1]
12:29:30.35 proberA.39964 > target.33503: udp 12 [ttl 1]


12:27:55.10 proberB.46164 > target.33485: udp 12 [ttl 1]
12:27:55.12 proberB.46164 > target.33487: udp 12 [ttl 1]
12:27:55.16 proberB.46164 > target.33488: udp 12 [ttl 1]
12:27:55.18 proberB.46164 > target.33489: udp 12 [ttl 1]


12:27:26.13 proberC.43327 > target.33491: udp 12 [ttl 1]
12:27:26.24 proberC.43327 > target.33492: udp 12 [ttl 1]
12:27:26.37 proberC.43327 > target.33493: udp 12 [ttl 1]
12:27:26.48 proberC.43327 > target.33494: udp 12 [ttl 1]


12:27:32.96 proberD.55528 > target.33485: udp 12 [ttl 1]
12:27:33.07 proberD.55528 > target.33486: udp 12 [ttl 1]
12:27:33.17 proberD.55528 > target.33487: udp 12 [ttl 1]
12:27:33.29 proberD.55528 > target.33488: udp 12 [ttl 1]


12:27:30.55 proberE.21337 > target.33475: udp 12 [ttl 1]
12:27:30.56 proberE.21337 > target.33476: udp 12 [ttl 1]
12:27:30.58 proberE.21337 > target.33477: udp 12 [ttl 1]
12:27:30.59 proberE.21337 > target.33478: udp 12 [ttl 1]


Figure 1. Coordinated traceroute example.
 
Coordinated traceroutes do have a commercial use. Some Internet Service Providers (ISP) use them to calculate the best routes back to clients in an attempt to provide optimum web response. The stimulus for this type activity is a host from the protected network visiting a web server supported by an ISP that uses coordinated traceroutes.

As mentioned above, coordinated traceroutes can be a benign effort to improve the performance of a server. As such they can be viewed as providing a useful service. However, they can also be used to determine all the routes into your protected network. Thus it should be of interest to determine who is performing these traceroutes and why.
 

3. NetBIOS deception

One of the first things that a network analyst learns is that network traffic is not always what it appears to be. Source address spoofing is a classic example of this. Many commonly available exploit tools include this capability. In fact, the latest version of nmap takes spoofing a step further; it includes a decoy option. This option allows the hacker to make an attack appear as though it is coming from multiple sources. Even if an analyst at the targeted site detects the attack, it is very difficult to determine which of the IP addresses were spoofed, and which one was real.


The trace in figure 2 is from a site that receives very few NetBIOS session connection attempts. The traffic shown was detected over a single twenty-four hour period. These source addresses correlate with NetBIOS session connection attempts seen at other sites over several days. The signature of this massive scan is: four connect attempts for each address, the do not fragment option is set, a window size of 8192, and the TTL fields cluster. Perhaps the most interesting signature of this coordinated activity is that the traffic is destined only for IP addresses that are not populated by hosts. The first two traces show all four attempts, the rest have been edited for space.

The source addresses spanned several countries, but certainly could have been spoofed. The scan rate is slow enough that the entire probe could have been generated from a single computer. The fact that the Time To Live (TTL) field is within three hops for all packets is also interesting and points to a single computer. Different operating systems have different TTL defaults. The probes were sent to hosts that do not exist, therefore the TCP three-way handshake was never completed. That would be evidence this was actually a probe. Could this be a hoax?

If this is a hoax, what is the purpose? One possibility is that fake attacks may create fear, uncertainty, and doubt in the same vein as virus hoaxes. Another possibility is an "attacker honey pot". Even a mediocre fake attack will tie up analyst and CIRT resources, and possibly serve as a distraction so that a much lower signal precision attack can get through undetected.

Another hypothesis is that the attacker is only interested in "brand new" systems that are brought online. Since most security patches are available from vendor websites, many administrators bring up vulnerable systems with the intent of downloading and installing the patches at a later date. This process may take several days, leaving new systems and the networks that they reside on vulnerable to attack.

The fact that only non-existent systems are targeted makes these probes particularly puzzling. It also makes them worthy of concern, since it implies that the attackers have a precise map of the protected network.


Trace 1:
 

00:56:22.78 proberD.3506 > 172.20.124.23.139: S 14300153:14300153(0) win 8192 (DF)
00:56:25.69 proberD.3506 > 172.20.124.23.139: S 14300153:14300153(0) win 8192 (DF)
00:56:31.70 proberD.3506 > 172.20.124.23.139: S 14300153:14300153(0) win 8192 (DF)
00:56:43.69 proberD.3506 > 172.20.124.23.139: S 14300153:14300153(0) win 8192 (DF)


Trace 2:


06:49:55.47 proberA.4197 > 172.20.139.137.139: S 596843772:596843772(0) win 8192 (DF)
06:49:58.44 proberA.4197 > 172.20.139.137.139: S 596843772:596843772(0) win 8192 (DF)
06:50:04.44 proberA.4197 > 172.20.139.137.139: S 596843772:596843772(0) win 8192 (DF)
06:50:16.43 proberA.4197 > 172.20.139.137.139: S 596843772:596843772(0) win 8192 (DF)
 
 

Additional traces, only the first packet is shown:


12:57:56.94 proberE.2038 > 172.20.216.29.139: S 294167370:294167370(0) win 8192 (DF)
13:37:51.75 proberI.4186 > 172.20.215.205.139: S 22881687:22881687(0) win 8192 (DF)
13:50:23.64 proberB.3293 > 172.20.53.123.139: S 355997160:355997160(0) win 8192 (DF)
14:11:01.95 proberC.3491 > 172.20.245.182.139: S 57370977:57370977(0) win 8192 (DF)
15:41:59.50 proberG.3278 > 172.20.252.141.139: S 266305199:266305199(0) win 8192 (DF)
22:49:15.39 proberH.3658 > 172.20.124.23.139: S 14035939:14035939(0) win 8192 (DF)


Figure 2. Netbios deception example.
4. Reset scans

If you examine the Internet traffic to your site, there is a very good chance you will find a large number of inbound Resets and SYN/ACKs for which there is no corresponding SYN packet. Generally, these scans originate from a multitude of source addresses and often appear to be coordinated due to their concurrency. Several questions come to mind: "What is going on?" and furthermore, "What are some of the events that cause Reset generation?" Section 4 will explore some of the events that can generate Reset scans, the motivations for Reset scanning, and will also discuss the methods that SHADOW uses to detect them.
 

4.1. Natural function of TCP/IP

Resets are a normal part of TCP/IP communications. If something goes wrong with a TCP connection, a reset may be generated. Typically, in this case only one would be observed between the server and client. If a connection is attempted to a service that does not exist, a reset may be generated. A single SYN attempt/Reset response from a mscan probe is shown in figure 3. Note that the acknowledgement number is the sequence number incremented by one.


13:13:10.670000 www.1880 > mailrelay.6000: S 1393635005:1393635005(0) win 512
13:13:10.680000 mailrelay.6000 > www.1880: R 0:0(0) ack 1393635006 win 0


Figure 3. SYN attempt/Reset response example.

Client systems generally attempt to establish connections multiple times. Four SYN "active open" attempts to the same destination address and source port is commonly seen for most services. Electronic mail and web (TCP port 25 and TCP port 80) active opens often try larger numbers of attempts ranging from twelve to twenty five.

From an intrusion detection standpoint, we generally expect to see outbound Resets as a result of activity caused by inbound traffic. Examining the trace in figure 3, we see that the inbound traffic from www to Mailrelay attempts to initiate an X Windows connection. Mailrelay wants no part of this; so an outbound and Reset to www is generated.

If we detect inbound Resets we expect that these were caused by outbound connections from our systems. In the next two possible causes for the generation of Resets, we will look at situations where we observe a medium to large number of Resets, (or SYN/ACKS) inbound. In these cases, there is no corresponding SYN packet.
 
 

4.2. Second order effect

The inbound Resets (or Syn/Acks) could also be explained as a "second order effect" of a denial of service attack, or scan on another site. For this to be a second order effect, we must not have initiated the connections with SYN packets and our IP addresses are used (spoofed) to attack someone else. This last case is a dominant factor in the generation of large numbers of inexplicable Resets. IRC servers seem to be the primary targets in a large number of these cases. 

A wide variety of Internet addresses have been used for this sport; we have received traces of excessive Resets from all over the globe. Figure 4 illustrates example traffic at two sensor locations: SITE_A and SITE_B. It shows the activity that each site detected on the same day. The time stamps indicate concurrent activity from Irc_victim to multiple destination hosts. This denial of service attack generates Resets from Irc_victim, since the attack was to Irc_victim’s inactive ports.


Excerpts from SITE_A tcpdump at ~02:00:

02:13:23.55 Irc_victim.37762 > 192.168.129.191.18602: R 0:0(0) ack 1940197743 win 0
02:14:00.07 Irc_victim.25013 > 192.168.251.67.26831: R 0:0(0) ack 397924438 win 0
02:14:20.68 Irc_victim.32824 > 192.168.123.30.17807: R 0:0(0) ack 1747849368 win 0
 

Excerpts from SITE_B tcpdump at ~02:00:
 

02:13:21.54 Irc_victim.4723 > 172.20.96.61.7790: R 0:0(0) ack 172384509 win 0
02:14:09.39 Irc_victim.45991 > 172.20.72.145.18363: R 0:0(0) ack 578682865 win 0
02:14:12.35 Irc_victim.58839 > 172.20.46.51.51347: R 0:0(0) ack 1901339874 win 0


Figure 4. Expected behavior for inactive ports.

In contrast, figure 5 depicts the network traffic pattern for active ports. Note the change in the 12:00 hour activity to the active port 6667 with the expected SYN/ACK response from Irc_victim, followed by the RST/ACK segment indicating an aborted connection.


For the truly paranoid, we offer an alternate interpretation of the traces shown in figure 5. A "man in the middle" scan could create this signature. In this case, the attackers must compromise our site, or a node on the route to our site. They must place a sniffer that is tuned to collect Resets and Syn/Acks on a compromised site. They then port scan the target from another location spoofing our address space. The sensor located on the compromised host collects the results and sends them to the attacker. This is unlikely to be the case in attacks against multiple sites.

It is important to point out that this kind of secondary effect will appear as a coordinated attack against the protected network if the attacker targets multiple hosts or networks, and always spoofs our IP addresses in the attack.
 

Sample trace from SITE_A at ~12:00:

12:47:03.65 Irc_victim.6667 > 192.168.140.187.10496: S 157348803:157348803(0) ack 687865857 win 16384 <mss 1460> (DF)
12:47:03.87 Irc_victim.6667 > 192.168.140.187.10496: R 1:1(0) ack 1 win 16384 (DF)
12:48:38.57 Irc_victim.6667 > 192.168.246.165.33026: S 2670541452:2670541452(0) ack 2164391937 win 16384 <mss 1460> (DF)
12:48:39.07 Irc_victim.6667 > 192.168.246.165.33026: R 1:1(0) ack 1 win 16384 (DF)


Sample trace from SITE_B at ~12:00:


12:47:07.43 Irc_victim.irc > 172.20.246.181.36126: S 1105399373:1105399373(0) ack 2367553537 win 16384 (DF)
12:47:07.56 Irc_victim.irc > 172.20.246.181.36126: R 1:1(0) ack 1 win 16384 (DF)
12:47:20.35 Irc_victim.irc > 172.20.64.221.18178: S 1443077754:1443077754(0) ack 1191313409 win 16384 (DF)


12:47:20.35 Irc_victim.irc > 172.20.64.221.18178: R 1:1(0) ack 1 win 16384 (DF)


Figure 5. Expected behavior for active ports.

4.3. Resets for intelligence gathering

Reset scanning works like any other inverse mapping method. This is because the routers are thinking IP, not TCP and the IP address is in the IP layer. When destination IPs or ports are inactive, the routers simply want to be helpful and return an address unreachable message. There are a variety of techniques (including Reset scanning) to locate the hosts, nets, and active service ports that do not exist. The attacker simply has to take the converse of the map to get a first order understanding of what does exist.

Figure 6 is an example from the point of view of the Reset scanner. They know the address of the system(s) they have scanned, so they wait for icmp error messages from the destination network’s router. The results of interest could look like net (or host) unreachable or time exceeded.


20:38:11.783596 router > 192.168.32.192: icmp: time exceeded in-transit [tos 0xc0]
20:38:55.597130 router > 192.168.31.15: icmp: time exceeded in-transit [tos 0xc0]
20:41:41.824191 router > 192.168.52.99: icmp: time exceeded in-transit [tos 0xc0]
20:43:50.750498 router > 192.168.52.99: icmp: time exceeded in-transit [tos 0xc0]
20:44:01.280339 router > 192.168.61.209: icmp: time exceeded in-transit [tos 0xc0]
20:44:27.790505 router > 192.168.59.164: icmp: time exceeded in-transit [tos 0xc0]


Figure 6. Results from a reset scan.

In the early days of this technique, Reset scans were easy to detect due to common "signature acknowledgement numbers"; the TCP header ACK field was always a fixed number, usually 674719802 or 674711610. Figure 7 shows a Reset probe from two attackers that can trivially be detected due to the signature Ack number.
 
 

17:40:45.87 hook.24408 > target1.1457: R 0:0(0) ack 674719802 win 0
17:40:53.03 hook.33174 > target2.1457: R 0:0(0) ack 674719802 win 0
17:41:12.16 hook.36250 > target3.1979: R 0:0(0) ack 674719802 win 0
17:43:37.61 router > hook: icmp: time exceeded in-transit
17:43:43.14 hook.44922 > target4.1496: R 0:0(0) ack 674719802 win 0
17:42:30.40 grin.3532 > target1a.1167: R 0:0(0) ack 674719802 win 0
17:42:40.58 grin.33233 > target2a.1797: R 0:0(0) ack 674719802 win 0
17:44:28.84 grin.52504 > target3a.1634: R 0:0(0) ack 674719802 win 0
17:47:52.58 grin.46657 > target4a.2121: R 0:0(0) ack 674719802 win 0
17:47:52.70 router > grin: icmp: time exceeded in-transit


Figure 7. Example of "signature acknowledgement numbers".


Unfortunately, some of the more recent probes have random acknowledgement numbers. Probes of this type have been observed from at least fourteen different cooperating Internet addresses, primarily ISPs, all within a twenty-four hour period. And of course, how do you sort between the scans and second order effects?

Many people want to label all Resets as a second order effect and just not deal with it. This is foolish; when there is this much smoke, find the fire. These probing systems are working together to map multiple target sites. Reset traces from all over the world provide strong evidence that this activity is a long-term, Internet wide effort. The scan rate from some attacks is as low as 2 packets per day per target site, well below commonly set thresholds for scan detectors.

This begs the question: "Without a signature Ack how can we detect Reset scans?" In this case, the primary signature is the Reset code bit set with no other activity from that source, (such as an active open [SYN] from the source or the target). An obvious solution is to keep track of the state of each TCP connection and alarm: if a Reset, Syn/Ack, or Fin is detected without the active open. However, this solution can be compute intensive for large networks. The answer lies in less expensive mechanisms; namely scan detectors.

Inverse mapping is best detected over a longer time window, such as an hour, or even a day. In this case, we can test for an external host making connections to n internal hosts where n is a small value, (Shadow systems default to 7, but this is configurable). This technique will detect any scan that meets or exceeds the tally trigger over the time window. Figure 8 shows how SHADOW displays detected scans.


Hourly Tally Counter


8 192.168.2.1 hook
7 172.20.20.20 grin
7 10.32.21.12 false_positive.net


Figure 8. SHADOW scan detection output.


The advantage of such a technique is that it will detect any scan, so it will detect scans for which there is no signature. The disadvantages of this approach are threefold: scans below the tally trigger point will be missed, the scan detector has no provision for a focusing filter, collecting low and slow probes on an hourly basis is a manual technique and therefore prone to error.

Some attackers are patient enough to scan at rates as low as two packets per day; in these cases an hour clearly is not a reasonable time window. Figure 9 illustrates example output from a 24 hour scan detection tool called look4scans.pl. This tool was part of the version 1.5 Shadow software release.


10.9.8.7 : Reset.host.net
10.9.8.7 > 192.168.103.90 : R
10.9.8.7 > 192.168.114.15 : R
10.9.8.7 > 192.168.122.80 : R
10.9.8.7 > 192.168.137.149 : R
10.9.8.7 > 192.168.157.224 : R
10.9.8.7 > 192.168.164.44 : R
10.9.8.7 > 192.168.174.161 : R
10.9.8.7 > 192.168.201.148 : R
10.9.8.7 > 192.168.202.85 : R
10.9.8.7 > 192.168.204.79 : R
10.9.8.7 > 192.168.213.156 : R
10.9.8.7 > 192.168.29.38 : R
10.9.8.7 > 192.168.41.157 : R
10.9.8.7 > 192.168.43.145 : R
10.9.8.7 > 192.168.45.174 : R
10.9.8.7 > 192.168.85.28 : R
10.9.8.7 > 172.20.107.109 : R
10.9.8.7 > 172.20.113.214 : R
10.9.8.7 > 172.20.115.6 : R
10.9.8.7 > 172.20.13.168 : R
10.9.8.7 > 172.20.140.69 : R
10.9.8.7 > 172.20.145.25 : R
10.9.8.7 > 172.20.191.30 : R
10.9.8.7 > 172.20.205.137 : R
10.9.8.7 > 172.20.207.56 : R
10.9.8.7 > 172.20.224.98 : R
10.9.8.7 > 172.20.23.185 : R
10.9.8.7 > 172.20.31.98 : R
10.9.8.7 > 172.20.41.248 : R
10.9.8.7 > 172.20.42.114 : R
10.9.8.7 > 172.20.62.140 : R
10.9.8.7 > 172.20.71.217 : R
10.9.8.7 > 172.20.84.178 : R


Figure 9. Example ‘look4scans.pl’ output.

Slow coordinated attacks are particularly difficult to detect using these methods. If the attackers can guess your detection threshold they can ensure that no single IP address sends enough packets to trip that threshold. Unless the attackers are foolish enough to include some other signature in the scan, these will be particularly difficult to detect.


4.4. Resets as an indicator of TCP session hijacking
 

The nmap scanning tool released December 1998 has a sequence number evaluator as part of its most basic functionality, so hijack will be with us for a while yet! The idea is to find an active connection, and predict the sequence numbers on both sides of the connection. Hit the side you don’t want to penetrate with a Reset to break off the connection from their point of view. Assume the connection and attack the other side. The signature for this attack is the correct sequence number and wrong IP address.


4.5. ISS RealSecure kill


We have seen this only twice. If an ISS RealSecure thinks the site it is protecting is under attack, it may generate a connection Reset. In this case, the packet contains the ID Number of the RealSecure engine.
 

4.6. Deception


As stated earlier, several freely available scanners can generate Resets with spoofed addresses simply as a smokescreen. They accomplish no purpose except possibly to consume analyst and CIRT resources.


How big of a problem is this? There are a few areas of concern:


1. If some portion of the inexplicable Resets is related to mapping attempts, then external actors are gaining intelligence about the networks that we are supposed to defend. In this case, the solution is to implement a firewall that can drop these packets.

2. Though we aren’t particularly bothered by the second order effect problem, it is bad from a public perception standpoint if it is widely thought that our sites are attacking other sites, since our address space is being used.
 

5. SFRP scans
 

In the previous scan examples, the attackers came to us. This is not always the case. Scanning can happen when we visit the attacker. In this case, malformed packets with SYN, Reset, FIN and Urgent are detected coming from web servers to the browsing client. The most common pattern is one SFRP (SYN/FIN/Reset/PUSH) packet sent to each browsing client per session. Sometimes SRP’s are also sent, Figure 10 illustrates the pattern.


10:47:36.61 media.com.2048 > target.48579: SFR 2842082:2842590(508) ack 2642669109 win 768 urg 2571 (DF)
11:23:42.97 media.com.2048 > target.47720: SFP 4820865:4821409(544) win 3840 urg 2571 (DF)
13:49:44.33 gm.com.49608 > target.49606: SFP 7051:7607(556) ack 2147789506 win 7768 (DF)
13:49:44.72 gm.com.22450 > target.1591: SFRP 2038:2074(36) ack 116065792 win 0 urg 0 (DF)


Figure 10. TCP stack analysis.

Figure 11 shows related activity that is not from the original site but is within the same general timeframe. The stimulus here is the client visiting the web server. These are examples of what comes back. Each client gets at least one packet and as many as four, (with different combinations), during a visit to a web server.
 
 

12:18:46.25 im.com.5500 > target.1137: SFP 3241821:3242365(544) win 13234 urg 55134 (DF)
13:37:30.33 im.com.22555 > target.22555: SF 8440982:8441538(556) win 10240 (DF)
14:52:57.45 scannernet.30975 > target.16940: SFRP 2029994540:2029995068(528) ack 2029994540 win 16940 urg 16940 <[bad opt]> (DF)
14:53:01.63 scannernet.30975 > target.556: SFRP 2029978156:2029978684(528) ack 2029978156 win 556 urg 556 <[bad opt]> (DF)


Figure 11. Cooperative tcp stack analysis example.

We have a pattern we have never seen before and it occurs during transactions with multiple web servers from multiple domains. During the height of this technique, in October 1998, over twenty web-servers from a very large ISP were exhibiting this behavior.

After tracking this for several weeks, we were still leaning toward considering this benign, perhaps some error in the web-server code. However, two weeks later, probes were observed from the same address family that did not have any stimulus (no one visited a web page). These non-stimulus caused probes were targeting DNS and mail servers. At this point, the activity was considered hostile. Since multiple web-servers were performing these probes in concert, this was also considered a coordinated attack.
 

6. Target based analysis


Until now, every example has shown multiple attackers, multiple targets, and we have focused on the activity of the inbound packets and the analysis of that activity. Now let’s consider a different analysis technique: examining the targets. One of the factors that helped us understand the fact that Reset scanners were working together was that they did not duplicate targets; each system probed was unique. Furthermore, many of the attackers would scan three hosts from one site and twelve from a second and this pattern would continue day after day.

Infrastructure systems such as DNS and email servers are a good starting place for target analysis. In a given week, a large number of the total attacks are usually against these types of systems. In figure 12, the traces show attacks that come from vastly different IP addresses. These IP addresses originate from Australia, Asia and the USA, but all include the same targets, and occurred over a single weekend. "Whoops" isn’t really a name server or email server, though it was erroneously listed as one in a DNS table.

Also, please note that SourceA and SourceB have different IP address numbers. Since this is TCP, the exploit cannot work if they spoof the source address. One of the probe sets could be a decoy; it could be a multi-homed host, or it could be two systems working together. Please note the packet arrival times to see how related the first two scans appear to be and also the static source port. The third trace has a significant difference from the first two; the source port pattern indicates two processes. In the following example, we would assume that the first two traces are related and the third trace is a different actor.

One of the themes of this story is that the events of interest we classify as coordinated attacks are often detects that we had never seen before. Suddenly, we see it from (or to) multiple locations. To detect and classify a coordinated attack, it really helps to have a database of all traffic and techniques to complement your signatures. Without a database of traffic that covers a time window of at least a couple months, there is no way to determine whether this activity has been going on and simply hasn’t been detected, or if it is a new pattern. Recently, we tested a pattern that had been detected by an analyst at another site. We were sure we had never seen it before. Wrong! What really stung us was that one of the attackers had spun this attack off of source port 7 (echo), something a good analyst should never miss. Oh well.


If you can only detect and examine traffic that matches your signature set, then how can you detect a new, or novel attack?


06:10:56.53 SourceA.10053 > NS1.111: S 1935318310:1935318310(0) win 242
06:32:42.15 SourceA.10053 > NS2.111: S 552822870:552822870(0) win 242
06:54:27.32 SourceA.10053 > MAIL1.111: S 944974642:944974642(0) win 242
07:16:12.73 SourceA.10053 > MAIL2.111: S 3045099303:3045099303(0) win 242
07:37:58.16 SourceA.10053 > Whoops.111: S 323776127:323776127(0) win 242
 
06:12:33.28 SourceB.10053 > NS1.domain: S 992750649:992750649(0) win 242
06:34:18.66 SourceB.10053 > NS2.domain: S 3455530061:3455530061(0) win 242
06:56:04.046 SourceB.10053 > MAIL1.domain: S 1895963699:1895963699(0) win 242
07:17:49.44 SourceB.10053 > MAIL2.domain: S 2485794595:2485794595(0) win 242
07:39:34.811723 SourceB.10053 > Whoops.domain: S 3785701160:3785701160(0) win 242
 

08:01:20.23 SourceB.1025 > NS1.imap: S 1471781129:1471781129(0) win 512
08:23:05.64 SourceB.21053 > NS2.imap: S 4110489384:4110489384(0) win 512
08:24:50.96 SourceB.1026 > MAIL1.imap: S 1486592867:1486592867(0) win 512
08:23:05.64 SourceB.21055 > MAIL2.imap: S 1112489384:1112489384(0) win 512
08:44:50.96 SourceB.1028 > Whoops.imap: S 0486592777:0486592777(0) win 512
 

Figure 12. Target based analysis.
 
AttackerB.6667 -> 192.168.229.72.1437, 1 packet
AttackerB.6667 -> 192.168.229.72.1437, 2 packets
AttackerB.6667 -> 192.168.229.82.1437, 1 packet
AttackerB.6667 -> 192.168.229.82.1437, 2 packets
AttackerB.6667 -> 192.168.229.95.1437, 1 packet
AttackerB.6667 -> 192.168.229.95.1437, 2 packets
AttackerB.6667 -> 192.168.229.6.1437, 1 packet
AttackerB.6667 -> 192.168.229.6.1437, 1 packet
AttackerB.6667 -> 192.168.229.79.1437, 1 packet

AttackerB.6667 -> 192.168.229.79.1437, 2 packets
AttackerB.6667 -> 192.168.229.45.1437, 1 packet
AttackerB.6667 -> 192.168.229.45.1437, 2 packets

AttackerC.139 -> 192.168.229.28.1437, 1 packet
AttackerC.139 -> 192.168.229.28.1437, 1 packet
AttackerC.139 -> 192.168.229.28.1437, 1 packet
AttackerC.139 -> 192.168.229.122.1437, 1 packet
AttackerC.139 -> 192.168.229.122.1437, 1 packet
AttackerC.139 -> 192.168.229.122.1437, 1 packet
AttackerC.139 -> 192.168.229.122.1437, 1 packet
AttackerC.139 -> 192.168.229.28.1437, 1 packet
AttackerC.139 -> 192.168.229.28.1437, 1 packet
AttackerC.139 -> 192.168.229.28.1437, 1 packet
AttackerC.139 -> 192.168.229.75.1437, 1 packet
AttackerC.139 -> 192.168.229.75.1437, 1 packet
AttackerC.139 -> 192.168.229.75.1437, 1 packet


Figure 13.
 

Figure 13 shows the traffic from an event that took place over a four-day weekend. In this case, multiple addresses began to target a specific destination port. In the first trace, notice the one packet two packet pattern and the source port of 6667 (IRC). Attacker C has a different pattern or their IDS interprets it differently. For two months different IP addresses were probing this site on the same destination port. No other sites with which we share information have detected this activity.

7. Conclusions
 

The examples shown in this paper represent a change in the kinds of attacks and probes we track. Previously, it had been common for a single attacker to target multiple sites. Now we see indications of multiple attackers working together to target either single sites or multiple sites. We can use all of the analysis techniques we have learned to find differences or similarities in delivery mechanisms. These may help provide clues as to the number of discrete attackers involved, especially when we have data across a fairly large time window, such as a week or longer.

It should be noted that these techniques are starting to be widely used and the attacker community is building decoy techniques into commonly available tools. However, we are not aware of a widely available distributed scanner, or exploit delivery system. Additionally, these coordinated attacks display a significant amount of variability making them difficult to detect with signature-based algorithms.
 

There are three obvious purposes for coordinated attacks and probes: stealth, firepower, and intelligence gathering.


7.1. Stealth


By working from multiple IP addresses the attackers achieve a smaller per-IP signature and are more difficult to detect through conventional means. In addition, stealth is enhanced by the development of new hard-to-detect probing techniques such as Reset scans.


7.2. Firepower


By coordinating multiple attacking IP addresses, the attackers will be able to deliver more exploits to destination hosts in a smaller period of time. Furthermore, the defensive technique of blocking an attacker IP, also known as shunning, will be less effective. A single attacking entity can utilize multiple non-related Internet addresses for the attacks. This is especially true for denial of service attacks; most of these do not rely on a connection being made, so the probability of the address being spoofed is very high. Some of these coordinated probes and scans we detect today may be practice runs for future larger scale attacks. After a new exploit is discovered, there is often a limited "window of opportunity" for its use; usually until countermeasures are developed.


7.3. Intelligence gathering


As discussed in the coordinated traceroute example, by working from different IP addresses on different backbones against the same target, it is possible to obtain data that is impossible to obtain from a single source IP scan or probe. These data may include shortest route data, (i.e. packets from source A arrive faster than from source , or even potential backdoors, (i.e. packets from source A can gain access to hosts that source B can’t see). This type of data can be used to optimize future scans, probes, or attacks. It could also be used to isolate a target site by attacking the links it uses to communicate with the outside world.

The SFRP example shows how a network of servers can simply wait for the customer to come to them. The progress in TCP stack analysis is very impressive and we wouldn’t be surprised to see this capability become integrated into commercial server software as one more method of gathering intelligence about the systems that visit the server.


8. Final words


Analysis of the network traffic collected by the SHADOW team indicates that new exploit delivery mechanisms are being developed and refined. These techniques employ multiple attackers and decoy hosts in an attempt to increase stealth, firepower, and reconnaissance.

Much of the network traffic discussed in this paper is definitely the result of coordinated attacks. However, a small portion can also be attributed to deception techniques and second order effects. Therefore, it is extremely important for the analyst to differentiate between the two possible causes of suspicious network traffic, and react accordingly. To this end, we have discussed the motivations for coordinating attacks, and also provided examples of each attack type. Methods for detecting this coordinated activity have been illustrated when possible.

Reference:

SHADOW is a freely available, public domain intrusion detection system. Information and software for the SHADOW System can be downloaded from the following website:

http://www.nswc.navy.mil/ISSEC/CID

About the authors
K. K. Mookhey is Founder & CTO of Network Intelligence India Pvt. Ltd. (www.nii.co.in), which provides information security consulting services including security audits, penetration testing, security design, application audits, and security training. He has written a number of articles and whitepapers on information security, and is also responsible for NII's research initiatives.
Nilesh Burghate is an Information Assurance Consultant with NII, and his interests include penetration testing, IDS signature writing, intrusion analysis and detection and forensics. The results from his team's research efforts provide direct input to NII's Security Alerting service.

    $ telnet www2.securityspace.com 80
    Trying 216.201.108.18...
    Connected to www2.securityspace.com.
    Escape character is '^]'.
    GET /sample.html HTTP/1.0

Having issued the request to retrieve the page sample.html, the server responds with the HTTP header and an HTML page.

    HTTP/1.1 200 OK
    Date: Fri, 04 May 2001 20:08:11 GMT
    Server: Apache/1.3.12 (Unix)
    Connection: close
    Content-Type: text/html

    <HTML>
    <HEAD></HEAD>
    <BODY>Sample Page</BODY>
    </HTML>
    Connection closed by foreign host.
    $

Now let's consider the exact same response received from a poorly configured IIS server:


    HTTP/1.1 200 OK
    Server: Microsoft-IIS/4.0
    Content-Location: http://10.1.1.1/sample.html
    Date: Wed, 11 Apr 2001 07:22:38 GMT
    Content-Type: text/html
    Accept-Ranges: bytes
    Last-Modified: Tue, 09 Jan 2001 21:41:34 GMT
    ETag: "b43f97ef847ac01:4096"
    Content-Length: 55

    <HTML>
    <HEAD></HEAD>
    <BODY>Sample Page</BODY>
    </HTML>
    Connection closed by foreign host.
    $