BACKDOOR superspy 2.0

Try wireshark or another analyzer and see what the PC is doing.

Barry

I get that message in my daily reports about once a fortnight and always from the same user. It only happens once or twice so it is very hard to lay a trap to catch it.

Ian M

If the port is always the same, then you could leave a sniffer running only on that port.

Barry

I just got this also. I scanned both boxes as the origin and destination are both on my network(albeit across VPN from each other) and I came up with nothing.

False positive maybe?

-Scott

You could always check to see where that IP (the 80.x.x.x address in the log there) is exactly... If it doesn't relate to a legitimate site, etc. that the user uses, then it could be a real issue.  Also, why was it allowed to get out, you must have a packet filter rule misconfigured somewhere... I don't know of any common service that sits on port 3724 --- maybe you have one of those "any->any->any" rules that should be turned off?

You could always check to see where that IP (the 80.x.x.x address in the log there) is exactly... If it doesn't relate to a legitimate site, etc. that the user uses, then it could be a real issue.  Also, why was it allowed to get out, you must have a packet filter rule misconfigured somewhere... I don't know of any common service that sits on port 3724 --- maybe you have one of those "any->any->any" rules that should be turned off?

The same and quiet a lot from two users from my LAN:
---------------------------------------------------
"Intrusion Protection Alert
An intrusion has been detected. The packet has *not* been dropped.
If you want to block packets like this one in the future,
set the corresponding intrusion protection rule to "drop" in WebAdmin.
Be careful not to block legitimate traffic caused by false alerts though.
Details about the intrusion alert:
Message........: BACKDOOR superspy 2.0 beta runtime detection - file management
Details........: http://www.snort.org/pub-bin/sigs.cgi?sid=8477
Time...........: 2007:08:17-13:55:49
Packet dropped.: no
Priority.......: 1 (high)
Classification.: A Network Trojan was detected
IP protocol....: 6 (TCP)
Source IP address: 10.2.4.240

Source port: 3354 (suitjd) (Changing )
Destination IP address: 84.246.93.184 (Changing )

Destination port: 6881 (Changing )
---------------------------------------------

Any Idea why The packet has *not* been dropped?

Hi All,

1) I also often see backdoor rules detected on my system.
    After doing a lot of test, I found that if you have Client Security such as F-Secure Client Security in my case which also have its own POP3 Virus Scanning feature, sometime these communication can cause IPS Backdoor alerts.

2) The IPS Rules default is warn only. You need to configure to drop.
    Personally I configure to Drop everything and seeing which breaks  then I disable those rules.

I am affected by the following and I can download my pop3 mails if I disable my f-secure client security e-mail scanning.

But I rather disable these rules and enable the e-mail scanning on f-secure.

I am sure the system is not compromised as I rebuilded a machine and this occurs.

It does Not occur with each and every send and receive.

BACKDOOR fkwp 2.0 runtime detection - connection success - ID 6033


BACKDOOR fkwp 2.0 runtime detection - connection attempt server-to-client - ID 6031

BACKDOOR superspy 2.0 beta runtime detection - file management - ID 8477

Hi All,

1)  I found that if you have Client Security such as F-Secure Client Security in my case which also have its own POP3 Virus Scanning feature, sometime these communication can cause IPS Backdoor alerts.

2) The IPS Rules default is warn only. You need to configure to drop.
    Personally I configure to Drop everything and seeing which breaks  then I disable those rules.

1. I have about 400 stations with KAV.
If it would be the reason for Supper spy,  i woul expect to see more of this behavior.

2. I couldn't find where to "Drop" the Superspy. [:S] 
Network Security » Intrusion Protection-Attack pattern set to drop (I don't use all of them).  Port scan - Drop
Here is the log:
/var/log/ips.log:2007:08:17-18:33:13 (none) barnyard[6163]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="alert" reason="BACKDOOR superspy 2.0 beta runtime detection - file management" group="510" srcip="10.2.4.240" dstip="84.246.93.184" proto="6" srcport="1074" dstport="6881" sid="8477" class="A Network Trojan was detected" priority="1" generator="1" msgid="0"

Goldy,

Go to network security/Intrusion Protection/Advanced. Click the Question symbol on top off your Astaro screen for Help.
Look for advanced:
Look-up the following sentence:
Rule ID: Enter the ID of the rule you want to modify. To look up the rule ID, go to the list of IPS rules at the Astaro Web site (available both in HTML and XML format). In addition, they can either be determined from the IPS log or the IPS report.
Select one of the Links, then you can search for "backdoor superspy 2.0" with CtrL/F and find the ID-number!
Under advanced settings you can make Manual rule modification

Thnks SilverOne.

Got it...

I'm not sure if it's meant to be, but the Notify sticks to "off".
Even changing it to "on", after saving, it goes back to "off".

Goldy,

Until now i couldn't find why this behaviour works that way? Strange....
maybe somebody else???

Hi.

I have added a rule in the Network Security » Intrusion Protection » Advanced, to "drop" the superspy (2101 Action: Drop, Notify off).

No successes.  I'm still getting "The packet has *not* been dropped"

Here is the log :
/var/log/ips.log:2007:08:20-16:30:12 (none) barnyard[23967]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="alert" reason="BACKDOOR superspy 2.0 beta runtime detection - file management" group="510" srcip="10.2.1.220" dstip="85.29.233.238" proto="6" srcport="3783" dstport="34174" sid="8477" class="A Network Trojan was detected" priority="1" generator="1" msgid="0"

Any Idea?

Goldy, I've had problems with the IPS not disabling rules as it is supposed to as well, I've started a ticket; they blame the issue on bad sourcefire rules --- I think it goes deeper than that.  I have not gotten an update on the case in quite some time, i'll check on it.  If you have maintenance, I'd suggest opening a case, as they say, the squeeky wheel gets the grease...

I see this a lot when there's a bittorrent client downloading - looks like some others in this thread are seeing that too (port 6881) - could it be legitimate bittorrent traffic triggering a false positive on this rule?