IOC's: Risks of False Positive Alerts Flood Ahead, (Thu, Jan 26th)

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 IOCs in different formats. One of them is the Suricata”>
alert http $HOME_NET any – $EXTERNAL_NET any ( msg: MISP e3791 Outgoing HTTP Domain: content: Host|3a| pcre: /(^|[^A-Za-z0-9-])[^A-Za-z0-9-.]/Hi )

This is very tempting to automatically inject more and more IOCs into your IDS system to spot bad traffic. Also, a” />

MISP can receive your own IOCs 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 anorganizationA, traffic to public DNS like Google or OpenDNS can be considered as suspicious. It could be legit to define them as IOCs. But in the organizationB, they use some public DNS services. If B integrates blindly all IOCs published by A, they will be facing a risk of false positive alerts! I already faced this issue with many customers. Classic bad IOCs are:

  • CRL services,
  • URL shorteners
  • Public DNS
  • Hashes of DLLs

To prevent this problem, my recommendation is to test your set of IDS rules based in shared IOCs 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 yourfull packet capture solution[4], exportPCAP files generated during interestingtime periods like in the morning (8AM-10AM) when people arrive at the office, read their emails and visit their regular websites or at the lunchbreak.”>
# wget –header Authorization: xxxxxxxxxxx –no-check-certificate -O /tmp/misp.rules “>
# suricata -r /tmp/sample-08-10.pcap -S /tmp/misp.rules -l /tmp

Now, it”>
# 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).


Xavier Mertens (@xme)
ISC Handler – Freelance Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Comments are closed.