One of the ThreatQ platform’s most powerful features is called Operations – our version of “workflow orchestration”.  They are customizable plugins (or modules) which can be added to the system in order to perform a number of tasks, including Data Enrichment.  They are written in Python and can either be created by ThreatQ or a customer.  This article will show how they can be used to enrich an Indicator using the ThreatQ threat intelligence platform.

Event

An investigation can start anywhere: a new Indicator, a new adversary, or a new Event.  For our example, we will start with an Event.  The ThreatQ Splunk App discovered an Indicator that we are watching was seen in the webserver access logs.  This triggered an Event being created on the ThreatQ threat intelligence platform with the Indicator related to it.  The Splunk App has been configured so that only Indicators which are not blocked by defenses generate an Event in order to reduce noise, however, this is all customizable to fit your requirements.

As we can see, we got a hit from 185.85.239.156.  At this point, all we have is the feed Source the Indicator of interest came from, Blocklist.de (Bruteforcelogin). This is not enough information to really jump start an investigation. This is where ‘Data Enrichment’ Operations plays a critical role to streamline workflows and allowing analysts to focus their time on analysis and less on manually-driven data collection tasks.

Operations

The ThreatQ threat intelligence platform provides a number of Operations by default, though more are able to be downloaded, created by savvy users or customized through ThreatQuotient Professional Services.  In this post, I will walk through four different Operations ranging from data enrichment to SIEM analysis.  As you would expect – some of the Operations require a commercial license whereas others are free.

Operation #1: Dig (free)

We will start simple and use the Console Utils Operation which does simple tasks such as Dig or Nslookup.

Dig tells us there is a Domain Name associated with this IP Address which we can now add as a Related Indicator by selecting it and clicking the Add Indicator button.  We can then pivot to the DNS name and see if any Operations reveal interesting data.  For now, we will focus on the IP Address.

Operation #2: RecordedFuture (commercial)

Next, we will check what Recorded Future (RF) knows about the Indicator.  RF is a commercial feed which provides cyber intelligence data, among other things.  Our operation is configured to import everything they have on the Indicator but it will also return an RF link to their site.

As we can see, they return quite a bit of interesting datapoints which we can add as Attributes to the Indicator.  As an analyst, I’d want to add the Rule which was triggered in RF: Recent Multicategory Blacklist.  This is good to know because it suggests this host has been involved in widespread activity.  Criticality and Risk Score are also entries an analyst may want to add but it is completely up to the analyst what information is captured.

Operation #3: Neutrino (free/commercial)

Using the Neutrino Operation, we can gather geolocation information about the IP Address and add this information to the Indicator.  This information can provide valuable context especially if you do NOT have any business ties in those parts of the world.

Neutrino also offers a Host Reputation to give you the IP’s status related to ~160 blacklists.  By using this Operation, we can find out exactly which blacklists are reporting it and some additional contextual information about why they are on the list.  This is important to know because it gives us a better picture of what activities this host has been involved with.

As we can see, this IP address has been seen by quite a few blacklists, so it is likely targeting the Internet at large rather than targeting a specific organization.  The analyst can choose which blacklist information they want to attach to the Indicator for later threat hunting.  Neutrino also offers a higher level view of the Indicator which attempts to categorize it.

As we can see above, they classify it as a bot.  This would make a useful attribute.  It, alone, can be selected and added.  This suggests the IP is not being used by a sophisticated attacker, rather it is running automated actions against the Internet in general.  We can also see it is likely NOT a TOR or VPN node and it hasn’t been seen running exploits against any sites – which may help dictate next steps in our alert investigation.  If we go back to the Source of this Indicator (Bruteforcelogin) it helps confirm what we are dealing with.

Now let’s take a look at all the information we have gathered about this Indicator using Operations.  We now have a lot more context in order to make our decisions.  As an analyst, this Indicator is most likely just general malicious noise.  There is no evidence suggesting our organization is being targeted specifically.

Although tacked up to noise, there is still the matter of what it was actually doing with our network since it did successfully get through the Firewall.  Now pivoting from several Data Enrichment Operations we can perform a SIEM Operation to easily get a look at the logs without having to login – in this case Splunk.

Looks like it was attempting to brute force a WordPress login.  Based on the context we now know about this Indicator, it aligns nicely.  Bots brute forcing WordPress sites are quite common.  As a result of this investigation, we could ask that the site’s login logs be checked and that this Indicator be blocked at the Firewall.  Or it may be ignored since this seems to be a general attack and not directed at our organization specifically.

ThreatQ Operations offers a tremendously powerful investigation and analysis capability to automate efforts across common workflows. The Operations allow an analyst to easily add context to an Indicator without having to open ‘a dozen tabs’ and copy/paste data which delays the investigation, decision-making, and ultimately, the remediation of the intrusion.