- What MITRE ATT&CK is
- The components that make up ATT&CK
- How this information can be used for threat hunting
When threat hunting, we have discussed the need to form a hypothesis and then hunt to confirm or refute that hypothesis. Developing this hypothesis can take a number of different forms which I won’t cover today, but I will mention there is a lot of great material out there on that topic. Today, I will use the MITRE ATT&CK framework as the basis of my hypothesis development and will use it to help guide my hunt.
Let’s use the fictitious homebrewing organization company Frothly (of Boss of the SOC fame) as an example. Frothly has received threat intelligence indicators of compromise (IOCs) from a prominent law enforcement agency that links the adversary group Taedonggang to attacks against Frothly. Using this threat intelligence data, we can hunt for any number of things, but by using the ATT&CK framework, I am already focused on looking for events pertaining to exploitation and post-exploitation. Depending on what I find, I may be able to move to earlier phases like delivery of the exploit or the kinds of reconnaissance that may have occurred.
Now that we have our scenario, we will perform two hunts using different techniques from MITRE ATT&CK. The first will be to hunt for indicators of account creation that would be associated with persistence. Our second hunt will be around removing indicators from a host that would be associated with defensive evasion.
In our first example, we can reference the ATT&CK site and see that there are 58 techniques currently listed as “Persistence (TA0003)” techniques. These range far and wide, but because we have Windows Event logs readily available to us, we could start by hypothesizing that our adversary will attempt to establish persistence by creating their own user account on victim machines. The specific technique is called “Create Account (T1136)” and in reviewing the MITRE wiki, I can see that a number of other adversary groups use this technique as well. I can also see that MITRE suggests that event code 4720 indicates account creation, so that gives us a good place to start.
My first search will be broad and over a fairly wide swath of time. Depending on the intelligence I have or other factors, I may be able to bound that search further.
index=botsv2 source=wineventlog:security EventCode=4720
In my result set, I find a few Windows event code 4720 events. When I expand one, I see the event above. I need to understand what the event code is telling me, so some quick research on Microsoft’s site on event code 4720 may be in order.
Based on my research, I can see that a user named “service3” created a new account called “svcvnc” on a system named mercury. I can also see that there were no additional attributes set. With that basic understanding, I could go hunt to see if any other systems had these same characteristics.
My next search would be to continue down this path and see if this new account name is in other Windows events. This time I will table the output to see when the events occurred, on what systems and what usernames are associated with it.
index=botsv2 source=wineventlog:security EventCode=4720 Account_Name=svcvnc
| table _time host Account_Name SAM_Account_Name
Based on our results, the system mercury is not the only one impacted. It is also interesting to see that service3 is referenced in three events, but another username is associated with a fourth event. This provides additional information that I can then search off of and continue to evolve my hunt.
Remember, my end goal is to either confirm or refute the hypothesis around account creation to establish persistence on Frothly systems. At this point, I have a pretty good idea that this is occurring, but my subsequent searches will help me understand the scope of this activity and potentially help me uncover if the adversary does this in a particular manner. For example, are specific attributes set by the adversary when these accounts are created? Are other events being created as well that provide insight into group membership as well? If so, what groups are these accounts being assigned to?
Another hunt I may want to undertake is to understand what kinds of “Defensive Evasion (TA0005)” tactics the adversary might take after having gained a foothold in Frothly. Because there are over 50 different techniques for defensive evasion, I will want to identify a specific technique to focus on initially.
Defensive Evasion Techniques Source: MITRE
If my hypothesis is too broad, I end up with an unproductive hunt that is a waste of time and resources and I am no closer to achieving my goal. Instead, I can focus on a specific technique, such as “Indicator Removal from Host (T1070).” This provides a greater level of specificity and helps provide a boundary to my hunt.
According to the MITRE ATT&CK site, the “Indicator Removal from Host (T1070)” technique states “Adversaries may delete or alter generated artifacts on a host system, including logs and potentially captured files such as quarantined malware. Locations and format of logs will vary, but typical organic system logs are captured as Windows events or Linux/macOS files such as Bash History and /var/log/* .” With that description, I can start searching Windows Event Logs and look for event code 1102, which would indicate the audit log is cleared. For dedicated readers of our "Hunting with Splunk" blog series, you may recall this Windows event code was briefly mentioned.
index=botsv2 sourcetype=wineventlog EventCode=1102
Now this search alone is very broad, so a time boundary is important to add. I may want to tighten this search by identifying specific enclaves or systems to focus on. If I do get a hit, I will want to understand more about the systems that this occurred on as well as the user(s) initiating this activity. If there are specific occasions when this occurs, we should make sure they are documented and factored into future hunts. What if I wasn’t collecting Windows event code 1102 events for some reason but I still wanted to hunt using this technique? I could search for systems where wevtutil.exe was executed with the cl flag. The cl flag indicates that specific log files being cleared.
index=botsv2 sourcetype="xmlwineventlog:microsoft-windows-sysmon/operational" wevtutil.exe CommandLine=*cl* EventDescription!="Process Terminate"
| table _time host user CommandLine ParentCommandLine
In our search results, we notice that the ParentCommandLine has PowerShell execution with encoded data strings. “PowerShell (T1086)” and “Data Encoding (T1132)” are two more ATT&CK techniques, so while our hunt for “Indicator Removal from Host (T1070)” may be ending with a finding that service3 initiated the log clearing of many logs on wrk-klagerf, I also uncovered the need to learn more about why encoded PowerShell is being used within the organization (and causing logs to be deleted!). Perhaps I should research what software uses encoded PowerShell and if this is a collection of techniques that Taedonggang uses, that is good to understand as well!
A word of caution—just because an adversary is listed as using a specific technique does not guarantee that they are the only ones using that technique nor does it mean that the named specific adversary is targeting your organization. It does provide some clues though and might assist you in determining if your next hunt should be for additional techniques that an identified adversary uses. The adversary groups being tracked are not just nation state actors like APT1, APT28 and APT29. If you are concerned that you are being targeted by financially motivated threat actors like FIN5 or FIN6, then observing their techniques and hunting for those techniques would be advisable.
With that, we will wrap up this second episode of our look at MITRE ATT&CK and using its technique to start threat hunting. What’s next you ask? Operationalizing with ATT&CK, so stretch out and wait.
Until next time,