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

Cómo extraer credenciales de Windows: Formas de hacer un minidump al proceso lsass.exe #pentesting #pentest

Durante estos días estamos viviendo experiencias nuevas, duras, pero con tiempo en casa para poder hacer muchas cosas en el tiempo que estamos ahorrando en los traslados de casa al trabajo y del trabajo a casa. Se puede aprovechar para avanzar en proyectos personales tecnológicos, ocio, deporte, etcétera, o proyectos familiares, para pasar más tiempo con la familia y aprovechar para ponerse al día en ciertas cosas que tal vez tuviéramos siempre en la lista de To-Do.

Figura 1: Cómo extraer credenciales de Windows:
Formas de hacer un minidump al proceso lsass.exe

En el artículo de hoy quería mostrar cómo llevar a cabo la extracción de credenciales de cuentas en sistemas Microsoft Windows que se encuentra en el proceso lsass.exe. Esto no es algo nuevo, y siempre que se habla de Hacking Windows: Ataques a Sistemas y Redes Microsoft, es un tema obligatorio, y que Microsoft ha intentado eliminar en Windows 10 con el uso de Credential Guard.

Figura 2: Hacking Windows: Ataques a Sistemas y Redes Microsoft

Hoy quería recopilar diferentes formas de hacer el volcado o dump de la memoria del proceso lsass.exe y aprovechar, por ejemplo, herramientas como Mimikatz para leer la información de dicho volcado de memoria.

Acceso físico: Create Dump File en el Task Manager

En primer lugar, vamos a ver la técnica más sencilla, que puede ser utilizada en un proyecto de Ethical Hacking. Si se tiene acceso al equipo, se puede hacer un volcado de la información del proceso lsass.exe desde el propio Administrador de Tareas (Task Manager). Esto tiene sentido cuando tenemos acceso físico a la máquina.

Figura 3: Solicitando un volcado de la memoria de lsass.exe desde el Task Manager

Cuando se genera el fichero de dump, éste se almacena en la ruta \Users\[nombre usuario]\AppData\Local\Temp. El volcado del proceso estará alrededor de los 40-43 MB y estará listo para ser “ojeado” por el pentester.

Figura 4: Libro de Ethical Hacking

En la Figura 3 se puede ver el "Task Manager" de un sistema Windows 7, aunque el proceso en un Windows 10 sería el mismo. Este proceso sirve para hacer volcados o minidump de procesos que se están ejecutando en la máquina.

Utilizando Mimikatz con minidump

Con Mimikatz podemos hacer uso de minidump para enlazar el dump del proceso lsass.exe con las instrucciones de sekurlsa. Lo que ocurre es un switch para las instrucciones de sekurlsa, para que operen sobre el volcado de memoria proporcionado bajo la instrucción sekurlsa::minidump [ruta al fichero DMP].

Figura 5: Mimikatz con instrucción skurlsa

En este momento, en cuanto hagamos uso de sekurlsa::logonpasswords u otras instrucciones que se pueden ejecutar y que hacen uso de lsass.exe. La imagen de la Figura 5 está sacada de un Windows 7.

Utilizando Procdump de Sysinternals

La herramienta Procdump de Sysinternals sirve para llevar a cabo un volcado de memoria de un proceso. Para llevar a cabo un volcado de proceso con procdump se debe ejecutar la siguiente instrucción:

procdump –ma lsass.exe lsass.dmp

El resultado es un volcado como el obtenido en el ejercicio anterior. El uso de procdump necesita de privilegios, pero se puede ejecutar a través de una shell remota, aunque previamente se debe subir el binario. Al ser un binario de SysInternals, no será detectado como algo malicioso.

Figura 6: Utilizando procdump.exe

El tema de la detección es interesante, ya que utilizar herramientas como PSExec o las PSTools ayudan a realizar acciones en el pentesting que no son tratadas como maliciosas.

Figura 7: Una vez conseguido el volcado. Mismo proceso.

Una vez obtenido el volcado del proceso se puede realizar la misma acción que hicimos con Mimikatz en el apartado anterior. El resultado es el mismo, como puede verse en la Figura 7.

Utilizando comsvcs.dll para hacer el volcado

De forma nativa, Windows 7, incluso Windows 10, permiten hacer el volcado de un proceso. Para llevar a cabo esta operativa lo vamos a ejemplificar en un Windows 10 y una Powershell 5.1, haciendo un poco de Penstesting con PowerShell.

Figura 8: Pentesting con PowerShell (2ª Edición)

Lo primero es listar el proceso lsass.exe y recoger el ID de este proceso. Por ejemplo, haciendo uso de get-process lsass en una Powershell. Después se puede ejecutar el binario:

rundll32.exe [ruta a comsvcs.dll], MiniDump [PID] [ruta almacenar el DUMP]

Tal y como puede verse en la imagen es algo sencillo y silencioso. Eso sí, necesitaremos privilegios previos.

Figura 9: Volcado de memoria con lsass.exe con PowerShell

Y, por último, cómo hemos hecho antes, ejecutamos Mimikatz en Windows 10. La sintaxis en Mimikatz es igual en todos los casos.

Figura 10: Usando Mimikatz para extraer las credenciales

Diferentes formas de hacer lo mismo y analizar el volcado del proceso. Técnicas que se deben conocer y que son útiles en un proceso de Ethical Hacking. Practica durante estas semanas, pasa el tiempo y aprovecha para mejorar tu conocimiento.

Desde hoy, y durante las próximas dos semanas en @0xWord hemos puesto un descuento de un 10% de descuento con el código YOMEQUEDOENCASA en todos los productos, y hemos rebajado un 5% los VBOOKS (Cursos Virtuales). Por favor, colaboremos con quedarnos todos en casa.

— 0xWORD (@0xWORD) March 16, 2020

Recuerda, que durante este tiempo tienes la opción de adquirir los cursos y libros de 0xWord con un 10% de descuento, y que además puedes consultar a todas las cuentas de MyPublicInbox a mitad de Tempos.

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 12: Contactar con Pablo González

Pentesting con PowerShell: Movimiento lateral con Invoke-WMIExec

En las últimas semanas y meses he ido hablando sobre diferentes técnicas de movimiento lateral como, por ejemplo, el uso de los objetos DCOM con la técnica ShellWindows - también con DCOM usando la MMC (Microsoft Management Console) - o con el uso del protocolo RDP con SharpRDP. Hoy quería mostrar otra forma de hacer un Lateral Movement (Movimiento Lateral) en un Ethical Hacking a través del uso de WMI y Powershell. Es decir, un poquito de Pentesting con PowerShell para hoy.

Figura 1: Pentesting con PowerShell: Movimiento lateral con Invoke-WMIExec

Ya sabemos que Powershell es muy utilizado hoy en día por cualquier Red Team y en cualquier proyecto de Ethical Hacking. La importancia que ha cobrado Powershell en la post-explotación es muy grande. Por esta razón han ido saliendo protecciones como el modo restringido del lenguaje o el propio AMSI. De estos también hemos hablado en el último año, y es que el bypass de AMSI está cotizado y es un proceso con el que cualquier pentester debe enfrentarse.

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

Lo dicho, hoy quería analizar el uso de WMI para hacer movimiento lateral, incluyendo una escalada de privilegios, en el caso de que se consiga el hash de un administrador local de una máquina del dominio o de la red en la que nos encontremos. La función Invoke-WMIExec puede descargarse desde el repositorio de Github de su creador Kevin Robertson.

Figura 3: GitHub de Kevin Robertson

Lo primero que nos puede llamar la atención al volcar la función en una Powershell en Windows 10 es que AMSI “no se queja”. Aunque en el artículo veremos cómo desde un Windows 7 llegamos a ejecutar código en Windows 10 gracias a este pass-the-hash, me ha resultado curioso ver que AMSI no diga nada sobre la función.

Figura 4: Hacking Windows: Ataques a sistemas y redes Microsoft

Eso sí, si tenéis activo el modo restringido del lenguaje en Powershell, éste sí que evitará la ejecución de la función. En la siguiente imagen se puede ver cómo se ha cargado la función en el proveedor de funciones de Powershell en Windows 10. Dicho esto, vamos a seguir viendo qué podemos hacer.

Figura 5: Función cargada en el proveedor de PowerShell

Ahora vamos a probar en Windows 7 con una Powershell 5.1 la función. Lo primero es descargarla a memoria y una vez cargada la vamos a ejecutar. La instrucción que vamos a lanzar es:

Invoke-WMIExec –Hash [hash NTLM] –Target [Dirección IP] 

        –Username Administrator –Command [comando a ejecutar]

Aquí nos damos cuenta que si ejecutamos el comando whoami no podremos ver la salida, por lo que optamos por el comando “cmd.exe /K echo hola > c:\boom.txt”. Este comando remoto levantará una CMD que pintará un “hola” y lo redirigirá a un archivo en C:\ llamado boom.txt.

Figura 6: Redirección a boom.txt

Tenemos que tener claro que para poder escribir en C:\ tenemos que tener privilegios en el sistema, pero estamos autenticando como Administrator, por lo que los tenemos. Aquí también hacemos escalada de privilegios en el sistema, gracias al hash.

Muchas veces nos preguntamos y podemos hacer lo mismo con un usuario que no sea RID = 500, es decir, que no sea administrador “real” de la máquina. Tal como está el sistema actualmente no, pero existe una clave en el sistema que si está activa habilita el uso del pass-the-hash a usuario no RID 500. En la siguiente imagen podemos ver cómo creamos la clave LocalAccountTokenFilterPolicy. Es una DWORD con valor 1.

Figura 7: Clave que habilita que se haga el pth (pass-the-hash)

Si esta clave existe, se podrá hacer un ataque de red tipo pth (pass-the-hash) con cualquier usuario. Vamos a comprobarlo. En el primer ejemplo de la imagen vemos que cambiamos el hash del usuario Administrator y la ejecución de Invoke-WMIExec falla. Acceso denegado. Después, probamos con el usuario IEUser y con su hash correcto, pero nos falla, ¿Por qué? Esa ejecución es de antes de habilitar la clave del registro anterior.

El tercer intento que ya es correcto, en lo que autenticación se refiere, funciona debido a que el hash es correcto con el usuario y la clave del registro está habilitada. El fichero boom.txt no se escribe en C:\ ya que el usuario IEUser no tiene privilegio. El último caso es el que funciona correctamente, tanto en autenticación como en la creación del fichero, ya que el usuario tiene permisos en su carpeta.

Figura 8: Ejecución correcta

Ahora vamos a ver el resultado de la última ejecución. Se crea el fichero indicado en el parámetro Command. El escritorio del usuario IEUser recoge el archivo ridnot500.txt con el contenido “hola”, como se indicaba en la instrucción Invoke-WMIExec.

Figura 9: Fichero creado en C:/

Como se puede ver esta técnica proporciona integración con Powershell, lo cual ayuda a ejecutarla en modo “fileless” y permite tener más vías para llevar a cabo este tipo de movimientos laterales en un pentest o un Ethical Hacking. Otra técnica para la mochila del pentester a tener muy en cuenta.

Desde hoy, y durante las próximas dos semanas en @0xWord hemos puesto un descuento de un 10% de descuento con el código YOMEQUEDOENCASA en todos los productos, y hemos rebajado un 5% los VBOOKS (Cursos Virtuales). Por favor, colaboremos con quedarnos todos en casa.

— 0xWORD (@0xWORD) March 16, 2020

Como nota final, en esta campaña de encierro - donde también #YoMeQuedoEnCasa - sabéis que tenéis un descuento del 10% en todos los libros de hacking, pentesting y seguridad informática en 0xWord. Aprovechemos este tiempo para aprender muchas más cosas.

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