The MITRE ATT&CK® Framework for Enterprise is an invaluable resource used by the security community to describe the “why” and “how” of intrusions with standardized language. The framework provides a linear story-telling resource that offers insight and context into each action taken by a threat actor as they progress through their tactical objectives.
As specific threat actors are observed more and more, patterns in the tactics, techniques, and procedures (TTPs) they use begin to emerge. This can involve specific utilities, malware or offensive security tools, or even copied and pasted commands. The threat actor’s repeated sequence of actions or decision tree logic can be referenced from a playbook, for example, and security analysts can use this predictability and repeatability to their detection advantage. If we zoom out from procedures and focus on sequences of techniques, we observe different threat actors making similar tactical decisions that can be detected regardless of the underlying procedure that’s used. This approach transcends specific threat actors, malware families, and attack vectors, making your detection capabilities more resilient to the ever-changing threat landscape.
With the ever expanding corpus of signatures that security teams must develop and maintain, a meaningful approach to alert and hunting lead refinement and noise reduction is a critical necessity. With the introduction of composite detection rules in Google Security Operations that match against combinations of ATT&CK elements, we aim to leverage the expertise of Mandiant and Google Threat Intelligence along with the interdependent nature of ATT&CK tactics and techniques to provide a threat-agnostic approach for detection.
Composite Rule examples that leverage MITRE ATT&CK
Our MITRE ATT&CK detection approach leverages composite detections, which uses individual alerts and detections as building blocks that, once assembled, can surface threat actor behaviors with greater specificity. We start with very simple detection content with granularity down to the ATT&CK procedure level, and we rely on composite detections to apply context and meaning to a grouping of detections.
To learn more about composite detection rule fundamentals and how to build your first composite rule, please see the following resources as pre-requisite reading:
- Google SecOps: Elevate Your Threat Detection Capabilities with Composite Detections - https://security.googlecloudcommunity.com/community-blog-42/google-secops-elevate-your-threat-detection-capabilities-with-composite-detections-3971
- New to Google SecOps: Composite Rule Fundamentals - https://security.googlecloudcommunity.com/community-blog-42/new-to-google-secops-composite-rule-fundamentals-3979
- New to Google SecOps: Building Your First Composite Rule - https://security.googlecloudcommunity.com/community-blog-42/new-to-google-secops-building-your-first-composite-rule-3982
Let’s take a look at ATT&CK composite detection rule examples that reference two or more Discovery techniques. Independently, there may be hundreds of thousands of individual events associated with the collection of user, system, or network information across an environment. However, the co-occurrence of these events, such domain trust discovery and permission groups discovery, in close proximity to one another can make them much more interesting. Let’s take a look at a series of Discovery related commands that were used by an actual threat actor:
| net user krbtgt /domain |
To approach this activity from a detection engineer’s perspective, we could start by assigning ATT&CK technique IDs to each of the commands.
| Command | MITRE ATT&CK Technique |
| net user krbtgt /domain | |
| net group "Domain Admins" /domain | |
| net group "Domain Controllers" /domain | |
| nltest /trusted_domains |
We can then start by writing simple detections that are deliberately broad and inclusionary. For example, to identify the use of the native Windows `net.exe` utility to perform permissions group discovery for domain groups, we could create a signature that looks something like:
| rule methodology_t1069_002_net_permissions_group_discovery_domain_accounts { meta: rule_name = "Net Permissions Group Discovery for Domain Accounts" description = "Detects on the execution of the Windows net.exe utility to enumerate accounts that are members of domain groups." tactic = "TA0007" // Discovery technique = "T1069.002" // Permission Groups Discovery: Domain Groups severity = "Info"
Events: ( $e.target.process.file.full_path = /net\.exe$/ nocase or (//net1.exe not launched by net.exe $e.target.process.file.full_path = /net1\.exe$/ nocase and not $e.principal.process.file.full_path = /net\.exe$/ nocase ) ) and (//net group $e.target.process.command_line = /\sgroup\s/ nocase or ( //net localgroup /domain $e.target.process.command_line = /\slocalgroup\s/ nocase and $e.target.process.command_line = /\/domain/ nocase ) ) $asset = $e.principal.asset_id $user = $e.principal.user.userid $command = $e.target.process.command_line $asset,$user over 5m
$command_lines = array_distinct($command) if( //Increase risk score if privileged group re.regex(arrays.join_string($command_lines, "|"), /Domain Admins|Enterprise Admins|Backup Operators|Server Operators|Schema Admins|Event Log Readers|Hyper-V Administrators|Exchange Trusted Subsystem/) nocase, 25 ) $risk_score = 10 + $privileged_group_risk_score $e }
|
Pretty straightforward, right? And we can do the same for the other Discovery commands that we observed. Now, you may not want to generate an alert based on one of these detections alone. But, how could we approach generating an alert if we observe two or more of these detections firing within a short period of time? You could create separate multi-event rules to detect a co-occurrence of these commands, but the rules could become quite large and difficult to manage, and you would lose the ability to use the underlying detections as building blocks for other rules. Or, as an alternative, you could use these individual rules as building blocks and approach this with a composite detection that matches against the ATT&CK technique IDs in the metadata section. Let’s see how this may look as a signature:
| rule c_mitre_ttps_t1482_t1069 { meta: rule_name = "Domain Trust Discovery and Permission Groups Discovery" description = "Detects on Domain Trust Discovery and Permission Groups Discovery events occurring in close proximity." tactic = "TA0007" // Discovery technique = "T1482" // Domain Trust Discovery severity = "Low"
events: $c1.detection.detection.rule_labels["technique"] = /^T1482|^T1069/ $asset_id = $c1.detection.collection_elements.references.event.principal.asset_id $asset_id over 10m
$risk_score = 35 $unique_mitre_technique_count = count_distinct($c1.detection.detection.rule_labels["technique"]) $unique_mitre_technique_cd = array_distinct($c1.detection.detection.rule_labels["technique"])
$c1 and $unique_mitre_technique_count >= 2 and arrays.contains($unique_mitre_technique_cd, "T1482") }
|
Now we have a way to generate a more meaningful detection that’s not dependent on hard-coded ATT&CK procedures and can match against the broad strokes of threat actor activity.
What if you wanted to zoom out further from ATT&CK techniques and look more broadly for activity across two or more ATT&CK tactics? We could approach this in a similar way:
| rule c_mitre_ttps_command_and_control_multi_discovery { rule_name = "Command and Control + Multiple Discovery Tactics" description = "Detects one Command and Control rule detection and multiple Discovery rule detections occurring in close proximity." severity = "Low" $c1.detection.detection.rule_labels["tactic"] = /TA0011|TA0007/
$asset_id over 3h $risk_score = 35 $unique_mitre_tactic_count = count_distinct($c1.detection.detection.rule_labels["tactic"]) $discovery_rule_count = count($discovery_rule)
$c1 and $unique_mitre_technique_count >= 3 and $unique_mitre_tactic_count >= 2 and $discovery_rule_count >= 2 }
|
How can you begin using these MITRE ATT&CK Composite Detection Rules?
The signatures shown above and more will be included in a new Endpoint Composite Rules pack that will be released within Google SecOps Curated Detections. You can build your own versions of composite detection rules that reference combinations of ATT&CK techniques and tactics, or you can leverage the new rule pack to generate alerts or detections within your Google Security Operations instance. To accomplish this, you’ll need to perform the following steps:
- Ensure that the Endpoint Composite Rules pack is enabled for precise and broad detections in the Curated Detections section of your Google Security Operations instance.
- Add or update the following values to the metadata section of your existing custom rules (example below):
- tactic = "TA000#" // Note: This uses the tactic identifier value
- technique = "T1###.###” // Note: This is the technique identifier value
| rule methodology_t1564_012_path_exclusion_added_to_windows_defender { rule_name = "Path Exclusion Added To Windows Defender" description = "Detects threat actors excluding specific file paths from Windows Defender scanning. Threat actors will modify the Windows Defender service settings to prevent detection and quarantine of their malware and utilities." tactic = "TA0005" // Defense Evasion technique = "T1564.012" // File/Path Exclusions
|
Once you verify that the metadata has been updated in your custom rules, you should begin seeing the MITRE ATT&CK Composite Rules in your detection or alert queues. And as always, perform this testing iteratively to monitor for tuning opportunities and to ensure an optimal volume of detections.