While onboarding with Google, I’ve been learning as much as I can about Chronicle Security Operations. Part of my new role is to help security practitioners use Chronicle to effectively detect, investigate, and respond to threats in their organizations.
This week, I’ve been experimenting with building detection rules that take advantage of how Chronicle enriches the entity and event data that it ingests. When we talk about entities in Chronicle, we are referring to users, assets, domains, and IP addresses. Ingested events are enriched using data from various sources such as VirusTotal, WHOIS, and Google Safe Browsing. Security teams can craft searches and rules that leverage this contextually enriched data to find more complex behaviors and improve the efficacy of their detections & hunts.
When I first learned about WHOIS enrichment for domains and the calculation of first-seen and last-seen timestamps being done automatically, I thought of a detection use case that would have been incredibly useful while responding to a security event last year. I’d like to share the details of that use case and a methodology for detecting it by building a rule that uses Chronicle’s contextual enrichment.
Leveraging entity enrichment data in Detection Engineering
During adversary-in-the-middle (AiTM) campaigns, it’s common for attackers to register domain names that contain their target’s company name in preparation of luring users to phishing sites to steal their credentials, intercepting multi-factor authentication (MFA), and using the stolen session cookie to impersonate the compromised user. In the remainder of this post, I’ll explain how to build a rule to detect a component of this behavior using context-enriched data in Chronicle.
While working in Threat Detection & Response roles at various companies, I’ve noticed that these domains are often registered by attackers with a domain registrar that’s not typically used or internally approved for use by the target organization. For example, if my company-approved domain registrar is “MarkMonitor”, a user interacting with a newly registered domain that contains my company name and is registered with “Porkbun” may be suspicious and something that the security team should investigate.
Chronicle enriches events after they’re ingested. When a domain entity is found in an event, Chronicle checks for a match in its WHOIS data. If there’s a match, Chronicle stores the related WHOIS data with the entity record for the domain. We are going to utilize this context-enriched data in our detection rule to surface domains based on their domain registrar.
Another type of enrichment performed by Chronicle is the calculation of the first-seen and last-seen times for an entity. This statistical analysis is done for domains, files, IP addresses, assets, and users. Our rule will check if the domain was first seen in our environment within the last 30 days.
Crafting a YARA-L rule to detect suspicious domains
The multi-event YARA-L rule below takes advantage of enriched entity data and can alert the security team if the following statements are true.
- A system on your network makes a DNS query for a domain that contains the specified company name.
- The domain is registered with a registrar other than what your company uses as per its internal processes. In this example, we’re assuming that the company registers all of its domains with MarkMonitor.
- The domain was first seen in the environment within the last 30 days.
I’ve included comments to explain the major components of the rule and will provide a more detailed explanation in the following section of this post. If you’re new to searching and building rules in Chronicle, I’d recommend checking out the New to Chronicle blog series written by my colleague, John Stoner.
A copy of the rule can be found here in our chronicle/detection-rules repo.
rule whois_dns_query_to_typosquatting_domain {
meta:
author = "Google Cloud Security"
description = "Provides example usage of WHOIS data, detecting a DNS query for a domain that contains a specific string and is not registered with the defined domain registrar."
// This rule must be customized to alert on DNS queries for possible typosquatting domains that contain your organization's domain name(s) that are not registered with your approved domain registrar.
type = "hunt"
tags = "whois"
data_source = "microsoft sysmon"
severity = "low"
priority = "low"
events:
// Search for DNS queries for domains that contain a specific string or company name(s).
$dns.metadata.event_type = "NETWORK_DNS"
// Customize the value for $dns.network.dns.questions.name to fit your environment.
$dns.network.dns.questions.name = /threatpunter/ nocase
$dns.network.dns.questions.name = $dns_query_name
// Join DNS query events with WHOIS data.
$whois.graph.entity.hostname = $dns_query_name
$whois.graph.metadata.entity_type = "DOMAIN_NAME"
$whois.graph.metadata.vendor_name = "WHOIS"
$whois.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
$whois.graph.metadata.source_type = "GLOBAL_CONTEXT"
// Check if the domain is registered with a registrar other than Mark Monitor.
// Customize the values for $whois.graph.entity.domain.registrar based on the approved/expected registrar(s) used by your organization.
$whois.graph.entity.domain.registrar != "MarkMonitor Inc."
// Check if the domain was first seen in our environment within the last 30 days (2592000 seconds).
$seen.graph.entity.domain.name = $dns_query_name
$seen.graph.entity.domain.first_seen_time.seconds > 0
2592000 > timestamp.current_seconds() - $seen.graph.entity.domain.first_seen_time.seconds
match:
// Return the DNS query name when the rule finds a match within a 1 hour time window.
$dns_query_name over 1h
outcome:
// Define outcome variables to provide context in detections generated by this rule.
$event_count = count_distinct($dns.metadata.id)
$principal_hostname = array_distinct($dns.principal.hostname)
$network_dns_questions_name = array_distinct($dns.network.dns.questions.name)
$network_dns_answers_data = array_distinct($dns.network.dns.answers.data)
$principal_ip = array_distinct($dns.principal.ip)
$target_ip = array_distinct($dns.target.ip)
$principal_process_pid = array_distinct($dns.principal.process.pid)
$principal_process_file_full_path = array_distinct($dns.principal.process.file.full_path)
$principal_process_product_specfic_process_id = array_distinct($dns.principal.process.product_specific_process_id)
$principal_process_command_line = array_distinct($dns.principal.process.command_line)
$principal_process_file_sha256 = array_distinct($dns.principal.process.file.sha256)
$principal_process_parent_process_product_specfic_process_id = array_distinct($dns.principal.process.parent_process.product_specific_process_id)
$principal_user_userid = array_distinct($dns.principal.user.userid)
condition:
// Trigger rule if a match is found for the following events.
$dns and $whois and $seen
}
Below is a description of what is happening in the events section of the rule. I’ve included a screenshot of this rule section so that I can refer to the line numbers in the rule and make it easier for you to follow along.
- Lines 15 and 17: Search for DNS query events where the
network.dns.questions.namefield contains a certain string (our company name). This can easily be customized to search for a list of domains or a regex pattern. - Line 18: Create a placeholder variable named
$dns_query_namethat is mapped to thenetwork.dns.questions.nameevent field. - Line 21: Join the DNS query events with the WHOIS contextual data for the domain in question using the
$dns_query_nameplaceholder variable. - Lines 22-25: Filter the events to include WHOIS enriched data. This makes the rule more specific on the events it searches for, which optimizes its performance.
- Line 29: Include WHOIS data for domains that are not registered with MarkMonitor Inc.
- Line 32: Join the DNS query events with the first/last seen time contextual data for the domain.
- Lines 33-34: Search for events where the domain was first seen in our environment within the last 30 days.
In the match section, we’re instructing the rule to return the DNS query name value when a match occurs within a 1 hour time window.
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. You can learn more about the outcome section in YARA-L rules in this blog post.
The condition section ensures that the rule will trigger if a match is found for the $dns, $whois, and $seen events defined in the events section of the rule.
The rule can be easily expanded or customized to do any of the following:
- Match on newly registered domains based on WHOIS data.
- Utilize other data sources such as HTTP traffic.
- Detect suspicious domains based on prevalence data that indicates how popular the entity is in your environment.
- Reference a list of company names/monitored brands to alert on or filter false positives.
My intention in this post is to show practitioners how to take advantage of using WHOIS enrichment data in their rules. As practitioners, we understand the reality that every organization’s environment is different. You can test and customize this rule to fit your environment.
Reviewing an alert from our new detection rule
The following image shows a detection from the rule. Remember that we joined the DNS query, WHOIS enrichment data, and first seen data together in our rule? Note that the DNS query events and enriched entities are joined together in the detection.
Wrap up
In this post, we learned how defensive practitioners can capitalize on entity enrichment data in Chronicle to build rules that detect complex behaviors.
It’s nice to see this type of enrichment happening automatically for users at scale. In my experience, a security team typically buys access to individual threat feeds & enrichment APIs to custom engineer the enrichment of log events & alerts while being careful not to exceed their API rate limits with various vendors.
As a reminder, there are additional contextual enrichment types available in Chronicle to enable your investigation and detection engineering efforts including VirusTotal, Google Safe Browsing, and Google Cloud Threat Intelligence.
I hope you found this post helpful. Thanks for reading!