Übersicht über die Sprache YARA-L 2.0
YARA-L 2.0 ist eine Computersprache, mit der Regeln für die Suche in Ihren Unternehmensprotokolldaten erstellt werden, wenn diese in Ihre Google Security Operations-Instanz aufgenommen werden. Die YARA-L-Syntax wird von der von VirusTotal entwickelten YARA-Sprache abgeleitet. Die Sprache arbeitet mit der Google Security Operations Detection Engine zusammen und ermöglicht die Suche nach Bedrohungen und anderen Ereignissen in großen Datenmengen.
Hier finden Sie weitere Informationen:
YARA-L 2.0-Beispielregeln
Die folgenden Beispiele zeigen Regeln in YARA-L 2.0. Jede davon zeigt, wie Ereignisse innerhalb der Regelsprache in Beziehung gesetzt werden.
Regeln und Abstimmung
Mit der folgenden Regel wird nach bestimmten Mustern in Ereignisdaten gesucht und eine Erkennung erstellt
ob sie die Muster findet. Diese Regel enthält die Variable $e1
für das Tracking-Ereignis
„type“ und das UDM-Feld metadata.event_type
. Die Regel prüft bestimmte Vorkommen
der regulären Ausdrücke stimmt mit e1
überein. Wenn das Ereignis $e1
eintritt, wird eine Erkennung erstellt.
Die Regel enthält die Bedingung not
, um bestimmte nicht schädliche Pfade auszuschließen.
Sie können not
-Bedingungen hinzufügen, um falsch positive Ergebnisse zu vermeiden.
rule suspicious_unusual_location_svchost_execution
{
meta:
author = "Google Cloud Security"
description = "Windows 'svchost' executed from an unusual location"
yara_version = "YL2.0"
rule_version = "1.0"
events:
$e1.metadata.event_type = "PROCESS_LAUNCH"
re.regex($e1.principal.process.command_line, `\bsvchost(\.exe)?\b`) nocase
not re.regex($e1.principal.process.command_line, `\\Windows\\System32\\`) nocase
condition:
$e1
}
Anmeldungen aus verschiedenen Städten
Mit der folgenden Regel wird nach Nutzern gesucht, die sich in weniger als 5 Minuten in zwei oder mehr Städten bei Ihrem Unternehmen angemeldet haben:
rule DifferentCityLogin {
meta:
events:
$udm.metadata.event_type = "USER_LOGIN"
$udm.principal.user.userid = $user
$udm.principal.location.city = $city
match:
$user over 5m
condition:
$udm and #city > 1
}
Übereinstimmungsvariable: $user
Ereignisvariable:$udm
Platzhaltervariable: $city
und $user
Im Folgenden wird die Funktionsweise dieser Regel beschrieben:
- Gruppiert Ereignisse mit dem Nutzernamen (
$user
) und gibt ihn ($user
) zurück, wenn eine Übereinstimmung gefunden wird. - Die Zeitspanne beträgt 5 Minuten. Das bedeutet, dass nur Ereignisse korreliert werden, die weniger als 5 Minuten auseinanderliegen.
- Es wird nach einer Ereignisgruppe (
$udm
) mit dem Ereignistyp USER_LOGIN gesucht. - Für diese Ereignisgruppe ruft die Regel die Nutzer-ID als
$user
und den Anmeldeort als$city.
auf - Gibt eine Übereinstimmung zurück, wenn die eindeutige Anzahl der
city
-Werte (gekennzeichnet mit#city
) in der Ereignisgruppe ($udm
) innerhalb des Zeitraums von 5 Minuten größer als 1 ist.
Schnelle Erstellung und Löschung von Nutzern
Mit der folgenden Regel wird nach Nutzern gesucht, die erstellt und dann innerhalb von vier Stunden gelöscht wurden:
rule UserCreationThenDeletion {
meta:
events:
$create.target.user.userid = $user
$create.metadata.event_type = "USER_CREATION"
$delete.target.user.userid = $user
$delete.metadata.event_type = "USER_DELETION"
$create.metadata.event_timestamp.seconds <=
$delete.metadata.event_timestamp.seconds
match:
$user over 4h
condition:
$create and $delete
}
Ereignisvariablen:$create
und $delete
Übereinstimmungsvariable: $user
Platzhaltervariable: –
Im Folgenden wird die Funktionsweise dieser Regel beschrieben:
- Gruppiert Ereignisse mit dem Nutzernamen (
$user
) und gibt ihn ($user
) zurück, wenn eine Übereinstimmung gefunden wird. - Das Zeitfenster beträgt 4 Stunden. Es werden also nur Ereignisse korreliert, die durch weniger als 4 Stunden voneinander getrennt sind.
- Sucht nach zwei Ereignisgruppen (
$create
und$delete
, wobei$create
#create >= 1
entspricht). $create
entsprichtUSER_CREATION
-Ereignissen und ruft die User-ID als$user
auf.- Mit
$user
werden die beiden Ereignisgruppen zusammengeführt. $delete
entsprichtUSER_DELETION
-Ereignissen und ruft die User-ID als$user
auf. Diese Regel sucht nach einer Übereinstimmung, bei der die Nutzer-ID in den beiden Ereignisgruppen identisch ist.- Diese Regel sucht nach Fällen, in denen das Ereignis aus
$delete
später als das Ereignis aus$create
eintritt. Wenn das Ereignis erkannt wird, wird eine Übereinstimmung zurückgegeben.
Einzelereignisregel
Regeln für einzelne Ereignisse sind Regeln, die sich auf ein einzelnes Ereignis beziehen. Eine einzelne Ereignisregel kann Folgendes sein:
- Jede Regel ohne Übereinstimmungsbereich.
- Eine Regel mit einem
match
-Abschnitt und einemcondition
-Abschnitt, die nur das Vorhandensein eines Ereignisses prüft (z. B. "$e", "#e > 0", "#e >= 1", "1 <= #e", "0 < #e").
Die folgende Regel sucht beispielsweise nach einem Anmeldeereignis eines Nutzers und gibt das erste Ereignis zurück, das in den Unternehmensdaten gefunden wird, die in Ihrem Google Security Operations-Konto gespeichert sind:
rule SingleEventRule {
meta:
author = "noone@altostrat.com"
events:
$e.metadata.event_type = "USER_LOGIN"
condition:
$e
}
Hier ist ein weiteres Beispiel für eine Einzelereignisregel mit einem Übereinstimmungsbereich. Mit dieser Regel wird nach einem Nutzer gesucht, der sich mindestens einmal in weniger als 5 Minuten angemeldet hat. Damit wird überprüft, ob ein Nutzeranmeldungsereignis einfach vorhanden ist.
rule SingleEventRule {
meta:
author = "alice@example.com"
description = "windowed single event example rule"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.principal.user.userid = $user
match:
$user over 5m
condition:
#e > 0
}
rule MultiEventRule{
meta:
author = "alice@example.com"
description = "Rule with outcome condition and simple existence condition on one event variable"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.principal.user.userid = $user
match:
$user over 10m
outcome:
$num_events_in_match_window = count($e.metadata.id)
condition:
#e > 0 and $num_events_in_match_window >= 10 // Could be rewritten as #e >= 10
}
Regel für mehrere Ereignisse
Verwenden Sie mehrere Ereignisregeln, um viele Ereignisse über einen bestimmten Zeitraum zu gruppieren, und versuchen Sie, Korrelationen zwischen den Ereignissen zu finden. Eine typische Regel für mehrere Ereignisse sieht folgendermaßen aus:
- Ein
match
-Abschnitt, der den Zeitraum angibt, über den Ereignisse gruppiert werden müssen. - Ein
condition
-Abschnitt, der angibt, welche Bedingung die Erkennung und Prüfung auf das Vorhandensein mehrerer Ereignisse auslösen soll.
Die folgende Regel sucht beispielsweise nach einem Nutzer, der sich in weniger als 10 Minuten mindestens 10-mal angemeldet hat:
rule MultiEventRule {
meta:
author = "noone@altostrat.com"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.principal.user.userid = $user
match:
$user over 10m
condition:
#e >= 10
}
Einzelnes Ereignis innerhalb des IP-Adressbereichs
Das folgende Beispiel zeigt eine Einzelereignisregel, die nach einer Übereinstimmung zwischen zwei bestimmten Nutzern und einem bestimmten IP-Adressbereich sucht:
rule OrsAndNetworkRange {
meta:
author = "noone@altostrat.com"
events:
// Checks CIDR ranges.
net.ip_in_range_cidr($e.principal.ip, "203.0.113.0/24")
// Detection when the hostname field matches either value using or.
$e.principal.hostname = /pbateman/ or $e.principal.hostname = /sspade/
condition:
$e
}
Beispiel für jede beliebige und alle Regeln
Mit der folgenden Regel wird nach Anmeldeereignissen gesucht, bei denen keine Quell-IP-Adressen innerhalb eines Zeitraums von 5 Minuten mit einer als sicher bekannten IP-Adresse übereinstimmen.
rule SuspiciousIPLogins {
meta:
author = "alice@example.com"
events:
$e.metadata.event_type = "USER_LOGIN"
// Detects if all source IP addresses in an event do not match "100.97.16.0"
// For example, if an event has source IP addresses
// ["100.97.16.1", "100.97.16.2", "100.97.16.3"],
// it will be detected since "100.97.16.1", "100.97.16.2",
// and "100.97.16.3" all do not match "100.97.16.0".
all $e.principal.ip != "100.97.16.0"
// Assigns placeholder variable $ip to the $e.principal.ip repeated field.
// There will be one detection per source IP address.
// For example, if an event has source IP addresses
// ["100.97.16.1", "100.97.16.2", "100.97.16.3"],
// there will be one detection per address.
$e.principal.ip = $ip
match:
$ip over 5m
condition:
$e
}
Reguläre Ausdrücke in einer Regel
Im folgenden Beispiel für einen regulären Ausdruck für YARA-L 2.0 wird nach Ereignissen mit E-Mails gesucht, die von der Domain altostrat.com empfangen wurden. Da nocase
dem Vergleich der $host
-Variablen regex
und der regex
-Funktion hinzugefügt wurde, wird bei beiden Vergleichen die Groß-/Kleinschreibung nicht berücksichtigt.
rule RegexRuleExample {
meta:
author = "noone@altostrat.com"
events:
$e.principal.hostname = $host
$host = /.*HoSt.*/ nocase
re.regex($e.network.email.from, `.*altostrat\.com`) nocase
match:
$host over 10m
condition:
#e > 10
}
Beispiel für eine gleitende Fensterregel
Im folgenden Beispiel für YARA-L 2.0-gleitende Fenster wird nach dem Fehlen von
firewall_2
Ereignisse nach firewall_1
Ereignissen. Das Schlüsselwort after
wird verwendet mit
die Pivot-Ereignisvariable $e1
, um anzugeben, dass jeweils nur 10-Minuten-Zeitfenster
firewall_1
-Ereignis sollte beim Korrelieren von Ereignissen geprüft werden.
rule SlidingWindowRuleExample {
meta:
author = "alice@example.com"
events:
$e1.metadata.product_name = "firewall_1"
$e1.principal.hostname = $host
$e2.metadata.product_name = "firewall_2"
$e2.principal.hostname = $host
match:
$host over 10m after $e1
condition:
$e1 and !$e2
}
Beispiel für den Ausschluss von Nullwerten
Das Rules Engine filtert die Nullwerte implizit für alle Platzhalter
die im Abschnitt match
verwendet werden.
Weitere Informationen finden Sie unter Umgang mit Nullwerten im Abschnitt match
.
Dies kann deaktiviert werden, indem Sie die Option allow_zero_values
als
unter allow_zero_values beschrieben.
Für andere referenzierte Ereignisfelder Nullwerte werden nur ausgeschlossen, wenn Sie solche Bedingungen explizit angeben.
rule ExcludeZeroValues {
meta:
author = "alice@example.com"
events:
$e1.metadata.event_type = "NETWORK_DNS"
$e1.principal.hostname = $hostname
// $e1.principal.user.userid may be empty string.
$e1.principal.user.userid != "Guest"
$e2.metadata.event_type = "NETWORK_HTTP"
$e2.principal.hostname = $hostname
// $e2.target.asset_id cannot be empty string as explicitly specified.
$e2.target.asset_id != ""
match:
// $hostname cannot be empty string. The rule behaves as if the
// predicate, `$hostname != ""` was added to the events section, because
// `$hostname` is used in the match section.
$hostname over 1h
condition:
$e1 and $e2
}
Beispiel für eine Regel mit dem Abschnitt „outcome
“
Sie können den optionalen Abschnitt outcome
in der YARA-L 2.0-Regel zum Extrahieren hinzufügen
zusätzliche Informationen zu jeder Erkennung. Im Bereich „Bedingung“ können Sie auch
Bedingungen für Ergebnisvariablen. Du kannst den Abschnitt outcome
einer Erkennung verwenden
zum Festlegen von Variablen
für den nachgelagerten Verbrauch. Sie können beispielsweise
Schweregradwert basierend auf Daten aus den zu analysierenden Ereignissen.
Hier finden Sie weitere Informationen:
Multi-Event-Regel mit Abschnitt „Ergebnis“:
Die folgende Regel untersucht zwei Ereignisse, um den Wert von
$hostname
Wenn der Wert von $hostname
über einen Zeitraum von 5 Minuten übereinstimmt,
wird ein Schweregrad angewendet. Wenn Sie im Abschnitt match
einen Zeitraum angeben,
wird innerhalb des angegebenen
Zeitraums überprüft.
rule OutcomeRuleMultiEvent {
meta:
author = "Google Cloud Security"
events:
$u.udm.principal.hostname = $hostname
$asset_context.graph.entity.hostname = $hostname
$severity = $asset_context.graph.entity.asset.vulnerabilities.severity
match:
$hostname over 5m
outcome:
$risk_score =
max(
100
+ if($hostname = "my-hostname", 100, 50)
+ if($severity = "HIGH", 10)
+ if($severity = "MEDIUM", 5)
+ if($severity = "LOW", 1)
)
$asset_id_list =
array(
if($u.principal.asset_id = "",
"Empty asset id",
$u.principal.asset_id
)
)
$asset_id_distinct_list = array_distinct($u.principal.asset_id)
$asset_id_count = count($u.principal.asset_id)
$asset_id_distinct_count = count_distinct($u.principal.asset_id)
condition:
$u and $asset_context and $risk_score > 50 and not arrays.contains($asset_id_list, "id_1234")
}
rule OutcomeRuleMultiEvent {
meta:
author = "alice@example.com"
events:
$u.udm.principal.hostname = $hostname
$asset_context.graph.entity.hostname = $hostname
$severity = $asset_context.graph.entity.asset.vulnerabilities.severity
match:
$hostname over 5m
outcome:
$total_network_bytes = sum($u.network.sent_bytes) + sum($u.network.received_bytes)
$risk_score = if(total_network_bytes > 1024, 100, 50) +
max(
if($severity = "HIGH", 10)
+ if($severity = "MEDIUM", 5)
+ if($severity = "LOW", 1)
)
$asset_id_list =
array(
if($u.principal.asset_id = "",
"Empty asset id",
$u.principal.asset_id
)
)
$asset_id_distinct_list = array_distinct($u.principal.asset_id)
$asset_id_count = count($u.principal.asset_id)
$asset_id_distinct_count = count_distinct($u.principal.asset_id)
condition:
$u and $asset_context and $risk_score > 50 and not arrays.contains($asset_id_list, "id_1234")
}
Einzelereignis-Regel mit Ergebnisabschnitt:
rule OutcomeRuleSingleEvent {
meta:
author = "alice@example.com"
events:
$u.metadata.event_type = "FILE_COPY"
$u.principal.file.size = $file_size
$u.principal.hostname = $hostname
outcome:
$suspicious_host = $hostname
$admin_severity = if($u.principal.userid in %admin_users, "SEVERE", "MODERATE")
$severity_tag = if($file_size > 1024, $admin_severity, "LOW")
condition:
$u
}
Refaktorieren einer Ergebnisregel für mehrere Ereignisse in eine Ergebnisregel für ein einzelnes Ereignis
Sie können den Abschnitt outcome
für beide Einzelereignisregeln (Regeln ohne
match
-Abschnitt) und Multi-Ereignis-Regeln (Regeln mit einem match
-Abschnitt).
Wenn Sie eine Regel mit mehreren Ereignissen erstellt haben,
verwenden, können Sie diese Regeln optional refaktorieren, indem Sie
match
, um die Leistung zu verbessern. Beachten Sie, dass die Regel
mehr einen match
-Abschnitt, der die Gruppierung anwendet,
erhalten Sie möglicherweise mehr Erkennungsmechanismen. Diese Refaktorierung ist nur
bei denen eine Ereignisvariable verwendet wird (siehe Abbildung
folgenden Beispiel.
Ergebnisregel für Mehrfachereignisse, die nur eine Ereignisvariable (eine ein guter Kandidat für eine Refaktorierung):
rule OutcomeMultiEventPreRefactor {
meta:
author = "alice@example.com"
description = "Outcome refactor rule, before the refactor"
events:
$u.udm.principal.hostname = $hostname
match:
$hostname over 5m
outcome:
$risk_score = max(if($hostname = "my-hostname", 100, 50))
condition:
$u
}
Sie können die Regel refaktorieren, indem Sie den Abschnitt match
löschen. Beachten Sie, dass Sie
muss auch das Aggregat im Abschnitt outcome
entfernen, da die Regel nun
für ein einzelnes Ereignis. Weitere Informationen finden Sie unter Ergebnisaggregationen.
rule OutcomeSingleEventPostRefactor {
meta:
author = "alice@example.com"
description = "Outcome refactor rule, after the refactor"
events:
$u.udm.principal.hostname = $hostname
// We deleted the match section.
outcome:
// We removed the max() aggregate.
$risk_score = if($hostname = "my-hostname", 100, 50)
condition:
$u
}
Beispiel für Regel von Funktion zu Platzhalter
Sie können dem Ergebnis eines Funktionsaufrufs eine Platzhaltervariable zuweisen und
die Platzhaltervariable in anderen Abschnitten der Regel verwenden, wie z. B.
Bereich „match
“, Bereich „outcome
“ oder Bereich „condition
“. Sehen Sie sich folgendes Beispiel an:
rule FunctionToPlaceholderRule {
meta:
author = "alice@example.com"
description = "Rule that uses function to placeholder assignments"
events:
$u.metadata.event_type = "EMAIL_TRANSACTION"
// Use function-placeholder assignment to extract the
// address from an email.
// address@website.com -> address
$email_to_address_only = re.capture($u.network.email.from , "(.*)@")
// Use function-placeholder assignment to normalize an email:
// uid@??? -> uid@company.com
$email_from_normalized = strings.concat(
re.capture($u.network.email.from , "(.*)@"),
"@company.com"
)
// Use function-placeholder assignment to get the day of the week of the event.
// 1 = Sunday, 7 = Saturday.
$dayofweek = timestamp.get_day_of_week($u.metadata.event_timestamp.seconds)
match:
// Use placeholder (from function-placeholder assignment) in match section.
// Group by the normalized from email, and expose it in the detection.
$email_from_normalized over 5m
outcome:
// Use placeholder (from function-placeholder assignment) in outcome section.
// Assign more risk if the event happened on weekend.
$risk_score = max(
if($dayofweek = 1, 10, 0) +
if($dayofweek = 7, 10, 0)
)
condition:
// Use placeholder (from function-placeholder assignment) in condition section.
// Match if an email was sent to multiple addresses.
#email_to_address_only > 1
}
Beispielregel für Ergebnisbedingungen
Im Bereich condition
können Sie definierte Ergebnisvariablen verwenden
im Abschnitt outcome
. Das folgende Beispiel zeigt, wie nach
Risikobewertungen, um Rauschen in Erkennungen mithilfe von Ergebnisbedingungen zu reduzieren.
rule OutcomeConditionalRule {
meta:
author = "alice@example.com"
description = "Rule that uses outcome conditionals"
events:
$u.metadata.event_type = "FILE_COPY"
$u.principal.file.size = $file_size
$u.principal.hostname = $hostname
// 1 = Sunday, 7 = Saturday.
$dayofweek = timestamp.get_day_of_week($u.metadata.collected_timestamp.seconds)
outcome:
$risk_score =
if($file_size > 500*1024*1024, 2) + // Files 500MB are moderately risky
if($file_size > 1024*1024*1024, 3) + // Files over 1G get assigned extra risk
if($dayofweek=1 or $dayofweek=7, 4) + // Events from the weekend are suspicious
if($hostname = /highly-privileged/, 5) // Check for files from highly privileged devices
condition:
$u and $risk_score >= 10
}