INTRODUCTION

This guide introduces you to Google Threat Intelligence's Livehunt rules—a powerful toolset that enables CTI and cybersecurity analysts to proactively identify and track Indicators of Compromise (IoCs) (including files, URLs, domains, and IP addresses) that are uploaded to the platform and match defined criteria. 

Whether you're investigating emerging threats, tracking malware campaigns, or monitoring specific network artifacts, this guide will help you understand the core concepts and confidently build and apply Livehunt rules.

Livehunt helps researchers and organizations stay ahead of adversaries by providing flexible, rule-based detection across file and network indicators. This guide will show you how to write, manage, and apply effective Livehunt rules using Google TI platform capabilities. Furthermore, we have also created a new Livehunt starter guide, to help you get started, which you can find in the Best practices section.

CONCEPTUAL OVERVIEW

Before diving into Livehunt, it's helpful to understand its relation to YARA, a well-known pattern-matching language used for malware classification. While YARA focuses on static file analysis, Livehunt extends this philosophy to include metadata, behavioral and network-based detection.

Livehunt offers the following functionalities:

• Continuous Monitoring: Constantly scans new files and network indicators submitted to Google TI.
• Rule Matching: Executes Livehunt user-defined rules on incoming indicators. This process compares matches against the specific conditions you've set in a rule.
• Real-time Notifications: When a submitted indicator to Google TI matches one of a user's Livehunt rules, Livehunt generates a notification. These critical alerts are automatically aggregated into the IOC Stream, providing a centralized view of all relevant threat intelligence.

In essence, Livehunt empowers cybersecurity professionals to move from a reactive to a proactive stance in identifying and mitigating cyber threats.

File hunting vs network hunting

For an analyst, File Hunting in Google TI is fundamentally about dissecting and understanding malicious software. It involves diving deep into individual files – be they executables, documents, or scripts – to uncover their true nature and capabilities. Analysts use this to identify threats by searching for tell-tale signs within the file's content (like unique code snippets or strings), its metadata (such as PDB paths or compile times), and, crucially, its behavior when executed in a sandbox (observing actions like creating other files, modifying registry keys, or attempting specific network communications). Key use cases include detecting new malware variants that might evade existing defenses, tracking specific tools used by threat actors, and understanding the precise functionality of a suspicious file to assess its potential impact.

Network Hunting, on the other hand, allows an analyst to map out and identify the malicious infrastructure that supports cyber attacks. Instead of focusing on the malware itself, this approach targets the URLs, domains, and IP addresses that malware communicates with or is distributed from. Analysts look for patterns in network traffic, suspicious domain characteristics (like recently registered domains using a specific pattern for the domain name or those with known malicious SSL certificates), or URLs known to host phishing kits or malware payloads. The main goals here are to uncover command and control (C2) servers, identify phishing sites, discover infrastructure used to distribute malicious content, and monitor an organization's own network presence for any signs of compromise or association with malicious activity.

In practice, analysts rarely use these two hunting methods in complete isolation. They are powerful, interconnected tools. For instance, a piece of malware identified through file hunting will often reveal network indicators (like a C2 domain) that an analyst can then investigate further using network hunting techniques. Conversely, suspicious network activity or a malicious URL found via network hunting can lead an analyst to download and scrutinize the specific files being distributed. This synergy allows analysts to build a more complete intelligence picture, moving from a single piece of malware to the broader campaign, or from a suspicious IP address back to the specific tools an attacker is deploying, ultimately enhancing their ability to detect, understand, and mitigate threats.

Core Concepts: Building Livehunt Rules

Understanding YARA rules

Every YARA rule follows a simple structure:

rule <RuleName> // Rule identifier
{
    meta:
        // Metadata about the rule
    strings:
        // Strings or patterns to search for
    condition:
        // Logic that defines a match
}

• Meta section: This optional section allows you to include descriptive information about your rule. This is invaluable for rule management, sharing, and understanding the rule's purpose later. Common metadata fields are:

meta:
 author = "TPG Team"
 date = "2025-05-05"
 version = "1.0"
 description = "Description or purpose of the rule"

• Strings section: This usually essential section defines the patterns, byte sequences, or text that the rule will search for within a file. You can use three different types of strings:
  • Text strings: $string1 = "your text"
  • Hexadecimal strings: $hex1 = { E2 ?? A1 C8 23 FB }
  • Regular Expressions: $regex_ipv4 = /\b(?:}0-9]{1,3}\.){3}l0-9]{1,3}\b/
