Writing Sigma correlation rules for multi-stage attack detection

Single-event detections are useful, but many real intrusions only become meaningful when you connect several low-signal actions into a sequence. That is where Sigma correlation rules come in. For a technical team, the value is not in writing a clever query for one log line. It is in expressing a detection hypothesis that spans multiple events, multiple data sources, and a bounded time window.

In practice, multi-stage detection is how you move from alerting on isolated noise to identifying behaviour that looks like an attack chain. A failed logon, a suspicious process start, and a remote service creation may each be weak on their own. Together, they can be enough to justify investigation. This article focuses on how to design those rules in a way that is operationally useful for UK SMEs, where telemetry quality, analyst time, and platform constraints all matter.

What Sigma correlation rules are and when to use them

Sigma is commonly used to describe detections in a backend-agnostic format, then translate them into a SIEM query language. Correlation rules extend that idea by allowing you to relate events over time, rather than matching a single event shape. In other words, a standard Sigma rule asks, “Does this event look suspicious?” A correlation rule asks, “Do these events, taken together, look like a sequence of attacker behaviour?”

That distinction matters because many techniques in building SIEM detections using Sigma rules are still single-stage by design. They are excellent for high-confidence signals such as a known malicious command line, but they do not always capture the wider campaign context. Correlation is more appropriate when you want to connect identity abuse, endpoint activity, and lateral movement into one detection story.

Typical use cases include credential theft followed by remote access, initial access followed by persistence, or suspicious administrative activity followed by data staging. These are all examples of behaviour that may be individually ambiguous but collectively meaningful. Correlation is especially useful when you already have decent endpoint and identity logging, but need to improve detection depth without flooding the SOC with isolated alerts.

Prerequisites before you write a correlation rule

Before writing any correlation logic, confirm that your log sources can actually support it. Correlation rules are only as strong as the fields you can reliably join on. You need consistent hostnames, user identifiers, process metadata, and timestamps across the datasets you intend to combine. If one source uses a display name, another uses a UPN, and a third uses a SID, your joins will be fragile unless you normalise them first.

Normalised timestamps are equally important. If one source is in UTC and another is local time, or if ingestion latency varies significantly, your time window may miss the relationship you are trying to detect. This is a common reason correlation rules appear to “work in testing” but fail in production. For that reason, make sure your SIEM pipeline preserves event time, ingestion time, and source time where possible, and be explicit about which one your backend uses for correlation.

Field consistency also affects entity resolution. If you are correlating by user, decide whether the rule should use a stable identity such as SID or object ID, rather than a mutable display name. If you are correlating by host, decide whether the canonical entity is the device name, agent ID, or cloud device identifier. These choices are not cosmetic. They determine whether your rule survives renames, reimaging, and hybrid identity complexity.

For teams building out central visibility, it is worth revisiting the broader logging model in achieving centralised visibility across endpoints, identity, and network. Correlation works best when the underlying visibility model is already coherent.

How to model a multi-stage attack chain

The safest way to design a correlation rule is to start with an attack narrative and break it into observable behaviours. Do not begin with the query language. Begin with the sequence you want to detect. For example, if you are modelling credential compromise, the stages might be suspicious authentication, privilege use, remote execution, and post-authentication discovery. Each stage should map to one or more log events that you can actually collect.

Once you have the sequence, map each stage to MITRE ATT&CK techniques. This gives you a shared vocabulary for coverage discussions and helps you avoid overfitting to one vendor’s log schema. For example, a remote service creation may align to lateral movement, while a scheduled task may align to persistence. The point is not to force every rule into ATT&CK, but to make the detection intent explicit and reviewable.

A practical approach is to define the minimum viable chain. Ask yourself which stages are essential for confidence, and which are supporting context. If a stage is optional, treat it as enrichment rather than a hard dependency. That keeps the rule resilient when telemetry is incomplete. It also reduces the risk of missing a genuine attack because one intermediate event was not logged.

Core building blocks of a Sigma correlation rule

At a structural level, correlation rules usually need three things: a selection for each stage, a way to order or relate those stages, and a time window. The selection logic defines what counts as a candidate event. The ordering logic defines whether the stages must occur in sequence or merely within the same window. The time window defines how far apart the events can be and still be considered related.

