SIEM Correlation Cheatsheet: 15 Rule Examples for Rapid Threat Detection

Ever seen an attacker slip past all your logs — leaving only a faint fingerprint behind? You're not alone. SIEMs are powerful, but they're…

Very Lazy Tech 👾

~10 min read · May 10, 2026 (Updated: May 10, 2026) · Free: No

Ever seen an attacker slip past all your logs — leaving only a faint fingerprint behind? You're not alone. SIEMs are powerful, but they're only as good as their rules. Miss a key correlation, and that pentester (or worse, real threat actor) might waltz right through. Today, we're cracking open the vault: 15 practical SIEM correlation rule examples, the ones I wish someone had handed me back when I was slogging through endless alerts and false positives.

If you want to turn your SIEM into a true threat detection machine, not just a noisy log aggregator, read on. These rules aren't just theory — they're the backbone of real-world security monitoring, from RCE attempts to lateral movement to those sneaky privilege escalations. Let's sharpen your detection game.

What Exactly Is SIEM Correlation? (And Why Should You Care?)

Before we dive into the cheat sheet, let's get super clear on what SIEM correlation rules actually do.

At its core, a SIEM (Security Information and Event Management) platform ingests logs from across your environment: firewalls, endpoints, servers, cloud, you name it. But logs alone are just noise. Correlation rules connect the dots — spotting suspicious patterns across different sources, times, or events.

Here's the real kicker: the right correlation rules can turn that ocean of data into actual, actionable security alerts. Suddenly, you're catching bug bounty-style attack chains, not just random single events.

Think of SIEM correlation as the difference between a motion sensor and an actual burglar alarm system.

Anatomy of a Strong SIEM Rule

Before we roll into the cheat sheet, a quick anatomy lesson:

A good SIEM correlation rule typically includes:

Event source(s): Where the data comes from (e.g., Windows logs, firewall, IDS)
Event pattern: What you're looking for (e.g., failed logins, PowerShell activity)
Time window: How far apart events can be and still counted (seconds, minutes, hours)
Threshold: How many events trigger the rule (e.g., 5 failed logins in 2 mins)
Context: Extra logic to avoid false positives (e.g., location, user, asset type)

You might think, "Isn't that overkill?" But in practice, the context is what saves you from alert fatigue.

SIEM Correlation Cheatsheet: 15 Rule Examples

Let's break down 15 actionable SIEM correlation rule examples. You'll get the event logic, typical use case, and even a sample rule you can tweak for your own environment.

Multiple Failed Logins Followed by Success

Why it matters: Brute-force attacks and credential stuffing are the bread and butter of pentesters and real attackers alike. A sudden spike in failed logins, immediately followed by a success, is a major red flag.

Logic:

Detect 5+ failed logins from a single IP or user within 3 minutes.
Followed by a successful login from the same source within 2 minutes.

Sample SIEM pseudocode:

IF count(failed_logins FROM same_ip/user IN 3 mins) >= 5
AND successful_login FROM same_ip/user IN 2 mins
THEN alert "Possible brute-force followed by compromise"

Pro tip: Tag "VIP" accounts for higher sensitivity. Most attackers don't even realize they're making noise until it's too late.

2. Lateral Movement: Pass-the-Hash or Pass-the-Ticket

Why it matters: After initial access, attackers move sideways. Pass-the-hash and pass-the-ticket are classic Active Directory tricks — if you catch these, you're miles ahead.

Logic:

Kerberos or NTLM authentication events from a host where the user never logs in.
Followed by remote admin tool usage (e.g., PsExec, WMI).

Sample SIEM pseudocode:

IF authentication_type IN (NTLM, Kerberos)
AND login_source IS unusual_for_user
AND process_name IN (psexec, wmiexec)
THEN alert "Potential lateral movement detected"

Human aside: I've seen this trick in real pentests before — most blue teams spot it only after the attacker has already dumped all the hashes.

3. Privilege Escalation: User Added to Domain Admins

Why it matters: If a new user suddenly pops up in your Domain Admins group, something is very wrong — unless it's an approved admin change, but how often does that happen randomly at 3am?

Logic:

Monitor for group membership changes.
Trigger on any addition to high-privilege groups.

Sample SIEM pseudocode:

IF group_membership_change
AND target_group = "Domain Admins"
THEN alert "Potential privilege escalation"

Tweak: Exclude known admin maintenance windows, but don't get too lax.

4. RCE Exploit Attempt Detected in Web Server Logs

Why it matters: The holy grail for attackers — Remote Code Execution. SIEMs can catch these by spotting odd parameters in web logs: think cmd.exe, bash, or classic shell upload patterns.

Logic:

HTTP requests containing OS command keywords or suspicious payloads (e.g., system(), eval)
Unusual user agents or URLs matching known vulnerability patterns (CVE-based).

Sample SIEM pseudocode:

IF http_request_url CONTAINS (cmd.exe, /bin/bash, powershell)
OR http_request_body MATCHES regex "(system|eval|exec)\("
THEN alert "Potential RCE attempt"

In practice: You'll get some noise — don't ignore, but investigate. Sometimes real users paste odd things, but attackers are not subtle.

