Help us improve
Share bugs, ideas, or general feedback.
From crowdstrike-behavioral-detections
Design multi-event behavioral detection rules using CrowdStrike NG-SIEM correlate() function. Use when building attack chain detections, correlating multiple events across time windows, or creating behavioral rules that detect complex threat patterns across AWS, EntraID, and CrowdStrike data sources.
npx claudepluginhub willwebster5/agent-skills --plugin crowdstrike-behavioral-detectionsHow this skill is triggered — by the user, by Claude, or both
Slash command
/crowdstrike-behavioral-detections:behavioral-detectionsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Design and implement behavioral detection rules that identify attack patterns across multiple events using CrowdStrike NG-SIEM's `correlate()` function.
Design SIEM (Security Information & Event Management) detection rules to identify suspicious activity and attacks.
Correlates events across log sources like auth, cloud audits, network flows to detect multi-stage attacks in SIEM systems. Useful for designing SIEM, building correlation rules, reducing alert fatigue, and compliance.
Analyze CrowdStrike NGSIEM detections for tuning opportunities based on environmental context, recent false positives, and available enrichment functions. Use when tuning detections (including behavioral rules with correlate()), reducing false positives, enhancing detection coverage, or reviewing OOTB templates for production deployment.
Share bugs, ideas, or general feedback.
Design and implement behavioral detection rules that identify attack patterns across multiple events using CrowdStrike NG-SIEM's correlate() function.
Use this skill when you need to:
// Detect failed logins followed by successful access
correlate(
FailedLogins: {
event.outcome="failure"
event.action=/UserLogon|Sign-in/
},
SuccessfulLogin: {
event.outcome="success"
event.action=/UserLogon|Sign-in/
| user.email <=> FailedLogins.user.email
},
sequence=true,
within=30m,
globalConstraints=[user.email]
)
| table([SuccessfulLogin.user.email, FailedLogins.source.ip])
| Type | Function | Use Case |
|---|---|---|
| Correlation Rule | Single-event threshold | "Alert on 50+ failed logins" |
| Behavioral Rule | Multi-event pattern via correlate() | "Alert on failed logins FOLLOWED BY success" |
Named Queries: Each event pattern has a unique name
QueryName: { filter_expression }
Link Operator <=>: Correlates fields between queries
| user.email <=> OtherQuery.user.email
Sequence: Enforce chronological order
sequence=true // Events must occur in order
Time Window: Constrain event timing
within=1h // All events within 1 hour
Global Constraints: Fields all events must share
globalConstraints=[user.email, cloud.account.id]
Identify the stages of the attack you want to detect:
| Stage | Event Type | Example |
|---|---|---|
| Reconnaissance | Read/List operations | DescribeInstances, ListBuckets |
| Initial Access | Authentication events | UserLogon, ConsoleLogin |
| Privilege Escalation | Permission changes | AttachUserPolicy, AddMemberToRole |
| Persistence | Credential creation | CreateAccessKey, CreateLoginProfile |
| Exfiltration | Data access | GetObject, FileDownloaded |
correlate(
// Stage 1: Reconnaissance
Recon: {
event.action=~in(values=["DescribeInstances", "ListBuckets"])
},
// Stage 2: Privilege Escalation
PrivEsc: {
event.action="AttachUserPolicy"
| Vendor.userIdentity.arn <=> Recon.Vendor.userIdentity.arn
},
// Stage 3: Persistence
Persist: {
event.action="CreateAccessKey"
| Vendor.userIdentity.arn <=> Recon.Vendor.userIdentity.arn
},
sequence=true,
within=2h,
globalConstraints=[Vendor.userIdentity.arn]
)
| ipLocation(Recon.source.ip)
| case {
Recon.source.ip.country!="United States" | _Risk := "Critical" ;
* | _Risk := "High" ;
}
| table([_Risk, Recon.Vendor.userIdentity.arn, Recon.source.ip, Recon.source.ip.country])
| Outcome | Field Value | Description |
|---|---|---|
| Behavioral Detection | Ngsiem.event.outcome="behavioral-detection" | Multi-event correlate() rule |
| Correlation Detection | Ngsiem.event.outcome="correlation-rule-detection" | Single-event threshold rule |
| Behavioral Case | Ngsiem.event.outcome="behavioral-case" | Creates investigation case |
// Start with 2 events
correlate(
EventA: { ... },
EventB: { ... | field <=> EventA.field },
within=1h
)
// Then add more stages after validation
| Attack Pattern | Recommended within |
|---|---|
| Authentication brute force | 15-30m |
| Privilege escalation chain | 1-2h |
| Data staging → exfil | 4-24h |
| Insider threat patterns | 24-72h |
// Cleaner than repeating links
globalConstraints=[user.email, cloud.account.id]
// Attack chain - order matters
sequence=true
// Alert correlation - either can come first
sequence=false
search:
filter: |
correlate(... within=2h ...)
lookback: 4h # Must exceed 'within' value
Before assembling a correlate() rule, run each component query independently against 30d of data. A noisy component query produces a noisy behavioral rule — and behavioral rules are harder to tune after the fact because the correlate() wrapper obscures which leg is generating volume.
// Run each leg standalone first:
ngsiem_query: <component_filter_A> | groupBy([actor, key_field], function=count()) | sort(count, desc)
ngsiem_query: <component_filter_B> | groupBy([actor, key_field], function=count()) | sort(count, desc)
If any component returns unexpectedly high volume, tune it individually before combining. The target is that each leg fires only on genuinely anomalous events — a behavioral rule combining two noisy legs produces noisy² alerts.
Failed attempts → Successful login See entraid-behavioral-rules.md
Create user → Attach admin policy → Create credentials See aws-behavioral-rules.md
Combine multiple rule triggers into compound alert See detection-chaining.md
Endpoint activity → Cloud API calls See attack-patterns.md
For complete correlate() syntax documentation, see: