Todo lo que siempre quisiste saber sobre las reglas de Sigma. Parte 1

Al crear productos y desarrollar experiencia, nos guiamos principalmente por el deseo de mejorar la seguridad de las empresas. Sin embargo, nuestra investigación está impulsada por algo más que la atención al cliente. Durante mucho tiempo, teníamos el deseo de realizar investigaciones para la comunidad de seguridad de la información de forma voluntaria, y ahora estamos haciendo esto activamente: publicamos ataques de red de alto perfil en Twitter , suministramos reglas de análisis de tráfico al servicio ANY.RUN y agregamos reglas ETOpen . Hay muchos proyectos de código abierto a los que puede enviar una solicitud de extracción, pero hasta hace poco, las detecciones de host todavía no llegaron a sus manos.



Y luego supimos que un grupo de entusiastas decidió organizar un sprint de dos semanas.sobre cómo escribir reglas para el proyecto Sigma , que fue creado para desarrollar un formato unificado para describir reglas para sistemas SIEM y cuenta con el apoyo de más de 140 participantes. Nos interesaron las noticias sobre el evento, ya que como proveedor de SIEM seguimos de cerca el desarrollo de la comunidad.



¡Imagine nuestra sorpresa cuando los organizadores nos contactaron e invitaron al equipo de PT Expert Security Center a participar en el sprint! Los participantes del evento formaron el Open Security Collaborative Development (OSCD), una iniciativa internacional de especialistas en seguridad de la información destinada a difundir el conocimiento y mejorar la seguridad informática en general. Con mucho gusto acordamos participar para aplicar nuestra experiencia en beneficio de la seguridad común.

Cómo surgió este artículo

Cuando comenzamos a escribir las reglas, nos dimos cuenta de que no había una descripción completa de la sintaxis de las reglas Sigma, especialmente en ruso. Las principales fuentes de conocimiento son GitHub y la experiencia personal. Hay varios artículos buenos (en ruso y en inglés ), pero en ellos el enfoque se desplaza de la sintaxis de las reglas al análisis del alcance de las reglas Sigma o la creación de una regla específica. Decidimos facilitar que los principiantes se familiaricen con el proyecto Sigma, compartan nuestra propia experiencia, recopilen en un solo lugar información sobre la sintaxis y las características de su uso. Y, por supuesto, esperamos que esto ayude a expandir la iniciativa OSCD y crear una gran comunidad en el futuro.



Como había mucho material, decidimos publicar una descripción en una serie de tres artículos:

1. , ( ).
2. . , .
3. (, , , , ) .

Sigma

Sigma es un formato unificado para describir reglas de detección basadas en datos de registros. Las reglas se almacenan en archivos YAML separados. Sigma le permite escribir una regla usando una sintaxis unificada, y luego, usando un convertidor especial, obtener la regla en la sintaxis de un sistema SIEM compatible. Además de la sintaxis de consultas de varios sistemas SIEM, se admite la creación de consultas de los siguientes tipos:

• Elasticsearch Query,
• línea de lanzamiento de la utilidad grep con los parámetros requeridos,
• Cadena de PowerShell de registros de auditoría de Windows.

Los dos últimos tipos son notables por el hecho de que no requieren software adicional para analizar registros. La utilidad grep y el intérprete de PowerShell son compatibles de fábrica en Linux y Windows, respectivamente.



La existencia de un formato unificado para describir detecciones basadas en registros hace que sea más fácil compartir conocimientos, desarrollar seguridad de código abierto y ayudar a la comunidad de seguridad de la información a combatir las amenazas emergentes.

Sintaxis general

En primer lugar, debe decirse que hay partes obligatorias y opcionales de la regla. Esto está documentado en la wiki oficial en GitHub. El bosquejo de la regla (fuente: Wiki oficial) se presenta a continuación:







Casi cualquier regla se puede dividir aproximadamente en tres partes:

1. atributos que describen la regla (metainformación);
2. atributos que describen fuentes de datos;
3. atributos que describen las condiciones para activar la regla.

Cada una de las partes corresponde al título de atributos de alto nivel requerido (además del título, el último grupo incluye los otros atributos de alto nivel opcionales), fuente de registro y detección .



Hay una característica más de la estructura de reglas de la que vale la pena hablar. Dado que las reglas se describen en el lenguaje de marcado YAML, los desarrolladores de Sigma han encontrado algún uso para esto, porque el formato YAML permite colocar múltiples documentos YAML en un archivo. Y para Sigma: varias reglas para combinar en un archivo, es decir, crear "colecciones de reglas". Este enfoque es conveniente cuando hay varias formas de detectar un ataque y no desea duplicar la parte descriptiva (como se describirá en la sección correspondiente, puede duplicar no solo la parte descriptiva de la regla).



En este caso, la regla se divide convencionalmente en dos partes:

• una parte con atributos generales para los elementos de la colección (generalmente todos los campos, excepto las secciones de fuente de registro y detección),
• una o varias partes que describen la detección (secciones fuente de registro y detección).

Si el archivo contiene una sola regla, esta declaración también es cierta, ya que estamos obteniendo una colección degenerada de una regla. Las colecciones de reglas se discutirán en detalle en la tercera parte de esta serie de artículos.



A continuación, veremos un ejemplo de una regla hipotética. Cabe señalar que los comentarios en este formulario generalmente no se usan en las reglas, aquí solo son para describir campos.

Descripción de la regla típica.

Un ejemplo de creación de una regla Sigma

Antes de describir los detalles de la sintaxis y hablar sobre las capacidades de las reglas de Sigma, consideremos un pequeño ejemplo de creación de dicha regla para dejar en claro de dónde en la práctica provienen estos o esos valores de atributos. Hay un buen artículo sobre este tema en inglés. Si ya intentó escribir sus propias reglas y descubrió qué datos deberían especificarse en el atributo del archivo YAML, puede pasar a la siguiente sección con una descripción detallada de la sección de fuentes de eventos (también llamaremos a esta sección fuentes de registro).



Describamos cómo crear una regla que detecte el uso de SettingSyncHost.exe como Living Off The Land Binary (LOLBin). La creación de reglas generalmente implica tres etapas:

1. llevar a cabo un ataque y recolectar los registros necesarios,
2. descripción de la detección como regla,
3. comprobando la regla creada.

Realizar un ataque

La idea de la regla está bien documentada en el blog de Hexacorn . Después de una lectura cuidadosa, queda claro qué pasos deben seguirse para repetir el resultado descrito en el artículo:

1. Copie el programa que desea ejecutar en cualquier directorio de escritura. El artículo sugiere elegir% TEMP%, sin embargo, puede elegir la ruta de su elección. Vale la pena considerar que se creará un subdirectorio en este directorio con el nombre que especifique en el paso 4.
2. , , , (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). , findstr.exe. , SettingSyncHost.exe Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
3. , ( settingsynchost.exe cmd PowerShell, cd < >).
4. : c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript <___>
5. SettingSyncHost.exe.

Sysmon se instala en el sistema con un archivo de configuración del proyecto modular de sysmon . Por lo tanto, la recolección de registros se realizó automáticamente. Se verán qué tipo de registros son útiles para escribir una detección mientras se escribe una regla.

Descripción de la detección en forma de una regla Sigma

En este paso, son posibles dos enfoques: encontrar una regla existente que esté más cerca en la lógica de detección y modificarla para satisfacer sus necesidades, o escribir una regla desde cero. En las etapas iniciales, se recomienda apegarse al primer enfoque. Para mayor claridad, escribiremos una regla utilizando el segundo enfoque.



Creamos un nuevo archivo e intentamos describir breve y sucintamente su esencia en el nombre. Aquí debe cumplir con el estilo de las reglas existentes. En nuestro caso, elegimos el nombre win_using_settingsynchost_to_run_hijacked_binary.yml. A continuación, comenzamos a llenarlo con contenido. Comencemos por completar la metainformación al comienzo de la regla. Ya tenemos todos los datos necesarios para esto.

Describimos brevemente qué tipo de ataque detecta la regla en el campotitle, explicaciones más detalladas: en el campo de descripción, para las nuevas reglas se acostumbra establecer el estado: experimental. El identificador único se puede generar de varias maneras; en Windows, la forma más fácil es ejecutar el siguiente código en un intérprete de PowerShell:

PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f

El resto de los campos hablan por sí mismos, solo notaré que es aconsejable proporcionar enlaces a fuentes que ayudaron a comprender el ataque. Esto ayudará a las personas que comprenderán mejor esta regla, y también es un tributo a los esfuerzos realizados por el autor del estudio original para describir el ataque.



Nuestra regla en esta etapa es la siguiente: a







continuación, debe describir las fuentes de los registros. Como se mencionó anteriormente, confiaremos en los registros de Sysmon, sin embargo, con el advenimiento de las categorías genéricas, se acostumbra usar la categoría process_creation para crear procesos. Más sobre categorías generalizadas se discutirá a continuación. Tenga en cuenta que es habitual escribir comentarios y consejos sobre la configuración de fuentes en el campo de definición, como las características de configuración de Sysmon:







Ahora es necesario describir la lógica de detección. Esta es la parte que consume más tiempo. Este ataque puede ser detectado por muchos criterios, nuestro ejemplo no pretende cubrir todas las formas posibles de detección, por lo tanto, describiremos una de las posibles opciones.



Si observa los eventos que sucedieron, puede construir la siguiente cadena.

Primero, comenzamos el proceso (PID: 4712) con la línea de inicio c: \ windows \ system32 \ SettingSyncHost.exe -LoadAndRunDiagScript join_oscd







Tenga en cuenta que el directorio de trabajo actual del proceso es el directorio TEMP del usuario.



A continuación, el proceso en ejecución crea un archivo por lotes y comienza su ejecución.











El proceso de ejecución de las instrucciones del archivo por lotes recibió el identificador 7076. Tras un análisis más detallado de los eventos, vemos el lanzamiento del archivo ipconfig.exe, que no contiene los metadatos inherentes a los archivos del sistema y, además, se encuentra en la carpeta con archivos temporales:







se propone considerar el lanzamiento de procesos cuyos archivos ejecutables no se encuentran en el directorio del sistema (C: \ Windows \ System32), y también si la línea de inicio del proceso padre contiene las subcadenas "cmd.exe / c", "RoamDiag.cmd" y "-outputpath". Describamos esto en la sintaxis de Sigma y obtengamos la regla final (en la próxima parte de nuestra serie de artículos sobre Sigma se proporcionará un análisis detallado de las construcciones que pueden usarse para describir la lógica de detección):

Comprobando que la regla funciona

Lanzamos el convertidor en una consulta de PowerShell: en







nuestro caso, esta consulta no dará el resultado deseado, ya que el filtro de exclusión también encuentra la ruta a la imagen del archivo ejecutable del proceso principal. Por lo tanto, simplemente indicamos que no debe haber una letra t antes de la palabra Imagen: el final de la palabra Padre:







vemos que se encontró nuestro evento. La regla funciona.



Así es como se crean las reglas Sigma en la práctica. A continuación, describiremos en detalle los campos responsables de la detección, a saber, la descripción de las fuentes de registro.

Detectar descripción

La parte principal de la regla es la descripción de la detección, ya que aquí es donde se contiene información sobre dónde y cómo buscar signos de un ataque. Esta información está contenida en los campos de los atributos de origen de registro (dónde) y de detección (cómo). En este artículo, veremos más de cerca la sección de fuente de registro y describiremos la sección de detección en la siguiente parte de nuestra serie.

Descripción de la sección de orígenes de eventos (atributo logsource)

La descripción de las fuentes de eventos está contenida en el valor del campo fuente de registro . Esta sección describe las fuentes de datos desde las cuales se entregarán los eventos para la sección de detección (el atributo de detección se trata en la siguiente sección). La sección describe la fuente en sí, la plataforma y la aplicación que se requieren para la detección. Puede contener tres atributos que los convertidores procesan automáticamente y un número arbitrario de elementos opcionales. Campos básicos:

• Categoría : describe las clases de productos. Ejemplos de valores para este campo: firewall, web, antivirus. Además, el campo puede contener categorías generalizadas, que se analizarán a continuación.
• Producto es un producto de software o sistema operativo que crea registros.
• Servicio : restricción de registros a un determinado subconjunto de servicios, por ejemplo "sshd" para Linux o "Seguridad" para Windows.
• Definición : un campo adicional para describir las características de la fuente, por ejemplo, los requisitos para configurar la auditoría (rara vez se utiliza, un ejemplo de una regla con este campo se puede encontrar en GitHub ). Se recomienda usar este atributo si la fuente tiene algún detalle.

 

El wiki oficial en GitHub define un conjunto de campos que deben usarse para que las reglas sean multiproducto. Estos campos se resumen en la tabla a continuación.





A continuación, describiremos con más detalle algunas fuentes de registros, indicando los campos de eventos utilizados y daremos ejemplos de reglas en las que se utilizan estos campos.

Campos de evento de categoría de proxy

Campos de evento de firewall

Campos de evento de la categoría de servidor web

Categorías generalizadas

Dado que Sigma es un formato generalizado para describir reglas de detección basadas en registros, la sintaxis de dichas reglas debería poder describir la lógica de detección para diferentes sistemas. Algunos sistemas usan tablas con datos agregados en lugar de eventos, y pueden venir datos de diferentes fuentes para describir la misma situación. Para unificar la sintaxis y resolver problemas similares, se introdujo un mecanismo genérico de fuentes de registro. Por el momento, se ha creado una de estas categorías: process_creation. Puede leer más sobre esto en el blog patzke.org . La lista de campos para esta categoría se puede encontrar en la página de taxonomía (esta página también describe otras categorías compatibles).

Campos de evento de categoría generalizada process_creation

ACTUALIZAR

En preparación para este artículo, se han agregado nuevas categorías genéricas:

• network_connection (Ejemplo sysmon_powershell_network_connection )
• dns_query (Ejemplo sysmon_regsvr32_network_activity )
• Registry_event (ejemplo de sysmon_rdp_settings_hijack )
• file_creation
• process_access (ejemplo de sysmon_lsass_memdump )
• image_load (ejemplo sysmon_mimikatz_inmemory_detection )
• proceso_terminado

Todos involucran información duplicada en eventos de registro de Windows y eventos de registro de Sysmon. Le recomendamos que utilice categorías generalizadas existentes al escribir sus reglas. Dado que el proyecto se está desarrollando activamente, es aconsejable seguir la aparición de nuevas categorías y actualizar sus reglas de acuerdo con otras innovaciones.

Estadísticas de uso de origen de eventos en reglas existentes

La siguiente tabla muestra las construcciones más comunes para describir las fuentes de registro. Lo más probable es que encuentre entre ellos el que se adapte a su regla.



Estadísticas sobre el uso de una combinación de campos de descripción para algunas de las fuentes más comunes (un guión significa la ausencia de este campo):

Consejos para escribir reglas

Al escribir una nueva regla, son posibles las siguientes situaciones:

1. El origen de eventos correcto ya se ha utilizado en las reglas existentes.
2. No hay una sola regla en el repositorio que use este origen de eventos.

Si se enfrenta al primer caso, utilice una de las reglas existentes como plantilla. Quizás la fuente de registro requerida ya se usa en otras reglas, entonces esto significa que los autores de complementos (convertidores de fondo) para diferentes sistemas SIEM, muy probablemente, lo tuvieron en cuenta en su mapeo y su regla debe procesarse correctamente de inmediato.



En la segunda situación, es necesario, utilizando el ejemplo de las reglas existentes, comprender cómo usar correctamente los identificadores de categoría, producto y servicio. Al crear su propio origen de registro, se recomienda agregarlo a todas las asignaciones de backends existentes. Otros contribuyentes o incluso desarrolladores pueden hacer esto, lo principal es informar sobre tal necesidad.



Hemos creado una visualización de la combinación de campos de descripción de origen de registro en las reglas existentes:

Distribución de fuentes de registro.

Usar estadísticas para combinaciones de subcampos de atributos de logsource

En este artículo, presentamos un ejemplo de creación de una regla simple y hablamos sobre la descripción de las fuentes de eventos. Ahora puede aplicar el conocimiento adquirido, ver las reglas en el repositorio de Sigma y descubrir qué fuentes se usan en una regla en particular. Siga nuestras publicaciones: en la siguiente parte veremos la parte más difícil de las reglas de Sigma: la sección que describe la lógica de detección.



Autor : Anton Kutepov, especialista del departamento de servicios expertos y desarrollo de tecnologías positivas (PT Expert Security Center)