5. SQL Injection (SQLi) Pattern in Web Traffic

Why it matters: Still one of the most common bug bounty findings. Automated scanners light up your logs with ' OR 1=1 -- and related classics.

Logic:

Web traffic with suspicious SQL meta-characters.
Parameters containing '--, ;--, OR, UNION SELECT, etc.

Sample SIEM pseudocode:

IF http_request_url OR http_request_body MATCHES regex "('.+--)|(\\bOR\\b)|(UNION\\sSELECT)"
THEN alert "Possible SQL Injection attempt"

Bonus: Correlate with WAF or database error logs for higher fidelity.

6. XSS (Cross-Site Scripting) Patterns Detected

Why it matters: XSS is noisy, especially with automated scanning. Attackers inject >script> tags or JavaScript payloads — look for these in your SIEM.

Logic:

Web logs containing >script>, onerror=, javascript:, or hex-encoded payloads.

Sample SIEM pseudocode:

IF http_request_url OR http_request_body CONTAINS ("<script>", "onerror=", "javascript:")
THEN alert "Potential XSS attack"

Human aside: Don't get too trigger-happy — sometimes you'll see these in user-generated content. But actual attack chains? They're obvious.

7. Suspicious PowerShell Activity

Why it matters: PowerShell is beloved by Red Teams and real attackers alike for living-off-the-land (LOL) attacks. Especially when invoked with -EncodedCommand or from non-admin users.

Logic:

PowerShell process started with suspicious flags (`-EncodedCommand`, -Command, downloading scripts from the internet)
Run by non-admin user or outside normal hours.

Sample SIEM pseudocode:

IF process_name = "powershell.exe"
AND (command_line CONTAINS "-EncodedCommand" OR "IEX" OR "Invoke-Expression")
THEN alert "Suspicious PowerShell activity"

The cool part? Pair this with network logs — did that script phone home to an odd domain?

8. Beaconing to Known Malicious Domains

Why it matters: Many C2 (Command and Control) frameworks beacon out to check in with their operators. Repeated small DNS or HTTP requests to sketchy domains = big trouble.

Logic:

Multiple outbound connections to domains on threat intelligence blocklists.
Repeated over regular intervals (every 60 seconds, etc.).

Sample SIEM pseudocode:

IF outbound_connection
AND destination_domain IN threat_intel_blocklist
AND count(interval = 1 min) >= 3
THEN alert "Possible beaconing/malware C2"

Tip: Don't rely only on known bads — track for new domains too.

9. Suspicious File Creation in Sensitive Directories

Why it matters: Dropping binaries or scripts in places like C:\Windows\System32 or /etc` is a classic sign of persistence or privilege escalation.

Logic:

New file created in sensitive directory.
File is executable or script.

Sample SIEM pseudocode:

IF file_create_event
AND file_path STARTSWITH ("C:\\Windows\\System32", "/etc", "/usr/bin")
AND file_extension IN (".exe", ".ps1", ".sh")
THEN alert "Suspicious file creation"

Real world: I've seen attackers hide reverse shells as svchost.exe — naming alone is not enough.

10. New Service or Scheduled Task Created

Why it matters: Attackers use new services or scheduled tasks to maintain access post-exploitation. If a new one pops up unexpectedly, take a close look.

Logic:

Service or scheduled task creation event.
Creator is not a known admin tool or not during maintenance window.

Sample SIEM pseudocode:

IF service_create_event OR scheduled_task_create_event
AND creator_user NOT IN admin_users
THEN alert "Potential persistence mechanism"

Pro move: Monitor for weird names or paths — updatehelper.exe at 2am is rarely legit.

11. Data Exfiltration: Unusual Data Volume to External Host

Why it matters: Data leaving your network in large, sudden bursts could mean an attacker is wrapping up their heist.

Logic:

Data transfer to external IP exceeds normal baseline by X%
Destination is not a known business partner or cloud provider.

Sample SIEM pseudocode:

IF data_outbound_to_external > baseline * 2
AND destination_ip NOT IN known_allowed_list
THEN alert "Possible data exfiltration"

Human aside: False positives happen — streaming HD video can look like exfil. Context is king.

12. Multiple Alarms from Different Tools for Same Asset

Why it matters: When your EDR, firewall, and SIEM all flag the same endpoint at once, something's up. Automated correlation rules can stitch these together.

Logic:

Multiple high-severity alerts for the same host/user within a short window.
Different sources (e.g., antivirus, IDS, SIEM).

Sample SIEM pseudocode:

IF count(alerts FROM different_sources FOR same_asset IN 10 mins) >= 3
THEN alert "Incident correlation: multi-source detection"

Pro tip: This can cut your response time by hours — tie it all together.

13. Suspicious VPN or Remote Access Patterns

Why it matters: Attackers often use stolen credentials to log in via VPN from odd locations, or log in simultaneously from two countries miles apart.

Logic:

VPN login from unusual geo-location for the user.
Impossible travel: two logins from distant locations within impossible time.

Sample SIEM pseudocode:

IF vpn_login
AND geoip_location NOT IN user_historical_locations
OR time_between_logins_from_different_locations < travel_time
THEN alert "Suspicious remote access"

I've seen this catch real incidents: Don't underestimate geo-correlation!

14. Malware Dropped and Executed

Why it matters: Sometimes classic detection is still king. If a file flagged as malware is written and executed on a host, it's time to jump in.

Logic:

File write event with hash matching known malware (via AV or threat intel)
Process execution of same file within short timeframe.

Sample SIEM pseudocode:

IF file_write_event AND file_hash IN malware_hash_db
AND process_start_event FOR same_file WITHIN 5 mins
THEN alert "Malware dropped and executed"

Why bother? Sometimes AV misses the execution, but the SIEM correlation nails it.

15. Attack Chain: Phishing Email ➔ Malicious Link Click ➔ Process Spawned

Why it matters: Single events don't always tell the story. Linking a phishing email to a user click and a suspicious process launch? That's the attack chain SIEMs were born to catch.

Logic:

User receives email with suspicious URL.
Click event recorded on same URL.
Short time later, new process started by user (e.g., powershell.exe).

Sample SIEM pseudocode:

IF email_received WITH suspicious_url
AND user_click_event ON suspicious_url WITHIN 10 mins
AND process_start_event (powershell.exe, cmd.exe) BY user WITHIN 5 mins
THEN alert "Phishing chain detected"

This is next-level detection: It's how you stop the attack before it results in ransomware.

Quick-Start: Building Your Own SIEM Correlation Rules

You don't need to be a SIEM wizard to get started. Here's my go-to checklist for building effective correlation rules:

Identify the critical threat scenarios. Think pentesting playbooks, real incident reports, MITRE ATT&CK.
Gather log sources. Can your SIEM see what it needs? No logs, no detection.
Define the pattern. What's the suspicious behavior? Be as specific as possible to reduce noise.
Test with real data. Simulate attacks or review past incidents. Don't wait for theory — see if your rule actually fires.
Tune for context. Exclude maintenance windows, known admins, or test users. But don't over-tune to the point of missing real attacks.
Document everything. If you can't explain what your rule does, neither can your colleagues.

Here's a basic template you can use for almost any rule:

IF [event pattern]
AND [context logic]
THEN alert "[rule description]"

Advanced Moves: Chaining and Tuning SIEM Correlations

Once you've got the basics down, step it up:

Chain rules together. Combine multiple events — failed logins plus PowerShell activity, for example.
Use threat intelligence. Ingest fresh blocklists, hash databases, and phishing URLs automatically.
Automate responses. Link your SIEM to SOAR to auto-quarantine hosts or disable accounts.
Regularly review rules. Attackers evolve, and so should your rules.

In practice, what really happens is… you'll find rules that are too sensitive (hello, alert storms). Don't sweat it — tune iteratively. Threats evolve, and so does your detection.

Real-World Example: Writing and Testing a Rule (Step by Step)

Let's run through a real example — detecting a potential privilege escalation via PowerShell.

Define your pattern: Non-admin user runs PowerShell with Add-LocalGroupMember (classic for local admin escalation).
Find the relevant logs: Windows event logs for process creation (`Event ID 4688`) and group membership changes (`Event ID 4732`).
Build the rule:

IF process_name = "powershell.exe"
AND command_line CONTAINS "Add-LocalGroupMember"
AND user NOT IN admin_group
AND group_membership_change TO "Administrators" WITHIN 2 mins
THEN alert "PowerShell privilege escalation attempt

Test it: Spin up a test VM, try the escalation, check if your SIEM fires.

Tune as needed: Exclude known IT scripts, reduce noise, and monitor for real hits.

This isn't rocket science — but it's exactly what catches real attacks.

Making SIEM Correlation Rules Actually Useful

You might think, "Aren't SIEMs just noisy and full of false positives?" That's true — unless you tune your rules and connect them to real response playbooks.

Make these rules actionable:

Include clear descriptions and recommended actions.
Prioritize alerts by impact.
Review and update regularly.

The difference between a SIEM that drowns you in noise and one that surfaces critical threats? Smart correlation, context, and continuous improvement.

Let's Be Real: Common Pitfalls (and How to Dodge Them)

Overly broad rules: You'll drown in noise. Add context and thresholds.
Under-logging: No logs = no detection. Audit your sources.
Ignoring tuning: Rules aren't set-and-forget. Attackers change tactics.
Blind spots: Not monitoring cloud, endpoints, or identity? You'll miss critical attacks.

Keep it human: talk to your SOC analysts, pentesters, and engineers. They know where the gaps are.

Wrapping Up: Your SIEM Superpower Awaits

The rules above aren't just random theory — they're in the detection playbooks of top blue teams, bug bounty hunters, and seasoned pentesters. If you start implementing just five of these, you'll be ahead of most organizations.

Remember: great SIEM correlation is part art, part science. Stay curious, keep tuning, and never stop hunting for those attacker chains. Your alerts will get sharper, your response faster, and your defenders less grumpy (well, mostly).

If you've got a favorite SIEM detection trick, or a rule that saved your bacon, don't be shy — share it around. Security's a team sport. 🚀