Grouping is the other key design choice. You may group by user, host, process tree, session, source IP, or some combination of these. The right grouping depends on the attack path. If you are looking for identity abuse, grouping by user or account object is often sensible. If you are looking for endpoint compromise followed by local privilege escalation, grouping by host and process lineage may be more appropriate. If you are looking for remote access followed by execution, you may need both host and source IP.

In Sigma terms, think in terms of stage definitions and correlation keys, then let the backend translation handle the mechanics. That said, not every SIEM backend implements correlation in the same way. Some support explicit sequence operators, some rely on joins or transaction functions, and some require you to emulate correlation with multiple analytics rules and a downstream enrichment step. The Sigma authoring pattern should therefore be portable, but the translated query still needs backend-specific validation.

Designing robust correlation logic

There are two broad styles of correlation logic: sequence-based and threshold-based. Sequence-based logic looks for a defined order of events, such as authentication followed by remote execution. Threshold-based logic looks for repeated behaviour within a window, such as multiple suspicious actions by the same user or host. Both are useful, but they answer different questions.

Sequence-based rules are better when the order of events is important to the attack narrative. Threshold-based rules are better when the attacker may repeat a behaviour several times before succeeding, or when the signal is a burst of activity rather than a strict chain. In many environments, the strongest detections combine both approaches. For example, you might require a suspicious logon, then alert only if it is followed by at least one high-risk action within 30 minutes.

Handling optional stages is where many correlation rules become brittle. If you require every stage, the rule may miss attacks in sparse telemetry. If you allow too many optional paths, the rule may become noisy and hard to reason about. A good compromise is to define a core chain and add optional context as scoring or enrichment. That way, the alert still fires on the core behaviour, but analysts can see whether additional suspicious actions were present.

Noise is inevitable, so design for it. Exclude known administrative tooling where appropriate, but do so carefully. Overly aggressive allow-lists can hide real abuse of legitimate tools. A better pattern is to narrow on combinations of context, such as unusual source host, first-seen account, or non-standard time of day, rather than suppressing by tool name alone.

Example pattern: credential access followed by lateral movement

One common multi-stage pattern is credential access followed by lateral movement. The first stage might be a high-risk authentication event, a suspicious LSASS access pattern, or evidence of token theft. The second stage might be remote service creation, PsExec-style execution, WMI activity, or another form of remote code execution. The detection value comes from the relationship between the stages, not from either stage alone.

To reduce false positives, anchor the correlation on the same user or host where possible, then add context such as source IP, logon type, and process ancestry. If the first stage occurs on one endpoint and the second stage occurs on another, the correlation key may need to include the account and the source machine rather than the destination host alone. That is particularly important in environments with shared admin accounts or jump servers.

Where you have endpoint telemetry, pair it with identity signals and, if available, network context. A suspicious authentication followed by a remote admin protocol from an unusual source is more actionable than either event in isolation. This is also where broader endpoint visibility helps, as described in why endpoint detection matters for organisations and memory and credential attack detection with Defender for Endpoint.

Example pattern: initial access followed by persistence and execution

Another useful pattern is initial access followed by persistence and execution. For example, a suspicious sign-in or mailbox rule change may be followed by a new scheduled task, a Run key modification, or a service installation. The key design challenge is that the first stage may come from identity logs, while the later stages come from endpoint logs. That makes field consistency and time alignment essential.

When correlating across endpoint and identity logs, use a time bound that reflects the likely attacker workflow, not just the default retention or alerting interval. A 15-minute window may be too tight for a human-operated intrusion, while a 24-hour window may be too loose for a high-fidelity alert. In many SME environments, a window between 30 minutes and 4 hours is a reasonable starting point, but it should be tuned to the behaviour you are trying to detect.

Use the time window to keep the rule operationally useful. If the window is too wide, you will create accidental relationships between unrelated events, especially in busy admin environments. If it is too narrow, you will miss slow-moving attacks. The right answer usually depends on the stage spacing you observe during testing, not on theory alone.

Tuning and validation in a SIEM pipeline

