Automating Incident Response Workflows with LimaCharlie

The hardest question in incident response is rarely what is happening now. It is what happened before you arrived. Eric Capuano, who came to LimaCharlie from a career in security operations, digital forensics, and incident response, opens this session by naming the trap that every responder knows and most tooling ignores: the tools to answer that question already exist, and they are good. Velociraptor, Hayabusa, and Plaso are open source, capable, and free. The thing that breaks is scale. Run them across an intrusion that touches dozens of systems, churn through gigabytes of artifacts per host, and you are no longer doing forensics. You are running a small data center, paying for compute and babysitting infrastructure, all to produce the one deliverable that actually moves an investigation forward: a granular chronological timeline of what happened on the hosts in scope.

Capuano's argument is that the bottleneck was never the tools. It was the infrastructure you had to wrap around them. The moment you stop owning that infrastructure, the economics of incident response change.

EDR sees forward; the work is reaching backward

Drop a LimaCharlie EDR agent into a fresh environment and you get exactly what every EDR promises: real-time telemetry, live command and control, detection and response running from the second the sensor lands. Capuano does not undersell that, but he is blunt about its limit. No EDR, regardless of which one you prefer, can see what happened before its sensor was installed. The agent gives you a forward-looking view and a hard wall behind it.

That wall is where most of the actual investigation lives. The intrusion started last week, or last month, and the responder's job is to reach back across that gap. Capuano's framing reorients the whole exercise. The agent is not just a sensor for what comes next. It is the delivery mechanism for reaching backward in time, pulling the historical artifacts off a compromised host, and ideally processing them too. He is explicit that the part he gets most excited about is not collecting evidence. It is having the platform handle the processing, so that what comes out the other end is a timeline ready for analysis, not a pile of raw event logs to sift by hand.

The platform as the compute layer, not just the collector

The pipeline Capuano demonstrates is deliberately undramatic to operate, and that is the point. He labels the relevant hosts as compromised, then points a Velociraptor triage acquisition at every sensor carrying that tag. One argument, KapeTriage equals y, against the KapeFiles targets artifact, tells Velociraptor to collect hundreds of artifact types: registry hives, event logs, evidence of execution like prefetch and Amcache. Velociraptor runs as a LimaCharlie extension, so there is no Velociraptor server to host. The acquisitions land as artifacts in the platform.

From there, the detection and response engine does work it was not originally famous for. Capuano is careful to point out that these particular rules are not hunting threats. They are automating the platform. One rule watches for completed Velociraptor acquisitions and routes them to Hayabusa. Another routes them to Plaso. The extensions are smart about what they ingest: Hayabusa, built only for event logs, simply unzips the full triage acquisition and pulls the EVTX files itself, which keeps the rule logic trivial.

This is where the ownership argument turns concrete. Plaso, also known as log2timeline, is the heaviest piece of the stack. Capuano is candid that it is compute-hungry, that it wants a 32-core machine to perform well, and that running it on a laptop is a different experience entirely. His earlier work, including a 2021 talk at the SANS DFIR Summit with Whitney Champion, did this at scale but still demanded heavy hosted systems and the bill that comes with them. What is genuinely new, he says, is that all of that compute now runs inside the platform. A 65-megabyte triage acquisition expanded into a 1.68-gigabyte timeline in his example, and no analyst had to provision a single VM to make it happen. For a provider, that ratio is the whole story: the granularity you want is expensive to produce, and the expense is now somebody else's problem to scale.

Filtering, not just generating

Producing forensic data is easy. Producing data an analyst can act on is the harder discipline, and Capuano builds the filtering directly into the flow. Hayabusa, from Yamato Security in Japan, evaluates event logs against thousands of Sigma rules and its own built-in detections, which means it surfaces retroactive detections of activity that predates the agent by a week or a month. Raw, though, that output is mostly informational noise, logons and logoffs. So he sends Hayabusa's findings to the sensor timeline, then uses a second detection and response rule to forward only the medium, high, and critical results to the LimaCharlie detections page, where the team already works. What lands there is the noteworthy material: suspicious service installs, cleared logs, firewall rule changes. Plaso, by contrast, can emit hundreds of thousands or millions of timeline rows, so he deliberately does not push it to the timeline. He keeps the key info summary, which reports what each parser found, and sends the full output to artifacts for review in a CSV viewer or, if you want collaborative analysis, an external Timesketch instance fed automatically by the platform.

What ties this together for an MSSP or MDR is reproducibility. Capuano references a companion blog post with a copy-pastable infrastructure-as-code template that enables the three extensions and installs the routing rules in any organization. Paste it into a new tenant's IaC settings, apply, and the pipeline exists. For a provider standardizing IR delivery across a client base, that is the difference between a clever one-off workflow and an operational capability you can deploy per customer in minutes. He notes you can even chain a YARA memory detection to trigger the acquisition automatically, though he is honest that most responders prefer to decide deliberately when to pull a triage, which is why the label-driven approach is the default.

Strip away the demonstration and the claim is simple. The tools were never the constraint. The infrastructure was. Move the compute into a platform you configure rather than maintain, and an analyst can label a host, press one button, get a coffee, and come back to timelines, across one endpoint or a hundred, without the cost to serve climbing every time a client environment grows.