The Tool Changes. The Question Doesn't: My Operation Cymbal CTF
I didn't know Google SecOps when I started. I knew how to investigate data, and I learned how to apply that thinking in a new environment.
Why I Joined
When I saw that Google Cloud Security was partnering with Hack The Box on a free community CTF, I applied right away. When my approval came through, I was excited, and honestly, a little nervous. This was Google and Hack The Box, on a platform I'd never touched. Would my skills hold up?
I'd been building my SOC and Blue Team skills through labs, log analysis, and hands-on investigations. This was my chance to find out.
I competed independently, under DataSec Chronicles. I wasn't waiting until I felt like an expert. If I'd done that, I'd still be waiting
Not My First CTF, but a New Kind of First
Operation Cymbal wasn't my first CTF. A week earlier, I competed solo in TryHackMe's Downtime event as Packet Poltergeist.
It took me three attempts to reach 999 points on a Splunk threat hunt. I nearly quit a Windows forensics challenge labeled "Easy" before finally capturing my first-ever flag. (The decoded message was The Ghost With the Most. For a team called Packet Poltergeist, in October, I couldn't have planned it better.)
Downtime taught me to separate attempted attacker activity from confirmed activity. Operation Cymbal pushed that a step further: separating unusual from relevant. And this time, I wasn't working in Splunk. I was learning Google SecOps as I went.
What Was Operation Cymbal: Cold Room?
The setup: I was an independent breach investigator at a fictional firm, Cymbal Investments, during a high-stakes week. The environment was frozen in time (the "Cold Room"), and three intrusions overlapped inside it. The core challenge was telling attacker behavior apart from routine admin maintenance.
Scenario | Difficulty | Result |
Deceptive Click | Very Easy | 6/6 flags |
OAuth Heist | Easy | 6/6 flags |
Rogue Synthesis | Medium | 6/6 flags |
Without giving anything away, the themes covered suspicious downloads and endpoint activity, identity compromise, and development or automation activity that may not have been what it seemed.
Preparation Versus Reality
I came in with some experience: security logs, SOC simulations, a Splunk threat hunt, and my own Zeek investigation of a Mirai botnet. Google SecOps was still brand new to me.
The biggest shift was UDM, Google's Unified Data Model. Every log is normalized into one schema, so instead of searching vendor-specific fields, you search shared ones. Who did it, what they did it to, and what kind of event it was. Conceptually, that made sense. Writing the queries under time pressure was another story.
I went back to the event documentation and the kickoff livestream more than once to understand the environment and the available telemetry. My experience helped. It didn't eliminate the learning curve.
Investigating Under Pressure
This wasn't a string-search exercise. Each scenario meant reconstructing what happened: comparing timestamps, connecting identities to activity, and testing possible explanations against the logs.
The process wasn't linear. Some searches came back empty because I was asking the right question with the wrong field. Others came back full of noise because I hadn't narrowed the question enough. More than once, I had to step back and rethink an assumption before the evidence made sense.
That back-and-forth felt familiar. It's the same loop I use in data analysis: ask, check, refine, ask again.
When Something Suspicious Wasn't the Answer
During Rogue Synthesis, I noticed activity from an account that didn't seem to fit. It stood out, so I dug in.
Unusual doesn't automatically mean malicious, or even relevant. The more I checked the surrounding evidence, the less it fit the story the scenario was telling. The data eventually pointed me toward a different line of activity entirely, and that's where the real investigation was.
This is where my analytics background earned its keep:
Spot an anomaly.
Form a hypothesis.
Check the supporting evidence.
Reject or refine the assumption.
Follow the data to a better-supported conclusion.
In analytics, chasing the wrong outlier wastes a report. In security, it can waste the hours an attacker is counting on. Learning to let go of a lead is as important as finding one.
The Challenges Weren't All Technical
Some of the friction had nothing to do with security. There were event-access hiccups, a few confusing logistics, and moments of leaderboard frustration. Even finding my completion certificate afterward took some digging.
That's not a complaint. Running a free event for well over a thousand teams is a big lift, and I'm grateful it existed. It's just the honest picture: real learning comes with friction, and pushing through it is part of the skill.
Using AI Without Outsourcing the Investigation
I used AI as a study partner: to explain unfamiliar concepts, think through query structure, and troubleshoot when a search wasn't returning what I expected.
What I didn't do was let it decide what happened. A plausible explanation isn't evidence. Every conclusion still had to hold up against the actual logs in front of me.
It's the same thesis behind my recent builds: AI explanations are not a substitute for verified evidence. This CTF was a chance to practice what I've been preaching.
The Results
I finished all 18 flags across all three scenarios.
Measure | Result |
Flags captured | 18/18 |
Scenarios completed | 3/3 |
Points earned | 2,075 |
Final placement | 462nd of 1,716 registered teams (about the top 27%) |
I earned the Hack The Box completion certificate, plus a Google Cloud Security Community continuing education certificate listing three CPE credits. I've submitted those credits to ISC2 and am waiting on review.
What I'd Do Differently
Learn the query language earlier.
I'd spend more time with the data model and available fields before jumping into individual questions.
Keep better investigation notes.
I want a record of each hypothesis, the useful queries, the evidence, and why I ruled leads out. That would also make a future technical case study much easier. (This is the same lesson Downtime taught me. Apparently I needed it twice.)
Separate event friction from investigation challenges.
Some of my struggles were about access and navigation, not cybersecurity knowledge. Knowing which is which keeps frustration from turning into self-doubt.
Trust the process.
An unfamiliar platform doesn't mean my analytical skills stop working.
How I'd Explain This in a SOC Interview
During the Google Cloud Security Community CTF, I independently investigated three simulated security incidents using Google SecOps. It was my first time on the platform, so I learned UDM querying while analyzing the telemetry.I approached it with skills from my data analytics background: identifying anomalies, correlating events, testing hypotheses, and validating findings against evidence. One key lesson was that unusual activity doesn't mean you've found the answer. I chased a false lead, refined my searches, and separated assumptions from supported conclusions. I completed all 18 challenges, and the experience showed me how well analytical thinking transfers to security operations, and which technical skills I want to keep building.
The Tool Changes
My first experience with Google SecOps didn't begin with knowing every query or understanding every log. It began with questions, evidence, and a willingness to keep investigating.
I came into cybersecurity from data analytics, and this CTF reminded me that the skills I've spent years developing still have a place here.
The tool changes. The question doesn't.
Find what doesn't belong. 🔎💜
Comments