Descripción general del lenguaje YARA-L 2.0

YARA-L 2.0 es un lenguaje informático que se usa para crear reglas para buscar en los datos de registro de tu empresa, ya que se ingieren en tu cuenta de Chronicle. La sintaxis YARA-L se deriva del lenguaje YARA desarrollado por VirusTotal. El lenguaje funciona en conjunto con el motor de detección de Chronicle, y permite buscar amenazas y otros eventos en grandes volúmenes de datos. Consulta también la sección Sintaxis del lenguaje YARA-L 2.0.

Estructura de reglas

En el caso de YARA-L 2, debes especificar declaraciones, definiciones y usos de la variable en el siguiente orden:

  1. meta
  2. eventos
  3. coincidencia (opcional)
  4. condición

A continuación, se muestra la estructura genérica de una regla:

rule <rule Name>
{
  meta:
    // Stores arbitrary key-value pairs of rule details, such as who wrote
    // it, what it detects on, version control, etc.
    // Identical to the meta section in YARA-L.
    //
    // For example:
    // author = "Analyst #2112"
    // date = "08/09/2020"
    // description = "suspicious domain detected"

  events:
    // Conditions to filter events and the relationship between events.

  match:
    // Values to return when matches are found.

  condition:
    // Condition to check events and the variables used to find matches.
}

Reglas de ejemplo de YARA-L 2.0

En los ejemplos siguientes se muestran reglas escritas en YARA-L 2.0. En ellos se muestra cómo correlacionar eventos en el lenguaje de reglas.

Inicios de sesión desde diferentes ciudades

La regla siguiente busca los usuarios que han iniciado sesión en tu empresa desde dos o más ciudades en menos de cinco minutos:

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:
    #city > 1
}

Variable de coincidencia: $user

Variable de evento:$udm

Variable de marcador de posición: $city $user

A continuación, se describe cómo funciona esta regla:

  • Agrupa los eventos con un nombre de usuario ($user) y lo devuelve ($user) cuando se encuentra una coincidencia.
  • El intervalo de tiempo es de 5 minutos, es decir, solo se correlacionan eventos que duran menos de 5 minutos.
  • Buscar un grupo de eventos ($udm) cuyo tipo de evento sea USER_LOGIN.
  • En ese grupo de eventos, la regla llama al ID de usuario como $user y la ciudad de inicio de sesión como $city..
  • Devuelve una coincidencia si el número diferenciado de valores de $city es mayor que 1 en el grupo de eventos ($udm) durante el intervalo de 5 minutos.

Creación y eliminación de usuarios rápidamente

La regla siguiente busca los usuarios que se han creado y eliminado en un plazo de cuatro horas:

  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
}

Variables de evento:$create y $delete

Variable de coincidencia: $user

Variable de marcador de posición: no aplicable.

A continuación, se describe cómo funciona esta regla:

  • Agrupa los eventos con un nombre de usuario ($user) y lo devuelve ($user) cuando se encuentra una coincidencia.
  • El intervalo de tiempo es de 4 horas, lo que significa que solo se asocian los eventos separados por menos de 4 horas.
  • Busca dos grupos de eventos ($create y $delete, donde $create equivale a #create >= 1).
  • $create corresponde a USER_CREATION eventos y llama al ID de usuario como $user.
  • $user se utiliza para unir los dos grupos de eventos.
  • $delete corresponde a USER_DELETION eventos y llama al ID de usuario como $user. Esta regla busca una coincidencia en la que el identificador de usuario de los dos grupos de eventos sea el mismo.
  • Esta regla busca casos en los que el evento de $delete se produzca más tarde que el evento de $create, con lo que se devolverá una coincidencia cuando se descubra.

Evento único frente a varios eventos

Las siguientes reglas de ejemplo muestran cómo crear una regla para buscar un único evento y modificarla para buscar varios eventos.

A continuación, se muestra una única versión de un evento de la regla:

rule SingleEventRule {
  meta:
    author = "noone@altostrat.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"

  condition:
    $e
}

Esta regla busca simplemente un evento de inicio de sesión de usuario y devuelve el primero que encuentre en los datos empresariales almacenados en tu cuenta de Chronicle.

A continuación, se muestra una versión de la regla con varios eventos:

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
}

