Good IOC VS. Bad IOC: When Automation Fails…

Good vs BadA few days ago, I wrote a diary on the SANS ISC website about automating the search for IOC’s (“Indicator of Compromise“). The use of tools to collect such information (IP addresses, domains, hashes, …) is very useful to build a list of interesting IOC’s … or not! Today, I wrote another diary about the recent threat that Apple faced with hundreds of malicious apps accepted on the AppStore (XCodeGhost).

A few hours later, a colleague at SANS ISC reported this:

IOC's

My diary contained a list of suspicious IP addresses. As you can see, the content was probably crawled by a bot and the useful data extracted. But my signature was also scanned and domain names were extracted (rootshell.be & truesec.be). Trust me, my domain names have no relation at all with XCodeGhost! I don’t want to blame the company behind this, I’m sure that plenty of other crawlers are doing the same job. But, just be warned: automation is not always accurate. Worse, some organizations can collect those IOC’s and implement blocking rules in firewalls, proxies based on them. It can be a disaster if sensitive domains become automagically blacklisted! Think about this…

[Updated at 22:24 CET]

After this blog post was published and a few messages exchanged via Twitter, I was in contact with somebody working for the company which is offering the service mentioned above. He clarified the situation, thanks to him! In a few bullet points:

  • The system does not work automatically and the content here above was created by a user.
  • The system is based on a toll where people can extract IOC’s from public sources. People using this tool must have some understandings of what they are doing. If the system is able to remote some false positives, it’s not always 100% accurate.
  • You need to “subscribe” to a specific content or account feeding the system with IOC’s to make them available through the available API.

The conclusion to the discussion was that operating an open platform always introduce risks to be populated with wrong content and that controls must be implemented to reduce the risk of false positives.

9 comments

  1. Xavier,
    Sorry this happened. That post was on our (AlienVault’s) Open Threat Exchange. OTX is a system designed with the intention of better facilitating the distribution and automated use of indicators. However, there is a little more to the story then automation. We provide a feature that allows users to provide a blog post (like yours), a pdf, a text block, a whatever then it attempts to extract indicators from it. We realize that we can not fully automate this so we have a step where the user who submits the blog post reviews what was extracted (along with our analysis of the indicator) and removes any erroneous entries. Unfortunately, in this case your two domains snuck through that step. We need to improve this system so that we can make it easier for peer review so you can flag such an error and prevent other OTX users from using this in error.

    Great post by the way and would be happy to give you the insiders tour of OTX so we can get some feedback and improve!

  2. Thanks for the feedback Jaime!
    But if other “pulses” are available for the same threat, how the end-user can choose which one to use/trust?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.