Once the Sigma rule is written, test the translated query in the target backend. Whether you are using Sentinel, Splunk, or another SIEM, the translation layer can change the semantics of joins, time windows, and aggregation. A rule that looks clean in Sigma may behave differently once converted to KQL, SPL, or another query language. Validate the backend query against real sample data, not just synthetic examples.

Measure precision, recall, and alert volume. Precision tells you how many alerts are worth analyst time. Recall tells you how many known test cases the rule catches. Alert volume tells you whether the rule is sustainable in production. If you cannot measure all three, you are tuning blind. For smaller teams, even a simple spreadsheet of test cases and outcomes is better than relying on intuition.

A useful validation method is to replay known benign and suspicious sequences into a test environment. You can also use controlled simulations to generate the stages you want to detect, provided you keep the activity safe and authorised. If you are already using detection quality metrics, the guidance in measuring detection quality and false positives for technical teams is a good companion to this work.

Common mistakes when writing correlation rules

The first common mistake is overly broad joins. If you correlate on a weak entity such as a common username, a generic hostname pattern, or a public IP range, you will create false relationships between unrelated events. Prefer stable identifiers and add secondary constraints where possible. Correlation should be specific enough to be meaningful, but not so specific that it only works in one lab.

The second mistake is relying on telemetry that most environments do not have. A correlation rule that depends on process command line, parent process, and network connection telemetry will be fragile if one of those fields is missing on half your estate. Before you invest in a complex rule, confirm that the required logs are enabled consistently and retained long enough to support investigation.

The third mistake is making the rule too clever. If the logic is so intricate that no one on the team can explain it, it will be hard to maintain and harder to trust. Good correlation rules are understandable. They should read like a detection hypothesis that an analyst can reason about, not like a puzzle only the original author can solve.

Operationalising correlation rules in detection engineering

Correlation rules should be treated as code. Store them in version control, review them like any other security control, and track changes with clear commit messages. If your team uses a pull request workflow, include a short explanation of the attack chain, the expected telemetry, the correlation key, and the intended backend behaviour. That makes future maintenance much easier.

It also helps to map each rule to ATT&CK techniques and to the telemetry sources it depends on. This gives you a practical view of coverage and blind spots. If a rule covers one technique but depends on three logs that are not universally deployed, the coverage may be more theoretical than real. For a broader framework view, see mapping detections and controls to MITRE ATT&CK.

Where possible, tie correlation rules into a release workflow with test cases. A simple set of sample events, expected matches, and expected non-matches is enough to catch regressions when the SIEM schema changes. This is especially important after log source upgrades, parser changes, or identity platform migrations.

How to maintain and improve correlation rules over time

Correlation rules are not one-time artefacts. They improve when you feed them with analyst feedback, incident findings, and false positive analysis. If a rule fires too often on benign admin activity, do not just suppress the alert. Ask whether the rule is trying to do too much. Sometimes the right fix is to split one broad correlation into two narrower detections with different thresholds or different entity keys.

Similarly, if a rule misses real incidents because one stage is too unreliable, consider whether that stage should be optional, replaced, or moved into enrichment. The best detections are usually the ones that reflect how your environment actually behaves, not how you wish it behaved. That means revisiting assumptions as tooling, identity patterns, and admin workflows change.

Over time, you should also track which rules are producing useful investigations and which are mostly generating noise. A small number of high-quality correlation rules is usually more valuable than a large library of brittle ones. If you are building a detection engineering programme, this kind of continuous improvement is part of the same discipline as continuous improvement loops in security operations.

For teams that want to go further, correlation rules can be paired with purple-team validation, ATT&CK coverage reviews, and controlled adversary simulation. The aim is not to chase every possible attack path. It is to increase the chance that a real multi-stage intrusion is detected early enough to investigate and contain.

If you want help reviewing your detection engineering approach, or need support aligning Sigma content, SIEM tuning, and operational response, speak to a consultant.

Frequently asked questions

What is the sigma correlation rule?

A Sigma correlation rule is a detection pattern that relates multiple events over time, rather than matching a single event. It is used to identify sequences of behaviour that together indicate a possible attack.

How do you write correlation rules in a SIEM?

Model the attack chain first, identify the log sources and fields needed for each stage, choose a stable correlation key such as user or host, define a time window, then validate the translated query in your SIEM with real sample data.