[Oisf-users] Suricata File Carving - Malware Detection

[Kevin Ross]

Thanks for the tip. I am looking forward to suricata having this capability
with the file_extract options that we mentioned after the last meeting but
until then I was going to use packet capture and file carving with nfex or
something (
http://blogs.cisco.com/security/network-based-file-carving/#more-13416) and
then have scripts to run clamav and other stuff against it. Ruminate looks
quite good though and I like that they are honest about its shortcomings and
its benefits which means you get a more realistic view of where it could fit
(though from the sound of it I don't think it is ready for production sized
networks though). Still it looks promising although I fear they may end up
getting dwarfed by suricata and razorback but for now may do they job and
worth experimenting with and I look forward to see where they go with it.

On 11 April 2011 13:46, Javier Almillategui <jalmilla at gmu.edu> wrote:

>   Hi Kevin,
>
> I know of Ruminate IDS project that just does what you want to do. it’s
> website is http://ruminate-ids.org/ .   I think file carving has a lot of
> challenges specially if you want it to scale properly.
>
> I hope this helps.
>
> best,
>
> Javier
>
>
>  *From:* Kevin Ross <kevross33 at googlemail.com>
> *Sent:* Monday, April 11, 2011 7:15 AM
> *To:* Victor Julien <victor at inliniac.net> ;
> oisf-users at openinfosecfoundation.org
> *Subject:* Re: [Oisf-users] Suricata File Carving - Malware Detection
>
> 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
>>
>
>  ------------------------------
> _______________________________________________
> 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/fe3f7f5d/attachment-0002.html>