1 - The rule, as written, will gather all the NETWORK_DNS and NETWORK_HTTP events and join them by a common hostname. For both events that common value will be in the principal.hostname field. The equivalent for lines 4 and 6 could be represented in this way as well.
$e1.principal.hostname = $e2.principal.hostname
The $hostname is being used as a placeholder variable in the event section but it also being used in the match section as a match variable. That's fine, to have a match variable, it needs to be defined in the events section because YARA-L does not allow a field name in the match section.
Without the the statement above or lines 2 and 4 joined via a placeholder variable there is not a way to join two disparate events together. While the match section appears to have that bridge, it's worth thinking of the match section as a group by or aggregation within a time boundary.
In this example rule, https://github.com/chronicle/detection-rules/blob/main/community/threat_intel/gcti_remote_access_tools.yaral, we are joining a list of remote access tools to process events using a sha256 field, but in the match section we are aggregating the events by hostname.
2 - The condition for a simple rule may appear to be redundant, basically we are saying that both event1 and event2 must exist to trigger, but when we get into more complex rules, we can use thresholding or aggregated values in the condition section to trigger.
Here's an example rule, https://github.com/chronicle/detection-rules/blob/main/community/microsoft/windows/win_repeatedAuthFailure_thenSuccess_T1110_001.yaral, where we are looking for 5 failed login events that meet some criteria (defined in events), and a success event for this to trigger. Also notice how joining time between the two events we can force the failed events to occur before the success. There are also examples where we could do a does not exist for a condition, that is we saw event 1 but never saw event 2 and we need to flag on that.
I like to keep this syntax guide handy when I build rules and is a useful reference that calls out a few of those other cases that aren't as frequently raised. https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-syntax
Hope this helps!
1 - The rule, as written, will gather all the NETWORK_DNS and NETWORK_HTTP events and join them by a common hostname. For both events that common value will be in the principal.hostname field. The equivalent for lines 4 and 6 could be represented in this way as well.
$e1.principal.hostname = $e2.principal.hostname
The $hostname is being used as a placeholder variable in the event section but it also being used in the match section as a match variable. That's fine, to have a match variable, it needs to be defined in the events section because YARA-L does not allow a field name in the match section.
Without the the statement above or lines 2 and 4 joined via a placeholder variable there is not a way to join two disparate events together. While the match section appears to have that bridge, it's worth thinking of the match section as a group by or aggregation within a time boundary.
In this example rule, https://github.com/chronicle/detection-rules/blob/main/community/threat_intel/gcti_remote_access_tools.yaral, we are joining a list of remote access tools to process events using a sha256 field, but in the match section we are aggregating the events by hostname.
2 - The condition for a simple rule may appear to be redundant, basically we are saying that both event1 and event2 must exist to trigger, but when we get into more complex rules, we can use thresholding or aggregated values in the condition section to trigger.
Here's an example rule, https://github.com/chronicle/detection-rules/blob/main/community/microsoft/windows/win_repeatedAuthFailure_thenSuccess_T1110_001.yaral, where we are looking for 5 failed login events that meet some criteria (defined in events), and a success event for this to trigger. Also notice how joining time between the two events we can force the failed events to occur before the success. There are also examples where we could do a does not exist for a condition, that is we saw event 1 but never saw event 2 and we need to flag on that.
I like to keep this syntax guide handy when I build rules and is a useful reference that calls out a few of those other cases that aren't as frequently raised. https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-syntax
Hope this helps!
Thank you so much for your detailed response.
The following that you laid down was very helpful to unlock this concept:
The rule, as written, will gather all the NETWORK_DNS and NETWORK_HTTP events and join them by a common hostname. For both events that common value will be in the principal.hostname field.
