[Oisf-users] Suricata File Carving - Malware Detection

[Kevin Ross]

I am definitely not suggesting this should be done on the wire or by the
main Suricata processes. What I mean once suricata drops it to disk maybe it
could have a process to analyse and feed the alerts back into suricata to
have it output an alert in unified2. Sure once suricata has file_extract
options creating your own script to run things on the file is easy but
suricata could do it straight out (or at least have it pass off). This way
those users who are not sure of the actual benefits or how to analyse files
on disk to detect malware and stuff don't have to think about it. Examples
of what could be done:

- Scan file with clamav
- Check for suspicious IATs such as ones checking for debuggers or other
stuff and the ability to possible threshold against a score. That way
suricata rather then generate an alert for every executable, suspicious
executables can be alerted on only (which with the right tuning could even
help zero in on unknown malware samples).
- Alerting on file type mismatches i.e server claims to send an image and
yet suricata is carving out an exe from the stream or carving flash out of
an excel file like the recent vulnerability (I guess this one could possibly
be handed by suricata itself if a user wanted such alerts).

My point is while making up your own scripts to do stuff (run clamav,
jsunpack etc on files) it is nice to have it handle it by default (if you
wanted it) and means more users who are learning or unsure how to take
advantage of file carving or why you would want to could benefit from it.

Kev


On 11 April 2011 10:13, Victor Julien <victor at inliniac.net> wrote:

> On 04/09/2011 02:51 AM, Kevin Ross wrote:
> > Stick with me with this. This is pescanner from the malware cookbook. I
> have
> > modified it slightly to have more IAT alerts after reading this
> > http://www.sans.org/reading_room/whitepapers/malicious/rss/_33649 as it
> has
> > a big list of IATs at the end and their malware uses so I added them in
> (in
> > this case I would say all those IATs look bad in combination). This was
> Zeus
> > with the file carved out a pcap on openpacket.org. You can see the
> > virtustotal report for the MD5 when I searched for it here
> >
> http://www.virustotal.com/file-scan/report.html?id=2f59173cf3842b3a72ac04404ab045c339cbc6f021f24b977a27441ea881e95b-1295056538
> >
> > Now what I was thinking is if they file_extract options were put into
> > suricata as was mentioned after the last meeting would it be hard to have
> > suricata or another tool check IATs, entropy, clamav scan possibly or
> > checking the MD5 against virustotal, shadowserver etc to determine if is
> is
> > possibly malicious? Even the IATs for their possible usage and risk and
> then
> > a threshold to then determine if the file is likely bad. If the file was
> > possible bad then a preprocessor style alert could be generated by
> suricata
> > with the relevant information about the file and the possibly malicious
> file
> > could be moved to a malicious folder or something to be stored while if
> the
> > user wants executables or other files that are not detected as anything
> or
> > suspicious could be deleted meaning you have a folder of likely samples
> for
> > stuff entering your network. What do people think?
>
> This analysis (mostly) requires the full file, right? In that case I
> think it makes more sense for Suricata to drop the file to disk and let
> a separate process do post inspection.
>
> Cheers,
> Victor
>
>
> --
> ---------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110411/36ee9b0f/attachment-0002.html>