"New to Google SecOps" is a deep-dive series by Google Cloud Principal Security Strategist John Stoner which provides practical guidance for security teams that are either new to SIEM or replacing their SIEM with Google SecOps.
Previously, I introduced contextual awareness and demonstrated how entity data is automatically enriched into events for analysts to use when searching–provided you are loading this data into Google SecOps.
Today, let’s move forward and show how to apply this capability to our YARA-L rules. To ensure everyone is on the same page, we will start with the search we used at the end of the contextual awareness post. We are looking for process command lines that execute the net use command that then attempt to map to C$, ADMIN$ or IPC$.
metadata.event_type = "PROCESS_LAUNCH" AND target.process.command_line = /net.*use.*(c|admin|ipc)\\$/ nocase
We can easily convert this search to a YARA-L rule. Here is what that search looks like converted to a rule.
rule mitre_attack_T1021_002_windows_admin_share {
meta:
author = "Google Cloud Security"
description = "Net use commands for SMB/Windows admin shares"
reference = "https://attack.mitre.org/techniques/T1021/002/"
events:
$process.target.process.command_line = /net.*use.*(C|ADMIN|IPC)\\$/ nocase
$process.principal.user.userid = $userid
match:
$userid over 5m
condition:
$process
}
The Detections screen indicates this rule is detecting the activity for both Sysmon and Windows event data. So far, so good.
Creating a Rule Based on Contextual Enrichment
The detection results indicate that there are Information Technology (IT) users accessing these administrative shares. For this example, this access is part of an IT user's normal workflow and alerting on every event may not be ideal. We can refine our rule to eliminate the members of the IT department.
To do so, we can refer back to our blog on single event rules, where we mentioned that the events section of YARA-L is where our criteria resides. Because we are associating an event with an entity, you might be thinking we need to apply the concepts of a multi-event rule to join the event data to the entity. Depending on the fields we are looking to leverage in our rules, we may not need to.
So, you are saying the answer is that it depends…
Yes, it does depend. If you recall, Google SecOps automatically enriches UDM events with entity values for users and assets. Fields that contain entity information like department, company, title, and address are automatically enriched in UDM if you are ingesting contextual data like Workspace, Active Directory and the like. Therefore, we don’t need to join the events and entities together to update our rule to filter out the IT department; we can use the fields that exist in the UDM events. Below, we’ve added criteria (line 11) that uses enriched entity data in the event to refine the rule. Nothing else changes in the match or condition sections of the rule.
rule mitre_attack_T1021_002_windows_admin_share_with_entity {
meta:
author = "Google Cloud Security"
description = "Net use commands for SMB/Windows admin shares"
reference = "https://attack.mitre.org/techniques/T1021/002/"
events:
$process.target.process.command_line = /net.*use.*(C|ADMIN|IPC)\\$/ nocase
$process.principal.user.userid = $userid
$process.principal.user.department != "Information Technology"
match:
$userid over 5m
condition:
$process
}In the results, the principal.user.department column is added, and we can see that a user from the Marketing department has been detected using the net.exe command to create the admin shares.
Pro tip: checking out the columns available in the Detections screen or in the UDM search will help identify different enriched content you can use to refine your rules!
Creating a Rule with User Context from the Entity Graph
Alright, we demonstrated how entity data that has been enriched into UDM can be used for rules. But what if we wanted to bound our rule based on contextual data that is not enriched into the UDM event? Group membership of an asset or user is not enriched into the UDM event, but we can still write our rule to focus on a group.
Let’s use the same rule we have been working with, but this time, let’s focus on alerting when an admin share is being used by someone who is a member of the domain administrator (Domain Admins) group. Admittedly this may not be the best rule to focus on our domain admins, but the concept is very important because of the power a domain admin account has. So, if we can trigger this rule based on the user’s group, we can apply the same concept to any rule.
In this example, lines 11-13 are the criteria that make up the entity portion of the rule. Line 11 joins the event and the entity graph, where all of our entities and context is stored, with a common value using a placeholder variable. Line 12 describes the entity as being a user. The addition of this criteria is considered a best practice to focus the rule on just user entities. Finally, line 13 focuses our rule on the group that this rule applies to. The any in front of $user.graph.relations.entity.group.group_display_name is used with repeated fields, a field that can have a list of values in it. Prepending any to this line will allow the rules engine to evaluate each group name individually and will meet our criteria even if only a single match occurs.
Last but not least, because this rule is referencing both event variables, $process and $user, we need to ensure they are both found in the condition section of the rule. I used this naming convention to clearly define the event and the entity in my detection. Creative, I know, but descriptive.
rule mitre_attack_T1021_002_windows_admin_share_with_entity {
meta:
author = "Google Cloud Security"
description = "Net use commands for SMB/Windows admin shares"
reference = "https://attack.mitre.org/techniques/T1021/002/"
events:
$process.target.process.command_line = /net.*use.*(C|ADMIN|IPC)\\$/ nocase
$process.principal.user.userid = $userid
$user.graph.entity.user.userid = $userid
$user.graph.metadata.entity_type = "USER"
any $user.graph.relations.entity.group.group_display_name = "Domain Admins"
match:
$userid over 5m
condition:
$process and $user
}We can see that the detection contains both an entity (user) record and the associated events. If we clicked on the row under Entities, we would see the entity metadata associated with this user to the right. We would find numerous fields that describe our user entity, including the enriched values like department that we used earlier, as well as the relations.entity.group.group_display_name field we used in this example, which we’ve added to the detection view.
Today, we demonstrated two different ways to use contextual awareness that apply greater focus to our rules. These concepts apply to both asset and user entity data. As I mentioned at the start of this blog, to take advantage of this capability, we need to load entity data to Google SecOps, so if you haven’t yet, you really should!
In subsequent blogs, we will be going further into all sorts of cool stuff that can be accessed with the entity graph, so think of this as our first step, but an important one at that.
