You Cannot Detect Techniques in the Execution Tactic! And What To Do Instead
Summary: There is a difference between a rule detecting a technique vs detecting a lower tier on the pyramid of pain that might be related to a technique. As an attack medium, techniques in the Execution tactic are closer to Data Sources than other ATT&CK Techniques. This means that Execution techniques can only be detected directly by banning them, with the exception of whitelisted sources.
I’ve been obsessing about detection coverage lately. Doctrines like “assumed breach” taught us to never take a break, but we still need a method to gauge where the weak points are compared to everything else. This is why a lot of us use Coverage Graphs.
I’ve seen enough people black out the Pre-ATT&CK tactics of Reconnaissance and Resource Development. The argument there is twofold: you cannot detect the attack before if happens and if you can, it most likely would be highly noisy or not very useful. I’m going to make the argument here that the Execution Tactic deserves a similar special treatment.
The above is a coverage graph I created for Sigma. You can download the ATT&CK Navigator layer file here. You can find instructions on how to load the file at the link as well.
Detection Vs. Relation
There are a few assumptions we make when we use Coverage Graphs, all of which I plan to dissect in due time (You know the drill. Follow for more updates, don’t forget to click the email icon, yada yada yada). For now, I want to make a distinction between two things, detection rules that detect a technique and detection rules that are related to a technique.
A detection rule that detects a technique would at least make it considerably more difficult to use this technique in the monitored environment. Take for example the Sigma rule “New DLL Added to AppInit_DLLs Registry Key”. The rule detects ATT&CK technique “Event Triggered Execution: AppInit DLLs” by monitoring the registry keys used by AppInit. That is, the attacker cannot use this technique without changing these registry keys. So unless the attacker can figure out a way to change the registry keys without triggering the related events, you can assume that this technique is reasonably covered and can move on to the next one.
But shouldn’t all detection rules make it “more difficult to use a technique?” At least, any properly written rule? Not really. David Bianco’s Pyramid of Pain still applies here. A rule that detects execution of Mimikatz.exe does not detect Credential Dumping as a technique. At most, we can say that it detects a tool. Similarly, blacklisting a IP address or domain that is known to used as a C2 server does not detect any Command and Control technique. This does not mean that these detection rules are not useful, we just need to make sure we tag them as related to a technique, not detecting those techniques.
The Execution Tactic
This is where coverage graphs get confusing. Without distinguishing between Detection and Relation, there is no way to to determine the strength of coverage per technique. Case in point, in the aforementioned Sigma coverage graph, the technique with the most rules is T1059.001 (Command and Scripting Interpreter: PowerShell) with a whopping 165 rules. That’s more than the next two techniques combined!
Except, what does it mean to have good coverage for Powershell? What is the malicious behaviour that these rules are detecting? Attackers don’t use Powershell as a goal in of itself. They use it to do something else. They use it to escalate privileges, establish persistence, do discovery, or literally any other tactic. That is, there should always be another technique tagged to any rule where the Execution tactic is tagged.
Going back to Mimikatz, detecting the execution of Invoke-Mimikatz is not detecting Powershell execution. That’s not the interesting part. It is the Credential Dumping that we’re interested in detecting. So tagging you rule as detecting “Powershell” does not really add much value.
But here’s my point, if we use my definition of Detection Vs. Relation, I would argue that you cannot Detect a technique in the Execution tactic because there is no defined malicious behaviour associated with Execution by itself. For example, the only way to cover Powershell would be to monitor every usage of Powershell, whitelist expected usage, and trigger on any usage of Powershell, effectively banning Powershell as an execution medium for anything but whitelisted sources. As difficult as that may sound, it is still far easier than other Execution techniques like Native API, WMI, or COM, which between the three of them cover most of the Windows operating system.
Following this logic, Execution techniques are somewhere between Techniques and Data Sources as defined in ATT&CK. So if we consider the 165 Sigma rules tagged with Powershell, we can interpret the number as saying that there are at least 165 rules that use Powershell as a data source, which might be a useful number, but it should not be used to measure the extent of coverage.
Then again, as with everything we do with ATT&CK, there are exceptions. Services and Scheduled tasks are not frequently updated on most systems that a method of whitelisting expected services or scheduled tasks is a viable coverage method in some environments. Even Powershell is feasibly whitelisted if you allow only digitally signed scripts, or even allow scripts signed by specific sources, but that remains very different from the way we tag detection rules today.
In summary, we need a method of distinguishing between rules that detect a technique and those that detect lower level tiers in the pyramid of pain but are still related to certain techniques. Execution techniques can only be detected if they are effectively banned except for a few whitelisted sources.
P.S. If you’re interested in Threat Hunting or Detection Engineering, you may be interested in checking out our newsletter at the link here: https://threathuntersdigest.substack.com
