Authors:
Jules Czarniak, Senior Security Engineer
Daniel Kapellmann Zafra, Staff Security Engineer
Connecting Intelligence to Execution
Google Threat Intelligence recently introduced new capabilities that deliver frontline Mandiant technical observations –including adversary tactics, techniques and procedures (TTPs)– from individual intrusions within 24 hours into the platform. By capturing granular execution details, such as exact command-line syntax, information about single target operations gives defenders immediate visibility into active adversary behavior. Digesting and using these operations allows security teams to turn raw intrusion telemetry directly into targeted detections, control validations, and threat hunting playbooks.
In this post, we show how to seamlessly create practical threat hunting playbooks using our data about operations and agentic threat intelligence. Google Threat Intelligence categorizes threat activity into three distinct campaign types:
-
Single target Operation: Represents highly targeted activity involving a single threat actor directing their efforts against a single specific victim organization.
-
Multitarget Campaign: Characterizes broader operations where a single threat actor coordinates attacks against multiple victims, often within a specific sector or region.
-
Global Multiactor Campaign: Defines widespread, systemic threat activity involving multiple threat actors targeting numerous victims globally, indicating a massive scale of operations.
These architectural tiers are composed of smaller building blocks we call observations. These are discrete, verifiable technical facts, such as host commands, network resolutions, and file executions, decoupled as independent, queryable objects that define campaigns and operations. Using Google Threat Intelligence’s agentic capabilities to act directly on structured threat data, the system can autonomously generate novel intelligence and narratives. Security teams can leverage these prompts to retrieve actual examples and synthesize these observations into actionable threat hunting playbooks.
Investigating a Ransomware Intrusion with Agentic Threat Intelligence
Enterprise ransomware intrusions represent an ideal testing ground for operational threat hunting playbooks. A single intrusion routinely spans perimeter appliances, endpoint Active Directory structures, cloud-hosted backup storage, and hypervisor virtualization layers.
Consider a typical enterprise response scenario: an analyst discovers hosts where files have been appended with an .akira extension alongside a ransom note titled akira_readme.txt. Akira is a ransomware-as-a-service operation whose primary encryptor payload, tracked by Google Threat Intelligence as REDBIKE, is deployed by several distinct affiliate clusters. The analyst decides to focus their investigation on one of the prolific Akira affiliates, which we track as UNC6361.
For threat hunters and incident responders tasked with scoping and containing this incident, the investigation centers on two key questions:
-
Adversary Attack Chain: What does UNC6361's technical execution sequence look like across the environment?
-
Payload Execution Baseline: What specific host commands and configuration exclusions does the REDBIKE payload execute internally once deployed?
The following workflow demonstrates how practitioners can leverage Google Threat Intelligence’s agentic features to answer both questions, mapping high-level adversary profiles directly down to granular execution objects across campaigns and operations.
Step 1: Reconstructing the Adversary Playbook (Threat Actor TTP Dive)
Although an operation container aggregates telemetry from a specific intrusion, traditional investigation workflows still require analysts to execute multiple manual pivots across disconnected entities to build full context. For example, an investigator might first identify a dropped file hash within the operation, navigate separately to the associated malware profile to assess its capabilities, and finally review dedicated threat actor dossiers to match observed command-line arguments.
Instead of pivoting manually, the analyst can use Google Threat Intelligence’s Threat Actor TTP Dive prompt to bring contextual enrichment and pull surrounding threat actor and malware characteristics, campaign linkages, as well as underlying telemetry into a unified technical sequence.
The analyst can simply type a query into Google Threat Intelligence’s agentic chatbox or trigger our premade prompt and select the variable: [THREAT_ACTOR: UNC6361]. In this case the analyst leaves the timeframe variable blank because they want to know all the context available about the threat actor.
Agentic Investigation Output
The initial output of the investigation provides an executive summary of findings which includes a description of the actor, the aliases, object associations and a short summary of their toolset. The initial details are relevant to provide context to the investigation and point to additional resources before visualizing the technical execution logs.
-
UNC6361 is a financially motivated cybercrime group specializing in multi-phase ransomware operations. They compromise enterprise environments to deploy REDBIKE (Akira) ransomware across both endpoint and hypervisor tiers.
-
Associated Malware: REDBIKE, CLOUDFLARED, POWERVIEW, WINRAR, 7ZIP, IMPACKET.WMIEXEC, RCLONE (and six further tools listed in the console).
-
Linked Campaigns & Operations: CAMP.25.051, OP.25.0401
-
The analyst can dive directly into the technical observation logs gathered from previous, anonymized intrusions tracked in Operations and Campaigns objects. Here, Google Threat Intelligence extracts and displays the exact command-line syntax the operator used.
As shown in Figure 4, this historical activity spans multiple months, beginning with internal network reconnaissance and data staging via WinRAR in February. However, during localized bursts of execution, malicious scripts often execute a high volume of actions simultaneously.
Within a flat telemetry table, these concurrent commands share identical timestamps, making raw chronological sorting ambiguous. Google Threat Intelligence bypasses this chronological limitation by mapping these simultaneous actions to their corresponding Mandiant lifecycle phases. This tactical ordering reveals the true operational sequence: the actor disabled the target’s XDR platform (Maintain Presence) before executing backup destruction and payload deployment (Complete Mission).
By looking across Google Threat Intelligence data, a single prompt links individual command-line observations to their respective parent entities in the hierarchy. For example, it maps the RDP port registry query to a specific single-victim Operation (OP.25.0401), while linking the az storage blob delete command directly to the broader overarching Campaign (CAMP.25.051). This pulls concrete syntax parameters from disparate objects into a synthesized technical sequence.
Step 2: Isolating Payload Execution (Malware TTP Dive)
After reviewing the actor's operations, the analyst continues to analyze the technical baseline for the ransomware payload itself.
Using the Malware TTP Dive prompt template, the analyst can query the REDBIKE malware object directly. This extracts the specific cryptographic settings, and the default execution pipeline recorded inside the intelligence graph. The analyst sets the following parameter for the query using the Malware TTP Dive template: [MALWARE_TARGET: REDBIKE].
The results include at first an executive summary and a list of relevant linked events.
Next, the analyst scrolls down to find a depiction of the REDBIKE execution pipeline, which shows a structured mapping of the payload's tactical capabilities and lateral movement behavior. This information is directly extracted from Google Threat Intelligence telemetry to provide a technical baseline of the malware’s behavior.
Among other things, the execution pipeline surfaces the commands the malware uses to terminate running virtual machines (vim-cmd vmsvc/power.off <VM_ID>) and traverse datastores (find /vmfs -name '*vmdk'). Powering off a virtual machine releases the hypervisor's locks on virtual disks, allowing the host-level encryptor to target the disk images directly. This bypasses guest operating system security controls where endpoint agents operate. Forensically, seeing these VM shutdown commands in the execution pipeline tells the analyst that virtualization should be in scope of the investigation.
Step 3: Operationalizing the Playbook: Defense in Depth and Threat Hunting
The analyst uses the execution timeline to turn tactical analysis into playbook work: confirming the controls that break the attack path, and hunting the telemetry that records evasion. Three branches from the operation logs (Figure 4) and the malware execution tree (Figure 6) detail this method across the domain, the cloud tenant, and the hypervisor:
Domain to hypervisor
-
Attack: The execution tree records the actor adding an account to the ESX Admins domain group. Domain-joined ESXi hosts automatically grant full hypervisor administrator rights to whichever Active Directory group carries that configured name, meaning a single domain command compromises the virtualization tier.
-
Control: To close this path, the analyst checks whether hosts are joined to Active Directory and proposes removing that trust.
-
Hunt: Because the domain controller processes these group modifications directly, deploy the hunt there to actively detect the creation, renaming, and membership changes of the target group.
-
-
Recovery destruction
-
Attack: The operation logs (Figure 4) record the actor deleting backup blobs via the Azure CLI using a raw storage account key that bypasses tenant identity controls, alongside clearing volume shadow copies through WMI.
-
Control: Control verification confirms whether backup containers carry immutability policies and soft delete, while the analyst recommends disabling shared key authorization on the storage account so deletions require an Entra ID identity subject to conditional access.
-
Hunt: Detect this activity by correlating cloud storage audit logs, tracking object deletion and the authorizing account key, with prior key-access precursor signals and endpoint telemetry showing host shadow copy removal.
-
-
Hypervisor execution
-
Attack: The tree ends with the host firewall disabled, the datastore swept for virtual disk files, guests powered off, and the encryptor launched.
-
Control: ESXi audit records and syslog forwarding default to off; the analyst advises enabling both and confirms the stream reaches the SIEM before writing the hunt.
-
Hunt: Because vSphere API actions bypass shell logging entirely, the analyst must rely on host daemon logs and vCenter power-off events to reconstruct firewall tampering and mass shutdown activity.
-
-
The analyst repeats this pass across the remaining branches to define a comprehensive action plan and identify threat hunting opportunities.
Synthesizing Campaigns, Operations, and Observations
The availability of operational telemetry makes threat intelligence directly usable by connecting findings across separate malware analyses, sandbox runs, and incident reports. As this intelligence arrives faster, security teams need automated methods to turn those findings into defense.
Defenders can use agentic capabilities in Google Threat Intelligence to synthesize large volumes of operational data into clear behavioral patterns. To get started, analysts can use Google Threat Intelligence’s pre-built prompt templates or author custom prompts tailored to their environment to extract execution timelines across these intelligence sources, as discussed in our past blog on operationalizing Google Agentic Threat Intelligence.
The three prompt templates demonstrated in this post surface actor, malware, and TTP behavior across Google Threat Intelligence's campaign sub-types (Global Events, Campaigns, and Operations) and the granular Observations that underpin them, giving defenders the execution detail needed to scope hunts, write detections against their own telemetry, and justify architectural changes that close the paths the adversary relies on.
We encourage security teams to try these agentic workflows in the Google Threat Intelligence console or via the API and CLI to surface execution intelligence on the actors and campaigns they track. To scale this analysis across your operations, start experimenting with feeding these intelligence outputs into your own SOAR playbooks, custom triage scripts, or agent-to-agent (A2A) workflows.
