LinkedIn
Twitter
The saying, “prevention is ideal, but detection is a must” has stuck with me ever since I landed my first SOC analyst job many years ago. It emphasizes the importance of a layered approach to security – preventive measures aim to stop security incidents from happening in the first place, while proactive monitoring and early detection enables security teams to identify and neutralize threats before they escalate.
Finding the right balance between preventive and detective security controls is crucial. While maximizing threat prevention and minimizing potential damage are important, it's equally important to avoid hindering employee productivity by implementing preventive measures that are too restrictive. For example, if your organization’s policies allow users to share documents with external parties, the security team can develop a detection rule that alerts them when a user account suddenly shares several dozen documents with a free email domain. This detection may tip the security team off to an active insider threat or compromised user account that’s being used to steal data from the organization.
To assist security teams with monitoring their Google Workspace organization for suspicious behavior in addition to the built-in detection capabilities in Workspace, my colleague, Serhat Gülbetekin developed a collection of over 20 detection rules for Chronicle Security Operations. You can find these rules in our chronicle/detection-rules GitHub repo.
In this blog post, we’ll summarize the coverage that these YARA-L rules provide and provide a detailed example of how a couple of these rules work.
Summary of detection rule coverage
Below is a summary of the detection coverage that these rules provide organized by MITRE ATT&CK technique. Please keep in mind that every organization is different; these rules will need to be tested and tuned to fit your environment.
Monitoring for Workspace trusted domain configuration changes
Now that you have some familiarity with this collection of rules, let’s look at a couple of the rules in more detail to understand how it works with Chronicle. In this first example, I’m going to be talking about the rule, New Trusted Domain Added in Google Workspace, and have configured Chronicle to ingest my organization’s Workspace logs.
In Workspace, trusted domains is a feature that allows administrators to restrict file sharing to specific domains. This ensures that users can only share files and folders with individuals whose email addresses belong to those trusted domains. For example, if I work at Cymbal Investments and want to restrict users to sharing files internally and with people who work at Google, I can configure my Workspace organization to allow file sharing with only trusted domains and add google.com as a trusted domain.
Security teams should monitor for changes to their Workspace trusted domain configuration to mitigate unauthorized data access and exposure events. Adding an unauthorized trusted domain could enable file sharing with unintended or malicious actors, leading to data breaches. Note, the unexpected configuration change could be carried out unintentionally or by a malicious actor/insider threat. By detecting and responding to unexpected configuration changes early on, the security team can avoid a nasty security breach.
A copy of the YARA-L rule that detects the behavior of a new trusted domain being added to Workspace is shown below. This is a relatively simple “single event” YARA-L rule meaning that the rule matches on a single event in Chronicle. I’ll provide a more detailed explanation of each section of the rule in the remainder of this section. If you’re new to building rules in Chronicle, I’d recommend checking out the New to Chronicle blog series written by my colleague, John Stoner.
rule google_workspace_new_trusted_domain_added {
meta:
author = "Google Cloud Security"
description = "Identifies when a domain is added to the list of trusted domains in Google Workspace. An adversary may attempt to manipulate sharing settings for trusted domains to gain unauthorized access to sensitive files and folders within an organization."
mitre_attack_tactic = "Defense Evasion"
mitre_attack_technique = "Impair Defenses: Disable or Modify Cloud Firewall"
mitre_attack_url = "https://attack.mitre.org/techniques/T1562/007/"
mitre_attack_version = "v13.1"
type = "Alert"
data_source = "Workspace Activity"
severity = "High"
priority = "High"
events:
$ws.metadata.vendor_name = "Google Workspace"
$ws.metadata.product_name = "admin"
$ws.metadata.product_event_type = "ADD_TRUSTED_DOMAINS"
outcome:
$risk_score = max(75)
$mitre_attack_tactic = "Defense Evasion"
$mitre_attack_technique = "Impair Defenses: Disable or Modify Cloud Firewall"
$mitre_attack_technique_id = "T1562.007"
$event_count = count_distinct($ws.metadata.id)
$principal_ip = array_distinct($ws.principal.ip)
$principal_country = array_distinct($ws.principal.ip_geo_artifact.location.country_or_region)
$principal_state = array_distinct($ws.principal.ip_geo_artifact.location.state)
$principal_user_emails = array_distinct($ws.principal.user.email_addresses)
$principal_user_id = array_distinct($ws.principal.user.userid)
$target_domain = $ws.target.domain.name
condition:
$ws
}
The meta section of the rule is quite simple. It contains key-value pairs that describe the rule. For example, the author of this rule is Google Cloud Security and its severity is High. The meta section helps the security team categorize, organize, and manage their detection rules.
In the events section of the rule, we specify which events we want the rule to filter on in Chronicle. On the first line, we’re filtering on Google Workspace events out of all of the events that have been ingested into Chronicle. On the second and third line in the events section, we’re filtering down the events based on admin activity and finally the ADD_TRUSTED_DOMAINS event, which is logged when a trusted domain is added in the Workspace admin console. Easy peasy.
The outcome section allows us to define up to 20 “outcome variables”, with arbitrary names. These outcomes will be stored in the detections generated by the rule and provide context to a security analyst when triage and investigation is needed. Please check out our YARA-L rule style guide if you’re interested in learning more about how we author rules.
The condition section ensures that the rule will trigger if a match is found for the $ws event defined in the events section of the rule. If no matches are found, the rule won’t trigger.
An example alert from this detection rule is shown in the image below. At a glance, we can see that the user admin@mydomain.com added the domain example.com as a trusted domain in Workspace. The security team should triage this alert to determine whether this was an unexpected change and if any unauthorized data exposure has occurred.
Detecting suspicious Workspace logins followed by a file download event
In this example, we’re going to review the rule named, Suspicious Google Workspace User Login Followed by Google Drive File Download. This is a “multi-event” YARA-L rule that matches on a suspicious Workspace user login event followed by a Google Drive file download event by the same user. A copy of this rule is shown below.
rule google_workspace_suspicious_login_and_google_drive_file_download {
meta:
author = "Google Cloud Security"
description = "Identifies when a Google Workspace user downloads a file from Google Drive after a suspicious login event occurred."
mitre_attack_tactic = "Exfiltration"
mitre_attack_technique = "Exfiltration Over Web Service"
mitre_attack_url = "https://attack.mitre.org/techniques/T1567/"
mitre_attack_version = "v13.1"
type = "Alert"
data_source = "Workspace Activity"
severity = "High"
priority = "High"
events:
// Suspicious Login Event
$login.metadata.vendor_name = "Google Workspace"
$login.metadata.product_name = "login"
$login.metadata.product_event_type = "login_success"
$login.about.labels["is_suspicious"] = "true"
// Document Download Event
$download.metadata.vendor_name = "Google Workspace"
$download.metadata.product_name = "drive"
$download.metadata.product_event_type = "download"
// Joining login and download events using userid
$login.target.user.userid = $download.principal.user.userid
// Placeholders for match section
$login.principal.ip = $principal_ip
$login.target.user.userid = $target_userid
// First login event occurs later a download event
$login.metadata.event_timestamp.seconds < $download.metadata.event_timestamp.seconds
match:
$target_userid, $principal_ip over 1h
outcome:
$risk_score = max(75)
$mitre_attack_tactic = "Exfiltration"
$mitre_attack_technique = "Exfiltration Over Web Service"
$mitre_attack_technique_id = "T1567"
$event_count = count_distinct($download.metadata.id)
$product_event_type = array_distinct($download.metadata.product_event_type)
$userid = array_distinct($download.principal.user.userid)
$doc_type = array_distinct($download.src.resource.attribute.labels["doc_type"])
$owner = array_distinct($download.target.resource.attribute.labels["owner"])
$doc_name = array_distinct($download.target.resource.name)
$doc_id = array_distinct($download.target.resource.product_object_id)
condition:
$login and $download
}
The meta section for YARA-L rules was explained in the earlier example, so let’s go right ahead and take a closer look at the events section for this rule. I’ve included a screenshot of this section below.
- Lines 17-20: Filter on Google Workspace login events that are labeled as suspicious (
is_suspicious=true). Google considers login activity suspicious if there's a sign-in attempt that doesn't match a user's normal behavior such as a sign-in attempt from an unusual location. - Lines 23-25: Filter on Google Drive file download events.
- Line 28: Join the Google Workspace login event with the Google Drive file download event based on the user ID value.
- Lines 31-32: Create placeholder variables for the user’s IP address (
$principal_ip) and user ID ($target_userid) to use in the match section of the rule. - Line 35: Filter on events where the Google Workspace login event occurred before the Google Drive file download event.
Let’s finish our review of this rule by focusing on its match and condition sections.
In the match section, we’re instructing the rule to return the user’s account ID ($target_userid) and IP address ($principal_ip) when a match occurs within a 1 hour time window.
The condition section ensures that the rule will trigger if a match is found for the $login and $download events defined in the events section of the rule.
The image below shows a detection generated by this rule. We can see that a suspicious login event occurred for a user with the ID of 105353206017972753368. After the user logged in, they downloaded a few files, reis.dll, installer.exe, and ssh.pem. This detection rule is provided as an example and can be customized to match on specific file extensions being downloaded, files being downloaded from sensitive folders in Google Drive, or login events from certain geolocations.
You can click the little expand icon next to any of the events in the detection to view more information about the event. For example, if we view the user login event, we can see that user ID 105353206017972753368 has an email address of intern@mydomain.org.
Wrap up
In this post, we talked about the importance of finding the right balance between implementing preventive and detective security controls. We introduced a collection of over 20 YARA-L rules that can be used to detect suspicious or notable behaviors in Chronicle Security Operations. Finally, we took a closer look at two of the rules and reviewed the alerts they generated when triggered.
Please feel free to reach out on the Google Cloud Security Community with any questions. Thanks for reading.
