Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Cisco Employee

Signature question - Modified LOKI ICMP - string 6302

We are seeing multiple hits on sig. 6032 description=Modified Loki ICMP tunnelling

These are coming from 3 different source ips.

An HP openview platform, Compaq Insight, and VPN contivity management interface.

They are going to hundreds of network devices.

Could this be normal management traffic triggering these events. Or maybe 3 management platforms have been compromised!

Sub signatures are 1144, 3904 and 57418

Any idea where to read up on the sub signatures.

Thank you

New Member

Re: Signature question - Modified LOKI ICMP - string 6302

This can be normal management traffic. We have several active ICMP devices for various reasons which trigger 6302 reliably.

Cisco Employee

Re: Signature question - Modified LOKI ICMP - string 6302

I'm going to asssume you are running a 3.0 release of the code.

The 6302 Loki signature is triggered by an imbalance in the number of echo replies to echo requests between a fixed src and destination. Additionally these replies must have the same sequence numbers as the associated request had, and at least one must have a different payload than the associated request.

This fits the mold of something that is using ICMP echo request/replies as a covert channel for communication. The standard implementation of ICMP would call for a one to one correlation between replies and requests and the payload in the replies should be the same as the request, hence the name Echo request/Echo reply.

Unfortunately several companies for various benign reasons have decided to use ICMP as a way of communicating. These appear to be covert channels and they are, however they are benign in this case.

The subsignature IDs are the ICMP sequence numbers of the traffic that we were following that caused the alert. This would allow you to sniff your ICMP traffic and match up the offending ICMP traffic to the alarm so that you could decide if the data being communicated in the channel was benign or if it was a potentailly compromised host.

Hope this helps to shed more light on this for you.