ATT&CK-ing the Adversary: Episode 3 – Operationalizing ATT&CK with Splunk

This is the final episode in our trilogy, "ATT&CK-ing the Adversary: Episode 1 - A New Hope" and "ATT&CK-ing the Adversary: Episode 2 - Hunting with ATT&CK in Splunk," on MITRE ATT&CK. The first episode focused on what MITRE ATT&CK is, the components that make up ATT&CK and how this information can be used for threat hunting. Our second installment walked through two examples of applying techniques to focus our hunting in Splunk. In this post, we will focus on applying what we learned from our hunting and operationalize it with ATT&CK to assist our security operations.

One thing we talked about earlier in our series was the need to learn from our hunts and operationalize our findings so we can be more efficient. I don’t want my threat hunters to keep hunting for the same things over and over again. I want them to identify new things to hunt for while taking their findings from previous hunts and making them into analytics that the security operations team can use.

Let’s start by revisiting the two hunts we performed in our last episode. The first focused on the “Create Account (T1136)” technique, one of many techniques that make up the “Persistence (TA0003)” tactic. As we saw in the guidance MITRE provided, detection of Windows event code 4720 is a method to use. However, if we are creating new users in an organization, alerting on that event alone in a vacuum is not ideal for security operations.

index=botsv2 source=wineventlog:security EventCode=4720

As we move toward operationalizing our hunts, we need to be cognizant of the quantity and quality of the alerts that are going to be generated. How can we operationalize the Create Account technique? This will depend on exactly what you want your operations team to focus on. Perhaps I can start with my basic search and focus on alerting if these events occur outside a particular time window. Or perhaps I alert when these events occur on specific systems or are initiated by anyone who is not part of a specific whitelist of individuals. Those are just a couple of ideas on how to operationalize against this technique. If we look at Splunk Security Essentials for some additional ideas, we could also evolve the “Create Account (T1136)” technique to focus on New Local Admin Accounts or Short Lived Admin Accounts or New Interactive Logins from a Service Account. You can see how I can take this single technique and broaden this to meet my organizational needs, but thought and consideration need to be put to this so as not to burden the operations team with false positives.

In our second example, we hunted for the “Indicator Removal from Host(T1070)” technique, one of the many “Defensive Evasion (TA0005)” tactics. Similarly, searching for event code 1102 in the Windows event logs was a good place to start. That said, the organization may have unique conditions that make this search unreliable for certain kinds of systems or the level of fidelity may not be sufficient for your organization.

index=botsv2 sourcetype=wineventlog EventCode=1102

We may find that organizationally the “Indicator Removal from Host (T1070)” technique should always fire whenever a Windows event code 1102 is seen because no one should be clearing audit logs and we should always alert on this.

Perhaps we want to understand if the application logs have been cleared or the logging service has been stopped. Maybe we have numerous Windows event logs and we want a more granular view into which logs are being manipulated.

If you recall from our previous blog, if I am running Microsoft Sysmon, I can monitor for wevtutil.exe and the specific flags associated with it. This allows our operations team to be selective in terms of their responsiveness based on the event log that is being cleared. Perhaps other event logs being cleared are less important and can just be logged and monitored as informational only.

Splunk has created Enterprise Security Content Update (ESCU) to facilitate this. In fact, there is an analytic story called Windows Log Manipulation that contains these and other detection analytics that can be easily deployed and then modified as your organization sees fit.

From there, I want to take my correlation searches and contextualize them to MITRE ATT&CK and map them to specific techniques. With a few tweaks to the correlation search and the incident management settings, I can add the technique to the Incident Review screen so the techniques are clearly seen during notable event triage.

From there, my analysts can expand the “Suspicious wevtutil Usage” notable and see what system had event logs cleared, under what account this took place, and additional context around the specific MITRE ATT&CK technique to include a description and the tactic. A workflow action is also added to allow a quick pivot to the MITRE site for more information on specific software and adversary groups leveraging this technique.

One thing we have not touched on in this trilogy is the Lockheed Martin Kill Chain (LMKC). I am going to take a moment before we end to discuss LMKC because it is a complementary model to ATT&CK and in fact, ATT&CK builds on the phases of the LMKC.

The Kill Chain does a great job of outlining specific phases an adversary would move through in a targeted attack. It provides an understanding of how an adversary would take the time to perform their reconnaissance and weaponize an entity that is then delivered to the target. When the weaponized entity—be it a URL or an attachment—is opened, it exploits the victim through execution and the adversary gains a foothold which is then used to communicate with a remote system that provides command and control. At that point, the adversary can issue commands back to the target systems and take actions on the objective.

The second half of the kill chain from exploit forward utilizes a number of varied tactics and techniques that an adversary will use to perform the mission it is attempting. This is where MITRE ATT&CK lives. Different techniques and tactics are not limited just to the exploit portion of the kill chain but can span across multiple phases. Using ATT&CK allows us to hypothesize on a specific technique to hunt across all latter phases of the kill chain. ATT&CK provides us a greater level of flexibility. In fact, you may notice that the ATT&CK model’s phases are loosely based on the LMKC. This is not by accident.
^{(https://attack.mitre.org/resources/enterprise-introduction/)}

You may also be thinking, well that sounds very interesting but what about the stuff that happens to the left of the exploit? Is there something that addresses those stages? In fact, there is! MITRE has a complementary framework called PRE-ATT&CK that aligns to tactics and techniques that occur prior to exploit.

I hope this trilogy provides you with a better understanding of what the MITRE ATT&CK framework is. Using ATT&CK will drive a greater understanding of the adversary techniques used while providing a starting point for your hunts and help guide your SOC to focus on the alerts that are most relevant to your organization.

As we mentioned earlier, as you move towards operationalization, remember that Splunk is using MITRE ATT&CK in its Enterprise Security Content Update and Security Essentials apps to better contextualize the analytics. With that, you’ve got everything now!

Happy Hunting!

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