Yesterday, I wrote a blog post[1] which explained how to interconnect a Cuckoo[2] sandbox and the MISP[3] sharing platform. MISP has a nice REST API that allows you to extract useful IOC's in different formats. One of them is the Suricata / Snort format. Example:

alert http $HOME_NET any -> $EXTERNAL_NET any (
  msg: "MISP e3791 Outgoing HTTP Domain: khanji.ddns.net"; 
  flow:to_server,established; 
  content: "Host|3a|"; nocase; 
  http_header; content:"khanji.ddns.net"; fast_pattern; nocase; 
  http_header; pcre: "/(^|[^A-Za-z0-9-])khanji\.ddns\.net[^A-Za-z0-9-\.]/Hi"; 
  tag:session,600,seconds; 
  classtype:trojan-activity;
  sid:9068216; rev:1; priority:2; 
  reference:url,https://misp.xxxxxxxxxxxx/events/view/3791;
)

This is very tempting to automatically inject more and more IOC's into your IDS system to spot bad traffic. Also, a MISP instance can be fed with many other sources as seen in the following schema:

MISP can receive your own IOC's from sandboxes, from remote connected MISP instances or from external public/private sources. Keep in mind that an IOC must always be delivered in a contact. A simple example is the use of public DNS servers: For an organization "A", traffic to public DNS like Google or OpenDNS can be considered as suspicious. It could be legit to define them as IOC's. But in the organization "B", they use some public DNS services. If "B" integrates blindly all IOC's published by "A", they will be facing a risk of false positive alerts! I already faced this issue with many customers. Classic bad IOC's are:

• CRL services like crl.verisign.com,sc.symcb.com
• URL shorteners
• Public DNS
• Hashes of DLL's

To prevent this problem, my recommendation is to test your set of IDS rules based in shared IOC's before enabling them in production. This can be performed in three steps:

1. Get some network data. The simple solution is to use samples from your full packet capture solution[4], export PCAP files generated during interesting time periods like in the morning (8AM-10AM) when people arrive at the office, read their emails and visit their regular websites or at the lunch break. 

2. Export Suricata rules from MISP via the rest API. The goal is to check only rules generated with data coming from remote peers. We can assume that normal rules like feeds from Emerging Threats are safe.

# wget --header 'Authorization: xxxxxxxxxxx' \
--no-check-certificate \
-O /tmp/misp.rules \
https://misp.xxxxxxxxxxx/events/nids/suricata/download/false/false/false/false/false/15d

3. Run your Suricata in offline mode to process the samples:

# suricata -r /tmp/sample-08-10.pcap -S /tmp/misp.rules -l /tmp

Now, it's easy to parse the results from the fast.log logfile:

# cat /tmp/fast.log | awk '{ print $3 }' | sort -u | while read ALERT 
> do 
> X=`echo $ALERT | tr -d "[]"`
> N=`grep $X fast.log|wc -l`
> echo $ALERT : $N
> done
[1:2200025:1] : 320
[1:2200067:1] : 224
[1:2200075:1] : 9
[1:2210007:1] : 38
[1:2210008:1] : 38
[1:2220006:1] : 1
[1:2221007:1] : 1

Easy to spot a rule that generates a lot of hits! (Those three steps can be easily scripted for automatic reporting).

[1] https://blog.rootshell.be/2017/01/25/quick-integration-misp-cuckoo/
[2] https://cuckoosandbox.org/
[3] http://www.misp-project.org/
[4] https://isc.sans.edu/forums/diary/Full+Packet+Capture+for+Dummies/21679/

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key