La regla busca un usuario que haya iniciado sesión al menos 10 veces en menos de 10 minutos.

Evento único dentro del intervalo de direcciones IP

En el siguiente ejemplo se muestra una única regla de evento que busca una coincidencia entre dos usuarios específicos y un intervalo específico de direcciones IP:

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
}

Campos repetidos

Los siguientes ejemplos ayudan a ilustrar el concepto de campos repetidos. El campo udm.principal.ip normalmente se representa como una matriz.

Por ejemplo, un host puede tener varias direcciones IP:

principal.ip [192.0.2.5, 198.51.100.10, 192.0.2.16]

Si incluyes la siguiente declaración en tu regla:

$e.principal.ip = "192.0.2.16"

Chronicle busca esta dirección IP dentro del conjunto de datos (y la encontrarás en este ejemplo). Esta declaración no implica que el host tenga solo una dirección IP.

La siguiente regla busca eventos en los que una dirección IP de origen se ha conectado a una dirección IP de destino y hace solicitudes a más de 50 puertos de destino en un periodo de tiempo inferior a un minuto. Lo más probable es que sea una entidad malintencionada que busque un puerto de red no seguro.

rule RepeatedFieldsRuleExample {
  meta:
    author = "noone@altostrat.com"

  events:
    $e.principal.ip = $source_ip
    $e.target.ip = $target_ip
    $e.target.port = $target_port

  match:
    $source_ip, $target_ip over 1m

  condition:
    #target_port > 50
}

Expresiones regulares de una regla

El siguiente ejemplo de expresión regular YARA-L 2.0 busca eventos con correos electrónicos recibidos del dominio altostrat.com. Como nocase se ha añadido a la comparación de las variables $host regex y regex, ambas comparaciones no distinguen entre mayúsculas y minúsculas.

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
}

Ventanas deslizantes YARA-L

De forma predeterminada, las reglas de YARA-L 2.0 se evalúan mediante ventanas de salto. Un intervalo de tiempo de datos de eventos de empresa se divide en un conjunto de ventanas de salto superpuestas, cada una con la duración especificada en la sección match. Después, los eventos se correlacionan dentro de cada periodo de salto. Con las ventanas de salto no se pueden buscar eventos que ocurran en un orden concreto (por ejemplo, e1 puede tardar hasta 2 minutos después de e2). La repetición del evento e1 y una repetición del evento e2 se relacionan siempre que estén dentro de la duración de las ventanas de salto.

Las reglas también se pueden evaluar mediante ventanas deslizantes. Con las ventanas deslizantes, las ventanas deslizantes con la duración especificada en la sección match se generan al iniciarse o terminar con una variable de evento dinámico especificada. Después, los eventos se asocian a cada ventana de desplazamiento. Esto permite buscar eventos que tengan un orden específico (por ejemplo, e1 se produce en dos minutos de e2). Se produce una repetición del evento e1 y una repetición del evento e2 si el evento e1 se produce dentro de la duración de la ventana deslizante que se muestra después del evento e2.

Sintaxis de regla de ventana deslizante

Especifique ventanas deslizantes en la sección de coincidencia de una regla de la siguiente manera:

<match-variable-name-1>, <match-variable-name-2>, ... over <sliding-window- duration> before|after <pivot-event-variable-name>

La variable de evento dinámico es la variable del evento en la que se basan las ventanas deslizantes. Si utilizas la palabra clave before, se generarán ventanas deslizantes que finalizan con cada repetición del evento dinámico. Si se usa la palabra clave after, se generan ventanas deslizantes que empiezan con cada repetición del evento dinámico.

Ejemplo de regla de ventana deslizante

El siguiente ejemplo de ventana deslizante de YARA-L 2.0 busca la ausencia de eventos firewall_2 después de firewall_1 eventos. La palabra clave after se usa con la variable de evento dinámico $e1 para especificar que solo se deben seleccionar las ventanas de 10 minutos después de cada evento firewall_1 que se debe comprobar al correlacionar eventos.

rule SlidingWindowRuleExample {
  meta:
    author = "noone@google.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
}