• Condition section: This is a mandatory section where the logic of the rule resides. It's a Boolean expression that determines if the rule matches. For example, “$string1 and $hex1” condition is true if the indicator matches both parts of the condition. Conditions could be more complex using for instance some iterators, as we will see during this guide.

A Practical YARA Example

YARA's capabilities can be extended by importing various modules, which provide specialized functions and data structures for analyzing specific file types or data. In the following example, we use the pe module to interact with Portable Executable (PE) file attributes.

Here you have a first example of YARA rule:

import "pe"

rule win_exe_512kb_signed_by_microsoft
{
  meta:
      author = "TPG Team"
      description = "MS signed binaries (< 512KB) containing 
      ‘supermalware’"
  strings:
      $mz = "MZ"
      $string1 = "supermalware"
  condition:
      $mz at 0 and filesize < 512KB and $string1 and
      for any i in (0 .. pe.number_of_signatures) : (
           pe.signaturesni].subject contains "Microsoft"
      )
}

This rule aims to detect Microsoft signed binaries under 512KB containing the term 'supermalware'. Some key aspects for this rule conditions are:

• File Type: Identifies it targets Windows PE files ($mz at 0).
• Size Constraint: Mentions the file size limit (filesize < 512KB).
• Signature Check: Highlights that it looks for a Microsoft signature (pe.signaturesei].subject contains "Microsoft"). Note the loop structure.
• Suspicious string: Clearly states the presence of the "supermalware" string,

There are many other YARA modules available that can enhance your rule-writing capabilities, such as hash for cryptographic hashing, math for mathematical operations, and elf for Linux executables. You can find a comprehensive list and documentation for these modules here.

The VT Module

Beyond the standard YARA modules, the VT module is a special YARA module created specifically for Google TI's hunting services. It allows your rules to leverage the extensive context data available on the platform. You must import "vt" to use its features, always using vt as a prefix for any submodule calls.

The vt module is divided in three submodules that allows you to create rules that expose most of information that can be found in the platform:

• vt.metadata: For accessing file metadata (e.g., Google TI score, antivirus detection rates, ExifTool data, submission details, file type, digital signatures, tags).
• vt.behaviour: For accessing file behavioral information from sandbox detonations (e.g., network activity, file system changes, sandbox verdicts, Android/Windows-specific actions).
• vt.net: For accessing data related to network assets (URLs, Domains, and IP addresses).

In the following sections, we'll dive into practical examples of how to use these vt submodules for both file and network indicator matching.

 Implementing Livehunt: Practical Hunting Examples

1. File Hunting using Livehunt

1.1. Creating rules based on file metadata

The ‘vt.metadata’ prefix exposes all the metadata that Google Threat Intelligence has about a file to YARA.

Let's see a basic example:

import "vt"

rule new_zbot_samples_submitted_BR
{
meta:
  author = "TPG Team"
  description = "Detect new zbot samples submitted from 
                Brazil"
  target_entity = "file"
condition:
  vt.metadata.new_file and
  for any engine, signature in vt.metadata.signatures : (
     signature contains "zbot"
  )
  and vt.metadata.submitter.country == "BR"
}

Figure: Looking for new zbot trojan virus samples submitted from Brazil

The previous Livehunt inspects for newly submitted files to Google TI that are likely related to the “Zbot” malware family (as indicated by at least one antivirus detection) and were specifically submitted by the user from Brazil.

Let's move on to a more advanced example:

import "vt"

rule attached_docx_files_related_Acme
{
meta:
  author = "TPG Team"
  description = "Detect attached docx files containing ‘Acme 
  Corp‘ in exiftool metadata"
  target_entity = "file"
condition:
  vt.metadata.file_type == vt.FileType.DOCX and
  for any vt_metadata_tags in vt.metadata.tags: (
    vt_metadata_tags ==  "attachment"
  )
  and vt.metadata.exiftoolb"Company"] ==  "Acme Corp."
  and vt.metadata.gti_assessment.verdict.value ==  
  vt.GtiVerdict.VERDICT_MALICIOUS
}

Figure: attached docx files containing “Acme Corp” in exiftool metadata

This rule aims to detect specific DOCX malicious documents that contain "Acme Corp." in the “Company” metadata field processed by ExifTool and tagged as attachments.

You can find comprehensive details on various metadata fields and more examples here.

