I don't believe this is an issue here, but I will mention that the hostname, user and process columns at the top of the column list are the principal fields, and I always tend to grab the specific named udm fields to ensure that I am looking at the correct field, principal v target v src or whatever. Again, having looked at the principal field in the UDM viewer, I don't believe that is the issue.
I ran your rule in my environment (I have 5 of the 7 event types) and the rule as written tested out as expected and returned results, so I am not really sure what to tell you. Sometimes the value you really want is in the target and not the principal but that does not appear to be the case here. Are you getting an error when you test your rule within the timeframe of the search you are showing at the top of the screen or just not getting any results?
From a troubleshooting perspective, I'd make sure my test is running within the same window of my search that I used. If my event criteria, basically the event types, all return in search, then I'd look at conditions and matches.
If you change your condition from #event_type>1 to $e, do you get grouped events by hostname and userid as expected?
What about if you remove the userid or hostname from the match, do you get hits then?
Also have you taken the named user and hostname out to widen your net a bit further and see if you get anything?
Hi Rahul,
I think the main reason you are not expecting the results you are looking for is because it appears for the 2x events "USER_LOGIN" and "FILE_MODIFICATION", the UDM field is not present in the USER_LOGIN event
Therefore, attempts to match on that will fail, unless if the events you are matching for contain the same value in the same UDM Field.
The alternative is to match on the principal.hostname, if this is suitable for your use-case, if all of the different event types you are matching for parse the data you want to match on to this field.
Alternatively, segregating the events and what they match on depending on the event will work. Lets say for example you know that for USER_LOGIN event types, the "principal.user.userid" (which gets parsed correctly in FILE_MODIFICATION events) gets parsed to "target.user.userid", then to utilise this.
Solution #1 - Matching on Principal.hostname (present in both events - this has not been tested for all of the event types listed in the rule logic)
rule test_for_rahul7514 {
meta:
author = "Ayman C"
description = "Test for Rahul7514"
events:
$e.principal.hostname = $hostname
$e.principal.user.userid = $userid
$e.metadata.event_type = $event_type
$hostname = "michael-bolton-pc"
$event_type = "FILE_MODIFICATION" or
$event_type = "USER_LOGIN" or
$event_type = "USER_CHANGE_PERMISSIONS" or
$event_type = "REGISTRY_MODIFICATION" or
$event_type = "SERVICE_MODIFICATION" or
$event_type = "SYSTEM_AUDIT_LOG_WIPE"
match:
$hostname over 15m
outcome:
$EventCount = count($event_type)
condition:
$e and $EventCount > 1
}
Solution #2 - Segregating Event Types value mapping:
rule test_for_rahul7514 {
meta:
author = "Ayman C"
description = "Test for Rahul7514"
events:
$e.principal.hostname = $hostname
$e.metadata.event_type = $event_type
$hostname = "michael-bolton-pc"
(
$e.target.user.userid = "michael" and
$event_type = "USER_LOGIN"
)
or
(
$e.principal.user.userid = "michael" and
$event_type = "FILE_MODIFICATION"
)
match:
$hostname, over 15m
outcome:
$EventCount = count($event_type)
condition:
$e and $EventCount > 1
}It's important to note, it is matching on Hostname, not the userid for both solutions - which is present in both event types.
