Trawling for IOCs: Catching C2 in a Sea of Data

Trawling for IOCs: Catching C2 in a Sea of Data

Speaker: Moses Schwartz

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch the full talk

Reading time: ~7 minutes

TL;DR

Detection engineering today scales linearly with headcount — more rules require more engineers, and the backlog compounds. Moses Schwartz from Google Security Operations presents a data-driven detection engineering approach that uses VirusTotal's signing certificate data, sandbox execution behavior, and GitHub repository tracking to automatically generate and maintain threat feeds and detection rules, reducing the manual toil that keeps the discipline from scaling.

Introduction

Detection engineering faces an engineering productivity problem that most disciplines grew out of years ago. The dominant workflow — an analyst reads a threat report, forms a hypothesis about what malicious behavior looks like, writes a detection rule, tunes it, deploys it, and maintains it forever — scales linearly with people. Double the desired rule coverage, double the headcount. And because existing rules require ongoing maintenance as the threat landscape shifts, a large rule set becomes a form of technical debt that demands even more people just to hold steady.

Moses Schwartz, who works on the Google Security Operations product team writing rules and developing threat feeds, describes this as the problem he wants to solve. His answer is data-driven detection engineering: using the data already available in platforms like VirusTotal to automatically discover, generate, and maintain detection inputs, turning the analyst's manual workflow into a feedback loop that improves over time without proportional labor investment.

Schwartz presented at BSidesSF 2025 as a three-time conference presenter, walking through two concrete techniques — signer identity pivoting and GitHub repository tracking — with live VirusTotal queries, SQL examples from Google's internal infrastructure, and an honest accounting of where the dragons are hiding.

▶ Watch: The case for data-driven detection engineering (00:00)

The Core Concept: Data-First Detection

Traditional detection starts with a threat — a reported technique, a known attacker behavior, a published IoC — and works forward toward a rule. Data-driven detection inverts this: it starts with the available data and asks what interesting patterns can be extracted from it automatically. The output is labeled telemetry — curated data sets with real signals — that feeds a continuous improvement loop rather than a static rule backlog.

Schwartz is careful not to oversell the current state of the art. The "grand vision" of a fully automated feedback loop where labeled telemetry continuously refines detection quality is not yet realized even at Google scale. But the individual techniques he demonstrates are practical enough to apply with free-tier access to VirusTotal and basic scripting knowledge.

▶ Watch: From hypothesis-first to data-first (02:00)

Technique 1: Signer Identity Pivoting

Most executables running on modern Windows systems are digitally signed — unsigned binaries increasingly fail to run at all. This creates an underexploited pivot point: if you know who signed a piece of software, you can use that signing identity to discover all other files signed by the same entity.

Schwartz demonstrates this using UltraVNC as a working example. The relevant signing certificate belongs to "UVNC BVBA." A simple VirusTotal search for signature:UVNC BVBA returns approximately 6,000 matched files, all verified as legitimate UltraVNC components — WinVNC, VNC Viewer, UltraVNC installer variants across versions and architectures.

▶ Watch: Signer identity pivoting with UltraVNC (04:00)

The practical applications are dual-use. For non-malicious tooling like UltraVNC, the resulting hash list can serve as an allowlist — any binary claiming to be UltraVNC that does not appear in the VirusTotal-derived feed is suspicious. For remote access tools known to appear in threat campaigns, the same technique builds an inventory of known legitimate samples that can sharpen alerting rules and reduce false positives.

Inside Google Security Operations, this runs at scale. SQL queries against the VirusTotal dataset — structured as SELECT hash FROM vt_data WHERE signer = 'X' — execute periodically across a configuration file full of known remote access tools: UltraVNC, RUdesktop, and many others. Results are aggregated into a single development feed, tested internally, then promoted to the production product. The secret sauce, Schwartz notes plainly, is the ability to run SQL joins across multiple VirusTotal datasets at once rather than navigating APIs one pivot at a time.

Technique 2: Tracking GitHub Repository C2

Attackers operating in PowerShell frequently pull payloads, tooling, or second-stage downloads directly from GitHub repositories. Tools like PowerSploit and PowerShell Empire are well-known enough to hard-code; the interesting detection surface is the long tail of less-famous repositories — and ephemeral repos created for a single campaign and deleted days later.

