Laboratorio de detección – Parte 3: Qué es Sysmon

En esta entrada vamos a hablar de Sysmon. Recordemos de las entradas anteriores que nuestro laboratorio de detección tiene este pinta ahora mismo:

Vamos a ver una herramienta de detección fundamental. Que además nos va a permitir tener mucho control sobre lo que monitorizamos. Estas es Sysmon. Vamos a ver su funcionamiento, su configuración y como podemos desplegarlo en las máquinas de nuestro laboratorio usando las capacidades del Active Directory.

Qué es Sysmon

La herramienta System Monitor (Sysmon) es un servicio que ofrece Microsoft para los sistemas Windows dentro de la suite Sysinternals. Con Sysmon vamos a poder definir qué eventos monitorizar en la máquina. Esto lo definiremos en un fichero de configuración que le pasaremos a Sysmon.

Podemos descargar la herramienta de la página oficial de Microsoft.

Instalación

Para desplegar Sysmon en una máquina es tan sencillo como ejecutar su proceso indicando el fichero de configuración.

# Añadimos la opción accepteula para no tener que confirmar en su instalación
PS> sysmon64.exe -i ["ficheroConfig"] -accepteula

Con esto ya tendríamos Sysmon corriendo en la máquina. Y se lanzará al inicio de Windows. Tenemos más opciones, entre otras la de actualizar el fichero de configuración sobre el que se basa el Sysmon que se está ejecutando, o para desinstalar el servicio.

# Actualiza la configuración de Sysmon
PS> sysmon64.exe -c ["ficheroConfig"]

# Desinstala el servicio
PS> sysmon64.exe -u ["ficheroConfig"]

Una vez desplegado, los eventos los podemos ver dentro del registro de eventos de Windows en la ruta:

• Registro de aplicaciones y servicios
  • Microsoft
    • Windows
      • Sysmon

El proceso de Sysmon lo tendremos ya corriendo en la máquina hasta que lo desinstalemos. Y da igual que reiniciemos, se lanzará solo al inicio del sistema.

Y hasta aquí. Ahora la gracia está en cómo definimos el fichero de configuración y qué eventos produce.

Configuración Sysmon

Por tanto, la clave del asunto con Sysmon es cómo definimos este fichero de configuración. Yo para el ejemplo anterior he usado un fichero de configuración diseñado por SwiftOnSecurity que podemos encontrar en su GitHub. Es una buena plantilla para desplegar en nuestras máquinas. Yo la uso mucho. Pero en este artículo quiero que entendáis como se conforma el fichero de configuración de Sysmon para que podáis modificar las plantillas que descarguéis según vuestras necesidades. O incluso crearlas desde cero.

Estructura básica del archivo

El archivo de configuración de Sysmon es un archivo con formato XML cuya estructura básica es:

<Sysmon schemaversion="4.50">
  <HashAlgorithms>md5,sha256</HashAlgorithms>
  <EventFiltering>

    <!-- Aqui las reglas de deteccion -->

  </EventFiltering>
</Sysmon>

• El fichero es un XML que se enmarca entre las etiquetas <Sysmon> … </Sysmon>
• La sección <HashAlgorithms> … </HashAlgorithms> va a definir qué hashes registrar cuando se necesite un cálculo de hash
  • Debemos entender que cuantos más algoritmos usemos, más va a aumentar Sysmon el uso de la CPU de ese equipo
• Por último, sección <EventFiltering> … </EventFiltering> es donde vamos a añadir las reglas para elegir qué eventos monitorizar
  • Aquí definimos básicamente qué eventos queremos que se Sysmon genere en esta máquina

Antes de la sección EventFiltering se pueden definir otras secciones que definen ciertos parámetros de configuración. Son de uso poco frecuente y no los vamos a usar demasiado. Estos son:

<EventFiltering> … </EventFiltering>

El formato básico para añadir entradas dentro de la sección <EventFiltering> … </EventFiltering> es el siguiente:

<EVENT onmatch=["include"/"exclude"]>
  <PARAMETRO condition=""> ... </PARAMETRO>
  <PARAMETRO condition=""> ... </PARAMETRO>
</EVENT>

• El EVENT define qué tipo de evento monitorizar. Esto se traducirá en un event ID concreto
• El EVENT se define por una serie de reglas de inclusión/exclusión. Y esto se define en el campo «onmatch» y los valores posibles son:
  • «include«: Si se cumplen las condiciones que se indiquen abajo, SI se monitoriza
  • «exclude«: Si se cumplen las condiciones que se indiquen abajo, NO se monitoriza
• Y los parámetros definen condiciones concretas de cuando monitorizar. Podemos verlas como reglas que definen bajo qué condiciones monitorizar ese evento
  • Los parámetros que se pueden definir son los campos de cada tipo de evento
  • Se elige el parámetro, la condición y el valor. Lo vemos a continuación

Por verlo con un ejemplo:

<ProcessCreate onmatch="include">
  <Image condition="is">C:\Windows\System32\cmd.exe</Image>
  <CommandLine condition="contains">/c</CommandLine>
</ProcessCreate>

• Monitorizamos un evento de creación de proceso (ProcessCreate). Evento con ID 1
• La condición es «include«. Eso significa, las condiciones que se definen a continuación se deben cumplir para que el evento se monitorice
• Las condiciones son:
  • Imagen del proceso sea igual (is) «C:\Windows\System32\cmd.exe»
  • Que la línea de comandos del proceso contenga (contains) «/c»

Toda cmd que se ejecute desde la ruta de cmd y que la línea de comandos contenga «/c» va a registrar un evento de ID 1 en el visor de eventos de Windows en la sección de Sysmon.

Condiciones iguales

En este ejemplo, dentro del evento ProcessCreate definimos dos condiciones que actúan en modo AND. Es decir, se tienen que cumplir las dos para que el evento se monitorice.

<ProcessCreate onmatch="include">
  <Image condition="is">C:\Windows\System32\cmd.exe</Image>
  <CommandLine condition="contains">/c</CommandLine>
</ProcessCreate>

Pero, ¿qué ocurre si tenemos un ejemplo como el siguiente? Es imposible que la imagen tenga las dos rutas a la vez.

<ProcessCreate onmatch="include">
  <Image condition="is">C:\Windows\System32\cmd.exe</Image>
  <Image condition="is">C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Image>
  <CommandLine condition="contains">/c</CommandLine>
</ProcessCreate>

En el caso de que haya dos entradas dentro del evento que definan el mismo valor (en este caso hay dos entradas para Image), estas actúan con condición OR.

Valores posibles EVENT

En el ejemplo hemos visto un EVENT, «ProcessCreate«, que se asocia con el evento con ID 1 de Sysmon. Los valores posibles y su event ID asociado los podéis encontrar en la documentación oficial y son:

Cada tipo de evento se puede definir con una serie de parámetros. En el ejemplo hemos visto que para el evento ProcessCreate definimos las condiciones de Image y CommandLine. Estas condiciones no son más que todos los campos posibles dentro del evento. Para saber qué campos tiene un evento:

• Hacéis una prueba generando uno y viendo sus campos
• Buscáis información del evento en Internet. Os recomiendo la página ultimatewindowssecurity

Por ejemplo, para el evento con ID 1, ProcessCreate, tenemos esta referencia. Podéis ver que dentro de los campos posibles se encuentran los dos que nosotros hemos usado, Image y CommandLine.

Valores posibles para las condiciones

Una vez definimos los parámetros, definimos un criterio a modo de condición. En el ejemplo hemos visto «is» y «contains«. Pero hay más opciones, y las podéis encontrar en la documentación oficial de Microsoft.

Despliegue de Sysmon por GPO

Ahora vamos a ver cómo desplegar Sysmon de forma remota usando las capacidades del Active Directory dentro del laboratorio. Esta forma es lo ideal para hacer un despliegue en un número elevado de máquinas sin tener que entrar una a una.

Crear grupo de máquinas

Si recordáis de la entrada 2, la máquina W10HOST001 ya la teníamos añadida al Active Directory y la podíamos ver usando la utilidad «Usuarios y equipos de Active Directory» dentro de la carpeta Computers.

Vamos a organizar un poco esto. Lo que nos permite tener una estructura dentro de nuestro AD es lo que se conoce como Unidad Organizativa (OU). Para crearlas hacemos clic derecho en el dominio y seleccionamos Nuevo – Unidad organizativa.

Voy a crear una primera OU que se llama «EquiposUsuarios» para agrupar aquí todo lo que vamos a considerar un equipo de usuario, es decir, no vamos a meter servidores, aplicaciones… Y dentro de esta OU, una segunda que se llame «Windows» para los equipos de usuario con SO Windows.

Ahora para mover la máquina a esta OU, hacemos clic derecho en ella, y seleccionamos Mover. Elegimos la OU y listo.

Crear carpeta compartida

Ahora vamos a crear una carpeta compartida en el DC para que el ejecutable de instalación de Sysmon y el fichero de configuración estén disponibles por todas las máquinas del lab.

Lo primero que voy a hacer es crear una carpeta en la ruta «C:» del DC. La voy a llamar «SharedLab». Y dentro voy a dejar una carpeta llamada «Sysmon» con el ejecutable y un fichero de configuración.

En la carpeta que hemos creado, «SharedLab«, hacemos clic derecho y seleccionamos Propiedades. Y dentro de estas seleccionamos Compartir. Aquí seleccionamos Uso compartido avanzado.

Dejamos las opciones por defecto. Aceptamos. Y ya vemos bajo qué ruta de red estamos compartiendo esta carpeta

Si entramos a la máquina W10HOST001 e introducimos esta ruta en un explorador de archivos:

Despliegue de Sysmon por GPO

Todo preparado para crear a GPO. Vamos por pasos.

Script de instalación

Necesitamos crear un script que se ejecute en las máquinas para instalar Sysmon. Debemos tener en cuenta que si el script se ejecuta y Sysmon ya está instalado, lo único que debe hacer es recargar la configuración. Yo he creado un script en batch como este:

@echo off

REM Si no existe, crea carpeta C:\Sysmon\
IF NOT EXIST "C:\Sysmon" (
    mkdir "C:\Sysmon"
) ELSE (
    REM Si la carpeta existe, borra contenido 
    del /q "C:\Sysmon\*" >nul
    FOR /D %%p IN ("C:\Sysmon\*") DO rmdir "%%p" /s /q
)

REM Copia ficheros de Sysmon de ruta compartida a C:\Sysmon\
xcopy /s /e /y "\\DC01\SharedLab\Sysmon\" "C:\Sysmon\"

REM Comprueba que exista Sysmon en el sistema 
sc query Sysmon | findstr /i "RUNNING"
if %errorlevel% equ 0 (
    REM Si esta corriendo, actualizamos config
    goto updatesysmon
) else (
    REM Si no esta corriendo, instalamos
    goto installsysmon
)

REM Sección para actualizar el fichero de config de Sysmon 
:updatesysmon
"C:\Sysmon\Sysmon64.exe" -c "C:\Sysmon\sysmonconfig-export.xml"

REM Sección para instalar Sysmon
:installsysmon
"C:\Sysmon\Sysmon64.exe" /accepteula -i "C:\Sysmon\sysmonconfig-export.xml"

Crear GPO

Ya tenemos en la carpeta compartida:

• Ejecutable de Sysmon
• Un fichero de configuración en XML
• Un script para la instalación de Sysmon en la máquina

Ya podemos crear la GPO. En el DC disponemos de la herramienta «Administración de directivas de grupo«. Podéis ver todas estas utilidades en el «Administrado del servidor» en la sección Herramientas.

En esta herramienta podemos crear GPOs. Lo primero que tenemos que decidir es a qué OU le aplica. Nosotros de momento solo la vamos a aplicar a los equipos de usuario que sean SO Windows. Y recordad que acabamos de crear una OU específica para esto. Vamos al dominio y a la OU y hacemos clic derecho. Seleccionamos «Crear un GPO en este dominio y vincularlo aquí…«.

Añadimos un nombre. Yo la voy a llamar «Despliegue Sysmon Usuarios«, y no seleccionamos ninguna GPO de origen. Y con esto ya la tenemos. Podemos seleccionarla para comenzar a editarla. Para comenzar con el proceso de edición hacemos clic derecho en la política y seleccionamos

No vamos a pararnos a explicar como funciona una GPO. Vale con entender que en una GPO vamos a tener un listado gigante de configuraciones, las cuales estan deshabilitadas por defecto. Algunas de estas configuraciones aplican al usuario, y otras a la máquina. Y esto es lo que vemos cuando entramos a la edicicón de la GO.

Lo que vamos a hacer es dejar una tarea programada en las máquinas de usuario que ejecute el script que hemos prepradao para que este se encarga o de instalar Sysmon o, si ya esta instalado, actualizar con la configuración más reciente que se comparta desde el DC. Vamos po tanto a Configuración de equipo – Preferencias – Configuración del Panel de Control – Tareas programadas

Hacemos clic derecho en «Tareas programadas» y seleccionamos Nuevo – Tarea programada (como mínimo, Windows 7).

Definimos:

• En la pestaña General
  • Nombre: Despliegue Sysmon Usuarios
  • Añadimos una descricpción que permita entender que hace esta tarea
  • Que se ejecute con el usuario SYSTEM
• En la pestaña Desencadenadores
  • Añadimos uno nuevo para que se ejecute de forma diaria a las 08:00 de la mañana
• En la pestaña Acciones
  • Añadimos una nueva e indicamos que se ejecute el script

Y listo. Ya lo tendriamos.

Depurando el despliegue de la GPO

Ya tenemos la GPO preparada para que deje una tarea programada diaria en las máquinas para lanzar el script de instalación o configuración. Vale, ¿y ahora qué? ¿rezamos?

No. Vamos a comprobar que esto está funcionado. Vamos a la máquina W10HOST001 y vamos a ejecutar en una cmd con permisos de admin:

gpupdate /force

Listo. Ya se han aplicado las GPOs según están definidas en el dominio en este momento.

Podemos abrir el programador de tareas con permisos de administrador y vemos que tenemos nuestra tarea desplegada.

Y si vamos al Historial, vemos sus ejecuciones:

Conclusiones

Fijaros qué fácil lo tenemos ya para añadir nuevas máquinas de usuario a nuestro laboratorio.

• Creamos una clonación enlazada a nuestra máquina Windows 10 Template (entrada 2)
• Creamos un nuevo usuario en AD para esta máquina (entrada 2)
• Añadimos la máquina al dominio (entrada 2)
• Añadimos la máquina a la OU de equipos de usuarios Windows (visto en esta entrada)
• A esa máquina se le va a crear la tarea programada y se le va a desplegar Sysmon (visto en esta entrada)

Es más, si en cualquier momento modificamos el xml de la configuración de Sysmon que tenemos en el DC, se desplegará esta nueva configuración a todas las máquinas.

Nos vemos en el próximo