Posted
To avoid indicators of compromise becoming links to malicious content, “defang” them.
If you’ve worked in the computer security industry for a while, you have probably seen a website, email, Slack message, or spreadsheet with a malicious URL, email address, or domain name that has become a link. One of the ways to avoid indicators of compromise becoming links to malicious content is to “defang” them. Defanging means that you change the form of the indicator in a way that it will not become a malicious link. For example, defanging “example.com” looks like: “example[.]com” and defanging “http://example.com” looks like: “hXXp://example[.]com”. The goal is to change the indicator in a way that it is clear what has been changed so that the indicator will not become a link. For the curious: the opposite operation is called “fanging” an indicator of compromise (e.g. “example[.]com” => “example.com” – you can read more fanging and defanging here and there is a Playbook app to do this here).
In this blog post, we’ll introduce a Component to defang indicators of compromise and introduce our newest Playbook feature: iterators (introduced in ThreatConnect version 5.8)!
Indicator Defanging Component
There is a Playbook Component to defang indicators of compromise here. As we have discussed before (refer to the “Why a Component?” section here), the benefit of creating a component is that is allows you to solve a problem once, in one place and use it multiple times, in multiple different places and contexts. To get started, download Indicator Defanger.pbx and import it into ThreatConnect:
Now, you can create a Playbook that uses this Component:
As an example where the indicator defanging component would be useful, if you want to send a Slack message to my team every time a new indicator is created in a ThreatConnect source, you should defang the indicator before sending it so that it does not become a link.
Brief Introduction to Iterators
But what happens if we want to defang multiple indicators? For example, let’s say there was an IR team that used the ThreatAssess score to help identify which indicators should be investigated first. Every morning, they want to get an email with all of the indicators whose ThreatAssess score is over a certain threshold (a dashboard card would probably be a better solution to their need for a list of what to work on for the day, but for the sake of demonstration we’ll just pretend they really want to get more emails). To accomplish this, a Playbook would run every morning and will pull all of the new indicators, check the ThreatAssess score, and, assuming the ThreatAssess score is high enough, defang them so that they can be added to the daily email. The challenge here is that each indicator needs to be processed individually. With ThreatConnect version 5.8, this is possible using iterators. Iterators do exactly what they sound like… they allow you to iterate through arrays.
A full-scale introduction to iterators is a topic for another time, but for the use-case we just described, we could pass all of the indicators as well as an array with all of the ThreatAssess ratings into the iterator, determine if the ThreatAssess rating is sufficiently high, and defang the indicator for addition in the email.
Here is a demo of what it looks like to build such a Playbook:
