Mavinject es un componente legítimo de Windows que puede usarse, o abusarse, para inyectar código arbitrario en procesos que están en ejecución. Dado que es un componente habitual en Windows, puede utilizarse para ataques “Living off the Land” (Vivir de la tierra).
Del Falso Positivo al Verdadero Positivo
Uno de nuestros clientes informó recientemente de un potencial falso positivo recogido por nuestros motores. Como parte del proceso de mantenimiento, investigamos el evento para comprender mejor por qué una operación concreta estaba siendo catalogada como maliciosa por los algoritmos:
Tras varios análisis, descartamos que el evento fuese un falso positivo. Pero seguíamos intrigados por la causa que propiciaba la detección y la razón por la que un componente legítimo ejecutaría una operación como esa sobre Excel.exe.
Desde el punto de vista cronológico, mavinject32.exe realizó una inyección de código en excel.exe sólo para terminar inmediatamente tras dicha acción. Esto levantó ciertas sospechas en los motores, los cuales marcaron la operación como potencialmente maliciosa e iniciaron el seguimiento exhaustivo del comportamiento del terminal. A continuación están los detalles del proceso que desencadenó esta situación:
Ahora está claro que mavinject32.exe es un componente legítimo de Microsoft. También es interesante la línea de comandos, dado que tras un análisis preliminar, los argumentos parecen seguir la siguiente fórmula:
mavinject32.exe <PID> <PATH DLL>
12232 es, de hecho, el PID de la instancia de excel.exe ejecutándose en el terminal y la ruta corresponde a la de la DLL inyectada durante el “incidente”. El nombre “mav-inject” debería haber sido ya bastante revelador 😉. Llegados a este punto teníamos la sospecha de que podría estar siendo usado (y abusado) para inyectar DLLs arbitrarias maliciosas dentro de otros procesos.
Como primer paso, intentamos entender si Mavinject era un componente común o no; lo descubrimos en distintos terminales en la siguiente localización:
"C:\Program Files\Common Files\microsoft shared\ClickToRun\MavInject32.exe"
Además, el ejecutable podía localizarse también en otros dos directorios: Systºem32 y SysWOW64.
La descripción del archivo indica qué es este componente:
FileDescription: Microsoft Application Virtualization Injector
La aplicación es parte de Microsoft Application Virtualization (App-V). El análisis del ejecutable nos llevó al siguiente parámetro, que es muy interesante:
/INJECTRUNNING
Trabajo Previo
Antes de empezar a profundizar en la parte abusiva, reconozcamos el mérito de los que se lo han ganado. Al momento de escribir este artículo, no habíamos encontrado ningún trabajo previo relacionado con el abuso de mavinject. La única referencia que pudimos encontrar fue un tweet de @hexacorn:
mavinject(32).exe contain detour lib&can inject code to processes; APP-V related cc @mattifestation @_devonkerr_ @Carlos_Perez @subTee
— Adam (@Hexacorn) September 14, 2016
Usando Mavinject…
Tras recopilar más información de distintos clientes, identificamos un caso de uso común:
mavinject <PID> /INJECTRUNNING
El ejecutable que se lanza con esta línea de comando busca la siguiente clave de registro:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Subsystem
cuyos valores correspondientes son:
ValueName: Modules - ValueData: C:\Windows\System32\AppVEntSubsystems32.dll ValueName: Modules64 - ValueData: C:\Windows\System32\AppVEntSubsystems64.dll
Dependiendo de la arquitectura del proceso objetivo (32 o 64 bits), inyecta una DLL o la otra.
Abusando de Mavinject…
Tras los varios análisis, se hizo patente que exactamente el mismo mecanismo podía ser abusado de la forma siguiente para inyectar una DLL dentro de cualquier proceso en ejecución:
MavInject.exe <PID> /INJECTRUNNING <PATH DLL>
Aquí hay un ejemplo práctico:
Using MavInject32.exe (Microsoft Corp Signed) to load any dll in a running process.
> "C:Program FilesCommon Filesmicrosoft sharedClickToRunMavInject32.exe" <PID> /INJECTRUNNING <PATH DLL>
cc: @Oddvarmoe @Hexacorn @mattifestation @subTee @tifkin_ pic.twitter.com/9b26fP03A9
— Giuseppe `N3mes1s` (@gN3mes1s) December 14, 2017
Al poco de escribir sobre esta “característica”, la comunidad infosec respondió rápidamente combinando los descubrimientos de varios investigadores con los ampliamente conocidos frameworks de red-team o explotación:
Got a #CobalStrike agent thanks to mavinject.exe which is a Microsoft signed binary, good job to @gN3mes1s ! pic.twitter.com/0X6puBHZpn
— P-A Braeken (@pabraeken) December 14, 2017
Otro experimento interesante fue el de la inyección de una DLL en el comúnmente utilizado Sysmon 😉 :
Sysmoney!
Thanks mavinject.exe!
Details probably never. #DFIR pic.twitter.com/8YQ9GTNFY4— Casey Smith (@subTee) December 15, 2017
A parte de los descubrimientos anteriormente descritos y de lo que señalaron otros investigadores, además de la inyección, este ataque puede usarse como técnica “living off the land” dado que ofrece una función muy conveniente mediante una aplicación totalmente legítima y confiable. Lo cual hace menos probable que se disparen alarmas en comparación con la ejecución de la misma acción desde un componente externo o no reconocido.
La Defensa
ReaQta-Hive, como acabamos de descubrir, no requiere de nada más para detectar y proteger nuestros terminales frente a este ataque. Nuestros clientes pueden localizar las operaciones realizadas por mavinject directamente desde la página de Hunting. Así también pueden hacer análisis adicionales de los eventos.
Si por el contrario, en tu organización se usan frameworks de lista blanca de aplicaciones, configúralo para prohibir la carga de módulos externos.
Our engineers have found a way to inject a DLL inside any process using mavinject (Microsoft Application Virtualization Injector, signed by Microsoft), below happens during the attack from the perspective of ReaQta-Hive. Original tweet: https://t.co/NHUco6NN6A pic.twitter.com/2XxOzhw333
— ReaQta (@ReaQta) December 15, 2017
Conclusiones
El análisis de comportamiento dinámico es muy potente tal y como ha demostrado detectando comportamientos que podrían ser fácilmente descartados por un analista humano (¡tal y como hicimos en un primer momento!), dado que los sistemas aprenden de la infraestructura y por tanto disponen de visibilidad completa de todas las operaciones, lo cual es muy complejo en análisis manuales. Los comportamientos anómalos deben investigarse antes de que se conviertan en la raíz de problemas más graves. En este caso, un falso positivo nos llevó a descubrir un problema mayor del que los atacantes pueden abusar fácilmente mientras mantienen un perfil bajo. Este tipo de “vulnerabilidades” son fáciles de explotar y, sin embargo, proporcionan muchas oportunidades a los atacantes, así que disponer de visibilidad sobre toda nuestra infraestructura es un paso esencial hacia la seguridad global de la misma.