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

Fri Nov 25 19:55:49 UTC 2011

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.

On 25 November 2011 16:19, Martin Holste <mcholste at gmail.com> wrote:

> One of the long-term benefits to improved kit detection would be more
> statistically accurate records of what subnets, ASN's, hosting
> providers, and ad providers/referrers. are participating in what
> stages.  That would really strengthen future IP reputation
> assessments, which can feed back into the detection/prevention phase.
>
> On Fri, Nov 25, 2011 at 10:02 AM, Kevin Ross <kevross33 at googlemail.com>
> wrote:
> > The idea is that we deal with exploit kits and there behaviours by
> detecting
> > the exploits. How this is done is:
> >
> > 1) We set a flowbit on sigs such as redirections to landing pages for
> > exploit kits, obfuscation methods etc. Now some of these on there own may
> > false positive and even if the risk is high we can do a noalert so it
> will
> > set the flowbit but not generate an alert. Not duplicating the sig at all
> > but modifying sigs such as "request to blackhole for EXE" or whatever
> these
> > exploit sigs may be to have the flowbit.
> > 2) We then check for the flowbit being set on PDF, EXE, Java, Flash
> > downloads, Office documents etc - common exploit kit exploits - and if we
> > see it then we alert. This means we can set all sorts of things for the
> > first stage including common exploit kit behaviours like obfuscation
> methods
> > but that may FP and then just silence them with noalert and try and get
> the
> > actual exploits, binary drops etc.
> >
> > What this means is we can have reliable rules for setting the flowbit
> still
> > alert but we get that extra bit of intel about what may have been
> exploited
> > (we don't even care about the exploit either so they can obfuscate it all
> > they want, we just want to detect the download) and on the sigs such as
> > obfuscation and things which may FP a lot we can eliminate that risk
> because
> > to see that and then get the file download may make it much more
> reliable.
> >
> > It really is off the idea of the Java stuff; that was successful and so I
> > figure it may be of use here. Hopefully what happens then is we just
> keep up
> > to date on what clients request, what landing pages look like etc as they
> > are changed for different exploit kits and then we don't care what
> exploit
> > they deliver. This would mean detecting Java, Flash, PDF exploits (or
> > whatever other file types you want to know about) and EXE drops. Still
> > experimenting with it but I believe this may be a good way forward in
> > helping track exploit kits and what they are doing. As you said there is
> no
> > guarantee but then again there are other things like obfuscation,
> changing
> > their behaviours and stuff that will evade it. I am eventually hoping we
> can
> > get enough obfuscation methods, behaviours, redirections or whatever
> > together than we can at least keep tracking them as much as possible (i.e
> > they may change the request the client makes such as blackhole may stop
> > using page?= whatever it is but they may still use replace /g
> excessively so
> > we catch that with noalert and then alert on the file downloads.
> >
> > Kevin
> >
> >
> >
> > On 25 November 2011 15:34, Chris Wakelin <c.d.wakelin at reading.ac.uk>
> wrote:
> >>
> >> I must admit I've not really got to grips with flowbits yet :) Are you
> >> suggesting having duplicate rules, one set using flowbits and much
> >> higher certainty?
> >>
> >> At the moment, with the exploit kits evolving, I'd rather suffer a few
> >> false positives than miss something because a flowbit wasn't set by a
> >> rule that no longer matched the latest version.
> >>
> >> As for rules with high certainty (such as the Blackhole binary
> >> downloads), surely flowbits are superfluous?
> >>
> >> The other problem is can we be sure that the landing page and the later
> >> exploits are in the same flow (HTTP/1.1 tends to make it so, but there's
> >> no guarantee)?
> >>
> >> Having said that, flowbits have really helped with things like spotting
> >> EXEs downloaded by vulnerable Java.
> >>
> >> Best Wishes,
> >> Chris
> >>
> >> On 25/11/11 15:17, Kevin Ross wrote:
> >> > Would you be willing to try something as a little experiment? If you
> >> > could
> >> > you could try making the changes I suggested in the exploit kit email
> I
> >> > sent for the flowbits and things and then on this set the
> >> > flowbit:set,et.exploitkitlanding; flowbit.  It could be noalert too
> but
> >> > I
> >> > am curious to how the sigs do in that regard so hopefully it will
> catch
> >> > file downloads of PDF, EXEs etc. If this detected though on the
> genuine
> >> > exploit kits then a noalert could be applied and this would help limit
> >> > FPs
> >> > (assuming you have the logging such as suricata http logs or snort
> >> > spew2u2
> >> > or whatever to see URL/URI).
> >> >
> >> > I have been playing with this idea for a little while now and it has
> >> > some
> >> > good results which is why I wanted to put it out there as a way to
> >> > detect
> >> > what exploits were downloaded & even eliminate FPs by catching follow
> up
> >> > downloads rather than alerting on stuff like this.
> >> >
> >> > Kevin
> >> >
> >>
> >> --
> >> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
> >> Christopher Wakelin,
> c.d.wakelin at reading.ac.uk
> >> IT Services Centre, The University of Reading,  Tel: +44 (0)118 378
> 2908
> >> Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975
> 3094
> >
> >
> > _______________________________________________
> > Emerging-sigs mailing list
> > Emerging-sigs at emergingthreats.net
> > http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> >
> > Support Emerging Threats! Subscribe to Emerging Threats Pro
> > http://www.emergingthreatspro.com
> > The ONLY place to get complete premium rulesets for Snort 2.4.0 through
> > Current!
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20111125/8cc1070d/attachment-0002.html>