You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the default alert rules in sentinel for Threat Intelligence uses the security event 4688 as a source, woudl it be possible to rewrite this rule so i can use sysmon eventId 1 instead. from our tests using security events with azure sentinel even with the lowest setting generates a huge amount of logs and thus costs.
below is the original query that relies on eventid 4688
let dt_lookBack = 1h;
let ioc_lookBack = 14d;
ThreatIntelligenceIndicator
| where TimeGenerated >= ago(ioc_lookBack) and ExpirationDateTime > now()
| where Active == true
| where isnotempty(FileHashValue)
| join (
SecurityEvent | where TimeGenerated >= ago(dt_lookBack)
| where EventID in ("8003","8002","8005")
| where isnotempty(FileHash)
| extend SecurityEvent_TimeGenerated = TimeGenerated, Event = EventID
)
on $left.FileHashValue == $right.FileHash
| summarize LatestIndicatorTime = arg_max(TimeGenerated, *) by IndicatorId
| project LatestIndicatorTime, Description, ActivityGroupNames, IndicatorId, ThreatType, ExpirationDateTime, ConfidenceScore, SecurityEvent_TimeGenerated, Process, FileHash, Computer, Account, Event
| extend timestamp = SecurityEvent_TimeGenerated, AccountCustomEntity = Account, HostCustomEntity = Computer
in the eventID 1 of the sysmon the hashes are not expilicitly seperated out, can this be "handled" or will I need to amend the sysmon_OSSEM function first / also
below is the result from the azure sentinel log query for eventID 1
hi
the default alert rules in sentinel for Threat Intelligence uses the security event 4688 as a source, woudl it be possible to rewrite this rule so i can use sysmon eventId 1 instead. from our tests using security events with azure sentinel even with the lowest setting generates a huge amount of logs and thus costs.
below is the original query that relies on eventid 4688
in the eventID 1 of the sysmon the hashes are not expilicitly seperated out, can this be "handled" or will I need to amend the sysmon_OSSEM function first / also
below is the result from the azure sentinel log query for eventID 1
it seems to me there is something off here with the process parent guid containing the file hashes ?
The text was updated successfully, but these errors were encountered: