Articles, updated 13 min read
SIEM Correlation Rules: 10 Examples and How to Write Them
By UTMStack Team
One failed login means nothing. Ten failed logins for the same account from the same address in five minutes, followed by a success, is worth waking someone up for. Correlation rules are how a SIEM (security information and event management system) tells those two situations apart. Loose rules bury analysts in alerts; strict rules miss the attack.
This guide shows ten real rules in plain words, one rule file line by line, and how to write, test and tune your own. The examples come from UTMStack’s open source rule set on GitHub. We build UTMStack, so weigh our view accordingly; the method works in any SIEM.
The short answer: a SIEM correlation rule turns several related log events into one alert. It names the event that starts the check (for example Windows event 4625, a failed logon), what earlier events must have in common with it (the same account and source address), how many there must be (10) and within what time (5 minutes). Good rules map to a known attacker technique in MITRE ATT&CK, read fields your logs really contain, exclude known harmless activity, and are tested with sample logs before they go live.
What a correlation rule is, and what it is not
Some rules need only one event. If the Windows security log is cleared (event 1102), that single event is enough for an alert. Correlation starts when one event is not enough and the rule has to look at others before deciding.
| Pattern | The question it asks | Example |
|---|---|---|
| Single event | Did something happen that should never happen? | Security log cleared |
| Threshold | Did the same thing happen too often, too fast? | 10 failed logons for one account in 5 minutes |
| Sequence | Did one thing happen, then another? | Many failed logons, then a successful one |
| Conflicting values | Did the same user appear in two places that cannot both be true? | One account signs in from two countries within 30 minutes |
| Across sources | Do events from different systems tell one story? | Remote logins on several servers by the same account |
A “SIEM use case” is the wider idea: the threat you want to catch, the logs it needs and the response. One use case, such as “detect password attacks”, is usually built from several rules.
Correlation only works if events speak the same language. A FortiGate firewall calls the source address srcip, a Windows logon event calls it IpAddress and Microsoft 365 calls it ClientIP. Parsers rename these into common fields, such as UTMStack’s origin.ip, origin.user and target.user, so one rule can compare them. When a parser does not fill the field a rule reads, the rule never fires. That is the most common reason a correct-looking rule stays silent.
How one correlation rule decides
The Windows brute force rule, checked against every event as it arrives
- Event arrivesThe parser fills common fields: event code, account, host, source address
- ConditionIs it a failed logon (event 4625)? If not, stop here
- Look backCount earlier failed logons with the same account, host and address
- Alert10 in 5 minRaised with its ATT&CK technique, T1110 Brute Force
- Group or suppressRepeat hits join the first alert instead of adding new ones
10 SIEM correlation rule examples
These ten rules come from UTMStack’s rule files (the definitions/rules folder of the v12 branch on GitHub). The trigger is the event that starts the check; the look-back is what the rule then counts among stored events. Each maps to a technique in MITRE ATT&CK, MITRE’s public catalog of attacker behavior.
| # | Rule | What it catches | Trigger event | Look-back | ATT&CK technique |
|---|---|---|---|---|---|
| 1 | Windows: possible brute force attack | Password guessing against one account | Failed logon (4625) | 10 failed logons with the same account, host and address within 5 minutes | T1110 Brute Force |
| 2 | Windows: multiple logon failures followed by success | A password guess that worked | Successful logon (4624) | 10 failed logons with the same account, host and address within 5 minutes | T1110 Brute Force |
| 3 | Linux: brute force followed by success | A password guess that worked, for example over SSH | Successful Linux login (audit log) | 10 failed logins for the same user and address within 15 minutes | T1110 Brute Force |
| 4 | MFA fatigue push spam | Multi-factor authentication (MFA) prompts sent until the user gives in | Microsoft 365 sign-in involving MFA | 5 sign-ins with an MFA error for the same user within 15 minutes | T1621 Multi-Factor Authentication Request Generation |
| 5 | AWS console login impossible travel | Stolen cloud credentials | Successful AWS console login (CloudTrail) | 1 console login by the same identity from a different country within 30 minutes | T1078.004 Valid Accounts: Cloud Accounts |
| 6 | SharePoint mass file download | Bulk theft of documents | A SharePoint or OneDrive file download | 100 downloads by the same user within 30 minutes | T1213 Data from Information Repositories |
| 7 | Internal SMB/RDP lateral movement | An attacker hopping between internal machines | A connection from a private address to port 445 (file sharing) or 3389 (remote desktop) | 10 connections from the same address to the same port within 10 minutes | T1021 Remote Services |
| 8 | Possible ransomware: multiple file writes | Mass encryption of user files | A write (4663) to a user’s document or media file, system processes excluded | 50 file access events (4663) for the same user within 5 minutes | T1486 Data Encrypted for Impact |
| 9 | C2 beaconing behavior | Malware checking in with its command and control (C2) server | A small outbound flow (under 10,000 bytes, under 50 packets) to port 80, 443, 8080 or 8443 | 30 flows between the same source and destination within 1 hour | T1071 Application Layer Protocol |
| 10 | Windows audit log was cleared | An attacker covering their tracks | Security log cleared (1102) | None: one event is enough | T1070.001 Clear Windows Event Logs |
The 10 examples by pattern
Most correlation rules count; a few look for an order or a conflict
- 1. Windows brute force: 10 in 5 min
- 4. MFA fatigue: 5 in 15 min
- 6. SharePoint downloads: 100 in 30 min
- 7. SMB or RDP hopping: 10 in 10 min
- 8. Ransomware file writes: 50 in 5 min
- 9. C2 beaconing: 30 in 1 hour
- 2. Windows: 10 failures in 5 min, then success
- 3. Linux: 10 failures in 15 min, then success
- 5. AWS console login from another country within 30 min
- 10. Security log cleared
What these examples teach:
- Thresholds are judgment calls. Lower numbers catch slower attacks and raise more alerts. Check any number, including these, against a normal week of your own logs.
- The window must fit the behavior. The beaconing rule looks back a full hour, because malware that calls home every two minutes looks harmless in any five-minute slice.
- Exclusions belong inside the rule. The ransomware rule ignores Windows Update, installers and temporary files; the lateral movement rule only counts private addresses. Most false positives are prevented here.
- Rules depend on audit settings. Event 4663 is only written when file system auditing is on and the folder has an audit entry (a SACL, system access control list). A rule cannot see an event Windows never wrote.
Across the whole rule set, 199 of the 664 rule files on the v12 branch look back at earlier events. The other 465 fire on a single event.
How many rules actually correlate
UTMStack rule files on the v12 branch, October 2026
A real rule file, line by line
This is the first rule from the table, as it appears in definitions/rules/windows/windows_bruteforce_attack.yaml. The impact scores, description and references are left out to keep it short.
dataTypes:
- wineventlog
name: "Windows: Possible Brute Force Attack"
category: "Credential Access"
technique: "T1110 - Brute Force"
adversary: origin
where: equals("log.eventCode", 4625)
afterEvents:
- with:
- field: log.eventCode
operator: filter_term
value: "{{.log.eventCode}}"
- field: target.user
operator: filter_term
value: "{{.target.user}}"
- field: origin.host
operator: filter_term
value: "{{.origin.host}}"
- field: origin.ip
operator: filter_term
value: "{{.origin.ip}}"
within: 5m
count: 10
deduplicateBy:
- adversary.host
- target.user
- adversary.ip- dataTypes: which logs the rule reads, here Windows event logs.
- name, category, technique: what the analyst sees on the alert, including the ATT&CK tactic and technique.
- adversary: origin: the source side of the event is the attacker, so the alert shows who is attacking whom.
- where: the condition every new event is checked against, written in CEL (Common Expression Language) with helpers such as
equals,oneOf,regexMatch,inCIDRfor address ranges, and working-hours checks. - afterEvents: the look-back. When a failed logon arrives, the engine counts stored events with the same event code, account, host and address. Placeholders such as
{{.target.user}}take their values from the new event. Ten matches within five minutes raise the alert. - deduplicateBy: suppresses a new alert if the rule already raised one for the same host, account and address in the past seven days. Most rules use groupBy instead, which files repeat hits under the first alert as “echoes”.
Each rule also scores impact from 1 to 3 for confidentiality, integrity and availability. Severity comes from the highest of the three.
How to write a SIEM correlation rule, step by step
- Start from a behavior, not a log. Pick an ATT&CK technique or a past incident and write the rule as one sentence: “Alert when one user downloads more than 100 files from SharePoint within 30 minutes.”
- Confirm the evidence exists. Find a real example of the event in your log search, check the audit policy that writes it, and note the field names after parsing.
- Write a narrow condition. Event type, result, and checks that the fields you will compare exist.
- Add a look-back only if one event is not enough. Decide what must match, the window and the count, after seeing how often the pattern happens in a normal week.
- Exclude what you already know: vulnerability scanners, backup jobs, service accounts. Use address ranges and lists, not one-off values.
- Decide how repeats behave: grouped under one alert to keep the trail, or suppressed for high-volume activity.
- Document it: technique, impact, and next steps for whoever gets the alert at 2 a.m.
- Test it with one log that should match and one that should not.
- Watch it for one to two weeks and tune. Track how many alerts it raised and how many were real.
The usual reasons a rule fails are dull: a field the parser never fills, an audit policy that is off on some machines, or grouping by a field that is often empty, which lumps unrelated users together. Retest after any parser, agent or log source change.
Writing and testing rules in UTMStack
UTMStack’s Alerting Rules page lists built-in and custom rules, filtered by category, technique or data type. Any rule can be switched off or exported as YAML; built-in rules are read-only, so export one as a starting point.
- Visual editor: name, category, technique, impact and data types, then a condition built from operators such as equals, contains, is one of, in CIDR or time between. Correlation steps take a window, a count and the fields that must match.
- YAML editing: the Code tab shows the same rule as YAML, and edits sync both ways. Rule files can also be imported.
- Test mode: the Test button runs your unsaved draft against a raw log you paste in (up to 1 MB). You see the parsed fields and any alerts the draft would raise before you save.
- Playground: the same tester works on the live pipeline and on parsers. Rules that look back need earlier events to exist already, so feed real or replayed events first.
Two safety nets catch rules that misbehave later. Tagging rules mark known harmless alerts as false positives and close them automatically. The rule flood guard switches off a rule that raises 50 separate alerts from one data source within 24 hours (the default) and notifies you. In the Enterprise edition, the SOC-AI assistant reviews new alerts and can create a rule from a plain-language request.
Sigma: the vendor-neutral rule format
Sigma is an open format for describing detections in log data, so a rule written once can run in many SIEMs. The SigmaHQ repository holds more than 3,000 community rules under the Detection Rule License 1.1, and the specification itself is public domain. Version 2.0 of the specification was released in August 2024 and version 2.1.0 in September 2025.
A Sigma rule has three parts: logsource (which logs), detection (named selections and a condition that combines them) and metadata such as title, level, ATT&CK tags and a falsepositives note for humans. Sigma correlation rules add types such as event_count, value_count, temporal and temporal_ordered, each with a timespan and group-by; the documentation’s example is 10 failed logons for one user within 5 minutes. Tools such as sigma-cli and the pySigma library convert Sigma rules into a SIEM’s query language.
UTMStack does not import Sigma files directly. Its rules run on each event as it arrives rather than as scheduled searches, and use UTMStack’s field names. Translating by hand is straightforward, and several UTMStack rules link to the Sigma rule they were modeled on.
| Sigma | UTMStack rule |
|---|---|
logsource | dataTypes |
detection selections and condition | where |
Correlation timespan, group-by and count condition | afterEvents with within, with and count |
tags: attack.t1110 | technique: "T1110 - Brute Force" |
level | Impact scores for confidentiality, integrity and availability |
falsepositives (notes only) | Exclusions in where, plus tagging rules |
For the full program around these rules, see our guide to detection engineering. For tuning after go-live, see reducing SIEM false positives. For Windows domain examples with the audit settings each needs, see Active Directory SIEM use cases.
How UTMStack helps
UTMStack ships more than 600 detection rules mapped to MITRE ATT&CK and checks each log against them as it arrives, before storage. The rules are open source under the AGPL-3.0, so you can read what each one does and adapt it. Response flows can act on an alert by blocking an address, disabling an account or isolating a host through the agent. See threat detection in UTMStack, try the live demo with no sign-up, or install the free Community edition.
Frequently asked questions
What is a correlation rule in a SIEM? A rule that raises one alert when several related events match a pattern, such as 10 failed logons for the same account within 5 minutes. It defines the trigger event, the fields earlier events must share, the count and the time window.
What are examples of SIEM correlation rules? Brute force, failed logons followed by a success, MFA fatigue, impossible travel, mass downloads, lateral movement, ransomware-style file writes and malware beaconing. The table above gives real thresholds for each.
What is the difference between a SIEM use case and a correlation rule? A use case is the security problem you want to detect and how you respond. A rule is the logic that detects it. One use case often needs several rules across different log sources.
Can I use Sigma rules in UTMStack? Not by importing the file directly. Translate the rule by hand using the mapping above, or use a Sigma rule as the reference for a new UTMStack rule.
How do I test a correlation rule? Run it against sample logs that should and should not match, then reproduce the attack in a lab. Atomic Red Team, an open source library of small attack tests mapped to ATT&CK, is a common way to do that.
Sources
- UTMStack detection rules, v12 branch and the Windows brute force rule file
- MITRE ATT&CK: T1110 Brute Force, T1621 Multi-Factor Authentication Request Generation, T1021 Remote Services, T1071 Application Layer Protocol, T1070.001 Clear Windows Event Logs
- SigmaHQ rule repository, Sigma rule structure, Sigma correlation rules and Sigma specification releases
- Microsoft: event 4663, an attempt was made to access an object
- Atomic Red Team
