25 jun 2021

Salto de pértiga al UAC


¡Muy buenas!

Este es mi primer post en este blog, y quería estrenarme en Flu Project hablando sobre las escaladas de privilegios, en concreto, me centraré en una escalada de privilegios basada en la técnica T1574.001 de MITRE ATT&CK. El objetivo que hoy expondré aquí es el de llegar a abrir una CMD con los privilegios de administrador, evadiendo el UAC del sistema.

Para ello, utilizaremos una técnica de DLL Hijacking, con la cual, cuando el sistema necesite utilizar la DLL en cuestión, utilizará la DLL que nosotros hemos preparado anteriormente con el código “malicioso” en su interior. Esto se produce porque muchos binarios y archivos de sistema no contienen una ruta absoluta hasta la DLL en cuestión.

Como aclaración, todo esto se realizó en las siguientes versiones de Windows 10:

  • 20H2 compilación de SO 19042. 1081
  • 21H1 compilación de SO 19043. 1052



Bien, como dijo John The Ripper, vamos por partes:

Primero, estando en el sistema víctima abrimos una consola de Powershell. Con la cual crearemos una carpeta donde alojaremos el binario a usar y su DLL. Para abrir la consola de comandos, podemos usar la combinación de teclas de Tecla Windows + R, la cual abrirá la ventana de ejecutar. Aquí pondremos la palabra powershell y le daremos a OK o Enter de nuestro teclado.


Cuando se nos haya abierto la consola, podemos probar a utilizar el comando: 

Whoami /priv

Con el cual podremos observar los privilegios que tenemos, los cuales deberían ser como se muestran en las imágenes, sin privilegios especiales.


Segundo, con nuestra consola ya abierta, vamos a crear la carpeta, para ello utilizaremos el siguiente comando.

cd .\Desktop\

New-Item Poc -ItemType Directory


Tercero, con la carpeta ya creada, necesitamos para este ejemplo el binario ComputerDefaults.exe de la carpeta System32. El cual, podemos copiar manualmente o desde consola como muestran las imágenes.

copy C:\Windows\System32\ComputerDefaults.exe "C:\Users\User\Desktop\Poc\ComputerDefaults.exe"


Con esto ya tenemos la mitad del trabajo hecho, ahora solo necesitamos una DLL que utilice este binario, en este caso utilizaremos profapi.dll. Podemos comprobar con el Process Monitor que ComputerDefaults.exe utiliza esta DLL.


La DLL está alojada en la misma ubicación que el binario, esto es lo que hace que funcione, el binario no lo busca únicamente en una ruta absoluta como sería lo correcto, si no que, primero lo busca donde el propio binario está ubicado. Bien, ahora vamos a crear una DLL y la vamos a llamar igual que la que requiere el binario. Para ello, podemos utilizar una plantilla que nos proporciona Windows:

https://docs.microsoft.com/en-us/windows/win32/dlls/dllmain.

Copiamos desde la palabra BOOL hasta el último símbolo de cierre de llave incluido, lo pegamos un archivo de texto nuevo, el cual llamaremos profapi.c


Cuarto, ahora necesitamos modificar el archivo profapi.c, para que cuando lo convirtamos en DLL realice la función que nosotros queremos. 


Con el archivo modificado y guardado, necesitamos descargar Visual Studio para poder compilar la DLL que hemos creado.



Cuando hayamos descargado e iniciado la instalación, primero hay que descargar los archivos necesarios y después se nos abrirá una ventana donde aparecerá lo que se va a instalar. Por seguridad, le daremos a Modify, el cual nos abrirá otra ventana donde podremos añadir qué paquetes extras queremos en la instalación. A nosotros nos interesan 2 en concreto:

.NET desktop development y Desktop development with C ++.



Con estos dos seleccionados podemos seguir con la instalación. Posteriormente sería recomendable reiniciar el equipo.

Quinto, con todo instalado y reiniciado el pc, necesitaremos abrir una consola que nos proporciona Visual Studio. Podemos utilizar el buscador que se encuentra la derecha del símbolo de Windows, incluimos la palabra Native y deberían de salirnos dos, en nuestro caso cogeremos el de x64.


