Sunday, 24 February 2013

NSM With Bro-IDS Part 5: In-house Modules to Leverage Outside Threat Intelligence

Unless you just do not follow the InfoSec world or main-stream media, the odds are pretty high that you've heard about the Mandiant APT1 report available at

There is some awesome information in that report and they've provided a ton of data in the form of Indicators of Compromise, or IOCs. It wasn't too long afterwards that Seth Hall released a script module for Bro IDS that incorporated some of those indicators. That module is available here:

Within a couple of days, Symantec released their own "Comment Crew: Indicators of Compromise" report. That report can be found here:

To my knowledge, nobody has released a Bro module that incorporates any of that data and I wanted to use it -- so guess what I did tonight?

Good Programmers Borrow, Great Programmers Steal

Since I've never written a custom module for Bro, and because I had already started using Seth's module, I decided that imitation was the greatest form of flattery and decided to use his module as a template for my own. After all, this guy eats, sleeps and lives Bro. If you're going to follow anyone's lead on writing a module for it, whose code would be better for re-use?

I used the default location for my bro install, /usr/local/bro, so Seth's module is installed in /usr/local/bro/share/bro/site/apt1. That means any custom modules will go in /usr/local/bro/share/bro/site, so I went ahead and changed to that directory and copied Seth's module to a new directory called "sccrew" (Symantec Comment Crew):
cd /usr/local/bro/share/bro/site
sudo cp -prv apt1 sccrew
cd sccrew

I saved all of the domains in the Symantec report to a plain text file - one domain per line, each domain in quotes and all but the last with a comma at the end of the line. That means the file looks something like this:

Some stuff you can toss, some stuff you keep...

The README.rst file and .git directory are both going to be useless for this purpose so you can go ahead and remove them, leave them, it doesn't matter, but it's good practice to go ahead and remove them.

The other files are important. data.bro contains the actual indicators. If you view it in vi, you'll see Seth's comments, the module name, a list of hashes, a list of domains, etc. I removed everything in the file EXCEPT the domain block, then deleted the existing domains and replaced them with the domains I saved from the Symantec report. Then I changed the module name from APT1 to SCCREW and saved the file.

__load__.bro basically "includes" the data.bro and main.bro files. Leave it untouched.

main.bro controls the actions to take. I modified the APT1::Domain_Hit to be a SCCREW::Domain_Hit and removed the other notice types. I changed the module name to SCCREW, removed the x509_certificate and http_message components and changed anything in the dns_request section from APT1 to SCCREW. A little tweaking of the message that accompanies alarms to indicate it's from the Symantec report, not Mandiant's APT1, and the file was ready to be saved.

From there it was trivial to edit my /usr/local/bro/share/bro/site/local.bro and add the magic line that calls the sccrew module:
@load "sccrew"

Update the Running Instance!

Then I told bro to install the new configuration and update its running configuration:
sudo broctl check
sudo broctl install
sudo broctl update
And with that, boom, I had a module loaded that would alert based off of the Symantec indicators.

You can view the actual module here:

Many, many thanks to Seth for providing a great template to use for in-house modules and to Symantec for releasing a fairly small dataset that served as a great tool for looking at how to create a custom module for DNS alarms!

No comments:

Post a Comment

Note: only a member of this blog may post a comment.

Enriching Logs With Active Directory Attributes

Date of writing: 4th November 2018 Last edit: 4th November 2018 JUST GIVE ME THE SCRIPT AND CONFIG If all you need are the logstash co...