August 11, 2026
Why Multi-Event Rules Matter
A single failed login is noise. A single resource access is normal. But failed logins, then a successful login, then sensitive resource access? That is an attack chain. Multi-event YARA-L rules correlate different event types into one detection.
How Multi-Event Correlation Works
The key mechanism is join variables. When two event variables use the same placeholder, SecOps joins them on that value. If $fail.target.user.userid = $user and $success.target.user.userid = $user, only events with matching user IDs correlate.
Temporal ordering uses timestamp comparisons: $success.metadata.event_timestamp.seconds > $fail.metadata.event_timestamp.seconds guarantees the success happened after the failure.
Working Rule: Brute Force Followed by Sensitive Access
rule detect_brute_force_then_access {
meta:
author = "SecOps Team"
description = "Multiple failed logins followed by success and sensitive resource access"
severity = "CRITICAL"
mitre_attack = "T1110, T1078"
events:
// 1. Capture failed login attempts
$fail.metadata.event_type = "USER_LOGIN"
$fail.security_result.action = "BLOCK"
$fail.target.user.userid = $user
// 2. Capture a subsequent successful login
$success.metadata.event_type = "USER_LOGIN"
$success.security_result.action = "ALLOW"
$success.target.user.userid = $user
$success.metadata.event_timestamp.seconds > $fail.metadata.event_timestamp.seconds
// 3. Capture a subsequent resource access event
$access.metadata.event_type = "USER_RESOURCE_ACCESS"
$access.principal.user.userid = $user
$access.metadata.event_timestamp.seconds > $success.metadata.event_timestamp.seconds
match:
$user over 1h
outcome:
$fail_count = count($fail.metadata.id) // Fixed: Now aggregates on the event ID
$resources_accessed = array_distinct($access.target.resource.name)
condition:
$fail and $success and $access and $fail_count >= 5
}
Breaking Down the Correlation
Three event variables ($fail, $success, $access) each define their own conditions. The join variable $user appears in all three, forcing SecOps to correlate only events for the same user. Timestamp ordering ensures the sequence is failures, then success, then access. The condition requires all three event types plus at least 5 failed attempts.
Tips: Keep to two or three event variables. Always include timestamp ordering when sequence matters. Choose a match window that fits your threat model.
