In this blog post I will be going over a simple use case for the Threat Artifacts dashboard that was introduced in Enterprise Security 3.3. To start, the Threat Artifacts dashboard was built to assist analysts in the investigation of events, as well as research into malicious entities, and is meant to serve as a window into the threat intelligence that is stored in the Splunk App for Enterprise Security. I kind of like to think of it as a Threat Intelligence Library.
The dashboard contains a “Threat Artifact” ToggleInputView that allows a user to select the type of form inputs they wish to use to search through their intel. These are as follows:
- Threat ID
In addition, the dashboard contains tabbed views of each of the different intel categories, beginning with a “Threat Overview” of all your intel, and followed by tabs for Network, Endpoint, Email, and Certificate Intelligence. When using the form inputs to filter through your intel, each tab will be populated to show the user all intel related to that query.
Moving forward with our use case, lets begin in the Incident Review Dashboard. Here we can see that we’ve started triaging the Threat Activity Detected notable events. These notables encompass all the matches between data stored in our Threat Intelligence Framework and data ingested by Splunk. (Note: For details on which fields are used for matching please see: http://blogs.splunk.com/2015/04/30/threat-intelligence-collections-in-enterprise-security-3-3/)
Now as analysts, our main goal in triaging these events is to determine whether or not the events we’re looking at are false positives or true positives. And when a true positive is found, assess the severity and criticality of the event, based on it’s potential impact to our organization. To do this, we need as much information about a particular event that we can get to make an informed decision. Expanding a notable event, we can already begin to see some of the additional context our updated intel framework provides.
Within the “Additional Fields” section of the event we’ve included a number of fields that relate to the attribution of the matching intel artifact. Scrolling down, we can immediately see the Threat Category of the event is APT (or Advanced Persistent Threat), which places this right at the top of our things to do list. We can also see the Threat Groups associated with this event, as well as a Threat Description.
Knowing that this threat is associated with Poison Ivy and that it matched on a remote IP, we can already begin to suspect that this may be related to Command and Control traffic. To give us a better understanding of what we’re dealing with, we can lookup the Threat Source ID from the notable event in the Threat Artifacts dashboard and see all intel associated with it.
From the Threat Overview tab, we can see the source of the intel as well as a count of artifacts that are used in matching against the data indexed in Splunk Enterprise. Though it does not appear as though we have any Email or Certificate Intel in relation to this source, it does show us that we have a number of IPs, Domains, and Endpoint artifacts that are related.
Jumping into the Network Tab we can see all the IPs, Domains, and HTTP Intel associated with this source. In addition we can expand the rows in our IP intel to give us additional information related to an entry.
Looking at the Endpoint Tab we can see all of its associated intel, which in this case appears to be a list of hashes. Also note that we can expand the threat_group cell to show the complete multi-valued (MV) list of threat_groups associated with these entries.
Now that we have somewhat of a broader understanding of the artifacts associated with the notable event we are investigating, lets move forward and attempt to validate it by hopping over to search to see if we can identify the original event that resulted in the creation of this notable.
By searching for the affected system (220.127.116.11) as well as the threat match field in the notable (18.104.22.168), we can see all the events that contain both these values. Right off the bat we see FireEye CEF alerts for a malware callback from the affected system to the malicious IP detected in the notable event. This confirms our suspicions that the traffic is related to command and control communication and gives us enough validation to warrant additional analysis of the affected system. We wont go into detail on how to do this here but one could imagine that the analysis would start with exhausting all the resources available in Splunk Enterprise. Then moving to third party resources for acquiring additional forensics data for analysis.
Hopefully this simple use case has shown you a glimpse into how the Threat Artifacts dashboard can be used as a tool to assist analysts in gaining additional context and information around a potential threat. Please feel free to post and discuss any questions, comments, suggestions, or even use cases of your own in the comments section below.