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:<br>
<br>- Scan file with clamav<br>- 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). <br>
- 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).<br>
<br>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. <br>
<br>Kev<br><br><br><div class="gmail_quote">On 11 April 2011 10:13, Victor Julien <span dir="ltr"><<a href="mailto:victor@inliniac.net" target="_blank">victor@inliniac.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 04/09/2011 02:51 AM, Kevin Ross wrote:<br>
> Stick with me with this. This is pescanner from the malware cookbook. I have<br>
> modified it slightly to have more IAT alerts after reading this<br>
> <a href="http://www.sans.org/reading_room/whitepapers/malicious/rss/_33649" target="_blank">http://www.sans.org/reading_room/whitepapers/malicious/rss/_33649</a> as it has<br>
> a big list of IATs at the end and their malware uses so I added them in (in<br>
> this case I would say all those IATs look bad in combination). This was Zeus<br>
> with the file carved out a pcap on <a href="http://openpacket.org" target="_blank">openpacket.org</a>. You can see the<br>
> virtustotal report for the MD5 when I searched for it here<br>
> <a href="http://www.virustotal.com/file-scan/report.html?id=2f59173cf3842b3a72ac04404ab045c339cbc6f021f24b977a27441ea881e95b-1295056538" target="_blank">http://www.virustotal.com/file-scan/report.html?id=2f59173cf3842b3a72ac04404ab045c339cbc6f021f24b977a27441ea881e95b-1295056538</a><br>
><br>
> Now what I was thinking is if they file_extract options were put into<br>
> suricata as was mentioned after the last meeting would it be hard to have<br>
> suricata or another tool check IATs, entropy, clamav scan possibly or<br>
> checking the MD5 against virustotal, shadowserver etc to determine if is is<br>
> possibly malicious? Even the IATs for their possible usage and risk and then<br>
> a threshold to then determine if the file is likely bad. If the file was<br>
> possible bad then a preprocessor style alert could be generated by suricata<br>
> with the relevant information about the file and the possibly malicious file<br>
> could be moved to a malicious folder or something to be stored while if the<br>
> user wants executables or other files that are not detected as anything or<br>
> suspicious could be deleted meaning you have a folder of likely samples for<br>
> stuff entering your network. What do people think?<br>
<br>
</div>This analysis (mostly) requires the full file, right? In that case I<br>
think it makes more sense for Suricata to drop the file to disk and let<br>
a separate process do post inspection.<br>
<br>
Cheers,<br>
Victor<br>
<br>
<br>
--<br>
---------------------------------------------<br>
Victor Julien<br>
<a href="http://www.inliniac.net/" target="_blank">http://www.inliniac.net/</a><br>
PGP: <a href="http://www.inliniac.net/victorjulien.asc" target="_blank">http://www.inliniac.net/victorjulien.asc</a><br>
---------------------------------------------<br>
<br>
_______________________________________________<br>
Oisf-users mailing list<br>
<a href="mailto:Oisf-users@openinfosecfoundation.org" target="_blank">Oisf-users@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
</blockquote></div><br>