[Oisf-users] [Emerging-Sigs] More "Unknown type of Driveby Sigs"

Victor Julien victor at inliniac.net
Sun Nov 27 16:16:18 UTC 2011


I wonder if this really belongs in the IDS engine itself. A SIEM like
facility should be a better place I think. For example,  in a system
like Sguil you could also remove the noalert from the first sig and have
it generate the alert. Then in Sguil set it to "autocat" so it doesn't
show up in the console. When the second sig matches you will be able to
see what else fired for that flow and then it will show up giving the
analyst all the info.

Thoughts?

On 11/26/2011 07:46 PM, Kevin Ross wrote:
> No I don't think so. If I was tracking flows so I do this:
> 
> 1) I set flowbit for a client doing a GET for a PDF from an exploit kit (we
> aren't sure at this point because of the format if it is genuine so we
> noalert it
> 2) Second Sig then checks flowbit and then sees PDF coming down so it
> alerts.
> 3) Third sig as you suggest checks both flowbits and generates an alert.
> However it would alert on the same thing as the second one or possibly a
> later packet (I think) as it can't back track and generate an alert for
> stage 1 as it is at a different part of the flow. However we may want to
> alert on stage 1 due to looking at websites, sources who may be
> participating in other parts of the activity (I know you can get logs for
> snort and suricata to see what sites and URI did stage 2 but stage 1 may
> have been on a different site.
> 
> Regards, Kev
> 
> 
> On 25 November 2011 23:50, Victor Julien <victor at inliniac.net> wrote:
> 
>> On 11/25/2011 08:47 PM, Kevin Ross wrote:
>>> actually that just gave me an idea for something that could be put into
>>> Suricata and that is the option to set a flowbit in a kind of noalert
>> state
>>> for the second stage and then only if the second stage fires then an
>> alert
>>> is generated for the noalert type sig. That means in this case we would
>> be
>>> able to suppress noisy FP sigs but we then consider the second part (the
>>> download) to be indicative of an exploit kit and so we may want to
>> generate
>>> an alert for the first part only if confirmed. So it is a noalert unless
>>> the next sig fires then alert on this too.
>>
>> This would be achieved by having both rules set a flowbit and then have
>> a third rule check for both bits, right?
>>
>> --
>> ---------------------------------------------
>> Victor Julien
>> http://www.inliniac.net/
>> PGP: http://www.inliniac.net/victorjulien.asc
>> ---------------------------------------------
>>
>> _______________________________________________
>> Oisf-users mailing list
>> Oisf-users at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
> 


-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------




More information about the Oisf-users mailing list