Advanced correlation rules¶

This page describes multi stage window detections from the correlation library: six rules under /Correlations/Advanced/, plus two related Sysmon window rules under /Correlations/Microsoft/Sysmon/ that analysts often validate in the same lab exercises.

Each rule looks for a sequence of related events within a short time window (typically 15 to 60 minutes), not a single suspicious log line. Window rules answer a different question than match rules: did several suspicious steps happen in order on the same host or user?

These rules are marked experimental or test. Run validation only in a controlled test environment (isolated lab host or dedicated test tenant). Do not run attack simulations on production systems without approval.

Before you start¶

Confirm the rules are deployed in your Library (/Correlations/Advanced/ and, where noted, /Correlations/Microsoft/Sysmon/).
Ensure the Correlator is consuming the relevant log sources (Windows Security and Sysmon for most rules; identity provider sign in logs for the travel rule).
Open Discover to search incoming events, Detections to confirm a rule is deployed and review metrics, and Alerts to work with tickets created from detections.
Allow a few minutes after the last test step for ingestion and correlation. Window rules need all stages inside the configured timeframe.

When a rule works as expected, the Correlator produces a complex event (event.dataset: complex) with the rule name, a risk score, and related.events linking the contributing activity. If the rule sends a signal to Alert Management (the default), you will also see a ticket in Alerts for analysts to triage.

Impossible Travel, MFA, and High Risk¶

What it detects¶

Scenario: An attacker signs in with a stolen password from an unusual location, the identity platform flags the session as risky, and the user (or attacker) interacts with MFA.

This rule produces a critical complex event when the same user account shows several identity risk signals within about 20 minutes:

Successful sign in from two different countries (impossible travel).
Registration or first use of a new device on sign in.
An MFA challenge that was denied or later confirmed.
An elevated identity risk score reported by your identity platform.

It is intended for cloud identity providers (Microsoft Entra ID, Okta, VPN portals with geo enrichment), not for Windows server logons alone.

How to test¶

Use a test user in your identity provider sandbox or lab tenant.
Sign in successfully from a location in country A (or simulate with an approved VPN exit in that country).
Within 20 minutes, sign in again from country B using a browser or device that the IdP treats as new (clear device cookies, use a fresh browser profile, or register a new test device).
Complete or fail an MFA prompt during the second sign in.
Ensure the IdP emits a sign in record that includes an elevated risk score for that user (Entra ID Identity Protection, Okta ThreatInsight, or equivalent).

What to watch¶

In Discover, filter on the test user and event.category: authentication. You should see successful sign ins from two countries, a new device signal, MFA outcome events, and a risk score field on at least one event.

After the final stage, expect one complex event for this rule in Discover, and a ticket in Alerts naming the user and showing MFA outcome with related authentication events.

Signs the rule behaves correctly¶

The rule triggers only after all four stages are present, not after a single unusual sign in.
The complex event is tied to one user across the whole chain.
If you omit the new device step or the second country, the rule should not fire.

Ransomware Kill Chain¶

What it detects¶

Scenario: Ransomware operators prepare the host for encryption: flood the disk with new files, destroy backups, stop security or backup services, rename data to ransom extensions, then talk to command and control.

This rule connects early ransomware preparation on a Windows host within about 30 minutes:

Many new files created in a short period (mass staging).
Shadow copy deletion (for example via vssadmin or wmic).
Security or backup services stopped or set to disabled.
Mass file rename to common ransomware extensions (.encrypted, .locked, .crypto, or extensions from the ransomware lookup).
Outbound command and control communication matched by threat intelligence.

It is broader and later in the attack than Ransomware Activity Detected (documented below), which focuses on three distinct precursors on one host.

How to test¶

On a lab Windows server or workstation with Sysmon and Security auditing enabled, sign in as a test administrator:

Create at least ten new files in a test folder (a short PowerShell loop or batch script is enough).
Open an elevated command prompt and run shadow copy deletion: vssadmin delete shadows /all /quiet (lab only).
Change the Windows Defender service start type to disabled, or stop a backup related service so a System log entry is generated.
Rename at least five of the test files to extensions such as .encrypted or .locked.
If your environment feeds threat intelligence into network or threat category events, generate or replay a test event that matches a known command and control indicator from the same host (optional in minimal tests; the first four stages may be enough to validate staging logic).

Perform all steps within 30 minutes on the same host.

What to watch¶

