Skip to main content

YARA L query

  • September 27, 2024
  • 3 replies
  • 132 views
rahul7514
Forum|alt.badge.img+10

Hi Team

I am trying to build a YARA L  rule for alert where "

"Alerts when one user sends too many emails are sent to a non client domain email over short time period. Can be indication of data exfil .However not sure if this is the right way to do this can some suggest where i am going wrong .This is currently giving lot of results .

 

events: $event.principal.user.email_addresses = $email_sender not $event.target.user.email_addresses in regex %non_client $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

 

3 replies

AymanC
Forum|alt.badge.img+14
  • AymanCBronze 5
  • Bronze 5
  • September 27, 2024

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

rahul7514
Forum|alt.badge.img+10
  • rahul7514Bronze 2
  • Author
  • Bronze 2
  • September 27, 2024

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

FedGreen84
  • FedGreen84
  • New Member
  • August 15, 2025

 

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

 

Hello ​@AymanC, i’m trying to use you code for a detection rule because i have more than 100 domains, but is not working, I suspect that my reference list is not correct, are you using the “@” for each line?

for example:

@example.com
@test.org

  or 

example.com
test.org

i tested both but i’m still getting way more results than using the current regex:

$ws.target.user.email_addresses != /^$|.*@example\.com|.*@test\.org/

Thank you, Regards

Terms & ConditionsCookie settingsAccessibility statement
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.