-
Notifications
You must be signed in to change notification settings - Fork 502
Description
Integration Name
CrowdStrike [crowdstrike]
Dataset Name
crowdstrike.fdr, crowdstrike.alert
Integration Version
2.3.0
Agent Version
9.2.0
Agent Output Type
elasticsearch
Elasticsearch Version
9.2.0
OS Version and Architecture
VM with ubuntu
Software/API Version
No response
Error Message
No response
Event Original
This is not original event, but I hope this helps:
- https://p.elstc.co/paste/NwvjhxJv#dbZ+n0+BZj-ZC47/M2tUt+ioXYjB4ZFhdu4MWV5EwXw
- https://p.elstc.co/paste/usZLmTO-#3BEBnn7Dz5qLRrFTPc7qmqeu9cVzGbLlM1Awq3tKXEG
What did you do?
i am playing with Kibana's analyzer to render CrowdStrike ingested data. And I have two observations.
- We've discovered that some CrowdStrike.FDR events (eg.
ProcessRollup2
events) are missingprocess.name
fields, causing blank process nodes in the Security Solution analyzer. This impacts user experience when investigating
process trees. - In CrowdStrike.Alert Potentially missing
event.category
field.
What did you see?
1. Missing process.name
packages/crowdstrike/data_stream/fdr/elasticsearch/ingest_pipeline/default.yml
Problematic Code (lines 2002-2016):
- script:
tag: process-name
lang: painless
if: ctx.process?.executable != null && ctx.process.executable != ""
description: Calculate process.name
source: |-
def executable = ctx.process.executable;
def exe_arr = [];
def name = executable;
if(executable.substring(0,1) == "\\") {
name = executable.splitOnToken("\\")[-1];
} else if(executable.substring(0,1) == "/") {
name = executable.splitOnToken("/")[-1];
}
ctx.process.put("name", name);
Issue Details
- Input: Some ProcessRollup2 events have
process.executable: "/"
- Current Behavior: Script allows this through validation and assigns
process.name: "/"
- Expected: Script should reject invalid paths and use fallback logic
Example Event:
{
"event": {
"action": "ProcessRollup2"
},
"process": {
"executable": "/",
"command_line": "runc init",
"entity_id": "10617417868138"
}
}
Result: process.name
becomes "/"
instead of extracting "runc"
from command line.
2. CrowdStrike.alert
Current Event Classification:
- event.kind: "signal" (line 333, 1074-1076)
- event.module: "crowdstrike" (line 747-748)
- event.dataset: "crowdstrike.alert" (line 1227-1228)
- Missing event.category - this is likely the issue!
Process Information Available:
- process.entity_id: "1757938379391936417" (line 250, 495-497)
- process.name: "bash" (line 257, 659-661)
- process.executable: "/usr/bin/bash" (line 251, 1185-1187)
- process.parent.entity_id: "1757938379391138180" (line 260, 1065-1067)
- process.parent.name: "bash" (line 266, 828-830)
This alert is a process-related security signal and should have:
{
{
"event": {
"kind": "signal",
"category": ["process"], // β MISSING!
"type": ["start"] // β Could also be helpful
}
}
What did you expect to see?
1. CrowdStrike.alert
Questions for the Team
-
Is this intentional behavior? Should
process.executable: "/"
be treated as valid? -
Fallback strategy: Should the script fall back to extracting process name from
command_line
when executable
path extraction fails? -
Data source: Are there cases where CrowdStrike legitimately provides
"/"
as the executable path, or is this a
data quality issue?
Proposed Fix
Enhanced validation and fallback logic:
if: ctx.process?.executable != null && ctx.process.executable != "" &&
ctx.process.executable != "/" && ctx.process.executable != "\\"
Plus fallback to command_line
parsing when path extraction fails.
2. CrowdStrike Alert: Missing event.category
Issue
Affected File:
packages/crowdstrike/data_stream/alert/elasticsearch/ingest_pipeline/default.yml
Questions for the Team:
- Is this intentional behavior? Should CrowdStrike alerts with process information lack
event.category
?
Proposed Fix:
Add event categorization after line 22:
- set:
field: event.kind
tag: set_event_kind
value: alert
# ADD THESE NEW PROCESSORS:
- set:
field: event.category
tag: set_event_category_process
value: ["process"]
if: ctx.json?.process_id != null || ctx.json?.triggering_process_graph_id != null
- set:
field: event.type
tag: set_event_type_start
value: ["start"]
if: ctx.json?.process_start_time != null
Anything else?
Hello, I did some testing, and wanted to run my observations by you in case these make sense.
- I think this is an edge case that might need to be addressed.
- Is there any specific reason for not setting up
event.category
in these alerts? They contain process data, and are definitely process related alerts.
If I got this all wrong, please tell me, I'd need to work on some workarounds on the kibana side then to render the Process trees in analyzer.
Also, if I could be of any help with providing more examples or anything, I'll try π
Big thank you in advance!