Sexto, con nuestra consola x64 Native Tools abierta, iremos a la ubicación del archivo, para evitar problemas. Y ejecutaremos el siguiente comando:

cl /LD /TC /DUNICODE /D_UNICODE profapi.c

cl – El compilador.
/LD – Crear .DLL
/TC – Compilar todos los archivos como .C
/DUNICODE – Como Unicode todos los textos.
/D_UNICODE – Como Unicode todas las funciones.


Esto nos genera 2 archivos, pero solo nos interesa profapi.dll. Con nuestra DLL creada, solo tenemos que llevarla a la carpeta que hemos creado donde se encuentra el binario ComputerDefaults.exe.


Ahora solo tendremos que hacer doble clic en ComputerDefaults.exe y se nos abrirá una consola. Podremos observar que en el nombre de esta consola aparece la palabra Administrador. Aun así, para asegurarnos, haremos como al inicio de la práctica, utilizaremos el comando Whoami /priv
para ver si de verdad contiene privilegios administrativos.


NOTA: Se ha podido observar que si el UAC no es restrictivo no debería causar ningún problema.

Para finalizar, me gustaría agradecer esta práctica a un par de personas, en primer lugar, Eduardo Parra San José, pues gracias a él puedo estar hoy aquí exponiendo esta técnica la cual él me mostró con el mismo entusiasmo que intento reflejar aquí. Y en segundo lugar y no menos importante a mi compañero de trabajo y de Flu Project, Francisco Palma, el cual hace que todo esto sea posible con sus enseñanzas diarias y su gran paciencia. :)

¡Un saludo!

18 jun 2021

Nuevo Windows 11: Una ventana al futuro

Muy buenas a todos! Recientemente "se filtró" una ISO de la nueva versión del Sistema Operativo de Microsoft, más concretamente se trata de Windows 11 Build 21996.1, la cual podemos levantar en una máquina virtual como de costumbre. El proceso de instalación es similar al que ya conocemos: tenemos el famoso asistente de instalación y luego se nos presentará un renovado asistente de configuración que debemos completar eligiendo las diferentes opciones que se nos proponen, para elegir cómo queremos compartir nuestra información... 
Si bien seguramente hay muchas cosas que todavía restan por pulir antes que liberen la versión definitiva y más allá de algunos cambios visuales respecto a su antecesor, en esta oportunidad queremos evaluar algunos aspectos de seguridad. En particular nos centraremos en las credenciales de usuarios.

Nuestro primer paso es recurrir a las herramientas de la colección de Impacket. Para ello haremos uso de secretsdump desde un equipo conectado a la red para obtener los hashes NTLM de los usuarios locales. Hay que tener en cuenta que para realizar esta tarea se debe contar con credenciales válidas de un usuario con privilegios que tenga permisos sobre RPC en el equipo objetivo.


Obtenemos un volcado de la SAM desde un equipo en la red mediante secretsdump


Luego procedemos a realizar pruebas en local. Lo primero que haremos será desactivar el mecanismo principal de control, el Windows Defender. Las opciones para desactivarlo se mantienen sin cambios, tanto utilizando la interfaz gráfica, como comandos de PowerShell:

> Set-MpPreference -DisableRealtimeMonitoring $true

Luego procedemos a hacer uso de la herramienta mimikatz del gran gentilkiwi. Lo primero que detectamos es que podemos acceder a la SAM sin inconvenientes y de manera habitual.

Obtenemos la SAM localmente mediante mimikatz
 
La limitación aparece cuando queremos acceder a la información del proceso lsass para obtener las credenciales que están cargadas en memoria.

Intento fallido de obtener credenciales desde proceso lsass
 
Como alternativa, podemos realizar un volcado de la memoria del proceso desde el Task Manager, para eso lo iniciamos como administrador y generamos el fichero desde el menú contextual


Generando el volcado del proceso LSASS
 
 
Pero al cargar el fichero en mimikatz mediante minidump y tratar de acceder a la información, obtenemos el mismo mensaje de error.

Otro intento fallido...
 
 
Podríamos pensar que se encuentra activada la protección sobre lsass, por lo que procedemos a cargar el driver de mimikatz para desactivar esta característica. Si bien el driver se carga sin problema y se elude la protección, no logramos acceder a la información y obtenemos el mismo error. 

Intento luego de desbloquear protección con driver

Como dato extra, podemos ver que en el registro no se encuentra la clave RunAsPPL que establece que deben protegerse las credenciales cargadas en memoria.

Registro: HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Probablemente se trata de problemas en el parseo, debido a cambios relativos a la nueva versión, esto ha ocurrido anteriormente al liberarse nuevas versiones del sistema operativo que obligan a adaptar la herramienta, podemos ver que en esta issue se menciona el problema.
 
Algo similar ocurre para los casos de lsassy y crackmapexec, ambos ejecutados desde una máquina remota conectada a la red.

Mensaje de error de signature tanto para lsassy como para CrackMapExec

En conclusión, podemos intuir que los métodos de gestión de credenciales no han sufrido cambios desde la anterior versión de Windows, tanto para los hashes en la SAM, como los que se mantienen en memoria en el proceso lsass.exe. Por el momento, no podemos hacer uso de mimikatz y otras herramientas para acceder a algunas credenciales, pero confiamos en los investigadores y desarrolladores para que puedan hacer los ajustes necesarios para que funcionen en esta nueva versión, tal como ha ocurrido con los distintos builds en ocasiones anteriores.
 
Saludos!!




8 jun 2021

El 11 de junio celebraremos el Webinar gratuito: "Ciberseguridad en los eSports"


El próximo 11 de junio a las 19:00h (España), tendremos el placer de organizar junto a la Federación Española de Jugadores de Videojuegos y eSports y el Consejo de la Juventud de España un webinar centrado en la ciberseguridad en los eSports. Será una mesa redonda de debate, en la que participaré junto a mi compañero Jesús Alcalde para responder las dudas de ciberseguridad del resto de miembros de la mesa, de forma abierta y cercana. Así mismo, cualquier internauta podrá preguntar a los miembros de la mesa sus dudas en la materia, y trataremos de resolverlas en directo, por lo que, ¡no os lo podéis perder! Nos encantaría que fuese un webinar dinámico, donde todos podáis participar, y por ello, FEJUVES ha puesto a vuestra disposición un formulario para que, durante esta semana, podáis enviar todas vuestras dudas y consultas sobre ciberseguridad en los eSports, para que puedan ser resueltas durante el webinar:

https://www.fejuves.es/el-11-de-junio-celebraremos-el-webinar-gratuito-ciberseguridad-en-los-esports/

Sin duda, las estafas en las compras de skins y demás contenidos digitales, los robos de cuentas de redes sociales o los ciberataques a servidores y demás dispositivos, ocuparán gran parte de las cuestiones, pero no dudéis en plantear cualquier inquietud sobre seguridad en el mundo de los videojuegos, los eSports o la generación de contenidos, y trataremos de darles respuesta con el mejor de los criterios posibles.

Finalmente, nos gustaría contaros que tendremos numerosas sorpresas en la mesa, con varias  incorporaciones muy interesantes e influyentes del sector, que iremos desvelando a lo largo de esta semana. 

¡Estad muy atentos a nuestras redes sociales!


2 jun 2021

¿Cómo proteger tu cuenta de Twitter? MyPublicInbox colabora con ESET en la creación de un asistente

La configuración de la privacidad y de la seguridad en una red social puede ser, en algunos casos, un dolor de muelas para un usuario. Cada vez las redes sociales ofrecen mayores funcionalidades, así como mayores posibilidades tecnológicas. Debido a esto, es importante conocer las posibilidades de privacidad y seguridad que tienen éstas. Si nos centramos en Twitter podemos encontrar un gran número de opciones que permiten que podamos ser "encontrables" por nuestro email o teléfono, que podamos proporcionar nuestra localización, que podamos ser suplantables por no tener la verificación de la cuenta, disponer de un segundo factor de autenticación en la cuenta y un largo etcétera de situaciones y cosas.