In Discover, search by host.hostname and verify file creation (Sysmon event 11 or file audit), process creation for vssadmin, service change messages mentioning Defender or backup, and rename events on .encrypted files.

Expect a complex event for Ransomware Kill Chain in Discover and a critical ticket in Alerts for that host with process and file context.

Signs the rule behaves correctly¶

Creating only one or two files should not trigger the rule.
Steps scattered across different hosts should not combine into one complex event.
The complex event should reference the same host.hostname throughout the chain.

Ransomware Activity Detected¶

Library path: /Correlations/Microsoft/Sysmon/Ransomware Activity Detected.yaml

What it detects¶

Scenario: A host is being prepared for or is already undergoing ransomware impact: backups are wiped, files gain ransom style extensions, and scripting tools run to enumerate or encrypt data.

This critical Sysmon and Security window rule ties three stages on the same host within about 15 minutes:

Inhibit recovery: Sysmon process create (event 1) for vssadmin.exe or wmic.exe with delete shadows or shadowcopy delete in the command line.
Encryption pattern: At least three file events (Security 4663/4656/4659/4660 or Sysmon 11) where we.object.name contains a ransom extension such as .encrypted, .locked, or .crypto (or an extension from the ransomwareextensions lookup).
Script activity: Sysmon process create for PowerShell (with -enc, -encodedcommand, or Get-ChildItem in the command line) or cmd.exe with /c.

Stage 2 uses we.object.name from the Windows Security log (ObjectName). Sysmon 11 stores paths in we.target.file_name, which alone does not satisfy this rule. Enable File System auditing and generate Security 4663 events on lab files, or rely on Security events from rename and access.

How to test¶

On a lab Windows server or workstation with Sysmon and File System auditing enabled, sign in as a test administrator through RDP. Complete all steps on the same host within 15 minutes.

Stage 1 (shadow copies): In an elevated command prompt or PowerShell, run vssadmin.exe delete shadows /all /quiet (lab only; this deletes all Volume Shadow Copies). If needed, use wmic shadowcopy delete instead. Confirm Sysmon logs process create for vssadmin.exe or wmic.exe, not only a parent cmd.exe.
Stage 2 (ransom extensions): Enable File System audit success events if they are not already on. Create a test folder (for example C:\Temp\lab-ransomware). Create plain files, rename at least three of them to extensions such as .encrypted, .locked, and .crypto, then read each file so Security logs 4663 (or 4656) with the full path in we.object.name.
Stage 3 (scripting): Run PowerShell with an encoded command, for example:
powershell.exe -NoProfile -enc <Base64 of a harmless command such as Write-Output "lab-test">

What to watch¶

In Discover (last 30 minutes, same host.hostname):

Stage 1: event.code:1 AND process.executable:*vssadmin* AND we.command_line:*delete*shadow*
Stage 2: event.code:(4663 OR 4656) AND we.object.name:*lab-ransomware*
Stage 3: event.code:1 AND process.executable:*powershell* AND we.command_line:*-enc*

Ignore unrelated Security noise (for example DHCP service files under c:\windows\system32\dhcp\). Filter on your test folder path.

Expect a complex event for Ransomware Activity Detected and a critical ticket in Alerts.

Signs the rule behaves correctly¶

Shadow copy deletion alone should not fire the rule.
Fewer than three file events with ransom extensions should not fire the rule.
Stages on different hostnames should not merge.
This rule is also a feeder for MITRE Attack Chain Incident (Execution stage).

Trojan Activity via File Download and Execution¶

Library path: /Correlations/Microsoft/Sysmon/Trojan Activity via File Download and Execution.yaml

What it detects¶

Scenario: A user or script downloads a payload, runs it through a command interpreter, and loads a script host or LOLBin that trojans often abuse (typical of phishing and drive by follow up).

This critical Sysmon window rule links three stages on the same host and same user context (host.id and we.user.data) within about 20 minutes:

Download: Sysmon process create (event 1) where process.executable contains curl, wget, or bitsadmin.
Execution: Sysmon process create (event 1) where we.command_line contains cmd.exe, encoded PowerShell, or regsvr32.exe /s.
Script or LOLBin load: Sysmon image load (event 7) where process.executable contains mshta.exe, rundll32.exe, or wscript.exe.

The pattern mirrors common post compromise chains (for example Qakbot style download, cmd staging, wscript or mshta execution).

How to test¶

On a lab Windows workstation or server with Sysmon (events 1 and 7) enabled, sign in as a test user through RDP. Stay on the same host and same user session within 20 minutes.

