Ir al contenido principal
Explicaciones

Volvamos a lo básico: detección de servicios maliciosos de Windows con Tanium

«El mensaje que realmente quiero que retengan [de esta presentación] es el siguiente: si de verdad quieren proteger su red, tienen que conocerla a fondo». Jefe de la TAO, NSA, USENIX Enigma 2016

Una parte esencial de «conocer su red» consiste en realizar un seguimiento de los mecanismos de persistencia de los puntos finales: la gran variedad de formas en que un sistema operativo puede cargar y ejecutar código de forma automática. Desde hace más de una década, los servicios en segundo plano han sido una de las ubicaciones de persistencia más utilizadas en Windows. Los servicios, disponibles desde la época de Windows NT y XP, ofrecen una forma fiable de cargar de manera discreta procesos y bibliotecas en segundo plano al arrancar el sistema, al iniciar sesión el usuario o cuando se dan determinadas condiciones. 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 aspectos básicos, sobre todo teniendo en cuenta lo extendido que sigue estando el malware basado en servicios.

Anteriormente, supervisar de cerca los servicios del sistema que se ejecutaban en toda una empresa resultaba una tarea imposible. Hace dos años, lo más avanzado consistía en una auditoría mensual con un análisis manual exhaustivo para detectar anomalías. Hoy en día, esto se puede llevar a cabo de forma continua y automatizada mediante la plataforma Tanium y su módulo de respuesta ante incidentes.

Las herramientas de acceso remoto (RAT) y otro tipo de malware pueden persistir como servicios de tres formas distintas: como ejecutables de servicio independientes, como módulos de servicio alojados y como componentes COM+. En esta entrada, analizaré las diferentes formas en que los atacantes se aprovechan de los servicios de Windows y cómo Tanium puede ayudarle a detectarlas.

Servicios independientes

Los servicios independientes ejecutan un archivo ejecutable o un comando de línea de comandos especificado en el valor «ImagePath» de sus respectivas claves de registro de configuración. El Registro de Windows contiene los parámetros de configuración de todos los servicios activos bajo la clave principal «HKLM\System\CurrentControlSet\Services».

Tanium ofrece desde hace tiempo la posibilidad de supervisar los servicios de Windows a gran escala (en todo el inventario de Windows). El sensor «Estado del servicio con hash MD5 », por ejemplo, recopila y compara el nombre del servicio, su estado (en ejecución, detenido, etc.), la línea de comandos, el hash de ImagePath y el contexto de usuario bajo el cual se está ejecutando el servicio. Esto significa que los servicios independientes destacarán por presentar un recuento de frecuencia de aparición bajo si su configuración o estado es inusual, o si difiere entre instancias con el mismo nombre. Los usuarios de Tanium han utilizado este sensor para identificar servicios legítimos pero mal configurados en función de su estado (como los servicios antivirus detenidos), así como servicios no autorizados basándose en su nombre, el contexto del usuario, la línea de comandos o los diferentes hash de ImagePath para instancias de servicios con el mismo nombre.

Desde el punto de vista de un atacante, los servicios independientes no son tan populares, ya que la ruta del ejecutable se puede obtener fácilmente mediante el Administrador de tareas, el comando «tasklist.exe» o las consultas del Administrador de control de servicios. Imaginemos que un atacante desea camuflar un programa malicioso bajo el nombre de un servicio legítimo, «Print Spooler». Este servicio tiene una ruta de ejecución de «c:\windows\system32\spoolsv.exe». Una instancia manipulada del servicio podría cargar un archivo binario malicioso a partir de un nombre de archivo o una ubicación con cambios sutiles, como «c:\windows\spoolsv.exe» o «c:\windows\system32\spoolsvc.exe». Esta técnica puede ocultar eficazmente el malware de un análisis «a simple vista», pero se puede contrarrestar fácilmente mediante el análisis estadístico acumulativo de ImagePath o de la línea de comandos. Los sensores de Tanium, como «Estado del servicio con hash MD5 », agruparán rápidamente estos valores atípicos al margen del conjunto para su posterior análisis e investigación.

Servicios alojados y aplicaciones COM+

Los servicios alojados se implementan como bibliotecas —normalmente, bibliotecas de enlace dinámico (DLL)— en lugar de como archivos ejecutables independientes. Por lo general, son cargados por el proceso de alojamiento de servicios de Windows, «svchost.exe». La captura de pantalla que figura a continuación muestra los resultados del sensor «Estado del servicio con hash MD5 » de Tanium para varios servicios alojados, como «Gestión de aplicaciones» y «Motor de filtrado básico». Para cada servicio, el hash facilitado corresponde a «svchost.exe» y no a la DLL alojada.

¿Cómo sabe Windows qué DLL debe cargar para un servicio alojado concreto? La configuración del Registro para cada uno de estos servicios incluye una subclave y un valor, «\Parameters\ServiceDLL», que apunta a la DLL que se debe cargar. Por motivos de eficiencia y seguridad, Windows también carga los servicios alojados en grupos bajo instancias compartidas del proceso de alojamiento (en lugar de crear una instancia independiente de «svchost.exe» para cada uno de ellos).

Los grupos de servicios alojados se configuran en la clave del Registro «HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost». Cada grupo ofrece distintos niveles de acceso; «netsvcs» es uno de los grupos con mayores privilegios para los servicios con acceso a la red y, por ello, los atacantes lo utilizan con frecuencia. El valor «netsvcs» es una matriz de cadenas que contiene los nombres de los servicios que se van a cargar en este grupo, tal y como se muestra en la captura de pantalla que figura a continuación.

Los atacantes pueden aprovechar los servicios alojados para cargar un archivo DLL malicioso de diversas formas. Una posibilidad es elegir un nombre de servicio alojado que esté «sin utilizar», es decir, para el que no haya ningún servicio configurado en «HKLM\SYSTEM\CurrentControlSet\services». Los «droppers» de malware podrían recorrer estas entradas no utilizadas, crear las claves de registro necesarias (incluido un parámetro ServiceDLL) y, de este modo, mantener su persistencia como servicio alojado. Por ejemplo, en versiones anteriores de Windows, los atacantes solían centrar sus ataques en el servicio “6to4” , que forma parte del grupo «netsvcs», pero que a menudo se encontraba inactivo al carecer de la configuración correspondiente. El atacante podría configurar este servicio para que apunte a un nombre de DLL que parezca razonable, como «c:\windows\system32\6to4svc.dll», y probablemente pasaría una inspección visual. Otra forma de proceder consiste simplemente en modificar el parámetro ServiceDLL de un servicio de Windows ya existente pero desactivado y, a continuación, configurarlo para que se inicie automáticamente.

Los servicios del sistema COM+ constituyen otra variante de los servicios alojados que pueden cargar DLL maliciosas. En este caso, el proceso «dllhost.exe» carga la aplicación COM+, que puede estar compuesta por varios componentes en forma de DLL. A modo de ejemplo, el servicio ComSysApp que aparece en la captura de pantalla siguiente se encarga de alojar aplicaciones COM+. La línea de comandos muestra la ruta de acceso a «dllhost.exe» y un GUID de «Processid» que identifica la aplicación COM+, y en el código se pueden enumerar los «componentes». Los componentes son archivos DLL que se utilizan para implementar la aplicación.

En resumen, los servicios alojados y los servicios COM constituyen un método encubierto y muy utilizado para mantener activos los RAT y otro tipo de malware. Los analistas deben ir más allá de la simple supervisión de procesos o de la revisión de los nombres de los servicios y las rutas de imagen (ImagePaths) para detectar los servicios que cargan DLL maliciosas.

Identificación de DLL de servicios no autorizados con Tanium

Tanium ofrece varios sensores que le permiten detectar y analizar fácilmente las DLL de servicio a escala empresarial. En primer lugar, vamos a presentar 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 ante incidentes, prevista para finales de mes. La captura de pantalla que figura a continuación muestra una parte de los datos de este sensor (se ha omitido la columna «count»).

Este sensor ofrece una visión global de los tres tipos de servicios mencionados anteriormente. Observe que se ha incluido una columna denominada «Ruta del módulo», junto con el nombre del servicio y la ruta de la imagen. Las dos primeras filas de este ejemplo muestran la ruta de acceso a dos DLL de componentes de la aplicación COM+ denominada «COMSysApp». El resto de resultados se ejecutan a través de «svchost.exe» e incluyen la ruta de acceso a la DLL de cada servicio correspondiente. El análisis de la pila de estos datos, al igual que con todos los sensores de Tanium, se lleva a cabo en tiempo real. Esto significa que puede detectar casos atípicos de servicios que cargan DLL maliciosas en cuestión de segundos en decenas o cientos de miles de sistemas.

Identificación de miembros no autorizados de grupos de servicios alojados

El trimestre pasado, la actualización de la solución de respuesta ante incidentes de Tanium incluyó otro sensor de análisis de servicios denominado «Auditoría de nombres de servicios alojados». La captura de pantalla que figura a continuación muestra un ejemplo de los resultados obtenidos para el grupo «netsvcs».

La información proporcionada por este sensor resulta útil para inspeccionar rápidamente el conjunto de servicios dentro de los grupos de servicios a gran escala. Para cada grupo, la columna «Lista ordenada de nombres de servicios alojados» ofrece una lista alfabética de los nombres de los servicios. De este modo se garantiza que los resultados de cada sistema «se agrupen»; los sistemas que contengan un servicio poco habitual dentro de un grupo quedan así separados como valores atípicos. Por supuesto, los sistemas pueden contar con conjuntos de servicios distintos en función del sistema operativo y la función que desempeñen, pero hemos observado que los datos del sensor se agrupan en función de la versión del sistema operativo y el tipo de plataforma. Los usuarios de Tanium pueden utilizar la función de «desglose» para analizar fácilmente los sistemas con resultados atípicos, o bien pasar a Tanium Trace para revisar los datos forenses históricos relacionados con la creación de un servicio no autorizado.

¿Le interesa ver cómo funciona Tanium? Concierte una demostración e individual o participe en nuestro seminario web semanal. Hable con nuestros expertos en Tanium en nuestros próximos eventos « » ().