What’s included in this section?
We’ve written extensive analysis of 12 ATT&CK techniques and sub-techniques. Each technique-specific section includes:
- a brief analysis of how and why adversaries leverage a given technique
- descriptions of MITRE ATT&CK data sources that offer visibility into the technique (e.g., command monitoring, process monitoring, etc.)
- guidance on the tooling or logs that will enable you to collect those data sources (e.g., EDR, Sysmon, AMSI, Windows Events. etc.)
- specific examples of how you can use that telemetry to detect adversaries abusing the technique
- individual tests for emulating how adversaries abuse the technique to validate that you can observe or detect it
The bottom line
Examined holistically, the list of prevalent techniques showcased in this report suggests that if you can detect threats relatively early in the intrusion lifecycle, you’re much less likely to face the consequences of a significant cyber intrusions. This principle has saved many of our customers from immeasurable grief over the years.
To that point, we mostly detect adversaries as they’re setting the stage for later, more impactful actions. We catch them attempting to abuse native operating system utilities to execute code or bring in custom tooling. We catch them elevating their privilege levels to get deeper access to compromised systems. We catch them establishing persistence so they can maintain their presence. We catch them manipulating our customers’ defensive controls to evade prevention or detection. These are necessary means to an end—whether the goal is to conduct espionage, a ransomware attack, or something else altogether. When we disrupt these means, we prevent their ends.
This is precisely why exfiltration and impact techniques (e.g., ransomware) don’t rank highly on our list. The following heatmap shows the distribution of the 20 most prevalent techniques across the ATT&CK matrix.
This isn’t to suggest that we never encounter ransomware. In fact, we routinely encounter ransomware threats through short-term engagements with our many incident response partners. However, we monitor far more customers full time than we do via IR engagements, and therefore, these ransomware incidents represent only a small fraction of our overall detection volume.
Interestingly, if we create a heatmap like the one above where we only include detections from our incident response work, we see a slightly different arrangement of techniques that does include impact tactics—as well as more defense evasion, more lateral movement, and less execution. This makes sense because in incident response engagements we are entering environments where a lot of the preliminary activity—the stuff we generally catch early for our full-time customers—has already occurred. In other words, we’re already at the impactful part of the incident.
How to use our analysis
If your organization is able to follow the visibility, collection, and detection guidance in this report, you can effectively improve your defense-in-depth against the adversary actions that often lead to a serious incident. Of course, this is easier said than done. There are countless prerequisites to operationalizing this report, ranging from configuration challenges to developing plumbing that allows you to move telemetry from its source to its destination—whether that’s a SIEM or some other aggregation point.
However, this analysis is still useful for practitioners or leaders who aren’t immediately ready to operationalize it. For leaders, the most prevalent techniques can help you identify gaps as you develop a road map for improving coverage. You can assess your existing sources of collection against the ones listed in this report to inform your investments in new tools and personnel.
As a practitioner, you’ll gain a better understanding of common adversary actions and what’s likely to occur if an adversary gains access to your environment. You’ll learn what malicious looks like in the form of telemetry and the many places you can look to find that telemetry. You’ll gain familiarity with the principles of detection engineering by studying our detection opportunities. At a bare minimum, you and your team will be armed with hyper-relevant and easy-to-use Atomic Red Team tests that you can leverage to ensure that your existing security tooling does what you think it’s supposed to do.
What’s missing and why?
Red Canary is actively adopting new data sources that reach beyond the endpoint to enhance our detection, investigation, and incident handling capabilities, and you’ll see evidence of this throughout the techniques section—particularly in the visibility, collection, and detection subsections. Even so, the majority of our detection analytics are based on endpoint telemetry and the majority of the endpoints we monitor are client workstations. This reality shapes our perspective and the contents of this report.
Given our vantage point and the defense-in-depth our detection analytics offer, we tend to detect the adversary behaviors that happen just after initial access. As a result, execution, privilege escalation, persistence, and defense evasion techniques are probably overemphasized in our report. On the other hand, one of the most prevalent forms of initial access—email-based phishing—is underrepresented. Under no circumstance should anyone interpret these findings to suggest that phishing protection is unimportant. To the contrary, phishing is among the most prevalent ways that adversaries initially access our customers’ environments, and the data in this report does reflect a great number of email-borne threats. However, Red Canary doesn’t have as much early-stage visibility into phishing as we do into other techniques, which is precisely why this report works best as a complement to other reports from vendors with different vantage points—like those who make firewalls or email-monitoring products.
Further, discovery techniques are also underrepresented in this report. This is because discovery techniques can be incredibly noisy, generating prohibitively high volumes of false positives for our detection engineers. Beyond that, discovery-related alerts aren’t always actionable since, for example, you can’t really prevent someone from scanning a public-facing resource. This isn’t to say we don’t inform our customers of discovery activity. We absolutely do, but it’s typically done manually by our detection engineers as they’re analyzing potentially malicious events. Since our ATT&CK mapping happens at the detection-analytic level, prior to human analysis, the discovery activity isn’t included in this report.
One final note: we overwhelmingly monitor Windows endpoints, and therefore we’ve included only limited information about macOS and Linux techniques in this section. To be very clear, we have robust detection coverage for macOS and Linux threats, but this report reflects the reality that Windows continues to dominate the enterprise marketplace.