Hi Rahul,
This looks like a great rule, in terms of why you may have a lot of events this could just be due to this activity being common within your organisation / log source, and a baseline needs to be done to determine legitimate vs illegitiamte activity.
In terms of the rule logic, it looks great, however you may come across a future limitation. You are currently using a regex reference list 'non_client', which I assume are recipient domains which are trusted within your organization. Unfortunately regex reference lists (from my last test of this) only supports 100 lines. Therefore what may be a preferred approach is to use a re.capture, capture out the domain for the 'target.user.email_addresses' and use a string reference list which has no upper limit (that I'm aware of anyway). Rule logic example can be seen below:
rule rule_test_email_transaction {
meta:
author = "Ayman C"
events:
$event.principal.user.email_addresses = $email_sender
$event.target.user.email_addresses = $email_recepient
$email_recepient_domain = re.capture($event.target.user.email_addresses, "@([^$]+)")
not $email_recepient_domain in %admin_list
$event.target.user.email_addresses = $email_target
$event.metadata.event_type = "EMAIL_TRANSACTION"
$event.security_result.action_details = "DELIVERED"
match:
$email_sender over 10m
outcome:
$event_count = count_distinct($event.metadata.id)
condition:
$event and $event_count > 30
} If you are unable to baseline this within your Chronicle instance, maybe look to identify if the 31 or more events count, if they contain attachments (something that may be likely within exfiltration), or correlate activity on storage platforms (such as Sharepoint) using metrics[1] to identify a lot of resources being accessed, or utilising EDR log sources if applicable. You could combine all of these different log sources and increment the risk score based on this to a minimum risk score for the rule to fire an alert.
I would recommend delving into the use of UEBA via metrics, unfortunately, there is no capabilities currently which look at 'EMAIL_TRANSACTION' event types, however, raising a request for this (if you have this capability) may result in this event type being acceptable for UEBA.
Looking into a DLP solution may also be something of interest 🙂
[1] Metrics - https://cloud.google.com/chronicle/docs/detection/metrics-functions
Hope this helps!
Kind Regards,
Ayman C
Hi Rahul,
This looks like a great rule, in terms of why you may have a lot of events this could just be due to this activity being common within your organisation / log source, and a baseline needs to be done to determine legitimate vs illegitiamte activity.
In terms of the rule logic, it looks great, however you may come across a future limitation. You are currently using a regex reference list 'non_client', which I assume are recipient domains which are trusted within your organization. Unfortunately regex reference lists (from my last test of this) only supports 100 lines. Therefore what may be a preferred approach is to use a re.capture, capture out the domain for the 'target.user.email_addresses' and use a string reference list which has no upper limit (that I'm aware of anyway). Rule logic example can be seen below:
rule rule_test_email_transaction {
meta:
author = "Ayman C"
events:
$event.principal.user.email_addresses = $email_sender
$event.target.user.email_addresses = $email_recepient
$email_recepient_domain = re.capture($event.target.user.email_addresses, "@([^$]+)")
not $email_recepient_domain in %admin_list
$event.target.user.email_addresses = $email_target
$event.metadata.event_type = "EMAIL_TRANSACTION"
$event.security_result.action_details = "DELIVERED"
match:
$email_sender over 10m
outcome:
$event_count = count_distinct($event.metadata.id)
condition:
$event and $event_count > 30
} If you are unable to baseline this within your Chronicle instance, maybe look to identify if the 31 or more events count, if they contain attachments (something that may be likely within exfiltration), or correlate activity on storage platforms (such as Sharepoint) using metrics[1] to identify a lot of resources being accessed, or utilising EDR log sources if applicable. You could combine all of these different log sources and increment the risk score based on this to a minimum risk score for the rule to fire an alert.
I would recommend delving into the use of UEBA via metrics, unfortunately, there is no capabilities currently which look at 'EMAIL_TRANSACTION' event types, however, raising a request for this (if you have this capability) may result in this event type being acceptable for UEBA.
Looking into a DLP solution may also be something of interest 🙂
[1] Metrics - https://cloud.google.com/chronicle/docs/detection/metrics-functions
Hope this helps!
Kind Regards,
Ayman C
Sorry that reference list is about internal domains of the org. This org has large number of domains. So in short it is trying to say is if email is sent within the org then it is fine, if someone sends more than 30 emails to someone external in 10m duration thens its suspicious. Since large number f results are generated looking for tuning
