Blacklists Are a Necessary Evil, But They Still Suck

Running into blacklists in security is virtually unavoidable regardless of what technical silo one is embarking on. Whether it is SPAM (IP, E-mail), malware (DNS, IP), or even targeted threats (DNS, IP, E-mail) there are blacklists meant to assist security professionals in determining the hostility of an entity for a multitude of attack types. Not to knock them too much, the people putting together blacklists are doing a tremendous amount of work. The problem is that these lists are useless without the right context. We’ll do a lot of discussion on intelligence topics here and this notion of “context” will be important throughout.

This is particularly true in the realm of blacklists as blacklists are typically focused around one key attribute. For example, there are many blacklists that focus their categorization around IP addresses. While IP addresses can obviously be helpful in identifying systems, there are numerous reasons why they may be inaccurate. It is these inaccuracies that make many blacklists unreliable. Some may argue that blacklists based around DNS information are more accurate, and they would have a point, however, there are fewer devices that can key around that information and there is no certainty whether the information is timely or not. In other words, there is no guarantee that the list is updated when the site is fixed or the DNS information is changed. What’s worst is when IP address information is directly associated with malware activity as fast flux DNS information can alter that information rapidly.

To give one example of how blacklist information can cause problems without context, take the Emerging Threats (ET) rules associated with the Snort alert “ET CNC Shadowserver Reported CnC Server.” If one reads the posted explanation on the ET site the explanation for the rule is pretty simple. A list is taken daily from several blacklists and turned into a Snort/Suricata signature and Firewall rules. Pretty simple and straight forward right? Not quite. Let’s take a look at an actual event that exemplifies why.

On the right is a common Snort alert ET CNC Shadowserver Reported CnC Server UDP (group 39), It’s pretty scary, a machine on the network went to a blacklisted IP address without any user interaction. Sounds like clear trojan activity right? Wrong. This is actually a false-positive. To understand how this can be determined, let’s take a look at the actual signature from ET:

alert udp $HOME_NET any -> [,,,,,,,,,,,,,,,,,,] any (msg:"ET CNC Shadowserver Reported CnC Server UDP (group 39)"; reference:url,; reference:url,; threshold: type limit, track by_src, seconds 3600, count 1; classtype:trojan-activity; flowbits:set,ET.Evil; flowbits:set,ET.BotccIP; sid:2404077; rev:3159;)

So basically all this rule does is say, did any machine on the home network touch any blacklisted machine? If yes, then fire the alert.However, when one looks a little closer at the why the particular IP address is blacklisted, things get a little interesting. Apparently Shadowserver saw a legitimate IRC channel being used for abuse at (see the E-mail confirming). In other words, if a machine on the network touched via port 6667, it may or may not be malicous. Which is pretty loose for a Severity 1 alert, but we’ll go with it. What’s actually worst is that this particular network alert triggered over port 123/UDP (NTP). This is not a trojan dialing home, it is simply a router trying syncing it’s time!

Which means that either there is a server that is running multiple services, some maybe malicious, some likely not. More likely even, there is several servers behind Network Address Translation (NAT) which are likely not related to one another with the exception of using the same NAT. This information makes the alert a blatant false-positive.

To hammer the point of why blacklists suck let’s compare the alert that fired with the work that is needed to be done to determine whether this was malicious traffic.

Information behind why this alert triggered:
1. A machine touched a blacklisted IP address

Information needed to determine whether the event should have triggered:
1. A machine touched a blacklisted IP address
2. Why the blacklist owner listed the IP address
3. What service was blacklisted on the server
4. What port did the traffic occur over
5. What type of malicious traffic is occuring

As is plain to see, the simple usage of the blacklist does provide anywhere near enough information to determine whether the traffic that is causing the alert is of a malicious nature or not. Rather, the blacklist information is a portion of the context necessary to determine whether traffic is malicious or not. It provides a necessary indicator but needs much more information to truly be useful.

Comments are closed.