Este artículo es la primera parte de una serie sobre el análisis de amenazas de Sysmon. Todas las otras partes de la serie:
Parte 1. Introducción al análisis de los logs de Sysmon (estamos aquí)
Parte 2. Uso de los datos de eventos de Sysmon para identificar amenazas
Parte 3. Análisis profundo de amenazas de Sysmon mediante gráficos
Si trabajas en ciberseguridad, seguramente a menudo te enfrentas a ataques en curso. Si ya tienes un ojo entrenado, puedes buscar actividades inusuales en los logs 'en crudo' — por ejemplo, un script de PowerShell ejecutando o un script de VBS disfrazado de archivo de Word, simplemente revisando la última actividad en el registro de eventos de Windows. Pero esto realmente puede ser un gran dolor de cabeza. Afortunadamente, Microsoft creó Sysmon, lo que facilita el análisis de ataques.
¿Quieres entender las ideas básicas detrás de las amenazas mostradas en el log de Sysmon? Descarga nuestra guía y te darás cuenta de cómo los insiders pueden observar sigilosamente a otros empleados. El principal problema al trabajar con el registro de eventos de Windows es la falta de información sobre los procesos padres, es decir, no se puede entender la jerarquía de los procesos. En los registros de Sysmon, por el contrario, se incluyen el identificador del proceso padre, su nombre y la línea de comandos que se está ejecutando. Gracias, Microsoft.
En la primera parte de nuestra serie, veremos qué se puede hacer con la información básica de Sysmon. En la segunda parte, aprovechemos al máximo la información sobre los procesos padres para crear estructuras de relación más complejas, conocidas como gráficos de amenazas. En la tercera parte, analizaremos un algoritmo simple que escanea el gráfico de amenazas en busca de actividad inusual mediante el análisis del 'peso' del gráfico. Y al final, como recompensa, te espera un método probabilístico preciso (y comprensible) para la detección de amenazas.
Parte 1: Introducción al análisis de los logs de Sysmon
¿Qué puede ayudar a entender las complejidades del registro de eventos? Al final, ¡SIEM! Normaliza eventos y simplifica su posterior análisis. Pero no es necesario llegar tan lejos, al menos al principio. Para entender los principios de SIEM, basta con probar la maravillosa herramienta gratuita Sysmon. Y es sorprendentemente fácil de usar. ¡Bien hecho, Microsoft!
¿Cuáles son las funciones de Sysmon?
En resumen, información útil y legible sobre los procesos (ver las imágenes abajo). Descubrirás un montón de detalles útiles que no están en el registro de eventos de Windows, pero lo más importante son los siguientes campos:
- ID del proceso (en forma decimal, ¡no hexadecimal!)
- ID del proceso padre
- Línea de comandos del proceso
- Línea de comandos del proceso padre
- Hash de la imagen del archivo
- Nombres de las imágenes de archivo
Sysmon se instala tanto como controlador de dispositivo como servicio – más información Su principal ventaja es la capacidad de analizar registros desde varios fuentes, correlacionar información y exportar resultados a una única carpeta de registro de eventos, localizada en la ruta Microsoft -> Windows -> Sysmon -> Operacional. En mis propias investigaciones de registros de Windows, las cuales son aterradoras, constantemente tenía que alternar entre, digamos, la carpeta con los registros de PowerShell y la carpeta 'Seguridad', revisando los registros de eventos en un intento heroico de correlacionar los valores entre ellos. No es una tarea fácil, y como me di cuenta más tarde, hubiera sido mejor tener aspirina a la mano.
Sysmon hace un salto cualitativo, proporcionando información útil (o como les gusta decir a los proveedores, información efectiva) para ayudar a entender los procesos fundamentales. Por ejemplo, lancé una sesión encubierta , simulando el movimiento de un insider inteligente dentro de la red. Esto es lo que verás en el registro de eventos de Windows:
En el registro de Windows se ve alguna información sobre el proceso, pero es poco útil. Además, ¿los identificadores de procesos en forma hexadecimal???
Un profesional de TI que entiende los fundamentos del hacking debería sospechar de la línea de comandos. Usar cmd.exe para posteriormente lanzar otro comando redirigiendo la salida a un archivo con un nombre extraño, claramente suena a operaciones de software con control y gestión. : de esta manera se crea un pseudo-shell utilizando los servicios WMI.
Ahora echemos un vistazo al equivalente del registro de Sysmon, prestando atención a cuánta información adicional nos proporciona:
Las capacidades de Sysmon en una sola captura de pantalla: información detallada del proceso en un formato legible
No solo puedes ver la línea de comando, sino también el nombre del archivo, la ruta del ejecutable, lo que Windows sabe sobre ello (“Processador de Comando de Windows”), el identificador del proceso padre, la línea de comando del padre, que lanzó el shell cmd, así como el nombre real del archivo del proceso padre. ¡Todo en un solo lugar, por fin!
A partir del registro de Sysmon, podemos concluir que es muy probable que esta línea de comando sospechosa que vimos en los registros 'crudos' no sea el resultado del trabajo normal de un empleado. Más bien, fue generada por un proceso similar a C2 — wmiexec, como mencioné anteriormente — y fue creada directamente por el proceso del servicio WMI (WmiPrvSe). Ahora tenemos un indicador de que un atacante remoto o un insider está probando la infraestructura corporativa.
Presentamos Get-Sysmonlogs
Por supuesto, es genial cuando Sysmon tiene los registros en un solo lugar. Pero quizás sería aún mejor si pudiéramos acceder a campos individuales del registro de forma programática, por ejemplo, a través de comandos de PowerShell. En ese caso, podríamos escribir un pequeño script de PowerShell que automatice la búsqueda de amenazas potenciales.
No fui el primero en tener esta idea. Y es bueno que en algunos hilos de foros y en GitHub ya se haya explicado cómo usar PowerShell para analizar los registros de Sysmon. En mi caso, quería evitar la necesidad de escribir líneas de script de análisis separadas para cada campo de Sysmon. Así que utilicé el principio del hombre perezoso y, como creo, al final ideé algo interesante.
El primer punto importante es que el comando puede leer registros de Sysmon, filtrar los eventos necesarios y devolver el resultado a una variable PS, como aquí:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Si deseas verificar el funcionamiento del equipo por ti mismo, puedes obtener una serie de cadenas de texto con un formato muy simple a través de la visualización del contenido en el primer elemento del array $events, $events[0].Message, que consiste en el nombre del campo Sysmon, dos puntos y luego el valor mismo.
¡Hurra! Salida del registro de Sysmon en un formato listo para JSON.
¿Estás pensando lo mismo que yo? Con un poco más de esfuerzo, se puede convertir la salida en una cadena formateada como JSON y luego cargarla directamente en un objeto PS utilizando un potente comando. .
Mostraré el código de PowerShell para la conversión, que es muy simple, en la siguiente parte. Pero por ahora, veamos qué puede hacer mi nuevo comando llamado get-sysmonlogs, que he instalado como módulo de PS.
En lugar de profundizar en el análisis de los registros de Sysmon a través de la incómoda interfaz del visor de eventos, podemos buscar sin esfuerzo la actividad incremental directamente desde la sesión de PowerShell, así como utilizar el comando PS. (alias - «?») para reducir los resultados de salida:
Lista de shells cmd, ejecutados a través de WMI. Análisis de amenazas a bajo costo con nuestro propio comando Get-Sysmonlogs.
¡Increíble! He creado una herramienta de encuesta de registros de Sysmon, como si fuera una base de datos. En nuestro artículo sobre se mencionó que esta función será realizada por la genial utilidad descrita, aunque formalmente a través de una interfaz real similar a SQL. Sí, EQL es elegante,pero lo abordaremos en la tercera parte.
Sysmon y análisis de gráficos.
Abstraigámonos y pensemos en lo que acabamos de crear. En esencia, ahora tenemos una base de datos de eventos de Windows, accesible a través de PowerShell. Como mencioné anteriormente, hay conexiones o vínculos entre los registros a través de ParentProcessId, por lo que se puede obtener la jerarquía completa de procesos.
Si has leído la serie sabes que a los hackers les gusta crear ataques complejos en múltiples etapas, donde cada proceso cumple su pequeño papel y prepara el terreno para el siguiente paso. Tales cosas son difíciles de captar simplemente desde un registro «crudo».
Pero con mi comando Get-Sysmonlogs y la estructura de datos adicional que abordaremos más adelante (por supuesto, se trata de un gráfico), tendremos una forma práctica de detectar amenazas, que solo requiere realizar la búsqueda correcta en los nodos.
Como siempre en nuestros proyectos de blog DYI, cuanto más trabajas en el análisis de los detalles de las amenazas a pequeña escala, mejor comprendes lo complicado que es detectar amenazas a nivel organizacional. Y esta comprensión es extremadamente importante.
Encontraremos las primeras y interesantes dificultades en la segunda parte del artículo, donde comenzaremos a vincular eventos de Sysmon en estructuras mucho más complejas.
Fuente: habr.com
