29APR2019

Dear Buttercup,

Thank you for explaining how threat intelligence can help inform my analysts. That's fantastic. However, where do I start? It seems so unfair, and I want to cry. Can you point me in the right direction?

Sincerely,
Little Drummer Boy from Oneonta, NY

–

Little Drummer Boy,

You seem very morose. I think you may want to consider your choice in 80s British indie music when writing to me.

Previously we had discussed the value of threat intelligence, and it sounds like we have satisfied your needs there, but figuring out where to start is a challenge. With that in mind, let's look at using the most relevant threat intelligence available to you—local threat intelligence.

Local threat intelligence provides us the opportunity to focus on high-impact events (because they have affected us previously) as well as provide a place to start without getting overrun by lower fidelity alerts. If you recall from my response to your earlier letter about threat intel, there's a vast array of threat intelligence, but not all of it is relevant to every organization.

Now, I could take a file hash or an IP address and show you how local threat intelligence can be used to match events coming into your organization, but if you recall from David Bianco’s Pyramid of Pain, file hashes and IP addresses are nice but easy for an adversary to change. That’s not to say we shouldn’t monitor for these values, but I would like to take your through two scenarios—one working with an IP address, and a second where we investigate that IP address and identify additional threat intelligence and raise the pain for the adversary.

We receive a tip from $LEO that the IP address 45.77.65.211 has targeted our organization. It's simple to add this to Splunk Enterprise Security (ES), and as soon as we do that, we can start correlating new events with this indicator. To add it, we can navigate in ES to the local IP intel list by clicking on:

Configure -> Content Management -> Lookup -> Local IP Intel

Adding the indicator is as easy as creating a new line and inserting the IP address and a brief description. Once your indicator has been added, click Save.

At that point, a backend process will run to integrate the new local threat intelligence with other threat intelligence you have already collected. In a few short minutes, open the following dashboard:

Security Intelligence -> Threat Intelligence -> Threat Artifacts

This step is not mandatory to integrate local threat intelligence into Splunk ES, but it serves as an excellent way to ensure that your indicator has been properly ingested.

With this is in place, I can patiently go about my day knowing that as soon as I get a match on that IP address, I will see a notable event associated with it. Because I know that this IP address is crucial to my organization, I could prioritize this notable event over other threat intel.

That's an excellent basic example of taking an IP address and quickly incorporating it into our threat intelligence framework and looking for new events. Now let's look at our other scenario where we can create our local threat intelligence and work our way up the Pyramid of Pain to make it harder for the adversary to escape detection!

Let's take that same IP address (45.77.65.211) and this time, let's do a little investigation to see where this has been seen previously in our organization. As I look at the SSL Search dashboard, I see that the IP address communicated with some hosts on August 23, 2017. The ssl_subject, ssl_issuer, ssl_serial and ssl_hash are now associated with this IP address, making them interesting observables and should be considered part of our threat intelligence collection. Remember from the Pyramid of Pain that the IP address could be easily swapped out by an adversary, but the SSL certificate that is part of the attacker infrastructure would likely take a more significant effort to replace depending upon the size of the infrastructure.

Let’s take our certificate indicator and insert it into the local certificate intel list in Splunk ES by clicking on:

Configure -> Content Management -> Lookup -> Local Certificate Intel

Adding the indicator is as easy as creating a new line and inserting the values that we have available to us. I am specifically interested in the certificate_serial field, but there are additional fields we can add. As always, a comment is a good idea so that other analysts can see why a specific indicator was added.

Once your indicator has been added, click Save.

Now that our certificate serial number has loaded, we can be assured that it will be available for correlation when events are ingested that have a matching certificate.

At this point, there isn’t much else to do with this serial number until a correlation occurs. Again if you want to know everything that happens behind the scenes, check out my talk from .conf17 entitled "Enterprise Security Biology: Dissecting the Threat Intelligence Framework."

The end state is a notable event in Incident Review. As we dig into the notable event, we can see a couple of exciting things.

We can see that the destination address is different than the previous address. The first two octets are the same for what that's worth. Investigating the IP address and its ownership is probably a wise idea. We can also see two internal IP addresses are using this SSL certificate to communicate to that IP address; I should probably investigate those systems too.

When we look at the threat intelligence data, we can see that the serial number was part of the certificate_intel threat collection and is part of the local threat group as well as providing the matching field and value (in this case, the serial number). None of this is a surprise for this single example, but having this additional context when tracking multiple lists of threat intelligence can be helpful.

At this point, I've taken an indicator that was pulled from my system in August 2017 and successfully applied it to events that are occurring on my network in January 2019. Perhaps the adversary went away for a while, but it appears they're back. The good news is that by taking the threat intelligence we previously captured, we can quickly identify the adversary infrastructure and our victim systems and shift into incident response mode quickly while also taking preventative measures.

I hope this illustrates the value of employing local threat intelligence, whether it's as simple as taking a known bad IP address and inserting it into Splunk ES, or doing some additional investigation first and then taking other indicators associated with that IP and loading them into Splunk. Either way, the value of locally cultivated threat intel cannot be understated. Splunk ES can leverage this threat intel; you just need to load it into your local threat intel lists!

Sincerely,
Buttercup

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