Onboarding Threat Indicators into Splunk Enterprise Security: SolarWinds Continued

As your team responds to the SolarWinds security advisory, we wanted to provide additional guidance to help you more effectively ingest threat indicators to combat the Sunburst Backdoor malware in Splunk Enterprise Security (ES). After applying these tips, you can jump into this blog, "Using Splunk to Detect Sunburst Backdoor," and take action.

While the existing method of downloading indicators into Splunk Enterprise has been in place for a long time whether you’re running ES 6.4 or older versions like ES 4.5, we have a few tips and tricks to share that will hopefully smooth out some bumps you may have encountered in the past. 

The Issues with Fields

One of the greatest pain points encountered when ingesting threat indicators is the naming of fields. The threat intelligence framework expects that specific header field values are being utilized. The reference for this can be found here. 

For example, if I am pulling a list of IP addresses in, the framework is expecting the field that contains the IP address to be called “IP” – not dest, src, source_ip or anything else, just “IP”. Similarly, for a domain name, it is looking for the field domain. Below is an example from the link above.

To illustrate this, we are going to use the GitHub repository for Sunburst Backdoor that Shannon Davis created as an example. I started off by creating two intelligence downloads called SunburstDomain and SunburstIP. I have configured the type, description and the URL that it is pulling from.

When I click on each one and scroll down, I can see parsing options. Notice in Fields we are looking in the first column of the csv file for values that will populate the ip field and the description column will be filled with a constant of SunburstIPListing.

Similarly in our domain download, the domain values are in the first position on the list, which is why we are using $1 to denote where to look. We are also using a constant again to describe the list. This time, I have ignored the wisdom of using the supported type of threat intel and instead of calling my first field domain, I am calling it “url_domain”.

While the threat intel download will save and the file will download, I find myself to be disappointed because these domains are not populating my lookups. How can I try to troubleshoot this?

The good news is there are a number of places that can be reviewed along the way to determine what is going wrong.

Tips and Tricks

Start by ensuring that the Intelligence Downloads are enabled.

From there, check and see if the file has been downloaded by going to Audit – Threat Intelligence Audit in Enterprise Security. The download_status should show that the threat list has been downloaded. If it didn’t, chances are that the URL is not correct.

For skeptics like me, knowing where the threat intelligence files have been downloaded to is a nice piece of information to have. From the command line, go to $SPLUNK_HOME/etc/apps/SA-ThreatIntelligence/local/data/threat_intel/ directory. If the files have been successfully downloaded, both the SunburstDomain and SunburstIP files can be viewed in the file system. The naming convention of the files are based on the name specified in the Intelligence Downloads.

Now that I know the files are there, how do I know that they are being parsed and loaded to lookups?

The lower half of the Threat Intelligence Audit dashboard has all of the audit logs pertaining to parsing the threat intelligence and loading of it so that is another nice place to look. That said, it is limited to the last 1000 events and if I want to focus on my two downloads, opening it and then adding my own file names might be a good choice.

eventtype=threatintel_internal_logs (SunburstIP.csv OR SunburstDomain.csv)

If I look closely at these two events, I want to highlight what the thrill of victory and the agony of defeat looks like. (Hopefully that resonates with a few of you who grew up watching the Wide World of Sports.) The second event in the image below shows that the IP addresses have been written to the collection. IP addresses are loaded!!!

The first event has thrown an error and this is due to the use of url_domain instead of domain for our field name and this has caused an exception in processing the file. The framework doesn’t know what to do with the downloaded data so it throws an error and moves on. This is definitely something to look for in events and if this error is seen, check the parsing options to ensure the field names used are defined by ES.

At this point I am going to set the domain indicators aside and finish up with the IP address. There are a few intermediate steps that happen that I won’t bore you with, the "Enterprise Security Biology" from .conf2017 covers that in gory detail, but what we are striving for is that the data gets loaded to the KVStore into the various threat collections, depending on the type of indicator.

| inputlookup ip_intel | search description=SunburstIPListing

In this case, I can search the ip_intel table to see if the indicators have been loaded. Because I want to focus on the SunburstIPListing, which if you recall is the description that I added into the parsing options, I can use a | search to narrow my results set to just that list.

From there, the threat intelligence framework takes over and a series of savedsearches run on an on-going basis to correlate events with the different threat collections and write the data to the threat_activity datamodel. The correlation search will then run on a scheduled basis and pluck the new items out of the datamodel and create notables out of them.

I hope this has been helpful and will streamline your onboarding of these threat indicators into your Splunk Enterprise Security instance.

----------------------------------------------------
Thanks!
John Stoner