cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
595
Views
0
Helpful
8
Replies

Sig 6302 Loki Alarms on Spyware?

ddinh
Level 1
Level 1

I have many incidents lately on windows boxes that are tripping this signature. It can't be a Lokid server all sending info to one ip address: 207.189.143.11. I thought only unix boxes run Lokid server so our security team looked up the ip address (a multi-media research co. in Oregon) and Loki on Google. It points to a spyware called Attune by Aveo.com. Currently, truste.org is after them for privacy violation. (http://www.truste.org/news/padvisories/users_aveo_seal.html)

Are there anyone experiencing this on their Cisco NIDS? or Am I running off on a tangent?

Thanks in advance for any input.

8 Replies 8

brenden
Level 1
Level 1

Guess what? I have had a few boxes from our network going to that IP, and we have been trying to investigate why.

You definitely have gotten some information to us that is valuable. Thanks!

Same here. Dating at least back to Feb 11, the last alarm firing Last Friday, March 8.

I've tried looking for this software and could not find it. The company website (www.aveo.com) is "under construction". If anyone seeing this alarm is willing to share a traffic trace, we'd be happy to look at it. You can send the trace(s) to mcerha@cisco.com. Also, a possible workaround is to use a RecordOfExcludedPatterm for the Loki alarm with the offending IP as the source.

This is the first I've heard of it, and did some searching on the net.

Looks like attune was installed by default in some commercial software packages.

It looks like it was supposed to periodically check your configuration against a database of some kind at aveo.com in order to warn the user of possible problems.

Cosmi shipped it as part of their software.

Cosmi has a FAQ about attune on their web site which talks about disabling and deinstalling it:

http://www.cosmi.com/support/attune_faq.htm

Looks like even McAfee had an alliance with them in the past:

http://www.mcafee.com/aboutus/press_room/press_releases/pr12209902.asp

So you may want to check your systems and see if it was loaded as part of another software program.

It could also be some other program and not attune that is generating these packets.

If you can verify that the ips in your network have attune loaded, and if you turn off attune the alarm stops firing then you are likely correct that it is attune.

You'll have to decide then on your own whether or not to disable or even de-install attune.

If you leave it enabled you would need to Exclude the loki signature where aveo.com's ip address is the source of the alarm, and possibly a second Exclude where aveo.com is the destination of the alarm since the address may be the source in one firing and a dest in another firing.

A sniffer trace of the icmp packets in a libpcap format as mcerha requested would be very helpful.

If you don't have a sniffer that generates libpcap formatted files (like tcpdump) , then you can:

1) set the action for loki to iplog, and set it to iplog for at least 5 minutes (the default of 15 is also fine)

2) let the alarm fire.

3) wait for the time of the iplog

4) set the action for loki back to what ever you had it before (likely none)

5) send mcerha the iplog file(s) from the /usr/nr/var/iplog/new directory for the ip address that fired the loki alarm. (there may be several)

(If the files are large then you can use a program like ethereal or tcpdump to read in the file and only write out the icmp packets from the file. You can then compress it if you like.)

Upon looking at the traffic from several people, I found that the spyware in question sends a normal looking ping to the IP address 207.189.143.11. The strange part is it responds with two or three ICMP echo responses. Our Modified Loki signature looks

for an imbalance in ICMP echo requests to replies. The current threshold is set to 3 replies to a

echo to fire the alarm. This threshold is currently not customer tuneable. One possible cause for the

numerous ICMP echo replies could be if the IP is the frontend for a load balancer of some kind. We have seen this before. I will update our NSDB

documentation to reflect this benign trigger. You can safely eliminate the alarm by using a RecordOfExcludedPattern for 6302 with 207.189.143.11 as a source address.

This alarm fires with the destination of 207.189.143.11, not the source.

>RecordOfExcludedPattern for 6302 with 207.189.143.11 as a source address.

Would you please specify how one would exactly do this?

Thank you,

Chris

In CSPM, go to the Filters tab and created an entry in the Advanced Filters.

The Advanced Filters are written out as RecordOfExcludedPattern entries in packetd.conf.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: