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

Cuándo un Bypass de UAC en Windows es un "Bug" o una "Feature"

El artículo de hoy lo escribo por algunas razones, las cuales comentaré en breve. El punto para reflexionar es: ¿Qué es un bypass de UAC? Para muchos una técnica desprestigiada en un Ethical Hacking, para otros una vía a tener en cuenta en la obtención de privilegios o la obtención de una shell en un nivel de integridad alto de Windows.  Puedo equivocarme en lo que comente en este artículo o puede que tengas otra visión, pero vamos a ir viendo y matizando ciertos aspectos que cubren a esta técnica. 

Figura 1: Cuando un Bypass de UAC en Windows es un "Bug" o una "Feature"

Lo primero, y seguramente más importante, ¿Es una vulnerabilidad? Para Microsoft no es una vulnerabilidad, es una opción de configuración. Y, técnicamente, es cierto. Es decir, si cambias la configuración por defecto del UAC, la inmensa mayoría de los bypasses conocidos dejan de funcionar. El mecanismo de UAC funciona, solo que depende de su configuración. 

Figura 2: Máxima Seguridad en Windows Gold Edition

Por supuesto, si lo que quieres es aplicar Máxima Seguridad a tu Windows, esto es algo que se aplica en primer paso. Es decir, quitar la configuración por defecto y aplicar la que exige a todos los binarios la confirmación UAC, y no permite el autoelevado. Vamos un poco más allá para entenderlo. ¿Cómo nos protegemos de los bypasses de UAC? Vamos primero a ver la GPO, para lo que buscamos: 

Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode

Ahí encontraremos uno de los motivos por los que los bypasses de UAC funcionan. Como se puede ver en la imagen, se pedirá consentimiento, por parte del UAC, solo a los procesos que no sean binarios de Windows. Realmente, hay un mayor detalle en esto que comentaré a continuación.

Figura 3: Política para UAC para los binarios que no son de Windows

Aparte de ser un “binario de Windows”, que esto no es más que se encuentre firmado por Microsoft, éste debe ser además un binario con una directiva en el Manifest con “Auto-Elevate”  con valor "True". Es decir, le están diciendo al sistema que el binario, aparte de estar firmado por Microsoft, éste tiene una especie de “carnet especial” o “pase especial” y que no debe rendir cuentas al UAC. 

Por último, otra de las comprobaciones que hace el sistema es que el binario se esté ejecutando en una ruta “privilegiada”, por ejemplo, System32. Si recordamos el bypass de UAC de Mocking Directory Trusted, gracias a un fallo de interpretación de una de las APIs internas del sistema se podía “saltar” esta protección.

Figura 4: Libro de Hacking Windows

Desde el punto de vista del pentesting tenemos que tener en cuenta algunas cosas también. Lo que parece más lógico, pero que a veces la gente puede no entender bien es que, para pasar a un nivel de integridad alto, debes de estar en otro nivel de integridad, inferior se entiende. 

En el caso de un bypass de UAC debes partir desde un nivel de integridad medio. Por esta razón, el módulo de Metasploit, cuando se hace cualquier bypass de UAC de forma automática, nos muestra los diferentes chequeos, entre ellos el nivel de integridad actual.

Figura 5: ByPass de UAC en Metasploit

Como se puede observar, una de las cosas que se chequean es el nivel de integridad. Si estuviéramos en un nivel de integridad alto y no nos hubiéramos dado cuenta, sería una cosa muy extraña, porque demostraríamos no tener el control de lo que hacemos, pues ya estaríamos “elevados”, por lo que no tendría sentido realizar esta operación. Puede que nuestro proceso no se encuentre en un nivel de integridad medio y estemos más abajo, tendremos problemas también. Debemos entender por qué estamos y debemos estar en este nivel de integridad.

Esto va relacionado con el tipo de usuario que debemos ser. Solo podemos ser un usuario que forme parte del grupo administradores, pero que no esté ejecutando el proceso como administrador. Esto es importante. Es otra cosa que a veces no queda clara. 

Figura 6: Metasploit para Pentesters Gold Edition

Necesitamos que un usuario que tiene privilegios para realizar acciones como administrador, haya ejecutado un proceso y que no haya hecho uso de dichos privilegios para, una vez comprometido su proceso, podamos aprovechar este hecho y hacer el bypass de UAC. Puede ser lioso, pero es lógico. Si el usuario hubiera lanzado el proceso como administrador, el nivel de integridad ya sería alto, no medio.

Como se veía en la imagen anterior, el módulo de Metasploit comprueba si el usuario al que pertenece el proceso comprometido es o no es del grupo administradores. Si no es del grupo administradores, ¿Qué ocurre? Es sencillo, la política de comportamiento del UAC asociada es diferente. Tal y como se puede ver en la imagen, la acción por defecto para un usuario que no pertenece al grupo administradores es que el UAC pida credenciales.

Figura 7: Selección de opción de pedir credenciales

Windows Vista, en el comienzo de la historia del UAC, utilizaba un comportamiento más estricto, pedía confirmación (Sí o No) para los administradores, independientemente de si el binario estuviera o no firmado por Microsoft o si tenía o no Auto-Elevate. 

Figura 8: Configuraciones de los Modos UAC en Windows 7

¿Era más seguro? A priori, y basándonos en este artículo, sí. Pero las quejas llegaron. Los usuarios no estaban preparados para ello y se rebajaron algunas configuraciones. Esto fue en Windows 7, si no recuerdo mal, que puedo recordarlo mal.

Y un bypass de UAC entonces, ¿dónde tiene sentido?

Yo siempre digo en las clases o en los cursos/talleres que un bypass de UAC se enseña en local, pero su aplicación tiene sentido en remoto. Es decir, por motivos de divulgación y educación se puede enseñar en local todo el proceso de lo que ocurre, no solo quedaros con se lanza un módulo de Metasploit y listo, eso es la automatización y está bien, una vez que se conoce qué ocurre por detrás. 

Miramos con ProcMon y Proccess Explorer lo que ocurre, se estudian diferentes técnicas: Environment Injection, DLL Hijacking, Fileless… O jugamos con nuestro querido UAC-A-Mola y vemos qué cosas se pueden hacer.


Figura 9: UAC-a-Mola: Bypassing UAC using Fileless techniques
Pero a la hora de poner en práctica o de utilizar en un Ethical Hacking solo tiene sentido en remoto, porque si tienes un usuario que cumple los requisitos del bypass de UAC y tienes acceso físico te vale ejecutar:

 “botón derecho -> Ejecutar como administrador” 

Bien, pero ¿cómo hacemos eso en remoto? Es complejo. Vamos a tener una shell remota con la que podemos ver fácilmente si tenemos la posibilidad de utilizar técnicas de bypass de UAC y si estamos en ese caso, ¿cómo se aplican? ¿Ejecutas botón derecho -> admin? No. No puedes. Aquí es dónde tiene todo el sentido del mundo las técnicas de bypass de UAC.

Desde una shell invocarás a un binario que cumple las tres necesidades comentadas anteriormente, previamente habrás preparado el camino para que la ejecución de dicho binario desemboque en que el nuevo proceso haga uso de tu código, y como ese proceso se estará ejecutando en un nivel de integridad alto, tu código también se ejecutará en el mismo nivel de integridad.

Ahí tenemos el bypass, porque gracias a las características del binario, el UAC dejará ejecutarlo. Y en esto se resume. Hemos hablado mucho en este blog sobre diferentes bypasses de UAC, cómo han ido evolucionando las técnicas, cómo a veces se simplificaban y ahí están los artículos

Para mí: ¿Qué no es un bypass de UAC?

Si desde la GUI de cualquier binario se puede ejecutar código, pero no se puede hacer a través de una consola, para mí no es un bypass de UAC efectivo. Puede que, técnicamente se haga un bypass de UAC, porque evitemos que se ejecute el UAC y se ejecute un código nuestro. ¿Nos aporta algo más que darle al botón derecho -> "ejecutar como administrador"? Eso es lo que nos tenemos que preguntar, es decir, ¿podremos utilizarlo?

Aquí tenemos una bifurcación: bypass de UAC efectivo para el pentesting o bypass de UAC que prueba un concepto, pero no es efectivo para el pentesting. Como ejemplo podemos utilizar algunos ejemplos con interfaces gráficas.

Técnicamente, lo que veremos ahora consigue hacer que un CMD se ejecute y no salte el UAC. Sabemos que cuando se intenta ejecutar una CMD con privilegio, el UAC saltará para confirmación del usuario o petición de credenciales en el caso de un usuario que no sea del grupo administradores. Tenemos que pensar, ¿se puede usar en un pentest? Eso es más complejo.  Lo primero es utilizar un binario de los que sabemos que ejecutan en un nivel de integridad alto sin que el UAC salte, por ejemplo, el eventvwr.exe en Windows 10.

Figura 10: EventViewer tiene Auto-Elevate True

Desde aquí, todo lo que sea código que se ejecute heredará el nivel de integridad alto, por lo que podemos ir al menú “Help”. La opción “Help Topics” nos muestra la ayuda del visor de eventos. Pinchando con el botón derecho en la parte donde se muestra el texto se puede ver una opción que es “View Source”.

Figura 11: View Source

Al ejecutar “View Source” se ve un bloc de notas con un texto. Claro, si analizamos el bloc de notas con Proccess Explorer podremos ver que el notepad.exe se ejecuta en un nivel de integridad alto. Aquí ya tenemos lo que buscamos, si abrimos un cuadro de diálogo tenemos la posibilidad de ejecutar lo que se quiera.

Figura 12: notepad.exe con nivel de integridad alto

Abrimos el cuadro de diálogo y buscamos en System32 el binario del CMD. En vez de abrirlo sobre el notepad.exe, botón derecho y abrir el cmd.exe. Ahí lo tenemos. ¿Podríamos haberlo hecho a través de una shell? Si encontramos la forma de hacer que todo esto se pueda hacer desde una línea de comandos, tendríamos, desde mi opinión, un bypass de UCA efectivo, si no, simplemente hemos demostrado o enseñado que hay código que puede ser ejecutado sin que el UAC salte, pero no termina de ser efectivo en un pentesting o en un Ethical Hacking.

Figura 13: CMD.exe elevado sin UAC

En la siguiente imagen de Process Explorer se puede ver el nivel de integridad y cómo desde el mmc.exe (abierto con eventvwr.exe directamente) sin que el UAC salte, porque es un binario que cumple las condiciones comentadas anteriormente, se van abriendo diferentes procesos hasta llegar a una cmd.exe.

Figura 14: Nivel de Integridad "High"

Vale, pero, ¿es efectivo? Cuando se lee bypass de UAC, una de las cosas que debemos valorar es efectivo o no. Generalmente, cuando hablamos de bypass de UAC entendemos que es una vía por la que se obtiene privilegios saltándonos el UAC y nunca a través de algo gráfico, porque no habría diferencia con “botón derecho -> ejecutar como admin”. El debate está servido. Tú decides.

Saludos,

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",  “Pentesting con Powershell” 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

Figura 15: Contactar con Pablo González

CrackMapExec: Una navaja suiza para el pentesting (2 de 2)

Vamos a continuar la segunda parte de este artículo, viendo alguna cosa más que podemos realizar en un Ethical Hacking de un sistema Windows utilizando CrackMapExec. En esta parte vamos a ver cómo podemos hacer un Credential Dumping, o lo que es lo mismo, el volcado de usuarios, hashes y contraseñas, cómo podemos utilizar WMI para la ejecución remota de comandos y cuáles son los módulos que podemos utilizar en la herramienta.

Figura 11: CrackMapExec: Una navaja suiza para el pentesting (2 de 2)

Como ya hemos dicho, CME es una navaja suiza para el pentesting con muchas posibilidades, y por supuesto se complementa con las utilidades que podemos utilizar en un entorno de post-explotación dentro de un Pentesting con PowerShell, o de las cosas que podemos hacer como Metasploit. Es decir una herramienta más en nuestra mochila de pentesters.

Figura 11: Metasploit para pentesters Gold Edition

Credential Dumping

Cuando uno tiene privilegios en la post-explotación siempre necesitará obtener credenciales para poder volver a las máquinas comprometidas o poder moverme lateralmente a otras máquinas.  CME proporciona diferentes parámetros, incluso diferente técnicas, para llevar a cabo el volcado de credenciales. En la siguiente imagen vamos a ver cómo hacer un volcado de credenciales de la SAM, de LSA y de NTDS. Con este último, se pueden utilizar diferentes técnicas, se recomienda leer la documentación de la herramienta, ya que con detalles como estos, gana muchos puntos. 

Figura 12: Pidiendo el volcado de la SAM

Pero, volvemos al movimiento lateral. Antes hemos utilizado credenciales en plano que, por supuesto, se pueden logran en un Ethical Hacking, pero lo suyo es ver en acción el uso de, por ejemplo, hashes NTLM. Si hay un libro que explica en detalle todos los sistemas de autenticación que están disponibles en Windows y cómo gestiona su seguridad el sistema es el libro de Máxima Seguridad en Windows Gold Edition de nuestro compañero Sergio de los Santos que os recomiendo sin duda.

Figura 13: Máxima Seguridad en Windows Gold Edition

Si tenemos un hash NTLM se puede hacer uso de éste con el parámetro -H. Se puede probar de manera rápida el comando crackmapexec -u [usuario] -H [hash NTLM] y ver que la autenticación funciona. 

Figura 14: Comprobando que el hash funciona  

Para ver que la autenticación con hash funciona y que podemos ejecutar acciones, módulos y comandos remotos se añade el parámetro --users, como hicimos anteriormente, para ver que el resultado es el mismo. Es decir, funciona.

Hacemos uso de WMI y la ejecución de comandos remotos
Con el parámetro -x podemos hacer invocaciones de comandos, con diferentes técnicas, una de ellas sería a través de WMI. El servicio Windows Management Instrumentation o WMI provee de un lenguaje de instrumentación del sistema operativo que, como os podéis imaginar, es muy utilizado en la fase de post-explotación, ya que permite realizar un gran número de acciones en este momento del pentesting. 

Por ejemplo, vamos a utilizar el parámetro --wmi seguido de la consulta WMI entrecomillada, tal y como se puede observar en la imagen. El resultado es similar al del uso del parámetro --users. 

 

Figura 15: Probando WMI

Es importante probar el uso del parámetro -x y el comando que se quiere ejecutar, ya que es fácil ejecutar comandos de terminal a través de este protocolo. Esto puede acabar provocando que algo más potente se ejecute lateralmente, por ejemplo… ¿Un Meterpreter? ¿Una iBombShell? ¿Un Empire?

Módulos en CrackMapExec
Para listar los módulos, como se comentó anteriormente, se puede hacer uso del parámetro -L, indicando previamente el protocolo que queremos utilizar. Como se puede ver en la imagen, CME tiene una gran cantidad de módulos de diferente índole: enumeración, volcado de credenciales, ejecución de código, recogida de configuración, etcétera. 

Figura 16: Listado de módulos en CME

 
Como una pequeña prueba se ha ejecutado el módulo de User Account Control. Este módulo lo que devuelve es la configuración del UAC en el sistema.

Figura 17: Accediendo a info de UAC

Otras opciones interesantes son: 

- Módulo de Mimikatz. Opción -M mimikatz.

  

- Mimikatz y el parámetro -o con el que se indica COMMAND=’[Comando Mimikatz]’. Es decir, se ejecuta el comando Mimikatz que queramos. Por ejemplo:

crackmapexec smb [IP] -u administrator -H [hash ntlm] -M Mimikatz -o ‘sekurlsa:logonPasswords’.

Esto ejecutaría Mimikatz y éste intentaría volcar todas las credenciales de lsass.exe.  

- El módulo de Web_Delivery está presenta también para invocar un Meterpreter a través de Powershell, directamente a memoria. Aquí es posible que, previamente hubiera que hacer bypass AMSI. Pero con PowerShell decides tú el límite.

Figura 18: Libro de Pentesting con PowerShell 2ª Edición

- El módulo de wdigest también es interesante, ya que permite habilitar el proveedor de autenticación wdigest a través de la manipulación de una clave de registro. La instrucción sería: crackmapexec smb [IP] -u administrador -H [hash ntlm] -M wdigest -o ACTION=enable.

Sin duda, una interesante herramienta que aporta bastante opciones en un pentesting. Otra herramienta que debemos meter en la mochila del pentester y con muchas opciones para tener éxito en nuestro trabajo.

 
Saludos,

*****************************************************************************

- CrackMapExec: Una navaja suiza para el pentesting (1 de 2)

- CrackMapExec: Una navaja suiza para el pentesting (2 de 2)

*****************************************************************************

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",  “Pentesting con Powershell” 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

Figura 19: Contactar con Pablo González

Xencrypt: Evasión en Windows 10 con Powershell usando cifrado AES

Los investigadores Xentrooy y SecForce han publicado un crypter en Powershell. Es un proyecto bastante nuevo, ya que si se ve el Github consta de pocos días. Llamó mi atención, ya que todo lo que es Powershell me llama la atención, debido a que los amigos de HackPlayers publicaron un interesante artículo.

Figura 1: Xencrypt: Evasión en Windows 10 con Powershell usando cifrado AES

Sin duda Xencrypt propone una solución interesante al juego de siempre, el juego de la evasión. El gato y el ratón. El que detecta con el que intenta no ser detectado. Como digo siempre en las clases, las protecciones mejoran y otros intentan evadirlas, con el objetivo de mejorar la protección. Este es el juego de la ciberseguridad, en cualquier protección que se precie.

PowerShell para Atacantes

Además, quería probar esta funcionalidad y herramienta, ya que creo que es un factor interesante, todo lo que es la evasión de protecciones. Viendo que me queda poco tiempo para el taller de Rooted Lab el día 3 de marzo sobre Offensive Powershell. Un taller donde le daremos ‘cera’ a Windows 10 y la Powershell. Había que probarlo e incluirlo.

Figura 4: Libro de Pentesting con PowerShell 2ª Edición de Pablo González

En otras palabras, Xencrypt proporciona un crypter que permite llevar a cabo la ofuscación de scripts y código para evitar su detección. La idea de Xencrypt es poder generar infinitas formas diferentes, es decir, tener diferentes scripts para ejecutar lo mismo que permiten la no detección por parte de un antivirus. Xencrypt es un crypter de Powershell, el cual utilizar cifrado AES y compresión GZip. Cada vez que se invoca se genera un script nuevo, con una salida o ejecución igual a lo que se quiere. En definitiva, como bien dicen los autores de la herramienta, es esencia es para Powershell un PE Crypter.

Figura 3: Xencrypt en GitHub

En otras palabras, con cada ejecución de Xencrypt, lo importante, es el gran número de variantes de script que se genera. Es decir, si tenemos un Mimikatz en Powershell, el cual es ‘cazado’ por el antivirus, se puede pasar por Xencrypt y la salida de la ejecución será un nuevo código de Mimikatz ofuscado y cifrado. Cuando lo llevemos al equipo dónde antes se detectaba, la probabilidad de que lo detecte el antivirus habrá disminuido.

Probando Xencrypt

Lo primero era hacer una prueba con el propio script de Powershell. Si lo cargamos directamente en una Powershell con Windows 10 puede que nos salte el antivirus, ya que este código ya es detectado, por lo que se puede probar, pero hay que tenerlo en cuenta. Si vamos a una Powershell en un Windows 7, AMSI no estará para poder detectarlo.

La ejecución de la función Invoke-Xencrypt es muy sencilla. Tiene tres parámetros. El parámetro infile indica que el fichero de entrada. El parámetro outfile refleja el fichero de salida, el cual estará ya cifrado y ofuscado. El parámetro iterations indicará el número de iteraciones que se realizará. Este es uno de los factores que hacen que las variantes de la salida sean casi infinitas.

Figura 4: Función Invoke-Xencrypt

A continuación, se puede ver la salida del script prueba.ps1. El código hace lo mismo que el de entrada, solo que tiene un aspecto bastante diferente. En tiempo de ejecución se llevará a cabo un descifrado de la acción y realizará una ejecución del código. Se intenta evitar que palabras clave, rutas claves y etiquetas claves sean detectadas por AMSI.

Figura 5: Salida del script prueba.ps1

Las características que indican los autores y que son muy interesantes sobre esta herramienta son las siguientes:

• Evasión de AMSI y AV modernos. 

• Comprime y cifra scripts. 

• El overhead es mínimo, incluso negativo. 

• Variables aleatorias. 

• Cifrado aleatorio con máxima entropía. 

• Capas recursivas (o iteraciones) hasta 500.

Es fácil de modificar, quizá sea el punto más interesante, para poder crear una variante propia y que mejore la evasión en un momento determinado. Probando el prueba.ps1 con diferentes motores de antivirus, la salida es más que interesante.

Figura 6: Script ofuscado bypasseando frimas de AV

Por supuesto, hay que probarlo en Windows 10 con el AMSI y las posibilidades que este ofrece. Ya hemos hablado en este blog sobre AMSI y diferentes técnicas de bypass y que nuestra iBombshell ya implementa. Al final, esto es probar, probar y probar en busca de la evasión. El Ethical Hacking es así.

Saludos,

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",  “Pentesting con Powershell” 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

Figura 11: Contactar con Pablo González

Named Pipe Impersonation: Escalando privilegios en Windows

Cuando te enfrentas a una escalada de privilegio en un pentesting dentro de un Ethical Hacking existen diferentes formas de afrontar este problema. La búsqueda de fallos en la configuración de los servicios, la búsqueda de la falta de paquetes de actualización en Windows mediante herramientas como Windows Exploit Suggester o el aprovechamiento de una vulnerabilidad en un instante de tiempo, ya sea porque tiene poco tiempo o porque no ha sido parcheada, como puede ser Hot Potato y su implementación en Powershell con Tater.

Figura 1: Named Pipe Impersonation: Escalando privilegios en Windows

Sin duda, la post-explotación puede ser una tarea ardua, aunque en algunas ocasiones nos parezca algo "sencillo". Hoy quería hablar del funcionamiento de la técnica Named Pipe Impersonation y cómo puede ser detectada gracias al registro de eventos de Windows. Este tipo de técnicas y otras se podrán conocer en el lab de Metasploit de Rooted CON 20018 - si te apuntas  y te has leído el libro de Metasploit para Pentesters 4ª Edición antes, podrás sacar lo máximo del training.

¿Qué es Named Pipe Impersonation?

Lo primero que hay que decir es que es una técnica utilizada dentro del framework de Metasploit, aunque también podría ser utilizada fuera de dicho contexto. Es una técnica que permite escalar privilegios. Un named pipe es una técnica que tiene el sistema operativo Windows para facilitar la comunicación entre procesos. Es sencillo, si un proceso quiere "contactar" con otro, el primero de los procesos puede enviar un mensaje sobre la red o utilizar un fichero. En el segundo caso, el proceso escribe el mensaje en un fichero y el otro proceso lo lee.

Esta es la base de la técnica Named Pipe, por lo que, si se mira desde el punto de vista de un pentester, ésta puede ser utilizada para lograr un objetivo como el de ejecutar un código en un contexto privilegiado. Hay que tener en cuenta que el malware NotPetya utilizaba un nuevo proceso para comunicarse con el malware y hacer un dumpeo de credenciales. Este proceso utilizaba esta técnica para utilizar una comunicación encubierta, entre el proceso y el malware.

¿Qué significa realmente "impersonar" un Named Pipe?

Imagina un servidor y un cliente. El cliente solicita al servidor que realice alguna acción, por ejemplo, una consulta a la base de datos. El servidor puede tener control total sobre la base de datos, pero, por el contrario, el cliente puede tener un acceso limitado. Si el cliente no tiene los suficientes privilegios, el servidor nunca le dará o ejecutará la consulta que éste pueda solicitar. Hasta aquí, todo claro.

¿Qué ocurre si el cliente tiene más privilegios que el servidor? Tú puedes pasar este hecho, es decir, estos privilegios al servidor para que utilice dichas credenciales. El servidor puede "impersonar" la cuenta del cliente para realizar las acciones que requiera. Esta idea es la utilizada en el contexto del named pipe, es decir, si un proceso crea un pipe, este proceso será propietario del pipe server. Cuando otro proceso conecta a este pipe, éste llamará al pipe client. Una vez ambos conecten, el pipe server puede utilizar el privilegio del pipe client, el contexto de seguridad en el que se ejecuta el cliente o los privilegios que éste tiene.

Figura 2: Namedpipe.c en Meterpreter

Este hecho puede ser aprovechado para crear un pipe server con bajos privilegios e intentar conectar con un cliente con más privilegio que el pipe comentado. Cuando esto sucede, el pipe server podrá realizar acciones con los privilegios del cliente. Metasploit simplifica este hecho y lo automatiza a través del comando Getsystem del Payload Meterpreter. El código se puede encontrar en el Github del proyecto.

Profundizando un poco más

La idea está clara, pero ¿cómo interactúa realmente? Getsystem, cuando utiliza la técnica Named Pipe Impersonation, crea un pipe server con privilegios limitados. Posteriormente, configura un servicio en Windows, el cual será el cliente, para conectarlo a ese pipe. De esta forma se "impersona" el contexto de seguridad, ya que un servicio se ejecutará en un contexto de SYSTEM.

Como se puede ver en la documentación del código que implementa la técnica en el Github de Metasploit, se ejecutará una cmd.exe bajo un contexto de SYSTEM para que conecte al named pipe y se "impersonará" a este cliente. Esto puede ser llevado a cabo cuando se es Administrador sin la necesidad de tener el permiso SeDebugPrivilege. Esta técnica trabaja con Windows 2000/XP/2003 y 2008. En Windows Vista y Windows 7 solo trabaja si el proceso ha sido elevado a través de UAC o con un bypass de UAC. En versiones más modernas del sistema operativo también sigue funcionando.

Figura 3: Elevación de privilegios a SYSTEM para hacer la impersonación

En el caso de que la técnica no tenga éxito, se intenta un método similar llamado named pipe impersonation 2. En este caso, Meterpreter subirá una DLL al equipo y la ejecuta por medio de rundll32.exe, haciéndolo como servicio. La DLL se ejecutará en el contexto de SYSTEM y conectará con el pipe server para "impersonar" el token.

En la imagen, se puede ver como se obtiene una sesión en la que hay un token con la identidad y el privilegio del proceso.

Figura 4: Obtención de sesión con privilegios

El comando getsystem tiene diferentes técnicas implementadas para llevar a cabo la escalada de privilegio. Se utiliza la opción 1 para utilizar la técnica Named Pipe Impersonation, aunque la técnica 2 utiliza el mismo procedimiento, solo que hay que hacer la parte de la DLL en disco y la ejecución a través de la invocación del servicio y rundll32.exe.

Como se puede ver en la imagen, se utiliza la opción "-t 1" para seleccionar la técnica de Named Pipe Impersonation, explicada anteriormente.

Figura 5: Con -t 1 se configura Named Pipe Impersonation

En resumen, y para simplificar el entendimiento de la técnica, se ejecuta un proceso el cual se está ejecutando con el token, el cual tiene limitados los privilegios. El proceso creado genera un pipe con un nombre aleatorio. En este ejemplo se llama gbsbtr el pipe. El pipe es creado con el privilegio del usuario.

Figura 6: Uso de Named Pipe Impersonation en Meterpreter

Desde los servicios de Windows se puede ejecutar un nuevo servicio, el cual se ejecuta con usuario SYSTEM y puede enviar cualquier mensaje a través del pipe llamado gbsbtr. Aquí tenemos la escalada. El servicio es creado y está listo para conectar con el pipe. Cuando el servicio arranca, se lanza un cmd.exe como SYSTEM y conecta al pipe creado por el proceso generado por Metasploit, el cual ahora obtiene un entorno de SYSTEM.

Detectándolo en la máquina

Ahora, vamos a ver cómo detectar esta situación en una máquina comprometida. Para ello hacemos uso de Powershell y del cmdlet Get-EventLog. Buscamos dentro del mensaje de los eventos el contenido "A service ". Nos devolverán todos los eventos que encajen con lo buscado.

Figura 7: Buscando servicios con PowerShell

En esta ocasión, se puede ver como se recopila la información del registro de eventos de Windows y se buscan los servicios que tienen un pipe creado para interactuar. Hay que fijarse en la expresión regular de "*\\.\pipe*".

Figura 8: Buscando servicios con pipe

Una vez tenemos esto, se puede ver que lo almacenamos en una variable. Esta variable el contenido de los diferentes objetos podemos verlo con la instrucción $services | ForEach-Object {$_.message}. Obtenemos el comando ejecutado por cmd.exe y el servicio creado, además, de la cuenta de servicio utilizada, en este caso se puede ver como realmente es SYSTEM.

Figura 9: Servicio instalado

Una técnica interesante para el pentesting y que muchas veces utilizamos en el día a día. Es interesante ver cómo funciona por debajo y saber que está ocurriendo a nivel de proceso para que esto tenga éxito y en qué condiciones puede fallarnos.

Figura 10: PoC de Named Pipe Impersonation

En el vídeo anterior tenéis una demostración de 1 minuto paso a paso de cómo funciona el proceso de Named Pipe Impersonation desde una equipo con Kali Linux.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”,  Hacking Windows, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths