"New to Chronicle" 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 Chronicle. You can view the entire series here.

This edition of New to Chronicle is a doubleheader that leverages the entity graph to bring Google Cloud Threat Intelligence (GCTI) indicators for your use in building rules. In previous blogs, we have discussed derived context, like prevalence and first/last seen as well as Safe Browsing. If you have already written rules for some of these other sources (or leveraged the examples in those blogs) the method to write rules for these new event sources will be a natural progression and even if you haven’t, we’ll make it easy.

Tor Exit Nodes

Tor, short for The Onion Router, is a tool that allows anonymous access across the internet. While this can be beneficial for users where censorship exists, it can also be abused to mask the origin of an adversary. A Tor communication path is going to start somewhere and enter a series of routers that mask a user’s location, but at some point, to reach others on the internet, the traffic has to hit a Tor exit node to reach its destination. Conversely for information to return to a user, it must hit an exit node before it goes behind that mask of anonymity.

Instead of providing a list of these nodes for users to maintain, the GCTI team maintains this list for Chronicle users. To take advantage of the information, we just need a rule to monitor for traffic associated with these IP addresses. Let's look at a rule and its associated detections.

Below we have a rule that is looking for network connection events that are bound for a target IP address that is in part of our Tor exit node data set. A complete rule including outcome fields for the alert graph can be found in our community rules on Github.

The event criteria uses the field metadata.event_type with a value of NETWORK_CONNECTION. That’s it. We are matching on the field target.ip and using the placeholder value of $ip to store that value. If there are specific netblocks you want this rule to apply to or focus the rule to specific tools, additional lines of criteria could be added to this rule, so this is really the bare minimum required.

The second half of the event section contains the join between the network connection events and the Tor exit node list using the $ip placeholder variable we defined for target.ip. On lines 13-16, we have a series of constraints that narrow down the vast amount of data in the entity graph to ensure a performant rule. If you don’t want to type all that in, you can grab the community rule referenced above or copy and paste the rule in this blog!

The match condition in our example matches on the target IP address which in this case is the Tor exit node. If you want to match on the IP address in your environment where the traffic originates, you could adjust the rule by adding the following line in the events section; $network.principal.ip = $principal_ip and then use the $principal_ip in the match section instead. And don’t forget, the time range is adjustable! Finally the condition section must include both event variables in our rule.

rule gcti_tor_exit_nodes {
meta:
  author = "Google Cloud Security"
  description = "Alert traffic destined for known Tor exit nodes"
events:
  $network.metadata.event_type = "NETWORK_CONNECTION"
  $network.target.ip = $ip
  // Tor IP listing provided by GCTI Feed
  $gcti_feed.graph.entity.artifact.ip = $ip
  $gcti_feed.graph.metadata.entity_type = "IP_ADDRESS"
  $gcti_feed.graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"
  $gcti_feed.graph.metadata.product_name = "GCTI Feed"
  $gcti_feed.graph.metadata.source_type = "GLOBAL_CONTEXT"
match:
  $ip over 1h
condition:
  $network and $gcti_feed
}

Notice that we have at least two detections for the same host within our network (harveyspecter) because we are grouping on the target IP address (the Tor exit node).

Remote Access Tools

Another GCTI maintained list is around what are commonly called RATs or Remote Access Tools. These are a little trickier than Tor exit nodes. Tor exit nodes are generally something a security operations team wants to be made aware of when they are observed communicating with your systems. In the case of RATs, there are a number of legitimate remote access tools that adversaries abuse for their own purposes, so understanding what remote access tools are expected on your systems will be important to avoid false positives.

The following rule is structured similarly to the Tor exit node rule we just discussed. This time though we are looking for a few different types of events including process launches and modules being loaded as well as file creation events. To optimize our results, we only want events that contain a hash value in the target.process.file.sha256 field. If we wanted to leverage SHA1 or MD5, we could modify our rule to accommodate them; the rule would just use different fields that contain those values. This time we are going to create two placeholder variables; a file hash variable that will be used to join to our list of RATs and a second for principal.hostname that will be used in our match section.

Lines 21-25 of the event section are used to optimize our rule and focus on the remote access tool hashes in the entity graph that we want to join to our events. Our match section contains the $hostname placeholder variable which will be the system that the process launch or file creation events occurred on rather than the indicator like we had in the Tor rule. Finally, our condition section contains our event variables for both the event and the indicator.

rule gcti_remote_access_tools {
meta:
  author = "Google Cloud Security"
  description = "Alert process and file create events that are associated with hashes from the GCTI Remote Access Tool list"
events:
  // find a process launch event
  (
   $process.metadata.event_type = "PROCESS_LAUNCH" or      $process.metadata.event_type = "PROCESS_MODULE_LOAD" or $process.metadata.event_type = "PROCESS_UNCATEGORIZED" or $process.metadata.event_type = "FILE_CREATION"
   )
  $process.target.process.file.sha256 != ""
  $process.target.process.file.sha256 = $rat_hash
  $process.principal.hostname = $hostname
  // look for files identified as likely remote access tools
  $gcti.graph.entity.file.sha256 = $rat_hash
  $gcti.graph.metadata.entity_type = "FILE"
  $gcti.graph.metadata.vendor_name = "Google Cloud Threat Intelligence"
  $gcti.graph.metadata.product_name = "GCTI Feed"
  $gcti.graph.metadata.source_type = "GLOBAL_CONTEXT"
  $gcti.graph.metadata.threat.threat_feed_name = "Remote Access Tools"
match:
  $hostname over 5m
condition:
  $process and $gcti
}

When we test our rule, we can see that our win-adfs host has multiple process module load events from Sysmon that contain SHA256 hashes that align with the remote access tool collection. We can drill into these detections to better understand which tools are being utilized.

As I mentioned previously, it is possible that this detection could generate alerts for legitimate tools that are deployed in your environment. But because there are legitimate remote access tools that are often abused by adversaries, this rule may require some additional tuning. One method to perform this tuning would be to add a reference list of the SHA256 hashes of the remote access tools used in your environment and filter from there, like this.

not $process.target.process.file.sha256 in %remote_access_tool_hash

Another approach might be to have two rules; the previous one that filters out the remote access tools you expect to see in your environment as well as a second hunt rule that looks at abuse of the authorized remote access tools that are expected to be seen in your environment. That way, the authorized tools are analyzed differently from the unauthorized tools which are always flagged.

I hope this blog provides you greater insight into how to leverage GCTI content to monitor for communication with Tor exit nodes as well as detect remote access tools being used or created within your environment. The rules used today are meant to be inspiration and a starting point for you in your environment.