Is it possible to prepare a single use case with different correlation Yara-L rules

[FranSalcidos]

dear people,
I´m currently working on a specific use case about detecting activity during non-working hours on an international environment with different timezones.
do you know if is possible to prepare a single use case with different correlation Yara-L rules ( per each timezone there are different outcomes) and call them from a "centralized" yara-L rule?
thanks in advance!

[Tomtomfridman]

This comment was originally sent by Gal Polak
Hi @FranSalcidos , All log sources are normalized to UTC in Chronicle, assuming correct timezones have been applied at the Forwarder level. You can use YARA-L time functions as follows to create an out of hours detection, e.g.,
rule coe_out_of_hours_privileged_entity_login {

meta:
author = "cmmartin@"
owner = "infosec@"
description = "Detects out of hours successful authentication for privileged entities. Login outside of core working hours is not abnormal."
response = "Verify if the entity has previously or commonly authenticated out of hours. Look for any anomalous related activity, e.g., location, auth mechanism, source."
severity = "INFOMATIONAL"
priority = "LOW"


events:
$out_of_hours_login.metadata.event_type = "USER_LOGIN"
$out_of_hours_login.target.user.email_addresses = $user
$out_of_hours_login.security_result.action = "ALLOW"
(
// Workspace Activities
$out_of_hours_login.metadata.vendor_name = "Google Workspace" or
// Workspace logging via GCP Logging
$out_of_hours_login.metadata.vendor_name = "Google Cloud Platform"
)

(
$out_of_hours_login.target.user.user_role = "ADMINISTRATOR" or
$out_of_hours_login.target.user.attribute.roles.type = "ADMINISTRATOR"
)

$ts = $out_of_hours_login.metadata.event_timestamp.seconds

// Sunday [01] and Saturday [07]
(
01 = timestamp.get_day_of_week($ts, "UTC") or
07 = timestamp.get_day_of_week($ts, "UTC")
) or
// successful auth beyond core hours of 19:00 through to 07:00
(
( timestamp.get_hour($ts, "UTC") >= 0 and timestamp.get_hour($ts,"UTC")<= 6) or
timestamp.get_hour($ts,"UTC") > 19
)

// remove context aliased addresses
not $out_of_hours_login.target.user.email_addresses = /1823127835827.altostrat.com.test-google-a.com/
not $out_of_hours_login.target.user.email_addresses = /1823127835827.demo.altostrat.com/
not $out_of_hours_login.target.user.email_addresses = /google.com/

match:
$user over 1h

outcome:
$risk_score = max(
if (01 = timestamp.get_day_of_week($ts, "UTC"), 10) +
if (07 = timestamp.get_day_of_week($ts, "UTC"), 10) +
if ( ( timestamp.get_hour($ts, "UTC") >= 0 and timestamp.get_hour($ts,"UTC")<= 6) or timestamp.get_hour($ts,"UTC") > 20, 50)
)

$outcome_user = array_distinct($user)

$weekend_activity = max(
// higher risk for weekends
if (01 = timestamp.get_day_of_week($ts, "UTC"), 20) +
if (07 = timestamp.get_day_of_week($ts, "UTC"), 20)
)

$after_hours_activity = max(
// higher risk for weekends
if ( ( timestamp.get_hour($ts, "UTC") >= 0 and timestamp.get_hour($ts,"UTC")<= 6) or timestamp.get_hour($ts,"UTC") > 19, 50)
)

condition:
$out_of_hours_login
} You can specify the timezone in YARA-L rules, e.g., timestamp.get_hour($ts, "America/Los_Angeles"), and in order to use that then you have to find some unique identifier in the original log source with the timezone (which by default our parsers don't do), e.g., you'd need to have the original timestamp in a UDM field and then use a Regex check to find the real timezone, and update your YARA-L timestamp function based off of that.

[FranSalcidos]

Thanks , will take a look!