Threat hunting (IX): cazando sin salir de casa. Creación de procesos (III)

Buen día, ¿qué tal va la caza?

En el artículo anterior hablamos sobre dos técnicas comúnmente utilizadas para crear procesos e intentar evadir las medidas de seguridad, el PPID Spoofing y el Process Hollowing.

Aunque como se mencionó en el artículo anterior, es posible intuir que algo ha pasado mediante los eventos de Sysmon, no nos vamos a quedar ahí.

En esta entrada quiero hablaros de unos grandes desconocidos “los eventos ETW”.

ETW – Event Tracing for Windows

Los eventos ETW tienen una misión muy clara: ayudar a los desarrolladores y analistas de software a depurar y/o mantener sus aplicaciones.

Para realizar esta tarea en todos los niveles del sistema operativo, se pueden generar eventos tanto a nivel de kernel como a nivel de usuario, algo que utiliza de manera interna Windows para su depuración.

Es importante tener claro que su origen y su uso principal no está relacionado con la seguridad. Muchos eventos que serían muy útiles desde el punto de vista de un analista de seguridad no están disponibles, pero otros sí :-)

Funcionamiento de ETW

Para entenderlo mejor, Microsoft ofrece este diagrama:

Ahora hablemos de los actores que intervienen en este modelo.

Los “controladores” son los encargados de iniciarlo todo, serán quienes creen las sesiones de uno o más “proveedores”. Ellos definirán el tiempo, el tamaño, nombre… de las sesiones, y si se guardan en ficheros o no.

Ya hemos mencionado a los “proveedores”: aplicaciones que tienen implementados los mecanismos para generar eventos ETW en ciertos momentos de su ejecución. Este mecanismo de generación de eventos puede ser activado o desactivado por un controlador en cualquier momento. Una aplicación puede implementar los mecanismos para ser proveedor y controlador al mismo tiempo, de tal manera que ella misma controlará cuando genera eventos y cuando no. Los eventos generados por el proveedor son almacenados en las sesiones.

Es importante saber que las sesiones, si no son guardadas en fichero, tienen un tamaño determinado y si no se está escuchando en esas sesiones cuando se genera el evento, es posible que se pierda la posibilidad de leer dicho evento.

Los consumidores son las aplicaciones que reciben los datos de las sesiones a las que se han suscrito, ya sean leyendo ficheros de log o consumiendo los eventos en tiempo real.

Proveedores del sistema

Aunque los desarrolladores pueden implementar ETW en sus propias aplicaciones, Microsoft también lo ha hecho con Windows y existen multitud de proveedores del sistema a los que podemos subscribirnos para recibir eventos.

Algunos de los más destacables desde el punto de vista de seguridad son:

• Microsoft-Windows-Kernel-Process permite monitorizar la creación y parada de procesos, hilos y trabajos. También permite monitorizar la carga de librerías por procesos.
• Microsoft-Windows-WMI-Activity ofrece eventos relativos a WMI (Windows Management Instrumentation) muy utilizado por atacantes para ejecutar código o realizar reconocimiento en la máquina local o remota.
• Microsoft-Windows-DNS-Client ofrece información relativa a las consultas y resoluciones hechas por el equipo.
• Microsoft-Windows-SMBServer incluye eventos sobre el uso del protocolo SMB como la autenticación o el intercambio de mensajes.
• Microsoft-Windows-DotNETRuntime es muy útil para monitorizar el comportamiento de los programas .NET así como sus funciones más de moda por atacantes como la carga dinámica de código.

Herramientas

Hay varias maneras de poder generar consumidores y consultar eventos, pero la herramienta nativa para ello es “Logman”.

Otra manera de generar consumidores es la aplicación “Administración de Equipos” de Windows, dentro de la sección “Rendimiento”.

Pavel Yosifovich ha desarrollado una aplicación llamada “EtwExplorer” para inventariar y consultar todos los proveedores disponibles en el sistema, disponible en su Github.

Tiene una interfaz muy simple e intuitiva y resulta muy útil cuando se trabaja con los proveedores del sistema de Windows.

Es obligatorio cuando hablamos de eventos ETW hablar de SilkETW, una herramienta desarrollada por Fireeye y publicada en su Github hace un par de años.

SilkETW

Esta estupenda aplicación de código libre escrita en .NET, permite trabajar de una manera más cómoda con los eventos ETW, permitiendo crear consumidores y seleccionando el formato de salida.

SilkETW tiene dos modos de funcionamiento, modo ejecutable y modo servicio.

Con el modo ejecutable podemos suscribirnos a cualquier proveedor del sistema y enviar los eventos a un fichero, crear una fuente de eventos del sistema o incluso enviarlo como peticiones POST a una URL.

Es posible realizar el filtrado de los eventos por proveedor, por etiqueta o también es posible la utilización de reglas Yara para realizar un filtrado muchísimo más flexible de los resultados.

Aunque el modo de ejecución puede sernos útil para realizar pruebas, cuando se desea tener un control más detallado yo recomiendo utilizar la versión que se ejecuta como un servicio.

Una de las grandes facilidades que tiene SilkETW como servicio es que nos permite realizar filtros sobre los eventos que capturan los proveedores y mediante su fichero de configuración podemos especificar multitud de casos de uso.

Os dejo los enlaces a los artículos de Roberto Rodríguez hablando de cómo implementar esta herramienta en nuestro laboratorio. Parte 1 y parte 2.

Y por último el omnipotente Python ;-)

Python – Pywintrace

Un investigador de Fireeye desarrolló una librería en Python para poder trabajar cómodamente con eventos ETW.

Para mostrar rápidamente su potencial, quiero enseñaros un simple script que desarrolló un analista de F-Secure y que podéis encontrar en este enlace.

En este script se busca detectar la técnica de la que ya hablamos en el post anterior, el PPID Spoofing. Para ello se utiliza el proveedor del kernel de Windows “Microsoft-Windows-Kernel-Process” para analizar los eventos de la creación de procesos.

Si ejecutamos el script con privilegios elevados y volvemos a ejecutar la herramienta creación de PPID Spoofing, el script mostrará lo siguiente.

¡Nos ha cazado!

Para ello ha utilizado la correlación de los campos “ProcessID” y el campo “ParentProcessID”. El primero indica el PID del proceso que generó el evento, y el segundo el PID del padre del proceso que se pretende crear. En la mayoría de los casos debería ser igual pero como hablamos anteriormente, es necesario excepcionar al proceso “AppInfo”.

Conclusiones

La creación de procesos debería ser un punto crítico en nuestra caza, de una manera u otra, los atacantes van a necesitar realizar la ejecución de código mediante la creación de nuevos procesos y debemos conocer en profundidad este mecanismo.

Los eventos ETW no están siendo ampliamente utilizados para la detección, pero su capacidad de colocarnos en el kernel del sistema podría convertirlos en una herramienta imprescindible en la detección.

Espero que os animéis a jugar con estas técnicas y os divirtáis por el camino. ¡Feliz caza!