“El tema que realmente quiero que se lleve [de esta presentación] es: si realmente desea proteger su red, realmente tiene que conocer su red”. Jefe de TAO, NSA, USENIX Enigma 2016
Una parte esencial de “conocer su red” es hacer un seguimiento de los mecanismos de persistencia del endpoint, la gran cantidad de formas en las que un sistema operativo puede cargar y ejecutar automáticamente el código. Durante más de una década, los servicios en segundo plano han sido una de las ubicaciones de persistencia más utilizadas en Windows. Disponibles desde la era de Windows NT y XP, los servicios proporcionan una forma confiable de cargar discretamente procesos y bibliotecas en segundo plano tras el arranque del sistema, el inicio de sesión del usuario o las condiciones activadas. Aunque a menudo se presta mucha atención al seguimiento de técnicas de persistencia novedosas y encubiertas, es importante no perder de vista los conceptos básicos, especialmente dada la forma en que permanece el malware basado en servicios.
Mantener un control atento de los servicios del sistema que se ejecutaban en toda una empresa solía ser una tarea imposible. Hace dos años, lo último sería una auditoría mensual con un amplio análisis manual para encontrar anomalías. Hoy en día, esto se puede hacer de manera continua y automatizada utilizando la plataforma Tanium y su módulo de respuesta a incidentes.
Las herramientas de acceso remoto (Remote Access Tools, RAT) y otro malware pueden persistir como servicios de tres maneras diferentes: como ejecutables de servicio independientes, módulos de servicio alojado y componentes COM+. En esta publicación, revisaré las diferentes formas en que los atacantes abusan de los servicios de Windows y cómo Tanium puede ayudarle a detectarlos.
Servicios independientes
Los servicios independientes ejecutan un archivo ejecutable o una línea de comandos especificada en el valor “ImagePath” dentro de sus respectivas claves de registro de configuración. El registro de Windows contiene los ajustes de configuración para todos los servicios actuales bajo la clave principal “HKLM\System\CurrentControlSet\Services”.
Tanium ha proporcionado durante mucho tiempo la capacidad de monitorear los servicios de Windows a escala (en todo el inventario de Windows). El sensor “Estado del servicio con hash MD5 ”, por ejemplo, recopila y compara el nombre del servicio, el estado (En ejecución, Detenido, etc.), la línea de comandos, el hash ImagePath y el contexto del usuario en el que se ejecuta el servicio. Esto significa que los servicios independientes se destacarán con un recuento de baja frecuencia de ocurrencia si su configuración o estado es inusual o difiere entre instancias con nombres idénticos. Los usuarios de Tanium han utilizado este sensor para identificar servicios mal configurados pero legítimos en función del estado (como servicios antivirus detenidos), así como servicios fraudulentos en función de su nombre, contexto de usuario, línea de comandos o hashes ImagePath diferentes para instancias de servicio con nombres idénticos.
Desde la perspectiva del atacante, los servicios independientes no son tan populares porque la ruta ejecutable está disponible fácilmente mediante consultas de Administrador de tareas, tasklist.exe o Administrador de control de servicios. Considere a un atacante que desea ocultar malware bajo el nombre de servicio legítimo “Print Spooler”. Este servicio tiene una ruta ejecutable de “c:\windows\system32\spoolsv.exe”. Una instancia manipulada del servicio puede cargar un binario malicioso desde un nombre de archivo o ubicación con cambios sutiles, como “c:\windows\spoolsv.exe” o “c:\windows\system32\spoolsvc.exe”. Esta técnica puede ocultar eficazmente el malware del análisis “de un vistazo”, pero es fácilmente anulada por el apilamiento estadístico de ImagePath o la línea de comandos. Los sensores de Tanium como “Estado de servicio con hash MD5 ” apilarán rápidamente estos valores atípicos al borde del rebaño para el análisis y la investigación de seguimiento.
Servicios alojados y aplicaciones COM+
Los servicios alojados se implementan como bibliotecas, generalmente bibliotecas de enlaces dinámicos (Dynamic Link Libraries, DLL), en lugar de archivos ejecutables independientes. Por lo general, se cargan mediante el proceso de alojamiento de servicios de Windows, “svchost.exe”. La captura de pantalla a continuación muestra la salida del sensor “Estado del servicio con hash MD5 ” de Tanium para varios servicios alojados, como “Administración de aplicaciones” y “Motor de filtrado base”. Para cada servicio, el hash suministrado es el de “svchost.exe” en lugar del DLL alojado.
¿Cómo sabe Windows qué DLL cargar para un servicio alojado determinado? La configuración del registro para cada uno de estos servicios incluye una subclave y un valor, “\Parameters\ServiceDLL”, que apunta al DLL que se cargará. Por motivos de eficiencia y seguridad, Windows también carga los servicios alojados en grupos en instancias compartidas del proceso de alojamiento (a diferencia de generar una instancia separada de “svchost.exe” para cada uno).
Los grupos de servicio alojados se configuran bajo la clave de registro “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost”. Cada grupo proporciona diferentes niveles de acceso; “netsvcs” es uno de los grupos más privilegiados para servicios con acceso a la red y, por lo tanto, los atacantes lo utilizan con frecuencia. El valor “netsvcs” es una matriz de cadenas de nombres de servicio que se cargarán en este grupo, como se muestra en la captura de pantalla a continuación.
Los atacantes pueden abusar de los servicios alojados para cargar un DLL malicioso de varias maneras. Un enfoque es elegir un nombre de servicio alojado que sea “sin usar”, es decir, para el cual no hay servicio configurado en “HKLM\SYSTEM\CurrentControlSet\services”. Los droppers de malware podrían pasar por estas entradas no utilizadas, crear las claves de registro requeridas (incluido un parámetro ServiceDLL) y, por lo tanto, mantener la persistencia como un servicio alojado. Por ejemplo, en versiones anteriores de Windows, los atacantes a menudo apuntaban al servicio “6to4” , presente en el grupo “netsvcs”, pero a menudo inactivo sin una configuración correspondiente. El atacante podría configurar este servicio para señalar un nombre de DLL de aspecto razonable, como “c:\windows\system32\6to4svc.dll” y probablemente aprobar la inspección visual. Otro enfoque es simplemente modificar el parámetro ServiceDLL para un servicio Windows existente pero deshabilitado y, posteriormente, configurarlo para que se inicie automáticamente.
Los servicios del sistema COM+ son otra variación en el tema de los servicios alojados que pueden cargar DLL maliciosos. En este caso, el proceso “dllhost.exe” carga la aplicación COM+ que puede comprender múltiples componentes como DLL. Como ejemplo, el servicio ComSysApp enumerado en la captura de pantalla a continuación es responsable de alojar aplicaciones COM+. La línea de comandos muestra la ruta a “dllhost.exe” y un GUID de “Processid” que identifica la aplicación COM+, y dentro del código se pueden enumerar los “componentes”. Los componentes son DLL utilizados para implementar la aplicación.
Para resumir, los servicios alojados y COM proporcionan un medio encubierto y ampliamente utilizado de RAT persistentes y otro malware. Los analistas deben ir más allá del monitoreo o la revisión básica de procesos de nombres de servicios e ImagePaths, para detectar servicios que cargan DLL maliciosos.
Identificación de DLL de servicio fraudulento con Tanium
Tanium proporciona varios sensores que pueden ayudarlo a detectar y analizar fácilmente los DLL de servicio a escala empresarial. Primero, presentaremos un nuevo sensor, “Detalles del módulo de servicio”, que se incluirá en la próxima versión 3.0 de nuestra solución de respuesta a incidentes a fin de mes. La captura de pantalla a continuación muestra la salida parcial de este sensor (se omite la columna “recuento”).
Este sensor proporciona una vista apilable de los tres tipos de servicios analizados anteriormente. Tenga en cuenta la inclusión de una columna de “Ruta del módulo”, junto con el Nombre del servicio y ImagePath. Las primeras dos filas de este ejemplo muestran la ruta a dos DLL de componentes para la aplicación COM+ llamada “COMSysApp”. Todos los demás resultados están alojados por “svchost.exe” e incluyen la ruta a cada DLL de servicio respectivo. El análisis de pila de estos datos, al igual que con todos los sensores de Tanium, se realiza en tiempo real. Eso significa que puede encontrar instancias atípicas de servicios que cargan DLL fraudulentos en segundos en decenas o cientos de miles de sistemas.
Identificación de miembros fraudulentos de grupos de servicio alojados
El trimestre pasado, la actualización de respuesta a incidentes de Tanium incluyó otro sensor de análisis de servicio llamado “Auditoría de nombre de servicio alojado”. La captura de pantalla a continuación muestra un ejemplo de su salida para el grupo “netsvcs”.
La salida de este sensor es útil para inspeccionar rápidamente el conjunto de servicios dentro de los grupos de servicios a escala. Para cada grupo, la columna “Lista ordenada de nombres de servicios alojados” proporciona una lista alfabética de nombres de servicios. Esto garantiza que la salida de cada sistema “apile”; sistemas que contienen un servicio poco común dentro de un grupo, por lo tanto, se separen como valores atípicos. Por supuesto, el sistema puede tener diferentes conjuntos de servicios basados en el sistema operativo y el rol, pero hemos descubierto que la producción del sensor produce clústeres en torno a la versión del SO y los tipos de plataforma. Los usuarios de Tanium pueden usar la función “desglosar” para interrogar fácilmente el sistema con resultados atípicos o pasar a Tanium trace Trace para revisar la información forense histórica que rodea la creación de un servicio fraudulento.
¿Le interesa ver a Tanium en acción? Programe una demostración personalizada o asista a nuestro seminario web semanal. Hable con nuestros expertos de Tanium en nuestros próximos eventos.
