capture it, and possibly crack the password file. You can find more information on Loki at www.phrack.com issue 49, article 6.

The danger in this whole scheme is that a seemingly innocuous protocol is being used to do some very sophisticated and potentially damaging exchanges. Again, ICMP was never intended to support applications such as this. My advice to the intrusion analyst is to regard ICMP traffic

with heightened suspicion and to stop just shy of outright paranoia.

Unsolicited ICMP Echo Replies

Now, try your hand at some analysis and put into practice some of the theory you just learned

about ICMP exploits by examining the output that follows: reply.com >192.168.127.41: icmp: echo reply

reply.com >192.168.127.41: icmp: echo reply reply.com >192.168.127.41: icmp: echo reply reply.com >192.168.127.41: icmp: echo reply reply.com >192.168.127.41: icmp: echo reply reply.com >192.168.127.41: icmp: echo reply

What you observe here is a host, reply.com, sending the 192.168.127.41 host ICMP echo reply traffic. This would not be unusual if the 192.168.127.41 host had sent an ICMP echo request eliciting these responses. However, this is not the case; no outbound ICMP echo requests were sent from 192.168.127.41. Why might someone initiate such activity? You learn possible reasons in the next three sections.

One thing to keep in mind is that for this kind of activity to be detected, you must have some kind of IDS or supporting software capable of maintaining state. This means that you must be able to determine whether any prior traffic had issued ICMP echo requests. Many IDSs do not maintain state information and cannot detect such anomalous activity. Let's examine some of the possible theories that might explain this anomalous activity.

Theory 1: Spoofing

The first theory poses the possibility that you see this traffic because someone has borrowed the source IP 192.168.127.41 and has issued ICMP echo requests to reply.com using the spoofed source IP; reply.com then replies to the real 192.168.127.41 IP address. If you saw ICMP echo replies from many other hosts on the same network as reply.com, you could be a Smurf target.

A dramatic increase in spoofing activity has arisen, so this is the most common explanation for this type of activity. Typically, when you have witnessed unsolicited ICMP echo replies that appear to be using your spoofed source IPs (in this example, 192.168.127.41), you might see other unsolicited activity from the same intermediate host (in this example, reply.com). You usually don't see this activity in isolation—you might see these replies going to many different 192.168.127 hosts, not just a single reply multiple times.

Theory 2: TFN

A second theory involves the TFN attack. You learned that the TFN master communicates with its TFN daemons using ICMP echo replies.

Therefore, another possibility is that the host receiving the unsolicited ICMP echo replies, 192.168.127.41, has become a victim TFN daemon. Although the ICMP identification value field is used to direct the daemon host to attack the victim, the exact value found in this field might not be predictable if the attacker changes the default source code. The more obvious way to determine whether the 192.168.127.41 has become an unwitting TFN daemon is to examine the outbound activity from 192.168.127.41 after receiving the ICMP echo requests. If it sends a flood of unexplained traffic outbound, it is possibly participating in a TFN attack.

Theory 3: Loki

The final theory is that this could be an exchange between a Loki client and a Loki server. When Loki traffic is exchanged, it might not have a pattern of each ICMP echo request generating a reply. It is possible for the Loki server to respond with multiple ICMP echo replies to a single ICMP echo request.