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

[Martin Holste]

> 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?

I agree:  You would need to make the flowbits set by source or
destination with a fairly high count, and in the end, I think you'd
still end up with a lot of garbage JPG/GIF/PDF/etc having flowbits set
that would be sent along with the exploit kit alert when the noalert
would be toggled, so I think the practical value would be far less
than the theoretical value, especially in NAT'ed environments.

That said, this is a problem worth solving somewhere as my analysts
currently spend quite a bit of time finding infection vectors, and if
the entire rule chain for exploit kits were available, it would cut
down on query time significantly.  This would lead to more security
teams having the full exploit path, which would in turn lead to more
ad companies hosting exploit banners being held accountable.

Bro has a nice feature which creates a unique connection ID for every
flow, which allows you to backtrace every event seen on that flow when
searching by connection ID.  The problem with that is it is usually a
single TCP connection, which will often only have one or two artifacts
on it.  So, the root challenge is how to properly trace all of the
activity from a single IP, which I agree is an SIEM function.  We do
this in ELSA by simply searching for the local IP involved, but there
are plenty of pitfalls in doing that, especially in a NAT'ed
environment.  So, the question for Suricata is what can be added that
provides artifact "breadcrumbs," and there is no easy answer.  I
suppose in a perfect world, Suricata would track connections by HTTP
referrer, user-agent, and TCP tuple to create an HTTP connection
record which could be attached to the existing HTTP logger and
generated alerts for tracing back.