The detection approach leverages VirusTotal's sandbox execution behavior data. Rather than searching static file properties, Schwartz writes a YARA rule that queries the VT module's sandbox behavior fields — specifically looking for PowerShell processes that make HTTP connections to raw.githubusercontent.com.

▶ Watch: Detecting GitHub-sourced C2 with YARA and sandbox data (12:01)

The VirusTotal Livehunt rule runs continuously; a retro hunt against historical data returns results almost immediately. From there, a Python script calls the VirusTotal API, pulls behavior summaries for matched samples, extracts HTTP connections matching the GitHub user content pattern, and produces a list of repositories referenced by suspicious files. Schwartz shows his actual output: alongside expected entries like PowerSploit and PowerShell Empire, the results surface repositories with names like evildev and RainV_exploit — sitting right next to more ambiguous entries like what appears to be a third-party Spotify client.

This is where the data-driven approach pays off: rather than trying to guess in advance what GitHub repositories attackers might use, the detection surfaces them empirically from observed behavior in VirusTotal's sandbox corpus.

The Dragons: Automation Gotchas

The talk's most technically specific section covers the obstacles that make automation harder than it looks. Schwartz is direct about these, calling them the places "where there are dragons."

Template-generated rules. When generating one detection rule per GitHub repository using Jinja2 templates and Python, the rule identifier (which cannot contain slashes or dots) must be derived from the repository URL through string sanitization logic. Missing this means all generated rules share the same identifier, which breaks the detection system.

Regular expression escaping. Dots in domain names are interpreted as "match any character" in regex, which is usually benign but occasionally causes false matches. More problematic: backslash escaping in Python strings that then pass through additional processing layers can require triple-escaping, and calculating the correct number of backslashes depends on the full processing chain in a non-obvious way.

▶ Watch: Normalization and the backslash escaping problem (18:01)

Schwartz's solution is a normalization layer: a library of normalizers that replace problematic patterns (like Windows drive letter variants) with placeholder tokens during intermediate processing, then denormalize back to proper escape sequences when writing final rule output. This approach also enables copying patterns between files and across different detection languages without manual re-escaping.

Rule aging. GitHub repositories may be ephemeral. A repo that triggered detections last week may be gone today. Maintaining a growing set of rules for dead repositories is pure technical debt. At Google scale, this means building rule aging mechanisms alongside rule generation — adding rules is only half the automation problem.

The Broader Vision

Schwartz frames all of this within a goal that is not yet achieved: a continuous feedback loop where analysis strategies automatically improve detection coverage, engineers spend time on decisions rather than on maintenance, and the detection corpus grows faster than the threat landscape.

▶ Watch: The data-driven vision and where we stand (20:01)

The Q&A surfaces a telling observation: asked whether deep learning or LLMs would improve the approach, Schwartz is enthusiastic in principle but pragmatic in practice. Regular expressions and straightforward SQL queries are still producing highly valuable signals at Google scale — the basics have not been exhausted. The pressure to add "advanced super deep learning AI" to detection engineering, he suggests, often comes before the fundamentals are solid.

He also notes, with evident enthusiasm, that several of the techniques demonstrated in the talk are accessible with free VirusTotal access, just rate-limited. The infrastructure to replicate the signer identity pivot and the sandbox behavior hunting rule does not require Google-scale tooling.

Notable Quotes

"The secret sauce really is that we can run SQL queries against everything. That is what makes a lot of our analysis so much easier." — ▶ 08:01

"We're still just scratching the surface. There's so much basics that can really get you pretty far, right?" — ▶ 24:02

"Threat feeds are a little bit misleading because good thing feeds are totally legitimate and useful for a lot of detections." — ▶ 22:01

Key Takeaways

• Detection engineering scales linearly with people under the traditional hypothesis-first model. Data-driven approaches break this constraint by automating the discovery and generation of detection inputs.
• Signing certificate pivoting in VirusTotal is an underused technique for building hash feeds of both malicious and legitimate software families, enabling allowlisting and anomaly detection simultaneously.
• Sandbox behavior data in VirusTotal surfaces C2 repository references that static analysis would miss entirely, including ephemeral repos created for single campaigns.
• Automation has real gotchas — template naming collisions, regex escaping layers, and rule aging are practical obstacles that must be engineered around, not hand-waved.
• The basics are still productive. SQL queries, regex, and YARA rules are generating high-value signals at Google scale; adding machine learning should follow rather than replace foundational data hygiene work.