Kernel ETW es el mejor ETW

Preámbulo

Una característica crítica del software seguro por diseño es la generación de registros de auditoría cuando se realizan operaciones con privilegios. Estos registros de auditoría nativos pueden incluir detalles del estado interno del software, que no son prácticos para que los proveedores de seguridad de terceros los incorporen luego del hecho.

La mayoría de los componentes de Windows generan registros mediante el seguimiento de eventos para Windows (ETW). Estos eventos exponen algunos de los funcionamientos internos de Windows, y hay escenarios en los que los productos de seguridad de puntos finales se benefician de suscribir a ellos. Sin embargo, por motivos de seguridad, no todos los proveedores de ETW son iguales.

La primera consideración suele ser la fiabilidad del propio proveedor de eventos, en individuo, dónde se produce el registro. ¿Está dentro del proceso del cliente y es trivialmente vulnerable a la manipulación de ETW? ¿O tal vez es un poco más seguro en un proceso de servidor RPC? Sin embargo, lo ideal es que la telemetría provenga del kernel. Dado el límite de seguridad del usuario al kernel, esto proporciona garantías antimanipulación más estables que la telemetría en proceso. Este es el enfoque recomendado por Microsoft. Al igual que Elastic Endpoint, Microsoft Defender para punto de conexión también usa ETW de kernel en lugar de enlaces de ntdll en modo de usuario frágiles.

Por ejemplo, un adversario podría evitar fácilmente un enlace en modo de usuario en proceso en ntdll!NtProtectVirtualMemory, pero omitir un evento ETW de PROTECTVM del kernel es significativamente más difícil. O, al menos, debería serlo.

El registro de eventos de seguridad es, en efecto, solo almacenamiento persistente para los eventos del proveedor ETW Microsoft-Windows-Security-Auditing. Sorprendentemente, el evento de seguridad 4688 para la creación de procesos no es un evento del kernel. El kernel envía los datos al servicio de la Autoridad de Seguridad Local (lsass.exe), emitiendo un evento ETW para que lo consuma el registro de eventos. Por lo tanto, los datos podrían ser manipulados desde dentro de ese proceso del servidor. Contrasta esto con el evento ProcessStart del proveedor Microsoft-Windows-Kernel-Process, que es registrado directamente por el kernel y requiere privilegios de nivel de kernel para interferir.

La segunda consideración es la fiabilidad de la información que se registra. Es posible que confíe en el origen del evento, pero ¿qué sucede si solo registra a ciegas los datos proporcionados por el cliente que son extrínsecos al evento que se está registrando?

En este artículo, nos centraremos en los eventos ETW del kernel. Por lo general, estos son los más relevantes para la seguridad porque son difíciles de omitir y, a menudo, pertenecen a acciones privilegiadas que se realizan en nombre de un subproceso de cliente.

Cuando Microsoft introdujo la protección de parches del kernel, los proveedores de seguridad estaban significativamente limitados en su capacidad para monitorear el kernel. Dado el número limitado de puntos de extensión del kernel proporcionados por Microsoft, se vieron cada vez más obligados a confiar en eventos ETW asíncronos para la visibilidad a posteriori de las acciones del kernel realizadas en nombre del malware.

Dada esta dependencia, la documentación pública de los orígenes de telemetría del kernel de Windows es, por desgracia, algo escasa.

Eventos ETW del kernel

Actualmente hay cuatro tipos de proveedores de ETW que debemos tener en cuenta.

En primer lugar, existen variantes heredadas y modernas de "proveedor de eventos":

• Proveedores de eventos heredados (basados en MOF)
• Proveedores de eventos modernos (basados en manifiestos)

Y luego están las variantes heredadas y modernas de "proveedor de seguimiento":

• Proveedores de rastreo de preprocesador de rastreo de software (WPP) heredados de Windows
• Proveedores de rastreo modernos de TraceLogging