1.2. Creating rules based on file behavior

Google TI executes files in multiple sandbox environments. The vt.behaviour prefix exposes this aggregated behavioral report to your rules, allowing you to hunt based on observed actions.

Let's see a basic example:

import "vt"

rule persistence_runonce_vbs {
meta:
 author = "TPG Team"
 description = "Identify files modifying Registry Run Keys 
 for persistence"
 target_entity = "file"
condition:
  for any registry_key in vt.behaviour.registry_keys_set: (
   registry_key.key icontains "\\CurrentVersion\\RunOnce\\"    
   and registry_key.value icontains ".vbs"
  )
}

Figure: files modifying Registry Run Keys for persistence

The conditions here focus on the behavior report of the file when executed in different sandbox environments. Determines if the registry keys that the file was observed to set during its behavioral analysis contains the string "\\CurrentVersion\\RunOnce\\" in the path and the value written to that specific registry key contains “.vbs”.

Let's move on to a more advanced example:

import "vt"

rule dns_remote_access {
meta:
  author = "TPG Team"
  description = "Identify files that perform DNS lookups to 
  known remote access software"
  target_entity = "file"
condition:
  for any lookup in vt.behaviour.dns_lookups: (
    lookup.hostname contains ".logmein.com" or
    lookup.hostname contains ".net.anydesk.com" or
    lookup.hostname contains "app.atera.com" or
    lookup.hostname contains "relay.screenconnect.com"
  )
}

Figure: files that perform DNS lookups related to known remote access software

In this example, the rule search through each DNS lookup recorded during the file's behavioral analysis checking if contains some of these hostnames: ".logmein.com", ".net.anydesk.com", "app.atera.com"," relay.screenconnect.com".

You can find more information on the vt.net module's network attributes and their combinations here.

2. Network Hunting using Livehunt

The vt.net prefix exposes all the metadata Google Threat Intelligence has about network indicators (URLs, domains, and IP addresses). It also includes complementary attributes for easy referencing.

Here, you can find details about the "vt" module's network attributes and their combinations.

Let’s see an example to hunt for URLs:

import "vt"

rule ACME_brandingAbuseMonitoring
{
meta:
  author = "TPG Team"
  description = "Monitoring Acme Corp. brand abuse in urls"
  target_entity = "url"
condition:
  (
   vt.net.url.raw icontains "Acme" or
   vt.net.url.html_title icontains "Acme Corp"
  ) and vt.net.domain.gti_assessment.verdict.value == 
   vt.GtiVerdict.VERDICT_MALICIOUS and not
   vt.net.domain.root == "acme.corp"
}

Figure: Potential URLs abusing Acme Corp Brand

This rule is designed to detect URLs that are potentially impersonating “Acme Corp” for malicious purposes. It focuses on seen URLs that contain the corporate branding either in the URL itself or in the HTML title, are assessed as malicious by Google Threat Intelligence, and are not hosted on the legitimate “acme.corp” domain. 

Let’s see another example using domains:

import "vt"

rule ACME_corporate_domains_malware
{
meta:
  author = "TPG Team"
  description = "Acme Corp domain monitoring related to 
                 malicious files (communicating or 
                 downloading)"
  target_entity = "domain"
condition:
 vt.net.domain.raw iendswith "acme.corp" and
 (
       vt.net.domain.downloaded_file.analysis_stats.malicious >0
 or
 vt.net.domain.communicating_file.analysis_stats.malicious >0
 )
}

Figure: Corporate domain malware monitoring

This rule monitors if the "acme.corp" domain is linked to any files that have at least one malicious detection, whether those files communicated with the domain or were downloaded from it.

Let’s see another example for IP addresses:

import "vt"

rule asn_ips_malicious_files
{
 meta:
   author = "TPG Team"
   description = "ASN IP addresses categorized as malicious or downloading or receiving network communications from malware samples."
  target_entity = "ip"
 condition:
 vt.net.ip.ip_asn == 400318 and 
 (
  vt.net.ip.analysis_stats.malicious > 0 or
  vt.net.ip.communicating_file.analysis_stats.malicious >0 or
  vt.net.ip.downloaded_file.analysis_stats.malicious > 0
 )
}

Figure: Malicious ASN IPs downloading or receiving network communications from malware samples

This rule monitors IP addresses belonging to a specific Autonomous System Number (ASN) (in this case, ASN 400318). It flags those IPs that are categorized as malicious or are linked to files (either communicating with them or downloaded from them) that have at least one malicious detection.

