I want to take a second to really commend Josh on these
signatures because I really think that this was a worthwhile endeavor and has really defined the scope of what needs to be detected. That said, I think that now that we know how many signatures it would take, we need to find a different way of doing it. Does a standard MZ executable signature miss on any of these PEiD signatures? I would think that by definition, all packed exe's must also have at least part of the standard MZ PE headers. If that is confirmed, then I would posit the following: <br>
<ul><li>There are too many ways to pack an exe to fit into an efficient rule set.</li><li>Polymorphic packers can easily evade existing PEiD's (see ShadowServer.org's packer stats).</li><li>I've not had reliable results with the PEiD Snort sigs because of signature overlap and false positives.<br>
</li></ul>Therefore, using the standard (and existing) exe signature which canonically identifes all exe's downloaded and feeds these exe's into an application-layer exe analysis framework is preferable to attempting to make Snort detect this on the wire. This can easily be accomplished (and to some degree already is) with the Bro framework, (insofar that it can auto-extract exe's and test them against things like known malware hashes). If it's not already done, it would be trivial to run an extracted exe through PEiD. This would be far easier to maintain than an entire ruleset of Snort sigs. In fact, Snort could do this as well with the "session" rule modifier and Jason Brevenik's SnortUnified Perl module tailing the unified output. This would also be the perfect spot to hook into a sandbox queue. Imagine a framework where a rule like this could be written: "alert if a binary is extracted which when executed contacts a domain not on this whitelist." If the binary hashes are cached and submitted to a central repository, over time, a larger existing library can be created which would save a lot of back-end work.<br>
<br>There's a big hole in this, though, and that is a relatively new phenemenon I've been coming across lately which consists of executable scripts encoded in Javascript payloads, where the Javascript, after being unobfuscated, will save a compressed .js file and run it using wscript.exe. This is used to replace the standard phase one downloader Trojan. Occasionally, I've seen it do phase two activities as well, like registry modification. So, while exe headers are easy to identify in a network stream, very application-level Javascript implementations like this are nearly impossible to identify. I think Javascript behavior profiling and a signature language that describes it is the next frontier for analysis, and I would love to see someone with Josh's abilities and ambition try to attempt something in that problem space. <br>
<br>To whet your appetites, check out the simply amazing work UC Santa Barbara has done with wepawet (<a href="http://wepawet.iseclab.org">wepawet.iseclab.org</a>). It profiles Javascript and Flash in a sandbox and shows the deobfuscated and run-time output. Check out the samples there for a look at how detailed it gets.<br>
<br>--Martin<br><br><div class="gmail_quote">On Sun, Jan 25, 2009 at 11:03 AM, Josh Smith <span dir="ltr"><<a href="mailto:famousjs@gmail.com">famousjs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
David,<br>
<br>
Well I originally converted the database file they offer on the PEiD<br>
website, and that was about 1500 signatures. Now I've just been<br>
collecting database files from around the internet. The one I<br>
originally did may be dated, but still applies to quite a few binary<br>
signatures.<br>
<font color="#888888"><br>
-Josh<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Sun, Jan 25, 2009 at 11:58 AM, David Glosser <<a href="mailto:david.glosser@gmail.com">david.glosser@gmail.com</a>> wrote:<br>
> wow! is there any way to have a smaller list of "active" sigs? (or would<br>
> that "smaller" list still be too large for most snort installations)?<br>
><br>
><br>
><br>
> On Sun, Jan 25, 2009 at 11:38 AM, Josh Smith <<a href="mailto:famousjs@gmail.com">famousjs@gmail.com</a>> wrote:<br>
>><br>
>> I have been working on converting the PEiD database of binary packer<br>
>> signatures straight to snort signatures. I've been refining my<br>
>> signatures with other members from Emerging Threats, and have over<br>
>> 10,000 snort signatures for packers. I was told this may be a good<br>
>> topic to bring up (binary packer detection) for OISF.<br>
>><br>
>> -Josh<br>
>> _______________________________________________<br>
>> Discussion mailing list<br>
>> <a href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a><br>
>> <a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
><br>
><br>
_______________________________________________<br>
Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
</div></div></blockquote></div><br>