Stage 1 (download): Download a harmless file with a built in tool, for example:
curl.exe -o C:\Temp\lab-test.ico https://www.microsoft.com/favicon.ico
Stage 2 (command line): Run a command through cmd, for example:
cmd.exe /c echo lab-test
Stage 3 (script host): Create a minimal test script and run it with wscript, for example a one line .vbs in C:\Temp executed with wscript.exe //B //Nologo C:\Temp\lab-test.vbs.

Run all three steps under the same interactive user so host.id and we.user.data match across stages.

What to watch¶

In Discover (last 30 minutes, same host and user context):

event.code:1 AND process.executable:*curl*
event.code:1 AND we.command_line:*cmd.exe*
event.code:7 AND process.executable:*wscript*
rule.name:"Trojan Activity via File Download and Execution"

Expect a complex event for Trojan Activity via File Download and Execution in Discover and a Critical ticket in Alerts.

Signs the rule behaves correctly¶

A download without cmd or wscript activity should not fire the rule.
wscript without a prior download on the same host and user should not complete the chain.
This rule is a feeder for MITRE Attack Chain Incident (Execution stage).

Pass the Hash Lateral Movement¶

What it detects¶

Scenario: An attacker reuses a captured NTLM hash to move laterally: failed guesses, then success, then remote execution and persistence style tooling on the target.

This rule describes a lateral movement pattern on one Windows host within about 30 minutes:

Several failed logons (at least three).
A successful logon using NTLM.
Remote execution via PsExec or WMI.
A new Windows service installed.
PowerShell execution on the host.

How to test¶

On a lab Windows server (member server or domain controller in test):

Generate three or more failed logons for the same test account (wrong password from the same or another machine).
Follow with a successful NTLM logon for that account (network logon to the server often uses NTLM).
From another lab machine, run PsExec against the target server to execute a harmless command, or use WMI process call create with wmic.
Confirm a service installed event appears in the System log (PsExec creates PSEXESVC).
Run a visible PowerShell command on the target (for example Get-Process) under the same session.

Keep all activity on the same target hostname within 30 minutes. Enable Audit Logon on the target so 4624/4625 authentication events appear in Discover.

What to watch¶

In Discover, filter host.hostname and look for authentication failures, NTLM success, event code 7045 (service installed), Sysmon or 4688 process events for powershell.exe.

Expect a complex event for Pass the Hash Lateral Movement in Discover and a ticket in Alerts naming the host, user, and PowerShell command line.

Signs the rule behaves correctly¶

Two failed logons alone should not be enough.
Activity split across unrelated hostnames should not merge.
PsExec or WMI plus service install and PowerShell should appear in related.events.

Privilege Escalation Chain¶

What it detects¶

Scenario: An attacker gains admin rights, signs in with the elevated account, weakens endpoint protection, and runs offensive tooling.

On one Windows host within about 30 minutes, this rule links:

A user added to a privileged group (Administrators, Domain Admins, or Enterprise Admins).
A successful logon by that elevated account.
Antivirus or endpoint protection impaired (disabled or stopped).
Execution of a suspicious process (powershell.exe, cmd.exe, rundll32.exe, or regsvr32.exe).

How to test¶

On a lab domain joined Windows server:

Sign in as a domain admin and add a test user to the local Administrators group (or Domain Admins in a test OU). This generates a security event for group membership change.
Sign out and log on as the elevated test user on the same server.
In an elevated session, set Windows Defender to disabled or stop the WinDefend service (lab only).
Run PowerShell with a simple, harmless script (for example list services).

Complete all steps on the same host within 30 minutes.

What to watch¶

In Discover, search for group change events, successful logon for the test user, service configuration changes mentioning Defender, and process creation for PowerShell.

Expect a complex event for Privilege Escalation Chain in Discover and a ticket in Alerts with the host, elevated user, and PowerShell details.

Signs the rule behaves correctly¶

Adding a user to a group without subsequent logon and process activity should not fire the rule.
Disabling Defender on a host with no prior privilege change should not fire this specific chain.
The complex event should name the same host for all stages.

Living off the Land Chain¶

What it detects¶

Scenario: Malware hides inside trusted applications: Office opens PowerShell, PowerShell uses certutil to fetch a payload, then a signed LOLBin loads a DLL.

This rule finds a fileless style attack chain on Windows when Office or Teams launches tools that attackers commonly abuse, within about 30 minutes:

An Office or Teams application starts PowerShell.
PowerShell starts certutil.
certutil downloads or decodes a file (urlcache, decode, or split in the command line).
rundll32 or regsvr32 runs a DLL.

How to test¶

On a lab Windows workstation with Microsoft Office and Sysmon:

Open Word (or Excel, Outlook, or Teams).
In the test lab only, start PowerShell as a child of Word (for example a controlled VBA macro, or a test harness that launches WINWORD.EXE and then spawns PowerShell with Word as parent process). The goal is a process tree: Office → PowerShell.
From that PowerShell session, run certutil to download a harmless test file, for example:
certutil.exe -urlcache -split -f https://your-lab-server/test.bin C:\Temp\test.bin
Run rundll32 against a harmless test DLL in C:\Temp, for example:
rundll32.exe C:\Temp\test.dll,EntryPoint
(use a signed or custom test DLL that only returns success).

Stay on the same host and same user within 30 minutes.

What to watch¶

In Discover, filter on process.parent.name containing winword, excel, or outlook, then follow child processes powershell.exe, certutil.exe, and rundll32.exe.

Expect a complex event for Living off the Land Chain in Discover and a ticket in Alerts with the final rundll32 or regsvr32 command line.

Signs the rule behaves correctly¶

PowerShell started from Explorer alone should not satisfy stage 1.
certutil run without an Office parent should not complete the chain.
Stages on different hosts or users should not combine.

MITRE Attack Chain Incident¶

What it detects¶

Scenario: Separate detections already fired across the kill chain for one user; this meta rule raises one consolidated incident when initial access, execution, credential access, and lateral movement are all present.

This is a meta detection. It does not use raw Windows logs directly. Instead, it waits until four separate existing detections have already fired for the same user within about 60 minutes, covering these attack stages:

Stage	Example feeder detections
Initial Access	Impossible Travel, Impossible Travel by Country, brute force with success
Execution	Critical Command Usage, Trojan Activity via File Download and Execution
Credential Access	Suspicious LSASS Memory Access
Lateral Movement	PsExec Service Installed, Using Remote Control Tool

When all four stages are present, it produces one critical complex event and a matching ticket in Alerts that stitches the story together.

How to test¶

Plan a lab exercise for one test user account across up to 60 minutes:

Initial Access: Trigger one of the feeder rules (for example simulate impossible travel, or run the brute force with successful login test scenario documented for that rule).
Execution: On a lab Windows host, trigger Critical Command Usage or Trojan Activity via File Download and Execution using the manual lab steps documented for that rule.
Credential Access: In the lab, run the approved test for Suspicious LSASS Memory Access (use only sanctioned red team tools or test signatures).
Lateral Movement: Install or simulate PsExec service activity, or trigger Using Remote Control Tool.

Each step should produce a complex event from the feeder rule with user.name set to your test account. Each feeder rule may also create its own ticket in Alerts.

What to watch¶

In Discover, search event.dataset: complex and user.name:<test user>. Confirm four distinct feeder rule.name values within one hour.

After the fourth feeder complex event, expect one consolidated complex event for MITRE Attack Chain Incident in Discover and a critical ticket in Alerts for that user.

Signs the rule behaves correctly¶

Three feeder stages without the fourth should not produce the meta complex event.
Feeder complex events for different users should not merge.
The meta complex event should list related.events pointing at the four contributing complex events.
If your deployment renames correlation files, feeder rule.id paths must still match the paths configured in the meta rule (coordinate with your detection engineer).

Troubleshooting¶

Symptom	Things to check
No complex event or ticket	Ingestion delay, wrong tenant, Correlator not subscribed to the log source, or stages outside the time window
Feeder rules fire but meta rule does not	User name must match exactly across complex events; MITRE chain allows up to 60 minutes
Partial stages visible in Discover only	Predicate may not match your log format; compare field names with a working event from the same source
Ransomware stage 2 missing	File System audit and SACL on lab folder; look for 4663 with `we.object.name`, not only Sysmon 11
Ransomware stage 1 missing	Need Sysmon 1 with `process.executable` containing `vssadmin`, not only `cmd.exe` wrapping vssadmin
Trojan stages split across users	Stages must share the same `host.id` and `we.user.data`; run all steps in one interactive RDP session
Rule too noisy in production	Tune thresholds with your detection engineer; these rules are experimental

For performance tuning after deployment, see Monitoring detection performance.

For authoring and offline YAML tests, see Writing a window correlation rule.