Creating Livehunt rules in Google TI

This section will guide you through creating and managing your Livehunt rules directly within the Google TI platform's user interface.

First, navigate to the Livehunt section in the left-hand menu and select the type of Livehunt you wish to create (e.g., "New ruleset to get files").

Figure: Livehunt dashboard

From here you will be redirected to the Livehunt code editor, which is divided into several intuitive parts:

Figure: Livehunt code editor UI

Left section

This section helps you set up and leverage tools for your new Livehunt rule:

• Name Your Livehunt: Assign a clear, descriptive name to your new Livehunt rule.
• Livehunt Dashboard Icon: Use this to return to the main dashboard, where all your previously created rules are displayed.
• Templates: This powerful feature provides nearly ready-to-use Livehunt rules. Templates cover many common cybersecurity analyst use cases, requiring only minimal adjustments to fit your specific needs.

Figure: Livehunt templates usage example

• Structure: A highly efficient tool for rule creation. This allows you to look up a file hash (or other indicator type) and then build a Livehunt rule based on its report fields. Simply click on the fields you're interested in from the report, and the corresponding code snippet will automatically be added to your editor, saving you from needing to know the exact YARA nomenclature.

For example, if we make a lookup of a hash using the text box in next image and we will have access to the report:

Figure: Hash lookup text box

Figure: File report for this hash

From the file report we can click on the different fields we are interested in, this will add the code snippet to the editor in order to create our new Livehunt:

Figure: Added Livehunt code by clicking on the report fields

Once you have the initial code, whether from a template or the Structure tool, you can then fine-tune your Livehunt rule by modifying paths, names, or the logical conditions to perfectly align with your hunting objective.

Top center section

This is the main coding area where you write and refine your Livehunt rules. The visual editor includes auto-complete support to guide you through available options, simplifying the rule-writing process and reducing errors.

Figure: Using the auto-complete support

As we have mentioned before it is possible to use the templates or structure methods.

Bottom center section

This section provides a textbox specifically for testing your rule. Enter observables like hashes, domains, URLs, or IP addresses that you expect should match your rule. This test functionality helps confirm your rule is working correctly before you deploy it into production, preventing unexpected false positives or negatives.

Figure: Using the test functionality

Right section

This section contain different settings for the current Livehunt rule, such as:

• Ruleset Management: Activate or deactivate hunting rules.
• Notification Throttling: Limit the number of Livehunt results you receive daily.
• Email Alerts: Choose to receive notifications by email.
• Historical Analysis: Launch a Retrohunt job to scan past file uploads to Google TI for threats.

This section also contains the rule sharing with other users or groups:

Figure: Sharing the rule with users and group

The IOC stream

The IOC Stream is a centralized notification system designed to provide users with a continuous flow of Indicators of Compromise (IOCs) relevant to their security interests. It acts as a unified hub where alerts from various Google TIl services are aggregated, making it easier for security professionals and researchers to stay updated on emerging threats and manage threat intelligence.

Figure: IOC Stream main view

Essentially, the IOC Stream consolidates information coming  from Livehunts, Retrohunts, IOC collections and Threat Profile Subscriptions. Take in mind that notifications are deleted automatically after 7 days. Furthermore,The IOC Stream can also be used with its dedicated API endpoint for integration into your existing security workflows

FINAL CONCLUSIONS 

Livehunt empowers security teams to define custom criteria for continuous monitoring of submitted files and other network indicators. This proactive stance is further enhanced by the VT module, which allows the creation of highly effective Livehunt rules by leveraging Google TI's extensive metadata and behavioral information. This means hunters can move beyond simple IOCs to detect similar threats based on their characteristics, metadata and behavior for a comprehensive defense.  We've also explored how Livehunt can be effectively used for both file hunting and network hunting, demonstrating its versatile application across different observable types.

In the technical area Livehunt's continuous monitoring provides real-time notifications, crucial for rapid response to emerging threats. The platform streamlines the creation and management of these hunting rules, offering helpful tools like templates for quick starts and the advanced structure functionality for rule building directly from indicator reports. Furthermore, the IOC Stream centralizes all alerts from Livehunt and other Google TI services, providing a consolidated view for streamlined alert management and facilitating easier integration of findings into an organization's broader security posture, ultimately leading to a more informed and agile threat response.