La distinción entre "evento" y "rastro" es principalmente semántica. Normalmente, los proveedores de eventos se registran en el sistema operativo con antelación y puede inspeccionar los metadatos de telemetría disponibles. Por lo general, los administradores de sistemas los emplean con fines de solución de problemas y, a menudo, están semidocumentados. Pero cuando algo sale muy, muy mal, hay proveedores de rastreo (ocultos). Por lo general, solo los autores del software original los emplean para la solución de problemas avanzados y no están documentados.

En la práctica, cada uno emplea un archivo de formato ligeramente diferente para describir y registrar sus eventos, lo que introduce pequeñas diferencias en la forma en que se registran los eventos y, lo que es más importante, en cómo se pueden enumerar los eventos potenciales.

Proveedores de eventos de kernel modernos

Los proveedores ETW del kernel moderno no están estrictamente documentados. Sin embargo, los detalles de los eventos registrados se pueden consultar desde el sistema operativo a través de la API auxiliar de datos de seguimiento. La herramienta PerfView de Microsoft usa estas API para reconstruir el manifiesto de registro del proveedor, y EtwExplorer de Pavel Yosifovich luego encapsula estos manifiestos en una GUI simple. Puede usar estos archivos de valores separados por tabulaciones de manifiestos registrados de versiones sucesivas de Windows. Una sola línea por evento es muy útil para grepping, aunque otros publicaron desde entonces los manifiestos XML sin procesar.

Sin embargo, estos no son todos los posibles eventos ETW de Windows. Son solo los registrados con el sistema operativo de forma predeterminada. Por ejemplo, los eventos ETW de muchos roles de servidor no se registran hasta que se habilita esa característica.

Proveedores de eventos de kernel heredados

Microsoft documenta los eventos de kernel heredados . Principalmente.

Los proveedores heredados también existen dentro del sistema operativo como clases EventTrace de WMI. Los proveedores son las clases raíz, los grupos son los hijos y los eventos son los nietos.

Para buscar los eventos heredados de la misma manera que los eventos modernosPara buscar eventos heredados de la misma manera que los eventos modernos, se analizaron estas clases y se reconstruyó el MOF original (en su mayoría). Este soporte de MOF se agregó a EtwExplorer y a los resúmenes de valores separados por tabulaciones de los eventos heredados donde se analizaron estas clases y se reconstruyó el MOF original (en su mayoría). Este soporte de MOF se agregó a EtwExplorer y a los resúmenes de valores separados por tabulaciones de los eventos heredados publicados.

El MOF de seguimiento del kernel de Windows completamente reconstruido está aquí (o en formato tabular aquí).

De los 340 eventos heredados registrados, solo se documentaron 116 . Por lo general, cada evento heredado debe habilitar a través de una marca específica, pero tampoco se documentaron. Había una pista en la documentación para los eventos de rastreo del kernel Object Manager . Mencionó PERF_OB_HANDLE, una constante que no está definida en los encabezados del último SDK. Por suerte, Geoff Chappell y el Windows 10 1511 WDK acudieron al rescate. Esta información se usó para agregar soporte para PERFINFO_GROUPMASK marcas de seguimiento del kernel a la biblioteca KrabsETW de Microsoft. También resultó que la documentación de Object Trace era incorrecta. Esa constante no pública solo se puede usar con una extensión de API no documentada. Afortunadamente, los proyectos públicos de Microsoft, como PerfView , a menudo proporcionan ejemplos de cómo usar API no documentadas.

Con los manifiestos y los MOF publicados en GitHub, la mayoría de los eventos del kernel ahora se pueden encontrar con esta consulta.

Curiosamente, Microsoft a menudo ofusca los nombres de los eventos relevantes para la seguridad, por lo que la búsqueda de eventos con un prefijo de nombre genérico como task_ produce algunos resultados interesantes.

A veces, la palabra clave insinúa el propósito del evento. Por ejemplo, task_014 en Microsoft-Windows-Kernel-General está habilitado con la palabra clave KERNEL_GENERAL_SECURITY_ACCESSCHECK.

Y, afortunadamente, los parámetros casi siempre están bien nombrados. Podríamos suponer que task_05 en Microsoft-Windows-Kernel-Audit-API-Calls está relacionado con OpenProcess , ya que registra campos llamados TargetProcessId y DesiredAccess.

Otra consulta útil es buscar eventos con un campo ProcessStartKey explícito. Los eventos ETW se pueden configurar para incluir este campo para el proceso de registro, y cualquier evento que incluya esta información para otro proceso suele ser relevante para la seguridad.

Si tenía una API específica en mente, puede consultar su nombre o sus parámetros. Por ejemplo, si desea eventos de canalización con nombre, puede usar esta consulta.

Sin embargo, en este caso, Microsoft-Windows-SEC pertenece a los controladores de seguridad de Microsoft integrados que usa Microsoft Defender para punto de conexión (MDE). Este proveedor solo está disponible oficialmente para MDE, aunque Sebastian Feldmann y Philipp Schmied demostraron cómo iniciar una sesión usando un AutoLogger y suscribir a los eventos de esa sesión. Actualmente, esto solo es útil para los usuarios de MDE, ya que, de lo contrario, el controlador no está configurado para emitir eventos.

Pero, ¿qué pasa con los proveedores de rastreo?

Proveedores de seguimiento de kernel modernos

Los metadatos de TraceLogging se almacenan como un blob opaco dentro del binario de registro. Afortunadamente, este formato fue invertido por Matt Graeber. Podemos usar el script de Matt para volcar todos los metadatos de TraceLogging para ntoskrnl.exe. Aquí se muestra un volcado de ejemplo de metadatos de Windows 11 TraceLogging.

Desafortunadamente, la estructura de metadatos por sí sola no conserva la correlación entre los proveedores y los eventos. Hay nombres de proveedores interesantes, como Microsoft.Windows.Kernel.Security y AttackSurfaceMonitor, pero aún no está claro en nuestro volcado de metadatos qué eventos pertenecen a estos proveedores.

Proveedores de seguimiento de kernel heredados

Los metadatos de WPP se almacenan en archivos de símbolos (PDB). Microsoft incluye esta información en los símbolos públicos de algunos controladores, pero no de todos. El kernel en sí, sin embargo, no produce ningún evento WPP. En su lugar, al proveedor de eventos de seguimiento del kernel de Windows heredado se le pueden pasar marcas no documentadas para habilitar los eventos de "seguimiento" heredados que normalmente solo están disponibles para los desarrolladores del kernel de Microsoft.

Próximos pasos

Ahora tenemos metadatos de eventos del kernel para cada uno de los cuatro tipos de proveedor de ETW, pero una lista de eventos de ETW es solo nuestro punto de partida. Conocer el proveedor y la palabra clave del evento puede no ser suficiente para generar los eventos que esperamos. A veces, se requiere una clave de registro de configuración adicional o una llamada a la API. Sin embargo, la mayoría de las veces, solo necesitamos comprender las condiciones exactas en las que se registra el evento.

Saber exactamente dónde y qué se está registrando es fundamental para comprender realmente la telemetría y sus limitaciones. Y, gracias a que los descompiladores están cada vez más disponibles, tenemos la opción de revertir lo suficiente. En IDA llamamos a esto "presione F5". Ghidra es la alternativa de código abierto y admite secuencias de comandos ... con Java.

Para el kernel ETW, estamos particularmente interesados en EtwWrite llamadas a las que se puede acceder desde las llamadas del sistema. Queremos obtener la mayor cantidad posible de información de los parámetros del sitio de llamada, incluida la información de símbolo público asociada. Esto significaba que necesitábamos recorrer el gráfico de llamadas, pero también intentar resolver los valores posibles para parámetros particulares.

Los parámetros necesarios eran el RegHandle y el EventDescriptor. El primero es un identificador opaco para el proveedor y el segundo proporciona información específica del evento, como el identificador del evento y sus palabras clave asociadas. Una palabra clave ETW es un identificador que se emplea para habilitar un conjunto de eventos.

Aún mejor, estos descriptores de eventos normalmente se almacenaban en una constante global con un símbolo público.

Teníamos suficientes metadatos de eventos, pero aún necesitábamos resolver el identificador de proveedor opaco asignado en tiempo de ejecución a los metadatos sobre el proveedor. Para ello, también necesitábamos las EtwRegister llamadas.

El patrón típico para los proveedores de eventos modernos del kernel era almacenar el GUID del proveedor constante y el identificador de tiempo de ejecución en globales con símbolos públicos.

Otro patrón encontrado fueron las llamadas a EtwRegister, EtwEwritey EtwUnregister, todas en la misma función. En este caso, aprovechamos la localidad para encontrar el GUID del proveedor para el evento.

Sin embargo, los proveedores modernos de TraceLogging no tenían símbolos públicos asociados por proveedor para proporcionar una pista del propósito de cada proveedor. Sin embargo, Matt Graeber invirtió el formato de metadatos de TraceLogging y documentó que el nombre del proveedor se almacena en un desplazamiento fijo del GUID del proveedor. Tener el nombre exacto del proveedor es incluso mejor que el símbolo público que recuperamos para los eventos modernos.

Esto solo dejó a los proveedores heredados. No parecían tener símbolos públicos ni blobs de metadatos. Algunas constantes se pasan a una función no documentada denominada EtwTraceKernelEvent que envuelve la llamada de escritura ETW final.

Esas constantes están presentes en los encabezados WDK de Windows 10 1511 (y en los encabezados System Informer ), por lo que podríamos etiquetar estos eventos con los nombres de las constantes.

Este script se actualizó recientemente para Ghidra 11, junto con un soporte mejorado para eventos TraceLogging y Legacy. Ahora puedes encontrarlo en GitHub aquí - https://github.com/jdu2600/API-To-ETW

La salida de ejemplo para el kernel de Windows 11 está aquí.

Nuestros eventos de Microsoft-Windows-Kernel-Audit-API-Calls previamente anónimos son rápidamente desenmascarados por este script.

Símbolo y función contenedora para eventos Microsoft-Windows-Kernel-Audit-API-Calls

Con la ruta de llamada y la información de los parámetros recuperada por el script, también podemos ver que el evento SECURITY_ACCESSCHECK de anteriormente está asociado con la API del kernel SeAccessCheck , pero solo se registra dentro de una función llamada SeLogAccessFailure. Solo las condiciones de error de registro son una ocurrencia muy común con los eventos ETW. Para fines de resolución de problemas, el caso de uso original de ETW, que suele ser el más útil, y la implementación en la mayoría de los componentes lo refleja. Desafortunadamente, por motivos de seguridad, a menudo ocurre lo contrario. Los registros de operaciones correctas suelen ser más útiles para encontrar actividad maliciosa. Por lo tanto, el valor de algunos de estos eventos heredados suele ser bajo.

La práctica moderna de seguridad desde el diseño consiste en auditar el registro de éxitos y errores de las actividades relevantes para la seguridad, y Microsoft sigue agregando nuevos eventos ETW relevantes para la seguridad que lo hacen. Por ejemplo, la versión preliminar de Windows 11 24H2 incluye algunos eventos ETW nuevos e interesantes en el proveedor de Microsoft-Windows-Threat-Intelligence . Con suerte, estos se documentarán para los proveedores de seguridad antes de su lanzamiento.

La ejecución de este script de descompilador en controladores de Windows interesantes y archivos DLL de servicio se deja como un ejercicio para el lector.