Google Cloud Compute and Cloud Ops Agent — What Actually Matters for DFIR
- 10 minutes ago
- 9 min read
When people say "compute" in Google Cloud, they're really talking about anything that burns CPU. If it runs code, processes data, or executes workloads — it falls under compute.
For investigations, though, not all compute is equal. Some services give you deep visibility. Others hide almost everything.
Here's the case we'll come back to throughout this article: a billing alert flags an unexpected spike in Compute Engine usage on a project called fernbridge-prod. Nobody on the team provisioned new VMs.
That's your incident — and everything below is how you'd actually work it.
Compute Types (Quick Reality Check)
Google Cloud groups compute into three big buckets:
IaaS (Infrastructure as a Service) — this is where DFIR people feel at home. You control the operating system, installed software, and users, processes, and disks. Examples: Virtual Machines (Compute Engine), Shielded VMs, GPU-backed VMs.
👉 From a forensic standpoint, this is gold.
PaaS (Platform as a Service) — here, Google manages the OS and runtime. You configure the app, not the system. Examples: App Engine, Google Kubernetes Engine (GKE), Cloud Run. You still get logs — but host-level evidence is mostly gone.
FaaS (Function as a Service) — this is the black box. Examples: Cloud Functions, Cloud Workflows. You deploy code. Google handles everything else. From a DFIR perspective: great logs, almost zero disk or memory visibility.
Why We Focus on Compute Engine (VMs)
Google keeps adding new compute services all the time. But for DFIR work, Compute Engine VMs are the most valuable.
Why?
They behave like traditional systems, they generate OS-level artifacts, you can snapshot disks, you can run agents, and you can do "normal" forensics on them. Most of the investigation techniques you use here carry over to other compute types, but VMs give you the deepest access.
In the fernbridge-prod case, the mystery workload turns out to be a handful of brand-new Compute Engine VMs — which is exactly why this article focuses here instead of on GKE or Cloud Functions: VMs are where you actually get to do forensics.
VM Types (Don't Overthink It)
Google offers a huge list of predefined VM types: General-purpose, High-memory, High-CPU, and Extreme performance machines (full list here).
For DFIR, the size doesn't matter much — the artifacts do.
A few things worth remembering:
VMs can run Windows or Linux, they can use custom images, they can host Docker containers, and you can also define custom machine types.
Special VM Configurations (DFIR Angle)
GPUs are zone-specific add-ons for an existing VM. They're useful when you need to crunch through evidence fast — say, running ML-assisted malware classification — but they're not an especially interesting artifact source themselves.
Preemptible VMs are cheap and not guaranteed to run continuously — they can disappear at any time. Picture this: you're investigating a spike in outbound traffic from a web cluster, and half the logs just stop mid-timeline. That's usually not evidence tampering — it's a preemptible VM getting reclaimed. These are about cost optimization, not stability, and they're common in exactly the kind of web clusters where you'd expect to find them.
Shielded VMs add Secure Boot, integrity monitoring, and a virtual TPM (vTPM). Security-wise: great. Forensics-wise: mixed — they often come with additional logins that a standard VM wouldn't have, which is one more thing to check during triage.
Capturing Evidence: Disk Snapshots (The Cloud Way)
In cloud environments, you don't image disks the old-school way. Instead, you:
Snapshot the persistent disk attached to the VM
Share that snapshot with your DFIR project
Copy it
Convert it back into a disk
Attach it to a forensic VM as read-only
Analyze like a normal disk
This works whether your DFIR team is in the same org, a different org, or a completely separate third-party firm — it's just permissions. Same concept as AWS and Azure, just different buttons.
For fernbridge-prod, day one looks exactly like this — from Cloud Shell or your workstation:
# 1. Snapshot the disk on the suspicious VM
gcloud compute disks snapshot fernbridge-vm-07 \
--project=fernbridge-prod \
--zone=us-central1-a \
--snapshot-names=incident-snap-01
# 2. Share the snapshot with your DFIR project
gcloud compute snapshots add-iam-policy-binding incident-snap-01 \
--project=fernbridge-prod \
--member="user:you@dfir-project.iam.gserviceaccount.com" \
--role="roles/compute.storageAdmin"
# 3. From the DFIR project: copy the snapshot into a new disk
gcloud compute disks create incident-disk-01 \
--project=dfir-project \
--source-snapshot=projects/fernbridge-prod/global/snapshots/incident-snap-01 \
--zone=us-central1-a
# 4. Attach it read-only to your forensic VM
gcloud compute instances attach-disk forensic-vm \
--project=dfir-project \
--zone=us-central1-a \
--disk=incident-disk-01 \
--mode=ro
From here, it mounts and analyzes like any other read-only disk.
But a snapshot alone won't tell you how those VMs got created in the first place — that's where it gets more complicated.
The Big Problem With Snapshots
Snapshots are single points in time. That's the catch. Attackers don't freeze just because you took a snapshot — processes keep running, credentials keep getting used, lateral movement continues, and data keeps changing. Modern DFIR often means "leave the system running and observe it live." And this is where cloud changes the game.
Live Forensics in Google Cloud: Ops Agent
Google Cloud provides a built-in way to collect live telemetry from VMs using the Ops Agent.
Instead of stopping the VM, you can collect logs, capture system metrics, monitor application behavior, and observe activity over time — crucial when you're scoping an incident, multiple systems are involved, you need timeline visibility, or shutting systems down simply isn't an option.
Think of Ops Agent as "your eyes inside a running cloud VM."
This is exactly the gap in the fernbridge-prod case — the mining VMs might already be gone by the time you get around to snapshotting anything. If Ops Agent had been running on them, you'd have live telemetry instead of a cold trail.
Snapshot vs Live Telemetry (Real Talk)
Disk Snapshot — strength: stable evidence. Weakness: single moment in time.
Ops Agent — strength: ongoing visibility. Weakness: requires pre-installation.
Logs — strength: broad coverage. Weakness: depends on retention.
In real investigations, you use all three.
Google Cloud Ops Agent — What It Really Does
If you've ever investigated a cloud VM and thought "okay, but what's happening right now on this box?" — that's exactly where Google Cloud Ops Agent comes in.
At a high level, Ops Agent is just a small agent running inside the VM (Linux or Windows) that watches logs and ships them to Google Cloud Logging.
But the important part isn't what it is — it's how it behaves during investigations.
Think of Ops Agent Like This
Instead of taking one disk snapshot and hoping it captured the right moment, Ops Agent lets you watch the system while it's alive, see logs as they're being generated, and build timelines without ever stopping the VM. For DFIR, that's huge.
How Logs Actually Flow (Simple Mental Model)
Here's what's happening under the hood:
Logs are generated on the VM — syslog, app logs, and auth logs on Linux; .evtx event logs on Windows
Ops Agent reads those logs locally
It converts them into structured JSON
It sends them to the Google Cloud Logging API
From there, your normal Log Sinks and Buckets take over
So Ops Agent doesn't store logs — it streams them.
Fluent Bit Is the Secret Sauce
Ops Agent is basically Fluent Bit wearing a Google jacket.
Why that matters:
Fluent Bit is fast, lightweight, understands a ton of log formats, and can parse messy logs into clean JSON. This is why Ops Agent works well even on busy systems — it's not some bloated collector.
What the Config Actually Looks Like
Fluent Bit doesn't guess what to watch — it reads a config file that spells it out. A basic Linux syslog receiver looks like this:
logging:
receivers:
syslog:
type: files
include_paths:
- /var/log/messages
- /var/log/syslog
service:
pipelines:
default_pipeline:
receivers: [syslog]
Why this matters for an investigation: this file tells you exactly which paths Ops Agent is watching — and just as importantly, which paths it isn't. If an attacker knows Ops Agent is running, quietly editing this config (or stopping the agent entirely) is a clean way to blind logging without triggering anything obvious.
That makes two commands you should run on every suspicious VM, not just the ones where you already suspect tampering:
# Is the agent actually running?
sudo systemctl status google-cloud-ops-agent
# What is it actually configured to collect — and when was this last touched?
cat /etc/google-cloud-ops-agent/config.yaml
stat /etc/google-cloud-ops-agent/config.yaml
(On Windows, the same file lives at C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml.) A config that's been trimmed down, or a modification timestamp that lines up with the intrusion, is itself an indicator.
Structured vs Unstructured Logs (Why You Care)
Not all logs are born equal. An unstructured line like:
Feb 2 10:41:02 sshd[2211]: Failed password for root
becomes, once Ops Agent gets to it, a structured record with a timestamp, hostname, process name, severity, and cleanly parsed fields — meaning you can search cleanly, build timelines, and correlate across systems instead of grepping raw text.
Ops Agent also adds its own timestamp when the log is received. This matters because formats like syslog often don't include full date or timezone info — that extra timestamp saves investigations more often than people realize.
What Logs Get Collected by Default?
Once Ops Agent is installed, it doesn't sit idle.
Out of the box, it starts collecting OS logs, common application logs, and auth-related events, and each one is tagged with the VM name, project name, and resource identifiers — that's how Google keeps logs from different projects from leaking into each other.
Finding Ops Agent Logs in Log Explorer
Logs follow a predictable pattern:
projects/[project-name]/logs/[log-name]. To narrow it down to one system, combine that with resource_name (the VM name). This is why Log Explorer searches often look a bit "busy" — you're filtering both what happened and where it happened.
Back to fernbridge-prod: this is the actual query you'd run, either in Log Explorer or from the CLI, to see whether Ops Agent caught anything before the instances were deleted:
gcloud logging read \
'logName="projects/fernbridge-prod/logs/syslog" AND resource.labels.instance_id="INSTANCE_ID"' \
--project=fernbridge-prod \
--limit=50 \
--format=json
Swap syslog for the log name you're after, and INSTANCE_ID for the VM's numeric instance ID (not its name) — that's what resource.labels.instance_id actually stores.
Installing Ops Agent (Zero Drama)
You've got two main options:
Option 1 — from inside the VM (manual, good for locked-down environments): SSH in, then run:
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
The agent starts automatically. Confirm it:
sudo systemctl status google-cloud-ops-agent
Option 2 — via Agent Monitoring Service (most common): from the Compute Engine or Cloud Monitoring console, click Install Agent — Google hands you the same script above, pre-filled, to run on the target VM (installation docs).
Even if you install it manually, Google Cloud still detects the agent, shows its status, and tells you which VMs are covered — so you always have visibility into coverage.
Why Ops Agent Beats Snapshots (In Many Cases)
Snapshots are useful, but they're frozen in time. Ops Agent gives you continuous visibility, ongoing timelines, and evidence while the attacker is still active — and in modern cloud incidents, you rarely investigate just one VM, you rarely have the luxury of stopping systems, and you need to observe rather than interrupt. Ops Agent fits that reality.
Multi-Cloud Bonus (This Part Is Underrated)
Ops Agent isn't limited to Google Cloud — you can run it on AWS Linux and Windows VMs and send those logs into Google Cloud Logging, using Google Cloud as a central log hub. This is surprisingly common in hybrid environments, migrations, and organizations tired of juggling tools. You just need an AWS connector project — after that, logs flow the same way.
What About the Legacy Agent?
You'll still see it in the wild.
Reality check: it's older, heavier, based on fluentd, and slowly being phased out.
Ops Agent uses Fluent Bit, uses less memory, scales better, and is clearly the future. If you see the Legacy Agent during an investigation, don't panic — just know it behaves
differently and may produce slightly different logs.
Compute Engine Attacks Aren't Theoretical (2025 Data)
If the fernbridge-prod scenario sounds oddly specific, that's because it's not far from real life.
Since 2023, Google has been tracking a financially motivated actor it calls TRIPLESTRENGTH doing almost exactly this: stealing credentials and session cookies (some sourced from Racoon infostealer logs), hijacking cloud service accounts, and spinning up Compute Engine instances purely to mine cryptocurrency.
Their playbook got smarter over time. Early campaigns just abused compromised accounts to create mining VMs directly. Later, they escalated — abuse a highly privileged account to add an attacker-controlled account as a billing contact, then use that billing access to spin up much larger compute resources for mining.
Tooling of choice: the unMiner app (which bundles several popular cryptocurrency miners into one package) paired with the unMineable pool, cashing out in TRX.
Google's own 2025 telemetry backs this up — in observed post-compromise activity, "Creation/Deletion of cloud instances" showed up as its own tracked category (4.4% of incidents), smaller than lateral movement (62.2%) but exactly the kind of spike Ops Agent and audit logs are built to catch.
DFIR takeaway: an unexpected compute spike or a new billing contact on a project is the pattern to check for first.
DFIR Takeaway
Ops Agent = live visibility
Snapshots = point-in-time evidence
Logs + telemetry = modern cloud forensics
Fluent Bit parsing = clean timelines
Project-level tagging = containment and scoping
If snapshots tell you what existed, Ops Agent tells you what's happening.
fernbridge-prod, resolved: it turned out to be a compromised service account with billing-contact privileges, used to spin up compute for mining — the TRIPLESTRENGTH pattern almost exactly.
Ops Agent hadn't been installed on the new VMs (they were too new), but the Admin Activity audit log for the IAM change on the billing account was enough to reconstruct the timeline — the kind of query that finds it:
gcloud logging read \
'protoPayload.methodName="SetIamPolicy" AND resource.type="billing_account"' \
--project=fernbridge-prod \
--freshness=30d \
--format=json
That single IAM change — an unfamiliar account added as a billing contact — was the actual root cause. Everything after it, including every VM Ops Agent never got a chance to watch, followed from that one event.
----------------------------------------------------Dean--------------------------------------------
Comments