From Detection to Action: How Thomas Murray Transformed Their Incident Response with LimaCharlie

Most security teams talk about automation as a feature they will get to once the platform is bedded in. Guillermo Roman, a senior DFIR analyst at Thomas Murray, treats it as the entire job. His argument in this session, hosted by LimaCharlie's Christopher Luft, is blunt: if you have not stopped to find the manual steps in your day to day work and engineered them away, you will be too slow when a real threat is live in a client environment. Speed is not a nice property of a response practice. It is the practice. Everything Roman demonstrated was built to collapse the gap between an event happening and someone, or more often nothing human at all, acting on it.

Thomas Murray is a global risk intelligence company that stood up a cybersecurity consultancy a couple of years ago, with an open risk team that does response, pen testing, red teaming, and threat intelligence for clients in finance, banking, and government. Roman has spent about eight years in forensics and response, mostly reacting to ransomware and the rest of the catalog of compromises a company can suffer. That background shapes the whole approach. He has felt what it costs to log into a platform mid incident, hunt for the right endpoint, list processes by hand, search for files by hand, and isolate a host by hand. The system he built exists so that no one on his team ever has to do that under pressure again.

Enrollment as a trigger, not an event to read later

The clearest expression of his thesis is what happens when a new sensor comes online. In most shops, a new agent enrolling is a line in a log somebody might glance at. At Thomas Murray, a detection and response rule matches the enrollment event, confirms there was no error, and immediately fires an output. That output is a signed webhook into n8n, the automation server they run, which posts a notification to Slack and turns around and calls back into LimaCharlie to kick off forensic collection. So the moment a Windows machine joins the environment, a full export of its Windows event logs is already being pulled through the Velociraptor extension, written to an internal file server, and announced in Slack when it finishes. A new device coming online stops being something to investigate and becomes the thing that starts the investigation. For a provider onboarding clients, that means evidence acquisition begins at enrollment with zero analyst time spent.

The architecture under this is deliberately small. Three LimaCharlie primitives do the work: D&R rules to detect and react, outputs to push events to external systems, and the API to send commands back in. n8n sits in the middle as the orchestrator, and Roman is careful to say you are not married to it. Microsoft Power Automate, Tines, or even plain Python scripts could occupy the same slot. What matters is the loop, not the brand. Events flow out through webhooks, n8n formats and enriches them and can fan out to other systems, and to act back on the platform the workflow requests a JWT from an API key and uses it to list sensors, isolate or de-isolate a host, pull sensor details, or trigger an extension.

The detail that makes it cheap to run at scale

One design choice does more work than it looks like. When a collection job finishes, LimaCharlie generates an event back through the stream rather than making the caller ask repeatedly whether it is done. Roman flagged this as something genuinely valuable about the platform. A domain controller's logs can take a long time to pull, and the network on the far end is out of your control. A system that forces you to poll for completion either wastes cycles checking every minute or sits in a wait loop forever, and Roman pointed out that this is exactly what some other platforms make you do. Event driven completion frees that processing capacity, which in his framing also means less energy spent and a slightly cheaper operation overall. For a team running this across many tenants at once, the difference between polling and being notified is the difference between an architecture that scales and one that grinds.

This is also where Roman's case for Velociraptor through LimaCharlie lands. He has gathered evidence plenty of other ways, with other forensic tools, with PowerShell scripts, with third party packages. Done manually that path is at least three API calls, one to deploy the tool, one to run it, one to retrieve results, plus the burden of actively querying for completion or building your own notification channel from the endpoint back to you. The Velociraptor extension folds all of that into a single API call and hands the completion notification back for free. The forensic outcome is the same. The operational tax is not.

A shared channel as the single surface

The other half of the system is manual response driven entirely from Slack. A list sensors command returns a live inventory plus a CSV export dropped into the channel, which doubles as something you can hand a client to show how many endpoints you are watching. A sensor info command returns one host's isolation state, online status, platform, internal and external IP, version, and first seen date. Isolation and de-isolation go out the same way, and Roman showed a host losing its network and getting it back in real time, with a nice piece of API symmetry underneath: the same endpoint isolates on a POST and releases on a DELETE. Every command travels through a signed webhook that n8n verifies came from Slack before acting on it.

The point of routing all this through one channel is not convenience. It is that the whole team sees the same information at the same instant, and any analyst can take a triage decision and task it immediately while everyone else watches the result arrive. That shared visibility, Roman said, is where most of the time savings actually come from. It is the difference between a coordinated response and several people quietly working the same incident in isolation.

What made LimaCharlie the right foundation for this is consistent with the whole philosophy. Roman needed a clean, well documented API he could build against fast, because his work is full of multi step investigations that demand quick queries and usable results, and he kept returning to the same observation: automations that would take days or weeks elsewhere come together in hours here. Cost mattered too, in a specific way. The usage based model lets Thomas Murray enroll clients quickly with a precise, predictable EDR budget, which makes pricing a new engagement something you can forecast rather than guess. And there was no leap of faith involved. A free trial with two sensors let him prototype the full integration before committing, so the platform proved the claim instead of asking him to believe it. For a provider deciding what to build a response practice on, that combination, fast to build, predictable to price, and provable before you pay, is the real argument.