Open greicefaustino opened 3 weeks ago
Pinging @elastic/security-solution (Team: SecuritySolution)
Pinging @elastic/security-detection-engine (Team:Detection Engine)
@greicefaustino for threshold rule type the only fields that are exposed for Alert/Rules Exception
are the ones in the threshold fields array (Group by fields
), for instance for this rule it will be host.id and/or file.name
.
the rule logic is looking for the same file.name
created in more than 20 different paths by same process (pid equal 4 and process.name is System), so adding file.path
to the Threshold Group by
won't help here (its not aligning with the detection logic, the file.path
is supposed to be unique not the same).
if you want a similar logic and where the alert contains all the fields you can use an EQL rule using with runs statement :
sequence by host.id, user.id, process.entity_id with maxspan=1m
[file where host.os.type == "windows" and event.action == "creation" and
process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and file.extension : ("hta", "txt", "readme", "htm*") and
/* ransom file name keywords */
file.name : ("*read*me*", "*lock*", "*@*", "*RECOVER*", "*decrypt*", "*restore*file*", "*FILES_BACK*", "*how*to*")] with runs=10
Below example of matches on the AKIRA ransomware :
we do have an existing built-in one that use EQL (with runs) but starts with a network event which may have more performance impact.
Describe the feature:
Have the file.path field added to the alert, so that it can be used for filtering and exceptions.
Describe a specific use case for the feature:
Trusted applications can cause false positive alerts to trigger. In this use case, a global "Trusted Application" would blind all other types of alerts from the application directory.
We want to only create the exclusion for this alert rule but since the "file.path" field is not included in the alert details, it cannot be used as a filter.