Detection Engineering with LimaCharlie and Claude Code

Prerequisite: Everything in this guide assumes Claude Code is already integrated with your LimaCharlie instance. If you have not integrated Claude Code with LimaCharlie, we have a brief tutorial on how to do so. 

Detection engineering is fundamentally a translation problem: rules need to be converted between formats, IOCs need to be converted into detection logic, and noisy alerts need to be converted into precise suppressions. That translation work is what consumes analyst time, and it's what Claude Code handles well. Once Claude Code is connected, you can use the CLI for all of it: writing detections, translating community rules, generating rules from threat intelligence, and tuning out false positives. This post walks through each of those workflows with example prompts and an explanation of what each one is actually doing.

Translating community detection rules

Community detection repositories exist because writing rules from scratch is expensive and most teams don't have the bandwidth for it. Rules require translation before they'll run on a security platform, a time-consuming task that diverts analyst expertise toward performing menial work. Rule translation is exactly the kind of repetitive, structured task that Claude Code handles well.

This prompt pulls auditd-based Linux detection rules mapped to MITRE ATT&CK from a GitHub repository and converts them into LimaCharlie's detection and response (D&R) format:

In the [YOUR ORG NAME] org create new Linux detections based on rules in this repository https://github.com/bfuzzy/auditd-attack. Respect the license and prefix all rules created with "_claude". Include the mitre att&ck tags as tags in the detection. Add a description of what the rule is doing as a comment in the detection. Apply and test the rules.

Notice how this prompt is constructed. It specifies the org, the source repository, a naming prefix for traceability, MITRE ATT&CK tag inclusion, and a plain-language description embedded as a comment in each rule. It also explicitly tells Claude to respect the license, which matters when you're pulling from public repos and deploying at scale.

The result is a set of D&R rules populated in your LimaCharlie org with detection logic, MITRE tags, and comments explaining what each rule looks for. You can verify the translation by clicking into any individual rule in the platform.

To do a quick functional test after deployment, run whoami in a terminal on your Linux endpoint. Several of the audited rules will fire on that command, confirming the detections are active and evaluating events correctly.

Building detections from threat intelligence

Community rule repositories are useful, but they're backward-looking by nature. For emerging threats, a more direct approach is pulling IOCs from current threat intel and immediately building detections around them.

This prompt does that using a published malware analysis report:

Use the IOCs in this article to create detection rule(s) with the prefix "_article" in the detection name and apply and test them on the [YOUR ORG NAME] org: https://www.cyfirma.com/research/github-abused-to-spread-malware-disguised-as-free-vpn/

Claude reads the article, extracts the relevant indicators (in this case file hashes and other IOCs from malware disguised as free VPN software), and builds LimaCharlie D&R rules around them.

Depending on how you phrase the prompt, Claude can either hardcode the indicator values directly into detection logic or structure them as a lookup table (threat feed) that can be updated independently of the rule itself. If you have a preference, specify it in the prompt.

The detection coverage here is against Windows targets, since the malware in the article targets that platform. Testing on a Linux-only lab environment won't produce hits, but the rules will be in place and evaluating telemetry if Windows sensors are added later.

The steps that would otherwise happen sequentially across multiple tools (reading the report, extracting IOCs, writing rule logic, formatting for the platform, and deploying) happen in a single prompt execution.

Tuning rules and suppressing false positives

Once detections are running, reducing noise is the next problem. Rules translated from community sources are often broad by design and will fire on benign system activity in production environments. 

Identifying which rules are generating the most noise, evaluating whether those alerts are legitimate, and writing suppression logic is time-consuming to do manually.

This prompt automates that triage:

Look at the detections in the [YOUR ORG NAME] org with the "_claude" prefix and identify the top 3 nosiest rules. If you have high confidence the alerts are benign create a false positive rule for each, apply it and test it to make sure it is working. Then list the rules you wrote the false positive rule for.

Claude examines the detection history for the specified org, identifies the three highest-volume rules under the _claude prefix, evaluates the alert context, and (where it can confidently determine the alerts are benign) writes and applies a suppression rule for each. It then reports back which rules it acted on.

The high-confidence qualifier in the prompt is intentional and worth keeping. You're not asking Claude to suppress everything that looks noisy; you're asking it to suppress what it can clearly identify as safe. Anything it's uncertain about is left for human review. 

Exporting to infrastructure as code

Rules written and tuned through Claude Code don't have to stay confined to the org where you built them. Once detections are in good shape, LimaCharlie's Infrastructure-as-Code (IaC) export or GitSync integration lets you version-control them, deploy them across multiple orgs, and manage them through standard engineering workflows. 

The AI-assisted development cycle and the IaC deployment pipeline work together. You use Claude Code to build and refine, then promote the output through your team’s standard infrastructure management process.

Additional prompts worth trying

The four workflows above cover the core detection engineering loop: translate, build, deploy, and tune. 

Once you have the environment running, these prompts extend that foundation:

• Output an HTML report with graphs showing current MITRE ATT&CK coverage — useful for understanding where your detection coverage has gaps across the ATT&CK matrix.

• Summarize the detections and alerts triggered over the past two hours — gives you a fast situational snapshot without navigating to the detections page manually.

• Convert this repository of Sigma rules to LimaCharlie's YAML format — extends the translation workflow to Sigma, which has a large and actively maintained community ruleset.

Each of these prompts follows the same pattern as the ones above: be specific about the org, the scope, and the output format you want. The more precisely you describe the outcome, the less cleanup the result requires.

The bottleneck in detection engineering has never been analyst judgment. It's been the translation work that consumes analyst time before any judgment gets applied. Claude Code handles the translation; analysts handle the decisions that require expertise. To get started, visit app.limacharlie.io/signup.