<br><br><div class="gmail_quote">On Fri, Apr 20, 2012 at 2:09 PM, Marcos Rodriguez <span dir="ltr"><<a href="mailto:marcos.e.rodriguez@gmail.com">marcos.e.rodriguez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><div><div class="gmail_quote">On Fri, Apr 13, 2012 at 9:15 AM, Peter Manev <span dir="ltr"><<a href="mailto:petermanev@gmail.com" target="_blank">petermanev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hi Francesco,</div>
<div>What are your file-data rules like for this particular case?</div>
<div> </div>
<div>thanks<br><br></div><div><div>
<div class="gmail_quote">On Fri, Apr 13, 2012 at 1:18 PM, Travel Factory S.r.l. <span dir="ltr"><<a href="mailto:mc8647@mclink.it" target="_blank">mc8647@mclink.it</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br>It drove me crazy that several identical .exe downloaded from the web<br>had different MD5, also "not-human" downloads like the automatic<br>
update checks of the software.<br><br><br>Please have a look at this:<br><br># cat file.1237.meta<br>TIME: 04/06/2012-11:53:29.220774<br>SRC IP: <proxy - ip ><br>DST IP: <client - ip ><br>
PROTO: 6<br>SRC PORT: 8080<br>DST PORT: 1697<br>HTTP URI:<br> <a href="http://cache.pack.google.com/edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe" target="_blank">http://cache.pack.google.com/edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe</a><br>
HTTP HOST: <a href="http://cache.pack.google.com/" target="_blank">cache.pack.google.com</a><br>HTTP REFERER: <unknown><br>FILENAME:<br> /edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe<br>
MAGIC: HTML document text<br>STATE: CLOSED<br>SIZE: 333<br>root@a01:/var/log/suricata/201204131244/files# cat file.1238.meta<br>TIME: 04/06/2012-11:53:29.220774<br>SRC IP: < proxy - ip ><br>
DST IP: < client - ip ><br>PROTO: 6<br>SRC PORT: 8080<br>DST PORT: 1697<br>HTTP URI:<br> <a href="http://o-o.preferred.mil01s10.v16.lscache1.c.pack.google.com/edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe?cms_redirect=yes" target="_blank">http://o-o.preferred.mil01s10.v16.lscache1.c.pack.google.com/edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe?cms_redirect=yes</a><br>
HTTP HOST:<br> <a href="http://o-o.preferred.mil01s10.v16.lscache1.c.pack.google.com/" target="_blank">o-o.preferred.mil01s10.v16.lscache1.c.pack.google.com</a><br>HTTP REFERER: <unknown><br>FILENAME:<br>
/edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe<br>MAGIC: PE32 executable for MS Windows (GUI) Intel 80386<br>32-bit<br>STATE: CLOSED<br>SIZE: 26259<br><br><br><br>
So it seems a client asks for an update and gets a 333 bytes HTML<br>answer and then gets the same file from another server and receives<br>26259 bytes of a PE32 executable.<br><br>The 333 HTML file is actually a 302 http redirect.. why does it get<br>
dumped ?<br><br>The second file is actually a PE32 file but it is truncated. Of about<br>15 logged downloads, only 3 dumps were complete.<br>Do you have similar results ?<br><br>Francesco<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><br clear="all"><br></div></div><span><font color="#888888">-- <br>
<div>Regards,</div>
<div>Peter Manev</div><br>
</font></span><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>
<br></blockquote></div><br></div></div></div><div>Hi Everyone,</div><div><br></div><div>I wanted to piggyback on this topic and add some observations I've noticed today:</div><div><br></div><div>While I haven't checked MD5 summing yet, I have noticed that with just one rule specifying Windows PE's for extraction, I'm also getting JPEG, CSS, and other files.</div>
<div><br></div><div>Here's a copy of my rule (blatant rip-off of Victor's example <a href="https://redmine.openinfosecfoundation.org/projects/suricata/wiki/File_Extraction" target="_blank">here</a>): </div><div><br>
</div><div>alert http any any -> any any (msg: "EXE Detected over HTTP"; filemagic:"executable for MS Windows"; fileext:"exe"; filestore; sid: 2000000; rev:1;)</div>
<div><br></div><div>Here are my yaml settings pertaining to file extraction:</div><div><br></div><div><div>- file-store:</div><div> enabled: yes # set to yes to enable</div><div> log-dir: /data/suricata/files # directory to store the files</div>
<div> force-magic: no # force logging magic on all stored files</div><div> force-md5: yes # force logging of md5 checksums</div></div><div><br></div><div>magic-file: /usr/share/file/magic</div><div><br></div>
<div><div>default-rule-path: /etc/suricata/rules</div><div>rule-files:</div></div><div>- file-extract.rules (This is the only rule file enabled, and it contains only the rule I listed above.)</div><div><br></div><div>Here is some output as an example:</div>
<div><br></div><div># file file.[0-9][0-9][0-9]</div><div><br></div><div><div>file.206: JPEG image data, JFIF standard 1.01</div><div>file.207: JPEG image data, JFIF standard 1.01</div><div>file.208: GIF image data, version 89a, 1 x 1</div>
<div>file.209: HTML document text</div><div>file.210: GIF image data, version 89a, 1 x 1</div><div>file.211: ASCII text, with no line terminators</div><div>file.212: UTF-8 Unicode text, with very long lines, with no line terminators</div>
<div>file.213: GIF image data, version 89a, 1 x 1</div><div>file.214: GIF image data, version 89a, 1 x 1</div><div>file.215: GIF image data, version 89a, 1 x 1</div><div>file.216: XML 1.0 document text</div><div>file.217: ASCII text, with very long lines, with no line terminators</div>
<div>file.218: ASCII text, with no line terminators</div><div>file.219: PNG image data, 256 x 256, 8-bit colormap, non-interlaced</div></div><div><div>file.272: PE32 executable for MS Windows (GUI) Intel 80386 32-bit</div>
<div>file.273: PE32 executable for MS Windows (GUI) Intel 80386 32-bit</div></div><div>--------------------------------------------------------------------------------------------------------------</div><div><br></div><div>
I apologize if this has been covered and I just missed the proper search for the answer. Any ideas? Don't get me wrong, I LOVE the file extraction capabilities, and it's getting better with each update. I really just want Windows PE's for now for research and tool development to analyze said PE's. Thanks, guys. You all rock!</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>marcos</div>
</font></span></blockquote></div><br><div>Hi again,</div><div><br></div><div>Looks like my apology was justified. I just read the other thread where Will mentioned rolling back the rules. Thanks again!</div><div><br></div>
<div>marcos</div>