Understanding Why Signature 6794/0 Fires

[natehausrath]

Hello all,

This is a signature that detects a "CA BrightStor ARCserve Backup Listservcntrl ActiveX Overflow".

As I understand it, this is a meta signature that fires when 6794/1 and 5477 both trigger. Alerts have showed up a couple times today, but the packet data in MARS associated with them do not appear to match correctly with the component signatures.

For example, 6794/1 looks like it tries to match a regex for this key: BF6EFFF3-4558-4C4C-ADAF-A87891C5F3A3

However, in the packet data, this does not occur anywhere. So I'm unsure if there is packet data that I cannot see (but I should be able to see!), or if it is firing incorrectly, or perhaps I just don't understand something!

Thanks for any help!

[Christopher Bell]

We had to disable this signature and 6497/0 while we try and figure out what is going on. This signature was firing just trying to read this forum page! Any info would be appreciated.

I did notice that this showed up about the same time we started running XO soft on our network. The 'victim' IP's however are all client machines for the most part - user boxes not even on the same subnet as our server block.

[wsulym]

6794-0, a revised version is going out in s405.

In s401, there was an inadvertent change to the all components required field, it should be set true, that will be seen in s405.

[Christopher Bell]

Sorry - I don't understand what that means as it relates to what is happening to us now...

Can we disregard these alerts? Is it ok to disable the signature for the time being? Can you expound a little more (in layman's terms) if possible.

[wsulym · Accepted solution]

Sure.... You can disregard these alerts for now or modify 6794-0 and set the all components required to *true* or disabled 6794-0 until s405 release, then re-anable.

Whats happening, is with the all components required set to false, when either 6794-1 or 5477-2 fire, 6794-0 will fire.

[natehausrath]

Makes sense! Thanks for your response!

[feyrerberbee]

This signature continues to fire in the latest release of the signatures, has the issue in the signature been corrected?

[wsulym]

yes, it has, the change was in s405, the "all components required" field was set to true. i just checked one of my dev sensors (running 6.0.5 e3 s407) and the expected values are there.

the only thing i can think of why you might not see it is that you possibly have a modification to that signature that trumped the default values from being installed.