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