How to Detect Botnet Beaconing That is Blocked By Your Firewall

[RSAAdmin]

NetWitness NextGen can actually detect compromised endpoints on your network by detecting connection attempts to known Command and Control servers-  connection attempts that are being blocked by your firewall or smart proxy.  Also, if known C&C hosts get blackholed, those bots out there will still try to communicate, and we can see these.  Here's how you do it.

• Step 1:  Deploy Zero Payload Rule.  Create a rule on the decoders to identify packets that have zero payload.  The rule should be called "Zero Payload" with the contents of the rule simply being "payload=0"  Deselect the option to stop rule processing and set the rule to alert into the Alert field.  Packets such as this are typically SYN connections.
  
  
• Step 2:  Create an Informer Chart.  Create a chart in Informer that looks for instances of this rule firing to all destination IP addresses that are listed in our 3rd party Threat Feed lists.  The rule for this chart should look for
  ip.dst WHERE alert='zero payload' && org.dst exists && org.dst != '$goodorgs' && threat.source exists && threat.source!='netwitness'
  and turn that rule into a chart.  Track the top 15  items.
  
  
  
  
• Step 3:  Create your white list of known good destination organizations.  As you begin investigating the results of this chart and rule you will invariably find known IP destinations that are trusted.  Like Google, a host in a common CDN, etc.  Add these destination organizations to this whitelist referenced in the rule of Step 2.
  
  
  

When deployed in the field, I typically see several connection attempts to known bad destinations.  And since it is a chart, you will begin to see the timed pattern of the traffic as well.  What this usually represents is a compromised source IP address that is attempting to connect to a blocked or blackholed destination, or you have orphaned malware that is trying to call home.  Those sources should be pulled from the network for re-imaging or similar internal IR process.

[Anonymous]

As Fielder said, even if you could that list wouldn't work, there's no payload on these sessions so there will be no information about those domains.

You really need to rely on the org.dst or domain.dst keys as these are based out of GeoIP information.

Hope that helps!

[RSAAdmin]

OK I think you guys lost me somewhere.

I removed the names on that list.  I still have the list in informer, but this is the only thing in it:

//List of acceptable download sources

//If listed name matches org.dst, filter from charting

The rule now looks like this:

alert='botnet beacon' && org.dst exists && org.dst != '$goodorgs' && threat.source exists && threat.source!='netwitness'

I am still getting the error when I look at Define Dashboards and when I look at my normal Dashboard view, it still says no results.

.

[RSAAdmin]

It looks right.  Do you get results when you test the rule?  Did you turn it into a chart and activate it?

[RSAAdmin]

i get no results when i test the rule.

i get no results when i test the chart.

i still get this msg when i look at Define Dashboard.

[RSAAdmin]

So step it back and make sure your rule is working first defining the botnet beacon rule. Do you see the rule fire in the alert meta in Investigator?  If not, move that rule to the top of your decoder rule order.  Wait a while to see if it fires.

When it does, and I'm certain it will, test your informer rule to get results without the where clause except for alert='botnet beacon.'  With Informer you will have to wait until the top of the hour rollover to see results in the test rule.

By the way, I went up to the rules you had posted and you have some interesting stuff about redkit and IE8 exploits.  Do those rules work?  If so, feel free to post those in a thread on here!

[RSAAdmin]

Also, I think your dashboard chart is referencing a rule no longer there.  Delete that dashboard item and recreate it and it should get rid of that error.

[RSAAdmin]

actually i have deleted it from the dashboard several times.

im checking those other things now but i do see it in the Alerts bucket in investigator.

to be honest i have so much on my plate with netwitness i cannot confirm if those other 2 rules you asked about work or not.

i think those were set up by PS when they were here.

i am the only one doing NetWitness so when i get a chance i will take a look and see if they work or i can post them for everyone to play with.

and being new to this whole forensics field makes it all the more fun...(sarcasm)... actually i love learning this stuff. it is a lot of fun playing detective.

i will have to continue this tomorrow and post updates.

thanks so much guys.

[RSAAdmin]

My bad.  The chart is referencing a rule that has been changed or deleted.  Delete that chart and recreate it from your rule.  If you are seeing the alert in investigator, copy and paste that into your informer rule to be sure of spelling and run the test.  You should see results.

[RSAAdmin]

I think I am going to have to give up on this one.

I have deleted everything and started from scratch, but still get no results when I test the chart.

We do have a Decoder App rule that's the same as the one you posted in the article called zero payload, so we will just use that one I guess.

I was curious to see if we would get different results with this rule.

Thanks for all the help.

[Anonymous]

If you have the "Zero Payload" rule already I would try with that just to be sure. It might a simple typo that we are missing somewhere or something like that.

It won't hurt to try if you have the time.