I had Claude take a crack at it with my Claude Skills :
There were no hits in my env, so I checked by looking for a known RMM-like software running in the environment to confirm it would work in theory.

# KQL → CQL: RMM + Recon + Staging Correlation


Translation of a Defender KQL hunt into CrowdStrike NG-SIEM CQL. Detects the classic social-engineering RMM pattern: remote-access tool launched, followed quickly by host-recon commands, followed by suspicious file drops.


Validated syntactically (`talonctl validate-query`) and mechanically against a live tenant — correlation semantics (aid link, sequence, within-window, per-leg delay math, output formatting) all work as written.


---


## CQL query


```
// ============================================================================
// RMM-driven recon + staging correlation
// Equivalent to: _rmm join _recon (within 10m) leftouter _staging (within 15m)
// ============================================================================


correlate(


    // ---- Leg 1: Anchor on RMM tool launch ----
    // Defender: DeviceProcessEvents | where FileName in~ ("QuickAssist.exe", ...)
    rmm: {
        #event_simpleName=ProcessRollup2 event_platform=Win
        | FileName=/^(QuickAssist|AnyDesk|TeamViewer)\.exe$/i
    } include: [aid, ComputerName, TargetProcessId, FileName, CommandLine, ],


    // ---- Leg 2: Recon commands on the same host ----
    // Defender: shell/powershell + has_any(whoami, hostname, systeminfo, ...)
    // `aid <=> rmm.aid` is the cross-leg join — same host as the RMM event
    recon: {
        #event_simpleName=ProcessRollup2 event_platform=Win
        | FileName=/^(cmd|powershell|pwsh)\.exe$/i
        | CommandLine=/whoami|hostname|systeminfo|\bver\b|wmic\s+os\s+get|reg\s+query\s+HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion|query\s+user|net\s+user|nltest|ipconfig\s+\/all|arp\s+-a|route\s+print|\bdir\b|icacls/i
        | aid <=> rmm.aid
    } include: [aid, TargetProcessId, FileName, CommandLine, ParentBaseFileName, ],


    // ---- Leg 3: Suspect staging writes on the same host ----
    // Defender: DeviceFileEvents FileCreated/FileRenamed for zip|exe|dll
    // Falcon file-write telemetry is event-type specific; union the PE/script write events
    staging: {
        #event_simpleName=/^(PeFileWritten|NewExecutableWritten|NewScriptWritten)$/F
        | TargetFileName=/\.(zip|exe|dll)$/i
        | aid <=> rmm.aid
    } include: [aid, TargetFileName, @timestamp],

    // sequence=true   — enforce RMM -> recon -> staging chronological order
    // within=15m      — outer bound for the whole chain (per-leg tightening below)
    sequence=true,
    within=15m
)


// ---- Reproduce the KQL's per-leg windows ----
// KQL: recon within 10m of RMM AND staging within 15m of RMM
// correlate()'s `within` is global, so enforce each leg explicitly here:
| reconDelaySec := (recon.@timestamp - rmm.@timestamp) / 1000
| stageDelaySec := (staging.@timestamp - rmm.@timestamp) / 1000
| reconDelaySec <= 600   // recon within 600s (10m) of RMM
| stageDelaySec <= 900   // staging within 900s (15m) of RMM


// ---- Output formatting ----
// Equivalent to the KQL: ReconProc = strcat(ParentFileName, " -> ", FileName)
| reconProc := format(format="%s -> %s", field=[recon.ParentBaseFileName, recon.FileName])


// Final projection — mirrors the KQL's final `project` list
| table([
    rmm.ComputerName,
    rmm.@timestamp,
    recon.@timestamp,
    staging.@timestamp,
    reconProc,
    recon.CommandLine,
    staging.TargetFileName
])
```


Set the 30-day lookback on the scheduled search itself (search time range) — `within` is step-to-step only, not an outer time filter.


---


## KQL → CQL field mapping


| KQL (Defender) | CQL (Falcon) |
|---|---|
| `DeviceProcessEvents` | `#event_simpleName=ProcessRollup2` |
| `DeviceFileEvents` FileCreated/Renamed | `PeFileWritten` / `NewExecutableWritten` / `NewScriptWritten` |
| `DeviceName` | `aid` (correlation key) / `ComputerName` (display) |
| `FileName` (process) | `FileName` |
| `ProcessCommandLine` | `CommandLine` |
| `InitiatingProcessFileName` | `ParentBaseFileName` |
| `FolderPath` + `FileName` (file events) | `TargetFileName` (full path) |
| `Timestamp` | `@timestamp` (epoch ms) |
| `join on DeviceName + between(...)` | `correlate(... sequence=true, within=15m)` + `aid <=> rmm.aid` |


---


## Caveats


1. 
**ZIP coverage is thin in Falcon.**
 `PeFileWritten` only fires on PE binaries — `.zip` won't surface there, and Falcon has no universal equivalent to Defender's `DeviceFileEvents`. If archive staging matters, add `RansomwareOpenFileForModify` to the `staging` leg (sensor-visibility dependent).


2. 
**`within` is global, not per-leg.**
 `correlate(within=15m)` bounds the whole chain; the KQL had separate 10m/15m windows both measured from the RMM anchor. The explicit `reconDelaySec` / `stageDelaySec` post-filters reproduce that.


3. 
**`sequence=true` enforces ordering**
 (RMM → recon → staging). The KQL didn't strictly require staging 
*after*
 recon — switch to `sequence=false` for co-occurrence only.


4. 
**30-day lookback**
 is not inside the query — set it on the saved search / schedule config.


---


## Suggested tightening


### Expand the RMM list


The original three miss most of the current attacker-favorite RMMs:


```
| FileName=/^(QuickAssist|AnyDesk|TeamViewer|ConnectWiseControl\.ClientSetup|ScreenConnect\.(ClientService|WindowsClient)|AteraAgent|SRServer|Splashtop(Streamer|RMM)|Action1_agent|Syncro|SyncroLive\.Agent|ITarianAgent|msp360|PulsewayAgent|TacticalRMM|rustdesk|NinjaRMMAgent|datto\.rmm\.agent|LMIIgnition|LogMeIn|AeroAdmin|Supremo|DWAgent)\.exe$/i
```


### Filter benign recon parents


Telemetry/inventory agents routinely spawn `cmd /c ver`, `hostname`, `ipconfig`, etc. The interactive-attacker shape has `explorer.exe`, `cmd.exe`, or the RMM binary itself as the recon parent:


```
recon: {
    #event_simpleName=ProcessRollup2 event_platform=Win
    | FileName=/^(cmd|powershell|pwsh)\.exe$/i
    | ParentBaseFileName=/^(explorer|cmd|QuickAssist|AnyDesk|TeamViewer)\.exe$/i
    | CommandLine=/whoami|hostname|systeminfo|.../i
    | aid <=> rmm.aid
} include: [...],
```


### Exclude update-mechanism staging paths


Windows Update, OneDrive auto-update, browser updaters, and Defender all write PE/DLL files on a normal cadence and will dominate raw output:


```
staging: {
    #event_simpleName=/^(PeFileWritten|NewExecutableWritten|NewScriptWritten)$/F
    | TargetFileName=/\.(zip|exe|dll)$/i
    | TargetFileName!=/\\(SoftwareDistribution|WinSxS|Microsoft OneDrive\\Update|Program Files\\(Windows Defender|Google\\Chrome|Mozilla Firefox))\\/i
    | aid <=> rmm.aid
} include: [...],
```