Today, the goals of maturing Security Operations teams require modest but valuable automation.

In this sense, few but impactful areas of threat hunting can be automated. One is IOC enrichment, which uses various threat intelligence provider integrations/apps within your SOAR or SIEM platforms. The second area would be taking this further and triggering SOAR threat hunts using threat intelligence via automatic SIEM searches.

We know what you’re thinking. Aren’t these just correlation rules?

And that’s a good question.

Unless your correlation rules can rewrite themselves on the fly, they ultimately depend on fresh threat intelligence.

Correlation rules cannot follow up on detection by enriching IOCs and performing follow-up searches on the results. Nor can they parse and search for specific criteria from those results and then update themselves.

In this sense, automated threat hunts are SIEM searches that trigger in response to enriched IOCs within SOAR incidents.

Assuming your team has a SOAR platform, which isn’t prevalent but is more common than in the past, you likely need to build use cases to justify the cost. Automated threat hunts that integrate premium threat intelligence are one use case that will immediately provide a return on value and reduce your teams’ cycle times.

This guide will illustrate a high-level design for automated threat hunting between SOAR and SIEM tools.

SOAR Automated Threat Hunting Workflow

Most SOAR platforms can generate and store indicators of compromise (IOC) within incidents. In XSOAR, these are called incidents, and in Splunk SOAR, these are called either events or cases.

These IOCs can be enriched with threat intelligence providers. An example would be Recorded Future, which integrates with Splunk SOAR and Palo Alto XSOAR.

For instance, the Recorded Future for Splunk SOAR app has actions that can enrich IOCs, such as IP addresses, and return any high-fidelity related IOCs.

Below are some actions the Recorded Future for Splunk SOAR action includes.

Embed actions like these into playbooks and format the results into search queries to detect threats in your environment.

Now:

Say you have an incident containing IP indicators of compromise. Enriching these indicators, fetching the results (additional related IOCs), and running SIEM search queries require time. Understandably, this can’t be scaled with dozens of daily incidents with manual searches.

So:

Let’s assemble a few example search queries that your SOAR tool will run.

Example: Splunk Search for IP Addresses

We’ll create a Splunk search that utilizes Splunk’s Network Traffic data models. This search will search against all destination IP addresses using your set of IP indicators of compromise.

prestats=t append=t summariesonly=true values(Network_Traffic.sourcetype) as sourcetype 
allow_old_summaries=true fillnull_value="none" count from datamodel=Network_Traffic 
where nodename=All_Traffic.Traffic_By_Action.Allowed_Traffic AND earliest=-7d@d 
by _time, index, All_Traffic.dest_ip
| eval Name='All_Traffic.dest_ip'
| join Name
    [| makeresults
   eval Name={Comma Separated List of IP Addresses}
   makemv Name delim=", "
   mvexpand Name]

If needed, this search can be formatted into two separate pieces. Simply take the Splunk sub-search enclosed by square brackets, format it independently, and then pass it into the main search query.

Example: QRadar Search for IP Addresses

Begin by creating a reference set containing the indicators from your SOAR platform. Most SOAR platforms, including XSOAR and Splunk SOAR, have this built-in capability.

Then, use the reference set you created to search for the list of indicators against all destination IP properties. In this example, we’ll name the reference set ip_threat_data.

SELECT destinationip
FROM events
WHERE REFERENCESETCONTAINS('ip_threat_data', destinationip)
LAST 30 days

How to Take Action on SOAR Incidents

Any matches or hits should be investigated with due diligence. It’s at this step where automation cannot be entirely relied on.

So far:

You’ve automated enriching indicators, formatting, and running SIEM searches to hunt for threats.

But what now?

You’ve automated a lot at this point. Likely, you won’t want to return to the old manual threat-hunting methods.

Additional automation, like quarantining devices, can be embedded into the workflow, mainly if your results determine a device communicates with an indicator used in your SIEM search.

You can also automate blocking any indicators with your firewall or EDR tools.

Enjoy the automation!