En MyPublicInbox han creado un nuevo servicio, en colaboración con ESET, para que todos los usuarios de la plataforma puedan utilizarlo. Ya seas un perfil público o un contactado puedes acceder al servicio. La opción se encuentra en la parte superior derecha del sitio web, en la zona de tu perfil, y encontrarás la frase "Securiza tu Twitter". El wizzard para securizar Twitter tiene un coste de 100 tempos. El servicio dura un mes y se puede ejecutar las veces que se quiera. 

¿Cómo funciona?

Cuando se quiere utilizar el servicio se pide que se autorice a una app de MyPublicInbox. Esta app revisará diferentes aspectos relacionados con la privacidad y seguridad del usuario. Cuando pasan unos segundos y se verifican ciertas acciones, el resultado proporciona el nivel de seguridad de tu cuenta, en función de lo que el wizzard haya podido comprobar. 


El resultado tiene un aspecto informativo que ayuda a entender los riesgos que podemos tener en nuestra cuenta de Twitter. Lo interesante es que, además, el wizzard proporciona consejos, aparte de indicarnos que cosas deberíamos mejorar. En resumen, un sencillo wizzard que revisa las opciones de seguridad y privacidad y que permite a los usuarios entender las cosas que pueden mejorar para fortificar su cuenta, en este caso en Twitter. Seguramente, con el paso del tiempo, se encontrará en más redes sociales. Buena idea de la gente de MyPublicInbox.

1 jun 2021

WLMS.exe: the Reboots Lover

Hello everyone!

Today we want to talk about WLMS, better known as Windows License Monitoring Service, the Windows service that allows to manage the evaluation licenses of the ISOs provided by Microsoft in its official repository.


Fig 1: If you have this registry... you have been swindled with your Windows.

How does WLMS work?

WLMS is a service present in Windows evaluation systems responsible for managing the validity of test licenses. This service controls that said license expires within the established deadlines and, in case of doing so, performs certain actions, such as adding a sign indicating that the license has expired or scheduling an automatic system reboot every hour.

Fig 2: If only this was reported, it would be even funny.

However, the limitation of functionalities or the appearance of informative banners are usually not problems for this type of virtual machines, since, normally, the main use of these environments is usually the realization of tests and test deployments. However, the forced reboot every hour... is it really necessary?

Fig 3: Inactive license? Well, I'll reboot you.

How do we avoid reboots?

Although the Microsoft WLMS documentation does not exist (or, at least, we have not been able to find it), there are several articles discussing how it works and possible ways to stop its operation. Obviously, the simplest way is the most optimal: disable the service.

To do this, we have to take into account the following points:

  • The WLMS service runs with SYSTEM integrity, so we will need that integrity to modify permissions and features.
  • The service is defined in such a way that, when there is a failure in its execution, the computer will automatically restart. 
  • Even if the service is disabled, the computer will likely restart itself one last time. From then, it should not restart itself again.
Fig 4: The "untouchable" service.

How do we change the features of this service?

As we have mentioned, we need SYSTEM integrity in order to modify the properties of the service. To achieve such integrity, we have several mechanisms (as detailed in this post). We will choose the comfortable version: Process Hacker. 

Fig 5: Process Hacker + Run as: Cmd as System.

Through Process Hacker, we can obtain a panel with SYSTEM integrity and from where we can open the services.msc process to modify WLMS permissions.

Fig 6: We open services.msc as System.

Once we have the WLMS service open, we can modify its properties: disable the service and, just in case, disable actions in case of service failure.

Fig 7: Final configuration of the service after its modification.

If all went well, after rebooting our machine (or waiting for it to reboot itself), our test device will never reboot itself again, even if the license has expired.

Fig 8: More than 1 hour on without a license...

Finally, if by chance you have a test laboratory with an Active Directory deployed and all your machines are evaluated, you can deploy a GPO that disables this service throughout the infrastructure, facilitating the process and avoiding the use of external programs such as Process Hacker or PsExec.

Fig 9: GPO to disable the service.

