Hunting with the LimaCharlie Query Console - Webinar

Most hunting platforms train a bad instinct. Because querying old data is slow and expensive almost everywhere else, analysts learn to hoard, to wildcard, to throw a year of telemetry at the wall and sift the wreckage. Matt's session on the LimaCharlie Query Console is, underneath the demos, an argument that this instinct is the enemy. The platform removes the two penalties that usually justify it, latency on old data and cost on recent data, and once those are gone the only scarce resource left is the analyst's attention. Almost every pro tip he offers is really a rule for not wasting it.

Cost and latency stop being the things you optimize around

Two facts reframe everything that follows. Every telemetry source you send into LimaCharlie, whether an EDR sensor, third-party logs, or an adapter, carries a year of retention in hot storage. And any query that runs inside the last 30 days is free, with only data older than that billable. Matt is blunt that this is not incidental: he credits the engineering team for the storage and query work that makes the free window possible, and he wants people to exploit it.

The consequence is a workflow that inverts the usual order. Instead of carefully rationing expensive historical queries, you build and test logic inside the free 30-day window until it returns exactly what you want, then change one thing, the time frame, to reach further back. Everything else in the query stays identical. For a provider standing up a hunting practice across many tenants, that is how you validate a reusable library without burning budget on iteration. It also quietly fixes incident response, since a fresh investigation is mostly querying recent activity anyway, which means the work you do most often is the work that costs nothing.

The latency half matters just as much because it kills the mental model analysts import from other tools. Matt has run searches against data six, eight, ten months old and describes them as fast, not degraded. More to the point, a historical hit drops you straight back onto the timeline around that event, so you can read the surrounding context the same way you would for something that happened an hour ago. He is explicit that he has used too many platforms where crossing some recency threshold meant cold storage, half the events, and a different and worse kind of analysis. Here, old does not mean lesser. That removes the second excuse for hoarding: you no longer need to grab everything now because retrieving it later will hurt.

Precision is for the analyst, not the machine

Once cost and speed are off the table, the case against wildcarding has to rest on something else, and Matt is clear about what that is. A wildcard query still runs. The computer can handle 50 bales of hay. The problem is that you then have to dig through 50 bales of hay. His framing is consistent throughout: the point of a query is to reduce analyst work, not to manufacture a thousand-row CSV that someone now has to read.

This is where the console's structure earns its keep. A query has four required parts, time frame, sensors, events, and a filter, and each is an opportunity to narrow before you search rather than sift after. The events field is the sharpest example. When you are hunting an indicator that only ever lives in one event type, a domain resolved in a DNS request, naming that event costs you nothing and optimizes the query, because the indicator cannot appear anywhere else. When you are hunting a technique like PsExec, which can surface as a service, a process, or a parent process, a broader selection is justified, and Matt is careful to call it a deliberate trade-off rather than laziness. The filter layer reinforces the same discipline with operators that go well past equality: contains, regex, starts and ends with, CIDR notation, is tagged, and decorations like "with child" and "with descendant." His example, asking for any process whose parent has a child of powershell.exe instead of hand-wiring parent-and-child conditions, is precision that also happens to be simpler to write. Tagging extends the idea to context the data does not carry on its own. If RDP is expected to and from certain systems but anomalous between workstations, tagging workstations lets you hunt that outlier directly instead of filtering it out by eye.

Built for teams that run many tenants

The features Matt flags as new are the ones that matter for an MSSP or MDR rather than a single analyst. Saved queries let you hand a hunt to any teammate with access to the same organization, which is how a task moves between people on a team. He is candid about the current limits: saving is org-wide for now, so anyone with access to that organization, including a customer in the UI, can see the saved query, and user-scoped saving is still coming. There is no folder nesting either, so he uses naming as a stand-in, labeling a query with a date and an intent like "September 2024 hunt, processes in userpublic" so it stays findable.

The console's validation is built for the reality of managing many organizations at once. It checks a query against the current org and warns you when, say, a Windows query cannot run because the org has no Windows sensors, which is exactly the failure you would otherwise hit while copy-pasting queries across tenants. That same trap shows up in the platform field, where Matt notes analysts get stuck searching Windows for telemetry that actually lives in Microsoft 365. And for heavy users, the command line lets you set the time frame, sensor selector, and events as variables, then run paged queries, non-paged queries, or a dry run that estimates cost before you commit. The dry run is the natural endpoint of the whole session's logic: a way to know what a search will cost before you spend a single analyst-minute on it.