[Oisf-users] Suricata File Carving - Malware Detection

Javier Almillategui jalmilla at gmu.edu
Mon Apr 11 12:46:15 UTC 2011

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.



From: Kevin Ross 
Sent: Monday, April 11, 2011 7:15 AM
To: Victor Julien ; 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. 


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.


  Victor Julien
  PGP: http://www.inliniac.net/victorjulien.asc

  Oisf-users mailing list
  Oisf-users at openinfosecfoundation.org

Oisf-users mailing list
Oisf-users at openinfosecfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110411/35a1f162/attachment-0002.html>

More information about the Oisf-users mailing list