Note: with GPO only the service is disabled, its properties remain unchanged in case of failure... although if the service does not run, there should be no execution failures, right?

Fig 10: Although I would change it anyway...

Happy Juanking!

WLMS.exe: el amante de los reinicios

 ¡Muy buenas a todos!

Hoy os venimos a hablar de WLMS, mejor conocido como Windows License Monitoring Service, el servicio de Windows que permite gestionar las licencias de evaluación de las ISOs proporcionadas por Microsoft en su repositorio oficial.

Fig 1: Si tienes este registro... te han tongado con tu Windows.

¿Cómo funciona WLMS?

WLMS es un servicio presente en los sistemas Windows de evaluación encargado de gestionar la validez de las licencias de prueba. Este servicio es el encargado de controlar que dicha licencia expire dentro de los plazos establecidos y, en caso de hacerlo, realiza determinadas acciones, como añadir un cartelito indicando que la licencia ha expirado o programar un reinicio del sistema automáticamente cada hora.

Fig 2: Si solo notificara esto, hasta sería gracioso.

Ahora bien, la limitación de funcionalidades o la aparición de carteles informativos no suelen ser problemas para este tipo de máquinas virtuales, ya que, normalmente, el principal uso de estos entornos suele ser la realización de tests y despliegues de prueba. Sin embargo, la aparición de un reinicio forzado cada hora... ¿es necesario?

Fig 3: ¿Licencia inactiva? Pues te reinicio.

¿Cómo evitamos los reinicios?

Aunque en la documentación de Microsoft WLMS no exista (o, al menos, nosotros no hemos sido capaces de localizarlo), existen varios artículos donde comentan cómo funciona y posibles maneras de parar su funcionamiento. Obviamente, la manera más sencilla es la más óptima: deshabilitar el servicio.

Para ello, tenemos que tener en consideración los siguientes puntos:

  • El servicio WLMS se ejecuta con integridad de SYSTEM, por lo que necesitaremos dicha integridad para modificar los permisos y las características del mismo.
  • El servicio está definido de tal manera que, cuando exista un fallo en su ejecución, el equipo se reiniciará automáticamente. 
  • Aunque el servicio se desactive, es probable que el equipo se reinicie solo una última vez. A partir de ese reinicio, no debería volver a reiniciarse solo.
Fig 4: El servicio "intocable".

¿Cómo cambiamos las características de este servicio?

Como hemos comentado, necesitamos integridad de SYSTEM para poder modificar las propiedades del servicio. Para conseguir dicha integridad, tenemos varios mecanismos (como se detalla en este post). Nosotros, optaremos por la versión cómoda: Process Hacker. 

Fig 5: Process Hacker + Run as: Cmd as System.

Mediante Process Hacker, podremos obtener una consola con integridad de SYSTEM y, desde ella, podremos abrir el proceso services.msc para modificar los permisos de WLMS.

Fig 6: Abrimos services.msc como System.

Una vez tengamos el servicio de WLMS abierto, podremos modificar sus propiedades: deshabilitar el servicio y, por si acaso, quitar las acciones en caso de fallo del servicio.

Fig 7: Configuración final del servicio tras su modificación.

Si todo ha ido bien, tras reiniciar nuestra máquina (o esperar a que se reinicie sola), nuestro equipo de pruebas no volverá a reiniciarse solo nunca más, aunque la licencia haya expirado.

Fig 8: Más de 1 hora encendida y sin licencia...

Para terminar, si por un casual tenéis un laboratorio de pruebas con un Directorio Activo desplegado y todas vuestras máquinas son de evaluación, podéis desplegar una GPO que deshabilite dicho servicio en todo el parque, facilitando el proceso y evitando el uso de programas externos como Process Hacker o PsExec.

Fig 9: GPO para deshabilitar el servicio.

Nota: con la GPO solo se deshabilita el servicio, no se cambian las propiedades del mismo en caso de fallo... aunque si el servicio no se ejecuta, no debería haber fallos de ejecución, ¿no?

Fig 10: Aunque yo lo cambiaría de todas formas...

Happy Juanking!