[Bro] Bro + Yara File Scanning Module?

Jason Batchelor jxbatchelor at gmail.com
Fri Jul 25 10:42:58 PDT 2014

Out of curiosity, were you working with Yara 2.0 when you were developing?
It is several orders of magnitude faster than previous versions.

To your question, I would be interested in this effort but before diving in
would like some time to familiarize myself more with Bro development. I
will be at this years BroCon in pursuit of that goal and would welcome
further collaboration toward this end :)

Ideally, what I would love to see is a way to take actions on alerts
generated by some kind of 'Files::ANALYZER_YARA'. So say if I have a ZIP
file for example and a Yara rule to detect a ZIP. I think it would be very
valuable for someone to not only just trigger on that, but then invoke an
event that decompresses the ZIP and feeds the contents through the same
scanning engine. Now replace ZIP files with a known crypter/obfuscation or
something else and you can perhaps start to see the power and possibilities
that begin to unfold :)

Full disclosure time...:

I am a malware reverse engineer by trade. When I RE a binary I can tell my
customers (the analysts) a lot about it, however, their ability to take
action on the intelligence I give them is oftentimes limited by their
capabilities / security posture as an organization.

Enter Bro, with a modular framework, I look to this as a means to make the
observables I gain from my RE efforts as more valuable actionable
intelligence for my team. By implementing this modular 'take action on X'
mentality with respect to Bro and Yara, my signatures get more milage, as
well as my observables on how certain crypters/encodings can be defeated.

Imagine this, I have a signature for shellcode that decrypts a PE in a
certain way always at a certain offset. My Yara rule hits on this signature
and triggers an event that unmaskes the binary as well, out pops the
dropper, that is scanned again, and hits on the signature I created for the
dropper, etc, etc..

So I've automated analysis that is usually done by someone more experienced
on the command line. Not only that, but now the analyst knows more about
what they are dealing with which directly informs IR/Intel efforts.

Hope that helps paint the picture a little more :)

- Jason

On Fri, Jul 25, 2014 at 10:09 AM, Seth Hall <seth at icir.org> wrote:

> On Jul 25, 2014, at 10:54 AM, Seth Hall <seth at icir.org> wrote:
> > On Jul 25, 2014, at 10:03 AM, Jason Batchelor <jxbatchelor at gmail.com>
> wrote:
> >
> >> Interested if this is something that has been considered previously? If
> so, what were the results? If not, I'm happy to spin off an effort of my
> own. Either way I see it as a good project to get into Bro scripting at a
> deeper level.
> >
> > I was working on this a while ago and got it working. :)
> I forgot to mention one more point.  It was pretty slow because of the
> internal architecture of Yara and I had started reworking a bit of Yara to
> fix the problem (compiling rule sets is slow and they mix rule match state
> with the compiled rule structure so you can't match multiple files
> concurrently with the same compiled rule set).
> Is there anyone out there interested in taking on this rework and pushing
> it to completion? (you need to know C)
>   .Seth
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20140725/cab9073a/attachment.html 

More information about the Bro mailing list