El malware EDR AuKill abusa del controlador Process Explorer

En los últimos meses, Sophos X-Ops ha investigado múltiples incidentes en los que los atacantes intentaban desactivar clientes EDR con una nueva herramienta de evasión de defensas que hemos bautizado como AuKill. La herramienta AuKill abusa de una versión anticuada del controlador utilizado por la versión 16.32 de la utilidad de Microsoft, Process Explorer, para desactivar los procesos EDR antes de desplegar una puerta trasera o un ransomware en el sistema objetivo.

La herramienta se utilizó durante al menos tres incidentes de ransomware desde principios de 2023 para sabotear la protección del objetivo y desplegar el ransomware: en enero y febrero, los atacantes desplegaron el ransomware Medusa Locker después de utilizar la herramienta; en febrero, un atacante utilizó AuKill justo antes de desplegar el ransomware Lockbit.

No es la primera vez que informamos sobre múltiples grupos de amenazas que despliegan simultáneamente software diseñado para matar a los agentes EDR que protegen los ordenadores. En diciembre de 2022, Sophos, Microsoft, Mandiant y SentinelOne informaron de que varios atacantes habían utilizado controladores personalizados para desactivar productos EDR.

En cambio, la herramienta AuKill abusaba de un controlador legítimo, pero obsoleto y explotable. Esta técnica se conoce comúnmente como ataque “trae tu propio controlador vulnerable” (BYOVD).

El método de abusar del controlador Process Explorer para eludir los sistemas EDR no es nuevo: se implementó en la herramienta de código abierto Backstab, publicada por primera vez en junio de 2021. De hecho, Sophos y otros proveedores de seguridad han informado anteriormente de múltiples incidentes en los que Backstab, o una versión de este controlador, se utilizó con fines maliciosos.

El pasado noviembre, por ejemplo, Sophos X-Ops informó  que un ciberdelincuente que trabajaba para el grupo de ransomware LockBit utilizó Backstab para desactivar procesos EDR en una máquina infectada. Tres meses después, Sentinel One publicó un informe sobre una herramienta que denominaron MalVirt, que utiliza el mismo controlador Process Explorer para desactivar productos de seguridad antes de desplegar la carga útil final en la máquina objetivo.

Mediante análisis y caza de amenazas, Sophos ha recopilado seis variantes diferentes del malware AuKill. Hemos encontrado múltiples similitudes entre la herramienta de código abierto Backstab y AuKill. Algunas de estas similitudes incluyen cadenas de depuración y características similares, y una lógica de flujo de código casi idéntica para interactuar con el controlador.

Creemos que el autor de AuKill utilizó varios fragmentos de código de la técnica principal introducida por Backstab, y construyó su malware en torno a ella.

Abuso legítimo de controladores y Procexp.sys

Los ciberdelincuentes se basan cada vez más en controladores para desactivar las herramientas de seguridad. Los controladores son componentes del sistema de bajo nivel que pueden acceder a estructuras de seguridad críticas en la memoria del núcleo. Como mecanismo de seguridad, Windows emplea por defecto una función llamada Aplicación de la Firma del Controlador que garantiza que los controladores del modo kernel han sido firmados por una autoridad de firma de código válida antes de que Windows permita su ejecución. Esta firma sirve como signo de confianza para verificar la identidad del software y proteger el sistema del usuario.

Para eludir esta medida de seguridad, los adversarios tienen que ingeniárselas para conseguir un controlador malicioso firmado por un certificado de confianza (como comentamos en nuestra investigación de diciembre), o (como es más habitual) abusar de un controlador de software comercial legítimo para alcanzar su objetivo, en un ataque BYOVD.

En este caso, los atacantes se aprovecharon de un controlador creado y firmado por Microsoft. El controlador Process Explorer, que forma parte de su conjunto de herramientas de administración producidas por el equipo de Sysinternals, implementa una serie de funciones para interactuar con los procesos en ejecución.

AuKill coloca un controlador llamado PROCEXP.SYS (de la versión 16.32 de Process Explorer) en la ruta C:\Windows\System32\drivers. El controlador legítimo de Process Explorer se llama PROCEXP152.sys, y normalmente se encuentra en la misma ubicación. Ambos controladores pueden estar presentes en una máquina que tenga una copia de Process Explorer en ejecución. El instalador de AuKill también deja caer una copia ejecutable de sí mismo en el directorio System32 o TEMP, que ejecuta como un servicio.

Por ejemplo, el controlador puede recibir el código de control de E/S IOCTL_CLOSE_HANDLE de aplicaciones en modo usuario, que ordena al controlador cerrar un identificador de proceso protegido, lo que provoca la finalización de un proceso.

Abusar de este proceso requiere que el atacante utilice privilegios administrativos en el sistema. Normalmente, cuando un atacante obtiene privilegios administrativos, significa que tiene control total sobre la máquina.

Sin embargo, los procesos críticos en Windows, como los clientes de endpoint, cuentan con funciones de protección adicionales para evitar que los atacantes los deshabiliten una vez que escalan privilegios. Un ejemplo de una protección adicional es el concepto de Servicios Antimalware Protegidos introducido en Windows 8.1.

Para eludir estas funciones, los atacantes tienen que ir un nivel más allá: ejecutar un controlador en modo kernel. En este caso, AuKill abusa del controlador legítimo detrás de Process Explorer para superar estas funciones.

La herramienta AuKill requiere privilegios administrativos para funcionar, pero no puede otorgar esos privilegios al atacante. Los ciberdelincuentes que utilizaron AuKill aprovecharon los privilegios existentes durante los ataques que obtuvieron por otros medios.

Análisis técnico de la evolución de AuKill

En los últimos tres meses, recopilamos seis versiones diferentes y rastreamos los cambios de funcionalidad de una versión a otra. Para simplificar, denominamos AuKill V1 a la versión más antigua del malware y AuKill V6 a la más reciente.

En particular, cambiaron el compilador y los componentes de seguridad objetivo. La Figura 1 muestra una cronología de los siguientes acontecimientos:

• La marca de tiempo de compilación de la versión de AuKill. El primer evento, por ejemplo, muestra que el binario AuKill V1 contiene una marca de tiempo de compilación de la fecha 2022-11-13.
• La fecha en que la muestra correspondiente fue escaneada por primera vez en nuestros sistemas internos. El 2022-11-17, por ejemplo, la primera vez que AuKill V1 apareció en nuestros sistemas internos.
• Para la correlación, también añadimos las marcas de tiempo en las que pudimos vincular este malware a ataques específicos de ransomware. El 2023-01-18, no pudimos obtener la muestra de AuKill utilizada en el incidente. Sin embargo, el 2023-02-14, vinculamos AuKill V1 a otro incidente, en el que los actores de la amenaza intentaron desplegar Medusa Locker.

Aunque la marca de tiempo de compilación de un archivo PE puede falsificarse, si reconstruimos el delta temporal entre el momento en que se compiló el archivo y el momento en que apareció inicialmente en nuestros sistemas, parece probable que las marcas de tiempo de compilación sean las reales.

Marcas de tiempo de compilación, hashes y objetivos de cada versión que analizamos.

Nuestro análisis se centra principalmente en las muestras etiquetadas como AuKill V1 y AuKill V6. V1 se vio en la mayoría de los incidentes, sin embargo AuKill V6 parece ser una versión experimental que introduce cambios interesantes. En las próximas secciones nos referiremos a V6 como la versión de depuración (o experimental). (Los indicadores de compromiso completos de este malware están publicados en el Github de SophosLabs).

Una comparación entre estas dos versiones ofrece interesantes perspectivas sobre la posible dirección de futuras actualizaciones.

Cuando se ejecuta, el malware comprueba primero si tiene privilegios de administrador. También requiere que el atacante ejecute el archivo con una palabra clave (o contraseña) como primer argumento en la línea de comandos. La ejecución se aborta si no se cumple alguno de estos requisitos. (El atacante necesita adquirir derechos administrativos antes de poder ejecutar la herramienta).

Para las dos muestras cubiertas en esta sección de análisis (y las seis muestras enumeradas en los COI), los atacantes necesitan pasar la cadena startkey como primer argumento de la línea de comandos.

El malware valida la contraseña/clave mediante un simple cálculo de suma aritmética. Itera un proceso en el que obtiene el valor decimal del código ASCII de cada carácter, duplica el valor, luego lo suma al valor decimal del siguiente carácter, que a su vez se duplica, y así sucesivamente.

Una vez finalizado el cálculo, se devuelve el resultado de la suma y se compara con un valor esperado codificado, en este caso 57502 (representado como el valor hexadecimal 0xE09E). La implementación en Python del algoritmo se muestra a continuación.

pwd = "startkey"
    # val end result = 0xE09E
val = 0x0
for ch in pwd:
    val += ord(ch)
    val *= 2

Figura 4: Representación en pseudocódigo Python del algoritmo de comprobación de contraseñas

Si la muestra no se ejecuta con privilegios de sistema, continúa intentando elevar sus derechos suplantando el contexto de seguridad de TrustedInstaller.exe.

En primer lugar, AuKill inicia el servicio Trusted Installer. Después duplica el token de TrustedInstaller.exe utilizando la función DuplicateTokenW WINAPI, y pasa el token a CreateProcessWithTokenW para elevarse a sistema una vez que se reinicie el proceso.

Por último, se copia a sí mismo en C:\Windows\system32, se instala como servicio e inicia el servicio.

Fase 2: Desactivar la seguridad

Una vez que el malware establece la persistencia mediante la creación de la entrada de servicio, deja caer procexp.sys en el disco. El controlador está incrustado en AuKill como recurso. Las dos versiones incluidas en este análisis dejan caer procexp.sys en C:\Windows\System32\drivers. La siguiente figura muestra el código descompilado de la V1, donde el malware lee procexp.sys de los recursos y lo escribe en el disco.

En particular, la versión de depuración también intenta conectarse a un controlador llamado WindowsKernelExplorer.sys como alternativa en caso de que no consiga soltar y cargar procexp.sys. Sin embargo, el controlador de reserva no está incrustado en los recursos como procexp.sys. Espera que este controlador, en parte, ya exista en la carpeta System32\drivers.

En este punto no podemos confirmar que el controlador del repositorio enlazado sea el que se está utilizando de forma abusiva aquí.

AuKill impide que se reinicien los servicios

Un cliente EDR suele estar formado por varios componentes que funcionan conjuntamente. Un componente puede ser (por ejemplo) un servicio instalado o un proceso en ejecución, cada uno con su propia funcionalidad. Por tanto, si uno se bloquea o finaliza, suele reiniciarse lo antes posible.

Para evitar que estos componentes se reinicien, AuKill inicia varios hilos para garantizar que estos procesos y servicios EDR permanezcan desactivados. Cada subproceso se dirige a un componente diferente y comprueba continuamente si los procesos o servicios a los que se dirige se están ejecutando. Si alguno de ellos lo está, AuKill lo desactiva o lo termina. La inicialización de estos hilos puede verse en la figura 6.

Los proveedores y servicios varían de una muestra a otra. Debajo de la figura 6, también compartimos un análisis de las diferentes funciones utilizadas para desactivar los componentes EDR que encontramos mediante ingeniería inversa.

1 – Terminar mediante Procexp

El primer tipo de función toma una lista de nombres de procesos como entrada y se llama TerminarVíaProcexp en la imagen anterior.

Recorre todos los procesos en ejecución. Si un nombre de proceso está incluido en la lista, AuKill envía el código de control IOCTL_CLOSE_HANDLE a procexp.sys para cerrar el identificador del proceso. El resultado es la finalización del proceso en cuestión.

AuKill V6 inicia dos subprocesos que ejecutan esta función. El primer hilo se dirige a una lista de procesos de seguridad relacionados con Microsoft y el segundo a una lista de varios proveedores. La mayoría de los nombres de procesos están relacionados con proveedores de seguridad. Sin embargo, el creador también incluyó una lista de nombres de herramientas de acceso remoto en la lista de objetivos.

2 – Finalizar Forzosamente

El segundo tipo de función toma como argumento una lista de nombres de procesos relacionados con vendedores y vuelve a ejecutarse en un hilo independiente. El malware itera a través de todos los procesos en ejecución y si un nombre de proceso está incluido en esta lista, AuKill intenta terminarlo forzosamente mediante TerminateProcess.

Este hilo se eliminó en la versión de depuración, pero se incluye en otras versiones, como la versión V2 de AuKill.

3 – Desactivar servicios

El tercer tipo de función se llama DisableServices en la imagen anterior, y toma como entrada una lista de nombres de servicios codificada.

Para cada nombre de servicio de la lista, AuKill comprueba si existe y, si existe, lo desactiva llamando a ChangeServiceConfigW y pasando SERVICE_DISABLED por dwStartType.

De nuevo, en AuKill V6 vemos dos subprocesos que ejecutan esta función.

4 – Descargar controladores

El último tipo se llama Descargar Controlador en la figura 6 y toma como entrada una lista de nombres de controladores codificados.

Para cada nombre de controlador, AuKill intenta descargarlo llamando a NtUnloadDriver y borrando la clave de registro correspondiente en el hive System\CurrentControlSet\Services\[DRIVER_NAME].

Solo hemos observado esta función en AuKill V6.

El abuso de controladores sigue aumentando en 2023

La desactivación de clientes EDR mediante controladores, tanto si son legítimos y se abusa de ellos con fines maliciosos (BYOVD), como si están firmados por un certificado robado/filtrado, sigue siendo popular entre los ciberdelincuentes que quieren desactivar los mecanismos de defensa.

El año pasado, la comunidad de seguridad informó sobre múltiples incidentes, en los que los controladores se convirtieron en armas con fines maliciosos. El descubrimiento de una herramienta de este tipo confirma nuestra suposición de que los adversarios siguen utilizando los controladores en armas, y esperamos que en los próximos meses se produzcan aún más avances en este ámbito.

Guía de detección

Actualmente, Sophos detecta las variantes de AuKill como ATK/BackStab-D. Además, protegemos a los clientes con detecciones de comportamiento (como la regla de comportamiento Priv_5a) contra el escenario de ataque explicado en este artículo. Estas protecciones no impiden a los usuarios ejecutar copias legítimas de Process Explorer, ni los productos de Sophos detectan o eliminan el controlador legítimo de Process Explorer cuando se utiliza normalmente.

Sophos ha notificado a Microsoft este abuso del controlador obsoleto de Process Explorer.

Por último, se pueden tomar medidas adicionales para defenderse contra el abuso del controlador:

• Es muy recomendable comprobar si tu producto de seguridad para endpoints implementa y activa la protección contra manipulaciones. Esta función proporciona una capa sólida contra este tipo de ataques. Si utilizas productos de Sophos pero actualmente no tienes activada la protección contra manipulaciones de Sophos, actívala hoy mismo.
• Practica una fuerte higiene de los roles de seguridad de Windows. Este ataque solo es posible si el atacante escala los privilegios o puede obtener derechos de administrador. La separación entre privilegios de usuario y de administrador puede ayudar a evitar que los atacantes carguen fácilmente los controladores.
• Mantén tu sistema actualizado. Como comentamos en nuestra investigación de diciembre, Windows mantiene una lista de controladores para los que Microsoft ha revocado certificados, o controladores obsoletos de los que se ha abusado históricamente, y actualiza esa lista a través del mecanismo Windows Update.
• Además de tu sistema operativo, también es importante comprobar, periódicamente, si hay actualizaciones para aplicaciones y otras herramientas en tu ordenador, y eliminar herramientas antiguas si ya no son necesarias o no se utilizan.
• El abuso legítimo de controladores también puede ocurrir si ya existe un controlador vulnerable en el sistema. Disponer de un sólido programa de gestión de vulnerabilidades puede ayudar a cerrar esas brechas de protección.

Los IOC de los archivos a los que se hace referencia en este artículo se han compartido en el Github de SophosLabs.

Agradecimientos

SophosLabs desea agradecer a Michael Wood y Felix Weyne su ayuda en la revisión técnica de este artículo.