A menudo, durante un proceso de intrusión puede sernos de utilidad disponer de la capacidad de deshabilitar las medidas de defensa del equipo objetivo. Para aquellos pentesters que ya hayan probado las mieles de la solución de seguridad embarcada por defecto en los sistemas operativos de Microsoft, Windows Defender, estarán de acuerdo conmigo que ha mejorado sustancialmente desde sus primeras releases, en especial las últimas versiones con capacidad en nube para Windows 10. Por lo tanto, es muy probable que nos enfrentemos a este antivirus durante un proceso de intrusión, más pronto o más tarde.
De forma muy resumida, el componente principal de Windows Defender es el servicio “WinDefend”, encargado de lanzar el proceso de monitorización continua “MsMpEng.exe” y cargar su motor “mpengine.dll”, por lo tanto si somos capaces de parar ese servicio, estaremos deteniendo su ejecución en gran medida.
Para los que hayan intentado pararlo alguna vez, se habrán dado cuenta que no es posible detenerlo ni como usuario Administrador ni incluso como usuario SYSTEM.
Sí que es cierto que se puede deshabilitar, que no detener (el servicio sigue en ejecución), mediante el interfaz gráfico, pero esta opción no nos interesa dado que muchas veces nuestro malware no va a interactuar con el sistema de esta manera.
Teniendo esto en cuenta, en las siguientes líneas veremos cómo poder detener el servicio de antivirus de forma programática y presentaremos una PoC que fácilmente la podéis incluir como módulo en vuestra herramienta de postexplotacion favorita.
Para poder entender los “internals” de la acción que vamos a llevar a cabo, debemos tener claros dos conceptos: que es un Token y que es TrustedInstaller (TI).
Token
Un Token dentro del sistema operativo Microsoft Windows, es un elemento de seguridad que dota de identificación a procesos e hilos cuando estos quieren realizar acciones sobre objetos securizables del sistema (ficheros, registros, servicios…). Es decir, es como enseñar el DNI cuando se quiere entrar en la discoteca.
En él se almacenan, entre otras cosas: el nivel de integridad, el usuario al que pertenece el proceso, los privilegios y los grupos. No vamos a entrar más en detalle, ya que lo que nos importa es justamente esto último, los grupos a los que pertenece el proceso/hilo que presenta ese Token de seguridad.
Destacar que un proceso o un hilo, si dispone de los permisos y privilegios adecuados, puede hacerse pasar por otro usuario, es lo que se llama impersonar. Por lo tanto nuestra aplicación puede copiar y/o usar el token de otro hilo/proceso siempre y cuando tengamos permisos para abrir el proceso remoto y obtener el manejador de su Token con los permisos adecuados (Impersonate/DuplicateToken).
Ahora que ya sabemos que es un Token y que podemos hacer con él, vamos a presentar el segundo concepto, TrustedInstaller.
TrustedInstaller
Seguro que para aquellos que alguna vez habéis tratado de borrar algún fichero del sistema y no hayáis podido, aun siendo SYSTEM o Administrador, os habrá llamado la atención el propietario del mismo (TrustedInstaller). Pues bien, TrustedInstaller es un grupo ficticio creado por el SCM (Service control Manager) al arranque del equipo, constituyendo lo que se denomina un “Grupo de Servicio”.
Es decir, cada servicio que forma parte de un sistema operativo Windows moderno tiene un grupo ficticio que concuerda con su nombre. Esta funcionalidad es útil para poder dotar de acceso a todos los objetos securizables (ficheros, pipes, registros, tokens…) del sistema que un proceso de servicio pueda utilizar, reduciendo de esta manera el overhead introducido por la comprobación del token contra todas las DACLs del objeto.
Entonces, como hemos comentado, TrustedInstaller no solo es un grupo sino que es también un servicio, y lo podemos encontrar en la lista de servicios del equipo como tal, normalmente detenido, ya que este se arranca solo cuando “Windows Update” requiere realizar alguna actualización.
Un lector avispado en este punto pensará: pues este proceso y este grupo tienen un gran poder… Es cierto, incluso más que SYSTEM en el sistema. Nos interesa. Como curiosidad, y si queremos diferenciar entre los grupos/usuarios reales y los ficticios creados por el SCM, debemos fijarnos en el “Dominio”, que es el prefijo que aparece delante del usuario/grupo.
Normalmente los reales son precedidos por el prefijo “NT AUTHORITY” mientras que el sintético de servicio esta precedido por “NT SERVICE”.
Pero no perdamos el foco de nuestro objetivo: parar el servicio WinDefend. Veamos qué protecciones tiene.
En un sistema operativo Microsoft Windows, todo es un objeto securizable, y un servicio no lo es menos, por lo que presenta un conjunto de DACLs y permisos de protección. Veamos cuáles son:
Como se observa en la imagen anterior, la única identidad de seguridad capaz de parar el servicio de Antivirus (Full control) es él mismo y el servicio de TrustedInstaller. Tiene sentido, ya que para actualizarse, TrustedInstaller.exe debe poder parar el antivirus y copiar los nuevos ficheros. Destacar que ni siquiera el grupo Administrador o SYSTEM es capaz de hacerlo.
Como primera aproximación a nuestro objetivo podríamos pensar en tomar prestado el Token del propio “MsMpEng.exe” e impersonarlo, dado que presenta el grupo “NT SERVICE/WinDefend”, pero esto no es posible ya que este proceso es un proceso de tipo PPL (Protected Process Light) y por lo tanto no vamos a poder obtener un manejador del proceso que nos permita leer finalmente su Token, ni siquiera con privilegios de debugging (SeDebugPrivilege).
Por lo tanto, ya sabemos que solo si conseguimos un Token con el grupo TI incluido en él podremos parar el servicio de Antivirus. Nuestro siguiente objetivo es, por tanto, el servicio TI.
En primer lugar arrancaremos el servicio, siendo administradores e inspeccionaremos los permisos de apertura del proceso.
Perfecto. Parece que nos sirve, ya que para poder acceder al Token nos vale con un acceso a nivel de apertura del proceso que contenga PROCESS_QUERY_INFORMATION, PROCESS_QUERY_LIMITED_INFORMATION o PROCESS_ALL_ACCESS (Full control).
Además, destacar que este proceso no está protegido con PPL por lo que nos permitiría, a priori, llevar a cabo su apertura. ¿Cómo es posible que Microsoft no proteja un proceso tan importante en el sistema? Es una feature, no un bug ¯\_(ツ)_/¯.
Pero no es tan bonito. Requerimos del uso del privilegio SeDebugPrivilege, ya que el nivel de integridad del proceso TI es SYSTEM y la de nuestra aplicación es High, por lo que está por debajo. Recordad que para comprobar si un objeto puede acceder a otro primero se checkean los controles Mandatorios de integridad (Mandatory Integrity Control) y después los discrecionales (Discretionary access control), en este caso cumplimos el segundo de ellos pero no el primero. SeDebugPrivilege nos permite saltarnos ambos, pero solo para la apertura del proceso (OpenProcess).
Inspeccionemos ahora los permisos del Token primario del proceso TI, ya que para poder usarlo e impersonarlo, este debe de permitirnos hacerlo mediante el permiso IMPERSONATE para nuestro usuario.
Siendo Administradores vemos que no es suficiente, por lo que no vamos a poder ser capaces de leer e impersonar el Token de TrustedInstaller. Solo lo podremos hacer si somos SYSTEM, por lo tanto deberemos dar un paso intermedio y escalar privilegios de Administrador a SYSTEM.
La forma más sencilla de escalar privilegios de Admin a SYSTEM es impersonar un token de SYSTEM de un proceso ya en ejecución. Uno de los mejores candidatos es Winlogon.exe, ya que este se ejecuta en la misma sesión del usuario y además presenta ACLs relajadas al respecto (Administrador puede abrir su Token en modo IMPERSONATE).
He aquí la última puerta abierta que nos conduce al camino para parar el Defender. A modo de resumen vamos a ver la serie de llamadas al WinApi que necesitamos para conseguir nuestro objetivo.
En el siguiente enlace tenéis la prueba de concepto basada en un fork de “slyd0g” y la idea principal de “tiraniddo” modificada en la consecución del token de System. Posiblemente, ni siquiera estos autores sean los intelectuales originales, no obstante, tiren de sus referencias para más info.
https://github.com/lab52io/StopDefender
Lo bueno de esta técnica es que el Defender no vuelve a la vida hasta que alguna de las tareas siguientes se ejecuta (unas 24h). Si quisiéramos deshabilitarlo por completo hasta el siguiente reinicio tan solo habría que deshabilitarlas como TI, ejercicio que se le deja ya al lector.
Por último, destacar que hay otras múltiples formas de poder obtener un token de TrustedInstaller, que implican cambios en cuanto a cómo conseguir el token de System, incluso llegando a forjar un token que presente este grupo sin llegar a necesitar robárselo al proceso TrustedInstaller.exe. No obstante, esta me parece la más directa y sencilla, sin requerir la modificación de servicios.
Happy hacking!
Referencias
- https://github.com/slyd0g/PrimaryTokenTheft
- https://posts.specterops.io/understanding-and-defending-against-access-token-theft-finding-alternatives-to-winlogon-exe-80696c8a73b
- https://www.tiraniddo.dev/2017/08/the-art-of-becoming-trustedinstaller.html
- https://docs.microsoft.com/en-us/windows/win32/com/impersonation-levels
- https://halove23.blogspot.com/2021/08/executing-code-in-context-of-trusted.html
- https://docs.microsoft.com/es-es/windows/win32/api/winsvc/ns-winsvc-service_sid_info?redirectedfrom=MSDN
Matización a la frase:
“En un PPL (Protected Process Light) no vamos a poder obtener un manejador del proceso que nos permita leer finalmente su Token, ni siquiera con privilegios de debugging (SeDebugPrivilege).”
Destacar que sí es posible disponer de un manejador de un proceso PPL si se abre con QUERY_LIMITED_INFORMATION y poder acceder a la abertura de su token. Ahí ya dependerá de los permisos del propio token y para que lo queremos abrir. Lo veremos en el próximo post.